メタCセキュリティ物語 ～アクセス制御技術編～

この記事は、セキュリティ資格学習のために、AI（Claude）と共同で作成したコンテンツです。
※間違った解釈がある可能性があります。

この記事の目的

セキュリティの専門用語は、カタカナや略語が多く、初学者にとって非常に取っつきにくいものです。
そこで、専門家じゃなくてもわかるようにストーリー風に構成してみました。

📍 結城の新たな作戦

マンションを追い出され、SNMP攻撃も失敗した結城は、自室で次の攻撃を計画していた。

「もう、情報収集だけじゃダメだ…今度は直接メタCのサーバーに侵入する」

結城の画面には、メタCのネットワーク構成図が表示されている。

「メタCは、外部からの攻撃を防ぐために、いくつものセキュリティ機器を設置してるはず…でも、完璧な防御なんてない。必ず穴がある」

結城は、攻撃計画を書き出した。

【攻撃計画】
1. ポートスキャンでファイアウォールの穴を探す
2. Webアプリケーションの脆弱性を突く（SQLインジェクション）
3. IDSを回避しながら侵入
4. サーバーの管理者権限を奪取
5. ユーザー情報を盗む

「今度こそ…山本とお砂糖の個人情報を全部手に入れる。そして、二人の関係をめちゃくちゃにしてやる…」

結城の目が、不気味に光った。

💑 カフェでのひととき

その頃、慎也と里見は、メタC内のカフェワールドでお茶をしていた。

「ねぇ、里見。最近、メタCのセキュリティが強化されたって聞いたけど、何が変わったの？」

慎也が興味深そうに聞く。

「うん、実はね、結城の一連の攻撃を受けて、佐藤さんたちがネットワークセキュリティ機器を大幅に強化したの」

「ネットワークセキュリティ機器？」

「そう。ファイアウォール、IDS/IPS、WAF、UTM…いろんな『門番』を配置して、多層防御してるのよ」

「門番…？」

「うん。お城を想像してみて。お城を守るために、いろんな防御があるでしょ？」

里見が説明を始めた。

📖 里見の解説：ネットワークセキュリティの多層防御

多層防御（Defense in Depth：ディフェンス・イン・デプス）

「セキュリティの基本は、1つの防御に頼らないこと。複数の防御を重ねることで、1つ突破されても次の防御が守るの」

お城の例：

【お城の多層防御】
外堀 → 城壁 → 内堀 → 城門 → 天守閣

ネットワークの多層防御：

【ネットワークの多層防御】
ファイアウォール → IDS/IPS → WAF → サーバー本体

「それぞれの『門番』が、違う役割を持ってるの。今から詳しく説明するね」

🔥 第1の門番：ファイアウォール

ファイアウォール（Firewall：防火壁）

「ファイアウォールは、ネットワークの最前線の門番よ」

役割：

• 外部ネットワークと内部ネットワークの境界に設置
• 許可されていない通信をブロック
• 「通してもいい通信」と「ダメな通信」を判断

身近な例え：

「マンションの入口にいる警備員さんみたいなもの。『住民と訪問者はOK、不審者はNG』って判断して通す人」

「なるほど！でも、どうやって判断するの？」

「それがね、ファイアウォールにもいくつかの種類があって、判断方法が違うの」

パケットフィルタリング型

「最も基本的なファイアウォール。パケット（データの小包）の宛先を見て判断するの」

チェック項目：

• 送信元IPアドレス：どこから来た？
• 宛先IPアドレス：どこ行き？
• ポート番号：何番ポート？
• プロトコル：TCP？UDP？

身近な例え：

「郵便配達員さんが、封筒の宛先だけ見て『この住所はOK、この住所はNG』って判断するようなもの。中身は見ない」

ルールの例：

ルール1：社内ネットワーク（192.168.1.0/24）からのアクセスは全て許可
ルール2：外部からTCPポート80（HTTP）へのアクセスは許可
ルール3：外部からTCPポート22（SSH）へのアクセスは拒否
ルール4：それ以外は全て拒否

メリット：

• 処理が速い
• シンプルで分かりやすい

デメリット：

• パケットの中身は見ない（悪意ある内容でも通過）
• 通信の流れ（セッション）を理解しない

ダイナミックパケットフィルタリング

「パケットフィルタリングの改良版。動的にルールを追加・削除するの」

仕組み：

