いつの間にか５月。
ということは、既に情報セキュリティスペシャリスト試験（春試験）は実施済みですねー（笑）
この「情報セキュリティスペシャリスト合格への軌跡（奇蹟？）」の投稿は、果たして何かの役に立っているのでしょうか？？
それはさておき。
ここでのセキュリティ技術は、ネットワークに関するセキュリティを指します。物理的な危機管理（入退室管理）やリスク分散、信頼性向上などは含まれません（信頼性の話はこの次の（２）で扱います）。
ところで、ネットワーク技術そのものがまさに日進月歩な現代において、どこまで最新技術や手法、名称を覚えればいいのかは判断に迷うところです。
が、試験は年に２回、問題を作成する側の情報収集力（問題作成力）、事例収集期間などを考慮すれば、少なくとも最新技術を押さえる必要はないでしょう。
本屋さんでパラパラっとネットワーク関係の書籍（雑誌である必要はない）をめくって目につくような用語や技術を理解できればＯＫではないかと。
日進月歩と言ったって、コンピュータそのものがノイマン型からパラダイムシフトしていないのですから、ネットワーク上の技術だってパラダイムシフトするようなことは当分無いでしょうし。
ということは、基本を押さえておけば、最新の技術云々だって基本的にはその延長にあるものなわけですから、闇雲になんでも暗記して済ませてしまおう、というのは結構無駄な努力なんじゃないかと思います。
でもって、ネットワークのセキュリティ対策云々の前に最低限押さえておかなければならないのは、リピータ、ブリッジ、ルータ、ゲートウェイ（アプリケーションゲートウェイ）の区別。
どの層のプロトコルに対応しているのかと、何ができるのか、もっとはっきり言ってしまえばフィルタリングできるのかどうか、できるとしたら何でできるのかといった基本的なことは知っておいたほうがいいです。
セキュリティがらみでブリッジのフィルタリング（要するにスイッチングハブ）とかが問われることはないでしょうから、さしあたって問題となりそうなのはファイアウォール（FW）ですね。
FW（場合によってはF/W）のその基本構造はフィルタリング。IPアドレスでフィルタリングするか、それともポート番号でフィルタリングするかに大別できますが、前者は動的IPへの対応が困難になること、IP詐称に対応できないことといった問題点があります。
後者はサービスごとにポート番号が割り当てられますから（わかりやすいのはwell-known portですね）、サービスごとにフィルタリングを行うことができます。
WEBサーバしか公開しないのにFTPサーバのポートが開いている、といった事態を防ぐことでセキュリティを確保する、という考え方ですね。
ところでFWの内側から外側のWEBサーバへのアクセスを考えてみましょう。
内（クライアント）→FW→外（WEBサーバ）
これは問題なく通せますね。しかし。
内（クライアント）←FW←外（WEBサーバ）
は、どうしましょう。
これは上記のフィルタリングでは通信を行えなくなってしまう可能性が残ります。
というのも、内側のクライアント（ブラウザ）のIPアドレスは動的に変更される上に、使用するポート番号も動的に割り当てられるからです。
こういったケースに備えて、ステートフルパケットは通過させる（ACKフラグが立っているパケットは通過させる）などの対応を取っておく必要があります。
いずれにしても、フィルタリングのルールをきちんと定めておくことが必要です。
well-known portを使うサービスならば、敢えてポート番号を変更して運用する、などの柔軟性も必要になるでしょう。
なお、こうしたパケットフィルタリング自体はルータで行うこともできます。FWとルータの線引きは難しいところですが、両者の違いを問うような問題は出ないでしょう（だって明確に線引きできない）。むしろ、文章問題でルータとFWとが相互の意味で利用されたりする、というケースを想定してそれぞれ置き換え可能、位に覚えておいた方がいいかも。
入ってくるパケットを選別するだけではなく、もっと大がかりなフィルタリング（たとえばアプリケーション層プロトコルの内容を解釈してフィルタリングを行うなど）の場合は、アプリケーションゲートウェイというか、ぶっちゃけプロキシが必要になります。
一番身近な例では、メールサーバのアダルト関連のスパムフィルタリングがありますね。「アダルト」とか「セックス」「ポルノ」などのいかがわしい文言がタイトルや本文に含まれているモノは通過させない、などのあれです。
こうした内容に踏み込んだセキュリティコントロールを「ステートフルインスペクション」と言いますが、何をフィルタリングするかは計画的に考えなければなりません。
私事の事例ですが、私はかつて法学政治学研究科（大学院）に進学しまして、当然にネットで論文や情報を収集していましたが、学内ネットワークからインターネットで情報を検索する際に、不適切キーワードは検索できないようになっていました（つまりプロキシを通してインターネットに接続されていた）。
しかし私の所属していた研究科では、たとえば刑法の研究をしている院生がネットで「児童ポルノ」の事件や情報、論文を検索しようとしたところ、不適切キーワードとして検索できない、とか、ジェンダー論を研究している院生が「セックス」に関して検索しようとしても不適切キーワードとして検索できなかった、といったことが多々ありました。
これは研究がらみの特殊な事例かも知れませんが、どんな用語をNGワードとして指定するのか、また指定するNGワードの量が増えれば処理情報もそれだけ増えるのでどれだけのキャパシティをプロキシに持たせるのかといったことは、事前に考えておかなければなりません。
業務に必要な情報がNGワードに指定されていたのでは、仕事に差し障りが出てしまうわけです。
ところでそのプロキシですが、元々の意味は「代理人」です。
つまりクライアント（LAN内のノード）からの外部（インターネット）への（主に）httpsアクセスを横取りして、ノードの「代わり」にインターネット上のhttpsサーバに接続し通信を行うのがその役割です。
もちろんプロキシにはそれ以外にキャッシュデータの保存によるレスポンスの向上、トラフィックの軽減といった役割もあります。
この一般的な意味でのプロキシはノード（クライアント）の代わりにサーバに接続するプロキシサーバを指しますが、場合によっては何らかのサーバの代理として働くプロキシというのもあります。
サーバの代わりにプロキシが応答する「リバースプロキシ」がそれです。
リバースプロキシは複数のサーバのプロキシとなることで、あるノード（ユーザ）の認証を全てのサーバに適用できる「シングルサインオン」を提供できるようになります。つまりサーバサイドのプロキシがユーザの一度のサインオンで全てのサーバへのサインオンを代理してくれるわけですね。
通常ノード（ユーザ）は一度リバースプロキシにサインオンすると、二回目以降はサインオンしなくても自動的にサインオンされます（Webサービスでもよく「サインオンしたままにする？」のチェックボックスオプションとかがありますよね）が、それを可能にするのがクッキー（Cookie、httpscookie）。
ブラウザでクッキーを食べない設定にしていると、クッキーを利用したログイン状態の継続は行えず、またログインそれ自体ができないということもしばしば。
従って利便性を取ればクッキーは原則受け入れるようにした方がいいのですが、クッキーのデータはクライアント側に保存されて対象サーバが適宜参照・変更するため、これ自体が不正アクセスの温床となることも。
特にいかがわしい（アダルト）サイトなどでクッキーを利用している所などには、注意が必要です！
ちなみに、https（WEB）に特化したリバースプロキシがWAF（Web Application Firewall）。増大の一途をたどるWebサーバ攻撃に対応する形で誕生しました。
その誕生の理由からも分かるように、WAFは通信内容を検査して正当なhttps/https通信かどうかをチェックします。しかしそれは逆に言えばhttps/httpsしか検査の対象にしていないということでもあります（Webアプリケーションなのだから当然と言えば当然ですが）。
これを、通信内容をプロトコル全般的に渡って検査するようにしたのがIDS/IPS（Intrusion Detection System/Intrusion Protection System）。逆に考えれば、IDS/IPSをWebに特化させたのがWAF、ということですね。
なお、IDSは侵入「検知」システム、IPSは侵入「防御」システムで、IDSはネットワーク全体を監視するネットワーク型IDS、ホストにインストールして特定のホストだけを監視するホストIDSに分類できます。
ホスト型IDSはそれがインストールされたホストだけを監視するのでわかりやすいのですが、ネットワーク型IDSの場合、ネットワーク上のどこにIDSを設置するかでキャプチャできるパケットが異なるため、設置場所を慎重に選定しなければなりません。
基本的に同じセグメント上を流れるパケットしかキャプチャできないからです。要するにルータの向こう側などのパケットは監視できない、というわけです。
IDSが以上を検出する方法には、Misesu検知法（攻撃のパターンファイルのようなモノと照らし合わせて、これに合致するパターンがあれば管理者に通知）やAnomaly検知法（システムの正常な稼働状態をパターンとして登録しておき、そこから外れた状態になったら異常を検出したことにする）などがあります。
IDSがもう少し高度？になると、IPSになります。
IPSはネットワークとネットワークを結ぶ境界に設置します。
というのも、IDSと違い、不正なアクセスがあったときに単に管理者に通知するだけではなく、ネットワーク自体を切断してアクセスを遮断することで防御するからです。
単にセグメント上に設置しただけではネットワークの切断を行えない、ということですね。
管理者の怠慢やアラート慣れに対しても有効で（IPS自らが遮断まで行うから）、セキュリティの面からも高い効果が期待できる一方で、誤検出による切断などの影響が大きくなってしまうという面も。
どちらにも一長一短があるので、それぞれの特徴は押さえておく必要があります。
それと同時に、サービスを提供するサーバを何処に公開するか（内部か外部かDMZか）、FWをハードウェアとして導入するかクライアント用のソフトウェア（パーソナルFW）として導入するか、なども併せて検討する必要があります。
ところで、FW等で外部からの通信を制限すると、たとえば業務で外部ネットワークから社内にアクセスしなければならないとか、物理的に異なる場所にいる管理者がサーバの管理でアクセスを行わなければならないといった時でも必要なアクセスが制限されてしまいます（特に前者の場合はIPアドレスやポート番号で制御することが難しい）。
それを解決する一つの方法が、リモートアクセス。
ものすごーく簡単にいってしまえば、FWを通れないんだから、別の所から社内ネットワークに入ってしまおう、という、適切なバックドアみたいなものを想像すればいいのかも。
RAS（Remote Access Server）にアクセスして認証を経てアクセスする、という段取りになりますが、PPPを使ってPAP認証（Password Authentification Protocol、平文でIDとPasswordを送信）するか、CHAP認証（Challenge Handshake Authentification Protocol、暗号化した認証データ送信）するかして認証をクリアします（現在は後者を利用するのが一般的です）。
リモートアクセスのイメージはモバイル端末から特定のネットワークへのアクセスですが、もしリモート先もリモート元も固定された場所ならば、VPN（Virtual Pribate Network）を視野に入れましょう。
インターネット上に仮想的にVPNを確保するインターネットVPNと、キャリアの回線を利用して仮想専用線を構築するIP-VPNがあります。もちろん後者の方が帯域保証やバックアップサービスなどの点で好ましいのですが、当然にその分だけお値段がはります。
また、インターネットVPNはVPNに必要な装置（ハードもソフトも）を自分で設置するため、モバイル端末からでも構築が可能ですが、IP-VPNはあくまで拠点間通信となります。
VPNはトランスポートモード（端末がデータの暗号化を行い、IPヘッダは暗号化されない）とトンネルモード（ゲートウェイで暗号化を行い、IPパケット自体を暗号化＝カプセル化し、相手方ゲートウェイ宛のIPヘッダを別途取り付けて拠点間通信を行う）があります。
前者はモバイル端末からのアクセスをしやすくし、後者は拠点間通信に適しているという特徴があります。
いずれにしてもVPNなので、暗号化と認証がその基本となります（平文でのやりとりはありえない）。
VPNを実現するプロトコルにはいくつかありますが、代表的なのはPPTP（Point to Point Tunneling Protocol、データリンク層での暗号化・認証プロトコル）とSSL-VPN（プレゼンテーション層での暗号化・認証プロトコル。SSLはブラウザでおなじみ）、そしてこれから普及するかも知れないIPSecがあります。IPSecは見てそのまま、IP層＝ネットワーク層での暗号化・認証プロトコルです。
IPSecはIPv6での標準プロトコルとして採用されていますが、IPv6そのものはまだ普及しているとは言えないのが現状です。
IPSecでは
０：通信相手の認証（共通鍵か公開鍵かディジタル署名を使って認証）
１：暗号化方式の決定と鍵の交換を行う（Security Associationを作成する）IKEフェーズ
２：IPSec通信を行うIPSecフェーズ
の二段階方式です（手順０はIPSec固有の手順ではない）。
IKEフェーズで暗号化方式を決定する、ということは、それぞれの端末がサポートしている暗号化方式ならばどのような暗号化方式でもかまわない、ということが特徴です。
IPSecでの通信に先立って行われる手順１では、IPアドレスで認証を行うメインモード（IPアドレスが可変のモバイル端末では使えない）、モバイルで使えるようにしたアグレッシブモードなどがあります。
なお、IPSecはIPに含まれないパラメータを取り扱いますがこれはIPヘッダには入り切りません。そこでIPSec用のフィールドが別に用意されますが、うち認証だけを行う場合はAH（Authentification header）を、暗号化も併せて行う場合にはESP（Encapsulating Security Payload）が用いられます。
現在ネットワークにおいて暗号化は避けて通れません。特に公開鍵暗号方式はディジタル署名に用いられ、認証のためにも用いられます。
暗号化方式は情報セキュリティスペシャリスト試験においてはもう一般常識と言っても過言ではありませんから、もし鍵を使った暗号化方式（そしてその復号化方式）や、公開鍵を使ったディジタル署名の仕組みに不安があるならば、まずはそこから徹底的に学習することをオススメします。
また、FWの学習には家庭用のルータのパケットフィルタリング設定画面がとても参考になります。インバウンド、アウトバウンドなども含めて実際に試すことができるので（もしインターネットにつながらなくなってしまった！としても、大抵は工場出荷時の設定に戻すことができるようになっていますし）、実際にいじってみて確認するのもいいでしょう（ご家族とかで回線を共有している場合は辞めた方がいいかもしれませんが）。
