1. VPCとサブネット: セキュリティ境界の出発点
VPCは、ユーザーが直接定義する論理的な仮想ネットワークです。オンプレミス環境に例えるなら、会社の内部ネットワークをAWS内に構築するのと似ています。
しかし、VPCを一つ作成しただけでセキュリティが完成するわけではありません。重要なのは、VPC内部をどのように分割するかです。
最も基本的な方法は、パブリックサブネットとプライベートサブネットを分離することです。
パブリックサブネット
パブリックサブネットは、インターネットゲートウェイへのルーティングがあるサブネットです。
一般的に、以下のリソースが配置されます。
- ALB
- Bastion Host
- NAT Gateway
- 外部から直接アクセスする必要がある一部のサービス
プライベートサブネット
プライベートサブネットは、インターネットから直接アクセスできないように構成するサブネットです。
一般的に、以下のリソースが配置されます。
- アプリケーションサーバー
- データベース
- 内部APIサーバー
- EKSノード
- ECSサービス
- ElastiCache
- OpenSearch
セキュリティの観点から重要な原則はシンプルです。
外部に直接公開する必要があるリソースのみをパブリックサブネットに配置し、残りは可能な限りプライベートサブネットに配置する必要があります。
特にデータベースは、ほとんどの場合、パブリックサブネットに置く必要はありません。
実務で最もよくある間違いは、「テストだから一時的にパブリックに開こう」というものです。問題は、この設定が本番環境までそのまま残ってしまうことが多い点です。
VPCセキュリティは、複雑なセキュリティ機器よりもまず、リソースが配置される場所を正しく設計することから始まります。
2. ルートテーブル: トラフィックの移動経路を制御する機能
VPC内でトラフィックがどこに移動するかは、ルートテーブルが決定します。
サブネットがどれほどプライベートに見えても、ルートテーブルにインターネットゲートウェイへのデフォルトルートがある場合、外部通信が可能な構造になります。
例えば、以下のようなルーティングがある場合、そのサブネットはパブリックな性質を持ちます。
0.0.0.0/0 -> Internet Gateway逆に、プライベートサブネットの一般的なルーティングは以下の通りです。
0.0.0.0/0 -> NAT Gatewayこの場合、プライベートサブネットのインスタンスはインターネットに出ることはできますが、インターネットからそのインスタンスに直接入ってくることはできません。
つまり、パッチのダウンロード、パッケージのインストール、外部API呼び出しは可能ですが、外部ユーザーが直接サーバーに接続する構造ではありません。
ルートテーブルは、セキュリティグループやネットワークACLのように「許可/拒否ルール」として見えないため、セキュリティ機能のように感じられないかもしれません。しかし、実際にはVPCセキュリティにおいて非常に重要な機能です。
誤ったルーティングは、内部ネットワークを外部に公開する可能性があります。
VPCセキュリティチェック時には、以下の項目を必ず確認する必要があります。
- データベースサブネットにインターネットゲートウェイの経路があるか？
- 内部アプリケーションサブネットが不必要にインターネットと直接接続されていないか？
- NATゲートウェイを介して出るトラフィックが制御されているか？
- Transit Gateway、VPC Peering、VPN接続を介して予期せぬネットワーク経路が生成されていないか？
VPCセキュリティチェックを行う際は、セキュリティグループだけでなく、ルートテーブルも一緒に確認する必要があります。
実際の攻撃経路は、「許可されたポート」と「開かれたルーティング」が組み合わされたときに作成されます。
3. セキュリティグループ: リソース単位の仮想ファイアウォール
セキュリティグループは、VPCセキュリティで最もよく使用される機能です。
EC2、RDS、ALB、ENI、VPCエンドポイントなど、さまざまなリソースに接続して、インバウンドおよびアウトバウンドトラフィックを制御します。
セキュリティグループの主要な特徴は、ステートフルであることです。
例えば、EC2インスタンスが外部にHTTPSリクエストを送信した場合、その応答トラフィックはインバウンドルールに別途明示されていなくても許可されます。
逆に、外部からEC2に入ってくるトラフィックは、インバウンドルールで許可されている必要があります。
危険なセキュリティグループの例
以下の設定は、運用環境では非常に危険です。
SSH 22번 포트 0.0.0.0/0 허용
RDP 3389번 포트 0.0.0.0/0 허용
MySQL 3306번 포트 0.0.0.0/0 허용
모든 아웃바운드 0.0.0.0/0 허용テスト環境ではよく見られる設定ですが、運用環境では非常に危険です。
特にSSHとRDPをインターネット全体に公開すると、ブルートフォース攻撃、脆弱なアカウント攻撃、公開されたキーの悪用などの対象となる可能性があります。
推奨されるセキュリティグループ設計良い方法は、送信元IPまたは他のセキュリティグループを基準に制限することです。
例えば、ALBセキュリティグループは、80番ポートと443番ポートをインターネットに許可できます。
しかし、アプリケーションサーバーのセキュリティグループは、インターネットからではなく、ALBセキュリティグループからのトラフィックのみを許可する必要があります。
RDSセキュリティグループは、アプリケーションサーバーセキュリティグループからの3306番または5432番ポートのみを許可すれば十分です。
一般的な流れは以下の通りです。
사용자 -> ALB -> 애플리케이션 서버 -> 데이터베이스この場合、データベースはユーザーのIPを直接知る必要もなく、インターネットに公開される必要もありません。
アプリケーションサーバーからのトラフィックのみを受け取ればよいのです。
セキュリティグループは単にポートを開放する機能ではありません。
セキュリティグループは、アプリケーション層間の信頼関係をネットワークレベルで表現する機能です。
4. ネットワークACL: サブネット単位の補助的な防御線
ネットワークACLは、サブネット単位で動作するアクセス制御機能です。
セキュリティグループがリソース単位であるのに対し、ネットワークACLはサブネット境界でトラフィックを制御します。
セキュリティグループとネットワークACLには、以下の違いがあります。
| 区分 | セキュリティグループ | ネットワークACL |
| 適用単位 | リソースまたはENI | サブネット |
| 動作方式 | ステートフル | ステートレス |
| ルールタイプ | 許可ルール | 許可および拒否ルール |
| 主な使用目的 | リソース単位の制御 | サブネット単位の補助制御 |
ステートレス方式とは、リクエストとレスポンスを別々に扱うという意味です。
例えば、インバウンド80番ポートを許可していても、応答として出るアウトバウンドトラフィックが許可されていない場合、通信が失敗する可能性があります。
ネットワークACLは、きめ細かなアプリケーション制御よりも、サブネット単位の広範な制御に適しています。
例えば、特定の悪意のあるIP帯域をサブネット全体でブロックしたり、特定のサブネットが指定されたポート以外では通信できないように制限したりするような使い方です。
ただし、すべてのセキュリティをネットワークACLで処理しようとすると、運用が複雑になる可能性があります。
実務では、セキュリティグループを主要な制御手段として使用し、ネットワークACLは補助的な防御線やガードレールとして使用するのが一般的です。
5. インターネットゲートウェイとNATゲートウェイ: インターネット接続を安全に分離する
VPCがインターネットと通信するには、インターネットゲートウェイが必要です。
しかし、インターネットゲートウェイがあるからといって、すべてのリソースがインターネットに公開されるわけではありません。
実際のインターネットアクセスは、以下の要素によって決定されます。
- パブリックIPの有無
- ルートテーブル
- セキュリティグループ
- ネットワークACL
- インターネットゲートウェイの接続状況
パブリックサブネットのリソースは、インターネットゲートウェイを介して外部と直接通信できます。
一方、プライベートサブネットのリソースは、一般的にNATゲートウェイを介して外部に出ます。
NATゲートウェイは、プライベートサブネットのリソースがインターネットに出ることを可能にしますが、外部インターネットからプライベートインスタンスへの直接接続を開始することはできません。
この構造は非常に重要です。
例えば、アプリケーションサーバーはOSのアップデートや外部API呼び出しのためにインターネット接続が必要になることがあります。
しかし、インターネットユーザーがアプリケーションサーバーに直接接続する必要はありません。
このとき、NATゲートウェイを使用すると、以下の構造を作成できます。
프라이빗 서버 -> NAT Gateway -> Internet Gateway -> 인터넷つまり、出ていく通信は許可し、入ってくる直接接続は遮断する構造です。
ただし、NATゲートウェイだけで完全なセキュリティが実現するわけではありません。
NATゲートウェイは、基本的に出ていくトラフィックを細かく検査したり、ドメイン別に遮断したりするセキュリティ機器ではありません。
したがって、重要な環境では、以下の機能と組み合わせて設計することをお勧めします。
- AWS Network Firewall
- プロキシサーバー
- Route 53 Resolver DNS Firewall
- egress filtering
- VPC Flow Logs
6. VPCエンドポイントとPrivateLink: AWSサービスへのアクセスをプライベートネットワークで処理する
多くのAWSサービスは、パブリックエンドポイントを介してアクセスされます。
例えば、EC2からS3にアクセスしたり、ECSからECRイメージを取得したり、アプリケーションからSecrets Managerを呼び出したりする状況が考えられます。
セキュリティが重要な環境では、可能な限りインターネットを経由せず、AWS内部ネットワーク経路でサービスにアクセスすることをお勧めします。
このときに使用する機能がVPCエンドポイントです。
VPCエンドポイントは、大きく分けて2つのタイプに分類できます。
ゲートウェイエンドポイント
ゲートウェイエンドポイントは、代表的に以下のサービスに使用されます。
- Amazon S3
- Amazon DynamoDB
ゲートウェイエンドポイントを使用すると、別途インターネットゲートウェイやNATゲートウェイなしで、VPC内部からS3、DynamoDBにアクセスできます。
インターフェースエンドポイント
インターフェースエンドポイントは、AWS PrivateLinkに基づいて動作し、AWSサービスにプライベートIPベースでアクセスできるようにします。
代表的に以下のサービスに使用できます。
- AWS Systems Manager
- AWS Secrets Manager
- Amazon ECR
- Amazon CloudWatch Logs
- AWS STS
- AWS KMS
- Amazon ECS
- Amazon EKS関連の一部サービス
VPCエンドポイントのセキュリティ上の利点は大きいです。
- インターネット経路を減らすことができる。
- NATゲートウェイへの依存度を減らすことができる。
- エンドポイントポリシーでアクセス可能な操作を制限できる。
- S3バケットポリシーで特定のVPCエンドポイントを介したリクエストのみを許可できる。
- 認証情報が外部で盗まれた場合でも、アクセス経路を制限できる。
例えば、以下のようなセキュリティポリシーを作成できます。
このS3バケットは、私たちのVPCの特定のVPCエンドポイントを介してのみアクセス可能です。
これにより、認証情報が盗まれた場合でも、外部インターネットから直接S3にアクセスすることを困難にできます。
VPCエンドポイントは、コスト削減目的だけで見る機能ではありません。
実際には、データ流出経路を減らす強力なセキュリティ設計要素です。
7. AWS Network Firewall: VPC単位のマネージド型ファイアウォール
セキュリティグループとネットワークACLは、基本的なネットワーク制御には非常に有用ですが、高度なセキュリティ検査には限界があります。
例えば、以下の要件がある場合、AWS Network Firewallを検討できます。
- ドメインベースのフィルタリング
- ステートフルなトラフィック検査
- 侵入検知および防止
- 集中型egress制御
- 疑わしい外部通信の遮断
- VPC間トラフィック検査
AWS Network Firewallは、VPCに適用できるマネージド型ネットワークファイアウォールサービスです。
ステートフルファイアウォール機能と侵入検知および防止機能を提供し、インターネットゲートウェイ、NATゲートウェイ、VPN、Direct Connect経路などからのトラフィックをフィルタリングする構造で使用できます。
実務では、特に出ていくトラフィックの制御に多く使用されます。
多くの企業はインバウンドセキュリティには敏感ですが、アウトバウンドセキュリティは比較的緩く設定しがちです。
しかし、侵害事故後、マルウェアが外部C2サーバーと通信したり、内部データが外部に流出する方向は、たいていアウトバウンドです。
したがって、重要なVPCでは、以下のポリシーを検討する必要があります。
- プライベートサブネットのすべてのインターネットアウトバウンドトラフィックをNetwork Firewallを介するようにする。
- 許可されたドメインまたはIP帯域のみ外部通信を許可する。
- 疑わしいプロトコルや異常なポートを遮断する。
- ファイアウォールログをCloudWatch Logs、S3、Security Lakeなどに収集する。
Network Firewallは単なる「高価なファイアウォール」ではありません。
VPCのegress制御と中央セキュリティポリシー適用のための中核機能と見なすことができます。
8. VPCフローログ: ネットワークフローを記録する基本的な可視性機能
セキュリティにおいて最も危険な状態は、「何が起こっているか分からない状態」です。
VPC内でどのIPがどのIPと通信したか、どのポートが許可されたか、どのトラフィックが拒否されたかを知ることができなければ、インシデント対応は非常に困難になります。
VPCフローログは、VPC、サブネット、ネットワークインターフェース単位でIPトラフィック情報を収集する機能です。
収集されたログは、以下の宛先に送信できます。
- Amazon CloudWatch Logs
- Amazon S3
- Amazon Data Firehose
フローログを活用すると、以下の分析が可能です。
- 特定のEC2が外部の見慣れないIPと通信したかどうかの確認
- セキュリティグループまたはネットワークACLによって拒否されたトラフィックの確認
- 使用されていないポートが継続的に呼び出されているかどうかの分析
- データベースに直接アクセスしようとする試みがあるかどうかの確認
- NATゲートウェイを介して外部に出るトラフィックの流れの把握
- 侵害事故発生時の攻撃者の移動経路の追跡
ただし、フローログはパケットの全体内容を保存する機能ではありません。
つまり、HTTP本文やファイルの内容まで表示するわけではありません。
代わりに、以下のフロー情報を提供します。
- 送信元IP
- 宛先IP
- 送信元ポート
- 宛先ポート
- プロトコル
- 許可または拒否の有無
- バイト数
- パケット数
- 時間情報
そのため、フローログは「ネットワークCCTV」というよりも「ネットワーク出入記録簿」に近いものです。
誰がどこに移動したか、どのドアから出たかを記録する機能です。
運用環境では、少なくとも重要なVPCまたは重要なサブネットにはフローログを有効にすることをお勧めします。
特にセキュリティの観点からは、ACCEPTログだけでなくREJECTログも一緒に分析する必要があります。
拒否されたトラフィックは、攻撃試行、誤った設定、アプリケーション障害の手がかりとなる可能性があります。
9. トラフィックミラーリング: パケットレベル分析が必要な場合
VPCフローログがネットワークフロー情報を提供するのに対し、トラフィックミラーリングは実際のトラフィックのコピーをセキュリティ分析装置に転送する機能です。
例えば、特定のEC2インスタンスのENIで発生するトラフィックをコピーして、以下のシステムに送信できます。
- IDS
- NDR
- パケット分析システム
- フォレンジック機器
- セキュリティ監視装置
トラフィックミラーリングは、セキュリティ事故分析、侵入検知、コンプライアンス、ネットワーク問題解決に有用です。
ただし、すべての環境に必ず必要な機能ではありません。
一般的なウェブサービス運用では、フローログとアプリケーションログだけでも十分な場合が多いです。
しかし、以下のような環境では有用である可能性があります。
- 金融機関またはセキュリティ監視が重要な環境
- パケットレベルの侵入検知が必要な環境
- ゼロトラストネットワーク分析を実行する環境
- 侵害事故発生時に特定のサーバーのトラフィックを詳細分析する必要がある環境
注意すべき点は、トラフィックミラーリングがトラフィックコピー機能であるため、コスト、パフォーマンス、個人情報保護、保存ポリシーを合わせて考慮する必要があることです。
無闇にすべてのトラフィックを複製するのではなく、重要な区間のみを選択的にミラーリングすることをお勧めします。
10. Reachability Analyzer: 実際の接続可能経路を検証する機能
VPCセキュリティ設定は、複数の要素が連携して動作します。
以下の要素が組み合わさるため、人間が目視で確認するだけでは見落としが生じる可能性があります。
- セキュリティグループ
- ネットワークACL
- ルートテーブル
- NATゲートウェイ
- インターネットゲートウェイ
- Transit Gateway
- ロードバランサー
- Network Firewall
- VPCエンドポイント
Reachability Analyzerは、特定の送信元から宛先までネットワーク的に到達可能かどうかを分析するツールです。
例えば、以下のような質問を確認できます。
- このEC2からRDSの3306番ポートにアクセス可能か？
- インターネットからこのENIまで到達可能か？
- Bastion Hostから内部サーバーへSSHアクセスが可能か？
- アプリケーションサーバーからのみRDSにアクセス可能か？
- 特定のサブネットから外部インターネットへ出る経路が存在するか？
到達可能であれば経路を段階的に表示し、到達不可能であればどの構成要素でブロックされたかを確認できます。
実務では、Reachability Analyzerは障害分析にも優れていますが、セキュリティ検証にも非常に有用です。
運用環境で重要な変更を行う前後でReachability Analyzerを使用すると、ネットワーク変更によるセキュリティ影響度を確認できます。
11. Network Access Analyzer: 意図しないネットワークアクセスを見つける
Reachability Analyzerが特定の送信元と宛先間の接続可能性を確認するツールであるのに対し、Network Access Analyzerはより広い観点から意図しないネットワークアクセス経路を見つける機能です。
例えば、以下のような範囲ベースの分析を実行できます。
- インターネットからアクセス可能なネットワークインターフェースがあるか？
- 特定のVPC外部から内部リソースにアクセス可能な経路があるか？
- 意図しないVPC Peering経路があるか？
- 外部ネットワークからデータベース層にアクセス可能な経路があるか？
人間がすべてのリソースの組み合わせを一つずつ確認するのは困難であるため、静的分析方式でネットワーク経路を見つける機能はセキュリティ監査に非常に有用です。
特に複数のアカウント、複数のVPC、複数のサブネットを運用する組織では、時間が経つにつれて例外設定が蓄積されます。
代表的な例は以下の通りです。
- 最初はテスト用に開けていたポート
- 一時的に作成されたVPC Peering接続
- 削除されていないセキュリティグループルール
- 運用移管中に残ったパブリックアクセス経路
- 不必要に広いCIDR許可
- 一時的なVPN接続
- 不必要に残ったTransit Gatewayルーティング
このような設定は、ドキュメントには残らず、実際の環境にのみ残ることが多いです。
Network Access Analyzerは、このような隠れたアクセス経路を見つけるのに役立ちます。
VPCセキュリティは一度構成して終わりではありません。
定期的に「現在、私たちのネットワークは意図した通りにのみ開かれているか？」を検証する必要があります。
12. DNSセキュリティとRoute 53 Resolverベースの制御
ネットワークセキュリティにおいて、IPとポートだけを見るのは不十分です。
実際のマルウェアや内部システムは、ドメイン名を介して外部と通信することが多いです。
したがって、DNSリクエストを制御し、記録することも重要です。
AWS環境では、以下の機能を活用できます。
- Route 53 Resolver Query Logs
- Route 53 Resolver DNS Firewall
- Network Firewall
- プロキシベースのドメイン制御
例えば、内部EC2が突然疑わしいドメインを照会した場合、マルウェア感染やデータ流出の試みを疑うことができます。
また、社内ポリシーで許可されていないドメインへのリクエストを遮断することも可能です。
DNSセキュリティは、特に出ていく通信のセキュリティと深く関連しています。
セキュリティグループで443番ポートを開放しただけでは、どのドメインにアクセスしているかを知ることは困難です。
Network Firewall、プロキシ、DNS Firewall、Resolver Query Logsを組み合わせて使用することで、外部通信をよりよく理解し、制御できます。
13. VPCセキュリティのための実務設計例
セキュリティが適切に構成された一般的な3層ウェブサービス構造を考えてみましょう。
パブリックサブネット
パブリックサブネットには、外部と直接接続する必要があるリソースのみを配置します。
- ALB
- NATゲートウェイ
- Bastion HostまたはSession Manager代替構成
プライベートアプリケーションサブネット
プライベートアプリケーションサブネットには、実際のアプリケーションワークロードを配置します。
- EC2
- ECS Service
- EKS Worker Node
- アプリケーションサーバー
- 内部APIサーバー
プライベートデータサブネット
プライベートデータサブネットには、外部に直接公開されてはならないデータ層を配置します。
- RDS
- ElastiCache
- OpenSearch
- 内部専用データストア
この構造におけるセキュリティフローは以下の通りです。
사용자
-> ALB
-> 애플리케이션 서버
-> 데이터베이스セキュリティ設計は以下のように適用できます。
- ユーザーはALBの443番ポートのみにアクセスします。
- ALBはアプリケーションサーバーの特定のポートのみにアクセスします。
- アプリケーションサーバーはデータベースの特定のポートのみにアクセスします。
- データベースはインターネットに直接公開されません。
- プライベートサーバーのインターネットアウトバウンドは、NATゲートウェイまたはNetwork Firewallを介して制御します。
- S3、DynamoDB、ECR、Secrets Manager、Systems Managerへのアクセスは、可能な限りVPCエンドポイントを使用します。
- VPCフローログでネットワークフローを記録します。
- Reachability AnalyzerとNetwork Access Analyzerで意図しない経路を点検します。
この構造の核心は、すべてのリソースを厳しくブロックするのではなく、必要なフローだけを明確に開けておくことです。
セキュリティは「すべて遮断」ではありません。サービスが正常に動作するために必要な経路のみを許可し、残りは開かないことです。
14. よく発生するVPCセキュリティのミス
実務でよく見られるVPCセキュリティのミスは以下の通りです。
1. SSHとRDPを0.0.0.0/0で開けておく
最も一般的で危険な設定です。
運用環境では、AWS Systems Manager Session Managerを使用するか、制限されたVPNまたは社内IPからのみアクセスするように構成することをお勧めします。
2. RDSをパブリックにする
RDSはほとんどの場合、インターネットに直接公開される必要はありません。
アプリケーションサーバーからのみアクセスできるように構成する必要があります。
3. すべてのアウトバウンドを無条件に許可する
デフォルトのセキュリティグループ設定のため、すべてのアウトバウンドが許可された状態で運用されることが多いです。
しかし、重要なシステムでは、どこに出ることができるかも制御する必要があります。
4. VPCフローログを有効にしない
事故が発生した後にログがないと、分析が非常に困難になります。
コストを考慮しても、重要な区間には必ずログを残すことをお勧めします。
5. VPCエンドポイントを使用しなくてもよいと考える
S3、DynamoDB、ECR、Secrets ManagerなどのサービスアクセスをインターネットまたはNATゲートウェイに依存すると、不必要な外部経路とコストが発生する可能性があります。
6. セキュリティグループ名だけを見て安全だと判断する
private-sg、db-sg、secure-sgのような名前がついていても、実際のルールが開いていると危険です。
名前ではなく、実際のインバウンド、アウトバウンドルールを確認する必要があります。
15. VPCセキュリティチェックリスト
運用環境でVPCを点検する際は、以下の項目を確認すると良いでしょう。
[ ] 퍼블릭 서브넷과 프라이빗 서브넷이 명확히 분리되어 있는가?
[ ] 데이터베이스가 퍼블릭 서브넷에 있지 않은가?
[ ] 라우트 테이블에 불필요한 0.0.0.0/0 경로가 없는가?
[ ] SSH, RDP가 전체 인터넷에 열려 있지 않은가?
[ ] 보안 그룹이 다른 보안 그룹을 참조하도록 설계되어 있는가?
[ ] Network ACL이 의도치 않게 너무 넓게 열려 있거나 너무 강하게 막혀 있지 않은가?
[ ] 프라이빗 리소스의 AWS 서비스 접근에 VPC Endpoint를 사용하고 있는가?
[ ] S3 버킷 정책에서 특정 VPC Endpoint 조건을 사용할 수 있는가?
[ ] VPC Flow Logs가 활성화되어 있는가?
[ ] Flow Logs가 S3 또는 CloudWatch Logs로 적절히 저장되고 있는가?
[ ] Network Firewall 또는 egress filtering이 필요한 환경인가?
[ ] Reachability Analyzer로 주요 경로를 검증했는가?
[ ] Network Access Analyzer로 의도하지 않은 인터넷 노출 경로를 점검했는가?
[ ] Transit Gateway, VPC Peering, VPN 연결로 인해 내부망이 과도하게 연결되어 있지 않은가?
[ ] 보안 그룹과 라우트 테이블 변경 이력이 관리되고 있는가?このチェックリストを見ればわかるように、VPCセキュリティは単一の機能一つで完成するものではありません。
複数の機能を組み合わせて階層的に構成する必要があります。
16. VPCセキュリティを一枚にまとめると
VPCセキュリティ機能を役割別に整理すると以下の通りです。
| 領域 | 主要機能 | セキュリティ目的 |
|---|---|---|
| ネットワーク分離 | VPC、サブネット | パブリック/プライベート領域の分離 |
| 経路制御 | ルートテーブル | トラフィック移動経路の制御 |
| リソースファイアウォール | セキュリティグループ | インスタンス、DB、ALB単位のアクセス制御 |
| サブネットファイアウォール | ネットワークACL | サブネット単位の許可/遮断 |
| インターネット接続 | インターネットゲートウェイ、NATゲートウェイ | 外部接続構造の分離 |
| プライベートAWSサービス接続 | VPCエンドポイント、PrivateLink | インターネットを経由しないAWSサービスアクセス |
| 高度なファイアウォール | AWS Network Firewall | アウトバウンド制御、IDS/IPS、ドメインフィルタリング |
| フローログ | VPC Flow Logs | ネットワーク通信記録 |
| パケット分析 | Traffic Mirroring | パケットレベルのセキュリティ分析 |
| 経路検証 | Reachability Analyzer | 特定経路の到達可能性検証 |
| 露出分析 | Network Access Analyzer | 意図しないアクセス経路の検出 |
| DNSセキュリティ | Route 53 Resolver Query Logs, DNS Firewall | ドメインベースの通信記録および遮断 |
—
まとめ: VPCセキュリティは「構造設計」である
AWS VPCセキュリティは、単にファイアウォールルールを作成する作業ではありません。
ネットワーク構造を設計する作業です。
パブリックとプライベートを分け、ルーティングを制御し、セキュリティグループでリソース間の通信を制限し、ネットワークACLでサブネット単位の補助的な防御線を作り、VPCエンドポイントでインターネット経路を減らし、Network Firewallで高度なトラフィック制御を行い、フローログとトラフィックミラーリングで可視性を確保し、Reachability AnalyzerとNetwork Access Analyzerで意図しない経路を検証する必要があります。
良いVPCセキュリティ設計は複雑に見えますが、原則は単純です。
- 外部に公開するものは最小限にする。
- 内部通信も必要な対象同士のみ許可する。
- インターネットに出る経路も制御する。
- すべての重要なトラフィックフローは記録する。
- 設定が意図した通りに動作するか定期的に検証する。
クラウドでは、数回のクリックでネットワークが開きます。
そのため、セキュリティ事故も数回のクリックで始まる可能性があります。
逆に言えば、VPCセキュリティ機能を正しく理解し、組み合わせることで、多くの事故を事前に防ぐことができます。
AWSセキュリティの最初の防御線はIAMだけではありません。
安全に設計されたVPCも非常に強力な最初の防御線です。
参考文献
- AWS VPC Security
- Security groups for your VPC
- Control traffic to subnets using Network ACLs
- VPC Flow Logs
- AWS PrivateLink and VPC endpoints
- AWS Network Firewall
- Reachability Analyzer
- Network Access Analyzer
コメントを残す