LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@555hamano(Akr)

実践！AWSネットワーク構築・運用30日チャレンジ: Day 6

Posted at

Day 6: セキュリティグループとNACL：多層防御の実現

皆さん、こんにちは！「実践！AWSネットワーク構築・運用30日チャレンジ」のDay 6へようこそ！

これまでの5日間で、VPC、サブネット、インターネットゲートウェイ、ルートテーブルといったAWSネットワークの骨格となる部分を構築し、その概念を深く理解してきました。これらの基盤がしっかりしていれば、ネットワークの通信経路は確保されますが、本当に重要なのは「誰が、何に、どのようにアクセスできるのか？」というセキュリティの側面です。

今日は、AWSネットワークセキュリティの要となる「セキュリティグループ (Security Group - SG)」と「ネットワークACL (Network Access Control List - NACL)」に焦点を当てます。これらを適切に設定することで、あなたのAWS環境を外部の脅威から守り、安全なシステムを運用するための「多層防御」を実現する極意を学び、実践していきます。

_- visual selection (1).png

1. ネットワークセキュリティの重要性：なぜ「多層防御」が必要なのか？

「セキュリティは後回し」と考えてはいけません。特に外資系AI企業では、顧客データや学習モデルといった機密性の高い情報を扱うことが多く、セキュリティ対策はビジネスの生命線です。

AWSでは、多層的なセキュリティモデルが推奨されています。これは、たとえ一つの防御層が破られても、次の層で脅威を食い止めるという考え方です。セキュリティグループとNACLは、この多層防御において異なるレベルで重要な役割を担います。

  • SG (セキュリティグループ): インスタンスレベルのファイアウォール。特定のインスタンスへの通信を制御します。
  • NACL (ネットワークACL): サブネットレベルのファイアウォール。サブネット全体への通信を制御します。

これらを適切に組み合わせることで、より堅牢なネットワークセキュリティを確立できます。

2. セキュリティグループ (Security Group - SG) の徹底理解と実践

セキュリティグループは、AWSで最も頻繁に利用されるセキュリティ機能の一つです。

2.1. セキュリティグループの基本と特徴（再確認）

  • インスタンスにアタッチ: EC2インスタンスやRDSデータベースなど、個々のリソースに関連付けます。
  • ステートフル: インバウンドルールで許可された通信の応答は、アウトバウンドルールに関わらず自動的に許可されます。例えば、Webサーバーが受信したHTTPリクエストに対する応答は、明示的なアウトバウンドルールがなくても外部へ送信されます。
  • 許可 (Allow) のみ: 明示的に許可したトラフィックのみを通します。拒否ルールは設定できません。
  • デフォルトは全て拒否 (インバウンド): インバウンド（受信）トラフィックは、デフォルトでは全て拒否されます。必要なポート（SSH: 22, HTTP: 80, HTTPS: 443など）を明示的に許可する必要があります。
  • デフォルトは全て許可 (アウトバウンド): アウトバウンド（送信）トラフィックは、デフォルトでは全て許可されます。通常はこのままで問題ありませんが、厳格な制御が必要な場合は変更します。

2.2. セキュリティグループの作成とルール設定

それでは、実際にWebサーバーとアプリケーションサーバー用のセキュリティグループを作成してみましょう。

  1. AWSマネジメントコンソールにログインし、「VPC」サービスを開きます。
  2. 左側ナビゲーションペインから「セキュリティグループ」をクリックします。
  3. 「セキュリティグループを作成」ボタンをクリックします。

2.2.1. Webサーバー用セキュリティグループの作成

