はじめに
金融IT本部 2年目の坂江 克斗です。
ネットワーク分野に興味があり、業務を進めていくうちにネットワークセキュリティに関して腹落ちする部分が増えてきたため、概要をまとめて記事にしました。
初学者の視点で疑問に感じる部分も含め、基本的な概念から丁寧に解説できればと思います。
経歴
セキュリティの中でのネットワークの位置づけ
実際にハマったポイントを基に、ネットワークセキュリティの基本的な考え方を整理します。
※ 実際は、コストや非機能要件によって実装すべきセキュリティレベルや内容を設定するものなので、あくまで学習の流れとして捉えていただけると嬉しいです
ふわっとした疑問
AWS資格の勉強を始めてから、セキュリティ強化の方法について考える機会が増えました。
AWSでセキュリティを高める手段として、例えば以下のようなものが思い浮かびます。
- IAMの権限を最小限にする
- セキュリティグループの許可ルールを絞る
- WAFを導入する
- ACMで証明書を発行してSSL接続を有効化する
- RDSを暗号化する
- Secrets Managerに機密情報を保存する
- etc...
一見すると、これらはすべて「セキュリティ対策」として並列に扱われがちですが、 実際に設計や運用を考えると 「どのサービスを、どんな場面で使い分けるべきか？」 という疑問が生じやすいと感じています。
例えば、DBの暗号化や機密情報の専用サービスによる管理はイメージしやすいですが、 アクセス制御に関しては次のような疑問が出てきます。
- IAMとセキュリティグループはどちらも「アクセス制御」の役割があるように見えるが、どちらか一方だけで十分なのでは？
- セキュリティグループはファイアウォールの役割を果たしているが、AWS WAFも「ファイアウォール」と名が付いている。両方必要なの？
このような疑問の根本的な原因は、「各AWSサービスが、アクセス時に発生する通信のどのレイヤーでセキュリティを提供しているのか」 を十分に理解できていないことにあります。
この点を整理するためには、基本情報技術者試験などでも学ぶ OSI参照モデルの考え方 が非常に役立ちます。
レイヤーの考え方
OSI参照モデルは、ネットワーク通信を7つの階層に分けて理解するためのフレームワークです。
例えば、セキュリティグループはファイアウォールとしてIPアドレスやポートに基づくフィルタリングを行うため、ネットワーク層・トランスポート層（第3・4層）に該当します。一方、IAMは認証・認可を担い、HTTPやHTTPSなどのアプリケーション層（第7層）で制御を行います。
パケットは低層のレイヤーから順に評価されるため、セキュリティグループ（第3・4層）でパケットを拒否した場合、IAM（第7層）による認証・認可は実行すらされません。イメージとしては、山から下りてくるクマを堰き止めるのがセキュリティグループで、街に降りてきたクマの中でも家や畑に侵入してくる（特定の行動をする）クマだけを止めるのがIAMとなります。
ただし、低層のネットワークで排除する = 上層のセキュリティが不要なわけではなく、ネットワークだけでは管理できない処理（リソースには到達できるが、削除処理は拒否したい等）や 多層防御 の考え方が重要となります。
クラウド環境では、物理的なサーバ管理等はクラウドプロバイダー側の責務となり、ユーザは主にネットワーク層（第3層）から上位のレイヤーを制御するため、ネットワークセキュリティが最も根本的かつ重要な防御レイヤーとなります。
現在の私自身の考えとしては、ネットワークセキュリティは 第2～4層で管理するリソースへの到達・接続可否の判定や、第2～7層における通信の暗号化、認証・認可 (段階的な権限管理)というよりは単純な評価・振り分けに留まる7層までの判定が主と捉えています。
一方で、IAMはネットワークセキュリティとは異なり、認証・認可や運用面での権限管理を目的としたサービスであると考えています。
AWSにおけるネットワークセキュリティ
前提
繰り返しになりますが、物理的な配線・サーバ管理等はAWS側の責務となります。 AWSが提供するグローバルネットワークでは、有線接続かつ多段階の暗号化による通信保護も提供されており、AWSのネットワーク内では 高速かつセキュア な通信を提供しています。
通常、VPCでデプロイしたパブリックIPアドレスにアクセスする場合、ユーザーの通信はインターネット上のさまざまな外部ネットワークを経由してAWSに到達します。
この経路は、距離やネットワーク状況によって遅延やセキュリティリスクが発生することがあります。
一方、AWS Global Acceleratorを利用すると、Anycast IPアドレスを持つ専用のエンドポイントが世界中に配置されます。
ユーザーは最寄りのエンドポイントにアクセスすることで、通信がすぐにAWSのグローバルネットワークに入り、その後はAWS内部の高速かつセキュアなネットワークを通じて目的のリソースに到達します。
これにより、
- 通信経路の最適化による遅延の減少
- 外部ネットワークを極力避けることによるセキュリティ向上
が実現できます。
代表的なAWSサービス
基本的なネットワークセキュリティの概念および対応する代表的なAWSサービスは、以下のように分類できます。
| カテゴリ | サービス / 機能 | レイヤー | 説明・具体例 |
|---|---|---|---|
| セグメント分割 | Amazon VPC（サブネット、ルートテーブル） | 3 | サブネットを役割ごとに分割し、ルートテーブルで通信経路を制御します。 必要なリソース数に応じて適切なサイズのCIDRブロックを割り当て、ルートテーブルでサブネットの通信経路を制限します。 |
| ファイアウォール | ネットワークACL | 3~4 | サブネット単位で設定するステートレス型のフィルタ。送信・受信を個別に判定し、帰り通信ではエフェメラルポートに注意が必要です。 |
| セキュリティグループ | 3~4 | リソース単位で設定するステートフル型のフィルタ。送信が許可されていれば戻り通信も自動的に許可され、IPアドレス・ポートだけでなく他のセキュリティグループも対象に設定できます。 | |
| IDS / IPS（不正侵入検知・防止） | AWS Network Firewall | 3~7 | パケットインスペクションによりトラフィックを制御。高度なルール設定により、ファイアウォールより柔軟な制御が可能です。 |
| AWS Gateway Load Balancer | 3~7 | サードパーティ製のIDS/IPSに中継するためのトンネリングを提供します。Network Firewallも本サービスを内部で使用し動作します。 | |
| NATによるIP秘匿 | NATゲートウェイ / NATインスタンス | 3~4 | 外部から隔離されたプライベートサブネット内のリソースが、外部通信を行う際に自身のIPを秘匿しつつ通信可能にします。 |
| EC2/Fargateによる自作NATインスタンス | 3~4 | カスタム構成によるNAT。セキュリティ設定や運用管理が必要です。 | |
| プロキシによる通信制御・中継 | ALB (Application Load Balancer) | 7 | 負荷分散および7層情報を基にしたルーティングが目的となります。ネットワーク面では、内部通信を中継することで内部リソースを外部ネットワークから隔離できます。 |
| API Gateway | 7 | クライアントのAPIリクエストを受け取り、バックエンドへ中継します。ネットワーク面では、内部通信を中継することで内部リソースを外部ネットワークから隔離できます。 | |
| EC2/Fargateによる自作プロキシ | 7 | nginxなどを利用して独自に構成するプロキシ。柔軟な通信制御や迅速なログ取得が可能です。 | |
| 暗号化・署名 | MACsec | 2 | ネットワークフレームを暗号化し、2層での盗聴や改ざんを防止します。AWSではDirect Connectで使用可能です。 |
| VPN (IPsec等) | 3 or 4 | トンネルモードでは第3層以上、トランスポートモードでは第4層以上を暗号化します。AWSではClient VPNやSite-to-Site VPNもしくは、EC2等で独自構成することが可能です。 | |
| TLS / SSL | 4,7の間 | AWSではACMにより証明書の発行・管理を行い、ALBやCloudFront、RDS等に証明書を設定することで、HTTPS通信を実現できます。 | |
| DNSSEC | - | Route53で設定可能。DNS応答に署名検証を追加し、改ざんやなりすましを防止します。 | |
| セキュリティ攻撃からの防御 | AWS Shield | 3~4 or 3~7 | DDoS攻撃からの防御を提供するマネージドサービス。Standardは第3~4層、Advancedは第7層まで対応し保護します。インバウンド専用。 |
| AWS WAF | 3~7 | HTTP/HTTPS通信のペイロードを確認し、SQLインジェクションやXSSなどの攻撃を防御します。IPやアクセスレート、地理ベースでの防御も可能です。インバウンド専用。 | |
| 包括的サービス | Amazon GuardDuty | - | 各種ログを分析し、異常な挙動や脅威を検知します。 |
| AWS Security Hub | - | 各AWSサービスのセキュリティ情報を集約し、AWS推奨構成との整合性を評価します。 | |
| AWS Shield Network Security Director | - | ネットワーク構成の脆弱性を包括的に評価し、リスクを可視化します。 | |
| その他 | VPC Endpoint | 3~7 | 外部ネットワークにアクセスせずに、VPC内部からAWSサービスにアクセス可能。 エンドポイントポリシーにより、権限的なアクセス管理も可能。 |
各サービスは、その設計目的や役割の違いにより、 インバウンド/アウトバウンド通信の制限、構築・運用負荷、レイヤーの違い 等の特性が異なります。 また、同じレイヤーに位置するサービスであっても、評価や制御が行われるタイミングが異なる場合があります。 そのため、これらの特性を正しく理解したうえで、非機能要件やコストに応じて適切に組み合わせることが重要です。
構成例 (外部公開するWebアプリケーション)
前節で紹介したネットワークセキュリティの考え方を踏まえ、AWS上で外部公開するWebアプリケーションの構成例を図示します。
| カテゴリ | 説明・具体例 |
|---|---|
| セグメント分割 | サブネットを「パブリック」「Network Firewall」「アプリケーション」「データベース」など役割ごとに分割し、不要な経路を遮断。最小限の通信経路だけを許可します。 |
| ファイアウォール | ネットワークACLやセキュリティグループで、サブネットやリソースごとに通信元・通信先・ポートを制限。図の矢印の経路以外は遮断します。 |
| IDS / IPS（不正侵入検知・防止） | 外部へのアウトバウンド通信時に、ファイアウォールだけでは防げないドメインベースのフィルタや不正な通信の検知・遮断を実施。 |
| NATによるIP秘匿 | アプリケーション（ECS/Fargate）が外部サービスへアクセスする際、NATゲートウェイを経由してプライベートIPを隠蔽しつつ通信します。 |
| プロキシによる通信制御・中継 | ALB（Application Load Balancer）が外部からの入口となり、アプリケーション本体（ECS/Fargate）は直接インターネットに公開しません。 |
| 暗号化・署名 | ALBにSSL/TLS証明書を設定し、クライアント~ALB間の通信を暗号化。盗聴や改ざんを防ぎます。 |
| セキュリティ攻撃からの防御 | AWS WAFやAWS Shieldでインバウンド通信におけるDDoSやWebアプリケーションへの攻撃（SQLインジェクション、XSS等）を防御します。 |
今回は自分に馴染みのあるAWS構成図をピックアップしましたが、例えば要件に合わせて以下のように更新することもできます。
- 外部サービスへのアクセス制限が不要な場合は、Network Firewallを導入せずにNACLやセキュリティグループのみで構成する。
- 社内プロキシからのアクセスに限定したい場合は、プロキシのグローバルIPアドレスを基に、AWS WAFのIPセットやファイアウォールで制限をかける。
おわりに
今回の記事を通じて、ネットワーク分野に興味を持つ方が少しでも増えれば嬉しいです。 私自身まだまだ知らないことばかりなので、今後もこのような形でアウトプットしながら、使用方法だけでなく基本的な概念も含めて理解を深めていきたいと思います。
