「セキュリティグループのルール」
セキュリティグループルールは、セキュリティグループに関連付けられたリソースに到達することを許可するインバウンドトラフィックを制御します。また、このルールによって、インスタンスから送信されるアウトバウンドトラフィックも制御されます。
セキュリティグループのルールは追加または削除できます (インバウンドまたはアウトバウンドアクセスの許可または取り消しとも呼ばれます)。ルールが適用されるのは、インバウンドトラフィック (受信) またはアウトバウンドトラフィック (送信) のいずれかです。特定のソースまたは送信先へのアクセス権を付与できます。
セキュリティグループのルールの基本
セキュリティグループのルールの特徴を次に示します。
-
許可ルールを指定できます。拒否ルールは指定できません。
-
セキュリティグループを初めて作成するときには、インバウンドルールはありません。したがって、インバウンドルールをセキュリティグループに追加するまで、インバウンドトラフィックは許可されません。
-
セキュリティグループを最初に作成するとき、リソースからのすべてのアウトバウンドトラフィックを許可するアウトバウンドルールが設定されます。ルールを削除し、任意の発信トラフィックのみを許可するアウトバウンドルールを追加できます。セキュリティグループにアウトバウンドルールがない場合、アウトバウンドトラフィックは許可されません。
-
複数のセキュリティグループをリソースに関連付けると、各セキュリティグループのルールが集約されて、アクセス許可の判断に使用する 1 つのルールセットが形成されます。
-
ルールを追加、更新、または削除すると、セキュリティグループに関連付けられたすべてのリソースにこの変更が自動的に適用されます。手順については、セキュリティグループのルールを設定する を参照してください。
-
一部のルール変更の影響は、トラフィックの追跡方法によって異なる場合があります。詳細については、「Amazon EC2 ユーザーガイド」の「接続追跡」を参照してください。
-
セキュリティグループルールを作成する際、AWS により、一意の ID がそのルールに割り当てられます。このルールの ID は、API または CLI を使用してルールを変更または削除する際に使用します。
制限
セキュリティグループは、「VPC+2 IP アドレス」 (「Amazon Route 53 デベロッパーガイド」の「Amazon Route 53 Resolver」を参照) または AmazonProvidedDNS と呼ばれることがある Route 53 Resolver から送受信される DNS リクエストをブロックできません。Route 53 Resolver 経由の DNS リクエストをフィルタリングするには、Route 53 Resolver DNS Firewall を使用します。
セキュリティグループルールの構成要素
以下は、インバウンドおよびアウトバウンドセキュリティグループルールの構成要素です。
-
プロトコル: 許可するプロトコル。最も一般的なプロトコルは、6 (TCP)、17 (UDP)、1 (ICMP) です。
-
ポートの範囲: TCP、UDP、カスタムプロトコルの場合、許可するポートの範囲。1 つのポート番号 (
22など)、または一定範囲のポート番号 (7000-8000など) を指定できます。 -
ICMP タイプおよびコード: ICMP の場合、ICMP タイプおよびコードです。例えば、ICMP エコー要求にはタイプ 8、ICMPv6 エコー要求にはタイプ 128 を使用します。
-
Source or destination (送信元または送信先): 許可するトラフィックの送信元 (インバウンドルール) または送信先 (アウトバウンドルール)。次のいずれかを指定します。
-
単一の IPv4 アドレス。
/32プレフィクス長を使用する必要があります。例えば、203.0.113.1/32と指定します。 -
単一の IPv6 アドレス。
/128プレフィクス長を使用する必要があります。例えば、2001:db8:1234:1a00::123/128と指定します。 -
CIDR ブロック表記の IPv4 アドレスの範囲。例えば、
203.0.113.0/24と指定します。 -
CIDR ブロック表記の IPv6 アドレスの範囲。例えば、
2001:db8:1234:1a00::/64と指定します。 -
プレフィクスリストの ID。例えば、
pl-1234abc1234abc123と指定します。詳細については、「マネージドプレフィックスリストを使用したネットワーク CIDR ブロックの統合と管理」を参照してください。 -
セキュリティグループの ID。例えば、
sg-1234567890abcdef0と指定します。詳細については、「セキュリティグループの参照」を参照してください。
-
-
(オプション) 説明: 後で分かりやすいように、このルールの説明を追加できます。説明の長さは最大 255 文字とすることができます。使用できる文字は、a～z、A～Z、0～9、スペース、._-:/()#,@[]+=;{}!$* です。
セキュリティグループの参照
ルールのソースまたは宛先としてセキュリティグループを指定する場合、ルールはセキュリティグループに関連付けられているすべてのインスタンスに影響します。インスタンスは、指定されたプロトコルとポート経由で、インスタンスのプライベート IP アドレスを使用して、指定された方向の通信を行うことができます。
例えば、以下は、セキュリティグループ sg-0abcdef1234567890 を参照するセキュリティグループのインバウンドルールを表しています。このルールは、sg-0abcdef1234567890 に関連付けられたインスタンスからのインバウンド SSH トラフィックを許可します。
| ソース | プロトコル | ポート範囲 |
|---|---|---|
sg-0abcdef1234567890 |
TCP | 22 |
セキュリティグループルール内のセキュリティグループを参照するときは、以下の点に注意してください。
-
次のいずれかに該当する場合、別のセキュリティグループのインバウンドルールのセキュリティグループを参照できます:
-
セキュリティグループは同じ VPC に関連付けられます。
-
セキュリティグループが関連付けられている VPC 間にピアリング接続があります。
-
セキュリティグループが関連付けられている VPC 間にトランジットゲートウェイがあります。
-
-
次のいずれかに該当する場合、アウトバウンドルールのセキュリティグループを参照できます:
-
セキュリティグループは同じ VPC に関連付けられます。
-
セキュリティグループが関連付けられている VPC 間にピアリング接続があります。
-
-
参照されるセキュリティグループからのルールが、このグループを参照するセキュリティグループに追加されていない。
-
インバウンドルールの場合は、セキュリティグループに関連付けられた EC2 インスタンスが、参照されるセキュリティグループに関連付けられた EC2 インスタンスのプライベート IP アドレスからのインバウンドトラフィックを受信できる。
-
アウトバウンドルールの場合は、セキュリティグループに関連付けられた EC2 インスタンスが、参照されるセキュリティグループに関連付けられた EC2 インスタンスのプライベート IP アドレスへのアウトバウンドトラフィックを送信できる。
制限
ミドルボックスアプライアンスを介して異なるサブネット内の 2 つのインスタンス間のトラフィックを転送するようにルートを設定するには、両方のインスタンスのセキュリティグループでインスタンス間のトラフィックがフローできるようにする必要があります。各インスタンスのセキュリティグループは、他のインスタンスのプライベート IP アドレス、または他のインスタンスを含むサブネットの CIDR 範囲を送信元として参照される必要があります。他のインスタンスのセキュリティグループを送信元として参照する場合、インスタンス間のトラフィックは許可されません。
例
次の図は、2 つのアベイラビリティーゾーン、1 つのインターネットゲートウェイ、1 つの Application Load Balancer のサブネットを使用する VPC を示しています。各アベイラビリティーゾーンには、ウェブサーバー用のパブリックサブネットと、データベースサーバー用のプライベートサブネットがあります。ロードバランサー、ウェブサーバー、データベースサーバーには個別のセキュリティグループがあります。以下のセキュリティグループルールを作成して、トラフィックを許可します。
-
ロードバランサーのセキュリティグループにルールを追加して、インターネットからの HTTP および HTTPS トラフィックを許可します。送信元は 0.0.0.0/0 です。
-
ウェブサーバーのセキュリティグループにルールを追加して、ロードバランサーからの HTTP および HTTPS トラフィックのみを許可します。送信元はロードバランサーのセキュリティグループです。
-
データベースサーバーのセキュリティグループにルールを追加して、ウェブサーバーからのデータベースリクエストを許可します。送信元はウェブサーバーのセキュリティグループです。
セキュリティグループのサイズ
各ルールがセキュリティグループごとに設定できるルールの最大数にカウントされる方法は、ソースまたは送信先のタイプに応じて判断されます。
-
CIDR ブロックを参照するルールは、1 個のルールとしてカウントされます。
-
別のセキュリティグループを参照するルールは、参照されるセキュリティグループのサイズにかかわらず、1 個のルールとしてカウントされます。
-
カスタマーマネージドプレフィックスリストを参照するルールは、プレフィックスリストの最大サイズにならってカウントされます。例えば、プレフィックスリストの最大サイズが 20 の場合、このプレフィックスリストを参照するルールも 20 個のルールとしてカウントされます。
-
AWS マネージドプレフィックスリストを参照するルールは、プレフィックスリストのウェイトにならってカウントされます。例えば、プレフィックスリストの最大サイズが 10 の場合、このプレフィックスリストを参照するルールも 10 個のルールとしてカウントされます。詳細については、「使用可能な AWS マネージドプレフィックスリスト」を参照してください。
古くなったセキュリティグループルール
VPC に別の VPC との VPC ピアリング接続がある場合、または別のアカウントで共有されている VPC を使用している場合、VPC のセキュリティグループルールは、そのピア VPC または共有 VPC のセキュリティグループを参照できます。これにより、参照されるセキュリティグループに関連付けられているリソースと、参照するセキュリティグループに関連付けられているリソースが、相互に通信できるようになります。詳細については、「Amazon VPC ピアリングガイド」の「セキュリティグループの更新とピアセキュリティグループの参照」を参照してください。
ピア VPC または共有 VPC のセキュリティグループを参照するセキュリティグループルールがあって、共有 VPC のセキュリティグループが削除されたまたは VPC ピアリング接続が削除された場合、そのセキュリティグループは陳腐化とマークされます。古くなったセキュリティグループルールは他のセキュリティグループルールと同じ方法で削除できます。
