「情報処理試験まとめ/情報処理安全確保支援士試験の勉強法まとめ/午後1&2対策」の編集履歴（バックアップ）一覧はこちら
「情報処理試験まとめ/情報処理安全確保支援士試験の勉強法まとめ/午後1&2対策」(2017/12/24 (日) 13:22:53) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
#divclass(pageTitle){情報処理安全確保支援士試験の勉強法まとめは移転しました}
情報処理試験まとめは、まとめwikiより情報処理試験関連情報だけ独立して情報を一新し&blanklink(別サイト){http://shiken.wiki.fc2.com/}に移転しました。
今後ともまとめwikiをよろしくお願いいたします。
&blanklink(移転先の情報処理技術者試験まとめwikiのトップページはこちら){http://shiken.wiki.fc2.com/}
&topicpath()&aname(top)
#divclass(pageTitle){情報処理安全確保支援士 午後1&2対策}
**目次
#contents_line(level=3,sep= / )
**関連ページ
#ls3(情報処理試験まとめ)
**初めに
モバイル版のページが表示される方は見やすいPC版からどうぞ。画面下部の「PC版はこちら」をクリック。
情報処理安全確保支援士試験に合格するためのコツ、勉強テクニックなどを紹介しています。このページでは特に午後問題のテクニックについて解説しています。情報処理安全確保支援士試験の勉強法を知りたい人は[[こちらからご覧ください>>情報処理試験まとめ/情報処理安全確保支援士試験の勉強法まとめ]]。
**参考書など
***参考書の種類について
情報処理安全確保支援士試験、情報セキュリティスペシャリスト試験の参考書は、主に3種類にわかれる。
主に学習をメインとした学習用参考書、過去問の解説に特化した過去問題集。さらに学習用参考書＋直近の数年の過去問題を掲載したハイブリッドタイプだ。
情報処理安全確保支援士試験では、同じような技術に関する出題がかなり多いため、様々な技術やセキュリティに関する解説と過去問解説が非常に重要になると思う。実は他の区分の試験では技術の解説と過去問解説の両方が非常に充実した鉄板本があったのだが、情報セキュリティスペシャリストの参考書ではそのような参考書がなく鉄板本というものが存在しない。
従って知識を得るための学習用参考書と、過去問題集をそれぞれ購入し、学習用参考書で知識を得て、過去問題集で実践し問題になれることが望ましい。
ハイブリッドタイプは参考書のページ数にもよるが、過去問解説が掲載されているぶん技術に関する説明が少なくなってしまうのであまりお勧めできないが、なるべく少ない金額で受験したい場合には有効だろう。
***学習用参考書
学習用参考書としてのお勧めは&blanklink(情報処理教科書){http://amzn.to/2fcqdss}だ。これは主に知識を得るための内容に特化しており、学習用には最適と思われる。
***学習用参考書一覧
#html2()
{
<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=as_ss_li_til&asins=4798148857&linkId=68b4f9995c37acf69098c9c04ca08010"></iframe>
}
#html2()
{
}
***過去問題集
情報処理安全確保支援士試験（新SC試験）では情報セキュリティスペシャリスト試験（旧SC試験）の過去問の演習が主な学習となる。そのため自分が解いた過去問についてどのように解答を導きだしたのかを解説してくれる過去問題集は非常に重要だ。これは他の区分の試験でも同様で、過去問を解いて慣れたり、言い回しを覚えたりする必要があるので、できるだけ過去問題の解説の多い参考書を選択することが合格への近道となる。
しかし旧SC試験では、多くの過去問を掲載している学習用参考書は残念ながら存在しない。そのため学習用参考書とあわせて過去問題集を購入しなければ過去問解説を手に入れることができない。なので、学習用参考書とともに過去問題集は必ず購入するようにしよう。
なお一部の過去問題集ではIPAの解答に準拠していないオリジナルの解答を掲載している問題集がある。IPAが実施する試験においては、IPAの出題意図を考えIPAの求める正解を解答する必要があるためIPAの解答に準拠した解説を掲載している問題集を選んだほうがいい。
これらを考慮すると現時点で実用に耐えうる過去問題集は&blanklink(情報処理教科書 情報セキュリティスペシャリスト 過去問題集){http://amzn.to/2ezyXaX}のみである。しかし残念ながら情報セキュリティスペシャリスト過去問題集は発行年度が古く最新本でも平成25年春までしか過去問が掲載されていない。
そこで学習用参考書は過去2年分以上の過去問題が掲載されている参考書を購入すれば、できる限り多くの年度の過去問解説を手に入れることが可能となる。参考書や問題集を購入する場合には、どの年度の過去問が掲載されているか、IPAに準拠した解説であるかどうかを把握して購入するようにしよう。
***過去問題集一覧
#html2()
{
<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=ss_til&asins=B00G9QJ69U" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>
}
**勉強テクニック
***知識エリアの絞り込み
旧試験の情報セキュリティスペシャリストの試験では、おおまかに以下の分野に分かれて出題される。
-システム設計
-ハードウェア
-ソフトウェア
-運用管理
-ネットワーク
-プログラミング
-データベース
-監査
これらが単独で出題されるわけではなく、関連する形で複数の分野が出題されるので基本的には全般的な知識が必要になる。しかし、この中でも特に頻出な分野がある。それが以下である。
-ネットワーク（ファイアウォール、プロトコル、DNS、SMTPなど）
-運用管理（ログ管理、アクセス制御、インシデント対応、アカウント管理、機密管理など）
-システム設計（暗号、認証、デジタル署名、マルウェア対策など）
-ソフトウェア（ウィルス対策ソフト、ブラウザなど）
特にこれらについては重点的に学習するようにしよう。
また知識エリアの中でも比較的、実務経験がないと難しいと思われるプログラミングやWebアプリケーションにおける対策、法律的な設問が多くなる監査などについてはスルーしてしまうという手もあるだろう。ただし年度によっては両方とも出題される可能性もあるので、そのあたりのリスクは受容しなければならない。
***特に学習しておきたいテクノロジ
その中でも特に頻出するテクノロジなどが存在する。そのためそれらは特に重点的に学習するようにしよう。ここでは頻出技術、特に学習すべきテクノロジについて記述しておく
#divclass(h5) {特に学習しておきたいテクノロジ一覧 }
-http over SSL/TLSの仕組み
-プロクシの仕組み
-SMTPサーバの仕組み
-公開鍵暗号の仕組み
-PKI（ディジタル証明書、サーバ証明書、クライアント証明書、電子署名、認証局）の仕組み
-DNSの仕組み
-ファイアーウォールによるフィルタリングルールの仕組み
-電子メールによる迷惑メール対策や暗号化の仕組み
***特に学習しておきたい情報セキュリティ対策
技術についての知識ももちろんだが、セキュリティに関する知識も必要だ。世の中には様々な脆弱性対策に関する本があるが、ここではIPAが提供する脆弱性対策についてのページを参考にしてみて欲しい。なぜなら情報処理技術者試験はIPAが主催しており、そのIPAが考える脆弱性対策がそのまま試験における正解になっているからである。従って時間があれば、一度IPAの脆弱性対策サイトを利用して学習したり、過去問演習中にわからない脆弱性などがでてきたら、このサイトを参考にして学習していこう。
http://www.ipa.go.jp/security/vuln/
***午後1&午後2の勉強方法
基本的には過去問を解くことで学習をしていく。問題と解答シートを必ずダウンロードし、問題に関しては印刷して解答するようにしよう。なお、このとき必ず設問を選択するところから開始すること。午後2であれば設問1と設問2をしっかりと見比べて、どちらかを選択し、そして完全に解答することまでを2時間以内で行うように学習しよう。どちらの設問を選択するかを決定する能力も磨くことが重要だ。
また旧試験の情報セキュリティスペシャリストの試験では問と問題文を頻繁に行き来して解答していくことになるが、これはPC上でPDFではとても問題文が読みにくい。時間もかかるし、正確な解答時間の計測に不向きなので可能であれば印刷するようにしよう。
また問によっては解答シートをみないと、どのような解答をしなければよくわからないような出題もある。例えば「理由を2つ。またその原因を20文字以内でそれぞれ説明せよ」といった出題だ。解答シートまで印刷する必要はないが、こちらはダウンロードしてPCの画面に表示し、どのような解答を求められているか確認して演習するようにしよう。
***午後1&午後2の復習方法
#divclass(h5) {解答できなかった理由のパターン }
試験で解答できないパターンは概ね以下の3通りにわかれる。
-知識がなかった
-怪しいと思うことができなかった
-問題文のヒントに気がつかなかった
「知識がなかった」というのは、記述された内容や技術に関する知識がなくまったく解答できなかったパターンだ。「怪しいと思うことができなかった」はその技術や運用方法におけるセキュリティ的な問題点に気がつくことができなかったパターンで、「ヒントに気がつかなかった」というのは問題文の中にヒントが記述されておりそのヒントによって解答がかなり狭まるのに、そのヒントに気がつかなかったためまったく見当違いの解答をしてしまうようなパターンである。
演習して間違ってしまった問題については、おおむね上記のパターンに収まると思うので、以下のような復習方法で知識を高めておいて欲しい。
-知識がなかった
--知らない技術やテクノロジ、運用方法、法律などに関しては学習用参考書などを利用にしてその分野の知識を得るようにしよう
-怪しいと思うことができなかった
--それぞれの技術についてセキュリティ的な問題点が潜んでいる可能性を思い浮かべることができるようにしておこう。具体的には本ページの下部の解答テクニックに詳しく記述してあるので参考にして欲しい。
-問題文のヒントに気がつかなかったり、ヒントを間違えた
--問題文にヒントがある場合は演習後にそのヒントのあった部分にアンダーラインを引いて、なぜそこに気がつくことができなかったのかを考え、その対策を検討し、次の演習に備えるようにしておこう。
#divclass(h5) {ヒントに気がつかなかったり、ヒントを間違えた場合 }
問題文の中のヒントに気がつかなかった場合は大きな得点源を失うことになる可能性が高い。そのためヒントを見逃さないことは非常に重要だ。従って確実にヒントを見つけておく必要がある。
ヒントは文中にさらっと軽く書いてあることが多いためどうしても見逃してしまう可能性があるわけだが、そのあたりは集中してとにかく見逃さないようにしよう。
見逃してしまった場合は以下の方法で復習をして欲しい。まずはヒントとなる文章中にアンダーラインを引いておく。ヒントを間違えた場合はその間違ったヒントの部分にもアンダーラインを引こう。そしてその章を読み返す。そしてなんでヒントに気がつかなかったのか、ヒントを間違えてしまったのか確認して分析しよう。そして次回に決してミスをしないようにしよう。
**解答テクニック
***問題文を最初から順番に理解しながら読む
当たり前のことだが、問題文中には様々なヒントが隠されているので、文章をよく理解しながら読んでいくことが重要だ。ちょっとしたことがヒントになっていることもあるので、隅々まで読み疑問に感じたらチェックをしておこう。
また設問は問題文の章ごとにまとめて順番に答えさせるような構成になっていることが多い。問題文を最初から最後まで一気に読もうとすると最初のほうの問題文を忘れてしまうし、あとから読み返すのに時間がかかってしまう。そのため回答する際には、まずは設問を確認し、どこまで読めばその設問の回答が可能なのかを確認しよう。そしてそこまで読んだら問題文を最後まで読まずに設問に回答をしてしまおう。設問は章単位で完結しており、次の章を読まなければ回答できないような出題のされ方はしないため、問題文を読みながら回答できる時点で設問に回答してしまったほうが問題文の内容をよく覚えているので、より正確に回答できるし、問題文を読んでいて疑問に思った内容も忘れずに済むので効果的だし得点もUPする。
***ネットワーク構成図を確認する
設問にはネットワーク構成図がよくでてくる。そのときに、ネットワークにリスクがないかどうか、すぐに判断できるようにならなければならない。具体的には、以下のような公正になっているか、しっかり確認しよう。
-公開されるサーバはDMZに配置されているか
-社内LANとDMZはファイアウォールで切り離されているか
-利用者PC、社内用サーバと管理用PCはL3SWで別セグメントになっているか
-DNSがコンテンツサーバとキャッシュサーバの二つに分かれているか
-メールサーバが内部と外部でそれぞれ設置されているか
-プロクシが設置されているか
-IPSは適切な場所に配置されているか
***送信元か、送信先か
解答として「ポート番号」「IPアドレス」などという答え方をする場合がある。この場合、送信元と送信先の区別がある場合には、必ず「送信元ポート番号」と宛先なのか送り主なのかわかるよう記述をしよう。ただの「ポート番号」だと減点、最悪は不正解になっている可能性がある。「ポート番号」「IPアドレス」という解答を記述するときには、このことを思い出せるようにしておこう。
***単語を聞いたら怪しいと思うことが重要
旧資格の情報セキュリティスペシャリストの問題文では、午後1、午後2ともセキュリティに問題が発生しそうな運用形態を文章で説明してその問題点を回答させようとしたり、システムを変更する際に問題が発生しそうなリスクを考えさせようとしている。そのため、問題文を読んでいて、ある技術についての単語を見つけたときに、その技術に関してセキュリティ上発生しうる問題点を思いつくことが重要となる。
具体的には、例えばDNSという単語をみつけたりネットワーク構成図にDNSの存在を見つけたとき、DNSならではの攻撃手法を思い出し、それについての対策をしているかどうかというチェックをしながら問題文を読んでいく。そうすると問題文中に不自然な説明や発生しうるセキュリティ上の対策をしていない場合があることがわかる。そのようなときはその部分が設問の回答になっていたり間接的に関係している可能性が非常に高い。
従って、各技術について発生しうるリスクをどれだけ知っているかが合格するために非常に重要となる。その内容は具体的には以下のようなリスクを思い浮かべるようにすることが重要となる。なのでまずは、各技術における発生しうるリスクについて下記のリストを暗記してみてほしい。
#divclass(h5) {プロキシ }
#divclass(h6){SSL/TLS}
プロキシで通信内容などについてウィルススキャンやURLでフィルタリングをしてセキュリティを高めたい場合がある。しかしSSL通信では暗号化されているためプロキシでは通信内容をスキャンすることができない。プロキシでウィルススキャンやフィルタリングするというワードがあった場合、SSL通信時にはどのように対応しているかを確認する必要がある。
#divclass(h6){ウィルス定義ファイル}
プロキシは一種のキャッシュサーバの役割をすることがある。例えばウィルス定義ファイルをネットからダウンロードさせるとき、もしプロキシが古い定義ファイルをキャッシュしていた場合には問題となる可能性がある。
#divclass(h6){ログの記録}
インターネットと通信するために必ずプロキシを経由しなければならない場合、従業員のPCがマルウェアに感染してしまった場合、マルウェアからの通信ログがプロキシに残っている可能性がある。そのためプロキシでは通信ログを残すような設定にされているかどうか重要である。また何か異常な通信が発生している場合、プロキシの通信ログを分析することで何が原因かわかる可能性もあるので、ログという言葉がでてきた場合には注意が必要である。
#divclass(h6){フィルタリング}
プロキシにフィルタリング機能があるなどという説明が問題文中にある場合、例えば問題になりそうなURLがあった場合に通信をブロックしたり、特定のWebサイトを閲覧できないようにするといった回答を求められる場合があるのでそのあたりに注意して問題文を読む必要がある。
#divclass(h6){https通信対応機能}
http over TLS(https)では通信内容が暗号化されているため、通信内容でURLフィルタリングやウィルスチェックを行うことができない。そのためプロキシでいったん通信内容を復号化し、内容を確認したら再暗号化しデータを通過させる必要がある。
httpsではブラウザが生成した共通鍵をサーバ側が提供するサーバ証明書に添付されている公開鍵で暗号化しサーバに送り、サーバ側ではその共通鍵でデータを暗号化してデータのやりとりを行う。しかし、これではプロクシには共通鍵はわからない。そのためhttps通信に対応しているプロクシは、https通信時には自身が共通鍵をサーバの公開鍵で暗号化しサーバとプロクシの間でhttps通信を行う。プロクシでは受信したデータを復号化し通信内容を確かめるわけだ。
しかし、プロクシ～PCの間はデータが暗号化されないのでプロクシ～PCの間はプロクシがサーバ証明書をPCのブラウザに提供する形でサーバの代理のように動作し通信を行う。しかしこれでは、ブラウザに表示されるサーバ証明書はプロクシサーバのサーバ認証によるディジタル証明書になってしまう。本当に接続したいと思って接続したサーバであるかどうかはブラウザに表示される証明書では確認不可能になってしまう。
このあたりどのように対応しているのかを注意して問題を読んでいこう。
#divclass(h5) {公開鍵暗号 }
#divclass(h6){秘密鍵の流出}
公開鍵暗号の秘密鍵が流出によって発生する問題は、なりすましや改ざんが可能になるということ念頭においておこう。
#divclass(h6){秘密鍵を渡す相手の確認}
せっかくの公開鍵暗号でも秘密鍵やクライアント証明書を別の人に渡してしまっては意味がない。秘密鍵やクライアント証明書を申請によって発行し、他人に渡す場合にはその相手がちゃんと渡したい本人であるかどうか確認することが重要。確認するのは本人に来てもらうか、上司が渡すという方法がある。本人しか利用できないメールアドレスで渡すという方法もあるが、この場合はメールが盗聴されていたり、なりすましの可能性もあるので、そのあたりは文意で判断するようにしよう。
#divclass(h6){秘密鍵の取り扱い}
従業員が退職したり異動した場合、その秘密鍵や証明書を利用できないようにしておかないと、その従業員本人や利用していたPCから秘密鍵や証明書を取り出してなりすましや改ざんが可能になってしまう。そのため退職したり職務権限に変更が発生した場合、PCや端末の陳腐化による破棄するときには、秘密鍵や証明書を無効にしたり、PCから安全に秘密鍵や証明書を削除したりする必要がある。
#divclass(h5) {ウィルス対策ソフト }
#divclass(h6){定期更新}
いくらウィルス対策されていてもウィルス定義ファイルが定期的に更新されていなければ、0day攻撃を受けてしまう可能性が高くなる。どの程度の頻度で定義ファイルを最新のものにしているかは注意しなければならない。
#divclass(h6){スキャン間隔}
ウィルス定義ファイルが最新のものでも、スキャンをしなければウィルスは発見されない。そのためリアルタイムスキャンをしているか、フルスキャンをどの程度の頻度で行っているかを頭に置きながら問題文を読む必要がある。リアルタイムなスキャンをしていないとか、フルスキャンを週に一度しかしていない場合は、それが回答になる可能性がある。
#divclass(h6){SMTPスキャン}
メール送受信時にサーバ側でウィルススキャンをするのがSMTPスキャンだ。メールサーバで送信されるメールに対してウィルススキャンをしているかどうかは問題となる可能性があるので、そのあたりを考慮して問題文を読んでいこう。
#divclass(h6){POP3スキャン、IMAP4スキャン}
PCやモバイルなどでのメール受信時に行うのがPOP3スキャン、IMAP4スキャンだ。サーバ側だけでなくPC側でも対策しているかどうか問題文をよく読もう。
#divclass(h6){更新されない可能性の検討}
ウィルス定義ファイルは何らかの理由で更新されない可能性がある。例えばPCを長期間起動していない場合や、LANケーブルを接続していなかった場合、ネットワークがインターネットに接続されていない状態のときだけ使用するPCがある場合などである。もしウィルス定義が更新されていないPCが見つかったなどの記述があったらこの可能性を検討して問題文を読んでみよう。もし長期間起動しないPCがある可能性を臭わしている場合には、そのPCの定義ファイルが古いもののままである可能性があるので、そのあたりを念頭に問題文を読み進めよう。
#divclass(h6){コールドスタンバイ、冗長化}
サービスを停止させないようにする場合に、様々な設備を冗長化させておく場合がある。コールドスタンバイとは普段は停止していて必要なときだけ起動する装置なわけだが、そのときウィルス定義ファイルなどが適切に更新されていないと古いままになっていて脆弱性を抱えてしまう可能性がある。コールドスタンバイ時やふだんは稼働させていない冗長化されている装置があった場合、その定義ファイルなどが更新されているかを確認しておく必要がある。
#divclass(h5) {セキュリティパッチ }
#divclass(h6){脆弱性やセキュリティパッチの定期的な確認}
いくらセキュリティパッチが公開されていても、その存在を知らなければ意味がない。そのためポリシーにセキュリティパッチや脆弱性発見の情報を定期的に確認するようになっていたり、責任者が毎日確認するなどの対策がとられているかどうかを考えながら読み進めることが重要だ。
#divclass(h6){パッチの適用状況の確認}
パッチがあっても適用されていなければ意味がない。自動更新される設定になっているか、使用者が毎日確認して適用するようなポリシーになっているかどうかを念頭に読み進めていこう。またしっかり適用されているかどうか確認するような仕組みがあるかどうかも重要だ。そのためには管理サーバなどでセキュリティパッチの適用具合をしっかり記録しているかどうかなどの確認をしながら問題文を読んでいこう。
#divclass(h6){適用されない可能性}
こちらもウィルス定義ファイルと同様にしばらく起動していないPCなどではセキュリティパッチが適用されていない可能性がある。
#divclass(h6){セキュリティパッチにより発生する可能性}
セキュリティパッチのインストールによっては何かしらの不具合がシステムに発生する可能性がある。そのためセキュリティパッチを導入する場合には、データのバックアップを取得したり、テスト環境で導入してテストしてから本番環境に導入したり、他社の動向を確認するなどして導入しなければならない。
#divclass(h5) {DNS }
#divclass(h6){オープンリゾルバの禁止、DNSリフレクション/DNSamp対策}
DNSは再帰的な問い合わせを許可していると攻撃に使われる可能性がある。DNSがネットワーク内にあったら再帰的な問い合わせを許可しているかどうかを疑いながら問題文を読み進めよう。
#divclass(h6){DNSSEC}
問い合わせ元が正規のDNSサーバかどうかを確かめる方法は、いまのところDNSSECしかない。DNSといえばDNSSECというぐらい頻出ワードなので覚えておこう。
#divclass(h6){DNSキャッシュポイズニング対策}
DNSにキャッシュされている情報を書き換えさせる攻撃手法だ。対策としては送信元ポートをランダムに変更する、TTLを長くする、返答内容を隅々まで確認する、受信するDNSパケットの数を検知して対策を施すなど様々な方法があるが、これらがしっかりとなされているかを確認しよう。
#divclass(h5) {ネットワーク }
#divclass(h6){管理用PC専用セグメントの設置}
普段使用するPCとサーバ管理用PCが同じであると、例えばメール添付されたウィルスからPCが遠隔操作され、サーバへ接続されてしまう可能性がある。ところが管理用PCは別セグメントで運用しインターネットと接続させないようにすれば、このようなリスクは低くなる。どのような対策をしているのか考えながら読み進めよう。
#divclass(h6){LANケーブルの保護}
LANケーブルが露出していると、そこから信号を読み取ったり、最悪切断してリピータハブを取り付けるなどして盗聴できてしまう。そのため金属製のパイプで覆ったり、オフィスの床下に配線するなどの配慮をしているかどうか確認をしよう。
#divclass(h6){接続する機器のポリシ}
社内LANには勝手に個人の持ち込みPCやモバイルを接続させると、そこからウィルス等に感染する可能性が高くなってしまう。そのためLANに接続できる端末のポリシがしっかりと記述され、それが適切に運用されているか疑っていこう。
#divclass(h6){利用しているネットワーク機器情報の収集}
社内のネットワークに接続する機器は様々あるが、これらを適切に管理していないと脆弱性情報やセキュリティパッチなどの情報を収集できず適切なセキュリティレベルを保てなくなる可能性がある。そのため社内ネットワークで利用している機器をリストとしておくことが望ましい。
#divclass(h5) {DMZ }
#divclass(h6){DMZから社内LANへの通信は原則禁止}
DMZは外部に公開しているサーバで、内部と外部を切り離すために存在している。外部に公開しているサーバが乗っ取られた場合、内部のサーバにまで侵入されてしまう可能性がある。そのため基本的にはファイアウォールを利用してDMZから内部のLANへの通信は遮断し、必要なポートだけ通過させることが基本になる。そのためファイアウォールの設定で必要なポート以外、DMZから内部LANに信号が通過可能な設定になっているのは問題となる。そのためどのようなフィルタリングルールになっているかそのあたりを確認しながら読むことが重要である。
#divclass(h6){キッシュDNSとコンテンツDNSの切り離し}
ネットワーク構成図をみたとき、キャッシュDNSとコンテンツDNSが別々に設定されているかを確認するようにしよう。もしDMZにDNSサーバが設定されている場合、オープンリゾルバになっていると攻撃の踏み台にされてしまう可能性がある。DNSサーバに対する問題点として攻撃の踏み台にされる可能性を指摘するような設問として出題される可能性があるので、キャッシュDNSが分離されているかどうかは確認するようにしよう。
#divclass(h6){プロキシサーバの設置}
従業員などが利用するクライアントPCは、直接ネットに接続するよりプロキシサーバを利用したほうが情報の一元管理やログの取得が容易になりセキュリティが高まる。そのためプロキシサーバが設置されていない場合は、その点が設問として出題される可能性があるので念頭に置いておこう。
#divclass(h6){内部メールサーバの設置}
外部メールサーバを設置し、内部メールサーバに転送することでネット上に公開されているメールサーバに不必要なデータを置く必要がなくなるのでセキュリティが向上する。もし内部メールサーバを設置せず外部サーバを普通に利用している場合、そのサーバに対して攻撃が行われ情報などが盗み出される可能性があるので、そのあたりが設問として出題される可能性がある。
また内部メールサーバを設置した場合、外部サーバのIPアドレスからのみ内部メールサーバにデータを通過させるように設定してセキュリティを高めることも重要なので、ファイアウォールでそのような設定になっているか念頭に問題文を読んでいこう。
#divclass(h5) {ファイアウォール }
#divclass(h6){ログの記録}
ファイアウォールはすべての要となるのでログを残す設定になっていることが重要。残すログは拒否も許可も両方とも残す必要がある。もし拒否だけしか記録されない設定になっている場合、それらは設問として問われる可能性があるので確認しよう。
#divclass(h6){インターネットからの接続は最小限}
DMZにはwebサーバ、外部メールサーバ、プロクシサーバDNSサーバなどを設置するわけだが、このとき適切なサーバに対し、適切なポートだけを開放するよう制限する必要がある。このあたりが適切かどうかを確かめながら問題を読み進めよう。
#divclass(h5) {無線LAN }
#divclass(h6){盗聴}
無線LANときたら盗聴の可能性を真っ先に問題文中で確認しよう。特にWEPはセキュリティが低いので突破される可能性がある。
#divclass(h6){勝手にAP化}
従業員が勝手に行ってしまうこととしてよく出題される。有線LANに勝手に無線APを接続してネットを利用したり、スマホでテザリングして貸与PCをネットに接続してしまう。この場合ポリシーで禁止されているかどうか、技術的な制約がかけてあるかどうかを問題文中で確認しながらら読んでいこう。
#divclass(h6){ユーザ認証}
無線LANでよくある認証は事前共有キーを利用したWPA2-PSK/AESなどの認証方法だが、これだとすべての人に同じ事前共有キーを設定することになるため、例えば社外の人に一時的に無線接続を許可するとその人のPCに事前共有キーが残ってしまう可能性がある。そうなると問題なので可能であればすべての人に共通の事前共有キーではなく、一人一人に対して行うユーザ認証を行ったほうがいい。そのため事前共有キーというワードがでてきたら、その点が問題として問われる可能性があるので注意しよう。
#divclass(h5) {ICカード }
#divclass(h6){耐タンパ性}
ICカードときたら耐タンパ性。なんども出題されている頻出ワードだ。
#divclass(h6){一時的に失った場合の対応}
ICカードも忘れると利用できなくなってしまう。そのためどうしても一時的に仮利用させたいという仮ICカードを配布する必要がでてくる場合がある。
その手法としては仮カードに一時的に本人であると設定して利用させたり、権限が縮小された誰でも利用できる共用仮ICカードを使用させるなどという方法がある。
しかしどちらも場合も、仮カードを利用させようとする時点でしっかり申請した本人であることを確認し、しっかりと貸し出しリスト記録し、さらに使用が終わったらしっかりICカードを取り戻し利用不可能な状態にすると同時に、仮カードを使用しているあいだ忘れてきたカードの使用を一時的に不可能なように設定しておく必要がある。
そのため仮ICカードを利用させるという内容が問題文中にでてきたら、使用後のカードはどうなっているのか、忘れてきたカードは利用できるのかなどのチェックをしながら問題文を読む必要がある。
#divclass(h5) {バックアップメディア }
#divclass(h6){暗号化}
サーバをハッキングしなくてもデータさえ盗み出せばいいのでバックアップメディアは非常に重要な情報源となる。特に情報を持ち出す場合は他人にみられないように暗号化しておく必要がある。これはUSBメモリや外付けHDDなどでも自動に暗号化してくれるようなものであることが望ましい。
#divclass(h6){別の場所に保存}
バックアップメディアをサーバと同じ場所に保存している場合、災害があると同時に失ってしまう場合がある。なのでバックアップメディアはサーバ室とは別の場所に保管しておくことが望ましい。バックアップがどこに保存されているのか問題文を確認しよう。
#divclass(h6){取り扱う人の問題}
バックアップメディアをどこか別の場所に保管する場合、それを運ぶ人がどのような人なのかも問題になる。勝手に中身をコピーされ情報が流出する可能性があるからだ。
なので安易に宅配業者、協力会社の社員、アルバイトなどに運ばせることは問題になる。誰がメディアを運ぶのか問題文で確認しよう。
#divclass(h5) {サーバ室 }
#divclass(h6){入室への対策}
サーバ室に誰でも入れるような環境ではサーバ室のサーバのコンソールを利用される可能性がある。そのためサーバ室へは何らかの認証で必要な権限を持った人だけが入れる状態かどうかを問題文から確認しよう。
#divclass(h6){入室者チェック}
サーバ室に入ったことが記録できるような仕組みの有無も重要なチェックポイントだ。例えばICカードでは他人のカードを利用すれば中には入れてしまう可能性がある。そのため生体認証を利用したり、ICカードの場合は室内に監視カメラを設置するなどして誰が入室したのか確実に記録が残せることが望ましい。
#divclass(h5) {メール、メールサーバ }
#divclass(h6){送信ドメイン認証}
メールといえば送信ドメイン認証が頻出技術。メールアドレスのドメインに対して問い合わせを行い、そこからメールを送信するサーバのIPアドレスを取得し、実際にそのサーバから送られたメールであることを確認する方式だ。
そのためネットワーク構成が変わってメールサーバのIPアドレスが変更になると怪しいメールとして処理されてしまう可能性があるので、ネットワーク構成が変わる場合には注意する必要がある。
#divclass(h6){SMTP AUTH}
これもよく出題される内容の一つ。SMTP AUTHはメール送信時に認証が必要な方法で、最近はこれを採用している企業が多い。SMTP AUTHのもう一つのメリットはネットワーク内からのメール送信だけでなく、認証が必要なため外部に公開してメール送信にも利用できる点だ。
#divclass(h6){オープンリレー対策}
オープンリレーを許可していると誰でもメールを自由に送信できるためスパムメールなどの踏み台にされる可能性がある。そのためメールサーバでは受信する場合は自社のドメインに対してのもののみ受け付け、送信する場合は自社のネットワークからのものだけ送信する設定にされている必要がある。
#divclass(h6){添付ファイル}
マルウェアの送付方法として暗号化したZIPファイルで添付してメール送信するという方法がある。こうすると暗号化されているためファイルの中身をスキャンしてウィルスやマルウェアなどと判断することができない。そのたけ添付ファイルについての対策をどのようにしているか確認しておく必要がある。
#divclass(h6){エンベロープ、メールヘッダ}
メールの送信は基本的にエンベローブに記述されているメールアドレスに対して行われる。エンベローブに記述されているメールアドレスと、メールヘッダに記述されているメールアドレスは異なる場合があるので注意が必要だ。
#divclass(h5) {クラウド }
#divclass(h6){盗聴の可能性}
クラウドを利用すると自社でサーバを運用せずに済むのでリスクを委譲することができる。しかしその反面、セキュリティに関する管理を他社に任せることになるし、クラウドとの通信過程で盗聴される危険性も高まる。
そのため盗聴防止はどうなっているか、攻撃を排除するための仕組みはどうなっているか、信頼して任せられるクラウド提供会社なのか問題文から理解する必要がある。
#divclass(h6){ハッキングの可能性}
クラウドでは設定画面などからハッキングされても自社で管理していないので攻撃の痕跡がわからず探知できない場合がある。そうなると何度もパスワードの入力を試行されてしまう可能性が高まってしまう。
その防止のためにはログイン失敗時のログはどうなっているか、設定画面には特定のIPアドレスでしかアクセスできないようにするなど必要があるが、それがなされているかどうかを確認する必要がある。
#divclass(h6){提供会社の信用}
クラウドを提供する会社が信頼できる会社かどうかということが問題になる。そのためには認証を受けた会社であるかどうかが指標になると同時に、セキュリティポリシーを確認したり、実際のインシデント発生事例を確認したりする。
また、セキュリティポリシーを自社で設定して履行させたり、定期的にしっかり守っているかどうかを自社で確認するなど必要があるが、それがされていない場合には問題となる可能性があるので注意しよう。
#divclass(h6){バックアップの問題}
クラウドを利用すると物理サーバは外部にあるのでバックアップに様々な制約が生じる。例えばネット経由でダウンロードしようとすると盗聴の問題がでてくるし、クラウド提供会社にお願いするとバックアップの管理がどうなっているかわからないので問題だ。
そのため暗号化したり、自社の社員が定期的にバックアップしにいったり、しっかり認証を受けた信頼のある会社のクラウドを利用するなどの対策が必要となる。そのあたりが問題文に記述されていないと問題にされる可能性がある。
#divclass(h5) {社内PCの持ち出し、携帯端末の利用 }
#divclass(h6){無くさないなどの教育}
持ち出し可能なノートパソコンや携帯端末は紛失、盗難の可能性がでてくる。出先では無くさないよう肌身離さないようにする必要がある。
そのようなことがポリシーに書いていない場合は問題にされる可能性があるので、そのあたりを注意しながら問題文を読む必要がある。
#divclass(h6){許可制にする}
貸し出し時には申請を得て、まっさらなPCを貸し出すなどの対策をポリシーとして記述されていなければ問題にされる可能性がある。
#divclass(h6){ログオフ、スクリーンセーバー}
客先でのPCの利用などで離席時に勝手にPCを使われると重要な情報が流失してしまう可能性がある。そのためスクリーンセーバーを設定し回復時には再ログオンしなければならないように設定しておくとセキュリティが高まる。
ポリシーにこの記述がないと設問で問われる可能性があるので注意が必要だ。
#divclass(h6){紛失時の対策}
紛失時にどのような対策をすればいいのがポリシーが決まっていないと問題として問われる可能性がある。例えば貸し出し履歴を残し、返却ない場合には問い合わせたり、紛失時に連絡する電話番号を決めておいて連絡し対応するなどの取り決めが必要だ。
またリモートで端末の中身を自動的に消去するような機能があれば、それを利用しているかどうかも確認したほうがいい。
#divclass(h6){貸し出し履歴の記録}
持ち出し時には誰に何のために貸し出したのかをリスト化して記録として残したり、余計な情報が無いことを持ち出し前に確認したり、上司に確認させてから貸し出すようにするとセキュリティが高まる。
このあたりも問題文に記述されているかどうか確認しよう。
#divclass(h5) {PCに対する対策 }
#divclass(h6){クライアント認証}
特定のPCにしか社内LANに接続できないようクライアント認証を導入するという方法がある。勝手に接続されないような仕組みがあるかどうかは重要なので問題文で確認しよう。
#divclass(h6){USBメモリの利用不可}
最近はUSBメモリの紛失による情報の流出なども問題になっている。この対策としてポリシーとしてUSBメモリを使わないよう規定したりUSB接続のできないPCを使ったり、自動的に暗号化されるUSBメモリを使うなどが有効になる。
#divclass(h6){設定変更できないような権限}
管理者の権限を与えてしまうとそのPCであらゆる設定が可能になってしまう。そうするとウィルス対策ソフトを停止させたりして問題になる可能性がある。
そのため、最小限の権限だけ与えセキュリティに関する設定は変えられないようにしておく必要がある。
#divclass(h6){ワイヤーロック}
PCにクライアント認証などが導入されている場合、PCを盗まれると秘密鍵や証明書までも盗まれてしまい情報の流出につながる可能性がある。
そのため、物理的に盗まれないようワイヤーなどでPCを固定することも重要だ。問題文にPC盗難に関する記述があるかどうかを意識して読んでいこう。
#divclass(h5) {Cookie }
#divclass(h6){セッションハイジャック}
セッションはセッションIDをCookieでやりとりして利用するわけだが、このときセッションIDが想像されやすいものであると他の使用者のセッションを利用されてしまう可能性がある。対策としてはセッションIDを推測されにくいものにランダムに変更したりするなどあるが、このあたりの対策がしっかりされているかを確認しよう。
#divclass(h5) {Webアプリ }
#divclass(h6){クロスサイトスクリプティング、SQLインジェクション、クロスサイトリクエストフォージュリ}
これらのWebアプリなど特有の攻撃手法については、どのように対応をしているのか確認しておく必要がある。
#divclass(h6){脆弱性発見ソフト}
Webアプリの脆弱性を発見するために脆弱性発見ソフトなどを利用して適切に脆弱性をつぶすような対処をしているかどうかを確認しよう。しかし脆弱性発見ソフトであっても、
#divclass(h5) {アカウント }
#divclass(h6){組織変更時、退職時などの報告}
権限はできるだけ最小限であることが望ましい。従って移動時にアカウントの権限を見直したり、退職時にアカウントを削除するなどのポリシがあるかどうか問題文で確認しよう。
#divclass(h6){共有アカウントの禁止}
アカウントを共有すると誰がどのような操作をしたのか個人を突き止められなくなる。共有アカウントと記述されている場合にはそのあたりが問題にされる可能性があるので注意しよう。
#divclass(h6){定期的な確認}
退職時や役職変更時に権限を縮小したり削除したりする必要があるが、人事から報告があがってこないというミスも考えられる。そのため定期的に設定されているアカウントを確認し適切な権限が与えられているか確認する必要がある。
#divclass(h6){強度の強いパスワード}
当然だがパスワードには他人に推測されないようなパスワードを設定する必要がある。同じパスワードを利用しない、誕生日などを含めない、大文字小文字数字などすべてを利用しなければならない、文字数を多くするなどの対策をしているかどうかを確認して問題文を読んでいこう。
#divclass(h6){定期的な変更}
パスワードを推測困難なものにしたり、ブルートフォース攻撃を防ぐ方法の一つ。定期的なパスワードを変更することで予防することができる。
#divclass(h6){ログイン失敗時の対策、ブルートフォース攻撃}
ログイン失敗が何回もあった場合の対策に関する記述にも注意が必要だ。短時間に同じ利用者IDに対して失敗があった場合や、同じIPアドレスから何回も失敗があった場合、ログイン失敗の全体数が極端に増えた場合などには管理者に連絡すると同時に機能的に一時停止させるような仕組みが必要である。
それらの対策がなされているかどうか問題文に記述がないと設問として出題される可能性があるので注意が必要だ。
#divclass(h5) {ログ }
#divclass(h6){syslog}
ログといえばsyslog。syslogはログを送信するプログラムでsmtpに近い。アプリケーションやOSのログを他のサーバに転送する仕組みを持っている。転送にはTCP、UDP、SSL/TLSを利用することができる。
#divclass(h6){許可も拒否も保存する}
ファイアウォールや認証のログは拒否したときだけ残せばいいのではないかと思うが、許可されたログを残しておかないと、すでに攻撃が成功している場合の通信内容や、適切な通信や認証を利用した攻撃手法の場合はログに残らないので、とにかくすべてをログに残しておく必要がある。このあたりどのような設定にしているか確認をしておこう。
#divclass(h6){ログサーバへの転送とログサーバの権限}
サーバの特権アカウントをユーザに与えている場合、その特権IDを利用してそのサーバ内のログを改ざんされてしまう可能性がある。そのためにはsyslogを利用してログサーバに転送して保存するなどする対策がされているかどうか確認しよう。また、もちろんログサーバの特権IDは他のサーバと別のアカウントにしておく必要があるので、そのあたりも確認が必要だ。
#divclass(h6){異常があったときのエラー通知}
ログは大量になるので自動的に内容を確認し、ある閾値に達したときに自動的にエラー通知するような仕組みがあるかどうかも確認しておこう。
#divclass(h6){稼働時間}
企業によっては週末に保守のためサーバを停止させる場合がある。このとき何かしらの攻撃があった場合にはログサーバが停止していてログが収集できない可能性がある。このあたりどうなっているか問題を確認して読み進めよう。
#divclass(h5) {社内サーバ運用 }
#divclass(h6){不要なファイル、不要のディレクトリの削除}
メールで添付ファイルをやりとりするとマルウェアに感染するなどのリスクが高まるためファイルサーバを利用して外部のファイルのやりとりをする場合がある。このとき機密情報を扱うため、ずっとファイルサーバにファイルが残っているというのは都合が悪い。閲覧したら自動的に削除されたり、一定期間経過後に自動削除するなどという対処をしているか確認しておこう。
#divclass(h6){アカウントの管理}
ファイルサーバでは機密ファイルも扱う可能性があるので、必要な人が必要なファイルだけを閲覧できるような権限を付与しなければならない。協力企業や客先とのプロジェクトが終了したら適切にファイルサーバの権限も削除するなどの対応をしているかどうか確認する必要がある。
#divclass(h6){接続者の限定}
ファイルサーバの利用者が限定されている場合、接続者を公開鍵暗号を利用したクライアント認証を利用して限定したり、協力企業が特定されている場合にはその企業のIPアドレスからしか利用できないように設定するなど配慮をする必要がある。これは、ファイルサーバだけでなくWebアプリを利用させたり、サーバをSSHをリモート利用させたりする場合にも必要なので、社外の利用者が限定されている場合は注意しておこう。
#divclass(h5) {データベース }
#divclass(h6){ディスクの暗号化}
データベースには各種アカウントや機密情報が保存されている。そのため情報は暗号化されていることが望ましい。データベースの機能として、接続しているHDDやSDDの内容を書き込むときに自動的に暗号化し利用するときに復号化してくれる機能がある。この機能はアプリ側でなにもしなくてもいいので便利だし、保存メディアが盗まれたときには中身が見られないというメリットがある。
しかし復号化も自動に行われるためSQLインジェクション、OSコマンドインジェクションなどの脆弱性を利用されアプリケーションなどを自由に利用できるような状態になってしまったとき、アプリを経由して情報を表示させるようにすると、自動的に復号化されて情報が提供されてしまうので、さほどセキュリティ的には高い方法ではない。従ってデータベースに保存されている情報の暗号化手法がだのようなものであるのかを確認しておく必要がある。
**関連ページ
#ls3(情報処理試験まとめ)
**コメントを残す
- テストの投稿 -- 名前 (2011-08-15 18:20:55)
#comment
----
#right(){&lastmod()&aname(bottom)}
#right(){&trackback()}
#divclass(pageTitle){情報処理安全確保支援士試験の勉強法まとめは移転しました}
情報処理試験まとめは、まとめwikiより情報処理試験関連情報だけ独立して情報を一新し&blanklink(別サイト){http://shiken.wiki.fc2.com/}に移転しました。
今後ともまとめwikiをよろしくお願いいたします。
&blanklink(移転先の情報処理技術者試験まとめwikiのトップページはこちら){http://shiken.wiki.fc2.com/}
&topicpath()&aname(top)
#divclass(pageTitle){情報処理安全確保支援士 午後1&2対策}
**目次
#contents_line(level=3,sep= / )
**関連ページ
#ls3(情報処理試験まとめ)
**初めに
モバイル版のページが表示される方は見やすいPC版からどうぞ。画面下部の「PC版はこちら」をクリック。
情報処理安全確保支援士試験に合格するためのコツ、勉強テクニックなどを紹介しています。このページでは特に午後問題のテクニックについて解説しています。情報処理安全確保支援士試験の勉強法を知りたい人は[[こちらからご覧ください>>情報処理試験まとめ/情報処理安全確保支援士試験の勉強法まとめ]]。
**参考書など
***参考書の種類について
情報処理安全確保支援士試験の参考書は、主に3種類にわかれる。
主に学習をメインとした学習用参考書、過去問の解説に特化した過去問題集。さらに学習用参考書＋直近の数年の過去問題を掲載したハイブリッドタイプだ。
情報処理安全確保支援士試験では、同じ技術に関する出題が毎年繰り返し出題されるため、様々な技術やセキュリティに関する解説と過去問解説が非常に重要になると思う。
情報処理安全確保支援士試験の参考書の鉄板参考書は&blanklink(情報処理教科書){http://amzn.to/2BuayyP}だ。この参考書は過去10回分（5年分）の過去問とその解説をWebからダウンロードすることができる。そのため過去問題集を購入する必要がなく、これ1冊で学習用参考書と過去問題集をまかなうことができる。もし、それで足りないようならば別の過去問題集の購入を検討すればいいので、まずは必ずこの一冊を購入しよう。
***学習用参考書 2018年最新版
学習用参考書としてのお勧めは&blanklink(情報処理教科書){http://amzn.to/2BuayyP}だ。様々な知識を学習できると同時に解答テクニック、過去問題とその解説も手に入れることがでぎるため、コストパフォマンスの高い参考書である。
***学習用参考書一覧 2018年最新版
#html2()
{
<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=matowiki-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=as_ss_li_til&asins=4798154180&linkId=1e154d507c9ed25070eba212873df3aa"></iframe>
}
#html2()
{
}
**勉強テクニック
***知識エリアの絞り込み
旧試験の情報セキュリティスペシャリストの試験では、おおまかに以下の分野に分かれて出題される。
-システム設計
-ハードウェア
-ソフトウェア
-運用管理
-ネットワーク
-プログラミング
-データベース
-監査
これらが単独で出題されるわけではなく、関連する形で複数の分野が出題されるので基本的には全般的な知識が必要になる。しかし、この中でも特に頻出な分野がある。それが以下である。
-ネットワーク（ファイアウォール、プロトコル、DNS、SMTPなど）
-運用管理（ログ管理、アクセス制御、インシデント対応、アカウント管理、機密管理など）
-システム設計（暗号、認証、デジタル署名、マルウェア対策など）
-ソフトウェア（ウィルス対策ソフト、ブラウザなど）
特にこれらについては重点的に学習するようにしよう。
また知識エリアの中でも比較的、実務経験がないと難しいと思われるプログラミングやWebアプリケーションにおける対策、法律的な設問が多くなる監査などについてはスルーしてしまうという手もあるだろう。ただし年度によっては両方とも出題される可能性もあるので、そのあたりのリスクは受容しなければならない。
***特に学習しておきたいテクノロジ
その中でも特に頻出するテクノロジなどが存在する。そのためそれらは特に重点的に学習するようにしよう。ここでは頻出技術、特に学習すべきテクノロジについて記述しておく
#divclass(h5) {特に学習しておきたいテクノロジ一覧 }
-http over SSL/TLSの仕組み
-プロクシの仕組み
-SMTPサーバの仕組み
-公開鍵暗号の仕組み
-PKI（ディジタル証明書、サーバ証明書、クライアント証明書、電子署名、認証局）の仕組み
-DNSの仕組み
-ファイアーウォールによるフィルタリングルールの仕組み
-電子メールによる迷惑メール対策や暗号化の仕組み
***特に学習しておきたい情報セキュリティ対策
技術についての知識ももちろんだが、セキュリティに関する知識も必要だ。世の中には様々な脆弱性対策に関する本があるが、ここではIPAが提供する脆弱性対策についてのページを参考にしてみて欲しい。なぜなら情報処理技術者試験はIPAが主催しており、そのIPAが考える脆弱性対策がそのまま試験における正解になっているからである。従って時間があれば、一度IPAの脆弱性対策サイトを利用して学習したり、過去問演習中にわからない脆弱性などがでてきたら、このサイトを参考にして学習していこう。
http://www.ipa.go.jp/security/vuln/
***午後1&午後2の勉強方法
基本的には過去問を解くことで学習をしていく。問題と解答シートを必ずダウンロードし、問題に関しては印刷して解答するようにしよう。なお、このとき必ず設問を選択するところから開始すること。午後2であれば設問1と設問2をしっかりと見比べて、どちらかを選択し、そして完全に解答することまでを2時間以内で行うように学習しよう。どちらの設問を選択するかを決定する能力も磨くことが重要だ。
また旧試験の情報セキュリティスペシャリストの試験では問と問題文を頻繁に行き来して解答していくことになるが、これはPC上でPDFではとても問題文が読みにくい。時間もかかるし、正確な解答時間の計測に不向きなので可能であれば印刷するようにしよう。
また問によっては解答シートをみないと、どのような解答をしなければよくわからないような出題もある。例えば「理由を2つ。またその原因を20文字以内でそれぞれ説明せよ」といった出題だ。解答シートまで印刷する必要はないが、こちらはダウンロードしてPCの画面に表示し、どのような解答を求められているか確認して演習するようにしよう。
***午後1&午後2の復習方法
#divclass(h5) {解答できなかった理由のパターン }
試験で解答できないパターンは概ね以下の3通りにわかれる。
-知識がなかった
-怪しいと思うことができなかった
-問題文のヒントに気がつかなかった
「知識がなかった」というのは、記述された内容や技術に関する知識がなくまったく解答できなかったパターンだ。「怪しいと思うことができなかった」はその技術や運用方法におけるセキュリティ的な問題点に気がつくことができなかったパターンで、「ヒントに気がつかなかった」というのは問題文の中にヒントが記述されておりそのヒントによって解答がかなり狭まるのに、そのヒントに気がつかなかったためまったく見当違いの解答をしてしまうようなパターンである。
演習して間違ってしまった問題については、おおむね上記のパターンに収まると思うので、以下のような復習方法で知識を高めておいて欲しい。
-知識がなかった
--知らない技術やテクノロジ、運用方法、法律などに関しては学習用参考書などを利用にしてその分野の知識を得るようにしよう
-怪しいと思うことができなかった
--それぞれの技術についてセキュリティ的な問題点が潜んでいる可能性を思い浮かべることができるようにしておこう。具体的には本ページの下部の解答テクニックに詳しく記述してあるので参考にして欲しい。
-問題文のヒントに気がつかなかったり、ヒントを間違えた
--問題文にヒントがある場合は演習後にそのヒントのあった部分にアンダーラインを引いて、なぜそこに気がつくことができなかったのかを考え、その対策を検討し、次の演習に備えるようにしておこう。
#divclass(h5) {ヒントに気がつかなかったり、ヒントを間違えた場合 }
問題文の中のヒントに気がつかなかった場合は大きな得点源を失うことになる可能性が高い。そのためヒントを見逃さないことは非常に重要だ。従って確実にヒントを見つけておく必要がある。
ヒントは文中にさらっと軽く書いてあることが多いためどうしても見逃してしまう可能性があるわけだが、そのあたりは集中してとにかく見逃さないようにしよう。
見逃してしまった場合は以下の方法で復習をして欲しい。まずはヒントとなる文章中にアンダーラインを引いておく。ヒントを間違えた場合はその間違ったヒントの部分にもアンダーラインを引こう。そしてその章を読み返す。そしてなんでヒントに気がつかなかったのか、ヒントを間違えてしまったのか確認して分析しよう。そして次回に決してミスをしないようにしよう。
**解答テクニック
***問題文を最初から順番に理解しながら読む
当たり前のことだが、問題文中には様々なヒントが隠されているので、文章をよく理解しながら読んでいくことが重要だ。ちょっとしたことがヒントになっていることもあるので、隅々まで読み疑問に感じたらチェックをしておこう。
また設問は問題文の章ごとにまとめて順番に答えさせるような構成になっていることが多い。問題文を最初から最後まで一気に読もうとすると最初のほうの問題文を忘れてしまうし、あとから読み返すのに時間がかかってしまう。そのため回答する際には、まずは設問を確認し、どこまで読めばその設問の回答が可能なのかを確認しよう。そしてそこまで読んだら問題文を最後まで読まずに設問に回答をしてしまおう。設問は章単位で完結しており、次の章を読まなければ回答できないような出題のされ方はしないため、問題文を読みながら回答できる時点で設問に回答してしまったほうが問題文の内容をよく覚えているので、より正確に回答できるし、問題文を読んでいて疑問に思った内容も忘れずに済むので効果的だし得点もUPする。
***ネットワーク構成図を確認する
設問にはネットワーク構成図がよくでてくる。そのときに、ネットワークにリスクがないかどうか、すぐに判断できるようにならなければならない。具体的には、以下のような公正になっているか、しっかり確認しよう。
-公開されるサーバはDMZに配置されているか
-社内LANとDMZはファイアウォールで切り離されているか
-利用者PC、社内用サーバと管理用PCはL3SWで別セグメントになっているか
-DNSがコンテンツサーバとキャッシュサーバの二つに分かれているか
-メールサーバが内部と外部でそれぞれ設置されているか
-プロクシが設置されているか
-IPSは適切な場所に配置されているか
***送信元か、送信先か
解答として「ポート番号」「IPアドレス」などという答え方をする場合がある。この場合、送信元と送信先の区別がある場合には、必ず「送信元ポート番号」と宛先なのか送り主なのかわかるよう記述をしよう。ただの「ポート番号」だと減点、最悪は不正解になっている可能性がある。「ポート番号」「IPアドレス」という解答を記述するときには、このことを思い出せるようにしておこう。
***単語を聞いたら怪しいと思うことが重要
旧資格の情報セキュリティスペシャリストの問題文では、午後1、午後2ともセキュリティに問題が発生しそうな運用形態を文章で説明してその問題点を回答させようとしたり、システムを変更する際に問題が発生しそうなリスクを考えさせようとしている。そのため、問題文を読んでいて、ある技術についての単語を見つけたときに、その技術に関してセキュリティ上発生しうる問題点を思いつくことが重要となる。
具体的には、例えばDNSという単語をみつけたりネットワーク構成図にDNSの存在を見つけたとき、DNSならではの攻撃手法を思い出し、それについての対策をしているかどうかというチェックをしながら問題文を読んでいく。そうすると問題文中に不自然な説明や発生しうるセキュリティ上の対策をしていない場合があることがわかる。そのようなときはその部分が設問の回答になっていたり間接的に関係している可能性が非常に高い。
従って、各技術について発生しうるリスクをどれだけ知っているかが合格するために非常に重要となる。その内容は具体的には以下のようなリスクを思い浮かべるようにすることが重要となる。なのでまずは、各技術における発生しうるリスクについて下記のリストを暗記してみてほしい。
#divclass(h5) {プロキシ }
#divclass(h6){SSL/TLS}
プロキシで通信内容などについてウィルススキャンやURLでフィルタリングをしてセキュリティを高めたい場合がある。しかしSSL通信では暗号化されているためプロキシでは通信内容をスキャンすることができない。プロキシでウィルススキャンやフィルタリングするというワードがあった場合、SSL通信時にはどのように対応しているかを確認する必要がある。
#divclass(h6){ウィルス定義ファイル}
プロキシは一種のキャッシュサーバの役割をすることがある。例えばウィルス定義ファイルをネットからダウンロードさせるとき、もしプロキシが古い定義ファイルをキャッシュしていた場合には問題となる可能性がある。
#divclass(h6){ログの記録}
インターネットと通信するために必ずプロキシを経由しなければならない場合、従業員のPCがマルウェアに感染してしまった場合、マルウェアからの通信ログがプロキシに残っている可能性がある。そのためプロキシでは通信ログを残すような設定にされているかどうか重要である。また何か異常な通信が発生している場合、プロキシの通信ログを分析することで何が原因かわかる可能性もあるので、ログという言葉がでてきた場合には注意が必要である。
#divclass(h6){フィルタリング}
プロキシにフィルタリング機能があるなどという説明が問題文中にある場合、例えば問題になりそうなURLがあった場合に通信をブロックしたり、特定のWebサイトを閲覧できないようにするといった回答を求められる場合があるのでそのあたりに注意して問題文を読む必要がある。
#divclass(h6){https通信対応機能}
http over TLS(https)では通信内容が暗号化されているため、通信内容でURLフィルタリングやウィルスチェックを行うことができない。そのためプロキシでいったん通信内容を復号化し、内容を確認したら再暗号化しデータを通過させる必要がある。
httpsではブラウザが生成した共通鍵をサーバ側が提供するサーバ証明書に添付されている公開鍵で暗号化しサーバに送り、サーバ側ではその共通鍵でデータを暗号化してデータのやりとりを行う。しかし、これではプロクシには共通鍵はわからない。そのためhttps通信に対応しているプロクシは、https通信時には自身が共通鍵をサーバの公開鍵で暗号化しサーバとプロクシの間でhttps通信を行う。プロクシでは受信したデータを復号化し通信内容を確かめるわけだ。
しかし、プロクシ～PCの間はデータが暗号化されないのでプロクシ～PCの間はプロクシがサーバ証明書をPCのブラウザに提供する形でサーバの代理のように動作し通信を行う。しかしこれでは、ブラウザに表示されるサーバ証明書はプロクシサーバのサーバ認証によるディジタル証明書になってしまう。本当に接続したいと思って接続したサーバであるかどうかはブラウザに表示される証明書では確認不可能になってしまう。
このあたりどのように対応しているのかを注意して問題を読んでいこう。
#divclass(h5) {公開鍵暗号 }
#divclass(h6){秘密鍵の流出}
公開鍵暗号の秘密鍵が流出によって発生する問題は、なりすましや改ざんが可能になるということ念頭においておこう。
#divclass(h6){秘密鍵を渡す相手の確認}
せっかくの公開鍵暗号でも秘密鍵やクライアント証明書を別の人に渡してしまっては意味がない。秘密鍵やクライアント証明書を申請によって発行し、他人に渡す場合にはその相手がちゃんと渡したい本人であるかどうか確認することが重要。確認するのは本人に来てもらうか、上司が渡すという方法がある。本人しか利用できないメールアドレスで渡すという方法もあるが、この場合はメールが盗聴されていたり、なりすましの可能性もあるので、そのあたりは文意で判断するようにしよう。
#divclass(h6){秘密鍵の取り扱い}
従業員が退職したり異動した場合、その秘密鍵や証明書を利用できないようにしておかないと、その従業員本人や利用していたPCから秘密鍵や証明書を取り出してなりすましや改ざんが可能になってしまう。そのため退職したり職務権限に変更が発生した場合、PCや端末の陳腐化による破棄するときには、秘密鍵や証明書を無効にしたり、PCから安全に秘密鍵や証明書を削除したりする必要がある。
#divclass(h5) {ウィルス対策ソフト }
#divclass(h6){定期更新}
いくらウィルス対策されていてもウィルス定義ファイルが定期的に更新されていなければ、0day攻撃を受けてしまう可能性が高くなる。どの程度の頻度で定義ファイルを最新のものにしているかは注意しなければならない。
#divclass(h6){スキャン間隔}
ウィルス定義ファイルが最新のものでも、スキャンをしなければウィルスは発見されない。そのためリアルタイムスキャンをしているか、フルスキャンをどの程度の頻度で行っているかを頭に置きながら問題文を読む必要がある。リアルタイムなスキャンをしていないとか、フルスキャンを週に一度しかしていない場合は、それが回答になる可能性がある。
#divclass(h6){SMTPスキャン}
メール送受信時にサーバ側でウィルススキャンをするのがSMTPスキャンだ。メールサーバで送信されるメールに対してウィルススキャンをしているかどうかは問題となる可能性があるので、そのあたりを考慮して問題文を読んでいこう。
#divclass(h6){POP3スキャン、IMAP4スキャン}
PCやモバイルなどでのメール受信時に行うのがPOP3スキャン、IMAP4スキャンだ。サーバ側だけでなくPC側でも対策しているかどうか問題文をよく読もう。
#divclass(h6){更新されない可能性の検討}
ウィルス定義ファイルは何らかの理由で更新されない可能性がある。例えばPCを長期間起動していない場合や、LANケーブルを接続していなかった場合、ネットワークがインターネットに接続されていない状態のときだけ使用するPCがある場合などである。もしウィルス定義が更新されていないPCが見つかったなどの記述があったらこの可能性を検討して問題文を読んでみよう。もし長期間起動しないPCがある可能性を臭わしている場合には、そのPCの定義ファイルが古いもののままである可能性があるので、そのあたりを念頭に問題文を読み進めよう。
#divclass(h6){コールドスタンバイ、冗長化}
サービスを停止させないようにする場合に、様々な設備を冗長化させておく場合がある。コールドスタンバイとは普段は停止していて必要なときだけ起動する装置なわけだが、そのときウィルス定義ファイルなどが適切に更新されていないと古いままになっていて脆弱性を抱えてしまう可能性がある。コールドスタンバイ時やふだんは稼働させていない冗長化されている装置があった場合、その定義ファイルなどが更新されているかを確認しておく必要がある。
#divclass(h5) {セキュリティパッチ }
#divclass(h6){脆弱性やセキュリティパッチの定期的な確認}
いくらセキュリティパッチが公開されていても、その存在を知らなければ意味がない。そのためポリシーにセキュリティパッチや脆弱性発見の情報を定期的に確認するようになっていたり、責任者が毎日確認するなどの対策がとられているかどうかを考えながら読み進めることが重要だ。
#divclass(h6){パッチの適用状況の確認}
パッチがあっても適用されていなければ意味がない。自動更新される設定になっているか、使用者が毎日確認して適用するようなポリシーになっているかどうかを念頭に読み進めていこう。またしっかり適用されているかどうか確認するような仕組みがあるかどうかも重要だ。そのためには管理サーバなどでセキュリティパッチの適用具合をしっかり記録しているかどうかなどの確認をしながら問題文を読んでいこう。
#divclass(h6){適用されない可能性}
こちらもウィルス定義ファイルと同様にしばらく起動していないPCなどではセキュリティパッチが適用されていない可能性がある。
#divclass(h6){セキュリティパッチにより発生する可能性}
セキュリティパッチのインストールによっては何かしらの不具合がシステムに発生する可能性がある。そのためセキュリティパッチを導入する場合には、データのバックアップを取得したり、テスト環境で導入してテストしてから本番環境に導入したり、他社の動向を確認するなどして導入しなければならない。
#divclass(h5) {DNS }
#divclass(h6){オープンリゾルバの禁止、DNSリフレクション/DNSamp対策}
DNSは再帰的な問い合わせを許可していると攻撃に使われる可能性がある。DNSがネットワーク内にあったら再帰的な問い合わせを許可しているかどうかを疑いながら問題文を読み進めよう。
#divclass(h6){DNSSEC}
問い合わせ元が正規のDNSサーバかどうかを確かめる方法は、いまのところDNSSECしかない。DNSといえばDNSSECというぐらい頻出ワードなので覚えておこう。
#divclass(h6){DNSキャッシュポイズニング対策}
DNSにキャッシュされている情報を書き換えさせる攻撃手法だ。対策としては送信元ポートをランダムに変更する、TTLを長くする、返答内容を隅々まで確認する、受信するDNSパケットの数を検知して対策を施すなど様々な方法があるが、これらがしっかりとなされているかを確認しよう。
#divclass(h5) {ネットワーク }
#divclass(h6){管理用PC専用セグメントの設置}
普段使用するPCとサーバ管理用PCが同じであると、例えばメール添付されたウィルスからPCが遠隔操作され、サーバへ接続されてしまう可能性がある。ところが管理用PCは別セグメントで運用しインターネットと接続させないようにすれば、このようなリスクは低くなる。どのような対策をしているのか考えながら読み進めよう。
#divclass(h6){LANケーブルの保護}
LANケーブルが露出していると、そこから信号を読み取ったり、最悪切断してリピータハブを取り付けるなどして盗聴できてしまう。そのため金属製のパイプで覆ったり、オフィスの床下に配線するなどの配慮をしているかどうか確認をしよう。
#divclass(h6){接続する機器のポリシ}
社内LANには勝手に個人の持ち込みPCやモバイルを接続させると、そこからウィルス等に感染する可能性が高くなってしまう。そのためLANに接続できる端末のポリシがしっかりと記述され、それが適切に運用されているか疑っていこう。
#divclass(h6){利用しているネットワーク機器情報の収集}
社内のネットワークに接続する機器は様々あるが、これらを適切に管理していないと脆弱性情報やセキュリティパッチなどの情報を収集できず適切なセキュリティレベルを保てなくなる可能性がある。そのため社内ネットワークで利用している機器をリストとしておくことが望ましい。
#divclass(h5) {DMZ }
#divclass(h6){DMZから社内LANへの通信は原則禁止}
DMZは外部に公開しているサーバで、内部と外部を切り離すために存在している。外部に公開しているサーバが乗っ取られた場合、内部のサーバにまで侵入されてしまう可能性がある。そのため基本的にはファイアウォールを利用してDMZから内部のLANへの通信は遮断し、必要なポートだけ通過させることが基本になる。そのためファイアウォールの設定で必要なポート以外、DMZから内部LANに信号が通過可能な設定になっているのは問題となる。そのためどのようなフィルタリングルールになっているかそのあたりを確認しながら読むことが重要である。
#divclass(h6){キッシュDNSとコンテンツDNSの切り離し}
ネットワーク構成図をみたとき、キャッシュDNSとコンテンツDNSが別々に設定されているかを確認するようにしよう。もしDMZにDNSサーバが設定されている場合、オープンリゾルバになっていると攻撃の踏み台にされてしまう可能性がある。DNSサーバに対する問題点として攻撃の踏み台にされる可能性を指摘するような設問として出題される可能性があるので、キャッシュDNSが分離されているかどうかは確認するようにしよう。
#divclass(h6){プロキシサーバの設置}
従業員などが利用するクライアントPCは、直接ネットに接続するよりプロキシサーバを利用したほうが情報の一元管理やログの取得が容易になりセキュリティが高まる。そのためプロキシサーバが設置されていない場合は、その点が設問として出題される可能性があるので念頭に置いておこう。
#divclass(h6){内部メールサーバの設置}
外部メールサーバを設置し、内部メールサーバに転送することでネット上に公開されているメールサーバに不必要なデータを置く必要がなくなるのでセキュリティが向上する。もし内部メールサーバを設置せず外部サーバを普通に利用している場合、そのサーバに対して攻撃が行われ情報などが盗み出される可能性があるので、そのあたりが設問として出題される可能性がある。
また内部メールサーバを設置した場合、外部サーバのIPアドレスからのみ内部メールサーバにデータを通過させるように設定してセキュリティを高めることも重要なので、ファイアウォールでそのような設定になっているか念頭に問題文を読んでいこう。
#divclass(h5) {ファイアウォール }
#divclass(h6){ログの記録}
ファイアウォールはすべての要となるのでログを残す設定になっていることが重要。残すログは拒否も許可も両方とも残す必要がある。もし拒否だけしか記録されない設定になっている場合、それらは設問として問われる可能性があるので確認しよう。
#divclass(h6){インターネットからの接続は最小限}
DMZにはwebサーバ、外部メールサーバ、プロクシサーバDNSサーバなどを設置するわけだが、このとき適切なサーバに対し、適切なポートだけを開放するよう制限する必要がある。このあたりが適切かどうかを確かめながら問題を読み進めよう。
#divclass(h5) {無線LAN }
#divclass(h6){盗聴}
無線LANときたら盗聴の可能性を真っ先に問題文中で確認しよう。特にWEPはセキュリティが低いので突破される可能性がある。
#divclass(h6){勝手にAP化}
従業員が勝手に行ってしまうこととしてよく出題される。有線LANに勝手に無線APを接続してネットを利用したり、スマホでテザリングして貸与PCをネットに接続してしまう。この場合ポリシーで禁止されているかどうか、技術的な制約がかけてあるかどうかを問題文中で確認しながらら読んでいこう。
#divclass(h6){ユーザ認証}
無線LANでよくある認証は事前共有キーを利用したWPA2-PSK/AESなどの認証方法だが、これだとすべての人に同じ事前共有キーを設定することになるため、例えば社外の人に一時的に無線接続を許可するとその人のPCに事前共有キーが残ってしまう可能性がある。そうなると問題なので可能であればすべての人に共通の事前共有キーではなく、一人一人に対して行うユーザ認証を行ったほうがいい。そのため事前共有キーというワードがでてきたら、その点が問題として問われる可能性があるので注意しよう。
#divclass(h5) {ICカード }
#divclass(h6){耐タンパ性}
ICカードときたら耐タンパ性。なんども出題されている頻出ワードだ。
#divclass(h6){一時的に失った場合の対応}
ICカードも忘れると利用できなくなってしまう。そのためどうしても一時的に仮利用させたいという仮ICカードを配布する必要がでてくる場合がある。
その手法としては仮カードに一時的に本人であると設定して利用させたり、権限が縮小された誰でも利用できる共用仮ICカードを使用させるなどという方法がある。
しかしどちらも場合も、仮カードを利用させようとする時点でしっかり申請した本人であることを確認し、しっかりと貸し出しリスト記録し、さらに使用が終わったらしっかりICカードを取り戻し利用不可能な状態にすると同時に、仮カードを使用しているあいだ忘れてきたカードの使用を一時的に不可能なように設定しておく必要がある。
そのため仮ICカードを利用させるという内容が問題文中にでてきたら、使用後のカードはどうなっているのか、忘れてきたカードは利用できるのかなどのチェックをしながら問題文を読む必要がある。
#divclass(h5) {バックアップメディア }
#divclass(h6){暗号化}
サーバをハッキングしなくてもデータさえ盗み出せばいいのでバックアップメディアは非常に重要な情報源となる。特に情報を持ち出す場合は他人にみられないように暗号化しておく必要がある。これはUSBメモリや外付けHDDなどでも自動に暗号化してくれるようなものであることが望ましい。
#divclass(h6){別の場所に保存}
バックアップメディアをサーバと同じ場所に保存している場合、災害があると同時に失ってしまう場合がある。なのでバックアップメディアはサーバ室とは別の場所に保管しておくことが望ましい。バックアップがどこに保存されているのか問題文を確認しよう。
#divclass(h6){取り扱う人の問題}
バックアップメディアをどこか別の場所に保管する場合、それを運ぶ人がどのような人なのかも問題になる。勝手に中身をコピーされ情報が流出する可能性があるからだ。
なので安易に宅配業者、協力会社の社員、アルバイトなどに運ばせることは問題になる。誰がメディアを運ぶのか問題文で確認しよう。
#divclass(h5) {サーバ室 }
#divclass(h6){入室への対策}
サーバ室に誰でも入れるような環境ではサーバ室のサーバのコンソールを利用される可能性がある。そのためサーバ室へは何らかの認証で必要な権限を持った人だけが入れる状態かどうかを問題文から確認しよう。
#divclass(h6){入室者チェック}
サーバ室に入ったことが記録できるような仕組みの有無も重要なチェックポイントだ。例えばICカードでは他人のカードを利用すれば中には入れてしまう可能性がある。そのため生体認証を利用したり、ICカードの場合は室内に監視カメラを設置するなどして誰が入室したのか確実に記録が残せることが望ましい。
#divclass(h5) {メール、メールサーバ }
#divclass(h6){送信ドメイン認証}
メールといえば送信ドメイン認証が頻出技術。メールアドレスのドメインに対して問い合わせを行い、そこからメールを送信するサーバのIPアドレスを取得し、実際にそのサーバから送られたメールであることを確認する方式だ。
そのためネットワーク構成が変わってメールサーバのIPアドレスが変更になると怪しいメールとして処理されてしまう可能性があるので、ネットワーク構成が変わる場合には注意する必要がある。
#divclass(h6){SMTP AUTH}
これもよく出題される内容の一つ。SMTP AUTHはメール送信時に認証が必要な方法で、最近はこれを採用している企業が多い。SMTP AUTHのもう一つのメリットはネットワーク内からのメール送信だけでなく、認証が必要なため外部に公開してメール送信にも利用できる点だ。
#divclass(h6){オープンリレー対策}
オープンリレーを許可していると誰でもメールを自由に送信できるためスパムメールなどの踏み台にされる可能性がある。そのためメールサーバでは受信する場合は自社のドメインに対してのもののみ受け付け、送信する場合は自社のネットワークからのものだけ送信する設定にされている必要がある。
#divclass(h6){添付ファイル}
マルウェアの送付方法として暗号化したZIPファイルで添付してメール送信するという方法がある。こうすると暗号化されているためファイルの中身をスキャンしてウィルスやマルウェアなどと判断することができない。そのたけ添付ファイルについての対策をどのようにしているか確認しておく必要がある。
#divclass(h6){エンベロープ、メールヘッダ}
メールの送信は基本的にエンベローブに記述されているメールアドレスに対して行われる。エンベローブに記述されているメールアドレスと、メールヘッダに記述されているメールアドレスは異なる場合があるので注意が必要だ。
#divclass(h5) {クラウド }
#divclass(h6){盗聴の可能性}
クラウドを利用すると自社でサーバを運用せずに済むのでリスクを委譲することができる。しかしその反面、セキュリティに関する管理を他社に任せることになるし、クラウドとの通信過程で盗聴される危険性も高まる。
そのため盗聴防止はどうなっているか、攻撃を排除するための仕組みはどうなっているか、信頼して任せられるクラウド提供会社なのか問題文から理解する必要がある。
#divclass(h6){ハッキングの可能性}
クラウドでは設定画面などからハッキングされても自社で管理していないので攻撃の痕跡がわからず探知できない場合がある。そうなると何度もパスワードの入力を試行されてしまう可能性が高まってしまう。
その防止のためにはログイン失敗時のログはどうなっているか、設定画面には特定のIPアドレスでしかアクセスできないようにするなど必要があるが、それがなされているかどうかを確認する必要がある。
#divclass(h6){提供会社の信用}
クラウドを提供する会社が信頼できる会社かどうかということが問題になる。そのためには認証を受けた会社であるかどうかが指標になると同時に、セキュリティポリシーを確認したり、実際のインシデント発生事例を確認したりする。
また、セキュリティポリシーを自社で設定して履行させたり、定期的にしっかり守っているかどうかを自社で確認するなど必要があるが、それがされていない場合には問題となる可能性があるので注意しよう。
#divclass(h6){バックアップの問題}
クラウドを利用すると物理サーバは外部にあるのでバックアップに様々な制約が生じる。例えばネット経由でダウンロードしようとすると盗聴の問題がでてくるし、クラウド提供会社にお願いするとバックアップの管理がどうなっているかわからないので問題だ。
そのため暗号化したり、自社の社員が定期的にバックアップしにいったり、しっかり認証を受けた信頼のある会社のクラウドを利用するなどの対策が必要となる。そのあたりが問題文に記述されていないと問題にされる可能性がある。
#divclass(h5) {社内PCの持ち出し、携帯端末の利用 }
#divclass(h6){無くさないなどの教育}
持ち出し可能なノートパソコンや携帯端末は紛失、盗難の可能性がでてくる。出先では無くさないよう肌身離さないようにする必要がある。
そのようなことがポリシーに書いていない場合は問題にされる可能性があるので、そのあたりを注意しながら問題文を読む必要がある。
#divclass(h6){許可制にする}
貸し出し時には申請を得て、まっさらなPCを貸し出すなどの対策をポリシーとして記述されていなければ問題にされる可能性がある。
#divclass(h6){ログオフ、スクリーンセーバー}
客先でのPCの利用などで離席時に勝手にPCを使われると重要な情報が流失してしまう可能性がある。そのためスクリーンセーバーを設定し回復時には再ログオンしなければならないように設定しておくとセキュリティが高まる。
ポリシーにこの記述がないと設問で問われる可能性があるので注意が必要だ。
#divclass(h6){紛失時の対策}
紛失時にどのような対策をすればいいのがポリシーが決まっていないと問題として問われる可能性がある。例えば貸し出し履歴を残し、返却ない場合には問い合わせたり、紛失時に連絡する電話番号を決めておいて連絡し対応するなどの取り決めが必要だ。
またリモートで端末の中身を自動的に消去するような機能があれば、それを利用しているかどうかも確認したほうがいい。
#divclass(h6){貸し出し履歴の記録}
持ち出し時には誰に何のために貸し出したのかをリスト化して記録として残したり、余計な情報が無いことを持ち出し前に確認したり、上司に確認させてから貸し出すようにするとセキュリティが高まる。
このあたりも問題文に記述されているかどうか確認しよう。
#divclass(h5) {PCに対する対策 }
#divclass(h6){クライアント認証}
特定のPCにしか社内LANに接続できないようクライアント認証を導入するという方法がある。勝手に接続されないような仕組みがあるかどうかは重要なので問題文で確認しよう。
#divclass(h6){USBメモリの利用不可}
最近はUSBメモリの紛失による情報の流出なども問題になっている。この対策としてポリシーとしてUSBメモリを使わないよう規定したりUSB接続のできないPCを使ったり、自動的に暗号化されるUSBメモリを使うなどが有効になる。
#divclass(h6){設定変更できないような権限}
管理者の権限を与えてしまうとそのPCであらゆる設定が可能になってしまう。そうするとウィルス対策ソフトを停止させたりして問題になる可能性がある。
そのため、最小限の権限だけ与えセキュリティに関する設定は変えられないようにしておく必要がある。
#divclass(h6){ワイヤーロック}
PCにクライアント認証などが導入されている場合、PCを盗まれると秘密鍵や証明書までも盗まれてしまい情報の流出につながる可能性がある。
そのため、物理的に盗まれないようワイヤーなどでPCを固定することも重要だ。問題文にPC盗難に関する記述があるかどうかを意識して読んでいこう。
#divclass(h5) {Cookie }
#divclass(h6){セッションハイジャック}
セッションはセッションIDをCookieでやりとりして利用するわけだが、このときセッションIDが想像されやすいものであると他の使用者のセッションを利用されてしまう可能性がある。対策としてはセッションIDを推測されにくいものにランダムに変更したりするなどあるが、このあたりの対策がしっかりされているかを確認しよう。
#divclass(h5) {Webアプリ }
#divclass(h6){クロスサイトスクリプティング、SQLインジェクション、クロスサイトリクエストフォージュリ}
これらのWebアプリなど特有の攻撃手法については、どのように対応をしているのか確認しておく必要がある。
#divclass(h6){脆弱性発見ソフト}
Webアプリの脆弱性を発見するために脆弱性発見ソフトなどを利用して適切に脆弱性をつぶすような対処をしているかどうかを確認しよう。しかし脆弱性発見ソフトであっても、
#divclass(h5) {アカウント }
#divclass(h6){組織変更時、退職時などの報告}
権限はできるだけ最小限であることが望ましい。従って移動時にアカウントの権限を見直したり、退職時にアカウントを削除するなどのポリシがあるかどうか問題文で確認しよう。
#divclass(h6){共有アカウントの禁止}
アカウントを共有すると誰がどのような操作をしたのか個人を突き止められなくなる。共有アカウントと記述されている場合にはそのあたりが問題にされる可能性があるので注意しよう。
#divclass(h6){定期的な確認}
退職時や役職変更時に権限を縮小したり削除したりする必要があるが、人事から報告があがってこないというミスも考えられる。そのため定期的に設定されているアカウントを確認し適切な権限が与えられているか確認する必要がある。
#divclass(h6){強度の強いパスワード}
当然だがパスワードには他人に推測されないようなパスワードを設定する必要がある。同じパスワードを利用しない、誕生日などを含めない、大文字小文字数字などすべてを利用しなければならない、文字数を多くするなどの対策をしているかどうかを確認して問題文を読んでいこう。
#divclass(h6){定期的な変更}
パスワードを推測困難なものにしたり、ブルートフォース攻撃を防ぐ方法の一つ。定期的なパスワードを変更することで予防することができる。
#divclass(h6){ログイン失敗時の対策、ブルートフォース攻撃}
ログイン失敗が何回もあった場合の対策に関する記述にも注意が必要だ。短時間に同じ利用者IDに対して失敗があった場合や、同じIPアドレスから何回も失敗があった場合、ログイン失敗の全体数が極端に増えた場合などには管理者に連絡すると同時に機能的に一時停止させるような仕組みが必要である。
それらの対策がなされているかどうか問題文に記述がないと設問として出題される可能性があるので注意が必要だ。
#divclass(h5) {ログ }
#divclass(h6){syslog}
ログといえばsyslog。syslogはログを送信するプログラムでsmtpに近い。アプリケーションやOSのログを他のサーバに転送する仕組みを持っている。転送にはTCP、UDP、SSL/TLSを利用することができる。
#divclass(h6){許可も拒否も保存する}
ファイアウォールや認証のログは拒否したときだけ残せばいいのではないかと思うが、許可されたログを残しておかないと、すでに攻撃が成功している場合の通信内容や、適切な通信や認証を利用した攻撃手法の場合はログに残らないので、とにかくすべてをログに残しておく必要がある。このあたりどのような設定にしているか確認をしておこう。
#divclass(h6){ログサーバへの転送とログサーバの権限}
サーバの特権アカウントをユーザに与えている場合、その特権IDを利用してそのサーバ内のログを改ざんされてしまう可能性がある。そのためにはsyslogを利用してログサーバに転送して保存するなどする対策がされているかどうか確認しよう。また、もちろんログサーバの特権IDは他のサーバと別のアカウントにしておく必要があるので、そのあたりも確認が必要だ。
#divclass(h6){異常があったときのエラー通知}
ログは大量になるので自動的に内容を確認し、ある閾値に達したときに自動的にエラー通知するような仕組みがあるかどうかも確認しておこう。
#divclass(h6){稼働時間}
企業によっては週末に保守のためサーバを停止させる場合がある。このとき何かしらの攻撃があった場合にはログサーバが停止していてログが収集できない可能性がある。このあたりどうなっているか問題を確認して読み進めよう。
#divclass(h5) {社内サーバ運用 }
#divclass(h6){不要なファイル、不要のディレクトリの削除}
メールで添付ファイルをやりとりするとマルウェアに感染するなどのリスクが高まるためファイルサーバを利用して外部のファイルのやりとりをする場合がある。このとき機密情報を扱うため、ずっとファイルサーバにファイルが残っているというのは都合が悪い。閲覧したら自動的に削除されたり、一定期間経過後に自動削除するなどという対処をしているか確認しておこう。
#divclass(h6){アカウントの管理}
ファイルサーバでは機密ファイルも扱う可能性があるので、必要な人が必要なファイルだけを閲覧できるような権限を付与しなければならない。協力企業や客先とのプロジェクトが終了したら適切にファイルサーバの権限も削除するなどの対応をしているかどうか確認する必要がある。
#divclass(h6){接続者の限定}
ファイルサーバの利用者が限定されている場合、接続者を公開鍵暗号を利用したクライアント認証を利用して限定したり、協力企業が特定されている場合にはその企業のIPアドレスからしか利用できないように設定するなど配慮をする必要がある。これは、ファイルサーバだけでなくWebアプリを利用させたり、サーバをSSHをリモート利用させたりする場合にも必要なので、社外の利用者が限定されている場合は注意しておこう。
#divclass(h5) {データベース }
#divclass(h6){ディスクの暗号化}
データベースには各種アカウントや機密情報が保存されている。そのため情報は暗号化されていることが望ましい。データベースの機能として、接続しているHDDやSDDの内容を書き込むときに自動的に暗号化し利用するときに復号化してくれる機能がある。この機能はアプリ側でなにもしなくてもいいので便利だし、保存メディアが盗まれたときには中身が見られないというメリットがある。
しかし復号化も自動に行われるためSQLインジェクション、OSコマンドインジェクションなどの脆弱性を利用されアプリケーションなどを自由に利用できるような状態になってしまったとき、アプリを経由して情報を表示させるようにすると、自動的に復号化されて情報が提供されてしまうので、さほどセキュリティ的には高い方法ではない。従ってデータベースに保存されている情報の暗号化手法がだのようなものであるのかを確認しておく必要がある。
**関連ページ
#ls3(情報処理試験まとめ)
**コメントを残す
- テストの投稿 -- 名前 (2011-08-15 18:20:55)
#comment
----
#right(){&lastmod()&aname(bottom)}
#right(){&trackback()}
表示オプション
横に並べて表示：
変化行の前後のみ表示：
