みなさん、こんにちは！ クラウドへの移行が進むなか、「これまでのネットワークの考え方で本当に安全なのかな？」と、ふと不安になることはありませんか？
これまで私たちは、会社のオフィスやデータセンターのまわりに高い塀（ファイアウォール）を建てて、「この門をくぐった人はみんな信頼できる安全な仲間です！」という前提でシステムを守ってきました。いわゆる「境界型防御」という考え方ですね。
でも、ちょっと想像してみてください。
もし、泥棒がこっそりその高い塀を乗り越えて、オフィスの中に侵入してしまったらどうなるでしょうか？ 塀の中（ネットワークの内側）は仕切りがほとんどないので、泥棒はどの部屋にも自由に出入りし放題、金庫もパソコンもやりたい放題になってしまいますよね。
クラウド時代やリモートワークが当たり前になった今、この「外側だけ固くて、中はガラ空き」というスタイルは、セキュリティ的にかなり危なっかしいものになっています。
そこで今回は、新人のIT担当者や開発者のみなさんに向けて、クラウド時代に必須の防犯テクニックである「マイクロセグメンテーション（細かな部屋割り）」と、攻撃者が中で暴れ回るのを防ぐ「ラテラルムーブメント（横方向への移動）の阻止」について、身近な防犯にたとえながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょう！
—
1. 家の鍵にたとえる「境界型防御」の限界とラテラルムーブメント
まずは、攻撃者がどのようにシステムを狙ってくるのか、そのメカニズムを覗いてみましょう。
さきほど、「会社のまわりに高い塀を建てていた」とお話ししました。これは、家の玄関に頑丈な鍵をかけるようなものです。泥棒（サイバー攻撃者）は、あの手この手を使って、この玄関の鍵（Webサイトの脆弱性や、誰かのフィッシングメールなど）をこじ開けようと侵入を試みます。
ここまではよくあるセキュリティの構図ですが、本当に怖いのは「侵入された後」です。
ラテラルムーブメント（横移動）という脅威
攻撃者は、運良く（あるいは執念で）玄関の鍵を開けて家の中に侵入すると、次はどう動くでしょうか？
リビング（Webサーバー）に侵入したあと、廊下を通って寝室（顧客データベースサーバー）へ、さらに書斎（機密ファイルを置いたストレージ）へと、まるで我が物顔で移動し、次々と大切なものを盗み出していきます。
この、「ネットワークの内側に侵入したあと、別の安全なはずの領域へ横方向に移動していく攻撃」のことを、セキュリティ用語でラテラルムーブメントと呼びます。
従来の境界型防御だけだと、一度玄関を破られてしまうと、家の中はノーチェックの「スイスチーズ状態」になってしまい、攻撃者にやりたい放題を許してしまうのです。
—
2. すべての部屋に鍵をかける「マイクロセグメンテーション」とは？
このラテラルムーブメントを防ぐための切り札が、今回テーマにする「マイクロセグメンテーション（超・細分化された区画整理）」です。
イメージとしては、大きなシェアハウスを思い浮かべてもらえばわかりやすいかもしれません。
シェアハウスの玄関だけでなく、リビングのドア、個々の部屋のドア、キッチンのドア、すべての部屋にICカードキーがついていて、「Aさんはリビングと自分の部屋に入れるけれど、他の人の部屋には絶対に入れない」という細かいルール（権限）がガチガチに設定されている状態です。
クラウドの世界（AWS、Azure、GCPなど）では、この「部屋」を1つひとつの「ワークロード（サーバーやコンテナなど）」にたとえ、ワークロード同士の通信を細かくコントロールします。
- 「Webサーバーからデータベースサーバーへは、特定の通信（データベースへの問い合わせ）だけを許可する」
- 「それ以外の通信は、すべて問答無用でブロックする」
このように、クラウド上のネットワーク（VPCやサブネット）の中で、サーバー同士の関係性を「ゼロ・トラスト（誰も信用しない）」の精神で細かく区切るのが、マイクロセグメンテーションの正体になります。
—
3. 実践！ クラウドでのネットワーク境界再設計（設定サンプル）
「理屈はわかったけれど、具体的にどう設定すればいいの？」と思いますよね。
ここでは、クラウドのインフラ設定でよく使われる、セキュリティグループ（仮想的なファイアウォール）のイメージをコードや設定の形で見てみましょう。
たとえば、AWSなどのクラウド環境で、Webサーバーとデータベースサーバーの通信を制御する設定（イメージ）は、次のように記述します。
# セキュリティグループの設定例：データベース（DB）サーバーを守るための盾
Resources:
DatabaseSecurityGroup:
Type: "AWS::EC2::SecurityGroup"
Properties:
GroupName: "db-microsegmentation-sg"
GroupDescription: "Webサーバーからのアクセスのみを許可し、他からの侵入を防ぐ"
# 【重要】外向きの通信設定（基本は必要最低限に絞る）
SecurityGroupEgress:
- IpProtocol: "-1"
CidrIp: "0.0.0.0/0"
Description: "すべての外部への出力を一旦許可（必要に応じて制限します）"
# 【重要】内向きの通信設定（マイクロセグメンテーションのキモ！）
SecurityGroupIngress:
# 許可ルール：Webサーバー用のセキュリティグループからの通信だけを通す
- IpProtocol: "tcp"
FromPort: 3306 # MySQLのポート番号
ToPort: 3306
SourceSecurityGroupId: "sg-webserver01" # Webサーバー以外のアクセスはすべてシャットアウト！
Description: "WebサーバーからのDBクエリのみ許可"この設定のポイント
SourceSecurityGroupIdにsg-webserver01という、Webサーバー専用の「身分証（セキュリティグループ）」を持つサーバーからしかアクセスできないように指定しています。- もし万が一、関係のない別のサーバーが攻撃者に乗っ取られたとしても、そのサーバーにはこのDBサーバーへの「鍵」がないため、通信自体がバッサリと遮断されます。これがラテラルムーブメントを食い止める仕組みです。
—
4. 開発現場・インフラ構築で心がけたい「泥臭い」ポイント
教科書通りの綺麗な設計図を描くだけでは、現場のセキュリティは守れません。最後に、私たちが実務で直面しがちな「泥臭い落とし穴」と、その対策についてお伝えします。
① 「とりあえず全て許可（0.0.0.0/0）」の誘惑に負けない
開発を急いでいると、エラーが出るたびに面倒くさくなって、通信の許可設定を 0.0.0.0/0（世界中どこからでもOK！）にしてしまいがちです。これは、家の玄関の鍵を開けっ放しにして「誰も入ってこないはず」と祈るようなものです。面倒でも、通信元やポート番号は必要最小限に絞るクセをつけましょう。
② アプリケーション側のヘッダー設定やバリデーションも忘れない
ネットワークの境界だけでなく、アプリケーションが受け取るリクエストの中身（HTTPヘッダーなど）に対しても、厳重なチェックを行いましょう。
たとえば、Webアプリケーションでセキュリティを高めるための基本的なHTTPヘッダーの例を見てみます。
# ApacheやNginxなどのWebサーバー設定例：クリックジャッキングやXSSを防ぐための基本ヘッダー
# （防犯で言えば、窓の内側に格子をつけるようなイメージです）
# 他のサイトのiframe内に自社サイトを表示させない（クリックジャッキング対策）
Header always set X-Frame-Options "DENY"
# ブラウザのMIMEタイプ推測による脆弱性を防ぐ
Header always set X-Content-Type-Options "nosniff"
# クロスサイトスクリプティング（XSS）などの攻撃を防ぐためのContent Security Policy (CSP)
# 許可されたドメイン以外のスクリプト実行を禁止する
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com;"このように、インフラ側のマイクロセグメンテーション（部屋の鍵）と、アプリケーション側のヘッダー設定（窓の格子）を組み合わせることで、多層防御の堅牢なシステムが完成します。
—
まとめ
今回は、クラウド移行におけるネットワーク境界の再設計と、マイクロセグメンテーションについて解説しました。
- 境界型防御の限界を知り、中に入られた後の対策（ラテラルムーブメントの阻止）がなぜ必要なのかを意識する。
- マイクロセグメンテーションを取り入れ、サーバーやワークロード同士の部屋割りを細かくして「お互いを信用しない」環境を作る。
- 日々の開発やインフラ構築において、面倒くさがらずに最小権限の原則を守る。
セキュリティは、一朝一夕で完璧なものができるわけではありません。まずは身近なシステムや開発環境で、「このサーバーとこのサーバーの間の通信、本当にこんなに緩くて大丈夫かな？」と見直すところから、一歩ずつ進めていきましょう！
コメント