セキュリティグループとキーペア

security group は、EC2 インスタンス（または RDS、Lambda、ELB などの他の AWS リソース）との間で送受信されるインバウンドおよびアウトバウンドトラフィックを制御する、仮想的なステートフルファイアウォールです。Security Groups はインスタンスレベルで動作します。各ルールでは、プロトコル（TCP/UDP/ICMP）、ポート範囲、送信元または送信先（IP 範囲または別の security group）を指定します。従来のファイアウォールとは異なり、Security Groups はステートフルです。インバウンドトラフィックを許可すると、明示的なルールがなくても応答トラフィックは自動的にアウトバウンドで許可されます。

Security Groups には、インバウンドとアウトバウンドのルールセットが別々にあります。インバウンドルールはインスタンスに到着するトラフィックを制御し、デフォルトではすべてのインバウンドトラフィックが拒否されます。アウトバウンドルールはインスタンスから送信されるトラフィックを制御し、デフォルトではすべてのアウトバウンドトラフィックが許可されます。明示的な Allow ルールを追加します。Security Groups には明示的な Deny ルールはありません（明示的な拒否には Network ACLs を使用します）。Security Group 内のすべてのルールは論理 OR でまとめて評価され、いずれかの Allow ルールに一致すればトラフィックは許可されます。

Security Groups は送信元/送信先 security group の参照をサポートしており、IP 範囲を指定するよりも柔軟で安全です。たとえば、ALB の security group ではポート 443 に対して 0.0.0.0/0 を許可します。EC2 インスタンスの security group では、任意の IP ではなく、ALB security group ID からのインバウンドポート 8080 のみを許可します。ALB が置き換えられたりスケールされたりしても、IP を変更することなくルールは引き続き正しく適用されます。このパターンにより、マルチティアアーキテクチャ向けの階層的かつ動的な防御を構築できます。

ステートフルとは、security group が接続状態を追跡することを意味します。インバウンドルールでインターネットからの TCP ポート 80 を許可し、クライアントがリクエストを送信した場合、ポート 80 のアウトバウンドルールがなくても、応答パケットはクライアントへ自動的に返送できます。これは、ステートレスであり、トラフィックの両方向に明示的なルールを必要とするNetwork ACLsとは根本的に異なります。ステートフルであるため、一般的なアプリケーショントラフィックのパターンに対して Security Groups を簡単に設定できます。

1 つの EC2 インスタンスには複数の security groupをアタッチできます（デフォルトでは最大 5 個、調整可能です）。アタッチされたすべての security group のルールは、和集合（OR ロジック）として結合されます。いずれかの security group がリクエストを許可すれば、そのリクエストは許可されます。つまり、security group は権限を追加することしかできず、制限することはできません。アクセスを厳しくしたい場合は、より制限的な security group を追加するのではなく、ルールを削除または変更する必要があります。アクセス制限に関する試験問題では、この加算的な動作を覚えておいてください。

すべての VPC にはdefault security groupが含まれます。デフォルトルールでは、インバウンドは同じ default security group 内の他のインスタンスからのすべてのトラフィックを許可し、アウトバウンドはすべての宛先へのトラフィックを許可します。これは、新しいインスタンスがデフォルトで通信できるようにするため、意図的に寛容な設定です。本番環境では、インバウンドルールセットを厳格に制限したカスタム security group を作成し、意図しない公開を避けるために default security group とインスタンスの関連付けを解除してください。

EC2 のkey pairsは、SSH 認証に非対称暗号を使用します。AWS がキーペアを生成するか、自身の公開鍵をインポートします。AWS は公開鍵を保存し、インスタンス起動時にその鍵をインスタンスへ注入します。一方で、秘密鍵（.pem ファイル）はダウンロードして保管します。AWS が秘密鍵を保存することはありません。SSH は、パスワードを送信せずにサーバーへ本人性を証明するために秘密鍵を使用します。秘密鍵には制限的な権限（chmod 400）が必要であり、そうでない場合 SSH はその鍵の使用を拒否します。

Linux EC2 インスタンスの秘密鍵を紛失した場合、通常の方法では SSH 接続できません。復旧方法には、Systems Manager Session Manager（SSM エージェントが実行中で IAM ロールがアタッチされている場合。キーは不要）、EC2 Instance Connect（ブラウザまたは CLI 経由で一時キーを注入。SSH ポートの開放と EIC 権限が必要）、またはインスタンスを停止し、ルート EBS ボリュームをデタッチして別のインスタンスにアタッチし、authorized_keys ファイルを変更してから、再アタッチして再起動する方法があります。Windows では、Systems Manager を使用してパスワードを取得します。

SSH（ポート 22）を 0.0.0.0/0 に開放すると、インスタンスはインターネット上のどこからでもブルートフォース攻撃やクレデンシャルスタッフィング攻撃にさらされます。ベストプラクティスとして、SSH を特定の企業 IP 範囲に制限するか、厳しく制御された security group を持つパブリックサブネットのbastion host（踏み台サーバー）を使用し、bastion からプライベートインスタンスへ SSH 接続します。さらに良い方法は、Systems Manager Session Manager を使用して SSH ポートの公開を完全になくすことです。インバウンドルールは一切必要ありません。

Security Groups の主なデフォルト制限は、Service Quotas を通じて調整可能です。VPC あたり最大 2,500 個の security group、security group あたりインバウンドルール 60 個、アウトバウンドルール 60 個、ネットワークインターフェイスあたり security group 5 個です。別の security group を送信元として参照する場合、参照する security group とルールの組み合わせごとに 1 ルールとして数えられます。ルールの上限に達した場合は、個々の IP 範囲ではなく security group ID を参照するように集約するか、prefix lists を使用して複数の CIDR を管理しやすい 1 つのエンティティにまとめてください。

managed prefix list は、security group のルールまたはルートテーブルで参照できる CIDR ブロックのセットです。AWS は S3 や CloudFront などのサービス向けにAWS-managed prefix listsを管理しているため、自分で IP 範囲を保守せずにこれらのサービスとの送受信トラフィックを許可できます（IP 範囲は時間とともに変わります）。また、customer-managed prefix listsを作成して企業 IP 範囲をグループ化することもできます。prefix list を 1 か所で更新すれば、それを参照するすべての security group に変更が自動的に継承されます。

このレッスンで学んだ AWS Solutions Architect（SAA-C03）の概念に対する理解度を確認しましょう。

このレッスンでは、security group はデフォルト拒否でトラフィックを許可するステートフルな仮想ファイアウォールであること、ID を使用して security group を連鎖させる方法は IP 範囲を使用するより安全で柔軟であること、そしてkey pairs は非対称 SSH 認証を提供し、Systems Manager Session Manager を使えば SSH ポートを開放する必要がなくなることを学びました。次は、EC2 のストレージオプションである Instance Store と EBS について学びます。