1. 内部から外部への通信を許可
2. その返信用のルールを一時的に自動作成
3. 通信が終わったらルールを削除

身近な例え：

「レストランで『2人です』って言ったら、店員さんが2人分の席をその場で用意してくれて、食事が終わったら片付けるようなもの」

例：

1. 社内PCが外部サーバー（8.8.8.8）にアクセス
   → ファイアウォールが「8.8.8.8からの返信を許可」ルールを自動追加

2. 外部サーバーから返信が来る
   → ルールがあるので通過

3. 通信終了
   → ルールを自動削除

メリット：

• セキュリティが向上（必要なときだけ穴を開ける）
• 管理者がいちいちルールを書かなくていい

ステートフルパケットインスペクション（SPI）

「さらに賢い方式。通信の状態（State：ステート）を記憶して判断するの」

チェック内容：

• この通信は、正当な手順で開始された？
• 過去のパケットとの関連性は？
• 通信の流れ（セッション）は正しい？

身近な例え：

「ホテルのフロントで、『501号室のお客様ですか？』って聞いて、チェックイン記録と照合してから鍵を渡すようなもの。単に『501号室』って言っただけじゃダメ」

具体例：TCPスリーウェイハンドシェイク：

【正常な通信】
1. クライアント → サーバー：SYN（接続したいです）
2. サーバー → クライアント：SYN-ACK（OKです）
3. クライアント → サーバー：ACK（ありがとう）
→ SPIは「正しい手順だ」と判断して通す

【異常な通信】
1. 攻撃者 → サーバー：ACK（いきなり3番目から！）
→ SPIは「手順がおかしい」と判断してブロック

メリット：

• 不正な通信を高精度で検知
• なりすまし攻撃を防げる
• 現在の主流方式

デメリット：

• 処理が複雑（CPUパワーが必要）
• パケットの中身（アプリケーション層）は見ない

アプリケーションゲートウェイ型

「最も高度なファイアウォール。パケットの中身まで見るの」

仕組み：

• ファイアウォールがプロキシ（代理人）として動作
• クライアントとサーバーの間に入って、両方の通信を代行
• 中身を解析してから転送

身近な例え：

「通訳さんみたいなもの。日本人と外国人が直接話すんじゃなくて、通訳さんが間に入って『この内容は問題ないな』って確認してから伝えるの」

動作の流れ：

1. クライアント → ゲートウェイ：「Webサイトを見たい」
2. ゲートウェイが内容をチェック：
   - HTTPリクエストは正しい形式？
   - 怪しいコマンドは含まれていない？
   - URLは許可リストにある？
3. 問題なければ、ゲートウェイ → サーバー：リクエストを転送
4. サーバー → ゲートウェイ：レスポンスを返す
5. ゲートウェイが内容をチェック：
   - ウイルスは含まれていない？
   - 機密情報は漏れていない？
6. 問題なければ、ゲートウェイ → クライアント：レスポンスを転送

チェック内容（例：HTTP）：

• HTTPメソッドは許可されたもの？（GET、POSTなど）
• URLに怪しい文字列はない？（../など）
• Content-Typeは適切？
• ファイルの拡張子は許可されたもの？

メリット：

• アプリケーション層の攻撃も防げる
• 詳細なログが取れる
• コンテンツフィルタリングが可能

デメリット：

• 処理が重い（遅くなる）
• プロトコルごとに専用のゲートウェイが必要
• 設定が複雑

🛡️ 第2の門番：WAF（Web Application Firewall）

WAF（ワフ）

「WAFは、Webアプリケーション専用のファイアウォールよ」

役割：

• Webアプリケーションへの攻撃を防ぐ
• SQLインジェクション、XSS（クロスサイトスクリプティング）などを検知
• 通常のファイアウォールでは防げない攻撃に対応

通常のファイアウォールとの違い：

【通常のファイアウォール】
「このポートは許可、このIPは拒否」← ネットワーク層の判断

【WAF】
「このHTTPリクエストは怪しい、このSQLコマンドは危険」← アプリケーション層の判断

身近な例え：

「空港のセキュリティチェックみたいなもの」

• 通常のファイアウォール：「チケットを持ってる人だけ通す」（入口の係員）
• WAF：「手荷物の中身をX線で検査」（セキュリティゲート）

検知できる攻撃例：

1. SQLインジェクション

【正常なリクエスト】
https://example.com/login?user=yamamoto&pass=1234

