本文の内容は、2022年9月6日にBrett Wolmaransが投稿したブログ(https://sysdig.com/blog/aws-security-groups-guide/)を元に日本語に翻訳・再構成した内容となっております。
AWSセキュリティグループ（およびネットワークACLとVPC）は、クラウド環境におけるセキュリティの基本的なビルディングブロックの一部です。
これらはファイアウォールに似ていますが、同じものではありません。クラウドでのビルドを始める前に、このトピックをよく理解しておく必要があります。なぜなら、これらの使用方法には微妙な違いがあり、ベストプラクティスに従う必要があるからです。
パブリッククラウドプロバイダーは、契約上、責任共有モデルの側を尊重する義務があることを知っておく必要があります。しかし、セキュリティグループはあなたの責任です。EC2インスタンスを起動したときのデフォルトのルールは、LinuxインスタンスのSSHアクセス用のポート22だけです。
あなたはさらに必要でしょう。たとえば、HTTPのポート80とHTTPSのポート443の両方をリッスンするWebサーバーを作成する場合があります。そして、インターネット全体、つまり 0.0.0.0/0 から Web サーバーを利用できるようにしたいとします。0.0.0.0/0からポート80とポート443へのトラフィックを許可するセキュリティグループがなければ、このトラフィックは拒否され、Webサービスが孤立してしまいます。
そのため、セキュリティのためにセキュリティグループが必要なだけでなく、基本的なトラフィックを動作させるだけでも正しく設定する必要があります。
このブログ記事では、AWSクラウドでネットワークを構成し、セキュリティを確保するために必要な情報とベストプラクティスを学びます。
AWSのセキュリティグループとは？
AWSにおけるセキュリティグループは、インスタンスのインバウンドとアウトバウンドのトラフィックを制御するルールのコレクションです。インスタンスを起動するときに、1つまたは複数のセキュリティグループを指定できます。注：Amazon Virtual Private Cloud (VPC)について触れずに、セキュリティグループについて語ることはできません。Amazon VPCは、従来のネットワークに類似した仮想ネットワークです。従来のネットワークと同様に、VPCには、IPアドレス、サブネット、ルートテーブル、インターネットゲートウェイなどがあります。そしてもちろん、VPCにも何らかのファイアウォールフィルタリングが必要で、それがセキュリティグループにつながります。
セキュリティグループを指定しない場合、Amazon EC2はデフォルトのセキュリティグループを使用します。例えば、EC2インスタンスにセキュリティグループを関連付けると、そのインスタンスのインバウンドとアウトバウンドのトラフィックは、セキュリティグループのルールに従います。セキュリティグループはサブネット全体ではなく、インスタンスにのみ適用されます。
セキュリティグループはステートフルであり、イングレスとイグレスは同じです。一方向のルールにマッチしたトラフィックは、自動的に反対方向にも許可されます。
セキュリティグループは、AWSコンソールのEC2サービスの下に表示されます：
また、AWS CLIでもEC2サービスの下にセキュリティグループがあるのはご存知の通りです。ここでは、セキュリティグループを作成する方法を確認します：
aws ec2 create-security-group --group-name web-pci-sg --description "allow SSL traffic" --vpc-id vpc-555666777そして、ここではAWS CLIを使って、セキュリティグループにルールを追加しています：
aws ec2 authorize-security-group-ingress
--group-name web-pci-sg
--protocol https
--port 443
--cidr <IP Subnet/Netmask>インスタンスに関連するAWS セキュリティグループの例です：
セキュリティグループにはDenyのルールが作れないことに注意してください - allowのルールしか作れません。デフォルトはDenyです。下図ではallowルールしか作れず、許可されていないものは拒否されることに注意してください：
なぜ、セキュリティグループが必要なのか？
クラウドでも物理世界と同じようにレイヤー3やレイヤー4のフィルタリングが必要です。そして、従来のファイアウォールは機能するかもしれませんが、クラウドネイティブではない仮想ファイアウォールは、管理上のオーバーヘッドとコストを追加するかもしれません。セキュリティグループには、いくつかの利点があります。セキュリティ・グループは無料で、好きなだけ使うことができます。カテゴリを作成するようにセキュリティグループを作成し、共通のフィルタリング戦略を必要とするインスタンスのグループに適用します。
これは、個々のインスタンスでiptablesなどのローカルファイアウォールを設定するのとは対照的です。スクリプトやユーザーデータのインジェクションなど、何らかの方法で行う必要があり、セキュリティグループがより良いアプローチに思えてきます。
どのサービスにセキュリティグループが必要なのか？
EC2コンピュートインスタンスで最も一般的に使用されていますが、多くのAWSサービスはセキュリティグループに依存しています。これらのサービスの中で、Amazon EC2 は最も広く使用されているサービスの 1 つです。 Amazon EC2 を一般的に保護する方法を知りたい場合、特に Amazon EC2 で SSH を保護する方法を完全に理解したい場合は、さらに詳しく調べる必要があります。
しかし、Amazon EC2だけでなく、以下のすべてのAWSサービスは、何らかの形でセキュリティグループに依存しています：
- Amazon EC2インスタンス
- AWS Lambda
- AWS Elasticロードバランサー
- データベース(Amazon RDS、Amazon Redshift)
- その他(ElastiCache、CloudSearch、Elastic Beanstalk、Elastic MapReduce)
- コンテナ、Kubernetesサービス（ECS、EKS）
ネットワークアクセスリストとは？
AWSでは、ネットワークアクセスコントロールリスト（NACL）は、サブネットのインバウンドとアウトバウンドのトラフィックを制御するルールの集合体です。NACLのルールはセキュリティグループと似ていますが、個々のインスタンスではなく、サブネット全体に適用されます。NACLはステートレスで、イングレスとイグレスは同じではありません。一方向のルールに一致するトラフィックが、反対方向で自動的に許可されることはありません。アウトバウンドルールを追加する必要があります。
セキュリティグループと同様に、NACLはEC2サービスの一部であり、AWS CLIでこのように表示されます。
AWS CLIを使用して、NACLを作成します：
aws ec2 create-network-acl --vpc-id vpc-a01106c2そして、ここでNACL用のルールを作成します：
aws ec2 create-network-acl-entry --network-acl-id acl-5fb85d36 --ingress --rule-number 100 --protocol udp --port-range From=53,To=53 --cidr-block 0.0.0.0/0 --rule-action allowただし、これは明らかではありません。AWS コンソールでは、EC2 サービスに NACL はありません。代わりに、VPC サービスの下にあります：
以下は、いくつかのNACLの例ですが、ご覧の通り、インスタンスではなく、サブネットに関連付けされています：
許可ルールしかないセキュリティグループとは異なり、NACLには許可ルールと拒否ルールの両方があることを忘れないでください：
このように、これはセキュリティグループではなくNACLであるため、許可と拒否の両方のルールを追加することができます。
AWSセキュリティグループとネットワークACLはどのように連携しているのか？
AWS セキュリティグループとAWS NACLは、単独で、または一緒にネットワークを保護するために使用することができます。ベストプラクティスに従えば、NACLとセキュリティグループはレイヤー3と4で非常に効果的な保護を提供します。ただし、大規模なDDOS攻撃や高度な攻撃からは保護されないことを忘れないでください。レイヤー3と4のこの種の保護については、AWS Shieldのようなオプションを検討することができます。レイヤー7の保護には、Webアプリケーションファイアウォールが必要です。AWS セキュリティグループとネットワーク ACLは、レイヤ7では役に立ちません。これら2つのフィルタリングサービスはどのように似ていて、どのように違うのでしょうか？見るべき重要な領域がいくつかあります：
| 領域 | AWS セキュリティグループ | AWS ネットワーク ACL |
| スコープ |
インスタンスレベルで動作 |
サブネットレベルで動作 |
| 関連 | インスタンスと関連付けられている場合にのみ適用される |
関連するサブネットにデプロイされたすべてのインスタンスに適用される（セキュリティグループのルールが寛容すぎる場合、追加の防御層を提供する） |
| 数量制限 |
インスタンスは複数のセキュリティグループを持つことができます。初期値は1VPCあたり2500ルールで、1グループあたり60ルールです |
サブネットはNACLを1つだけ持つことができます。初期枠は1VPCあたり200です |
| 送信先 |
送信先は、CIDR サブネット、特定の IP アドレス、または別のセキュリティ グループにすることができます |
送信先は CIDR サブネットのみです |
| 暗黙的な拒否 |
暗黙的なDeny。 "allow" ルールのみ追加可能です |
暗黙的なAllow。"allow"ルールと"deny"ルールを追加可能です |
| 評価順序とロジック |
すべてのルールは、トラフィックを allow または deny するかどうかを決定するために評価されます。最も寛容なルールが適用されます |
NACL のルールは、番号の小さいルールから順番に評価されます。トラフィックがルールに一致する場合、そのルールが適用され、それ以降のルールは評価されません |
| ステートフル vs ステートレス |
ステートフル：Ingress == Egress。レスポンスのトラフィックはデフォルトで許可されます |
ステートレス：Ingress != Egress。リターントラフィックはルールで明示的に許可する必要があります |
AWSセキュリティグループのステートフルな性質と、ネットワークACLのステートレスな性質を視覚化することは役に立ちます。
ここでは、ネットワークACLにアウトバウンドルールがない場合、トラフィックはアウトバウンドでブロックされますが、アウトバウンドルールを追加すると、トラフィックは正しく流れることがわかります。
一方、セキュリティグループはステートフルなため、インバウンド接続が確立されると自動的にアウトバウンドが許可されます。
AWS CIS ベンチマーク
セキュリティグループを理解しデプロイしたら、1つ以上のベンチマークと照らし合わせることを検討する必要があります。特に大規模なクラウドを使用している場合、どのセキュリティグループが正しく設定されているかを追跡することは非常に困難になります。AWS セキュリティグループの要件は、業界のベンチマークで規定されています。ここでは、2つのベンチマークについて見ていきます。ここでは、CIS AWS Foundations BenchmarkとPCI-DSS Standardの2つのベンチマークを紹介します。
CIS AWS Foundations Benchmark 1.5におけるSecurity Groupsについて
このCIS AWS Guidelines and Benchmarks 1.5には、セキュリティグループとネットワークACLについて、以下のようなコントロールが含まれています。これらの推奨事項を設定する手順を含む本ガイドの最新版を入手するには、 で更新を確認することができます。| CIS AWS 推奨事項 | 説明 |
| 2.3.3 RDSインスタンスにパブリックアクセスが与えられないようにする（自動） |
パブリックアクセス可能なRDSデータベースインスタンスへのアクセスを制限するには、データベースのPublicly Accessibleフラグを無効にし、インスタンスに関連するVPC セキュリティグループを更新する必要があります。 |
| 4.10 セキュリティグループ の変更に関するログメトリクスフィルターとアラームの存在を確認する（自動） |
セキュリティグループ への変更を監視することで、リソースとサービスが意図せずに公開されることを防ぐことができます。 |
| 5.1 0.0.0/0 からリモートサーバー管理ポートへのアクセスを許可するネットワーク ACL がないことを確認する (自動) |
SSH のポート 22 や RDP のポート 3389 など、リモートサーバー管理ポートへの無制限のアクセスを許可する NACL がないことが推奨されます。 |
| 5.2 0.0.0/0 からリモートサーバー管理ポートへの侵入を許可するセキュリティグループがないこと (自動) |
SSH のポート 22 や RDP のポート 3389 など、リモートサーバー管理ポートへの侵入を制限しないセキュリティグループ がないことが推奨されます。 |
| 5.3 ::/0 からリモートサーバー管理ポートへのアクセスを許可するセキュリティグルー プがないことを確認する (自動) |
これは上記の IPv6 バージョンです。SSH のポート 22 や RDP のポート 3389 など、リモートサーバー管理ポートへの無制限の入室を許可するセキュリ ティグループがないことを推奨されます。 |
| 5.4 すべてのVPCのデフォルトセキュリティグループがすべてのトラフィックを制限するようにする（自動） |
VPCにはデフォルトのセキュリティグループがあり、その初期設定はすべてのインバウンドトラフィックを拒否、すべてのアウトバウンドトラフィックを許可、そのセキュリティグループに割り当てられたインスタンス間のすべてのトラフィックを許可しています。 |
PCI-DSS標準におけるAWSのセキュリティグループ
Webサイトで決済カードを利用している場合、もう1つ重要な標準としてPCI標準があります。この標準は、ペイメントカードのブランドによって作成されました。準拠の検証は、毎年または四半期ごとに行われます。PCI 標準の全文は、 から入手できます。AWSのページでは、セキュリティグループルールに関する以下のPCIコントロールについて説明されており、コントロールの設定方法についての詳細が掲載されています。このページで更新を確認することができます。
| PCI DSS 要件 | 説明 |
| PCI DSS 1.2.1: カード会員データ環境（CDE）に必要なインバウンドおよびアウトバウンドトラフィックに制限し、それ以外のトラフィックを明確に拒否する。 |
PCI DSS の適用範囲にあるサービスがデフォルトのセキュリティ グループに関連付けられている場合、そのセキュリティ グループのデフォルト ルールはすべてのアウトバウンド トラフィックを許可します。また、このルールは、同じセキュリティグループに割り当てられているネットワークインターフェイス（およびその関連インスタンス）からのすべてのインバウンドトラフィックを許可します。 |
| PCI DSS 1.3.4: カード会員データ環境からインターネットへの未承認のアウトバウンドトラフィックを許可しない。 |
同上 |
| PCI DSS 2.1：システムをネットワークにインストールする前に、必ずベンダーが提供するデフォルトを変更し、不要 なデフォルトアカウントを削除または無効化する。 |
同上 |
| PCI.EC2.5： セキュリティグループは、0.0.0.0/0からポート22への侵入を許可してはならない。 |
このコントロールは、使用中の セキュリティグループ が無制限の受信 SSH トラフィックを許可しないかどうかをチェックします。 |
| PCI.RDS.2 Amazon RDS DB インスタンスは、PubliclyAccessible 構成によって決定されるパブリック アクセスを禁止する必要がある。 |
また、VPCサブネットルーティングがパブリックアクセスを許可していないこと、RDSインスタンスに関連するセキュリティグループの受信ルールが無制限のアクセス（0.0.0.0/0）を許可していないことを確認する必要があります。 |
AWSセキュリティグループのベストプラクティス
以下のベストプラクティスは一般的なガイドラインです。これらは包括的なデプロイメントガイドではなく、すべてのユースケースをカバーしていないかもしれませんが、出発点としては最適です。- セキュリティグループのルールは、大きなポートレンジを持つべきではありません。そうすると、攻撃対象が非常に大きくなります。
- VPCフローのログは、最低でもVPC間フローとインターネットフローで有効にする必要があります。同じVPC内のトラフィックをログに記録することで、デバッグに役立てることができます。詳細は、「フローログをCloudWatch Logsにパブリッシュする」を参照してください。
- 未使用のセキュリティグループを削除する。大量の未使用または未接続の セキュリティグループは、混乱を招き、設定ミスを誘発します。未使用のセキュリティグループは削除してください。
- 変更を許可されたロールのみに制限する。すべてのユーザーやIAMロールがセキュリティグループを変更できるわけではありません。
- セキュリティグループの変更を監視する。セキュリティグループがいつ作成され、いつ削除され、いつ変更されたかを知ることは、セキュリティに影響を与えるので、重要です。
- アウトバウンドルールやイグレスルールを無視しないこと。 アウトバウンドアクセスを必要なサブネットだけに制限すること。例えば、3層構造のWebアプリケーションでは、アプリケーション層はインターネットに無制限にアクセスできるようにすべきではないでしょう。そのため、アプリケーションが正しく機能するために必要なホストまたはサブネットのみにアクセスを許可するようにセキュリティグループを構成します。
AWSセキュリティグループの管理
セキュリティグループを正しく設定するためには、常に監視し、可視化する必要があります。あなたがいくつかのセキュリティグループを持っている場合、あなたはAWS CLIまたはAWS APIを使用する必要があります。
また、AWS Firewall Managerを有効にしてデプロイするオプションもあり、これはある意味この痛みに対処することができます。しかし、それは追加のコストとAWS Organizationsが必要であるなどの条件が付いています。しかし、あなたがそれを扱うことができれば、AWS Firewall Managerは、Amazon EC2、アプリケーションロードバランサー（ALB）、ENIリソースタイプの既存のセキュリティグループを監査し、新しいセキュリティグループを構成することができます。
AWSセキュリティグループの検証
クラウドの規模に関わらず、安全に設定されたセキュリティグループを手動で確認することは非常に骨が折れることでしょう。代わりに、セキュリティグループが正しく設定されているかどうかを把握するために、Cloud Security Posture Management (CSPM) ツールの利用を検討しましょう。基本的なCSPMでも役に立ちますが、カスタムポリシーを作成できる高度なポリシーツールも知っておくとよいでしょう。また、CSPMを語る上で、継続的なスキャンについても触れないわけにはいきません。継続的なスキャンは、CSPMのスキャンの間にクラウドに加えられたリスクのある変更を捕捉します。
AWS CloudTrailはデフォルトですべての変更をログに記録する素晴らしい仕事をしており、継続的なクラウド脅威の検出はこの上に構築することができます。より詳しく知りたい方は、AWS 脅威検知のブログを読んでみてください。
まとめ
セキュリティグループとNACLがどのように連携しているかを知ることは、インスタンスとサブネットへのネットワークトラフィックを制御するために非常に重要です。このことを理解していないと、困難にぶつかり、潜在的にリスクを負うことになります。正しい方法で セキュリティグループ をデプロイしたら、デプロイを検証し、脅威やドリフトがないかを確認する必要があります。1つの良いアプローチは、AWS CloudTrailログの継続的なスキャンを組み合わせたスキャンを毎日実行できるCSPMツールを使用して、セキュリティグループが追加、削除、または変更されたときに警告を出すことです。
AWS セキュリティグループとNACLsは、一度理解すれば使いこなすのは難しくありません。
この記事で紹介したAWS セキュリティグループのベストプラクティスに従って、セキュリティグループをコントロールできるようになりましょう。
AWS MarketplaceでSysdig Secure DevOps Platformをご購入ください！
Sysdigは、AWS Marketplaceで簡単にご購入いただくことができます。