Day 24: データベースのセキュリティ：VPC、セキュリティグループ、ネットワークACL
皆さん、こんにちは！「AWSデータベース・ストレージ完全攻略」のDay 24へようこそ！
昨日のDay 23では、AWSのアクセス管理の中核であるIAMと、各データベース・ストレージサービスへのアクセス制御について学びました。IAMは「誰が、何に、何ができるか」を制御する認証・認可の仕組みですが、もう一つ、AWS環境のセキュリティを語る上で欠かせない要素があります。それは、ネットワークレベルのセキュリティです。
AWSクラウドでは、ほとんどのリソースが仮想ネットワークであるAmazon Virtual Private Cloud (VPC) 内にデプロイされます。今日のDay 24では、このVPCと、その中でリソース間のトラフィックを制御する主要なセキュリティ機能、セキュリティグループとネットワークACL (NACL) に焦点を当てます。これらがデータベースやストレージのセキュリティをどのように強化するのかを詳しく見ていきましょう。
1. なぜネットワークセキュリティが必要なのか？
IAMはアプリケーションやユーザーがAPIを介してリソースを操作する際の認証・認可を制御しますが、ネットワークセキュリティは、特定のIPアドレスやポートからの通信を許可または拒否することで、リソースへのネットワークレベルでのアクセスを制限します。
たとえIAMでアクセスが許可されていても、ネットワークレベルでアクセスがブロックされていれば、通信は確立されません。この多層防御の考え方が、クラウドセキュリティの基本です。
ネットワークセキュリティの重要性：
- 不正アクセスからの保護: 外部からの不正な接続やポートスキャンなどをブロックし、データベースやストレージへの攻撃経路を遮断する。
- 内部からの誤操作/悪意のあるアクセス制限: 許可されていないVPC内のリソースや、特定のサブネットからの通信を制限し、内部からのセキュリティリスクを低減する。
- コンプライアンス要件: 多くの規制要件において、ネットワークセグメンテーションやアクセス制御が求められる。
- 攻撃対象領域の削減: 必要最低限のポートとプロトコルのみを開放することで、攻撃者が利用できる脆弱性を減らす。
2. Amazon Virtual Private Cloud (VPC) の基本
Amazon VPCは、AWSクラウド内で論理的に分離された独自の仮想ネットワークを構築するためのサービスです。VPCを構築することで、オンプレミスデータセンターでネットワークを構成するのと同様に、IPアドレス範囲、サブネット、ルートテーブル、ネットワークゲートウェイなどを完全に制御できます。
VPCの主要コンポーネント：
-
VPC (Virtual Private Cloud):
- AWSアカウント専用の分離された仮想ネットワーク。
- CIDRブロック（IPアドレス範囲）を指定して作成します（例:
10.0.0.0/16）。 - デフォルトVPCが各リージョンに用意されていますが、通常はカスタムVPCを作成してより詳細な制御を行います。
-
サブネット (Subnets):
- VPCのIPアドレス範囲をさらに分割した論理的なセグメント。
- 通常、可用性を高めるために、異なるアベイラビリティゾーン (AZ) にサブネットを作成します。
- パブリックサブネット: インターネットゲートウェイへのルートを持ち、インターネットからのアクセスを許可する（Webサーバーなど）。
- プライベートサブネット: インターネットゲートウェイへのルートを持たず、インターネットからの直接アクセスを許可しない（データベースなど）。
-
インターネットゲートウェイ (Internet Gateway - IGW):
- VPC内のリソースがインターネットと通信できるようにするゲートウェイ。パブリックサブネットに関連付けられます。
-
NATゲートウェイ (NAT Gateway) / NATインスタンス:
- プライベートサブネット内のリソースがインターネット（例: OSアップデート、外部APIアクセス）にアクセスできるようにするが、インターネットからは直接アクセスさせないためのサービス/インスタンス。
-
ルートテーブル (Route Tables):
- サブネットからのネットワークトラフィックのルーティングルールを定義します。
-
VPCエンドポイント (VPC Endpoints):
- インターネットを経由せずに、VPCからAWSサービス（S3、DynamoDB、KMSなど）にプライベートに接続するためのインターフェース。これにより、セキュリティとパフォーマンスが向上します。
データベースとストレージのデプロイ戦略：
- データベースインスタンス（RDS, Aurora, Redshift, DynamoDB (VPCエンドポイント経由), Neptune, DocumentDBなど）は、常にプライベートサブネットにデプロイするべきです。 これにより、インターネットからの直接アクセスが遮断され、データベースのセキュリティが大幅に向上します。
- アプリケーションサーバーはパブリックサブネットまたはプライベートサブネット（NAT経由でインターネットアクセス）にデプロイし、データベースにはプライベートIPアドレス経由で接続させます。
3. セキュリティグループ (Security Groups)
セキュリティグループは、EC2インスタンス、RDSインスタンス、ElastiCacheクラスター、Redshiftクラスターなど、リソースレベルでトラフィックを制御するステートフルな仮想ファイアウォールです。
セキュリティグループの主な特徴：
-
ステートフル (Stateful):
- インバウンドルール（外から中への通信）を許可すると、対応するアウトバウンドルール（中から外への通信）が自動的に許可されます。例えば、TCP 80番ポートへのインバウンドアクセスを許可すると、TCP 80番ポートからのアウトバウンド応答も自動的に許可されます。
-
許可ルールのみ:
- デフォルトではすべてのインバウンドトラフィックを拒否し、すべてのアウトバウンドトラフィックを許可します。
- 明示的に許可するルールのみを追加します（拒否ルールは作成できません）。
-
インスタンスレベルでの適用:
- 個々のEC2インスタンスやDBインスタンスにアタッチされます。同じセキュリティグループを複数のインスタンスに適用することも可能です。
-
ルール定義:
- タイプ (Type): プロトコル（TCP, UDP, ICMPなど）
- ポート範囲 (Port Range): ポート番号または範囲（例: 3306 (MySQL), 5432 (PostgreSQL), 80, 443）
-
ソース/送信元 (Source/Destination): 許可するトラフィックの送信元（IPアドレス、CIDRブロック、または別のセキュリティグループID）。
- ベストプラクティス: 厳密なIPアドレスではなく、別のセキュリティグループIDをソースとして指定することで、そのセキュリティグループに属するインスタンスからのアクセスのみを許可できます。これにより、EC2インスタンスのIPアドレスが変わってもルールを更新する必要がなくなります。
データベース・ストレージにおけるセキュリティグループの活用：
-
RDS/Aurora/Redshift/Neptune/DocumentDB:
- データベースインスタンスにアタッチし、アプリケーションサーバーのセキュリティグループからの特定のデータベースポート（例: MySQL:3306, PostgreSQL:5432, Redshift:5439, Neptune:8182）へのインバウンドアクセスのみを許可します。
- 管理ツール（SQL Client）を使用する開発者や管理者の固定IPアドレスからのアクセスのみを許可する場合もあります。
-
ElastiCache:
- キャッシュクラスターにアタッチし、アプリケーションサーバーのセキュリティグループからのRedis/Memcachedポート（例: Redis:6379, Memcached:11211）へのインバウンドアクセスのみを許可します。
-
S3/DynamoDB (VPCエンドポイント使用時):
- VPCエンドポイント自体に関連付けられたセキュリティグループで、VPCエンドポイントへのアクセスを許可するソース（例: アプリケーションサーバーのセキュリティグループ）を制御します。これにより、S3/DynamoDBへのトラフィックをさらに制限できます。
-
FSx/EFS:
- ファイルシステムへのマウントアクセスを許可するクライアントEC2インスタンスのセキュリティグループからのインバウンドアクセスを制御します。
4. ネットワークACL (Network Access Control Lists - NACLs)
ネットワークACL (NACL) は、サブネットレベルでトラフィックを制御するステートレスな仮想ファイアウォールです。セキュリティグループよりも粗い粒度で、より厳密な制御が可能です。
NACLの主な特徴：
-
ステートレス (Stateless):
- インバウンドルールとアウトバウンドルールを個別に定義する必要があります。例えば、インバウンドでTCP 80番ポートを許可した場合でも、アウトバウンドでTCP 80番ポートを明示的に許可しないと、応答トラフィックがブロックされます。
-
許可と拒否ルール:
- セキュリティグループとは異なり、明示的に許可 (ALLOW) するルールと、明示的に拒否 (DENY) するルールの両方を作成できます。
- ルールは番号が小さい順に評価され、一致したルールが適用されます。ルールリストの末尾には、デフォルトで明示的に許可されていないすべてのトラフィックを拒否する暗黙的な拒否ルールがあります。
-
サブネットレベルでの適用:
- サブネット全体にアタッチされます。そのサブネット内のすべてのインスタンスに影響します。
セキュリティグループとNACLの比較：
| 特徴 | セキュリティグループ (Security Group) | ネットワークACL (Network ACL) |
|---|---|---|
| 適用範囲 | インスタンスレベル | サブネットレベル |
| ステート | ステートフル (Stateful) | ステートレス (Stateless) |
| ルールタイプ | 許可ルールのみ | 許可と拒否ルール |
| デフォルト動作 | すべて拒否、すべて許可（アウトバウンド） | すべて許可 (カスタムNACLはすべて拒否) |
| 評価順序 | 全てのルールが評価される | ルール番号の小さい順に評価される |
| 推奨ユースケース | ほとんどのアクセス制御に利用。よりきめ細やか。 | サブネット間のトラフィックフィルタリング、追加の防御層。 |
データベース・ストレージにおけるNACLの活用：
- セキュリティグループは通常、ほとんどのユースケースで十分な保護を提供します。NACLは、追加の防御層として、または非常に厳格なコンプライアンス要件がある場合に検討されます。
- 多層防御: データベースをデプロイするプライベートサブネットに対して、アプリケーションサブネットからの特定のポートへのアクセスのみを許可し、他のサブネットからのアクセスを拒否するNACLを設定できます。
- IPアドレスベースのブロック: 特定の悪意のあるIPアドレス範囲からのアクセスをサブネット全体で拒否するといった目的にも利用できます。
5. AI企業におけるネットワークセキュリティのベストプラクティス
AI企業では、大量の機密データや高負荷な計算リソースを扱うため、ネットワークセキュリティは特に重要です。
-
データベースは常にプライベートサブネットにデプロイ:
- 学習データが保存されるデータベース（RDS, DynamoDB, Redshift）や、推論結果が書き込まれるデータベースなどは、インターネットから直接アクセスできないプライベートサブネットに配置する。
-
最小特権の原則をネットワークにも適用:
- セキュリティグループで、アプリケーションサーバー、BIツール、データサイエンティストの作業環境など、必要なソースIPアドレスやセキュリティグループからのみ、必要なデータベースポートへのアクセスを許可する。
0.0.0.0/0（全IPアドレスからのアクセス）は原則避ける。
- セキュリティグループで、アプリケーションサーバー、BIツール、データサイエンティストの作業環境など、必要なソースIPアドレスやセキュリティグループからのみ、必要なデータベースポートへのアクセスを許可する。
-
VPCエンドポイントの積極的な活用:
- S3（学習データ、モデルアーティファクト）、DynamoDB（特徴量ストア、推論ログ）、KMS（暗号化キー）など、AWSサービスへのアクセスは、インターネットゲートウェイを経由せず、VPCエンドポイントを介してプライベートに行う。これにより、データの公開範囲を最小限に抑え、セキュリティとパフォーマンスを向上させる。
-
セキュリティグループとNACLの連携（必要に応じて）:
- 基本的なアクセス制御はセキュリティグループで行い、さらに厳格な層が必要な場合や、明確な拒否ルールが必要な場合にNACLを導入する。例えば、データレイクのサブネットは、データの取り込みと分析に必要なトラフィックのみを許可し、その他すべての通信をNACLで拒否する。
-
ネットワーク分離とセグメンテーション:
- 本番環境、開発環境、テスト環境を異なるVPCまたは異なるサブネットに分離し、VPC PeeringやTransit Gatewayを使って必要な通信のみを許可する。
- データベース層、アプリケーション層、Web層を異なるサブネットに配置し、それぞれの間に適切なセキュリティグループとNACLを設定する。
-
VPCフローログの活用:
- VPC内のIPトラフィックに関する情報をキャプチャし、S3やCloudWatch Logsに公開するVPCフローログを有効にする。これにより、不正なネットワークアクティビティや通信の問題を検出・診断できる。
-
定期的なセキュリティグループ/NACLルールのレビュー:
- 設定ミスや不要なポートの開放がないかを定期的に監査し、削除する。AWS ConfigやAWS Security Hubなどのサービスを活用することも有効です。
まとめとDay 25への展望
今日のDay 24では、AWSにおけるデータベース・ストレージのネットワークセキュリティの基礎として、Amazon VPC、セキュリティグループ、そしてネットワークACL (NACL) について深く学びました。
- VPCがAWSクラウド内の論理的に分離された仮想ネットワークであり、データベースをプライベートサブネットにデプロイすることが推奨されること。
- セキュリティグループがリソースレベルのステートフルな仮想ファイアウォールであり、必要なポートとソースIP/セキュリティグループからのアクセスのみを許可すること。
- NACLがサブネットレベルのステートレスな仮想ファイアウォールであり、許可/拒否ルールを番号順に評価すること。
- VPCエンドポイントの活用や、VPCフローログによる監視など、AI企業におけるネットワークセキュリティのベストプラクティス。
IAMによる認証・認可と、VPC、セキュリティグループ、NACLによるネットワークレベルの制御は、AWSにおける多層防御戦略の重要な柱です。これらを適切に組み合わせることで、強固なセキュリティ基盤を構築し、AI資産を安全に保護できるでしょう。
さて、これでネットワークセキュリティの重要な概念もカバーしました。明日のDay 25からは、これまでのデータベース・ストレージの知識を総動員して、AI/MLのユースケースに特化したデータ戦略を具体的に掘り下げていきます。まずは、AI/MLにおけるデータ戦略の全体像から見ていきましょう。
それでは、また明日お会いしましょう！