【攻撃】
https://example.com/login?user=admin' OR '1'='1&pass=dummy
→ WAFが「'（シングルクォート）」や「OR」などの怪しい文字列を検知してブロック

2. XSS（クロスサイトスクリプティング）

【攻撃】
<script>alert('攻撃！')</script>
→ WAFが「<script>」タグを検知してブロック

3. パストラバーサル

【攻撃】
https://example.com/file?name=../../etc/passwd
→ WAFが「../」を検知してブロック

WAFの配置場所：

インターネット → ファイアウォール → WAF → Webサーバー

メリット：

• アプリケーションのバグを突く攻撃を防げる
• アプリ側を修正しなくても防御できる
• 攻撃のログが詳細に残る

デメリット：

• 誤検知（正常な通信をブロック）の可能性
• チューニングが必要
• 処理が重い

🔍 第3の門番：IDS/IPS

IDS（Intrusion Detection System：侵入検知システム）

「IDSは、不正な通信を検知して警告するシステムよ」

役割：

• ネットワークやホスト（サーバー）を監視
• 怪しい通信やアクセスを見つけたら管理者に通知
• ブロックはしない（検知のみ）

身近な例え：

「防犯カメラと警備員みたいなもの。不審者を見つけたら『怪しい人がいます！』って通報するけど、その場で捕まえたりはしない」

IPS（Intrusion Prevention System：侵入防止システム）

「IPSは、IDSの進化版。検知だけじゃなくて、ブロックもするの」

役割：

• 不正な通信を検知
• 自動的にブロック
• リアルタイムで防御

身近な例え：

「警備員さんが、不審者を見つけたらその場で取り押さえるようなもの」

IDSとIPSの違い：

【IDS】
検知 → 通報 → 管理者が対応（受動的）

【IPS】
検知 → 自動ブロック（能動的）

NIDS（Network-based IDS：ネットワーク型IDS）

「NIDSは、ネットワーク全体を監視するタイプのIDSよ」

特徴：

• ネットワークの途中に設置
• 流れるパケットを全部チェック
• 複数のサーバーを一度に監視できる

身近な例え：

「交差点に設置された防犯カメラ。通る車全部を監視してる」

設置場所：

インターネット → ファイアウォール → [NIDS] → 社内ネットワーク
                                    ↓
                                  監視

HIDS（Host-based IDS：ホスト型IDS）

「HIDSは、サーバー1台1台に入れるタイプのIDSよ」

特徴：

• サーバーにソフトウェアとしてインストール
• そのサーバーのログ、ファイル、プロセスを監視
• 暗号化通信の中身も見れる

身近な例え：

「各部屋に設置された防犯カメラ。その部屋の中だけを詳しく監視」

監視内容：

• ログイン試行の監視
• ファイルの改ざん検知
• プロセスの監視
• システムコールの監視

NIDSとHIDSの使い分け：

【NIDS】
・ネットワーク全体を監視
・設置が簡単（1台で全体を見れる）
・暗号化通信は中身が見えない

【HIDS】
・サーバー個別に監視
・設置が大変（全サーバーに必要）
・暗号化通信も中身が見れる

「理想は両方使うこと。NIDSで外部からの攻撃を監視して、HIDSで内部の異常を監視するの」

IDS/IPSの動作モード

「IDS/IPSには、2つの設置方法があるの」

1. インラインモード（In-Line Mode）

設置方法：通信経路の途中に設置

クライアント → [IPS] → サーバー
           全通信が必ず通る

特徴：

• 全ての通信がIPS を通過
• リアルタイムでブロック可能
• IPSでよく使われる

身近な例え：

「高速道路の料金所。必ず全ての車が通る場所にいるから、怪しい車をその場で止められる」

メリット：

• 攻撃を即座にブロック
• 確実に防御できる

デメリット：

• IPS が止まると通信も止まる（単一障害点）
• 処理が遅いと通信速度が落ちる

2. プロミスキャスモード（Promiscuous Mode）

設置方法：通信経路の横に設置（傍受）

クライアント → サーバー
        ↓コピー
      [IDS]
     （監視のみ）

特徴：

• 通信のコピーを受け取って監視
• ブロックはできない（検知のみ）
• IDSでよく使われる

身近な例え：

「道路脇の監視カメラ。車は普通に通り過ぎるけど、録画して後で確認できる」

メリット：

• 通信速度に影響しない
• IDS が止まっても通信は続く
• 導入が簡単