インターネットからのHTTP/HTTPSアクセスと、SSHでの管理アクセスを許可するSGを作成します。

  • 基本詳細:
    • セキュリティグループ名: web-server-sg (分かりやすい名前に)
    • 説明: Allow HTTP/HTTPS/SSH to web servers
    • VPC: 昨日までに作成したあなたのVPCを選択します。
  • インバウンドルール:
    • ルールを追加
      • タイプ: HTTP
      • ソース: Anywhere-IPv4 (0.0.0.0/0) (インターネットからのHTTPアクセスを許可)
    • ルールを追加
      • タイプ: HTTPS
      • ソース: Anywhere-IPv4 (0.0.0.0/0) (インターネットからのHTTPSアクセスを許可)
    • ルールを追加
      • タイプ: SSH
      • ソース: My IP または あなたのオフィス/自宅の固定IPアドレス
        • ポイント: SSHは管理用アクセスなので、0.0.0.0/0 (どこからでも) は絶対に避けてください。特定のIPアドレスからのアクセスのみに限定することで、不正アクセスリスクを大幅に低減できます。My IP を選択すると、今アクセスしているグローバルIPアドレスが自動で設定されます。
  • アウトバウンドルール:
    • デフォルトの All traffic | 0.0.0.0/0 (全て許可) のままでOKです。
  • 「セキュリティグループを作成」をクリックします。

2.2.2. アプリケーションサーバー用セキュリティグループの作成

Webサーバーからのアクセス（特定のポート）と、SSHでの管理アクセスを許可するSGを作成します。データベースへのアウトバウンドアクセスも許可します。

  • 基本詳細:
    • セキュリティグループ名: app-server-sg
    • 説明: Allow web server access and SSH to app servers
    • VPC: あなたのVPCを選択します。
  • インバウンドルール:
    • ルールを追加
      • タイプ: カスタム TCP
      • ポート範囲: 例: 8080 (アプリケーションがリッスンするポート)
      • ソース: web-server-sg (先ほど作成したWebサーバー用SGを選択)
        • ポイント: ソースに「セキュリティグループID」を指定することで、そのセキュリティグループに属するインスタンスからの通信のみを許可できます。IPアドレスが変わっても対応できるため、非常に便利でセキュアな設定方法です。
    • ルールを追加
      • タイプ: SSH
      • ソース: My IP または あなたのオフィス/自宅の固定IPアドレス
  • アウトバウンドルール:
    • ルールを追加
      • タイプ: カスタム TCP
      • ポート範囲: 例: 3306 (MySQL/Auroraの場合) または 5432 (PostgreSQLの場合)
      • 宛先: db-server-sg (将来作成するデータベース用SGを選択)
        • ポイント: アプリケーションサーバーがデータベースに接続できるよう、宛先にデータベース用SGを指定します。
    • デフォルトの All traffic | 0.0.0.0/0 は削除し、必要な通信のみを許可するようにします。これにより、アプリケーションサーバーが意図しない外部への通信を行うことを防ぎます。
  • 「セキュリティグループを作成」をクリックします。

3. ネットワークACL (Network Access Control List - NACL) の徹底理解と実践

NACLはサブネットレベルのファイアウォールであり、セキュリティグループよりも広範なトラフィック制御を提供します。

3.1. ネットワークACLの基本と特徴（再確認）

  • サブネットにアタッチ: 特定のサブネット全体への通信を制御します。
  • ステートレス: インバウンドルールで許可された通信の応答も、アウトバウンドルールで明示的に許可する必要があります。双方向でルールが必要です。
  • 許可 (Allow) と拒否 (Deny) の両方を定義可能: 明示的な拒否ルールを設定できる点がセキュリティグループとの大きな違いです。
  • ルール番号の評価: ルールは番号の昇順（例: 100, 200, 300...）で評価され、最初に一致したルールが適用されます。リストの最後に * (全て拒否) ルールが暗黙的に存在します。
  • デフォルトは全て許可 (新規作成時は全て拒否): 新しくVPCを作成すると、そのVPCのデフォルトNACLは全てのインバウンド・アウトバウンドトラフィックを許可します。しかし、カスタムNACLを新規作成すると、デフォルトは全て拒否となります。この違いに注意が必要です。

3.2. カスタムNACLの作成とルール設定

セキュリティグループよりも厳格なサブネットレベルの制御が必要な場合、カスタムNACLを作成します。今回は、パブリックサブネット用NACLを例に作成してみましょう。

  1. VPCサービスの左側ナビゲーションペインから「ネットワークACL」をクリックします。
  2. 「ネットワークACLを作成」ボタンをクリックします。

3.2.1. パブリックサブネット用NACLの作成

Webサーバーが配置されるパブリックサブネットへのアクセスを制御します。

  • 基本詳細:
    • 名前タグ: public-subnet-nacl
    • VPC: あなたのVPCを選択します。
  • 「ネットワークACLを作成」をクリックします。

