【資料公開】PCI DSS 勉強会 ネットワークアクセス制御編
こんにちは、岩城です。
PCI DSS 勉強会シリーズです。
先日、社外の方（とある QSA （認定審査機関）の中の方たち）とクローズドな PCI DSS 勉強会が行われました。今回の勉強会の目的は、「PCI DSS の要件1:安全なネットワークの構築と維持」に関連する AWS のネットワークアクセス制御機能を理解することでした。本エントリでは、勉強会で利用した資料とディスカッションの内容を共有したいと思います。
合わせて弊社中山によるネットワークアクセス制御の設定を管理する方法もご確認ください。
目次
資料
勉強会内容
本日のゴール
AWS における以下のネットワークアクセス制御機能の理解を目指します。
- ネットワークアクセス制御
- ルートテーブル
- セキュリティグループ
- ネットワーク ACL
- WAF
- VPC エンドポイント
- URL フィルタリング / フォワードプロキシ on AWS
- IAM によるアクセス制御
- アイデンティティベースポリシー
- リソースベースポリシー
本エントリで扱う構成図の概要
本エントリで扱う構成図をざっくり説明します。
- アプリケーションは、WEB サーバ上で稼働しています
- アプリケーションへのリクエストは、ALB を介して WEB サーバに到達します
- WEB サーバは、メンテンスのために Bastion サーバを踏み台にSSH接続可能です
- パッケージをダウンロードおよびインストールすために NAT ゲートウェイを介してインターネットにアクセスすることが可能です
- RDS は、WEB サーバからのアクセスのみ許可し、インターネットとの接続は許可しません
- 通常インターネット経由でアクセスする S3 や SQS にプライベートアクセスします
本エントリを読み終える頃には、この構成図で考慮されているネットワークアクセス制御機能を理解できるようになるはずです。
復習
まずは、基礎となる VPC とサブネットについて復習します。
VPC
VPC は、AWS アカウント専用の仮想ネットワークであり、他の仮想ネットワークから論理的に切り離されています。VPC は同じリージョンの全てのアベイラビリティゾーンに及び、アドレス範囲を 10.0.0.0/16 のような CIDR 形式で指定して作成して利用します。
サブネット
サブネットは、VPC を分割したアドレス空間です。アベイラビリティゾーンごとに 1 つ以上のサブネットを作成します。アベイラビリティゾーンを跨いで作成することはできません。 また、サブネットには、パブリックサブネットとプライベートサブネットがあります。
パブリックサブネット
パブリックサブネットは、インターネットへ直接アクセスできるサブネットを指します。VPC からインターネットに通信するには、VPC にインターネットゲートウェイをアタッチする必要です。このため、インターネットゲートウェイにルーティングされたサブネットをパブリックサブネットと言うことができます。
プライベートサブネット
プライベートサブネットは、インターネットへ直接アクセスできないサブネットを指します。プライベートサブネット上にあるインスタンスから、インターネットへパッケージをダウンロードしたい場合があると思います。そのような場合は、NAT ゲートウェイにルーティングさせ、NATゲートウェイ経由でインターネットへアクセスします。
構成図から確認してみる
今回の構成は、マルチ AZ 構成で 3 つのサブネットに分けています。
- パブリックサブネット
- インターネットに直接アクセスするリソースをプロビジョニングするサブネット
- プライベートサブネット１
- NAT ゲートウェイを介してインターネットにアクセスする WEB サーバがプロビジョニングするサブネット
- プライベートサブネット2
- インターネットにアクセスする経路がなく、RDS をプロビジョニングするサブネット
ネットワークアクセス制御
それでは、6 つのネットワークアクセス制御を紹介していきます。
1.ルートテーブル
さらっとルーティングという言葉を使いましたが、各サブネットのトラフィックのルーティングを設定したい場合、ネットワークアクセス制御機能の一つであるルートテーブルを使用します。
ルートテーブルは、サブネット内にあるリソースがどこに通信するかのルールを定めたものです。送信先とターゲットを指定してサブネットに関連付けて利用します。注意する点としては、1 つのルートテーブルに複数サブネットを関連付けられますが、1 つのサブネットに複数のルートテーブルを関連付けることはできません。
構成図から確認する
ポイントは、インターネットに通信できる経路をルートテーブルによって、サブネットごとに管理していることです。
- パブリックサブネットのルートテーブル
- インターネットへの通信はインターネットゲートウェイにルーティングします
- プライベートサブネット 1 のルートテーブル
- インターネットへの通信は NAT ゲートウェイにルーティングします
- プライベートサブネット 2 のルートテーブル -インターネットゲートウェイや NAT ゲートウェイへルーティングされていないため、完全プライベートを実現
2.セキュリティグループ
トラフィックのルーティングはできるようになりましたが、何でもかんでも通信させたくありませんよね。そこで、送信元とポートの組み合わせでアクセス制御させる機能の一つであるセキュリティグループとネットワーク ACL を使用します。まずはセキュリティグループについて説明します。
セキュリティグループは、インスタンスに関連付けられ、インスタンスレベルのファイアウォールとして動作します。ルールの許可のみが設定でき拒否は設定できません。ステートフルであり、インバウンドで許可された通信はアウトバウンドで明示的に許可せずとも自動で許可され通信することができます。
セキュリティグループのソースには、セキュリティグループ ID を指定可能です。特定のセキュリティグループに属したインスタンスからの接続を許可、といった利用ができます。ソースに IP アドレスを指定することもできますが、通信元の IP アドレスが変わったり、通信元となるインスタンスが増減する場合、都度メンテナンスが必要となるため、明確な理由がない限り推奨しません。
構成図から確認する
| セキュリティグループ名 | 用途 | 設定内容 |
|---|---|---|
| ALB-SG | ALB用セキュリティグループ | 全ての送信元から HTTP または HTTPS 通信を許可 |
| Bastion-SG | 踏み台インスタンス用 | 特定の拠点 IP からの Bastion への SSH 接続を許可 |
| WEB-SG | WEBインスタンス用 | ALB からの HTTP 通信、Bastion からの SSH 接続を許可 |
| RDS-SG | RDS用 | WEB インスタンスからの MySQL 3306 ポートを利用した通信のみ接続を許可 |
3.ネットワーク ACL
つぎに、ネットワーク ACL について説明します。
ネットワーク ACL は、サブネットに関連付けられ、サブネットの内外のトラフィックを制御するファイアウォールとして動作します。許可および拒否ルールを設定可能です。ステートレスであるため、インバウンドだけでなくアウトバウンド共に許可しなければ通信することができません。
ネットワーク ACL のユースケースとしては、特定 IP アドレスとポートを拒否ルールとして設定しブラックリストとして利用できますが、上限緩和して最大 40 なので上限があるので注意が必要です。つぎに、セキュリティグループを削除した際、トラフィックがすぐに中断されるようにしたい場合に利用します。通常、一度確立されたコネクションはセキュリティグループが削除されても、明示的に接続断されるまで維持される。
構成図から確認する
これまで関わってきた案件などから考えると、余程の理由がない限りネットワーク ACLは設定せず、セキュリティグループで対応することが多いです。 構成図上では、デフォルトのネットワーク ACLを利用せずにサブネットごとにネットワーク ACL を作成し、全ての通信を許可しセキュリティグループでネットワークアクセス制御する形としています。
セキュリティグループとネットワーク ACL の違い
4.WAF
ここまでの説明で、通信経路や IP やポートによる通信制限を行う方法を知りました。WEB システムを運用していると本来スコープにない国からのアクセスで困るケースがありますよね。そこで利用するのが AWS WAF の Geographic 一致条件を利用します。
AWS WAF は、CloudFront、ALB、APIGateway 上で動作します。許可または拒否する WEB リクエストの条件を定義します。 定義可能な条件は以下のようなものがあります。
- 悪意のある SQL インジェクションや XSS の攻撃検知
- 送信元が特定の IP アドレスまたは IP アドレス範囲
- 送信元が特定の国
- リクエストの特定部分が指定した文字列や正規表現と一致
- リクエストが指定した長さを超えている
例えば、日本からの接続を拒否したい場合は、送信元の国に日本を設定し拒否するルールを設定します。
構成図から確認する
構成図上では、ALB に WAF をデプロイして利用します。
5.VPC エンドポイント
インターネットを経由せずに AWS サービスにアクセスしたい場合、VPC エンドポイントを利用します。
VPC エンドポイントは、インターネットを経由せずに VPC から AWS サービスへすることが可能です。VPC エンドポイントの種類は 2 つあります。
- VPC Gateway エンドポイント
- VPC Interface エンドポイント
VPC Gateway エンドポイント
S3 または DynamoDB にアクセスしたい場合に利用します。VPC エンドポイントポリシーを使用してアクセス制御することが可能です。 次の例は、すべてのユーザーやリソースからmy_secure_bucketに対し、バケット配下のオブジェクトを GET したり、新しいオブジェクトを PUT したりすることができるポリシー例です。
{
"Statement": [
{
"Sid": "Access-to-specific-bucket-only",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": ["arn:aws:s3:::my_secure_bucket",
"arn:aws:s3:::my_secure_bucket/*"]
}
]
}
VPC Interface エンドポイント
S3 や DynamoDB 以外の AWS サービスにプライベートからアクセスしたい場合に利用します。対応しているサービスは 2019 年 8 月 14 日現在 31 あります。 全てを紹介するのは難しいので気になる方は以下のドキュメントを確認してみてください。
- https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html
Gateway エンドポイントと違い VPC エンドポイントポリシーだけでなく、セキュリティグループによるアクセス制御も可能です。
構成図から確認する
構成図上では、VPC エンドポイントを利用して S3 と SQS のアクセスを想定しています。
6.URL フィルタリング / フォワードプロキシ on AWS
番外編です。 WEB サーバで利用するパッケージダウンロードのために、NAT ゲートウェイを介してインターネットにアクセスできるようになっています。このままでは、どこにでもアクセスできてしまうのでアクセス可能な URL を制御したい場合があると思います。
マネージドサービスにはこのような機能がないため、EC2 上に HTTP プロキシを構築して利用します。AWS blog にて Squid を EC2上に構築して利用するケースが紹介されています。
以前私が書いたエントリもあります。
IAM によるアクセス制御
ネットワークアクセス制御ではありませんが、マネージドサービスへのアクセス制御機能である IAM にも触れておきます。
1.アイデンティティベースポリシー
IAM ユーザー、グループ、ロールといったアイデンティティにアタッチするポリシーです。AWS 提供の管理ポリシーと自身でカスタマイズしたインラインポリシーを設定することが可能です。 次の例では、examplebucket に対してオブジェクトのリストを取得することを許可したポリシーを示しており、このポリシーがアタッチされたIAM ユーザー、グループ、ロールで有効になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::examplebucket"]
}
]
}
2.リソースベースポリシー
リソースにアタッチするポリシーです。誰がリソースにアクセスでき、どのようなアクションを実行できるか指定することができます。AWS 管理ポリシーは提供されておらず、インラインポリシーのみです。 例えば、S3バケットに対し、特定の VPC エンドポイントからのアクセスのみを許可するようなポリシーを定義することができます。
{
"Version": "2012-10-17",
"Statement": [
{
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::examplebucket",
"arn:aws:s3:::examplebucket/*"],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1a2b3c4d"
}
}
}
]
}
ディスカッション
勉強会のディスカッション内容をまとめます。
審査スコープのセグメンテーションの定義が重要
カード情報が通らないようにネットワークが分断されているようなアーキテクチャーを意識し、PCI DSS の監査対象を適切に絞ることが重要です。 QSAとディスカッションした結果、AWS上のシステムにおいてPCI DSSのネットワーク要件（要件1）に準拠するには、ルートテーブルやネットワークACLではなく、ホワイトリスト方式（デフォルトDeny）かつステーフルインスペクションが適用されているセキュリティグループの利用が一般的である、とのコメントがありました。
構成図上どこまでを DMZ とするか
事例や構成、状況で変わる可能性があるので、AWS環境における DMZ の捉え方が設計側とQSA側で違うこともあるそうです。 本事例の場合は、サブネットの名前はプライベートですが、WEBサーバまでセッションが張られるため、WEB サーバがプロビジョニングされているサブネットまでを DMZとして審査上評価するのが妥当と考えられる、とのコメントがありました。
ネットワーク装置の設定確認について
AWS では、AWS Config や CloudWatchEvents で変更を常に検知できる仕組みがあります。 PCI DSS要件（要件1.1.7）においては、少なくとも6か月ごとにルールセットをレビューすることが求められており、その目的は、本来あるべき設定値と実際の設定内容の差異がないことを確認するものなので、設定変更の検知だけでは十分ではありませんが、リアルタイムに検知が行われ、その内容が適切か判断できるプロセスがあれば要件上許容できる可能性がある、とのコメントがありました。
オンプレの NW 機器が AWS ではどのように置き換わるのかイメージし辛い
ディスカッション中には、具体的なところまで話ができませんでしたが、調べてみると良い記事を見つけました。
AKIBA.AWS 第5回 ネットワーク基礎編：「VPCをネットワーク図で理解してみる」で発表しました #akibaaws
まとめ
この度、基礎的なアクセス制御機能を紹介させていただきました。各アクセス制御機能を理解した上で、適切に利用しましょう。また、本エントリで紹介していない機能もありますし、今後のサービスアップデートや新しいサービスによりアクセス制御の考え方が変わる可能性もあります。定期的に設定したサービス内容を見直し、より PCI DSS に最適なアーキテクチャを検討しましょう。
本エントリがどなたかのお役に立てれば幸いです。
PCI DSS 勉強会シリーズ
【資料公開】PCI DSSの認証取得を目指す方へ！AWSの利用を前提としたパッチ管理について考えるクローズドな勉強会をやりました