デメリット：

• リアルタイムでブロックできない
• 攻撃を検知しても、すでに侵入されている

使い分け：

• IDS + プロミスキャスモード：ログ取得、分析用
• IPS + インラインモード：実際の防御用

🎯 第4の門番：UTM（Unified Threat Management）

UTM（ユーティーエム）

「UTMは、全部入りセキュリティ機器よ」

正式名称：Unified Threat Management（統合脅威管理）

役割：

• ファイアウォール
• IDS/IPS
• アンチウイルス
• アンチスパム
• Webフィルタリング
• VPN

これら全部を1台に統合

身近な例え：

「スマホみたいなもの。電話、カメラ、音楽プレイヤー、ゲーム機…全部1台に入ってる」

メリット：

• 管理が楽（1台で全部できる）
• コストが安い（個別に買うより）
• 設定が統一される
• 中小企業に最適

デメリット：

• 1台に集約されるので、壊れたら全機能停止（単一障害点）
• 大規模ネットワークには性能不足
• 専用機器より性能が劣る場合がある

使い分け：

• 中小企業：UTMで十分
• 大企業：専用機器を組み合わせる

📊 各セキュリティ機器の比較

「それぞれの機器の違いをまとめるとこうなるわ」

配置順序：

インターネット
    ↓
[ファイアウォール] ← 最前線（IP/ポートで判断）
    ↓
[IPS] ← 攻撃パターンで判断
    ↓
[WAF] ← Webアプリへの攻撃を判断
    ↓
Webサーバー
    ↓
[HIDS] ← サーバー内部を監視

⚠️ 結城の攻撃開始

その夜、結城は攻撃を開始した。

ステップ1：ポートスキャン

結城：「メタCのサーバー 203.0.113.100 をスキャン…」

# Nmapでポートスキャン
結果：
- TCPポート80（HTTP）：開放
- TCPポート443（HTTPS）：開放
- TCPポート22（SSH）：閉鎖（ファイアウォールでブロック）
- TCPポート3306（MySQL）：閉鎖（ファイアウォールでブロック）

「やっぱり、SSHとMySQLは外部から直接アクセスできないようにしてる…でも、WebサーバーのポートはI開いてる。ここが狙い目だ」

ステップ2：Webアプリケーションの脆弱性探し

結城：「ログインページで SQLインジェクションを試す…」

# SQLインジェクション攻撃
URL：https://meta-c.com/login?user=admin' OR '1'='1'--&pass=dummy

結果：【WAFによってブロック】
HTTP 403 Forbidden
「This request has been blocked for security reasons.」

「くそっ！WAFが入ってる…SQLインジェクションは通らない」

ステップ3：IPS回避を試みる

結城：「攻撃をゆっくり、少しずつ変えながら送ってみる…」

# スロースキャン（ゆっくり攻撃）
結果：【IPSによって検知】

[IPSログ]
2025-01-03 22:15:30 - Slow Scan Detected from 203.0.113.99
2025-01-03 22:15:31 - IP Address 203.0.113.99 Blocked for 24 hours

「ダメだ…IPSも入ってる。しかも、IPごとブロックされた…」

🔍 佐藤の対応

メタCのセキュリティ監視室。佐藤が異常を検知した。

「来たな…また結城だ」

[セキュリティログ]
22:10:15 - Port Scan Detected (Firewall Log)
22:15:20 - SQL Injection Attempt Blocked (WAF Log)
22:15:30 - Slow Scan Detected (IPS Log)
22:15:31 - IP 203.0.113.99 Blocked

「ファイアウォール、WAF、IPS…全部が連携して攻撃を防いでる。多層防御が機能してる」

佐藤は、すぐに追加対策を実施した。

追加対策：

1. 該当IPを完全ブロック（全サービスで）
2. WAFのルールを強化（新しい攻撃パターンを追加）
3. ログ監視を強化（リアルタイムアラート）
4. 警察に通報（サイバー犯罪対策課）

「これで、結城はもうメタCに近づけない」

💑 安堵のひととき

攻撃が阻止された翌日、慎也と里見はメタCのプライベートワールドで話していた。

「里見、また結城の攻撃があったって聞いたけど、大丈夫だった？」

「うん、大丈夫。佐藤さんたちが完璧に防いでくれたわ」

「すごいね…ファイアウォール、WAF、IDS、IPS…全部が連携して守ってくれたんだね」

