応用情報技術者の過去問・解答解説 平成25年秋・午後問8 (Webサイトのセキュリティ対策)
応用情報・平成25年秋・午後問8の問題および解答解説。
設問1
- (設問1)暗号化せずに流れると困るデータを,問題文の中から2つ。
↓
ユーザIDとパスワード。
なぜかというと,これは「ログイン情報」だから。
ユーザが購入した製品の情報などは,いわばどうでもいい情報。
誰が購入したのかわからなければ,製品の情報を盗み取ったところでとくにメリットはないのだから。
ユーザIDが漏洩するのは,別に構わないのでは?
と思う方,その意識はまずい。
ユーザIDを入手したら,そのユーザのふりをすることが可能になり,
なりすまして「パスワードを忘れた」などと偽って,
アカウントを乗っ取ることも可能になるのだから。
つまり,パスワードを管理するシステム管理者に対する「ソーシャルエンジニアリング」攻撃につながってしまうのだ。
設問2
- (設問2)3つのセキュリティ強化の施策について,何の脅威に対する対策なのか?
- (1)HTTPをHTTPS化
- (2)DMZにWebサーバを置くのをやめて,リバースプロキシを代わりに設置
- (3)リバースプロキシにWAF機能を持たせ,ブラックリストで脆弱性攻撃を管理
→それぞれ・・・
(1)認証情報の盗聴。
HTTPSにするとなにが変わるかというと,ユーザとサーバの間の通信が見えなくなる,ということ。
サーバそのものは何も変わらない。ユーザに関わる部分を秘匿できる。
よって,認証情報の盗聴を防げる。
なおHTTPSにしたところで,サーバの中身は改ざんされうるし,
暗号化通信の中でSQLインジェクションなどの攻撃も受けることがありうる。
(2)Webサイトの改ざん。
要は,侵入である。
DMZはインターネットに直接となりあって接している部分だから,侵入の攻撃を受けやすい。
これを,www側から手の届かない社内LAN側に移動させてしまえば,攻撃者はDMZ止まりとなる。
なおサーバへの侵入が防げたとしても,通信内容が読み取られたり
SQLインジェクションを受けたりという可能性は残る。
(3)SQLインジェクションとクロスサイトスクリプティング。
Webアプリの脆弱性を狙った攻撃パターンを登録しておく,
ということなので,特定のパターンの通信を検出している。
つまり,通信内容が変かどうかを見ているのだ。
なお,通信内容のパターンを見ただけでは,その通信が漏れているかどうかはわからない。
またユーザ側の通信のパターンを調べているだけでは,サーバ側が改ざんされたかどうかもわからない。
設問3(1)
- 設問3(1):
- (a)HTTPSを使って通信するために取得するもので,認証局に申請し,識別名などの情報を掲載するのは?
- (c)(a)を申請する際に,識別名とともに必要になるもので,あるペアの片方をなすものは?
- (d)(c)のペアのもう一つで,機器に導入するものは?
→それぞれ,SSLサーバ証明書,公開鍵,秘密鍵。
SSLクライアント証明書は,機器に導入するのではなく,アクセスしたいユーザが持つもの。
ルート証明は,サーバ証明書を発行する業者が,自分が信頼の置ける機関であることを証明するために,最上位の認証局であることを示すもの。
公開鍵は証明書の認証局も知っている情報だが,秘密鍵は機器を運用する側しか知らない。
共通鍵はここでは出てこない。
共通鍵はそもそも公開鍵基盤(PKI)の普通の仕組みでは出てこない。
共通の鍵を事前に共有しておくための搬送の仕組みがなく,
その問題点を解消するために公開鍵方式が生まれたのだから。
設問3(2)
- 設問3(2):サーバ証明書の申請の際に必要となる,コモンネーム(SSL接続するサイトのFQDN)の具体例は?
→www.a.co.jp
「www」も含めた部分なのがポイント。
a.co.jpの中でWebサーバとして動いているマシンはwww.a.co.jpであり,
そのマシンの完全修飾名は何か,ということだから。
この問題の正答率は低かったそうな。
※豆知識:
http://www.a.co.jp/ は存在しないが,
http://www.a-co.jp/ はアクセスできる。
設問3(3)
- 設問3(3):認証局に申請した結果,取得できたものを,DMZ内のどの機器に設置する必要があるのか?その機器でなければならない理由は?
→この問題の特有のNW構成に依存した解答となる。
答えはロードバランサで,理由はCookieの情報を参照する必要があるから。
Webサーバやリバースプロキシに証明書を置いてしまうと,
そこまでの途中の経路では通信が暗号化されてしまい,
パケットの中身を読めない。
この問いでは,まずロードバランサが通信の中身を読み取って処理に利用するので,
そこよりも後ろ側には証明書を置けない。
そして,ロードバランサよりもさらに前の段階となると,DMZ内ではなくなってしまう。
DMZを守るのがファイアウォールであって,ファイアウォール自体に機密情報を置くなどありえない。
そういうわけで,答えはロードバランサなのだ。
設問4
- 設問4:証明書についてセキュリティの警告ダイアログが表示されるようになってしまったら,Webサイト管理者はどうするべきか。
→SSLサーバ証明書を更新する。
期限が切れたので,証明書を丸ごと更新するということ。
全体の考え方
DMZとリバースプロキシを使った構成は,他の年にも出題されている。
また,証明書をつかった安全な通信の仕組みについて,PKIの原理や運用方法を押えておこう。
今回出たのは,証明書を・・・
- 申請するには?
- 設置するのはどこ?
- 期限が切れたら?
- 認証局が持つタイプの証明書は?
などの総合的な運用方法が問われている。
この問題に類似した例題
ルートCAについての関連問題:
必ず受かる情報処理技術者試験-平成21年度秋季-情報セキュリティスペシャリスト-問題・解答2
http://kanauka.com/kakomon/sc/h21a/002.html
勉強用の資料
SSLのルート証明書とは何か:
ルート証明書とは 【 root certificate 】 - 意味/解説/説明/定義 : IT用語辞典
http://e-words.jp/w/E383ABE383BCE38388E8A8BCE6988EE69BB8.html
- 認証局が、その正当性を証明するために自ら署名して発行するデジタル証明書
ルート認証局の信頼性 | SSL・電子証明書ならグローバルサイン
https://jp.globalsign.com/service/knowledge/ca/trust.html
- 階層構造の最上位に位置する認証局をルート認証局と呼び、ルート認証局自身は自分自身に対して電子証明書を発行しています。
公開鍵証明書認証局(CA)|応用情報技術者試験に受からなかったらクビ。
http://ameblo.jp/gokaku-kigan/entry-10389691014.html
- CAにはルート認証局(root CA)と中間認証局(intermediate CA)がある。
ルート証明書 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%BC%E3%83%88%E8%A8%BC%E6%98%8E%E6%9B%B8
- ルート証明書は、発行された証明書の中で木の根元に位置する。すべての証明書は、自らの親となるルート証明書の持つ信頼性を継承する。
SSL証明書のコモンネームについて:
グローバルIPアドレス用SSLサーバ証明書
https://www.onlinessl.jp/content/global_ip.html
- 従来のサーバ証明書では、”コモンネーム”に FQDN( サーバ名 + ドメイン名 )のみ指定が可能でした
コモンネーム - SSLサーバ証明書用語集
https://www.ssloff.com/ssl/glossary_ka/common-name
- サブドメインなど、複数のコモンネームでSSL暗号化通信を行う場合、コモンネームごとにSSLサーバ証明書が必要
FAQ - コモンネームに「www」をつける,つけないで何が変わりますか?
http://www.m-t.com/faq/index.php?action=artikel&cat=5&id=20&artlang=ja
- SSLサーバ証明書は,ドメイン単位ではなくホスト名単位にて発行されます。そのため,「www」有りと無しのサイトでは,別のサイトとみなされます。
- 例えば,コモンネームをdomain_nameでお申し込み頂いた場合は,www.domain_nameにアクセスすると,セキュリティ警告が表示されます。
よくあるご質問 | KDDI株式会社
http://bizcs.kddi.com/app/answers/detail/a_id/4059
- 異なるサブドメインなどでアクセスした場合にはエラーになります。複数サイトでSSLをご利用になる場合は、サイトごとに証明書が必要です
【用語明解】 コモンネームって何? | SSL証明書をもっと探しやすく、そして低価格 【 SSLコンシェル 】
http://www.ssl-concier.com/news/topics/88
- URLの内、最初のスラッシュ(/)の前までの部分
コモンネームとは 【 common name 】 - 意味/解説/説明/定義 : IT用語辞典
http://e-words.jp/w/E382B3E383A2E383B3E3838DE383BCE383A0.html
- 同じドメイン名の傘下でも,ホスト名が異なる場合には対応する証明書を別に用意しなければならない。
共通鍵方式の問題点:
PKI関連技術に関するコンテンツ
https://www.ipa.go.jp/security/pki/022.html
- 共通鍵暗号方式は、共通鍵を安全な方法でネットワーク越しに配送するための具体的手段が無いという課題があります。
- 公開鍵暗号方式 (Public Key Cryptography) は、この鍵配送の問題を解決した画期的な暗号方式です。
PKIの基礎知識 | 利用者環境の安全性のためのPKI | 信頼のシステム開発.COM
http://www.shinrai-kaihatsu.com/pki_basis.html
- 共通鍵暗号の安全性は鍵の安全性に帰着しますが、鍵そのものを配送しなければならないという本質的な制約が存在しています。
Entrust Japan - PKI 理解のために
http://japan.entrust.com/products/PKI/
- 共通鍵暗号方式は処理速度が速いといった利点がある
- 自分と同じ鍵を相手に送るための確実な手段がない, 複数人と通信を行なうとき鍵の数が相手の数だけ必要になり大きな組織においては不向き、などの問題があります。
- 公開鍵暗号方式は上記の共通鍵暗号方式と違い、自分で秘密にしておく鍵(秘密鍵)と公開してもよい鍵(公開鍵)という異なった2種類の鍵のペアにより構成されます。