この課題では、第41回〜第50回で学んだネットワークセキュリティの知識を使い、 企業ネットワークのセキュリティ設計とインシデント対応を実践します。
章末課題｜企業ネットワークのセキュリティを設計しよう
ファイアウォール、DMZ、IDS・IPS、WAF、VPN、AAA、セグメンテーション、 ゼロトラストを組み合わせ、セキュリティ要件を具体的なネットワーク設計へ落とし込みます。 最後には、実際のインシデントを想定した通信調査にも取り組みます。
実務のセキュリティ設計では、単に「ファイアウォールを置く」 「VPNを導入する」と決めるだけでは不十分です。
何を守るのか、誰からアクセスさせるのか、どこまで通信を許可するのか、 侵害された場合にどう被害を限定するのか を整理し、複数の対策を組み合わせる必要があります。
この章末課題で身につけること
- セキュリティ要件をネットワーク構成へ落とし込む
- ファイアウォールポリシーを設計する
- DMZ・WAF・IDS/IPSの配置理由を説明する
- リモートアクセスVPNを設計する
- AAAによる管理者アクセスを整理する
- ネットワークセグメンテーションを設計する
- ゼロトラストの考え方を既存ネットワークへ適用する
- ログからインシデントの影響範囲を調査する
今回の企業ネットワーク
ITJソリューション株式会社は、社員約500名の企業です。 本社に社内システムと管理ネットワークがあり、 インターネット上では顧客向けWebサービスを公開しています。
社員の約200名はリモートワークを利用しており、 社外から社内システムへアクセスする必要があります。
社内ユーザー
営業部・技術部・管理部など約500名が利用します。
公開サービス
顧客向けWebアプリケーションをインターネットへ公開します。
リモートワーク
約200名がVPN経由で社内システムを利用します。
重要サーバー
業務DB、ファイルサーバー、認証サーバーがあります。
運用管理
ネットワーク管理者10名が機器を運用します。
セキュリティ課題
外部攻撃・マルウェア・不正アクセスへの対策が必要です。
現在の簡略ネットワーク構成
顧客から提示された要件
| 分類 | 要件 |
|---|---|
| 公開Web | インターネットからHTTPSでアクセスできること |
| DB | インターネットから直接アクセスできないこと |
| 社内 | 部署間の不要な通信を制限すること |
| リモート | 社外から安全に社内システムへアクセスできること |
| 認証 | 重要システムでは利用者を確実に識別すること |
| 管理 | ネットワーク機器へ一般社員がアクセスできないこと |
| 攻撃対策 | Web攻撃や不審な通信を検知・防御できること |
| 侵害時 | 1台が侵害されても被害を全社へ拡大させないこと |
| 監査 | 誰がいつアクセスしたか確認できること |
守る対象とリスクを整理する
最初に、「どの製品を入れるか」ではなく、 何を守る必要があるのかを整理してください。
問題
次の観点から、重要な資産と想定リスクを5つ以上挙げてください。
- 公開Webサービス
- 顧客データ
- 社内端末
- 認証情報
- ネットワーク機器
- リモートアクセス
リスク：Webサーバーが侵害され、内部DBへ不正アクセスされる。
解答例を見る
- 公開Web：脆弱性を悪用され、Webサーバーが侵害される
- 顧客DB：個人情報や機密情報が外部へ流出する
- 社員PC：マルウェア感染後に社内ネットワークへ横展開される
- 認証情報：盗まれたID・パスワードで不正ログインされる
- VPN：侵害された端末や認証情報から社内へ侵入される
- ネットワーク機器：管理者権限を奪われ設定を書き換えられる
- ログ：記録不足により侵害範囲を追跡できない
セキュリティゾーンを設計する
すべての端末・サーバーを同じネットワークへ置かず、 役割や重要度に応じてネットワークを分割します。
問題
次の機器・利用者を、適切なセキュリティゾーンへ分類してください。
- 営業部PC
- 技術部PC
- 公開Webサーバー
- 業務DBサーバー
- 認証サーバー
- ネットワーク管理端末
- VPN接続ユーザー
社内ユーザー：
サーバー：
管理：
VPN：
解答例を見る
- DMZ：公開Webサーバー
- 営業セグメント：営業部PC
- 技術セグメント：技術部PC
- サーバーセグメント：業務DB・認証サーバー
- 管理セグメント：管理端末・監視サーバー
- VPNセグメント：リモートアクセスVPNユーザー
重要なのは、VLANを分けること自体ではなく、 セグメント間通信をファイアウォールやACLで制御することです。
ファイアウォールポリシーを作成する
「必要な通信だけを許可する」という考え方で、 ファイアウォールポリシーを作成してください。
条件
- インターネット → WebサーバーはHTTPSのみ許可
- インターネット → DBサーバーは禁止
- Webサーバー → DBサーバーは必要なDB通信のみ許可
- 一般社員 → 管理ネットワークは禁止
- 管理端末 → ネットワーク機器はSSH/HTTPSを許可
解答例を見る
| 送信元 | 宛先 | サービス | Action |
|---|---|---|---|
| Internet | Web | HTTPS | Permit |
| Internet | DB | Any | Deny |
| Web | DB | 必要なDBポート | Permit |
| User | Management | Any | Deny |
| Management PC | Network Device | SSH / HTTPS | Permit |
| Any | Any | Any | Deny |
ポイント： 最後に不要な通信を拒否する考え方を取り入れ、 「必要な通信を個別に許可する」設計にします。
DMZ・WAF・IDS/IPSを配置する
公開Webサービスを守るため、 DMZ・WAF・IDS/IPSの役割と配置を考えます。
問題
- 公開Webサーバーを社内LANへ直接配置しない理由を説明してください。
- WAFをどの通信経路へ配置しますか。
- IDS/IPSはどのような通信を監視・防御しますか。
- WAFとファイアウォールだけでは代替できない理由を説明してください。
解答例を見る
公開WebサーバーはDMZへ配置し、インターネットと内部ネットワークの間に セキュリティ境界を設けます。
WAFはWebサーバーの前段へ配置し、 HTTP/HTTPSのアプリケーション層に対する攻撃を検査します。
IDS/IPSはネットワーク上の不審なパターンや既知攻撃などを検知し、 IPSの場合は条件に応じて通信を遮断します。
ファイアウォール、WAF、IDS/IPSは確認する対象や役割が異なるため、 1つの仕組みだけですべてを防御するのではなく、 多層防御として組み合わせます。
リモートアクセスVPNを設計する
200名のリモートワーカーが社内システムを利用します。
要件
- インターネット経由で安全に接続する
- ID・パスワードだけに依存しない
- VPN接続後もすべての社内ネットワークへアクセスさせない
- 誰が接続したか記録する
- 退職者や不要アカウントを停止できる
問題
認証方式、通信制御、ログ、アカウント管理について設計してください。
アクセス範囲：
ログ：
アカウント管理：
解答例を見る
- 認証：ID・パスワード＋多要素認証
- アクセス範囲：利用者の業務に必要なシステムだけ許可
- 通信制御：VPNセグメントから各社内セグメントへの通信をFWで制御
- ログ：接続者、接続時刻、切断時刻、接続元などを記録
- アカウント管理：人事情報等と連携し不要アカウントを停止
AAAと管理アクセスを設計する
ネットワーク機器の管理者アカウントを各機器へ個別登録しているため、 誰が設定変更したのか追跡しづらい状態です。
問題
Authentication、Authorization、Accountingの3つの観点から改善案を書いてください。
Authorization：
Accounting：
解答例を見る
- Authentication： 管理者本人であることを認証基盤で確認する
- Authorization： 管理者の役割に応じて実行可能な操作を制御する
- Accounting： ログイン日時や操作内容を記録する
共通アカウントを複数人で利用すると、 「誰が操作したのか」を特定しづらくなります。 個人単位で識別できる運用が重要です。
ゼロトラスト導入案を考える
現在は「VPNへ接続できれば社内ユーザーとして信頼する」という考え方です。
これをゼロトラストの考え方へ段階的に変更します。
問題
次の4つについて改善案を書いてください。
- 利用者の確認
- 端末の確認
- アクセス先の制限
- アクセス後の継続的な監視
端末：
アクセス制御：
継続監視：
解答例を見る
- 利用者：多要素認証を使用し、ユーザーを明確に識別する
- 端末：管理対象端末か、セキュリティ状態に問題がないか確認する
- アクセス：ユーザーの役割に必要なアプリケーションだけ許可する
- 監視：アクセス後もログや振る舞いを確認し、異常時は遮断する
ゼロトラストでは、 「社内ネットワークにいるから安全」 「VPN接続したから安全」 と固定的に信頼するのではなく、 アクセスごとに条件を確認する考え方が重要です。
課題8：セキュリティインシデントを調査する
インシデント発生
14時05分、監視システムから 「サーバーセグメント内の端末から大量の外向き通信が発生している」 というアラートが通知されました。
対象は次のサーバーです。
- ホスト名：APP-SRV01
- IPアドレス：10.10.30.25
- 用途：社内業務アプリケーション
最初に確認する情報を整理する
このログだけで「情報漏えいが発生した」と断定してはいけません。
追加で確認したい情報を5つ以上挙げてください。
2.
3.
4.
5.
解答例を見る
- 198.51.100.80が正規の通信先か
- APP-SRV01が通常HTTPS通信を行うサーバーか
- 通信開始時刻と継続時間
- 総送信データ量
- 同じ宛先へ通信している他端末の有無
- 直前のログイン履歴
- サーバー上で動作しているプロセス
- EDRやアンチウイルスの検知結果
- ファイアウォール・IDS/IPSログ
- 直前の設定変更やアプリ更新
初動対応を考える
調査の結果、通常は接続しない外部サーバーとの通信であることが判明しました。
次に行う対応を優先順位付きで整理してください。
優先度2：
優先度3：
優先度4：
対応例を見る
-
影響拡大を抑える
対象端末の隔離や、不審な宛先への通信遮断を検討する。 -
証拠を保存する
ログ・アラート・通信情報など、調査に必要な情報を保存する。 -
影響範囲を確認する
同様の通信を行う端末や、不正アクセスされたアカウントを調査する。 -
関係者へ報告する
現時点で分かっている事実、影響範囲、対応状況を報告する。
注意： 障害・インシデント対応では、 原因が確定していない段階で断定的な報告をしないことも重要です。
再発防止策を考える
今回のインシデントを踏まえ、 ネットワーク側で実施できる再発防止策を5つ以上挙げてください。
解答例を見る
- サーバーからインターネットへの不要な通信を制限する
- セグメント間の通信を最小限にする
- IDS/IPSによる不審通信の検知を強化する
- ファイアウォールログを集中管理する
- 異常な通信量を監視する
- 管理アクセスへ多要素認証を導入する
- 侵害された端末を速やかに隔離できる構成を作る
最終成果物を作成する
最後に、ここまでの回答を1つのセキュリティ設計資料としてまとめてください。
守る対象と想定リスクを整理する
DMZ・社内・サーバー・管理・VPNを整理する
送信元・宛先・サービス・Actionを整理する
Firewall・WAF・IDS/IPSの役割を明示する
認証・アクセス制御・ログを整理する
認証・認可・操作記録を整理する
利用者・端末・アクセス先・監視を整理する
事象・調査内容・対応・再発防止を整理する
上級編では、正解を選ぶだけではなく、 「なぜこの構成にしたのか」を他のエンジニアや顧客へ説明できること が重要です。
採点基準｜100点
| 評価項目 | 配点 | 評価ポイント |
|---|---|---|
| リスク整理 | 10点 | 守る対象と想定脅威を整理できている |
| セグメンテーション | 15点 | 役割・重要度に応じた分割ができている |
| FWポリシー | 15点 | 必要最小限の通信許可になっている |
| DMZ・WAF・IDS/IPS | 15点 | 各機能の役割と配置理由を説明できる |
| VPN・AAA | 15点 | 認証・認可・記録を考慮できている |
| ゼロトラスト | 10点 | ユーザー・端末・アクセス単位で考えられている |
| インシデント対応 | 15点 | 事実確認・封じ込め・調査・再発防止を整理できる |
| 説明力 | 5点 | 設計理由を第三者へ説明できる |
80点以上を、第5章の修了目安とします。
第5章 修了チェック
次の質問へすべて「はい」と答えられるか確認してください。
- ファイアウォールの許可ルールを理由付きで設計できる
- DMZが必要な理由を説明できる
- Firewall・WAF・IDS・IPSの役割を区別できる
- 安全なリモートアクセスVPNの要件を整理できる
- AAAの3要素を実務に当てはめて説明できる
- ネットワークをセグメント化する目的を説明できる
- ゼロトラストを「製品名」ではなく考え方として説明できる
- 不審通信を見たときに追加調査すべき情報を判断できる
- インシデント発生時の初動と再発防止策を整理できる
すべて説明できれば、 第5章「セキュリティ」は修了です。
コメント