「そう。多層防御の力よ。1つの防御じゃ突破されるかもしれないけど、何層も重ねれば、攻撃者は疲れちゃうの」

「お城の防御と同じだね。外堀、城壁、内堀、城門…全部突破するのは無理だもんね」

「その通り！慎也、理解が早いわ」

里見が嬉しそうに微笑んだ。

「ねぇ、里見。今回学んだこと、僕の会社でも活かせるかな？」

「もちろん！小さい会社なら、まずはUTMを1台導入するのがオススメよ。それだけで、かなり守れるから」

「UTM、全部入りのやつだよね。今度、上司に提案してみる！」

「素晴らしいわ。あと、大事なのはログをちゃんと見ること。機器を入れただけじゃダメ。異常を検知したら、すぐに対応しないと」

「うん、分かった。里見がいてくれて、本当に助かるよ」

「こちらこそ。慎也は、私の話を真剣に聞いてくれるから嬉しいわ」

二人は手を繋ぎながら、夜空を見上げた。

「結城の攻撃、これで本当に終わりかな？」

「どうかしら…でも、もう警察も動いてるし、技術的にもほぼ完全にブロックできてるから、大丈夫だと思うわ」

「うん、里見と一緒なら、どんな攻撃も乗り越えられる気がする」

「ありがとう。じゃあ、次はもっと高度なセキュリティ技術を学びましょうか」

「うん、楽しみ！」

😤 結城の限界

一方、結城は自室で完全に行き詰まっていた。

「くそっ…もう何も通らない。ファイアウォール、WAF、IPS…全部に阻まれた」

画面には、「403 Forbidden」「Access Denied」「IP Blocked」の文字が並んでいた。

「お砂糖…あなた、本当に優秀ね。DNS、DHCP、SNMP、そして今回のネットワーク侵入…全部対策された」

結城のメールボックスに、警察からの呼び出し状が届いていた。

「不正アクセス禁止法違反、電子計算機損壊等業務妨害罪の疑い…出頭を求める…」

結城の顔が青ざめた。

「もう…本当に終わりなの…？」

結城の長い復讐劇は、ついに終わりを迎えようとしていた。

📚 用語まとめ

🎯 試験対策ポイント

ファイアウォールの種類（超重要！）

IDS vs IPS

NIDS vs HIDS

各機器の役割分担

• ファイアウォール：外部からの不正アクセスをブロック（IP/ポートレベル）
• WAF：Webアプリへの攻撃をブロック（HTTPレベル）
• IPS：攻撃パターンを検知してブロック（シグネチャベース）
• IDS：攻撃を検知して通知（監視専門）
• UTM：上記すべてを1台で実現

頻出問題パターン

問題1：「通信の中身まで検査するファイアウォールはどれか？」

→ アプリケーションゲートウェイ型

問題2：「通信のセッションを管理するファイアウォールはどれか？」

→ ステートフルパケットインスペクション（SPI）

問題3：「SQLインジェクション攻撃を防ぐのはどれか？」

→ WAF

問題4：「不正アクセスを検知するが、ブロックはしないのはどれか？」

→ IDS

問題5：「通信経路の途中に設置して、リアルタイムでブロックするのはどれか？」

→ IPS（インラインモード）

🎓 語呂合わせ・暗記法

ファイアウォールの進化

「パダステアプ」

• パ：パケットフィルタリング
• ダ：ダイナミック
• ステ：ステートフル（SPI）
• アプ：アプリケーションGW

IDS vs IPS

「IDSは検知のみ、IPSは防止もする」

• Detection（検知）← 通知だけ
• Prevention（防止）← ブロックもする

NIDS vs HIDS

「NはNetwork（広い）、HはHost（狭い）」

インラインとプロミスキャス

「インラインは『イン』だから中に入る、プロミスキャスは『プロ』だから横で見守る」

💡 補足：実際の企業での使われ方

小規模企業（従業員50名以下）

• UTM 1台でほぼ全てをカバー
• コストを抑えられる
• 管理が簡単

中規模企業（従業員50〜500名）

• ファイアウォール + IPS + WAF
• 役割ごとに専用機器を配置
• 冗長化（2台体制）も検討

大規模企業（従業員500名以上）

• 多層防御の完全構築
• ファイアウォール、IPS、WAF、NIDS、HIDS すべて導入
• 冗長化、負荷分散
• 24時間監視体制
• SOC（Security Operation Center）設置