Elastic Compute Service:セキュリティグループのガイドラインとユースケース

セキュリティグループのガイドライン

1. ニーズの特定とセキュリティグループの計画

ビジネスニーズと特定のセキュリティ要件を定義します。たとえば、どのサービスをパブリックにアクセス可能にする必要があり、どのサービスを内部アクセスに制限する必要があるかを決定します。

• パブリックサービス用と内部サービス用のサーバーを異なるセキュリティグループに分離する

  不要なサービスポートを公開すると、セキュリティの脆弱性が生じる可能性があります。ご利用の Elastic Compute Service (ECS) インスタンスのセキュリティグループには、最も厳格なルールを適用してください。デフォルトですべてのポートとプロトコルを閉じ、サービスで必要な特定のポートのみを開放する、デフォルト拒否ポリシーを採用してください。

  公開サーバー向けのセキュリティグループは、明確でシンプルな目的を持つべきです。同じサーバーで MySQL や Redis などの他のサービスを実行することは避けてください。これらのバックエンドサービスは、パブリック IP アドレスを持たない ECS インスタンスにインストールすることを推奨します。その後、別のセキュリティグループからのアクセスを許可するセキュリティグループルールを作成して、アクセスを許可します。

• アプリケーションごとに異なるセキュリティグループを使用する

  本番環境では、オペレーティングシステムやアプリケーションが異なるサーバーは、通常、負荷分散のために同じグループに属しません。サービスが異なれば、開閉する必要のあるポートも異なります。ロールが異なるリソースは、異なるセキュリティグループに割り当ててください。

  たとえば、Linux インスタンスでは SSH アクセス用に TCP ポート 22 が必要になる場合がありますが、Windows インスタンスではリモートデスクトップ接続用に TCP ポート 3389 が必要になる場合があります。

  インスタンスが同じイメージタイプを使用していても、提供するサービスが異なり、内部ネットワーク経由での通信が不要な場合は、異なるセキュリティグループに割り当てるべきです。このアプローチにより、サービスが分離され、将来のルール変更が簡素化され、各セキュリティグループが単一の責任を持つことが保証されます。

  新しいアプリケーションを計画・追加する際は、vSwitch でサブネットを計画するのと同じように、セキュリティグループを計画する必要があります。CIDR ブロックとセキュリティグループの両方を使用して、サービスプロバイダーとコンシューマーの間に明確な境界を定義します。

• 本番環境とテスト環境でセキュリティグループを分ける

  システムをより良く分離するために、複数のテスト環境と 1 つの本番環境を構築することがあります。ネットワークを適切に分離するには、各環境に異なるセキュリティポリシーを設定します。これにより、テスト環境での変更が誤って本番環境の安定性に影響を与えるのを防ぎます。

  異なるセキュリティグループを作成することで、アプリケーションのアクセスドメインを制限し、本番環境とテスト環境間の通信を防ぐことができます。また、複数のテスト環境に異なるセキュリティグループを割り当てることで、互いに干渉するのを防ぎ、開発効率を向上させることができます。

• パブリックアクセスを必要としないリソースにはパブリック IP アドレスを割り当てない

  パブリックな露出を最小限に抑えるため、ワークベンチ、Session Manager、ジャンプサーバーなど、パブリック IP アドレスを必要としない方法で ECS インスタンスに接続します。プライベートネットワークにデプロイされたサービスに直接アクセスするには、ポートフォワーディング機能を使用できます。詳細については、「Session Manager CLI のポートフォワーディング機能を使用してパブリック IP アドレスを持たないインスタンスにアクセスする」をご参照ください。

  分散アプリケーションでは、リソースはしばしば異なる階層やグループに分離されます。パブリックサービスを提供しない ECS インスタンスには、パブリック IP アドレスを割り当てないでください。パブリックアクセスを提供するサーバーが複数ある場合は、Server Load Balancer (SLB) を使用してパブリックトラフィックを分散させます。これにより、システムの可用性が向上し、単一障害点を防ぐことができます。詳細については、 をご参照ください。

  Virtual Private Cloud (VPC) 内で、パブリック IP アドレスを持たない ECS インスタンスがインターネットにアクセスする必要がある場合は、NAT Gateway を使用します。これはインターネットアクセスのプロキシとして機能します。特定の CIDR ブロックまたはサブネットに対して SNAT ルールを設定するだけで、パブリックアクセスを有効にできます。これにより、アウトバウンドのインターネットアクセスのみが必要な場合に、パブリック IP アドレス (または Elastic IP アドレス) を割り当ててサービスをインターネットに公開することを防ぎます。詳細については、「SNAT エントリの作成と管理」をご参照ください。