作成後、このNACLを選択し、以下のルールを設定します。

  • インバウンドルール:
    • ルールを追加
      • ルール番号: 100 (若い番号ほど優先)
      • タイプ: HTTP
      • ソース: 0.0.0.0/0
      • 許可/拒否: 許可
    • ルールを追加
      • ルール番号: 110
      • タイプ: HTTPS
      • ソース: 0.0.0.0/0
      • 許可/拒否: 許可
    • ルールを追加
      • ルール番号: 120
      • タイプ: SSH
      • ソース: あなたのオフィス/自宅の固定IPアドレス
      • 許可/拒否: 許可
    • ルールを追加
      • ルール番号: 130 (重要！)
      • タイプ: カスタム TCP
      • ポート範囲: 1024-65535 (一時ポート)
      • ソース: 0.0.0.0/0
      • 許可/拒否: 許可
        • ポイント: ステートレスなNACLでは、HTTP/HTTPSリクエストに対するWebサーバーからの「応答」がアウトバウンドで許可されていても、その応答がインターネットクライアントへ到達するためには、クライアント側からの一時ポートへのインバウンド接続（リクエストへの応答）も許可する必要があります。
  • アウトバウンドルール:
    • ルールを追加
      • ルール番号: 100
      • タイプ: HTTP
      • 宛先: 0.0.0.0/0
      • 許可/拒否: 許可
    • ルールを追加
      • ルール番号: 110
      • タイプ: HTTPS
      • 宛先: 0.0.0.0/0
      • 許可/拒否: 許可
    • ルールを追加
      • ルール番号: 120 (重要！)
      • タイプ: カスタム TCP
      • ポート範囲: 1024-65535 (一時ポート)
      • 宛先: 0.0.0.0/0
      • 許可/拒否: 許可
        • ポイント: Webサーバーが外部にアクセス（例: 外部APIへの接続）する場合や、クライアントへの応答を送るための一般的な一時ポートを許可します。
    • ルールを追加
      • ルール番号: 130
      • タイプ: SSH
      • 宛先: あなたのオフィス/自宅の固定IPアドレス
      • 許可/拒否: 許可
        • ポイント: SSHセッション中に、SSHクライアントからサーバーへのアウトバウンド（応答）通信も許可が必要です。
  • サブネットの関連付け:
    • 作成したNACLを選択し、「サブネットの関連付け」タブをクリックし、「サブネットの関連付けを編集」ボタンをクリックします。
    • パブリックサブネットAとパブリックサブネットCにチェックを入れ、「関連付けを保存」をクリックします。
      • ポイント: これで、デフォルトのNACLではなく、このカスタムNACLがサブネットに適用されます。

注意！ NACLは非常に強力ですが、設定ミスは簡単に通信断を引き起こします。特にステートレスである点を忘れずに、インバウンドとアウトバウンドの両方で必要なポートを許可してください。

4. セキュリティグループとNACLによる多層防御の実践

では、これらのコンポーネントがどのように連携して「多層防御」を構築するのかを見てみましょう。

[ インターネット ]
        |
        V
+-------------------------------------+  (NACL: サブネットレベルのファイアウォール)
| パブリックサブネット (Web層)           |
|                                    |
|       +------------------------+   |
|       |    Webサーバー (EC2)     |   |
|       |  (SG: インスタンスレベルのファイアウォール) |
|       +------------------------+   |
|                                    |
+------------------------------------+
        | (許可されたポートのみ通信)
        V
+------------------------------------+  (NACL: サブネットレベルのファイアウォール)
| プライベートサブネット (App層)         |
|                                    |
|       +------------------------+   |
|       | アプリケーションサーバー(EC2)  |
|       |  (SG: インスタンスレベルのファイアウォール) |
|       +------------------------+   |
|                                    |
+------------------------------------+
        | (許可されたポートのみ通信)
        V
+------------------------------------+  (NACL: サブネットレベルのファイアウォール)
| プライベートサブネット (DB層)          |
|                                    |
|       +------------------------+   |
|       |    データベース (RDS)    |   |
|       |  (SG: インスタンスレベルのファイアウォール) |
|       +------------------------+   |
|                                    |
+------------------------------------+

