アクセスポリシーの策定－その２

ここでは引き続き、ネットワーク構築時におけるアクセスポリシーの決定方法について説明します。
以下、2人の会話をご覧ください。

せんぱ～い（_ _；）

ど、どうした～？

寝不足なんです～(-_-)Zzz
でも昨日のコレ、分かりましたよ～（_ _；）

Policy図2

そ、そうか。

良く考えたら、他の2社から身を守ろうとしているわけだから、その人たちと仲良く1台のファイアウォールを管理することなんて元々あり得ないっていう話ですよね。。。？（_ _；）

おぉ、正解だ！(￣ー￣)
これは前提の問題だから、例えば担当者同士がノミニケーションで仲良くなればいい、とかいう問題じゃないんだ。

ヤッタ！ヾ(´ー｀ )ノ
そうなると、もうコレしかないですよね。(．．)

Policy図4

おぉ、さらに正解だ！(￣ー￣)(￣ー￣)
これなら他社の都合も聞きつつ、自分でファイアウォールを管理できるね。

でも、これだとファイアウォールを3台も購入しなきゃいけないですよね？
もったいなくないですか？

そりゃ安いほうがイイに決まっているが、せっかく買ったのに目的が達成されないほうが、もっともったいないだろう？
それに、この構成にするともう1つイイことがあるぞ。

えっ、なんですか？
知りた～い！o(*^ー^*)o

この前、NATについて説明したよね？

えっと、アドレス変換機能でしたっけ？

そう。NATを使うと、内部のアドレスと外部のアドレスを対応付けできるよね。

はい、そういう機能でした。
異なるネットワーク空間を接続するときに便利なんですよね？

そうだね。
つまり自分の管理しているファイアウォールでNATを使えば、各社は内部のアドレス体系を他社に教えなくて済むんだ。

そっか！（・０・☆）
他社が接続してくるときは、外側に浮かんでいるNATのアドレス宛てに通信してもらえばいいんですね？

そうそうそう(￣ー￣)(￣ー￣)(￣ー￣)
それに、NATのところでも説明したけど、仮に各社でアドレス空間が重複していたとしても全く気にしなくて済むんだ。

な、なるほど～！
これなら、3台買うことに十分な価値がありますね！

デショ？
同じ組織内だったらそこまでする必要ないけど、会社同士の接続だったことが今回のポイントだね。

そうですね。
技術的な問題というよりも、前提条件の問題でしたからね。

アクセスポリシーの決め方と構成への落とし込み方は理解してもらえたかな？

はい、理解しました～！
でも、こういうのってお客さんごとにいろんなパターンがありそうですね。

そうだね。たぶんモデル的なものは決まっているけど、要件を聞いた上でカスタマイズが必要になるだろうね。
さっきの例も、アドレス重複がないという前提なら、もう1つ構成方法があるんだよ。

えっ、まだ方法があるんですか？

うん、こんな感じ。(．．)

Policy図3

え～っと、、、アレッ？( ゜゜)
これって、昨日わたしが書いたやつじゃないんですか。。。？ (;´Д`)

そう、構成は同じ。
でも「みんなで仲良く管理」じゃなくて、「中立的な第三者が管理し、守秘義務を守る」というところが違う。

（？＿？）

さっき、大げさに言うと「敵同士が仲良く出来るわけない」という理由でこの構成がダメになったよね？

は、はい。

だから、公平な判断を下す「審判」を置くんだ。
いや、「裁判官」と言ったほうが正しいかな？

（？＿！）

審判は「グラウンドの石ころ」、裁判官は「法律の忠実なる下僕」だから、信頼できるだろう？

（！＿！）

各社は第三者の管理者に要望を伝えて、客観的な判断に委ねることにするんだよ。
各社がその内容に納得できれば、それでポリシーが完成。

でも、客観的な視点で各社からの一方的な要望を取りまとめて、それを元に作ったポリシーを各社に納得させることが出来て、なおかつポロッと不用意な発言をしない人、なんているんでしょうか？

そうそうそうそう(￣ー￣)(￣ー￣)(￣ー￣)(￣ー￣)
たぶんそんな「鋼の心臓」と「百戦錬磨の知恵」を併せ持つ人はほとんどいないから、これはきっと「夢の構成」だね？

はは、、、最後に見事なオチが付きましたね。
ちゃんちゃん♪┐(´ー｀)┌

以上でアクセスポリシーの話は終わりです。
引き続き、「ネットワークを利用した攻撃－その１」をご覧ください。。。