• セキュリティグループをホワイトリストとして使用する

  セキュリティグループはホワイトリストとして機能させるべきです。デフォルトでは、すべてのアクセスを拒否します。許可ルールを追加して、特定のポート範囲で、許可されたソースからのトラフィックを許可できます。ポートの開放とパブリック IP アドレスの割り当ては、可能な限り少なくしてください。Elastic IP アドレスを関連付けることは、トラブルシューティングのために本番マシンにアクセスする便利な方法ですが、マシン全体をインターネットに公開することになります。

2. セキュリティグループルールの設定

セキュリティグループは、ECS インスタンスのインバウンドおよびアウトバウンドトラフィックを制御する仮想ファイアウォールとして機能します。必要な通信ポートのみを開放し、ソース IP アドレス範囲を可能な限り制限する必要があります。

VPC では、単一のセキュリティグループルールでパブリックネットワークとプライベートネットワークの両方のアクセスを制御できます。つまり、1 つのルールを設定して、インターネットと内部ネットワークの両方からのトラフィックを制限または許可できます。

• デフォルトポリシーは基本セキュリティグループと高度セキュリティグループで異なる

  デフォルトでは、基本セキュリティグループと高度セキュリティグループの両方がすべてのインバウンドトラフィックを拒否します。ただし、アウトバウンドポリシーは異なります：基本セキュリティグループはすべてのアウトバウンドトラフィックを許可しますが、高度セキュリティグループはそれを拒否します。

• 内部接続性はセキュリティグループおよびセキュリティグループタイプによって異なる

  同じアカウントに属していても、異なるセキュリティグループ内の ECS インスタンスは、内部ネットワーク上で互いに分離されています。デフォルトでは、同じ基本セキュリティグループ内のインスタンスは互いに通信できますが、同じ高度セキュリティグループ内のインスタンスは互いに分離されています。

• 最小権限の原則に基づいてルールを追加する

  たとえば、リモートログインのために Linux インスタンスでポート 22 を開く場合、特定の IP アドレスからのアクセスのみを許可します。

  警告

  0.0.0.0/0 からのアクセスを許可すると、すべての IP アドレスがインスタンスにアクセスできるようになり、すべてのポートが公開されます。これは非常に安全ではありません。正しいプラクティスは、デフォルトですべてのポートへのアクセスを拒否することです。たとえば、Web サービスを公開する必要がある場合は、80、8080、443 などの一般的な TCP ポートのみを開き、他のすべてのポートを閉じたままにする必要があります。

  ビジネスニーズと最小権限の原則に基づいて、セキュリティグループルールを設定してください。セキュリティリスクを避けるため、すべてのポートを開放することは避けてください (::/0 または 0.0.0.0/0 の使用には細心の注意を払ってください)。権限付与オブジェクトの種類についての詳細は、「セキュリティグループルール」をご参照ください。

• 最小権限の原則に基づいてグループ内のインスタンスを分離する

  基本セキュリティグループ内のインスタンスが互いに通信する必要がない場合は、セキュリティグループの内部アクセス ポリシーを設定してインスタンスを分離します。

• 単一のセキュリティグループ内のルールの目的を一貫させる

  ルールをその目的に基づいて複数のセキュリティグループに整理し、インスタンスを関連するグループに関連付けます。単一のセキュリティグループにルールが多すぎると、管理が複雑になります。

• 権限付与オブジェクトを慎重に選択する

  セキュリティグループルールの権限付与オブジェクトは、IP アドレス、別のセキュリティグループ、または CIDR ブロックにすることができます。

  異なるセキュリティグループのリソース間でネットワーク通信を有効にしたい場合は、セキュリティグループによるアクセスを許可する必要があります。たとえば、分散アプリケーションの場合、コンポーネントごとに異なるセキュリティグループを使用することがあります。これらのセキュリティグループが互いに通信できない場合、IP アドレスや CIDR ブロックでアクセスを許可するべきではありません。代わりに、他のセキュリティグループ内のすべてのリソースからのアクセスを直接許可する必要があります。たとえば、アプリケーションの Web コンポーネントとデータベースコンポーネント用に sg-web と sg-database という別々のセキュリティグループを作成した場合、sg-database にルールを追加できます。このルールは、sg-web セキュリティグループ内のすべてのリソースが MySQL (3306) ポートにアクセスすることを許可します。

  内部ネットワークアクセスには、CIDR ブロックではなく、ソースセキュリティグループを許可します。

