応用情報午後問題の把握（必須：セキュリティ）

応用情報午後への対策

応用情報技術者試験は午前と午後に分かれている重めの試験となる。
午後は比較的長めの擬似的な事例を設定した問題となっており、全体としては11問で構成されるが、そのうちの5問を選択して答えるものとなっている。そして第1問である 情報セキュリティ は必須とされている。

他の項目としては……

• 経営戦略
• プログラミング
• システムアーキテクチャ
• ネットワーク
• データベース
• 組み込みシステム開発
• 情報システム開発
• プロジェクトマネジメント
• サービスマネジメント
• システム監査

が出題される。
この中では今のところ プログラミング, ネットワーク, データベース, 情報システム開発 を狙おうかと考えている。もしかしたら システムアーキテクチャ にするかもしれない。

今日はUdemyの動画教材で情報セキュリティについての概要を一通り眺めることとした。
以下は学習の思い出し定着として自分で書いてみたものなので正確性はない。

• XSS
  • クロスサイトスクリプティング。なんらかの入力が可能なWebサイトにおいて、その入力にスクリプトを埋め込み、別のサイトへ影響を及ぼそうとする（クロスサイト）攻撃方法。Webサイトが入力欄で受け付けたデータに対して何らの対策もしていない場合はこれが可能となってしまう。単純な例では <script> タグをそのまま入力できてしまうといったものがある。Webサイト側の処理で記号をそのまま受け付けるのではなく、表示用文字列に変換するなどといった対策をする必要がある。
• SQLインジェクション
  • クロスサイトスクリプティングのSQL版のような攻撃。ログイン認証でパスワード欄などにSQLを誤動作させるような文字列を入力し、意図されていない情報を引き出そうとするといった手法がある。Webサイト側のSQLの実装が未熟な場合、入力された内容によって全くことなるSQL動作を引き起こせてしまう。SQLを使用する部分の設計を見直したり、パスワード部分に入れられる文字の種別を制限するなどといった対策が必要となる。
• クロスサイトリクエストフォージェリ
  • フォージェリとは「偽装」を意味している。Webサイトへ送信するリクエストをURLなどからリクエストや使用される変数を推測して、設計の意図から外れた内容を送信し、別のサイトへアクセスさせるといった攻撃。GETリクエストを使用するとアドレスバーに入力情報が表示されるといったことを把握していない場合、セキュリティの弱みとして悪用されやすい。かといってPOSTにすれば単純に回避できるというものでもない。
• ブルートフォースアタック
  • ひとつのIDに対してとにかく考えられる限りの組み合わせのパスワードをひたすら試行して強引に突破しようとする攻撃。試行回数に制限のないZipファイルパスワードなどは、パスワード文字数が少ない場合に一瞬で破られてしまう。試行回数に制限を設け、超えた場合にはIDへのアクセス自体を止めるといった対応で回避できるが、アクセスを止めることそのものを目的とした攻撃へ逆に利用されてしまうという問題もある。
• レインボー攻撃
  • IDとパスワードの情報をサーバ内に保存する際には、平文での保存ではなくハッシュ化といった暗号化を行うことが多い。ハッシュ化されていれば漏洩時にも（簡単には）利用できず、セキュリティの維持を期待できる。ただし、ハッシュ値から元データを生成できないとはいえ、簡単なパスワードから生成したハッシュ値のリストを予め膨大に用意しておけば、その組み合わせからマッチさせる可能性は得られるので、そこを突いた攻撃となる。予め用意したパスワードとハッシュ値の対応リストをレインボーリストと呼ぶ。サーバ側で「ソルト」と呼ばれる独自の値を付記する対応を取ることで、利用者にパスワードの変更コストを追わせることなくレインボーリストの無効化を狙える。
• オープンリダイレクト
  • サーバ側がスクリプトによって表示ページを切り替えるような構造をしている場合、単純に受け取ったリクエストで分岐させるような設計だと、どのような行き先にも切り替えられるようになってしまう。リダイレクト先がオープンになっているという意味でこの名前となっている。悪意あるサイトへ誘導する際に、オープンリダイレクトな状態となってしまっているURLを悪用して、そのサーバを経由し誘導させるといったことが可能となってしまう。
• クリックジャッキング
  • スタイルシートの透明度などを悪用して、利用者には見えない形で悪意あるリンクなどをクリックさせる手法。
• SPFメール認証
  • DNSを利用して、メール送信側のレコードにSPF情報を付記する。SPF情報には「送信可能サーバとするIP」を入力する。受信側はDNSを利用してそのIPアドレスを問い合わせ、送信側の「可能サーバ」と一致しているかを確認することで、なりすましの疑いがあるかどうかをチェックできる。
• 共通鍵認証方式
  • 通信したい者同士が作成した鍵を互いに持つことで、送受信するデータを暗号化して傍受に対応しようとするもの。ただし、共通鍵は傍受されない安全な方法で事前に渡し合う必要があり、通信したい相手が増えるほどそのペアも増やす必要があるので、管理コストが膨大になっていくという問題がある。
• 公開鍵認証方式
  • データを受信したい側が秘密鍵を作成し、それを基に公開鍵を作成する。公開鍵は誰が所持しても問題なく、通信を利用して送信側へ渡せるようになる。送信側は入手した公開鍵を利用して暗号化し、受信側へ暗号データを送信する。公開鍵でデータを復号することはできず、受信側が持つ秘密鍵でしか復号できないので、これをもって受信側は本来のデータを入手する。秘密鍵と公開鍵を用意するという手間はかかるが、送信側がどれほど増えても同じ公開鍵を渡していくだけで対応できるので管理コストは大きくならないし、公開鍵自体も通信で渡せるという手軽さが実現できる。
• サーバ証明書
  • 認証局により発行された証明書によりTLS通信（HTTPSなど）を可能とするもの。原則としては政府が推奨する認証局に費用を支払って証明書の発行を受けることとなるが、オープンソースによるものも存在する。認証局が発行するのは公開鍵となる。
• クライアント証明書
  • あるサーバにアクセスするための制限を設ける形で「クライアント証明書」をサーバが作成する。サーバ内で作成した秘密鍵と公開鍵を基にクライアント証明書を生成し、これをアクセスしたい端末へインストールすることで、インストールした端末のみがサーバへ外部からアクセスできるようになる。
• デジタル署名
  • 暗号化してやりとりしたデータの改ざんを検知できるようにするもの。秘密鍵と公開鍵を基にして送信データに対応するデジタル署名を作成する。受信したデータとデジタル署名を対応させると、データに改ざんがあった場合に認証不可と表示され、改ざんを検知できる。

このあたりの要素を概略として頭に入れた。実際には以前から知っているものも多いが、明日は問題集などを通してより細かく固めていきたい。