この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第41回です。
第5章「セキュリティ」の最初の記事として、 ネットワークセキュリティ設計の全体像と、 セキュリティ要件を具体的なネットワーク構成へ変換する考え方を学びます。
ネットワークセキュリティ設計とは？
守る対象から通信制御・監視まで設計する方法
ネットワークセキュリティ設計は、 ファイアウォールなどの製品を配置するだけの作業ではありません。 守る対象と想定リスクを整理し、ネットワーク分離、通信制御、 認証、暗号化、監視などを組み合わせて、 業務に必要な通信を安全に利用できる構成へ落とし込みます。
「セキュリティを高めるためにファイアウォールを導入する」 という考え方だけでは、ネットワークセキュリティ設計としては不十分です。
設計者には、 「何を守るのか」「何から守るのか」「誰からどこへの通信を許可するのか」 を整理し、その理由を説明することが求められます。
この記事を読み終えるとできること
- ネットワークセキュリティ設計の目的を説明できる
- セキュリティ要件と設計の違いを説明できる
- 守る対象とリスクから対策を検討できる
- セキュリティゾーンを設計できる
- 必要な通信だけを許可する考え方を理解できる
- 管理ネットワーク分離の理由を説明できる
- ログ・監視まで含めて設計できる
- 設計理由を顧客へ説明できる
ネットワークセキュリティ設計とは
ネットワークセキュリティ設計とは、 情報資産やシステムを脅威から守るために、 ネットワーク分離、通信制御、認証、暗号化、監視などを組み合わせ、 必要な通信だけを安全に利用できる構成を設計することです。
セキュリティという言葉を聞くと、 「通信を禁止する」「攻撃をブロックする」といった 防御のイメージを持ちやすいかもしれません。
しかし、企業ネットワークでは業務通信をすべて止めることはできません。
例えば社員が業務Webシステムを利用するのであれば、 PCからWebサーバーへのHTTPS通信は必要です。
セキュリティ設計の目的は「通信をすべて止めること」ではありません。
業務に必要な通信を確保しながら、 不要な通信経路や攻撃可能な範囲をできるだけ小さくすることが重要です。
セキュリティ要件とセキュリティ設計の違い
上級編の 第6回「セキュリティ要件の整理」 では、顧客が求める安全性を要件として整理しました。
今回の第41回では、その要件を具体的なネットワーク構成や 通信制御へ変換していきます。
| 段階 | 考える内容 | 例 |
|---|---|---|
| 要望 | 顧客が実現したいこと | 社内システムを安全に利用したい |
| 要件 | 満たすべき条件 | 一般PCから管理サーバーへ直接アクセスできないこと |
| 設計 | 要件の実現方法 | 管理VLANを分離し、FWで管理端末のみ許可する |
| 設定 | 実際の機器設定 | 送信元・宛先・サービスを指定したFWポリシー |
「次世代ファイアウォールを導入する」は、 それだけではセキュリティ要件ではありません。
先に「どのリスクを下げたいのか」を整理し、 その実現に必要な機能や製品を選びます。
まず「何を守るのか」を決める
セキュリティ製品を選定する前に、 まずネットワーク上で守る対象を整理します。
情報
- 顧客情報
- 個人情報
- 設計資料
- 機密ファイル
- バックアップデータ
システム
- 業務Webシステム
- ファイルサーバー
- データベース
- 認証基盤
- クラウドサービス
ネットワーク機器
- ルーター
- スイッチ
- ファイアウォール
- 無線LAN機器
- VPN装置
アカウント
- 一般ユーザー
- 管理者アカウント
- サービスアカウント
- クラウドIAM
- VPNユーザー
守る対象と通信をセットで考える
例えば、次の業務要件があるとします。
社員PCから業務Webシステムを利用する。
この要件を通信へ分解します。
必要な通信を具体化する
この場合、社員PCからWebサーバーへのHTTPSは必要ですが、 SSH、RDP、データベース接続などを 一般社員へ許可する必要はありません。
ネットワークセキュリティ設計の全体像
企業ネットワークをセキュリティの観点から見ると、 単純な「社内」と「インターネット」の2領域ではなく、 用途と重要度に応じて複数の領域へ分割して考えます。
企業ネットワークのセキュリティゾーン例
ネットワークを分ける目的は、 VLAN数を増やすことではありません。
用途や信頼レベルが異なる通信を分離し、 必要な通信だけを境界で許可できるようにすること が目的です。
セキュリティゾーンを設計する
ネットワークセキュリティ設計では、 同じ性質を持つ機器や通信をセキュリティゾーンとしてまとめます。
| ゾーン | 主な用途 | 設計上の考え方 |
|---|---|---|
| Internet | 外部ネットワーク | 原則として信頼しない |
| DMZ | 公開Web・DNS等 | 内部ネットワークと分離する |
| User | 社員PC | 業務上必要な宛先のみ許可する |
| Server | 業務サーバー | ユーザーやサーバー間通信を制御する |
| Management | ネットワーク管理 | 管理者・管理端末だけに限定する |
| Guest | 来訪者Wi-Fi | 社内ネットワークへのアクセスを禁止する |
| IoT | カメラ・センサー等 | 一般ユーザーや重要サーバーから分離する |
「VLANを分けた」で設計を終わらせないことが重要です。
VLANやサブネットを分離したあと、 ゾーン間のどの通信を許可するのかまで決めます。
通信制御を設計する
セキュリティゾーンを決めたら、 次にゾーン間で許可する通信を定義します。
基本となる考え方は、 業務上必要な通信だけを許可する ことです。
通信要件表を作る
| No. | 送信元 | 宛先 | プロトコル／ポート | 用途 | 判定 |
|---|---|---|---|---|---|
| 1 | User VLAN | Web Server | TCP/443 | 業務システム | 許可 |
| 2 | User VLAN | DNS Server | UDP/TCP 53 | 名前解決 | 許可 |
| 3 | User VLAN | Network Device | TCP/22 | SSH管理 | 拒否 |
| 4 | Admin VLAN | Network Device | TCP/22 | SSH管理 | 許可 |
| 5 | Guest VLAN | Internal Network | Any | 社内アクセス | 拒否 |
この通信要件をもとに、 ACLやファイアウォールポリシー、 クラウドのセキュリティ制御へ落とし込みます。
次の 第42回「ファイアウォールポリシー設計」 では、この通信要件をSource、Destination、Service、 Action、Loggingなどへ変換する方法を詳しく学びます。
インターネット公開システムを守る
Webサーバーなどをインターネットへ公開する場合、 社内の重要サーバーと同じネットワークへ配置すると、 公開サーバーが侵害された際に内部へ被害が広がる可能性があります。
DMZを利用した公開システムの分離
例えばインターネットからWebサーバーへはHTTPSのみを許可します。
さらにWebサーバーから内部データベースへの通信が必要な場合も、 必要なポートだけに限定します。
公開サーバーが侵害される可能性も考え、 その先へ自由に通信できない構成にすることが重要です。
DMZの詳細は 第43回「DMZ設計」 で詳しく扱います。
管理ネットワークを分離する
ネットワーク機器には、 通常の業務通信とは別に管理用通信があります。
- SSH
- HTTPS
- SNMP
- API
- Syslog
- NTP
一般社員のPCから、 ルーターやファイアウォールの管理画面へアクセスする必要はありません。
管理ネットワークの分離例
さらに、次の対策を組み合わせます。
- 管理アクセス元IPを限定する
- 管理端末を限定する
- 管理者認証を強化する
- 不要な管理サービスを停止する
- 管理操作をログへ残す
- 管理ネットワークとユーザーネットワークを分離する
暗号化とVPNを設計する
インターネットなど信頼できないネットワークを経由する通信では、 盗聴や改ざんのリスクを考える必要があります。
特に次のような通信では暗号化を検討します。
- 拠点間通信
- リモートアクセス
- オンプレミスとクラウドの接続
- 管理通信
拠点間VPNの例
VPNを使用しているから安全、とは限りません。
VPNで接続した後に、 利用者がどのネットワークやシステムへアクセスできるのかも 設計する必要があります。
VPN全体の設計については 第17回「VPN設計」 も参照してください。
ログ・監視・検知を設計する
セキュリティ対策では、 攻撃を防止するだけでなく、 異常が発生したときに検知・調査できることも重要です。
収集を検討するログ
ネットワーク境界
- Firewall Allowログ
- Firewall Denyログ
- NATログ
- VPN接続ログ
セキュリティ機能
- IDS・IPS検知ログ
- WAFログ
- URLフィルタログ
- 脅威検知ログ
認証
- ログイン成功・失敗
- VPN認証
- 管理者認証
- 権限変更
管理操作
- 設定変更
- 管理者ログイン
- 設定保存
- システム再起動
セキュリティインシデントが発生したあとに 「必要なログを取得していなかった」とならないよう、 あらかじめログ設計を行います。
ログの保存先、保存期間、時刻同期、転送方法については、 第20回「ログ設計」 の内容と組み合わせて考えます。
侵害された場合の被害範囲を限定する
セキュリティ設計では、 「絶対に侵入されない」ことだけを前提にしてはいけません。
1台の端末が侵害された場合でも、 他の重要なサーバーへ自由に移動できない構成を考えます。
分離が不十分なネットワーク
1台の侵害から広い範囲へ到達できる状態
セグメンテーションしたネットワーク
ゾーン間通信を制限する
このように、侵害後に他のシステムへ移動できる範囲を 小さくすることもネットワークセキュリティ設計の重要な役割です。
詳細は 第48回「ネットワークセグメンテーション」 で扱います。
多層防御で考える
1つの製品や機能ですべての攻撃を防ぐことはできません。
そのため、異なる役割を持つ複数の対策を組み合わせます。
Webシステムを守る多層防御の例
| 対策 | 主な役割 |
|---|---|
| Firewall | 送信元・宛先・ポートなどによる通信制御 |
| IDS・IPS | 不審な通信や攻撃パターンの検知・防御 |
| WAF | Webアプリケーション向け通信の保護 |
| VPN | 通信経路の暗号化 |
| 認証 | 利用者・端末の確認 |
| セグメンテーション | 侵害時の影響範囲を限定 |
| ログ監視 | 異常の検知とインシデント調査 |
ネットワークセキュリティ設計の進め方
実務では、次の順番で整理すると設計しやすくなります。
- 守る対象を確認する システム、サーバー、データ、ネットワーク機器、 アカウントなどの情報資産を整理します。
- 想定するリスクを整理する 外部からの不正アクセス、マルウェア、 内部不正、盗聴、アカウント侵害などを整理します。
- 通信要件を整理する 誰が、どこへ、何のために、 どのプロトコルで通信するのかを明確にします。
- セキュリティゾーンを決める User、Server、DMZ、Management、 Guestなどへ分離します。
- ゾーン間通信を定義する 業務上必要な通信だけを許可する方針を作ります。
- セキュリティ機能を配置する Firewall、IDS・IPS、WAF、VPN、 認証基盤などを必要に応じて配置します。
- 管理経路を設計する 誰がどこからネットワーク機器を管理できるのかを決めます。
- ログ・監視を設計する 異常を検知し、問題発生時に調査できる状態を作ります。
- 障害時の影響を確認する セキュリティ機器そのものが単一障害点にならないか確認します。
- 試験項目を作成する 許可通信、禁止通信、ログ、認証、 フェイルオーバーなどを確認します。
セキュリティ要件から設計へ変換する例
要件1
インターネットから社内サーバーへ直接アクセスできないこと。
設計例：
公開WebサーバーをDMZへ配置し、
内部サーバーとはFirewallで分離する。
要件2
一般社員からネットワーク機器の管理画面へアクセスできないこと。
設計例：
管理VLANを作成し、
管理端末からのみSSH／HTTPSを許可する。
要件3
来訪者用Wi-Fiから社内ネットワークへアクセスできないこと。
設計例：
Guest VLANを社内ネットワークから分離し、
インターネット向け通信のみ許可する。
要件4
拠点間で機密情報を安全に通信できること。
設計例：
拠点間IPsec VPNを構成して通信を暗号化する。
要件5
不正アクセス発生時に通信履歴を調査できること。
設計例：
Firewall、VPN、認証、IDS・IPSなどのログを
集中管理する。
要件6
社員PCが侵害されても重要サーバーへの被害を限定すること。
設計例：
User、Server、Managementを分離し、
ゾーン間通信を必要最小限にする。
可用性とセキュリティを両立させる
セキュリティを強化することだけを考えると、 セキュリティ装置自体がサービス停止の原因になる場合があります。
例えばインターネット接続が 1台のファイアウォールだけを経由している場合、 その機器が故障すると通信全体が停止する可能性があります。
Firewall冗長化のイメージ
ネットワークセキュリティ設計では、 セキュリティ・可用性・性能・運用性・コスト のバランスを考えることが重要です。
ネットワークセキュリティ設計のよくある失敗
「セキュリティ強化のため次世代Firewallを導入する」 だけでは、何のリスクを解決するのか分かりません。
先に守る対象、リスク、通信要件を整理します。
一度社内へ侵入されると、 多数のシステムへ自由にアクセスできる構成は 被害が拡大しやすくなります。
障害回避のため一時的に全許可したルールが、 そのまま残ってしまうケースがあります。
一時ルールには目的、申請者、作成日、 削除予定日などを記録します。
一般PCからネットワーク機器の管理インターフェースへ 到達できる構成は、侵害時のリスクを高めます。
通信を拒否できても、 誰がいつ何を行ったか確認できなければ、 インシデント調査が難しくなります。
通ってはいけない通信だけでなく、 業務に必要な通信が正常に通ることも確認します。
良いセキュリティ設計は、 セキュリティ機能を増やすことではなく、 業務を維持しながらリスクを下げる設計です。
顧客・上司への説明方法
設計レビューで、
「セキュリティ上必要なので、 管理ネットワークを分けました」
とだけ説明しても、 非エンジニアには必要性が伝わりにくい場合があります。
セキュリティ設計は、 リスク → 対策 → 効果 の順番で説明すると分かりやすくなります。
管理ネットワークを分離する場合
| 項目 | 説明 |
|---|---|
| リスク | 社員PCがマルウェア感染すると、ネットワーク機器の管理画面へ攻撃される可能性がある |
| 対策 | 管理ネットワークを分離し、管理端末からのみアクセスを許可する |
| 効果 | 一般PCが侵害されても、ネットワーク機器の管理インターフェースへ直接到達しにくくなる |
「何を設定するか」ではなく、 「どのリスクを下げるための設計なのか」を説明しましょう。
ネットワークセキュリティで使う英語表現
| 英語 | 意味 |
|---|---|
| Network Security | ネットワークセキュリティ |
| Security Policy | セキュリティポリシー |
| Access Control | アクセス制御 |
| Least Privilege | 最小権限 |
| Network Segmentation | ネットワーク分割 |
| Security Zone | セキュリティゾーン |
| Management Network | 管理ネットワーク |
| Threat | 脅威 |
| Vulnerability | 脆弱性 |
| Attack Surface | 攻撃対象領域 |
| Defense in Depth | 多層防御 |
| Lateral Movement | 侵害後の横展開 |
| Unauthorized Access | 不正アクセス |
英文例1
Only required traffic should be allowed between security zones.
セキュリティゾーン間では、 必要な通信だけを許可する必要があります。
英文例2
Administrative access should be restricted to authorized management hosts.
管理アクセスは、 許可された管理端末だけに制限する必要があります。
英文例3
Network segmentation can help limit the impact of a compromised endpoint.
ネットワーク分割は、 端末が侵害された場合の影響範囲を限定するのに役立ちます。
理解度チェック
記事の内容を確認するため、 次の5問に答えてください。
問題1．ネットワークセキュリティ設計を始める際、 最初に確認すべきこととして最も適切なのはどれですか。
- Firewallのメーカー
- IPSのライセンス価格
- 守る対象とセキュリティ要件
- すべての通信を拒否する方法
解答を見る
先に守る対象、リスク、必要な通信などを整理し、 その後に具体的な方式や製品を検討します。
問題2．社員PCから業務Webサーバーへ HTTPSだけが必要な場合、適切な考え方はどれですか。
- 社員PCからサーバーネットワークへすべて許可する
- HTTPSなど必要な通信だけを許可する
- Firewallを使用しない
- 社員PCとすべてのサーバーを同じVLANへ配置する
解答を見る
業務上必要な通信を明確にし、 不要な通信を許可しないように設計します。
問題3．来訪者用Wi-Fiの設計として適切なのはどれですか。
- 社員PCと同じネットワークへ収容する
- 管理ネットワークへ接続する
- 社内ネットワークから分離する
- すべての社内サーバーへアクセス可能にする
解答を見る
Guestネットワークは社内ネットワークから分離し、 必要に応じてインターネット向け通信だけを許可します。
問題4．ネットワーク機器のSSH管理として、 より安全な設計はどれですか。
- 社員PCすべてから許可する
- インターネットから直接許可する
- 許可された管理端末からだけ許可する
- 送信元Anyで許可する
解答を見る
管理ネットワークを分離し、 管理アクセス元を限定することが重要です。
問題5．次の空欄を埋めてください。
ネットワークセキュリティでは、 侵入を防ぐだけでなく、 侵害された場合に被害が他のシステムへ広がらないよう、 ネットワークを適切に「＿＿＿＿＿＿」することも重要です。
解答を見る
ユーザー、サーバー、管理ネットワークなどを分離し、 必要な通信だけを許可することで、 侵害時の影響範囲を限定できます。
実践演習：小規模企業のセキュリティ構成を設計する
次の企業ネットワークを想定します。
現在のネットワーク
顧客要望
- Webサーバーをインターネットへ公開したい
- 社員からファイルサーバーを利用したい
- 来訪者へWi-Fiを提供したい
- 来訪者から社内システムへアクセスさせたくない
- ネットワーク機器の管理画面へ社員全員がアクセスできる状態をやめたい
- 不正アクセス発生時にログを確認できるようにしたい
課題1．セキュリティゾーンを設計する
どのようなゾーンへ分割するべきか考えてください。
解答例を見る
- DMZ
- User Network
- Server Network
- Management Network
- Guest Network
課題2．通信要件を作る
最低5つの通信ルールを考えてください。
解答例を見る
| 送信元 | 宛先 | 通信 | 判定 |
|---|---|---|---|
| Internet | Web Server | HTTPS | 許可 |
| Internet | File Server | Any | 拒否 |
| User | File Server | 必要なファイル共有通信 | 許可 |
| Guest | Internal | Any | 拒否 |
| Guest | Internet | Web等 | 許可 |
| User | Network Device | SSH/HTTPS | 拒否 |
| Admin PC | Network Device | SSH/HTTPS | 許可 |
課題3．必要なセキュリティ機能を考える
次の観点から必要な機能を書き出してください。
- インターネット境界
- Webサーバー公開
- 管理アクセス
- ログ
- 侵害時の横展開防止
解答例を見る
- Firewallによる境界制御
- DMZによる公開サーバー分離
- 必要に応じたIDS・IPSやWAF
- 管理ネットワーク分離
- Firewallや認証ログの集中管理
- User・Server・Managementのセグメンテーション
課題4．設計理由を顧客へ説明する
顧客から次の質問を受けました。
「なぜ社員PC、サーバー、ゲストWi-Fi、 管理ネットワークを分ける必要があるのですか？」
説明例を見る
ネットワークを用途ごとに分離することで、 1台の端末がマルウェア感染や不正アクセスを受けた場合でも、 他の重要なシステムへ自由にアクセスできないようにします。
例えば来訪者用Wi-Fiから社内ファイルサーバーへ アクセスする必要はありません。
また、ネットワーク機器の管理画面は 管理担当者だけが利用できればよいため、 管理ネットワークへ分離します。
必要な通信だけを許可することで、 業務への影響を抑えながら、 不正アクセスや侵害拡大のリスクを低減できます。
自分の言葉で説明する課題
顧客から次の質問を受けました。
「Firewallを導入するのであれば、 ネットワークを分ける必要はないのではないですか？」
30秒程度で説明してください。
説明例を見る
Firewallは重要なセキュリティ対策ですが、 1つの対策だけですべてのリスクへ対応することはできません。
社員PC、サーバー、管理ネットワークなどを分離し、 必要な通信だけを許可することで、 万が一1台の端末が侵害された場合でも、 他のシステムへのアクセスを制限できます。
そのためFirewallだけでなく、 ネットワーク分離、認証、監視などを組み合わせて設計します。
まとめ
- ネットワークセキュリティ設計は、 セキュリティ製品を配置するだけの作業ではない
- 最初に守る対象、リスク、必要な通信を整理する
- 要件をセキュリティゾーンや通信制御へ変換する
- User、Server、DMZ、Management、Guestなど、 用途や信頼度に応じてネットワークを分離する
- ゾーン間では業務上必要な通信だけを許可する
- インターネット公開システムと内部システムを分離する
- 管理通信は一般ユーザー通信から分離する
- VPNでは暗号化だけでなく接続後のアクセス範囲も設計する
- 攻撃の防止だけでなくログによる検知・調査も設計する
- 侵害された場合に被害が広がらない構成を考える
- Firewall、IDS・IPS、WAF、認証、セグメンテーションなどを 多層的に組み合わせる
- セキュリティだけでなく可用性・性能・運用性・コストも考慮する
良いネットワークセキュリティ設計とは、 「すべてを禁止する設計」ではありません。 業務に必要な通信を明確にし、 不要な通信経路をできるだけ減らす設計です。
コメント