• 一般的なアプリケーションはデフォルトポートを使用する

  アプリケーションは、外部サービスと通信するために特定のサーバーポートを使用します。詳細については、「一般的なポート」をご参照ください。

3. ルールの継続的なレビューと最適化

ビジネスの進化に伴い、既存のセキュリティグループとルールが古くなる可能性があります。定期的にアーキテクチャを見直し、最新のセキュリティ状況に基づいて調整を行ってください。本番環境でセキュリティグループを変更する前に、まずそれをクローンし、テスト環境でルールをテストしてトラフィックが正しく流れることを確認します。その後、変更を本番のセキュリティグループに適用します。この実践は、誤った変更によるサービスの中断を防ぐのに役立ちます。

ユースケース

ECS インスタンスへのインバウンドトラフィックの制御

インバウンドトラフィックとは、外部リソースからご利用の ECS インスタンスへのトラフィックです。インバウンド セキュリティグループルールを設定して、指定されたユーザーがご利用の ECS インスタンスにデプロイされたサービスにアクセスできるようにすることができます。デフォルトでは、すべてのインバウンドトラフィックは拒否されるため、許可したいトラフィックに対してのみ許可ルールを設定する必要があります。関連するユースケースは次のとおりです：

• ケース 1: ECS インスタンスにデプロイされた Web サイトから Web サービスを提供する

• ケース 2: 特定のユーザーに ECS インスタンスへのリモートアクセスを許可する

• ケース 3: ECS インスタンスにデプロイされたデータベースのセキュリティポリシーを実装する

• ケース 4: 特定のプロトコルのみのアクセスを許可する

• ケース 5: 異なるセキュリティグループ内のインスタンス間の内部通信を有効にする

ECS インスタンスからのアウトバウンドトラフィックの制御

アウトバウンドトラフィックとは、ご利用の ECS インスタンスから外部リソースへのトラフィックです。アウトバウンド セキュリティグループルールを設定して、ご利用の ECS インスタンスから指定された外部リソースへのアクセスを拒否することができます。基本セキュリティグループの場合、デフォルトですべてのアウトバウンドトラフィックが許可されるため、ブロックしたいトラフィックに対してのみ拒否ルールを追加する必要があります。関連するユースケースは次のとおりです：

• ケース 6: ECS インスタンスから外部 Web サイトへのアウトバウンドアクセスを制限する

ケース 1: Web サービスの提供

ケース 2: リモートアクセスの許可

ケース 3: データベースセキュリティの設定

ケース 4: 特定プロトコルの許可

ケース 5: 内部通信の有効化

• シナリオ 1: 同じアカウント内のセキュリティグループ

  セキュリティグループ A とセキュリティグループ B が同じアカウントに属している場合、権限付与オブジェクトをソースセキュリティグループの ID に設定します。次の表に、このセキュリティグループルール設定の例を示します。

  ルール方向	アクション	優先度	プロトコルタイプ	ポート範囲	権限付与オブジェクト
  インバウンド	許可	1	カスタム TCP	21/21	sg-bp1hv6wvmegs036****

  説明

  例のセキュリティグループ ID を実際の値に置き換えてください。

• シナリオ 2: 異なるアカウント内のセキュリティグループ

  セキュリティグループ A とセキュリティグループ B が異なるアカウントに属している場合、権限付与オブジェクトをソース Alibaba Cloud アカウントの ID とソースセキュリティグループの ID に設定します。次の表に、このセキュリティグループルール設定の例を示します。

  ルール方向	アクション	優先度	プロトコルタイプ	ポート範囲	権限付与オブジェクト
  インバウンド	許可	1	カスタム TCP	21/21	160998252992****/sg-bp174yoe2ib1sqj5****

  説明

  例の Alibaba Cloud アカウント ID とセキュリティグループ ID を実際の値に置き換えてください。

ケース 6: アウトバウンドアクセスの制限