この図からわかるように、WebリクエストはまずパブリックサブネットのNACLでフィルタリングされ、次にWebサーバーのセキュリティグループでフィルタリングされます。Webサーバーからアプリケーションサーバーへの通信も同様に、NACLとSGの両方で制御されます。

  • NACL: サブネット全体のトラフィックを広範囲で制御し、不要な通信をサブネットレベルでブロックします。DDoS攻撃やポートスキャンなど、大量のトラフィックに対して効果的です。
  • セキュリティグループ: インスタンス個別の細かい通信制御を行います。どのインスタンスからどのインスタンスへのどのポートでのアクセスを許可するかを具体的に定義できます。

ベストプラクティス:

  1. SGを主軸に考える: ほとんどのケースでは、セキュリティグループで十分なアクセス制御が可能です。SGのシンプルな「許可のみ」のルールとステートフルな動作は、設定ミスを減らし、管理を容易にします。
  2. NACLは追加の防御層として: NACLは、より厳格なセキュリティ要件がある場合や、セキュリティグループでは実現できない特定のシナリオ（例: 特定のIPからの通信を明示的に拒否したい）で活用します。特に、VPCの境界や、非常に機密性の高いサブネットに対して適用を検討しましょう。
  3. 最小権限の原則: 常に、必要なトラフィックのみを許可する最小権限の原則に従ってルールを設定します。0.0.0.0/0 (どこからでも) の許可は慎重に行い、特にSSHのような管理ポートでは限定的なIPアドレスのみを許可しましょう。
  4. 定期的なレビュー: セキュリティグループやNACLのルールは、時間の経過とともに複雑になりがちです。定期的に見直し、不要なルールを削除したり、より厳格なルールに変更したりすることで、セキュリティリスクを低減できます。

5. AI時代におけるセキュリティネットワークの考慮事項

AI/ML環境は、大量のデータと計算リソースを扱うため、特に強固なネットワークセキュリティが求められます。

  • データ保護: 学習データやモデルの推論結果は機密情報であることが多いため、これらのデータが保存されるストレージ（S3など）へのアクセスは、セキュリティグループやNACL、そしてVPCエンドポイントなどを組み合わせて、インターネットからの直接アクセスを完全に遮断すべきです。
  • 内部通信の分離: AI/MLパイプラインでは、データ前処理、モデル学習、推論といった複数のコンポーネントが連携します。これらのコンポーネント間の通信も、最小権限の原則に基づき、厳密にセキュリティグループで制御すべきです。例えば、学習サーバーから推論サーバーへのSSHアクセスは許可しないなど。
  • 認証・認可との連携: ネットワークセキュリティは、IAMによる認証・認可と組み合わせて初めて完全なセキュリティが実現します。どのユーザーがどのリソースに、ネットワーク経由でどのようにアクセスできるのか、両面から考慮しましょう。
  • ログと監視: セキュリティグループとNACLのフローログ（VPC Flow Logs）を有効にし、不審な通信がないか常に監視することが重要です。これにより、潜在的な脅威を早期に検知し、対応することができます（Day 16で詳しく扱います）。

本日のまとめと次へのステップ

今日は、AWSネットワークセキュリティの二つの柱であるセキュリティグループとNACLについて、それぞれの特徴と設定方法、そしてそれらを組み合わせて多層防御を実現する方法を学びました。

  • セキュリティグループ (SG): インスタンスレベルのステートフルなファイアウォール。許可ルールのみ。
  • ネットワークACL (NACL): サブネットレベルのステートレスなファイアウォール。許可と拒否ルールを設定可能。

これらを適切に使い分け、最小権限の原則に基づいて設定することで、あなたのAWS環境ははるかに安全になります。これは、外資系AI企業が最も重視するポイントの一つです。

明日のDay 7は、「1週間の振り返り：基礎固めと次のステップ」です。これまで学んだVPC、サブネット、IGW、ルートテーブル、そしてセキュリティグループとNACLの知識を整理し、理解度を確認するための振り返りを行います。そして、来週からの学習に備えて、さらに一歩踏み込んだ内容へと進む準備をしましょう。

今日のセキュリティに関する内容、実践的だと感じましたか？ぜひ「いいね」👍でフィードバックをお願いします！

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?