Amazon Web Services ブログ
Amazon S3 セキュリティベストプラクティスの実践（権限管理のポリシー) – 後編
はじめに
AWS では、サービス毎にセキュリティのベストプラクティスを公式ドキュメントとして提供しています。本記事では AWS を利用したシステムのセキュリティの検討や実装に関わる皆様を対象に、AWS の代表的なストレージサービスである Amazon Simple Storage Service (S3) を題材にとりあげて、公式ドキュメントで紹介しているベストプラクティスの実装方法をできるだけ具体的に解説したいと思います。
前編では、4つのポリシータイプとACLを中心に、S3 のセキュリティベストプラクティスを紹介しました。後編となる今回は２つのモデルケースを例に４つのポリシータイプと ACL、パブリックアクセスブロックの設定パターンを解説していきます。
ご紹介する４つのポリシータイプと用途
| アイデンティティベースのポリシー | プリンシパル (IAM ユーザ、ロール、グループ) の権限を定義 |
| リソースベースのポリシー (注釈1) | リソースへアクセス可能なプリンシパルや、利用条件を定義 |
| VPC エンドポイントポリシー | プライベートな仮想 NW から AWS サービスへのアクセス条件を定義 |
| サービスコントロールポリシー | AWS Organizations にて組織やアカウントの最大使用アクセス権限を定義 |
注釈1：リソースベースのポリシーは様々な AWS リソースで利用可能です。アタッチされるリソースによって別名で呼ばれることもあり、KMS の暗号鍵にアタッチするキーポリシーや、S3 バケットにアタッチするバケットポリシーなどがあります。各サービスの対応状況は、ユーザーガイドで調べることができます。
外部公開用データのレポジトリとして Amazon S3 を使用する
Amazon S3 はスケーラブルなデータストレージサービスです。静的な Web ホスティングサービスとして使用したり、AWS のコンテンツデリバリネットワーク (CDN) である Amazon CloudFront と組み合わせて、様々な地域にデータを公開するプラットフォームとして利用することができます。このような利用シーンを想定して外部公開用 S3 バケットを統制するポリシーの設定例を紹介します。
外部公開用 S3 バケットを統制するポリシーの構成イメージ
1. アイデンティティベースのポリシーを使用して S3 管理者の権限を統制する
どの利用パターンでも同様ですが、データの機密性や完全性を保証するために Amazon S3 の権限は必要な管理者やユーザにのみ割当たるように計画します。たとえパブリックバケットであっても、データは改ざんや意図せぬ公開から適切に保護される必要があります。Amazon S3 の操作権限は必要な管理者や利用者しか保持しないことが重要です。
アイデンティティベースのポリシーの例
以下は、図中の Contents Manager にコンテンツの管理の権限のみを許可するポリシーの例です。
Amazon S3 のバケットポリシー等はより権限の強い S3 管理者 ( 図中の S3 Manager ) が管理します。
{
"Id": "ContentManagerPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::blue_public_bucket2020"
]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": [
"s3:*Object",
"s3:*ObjectVersion",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::blue_public_bucket2020/*"
]
}
]
}2. リソースベースのポリシーと ACL でパブリック公開を制御する
S3 バケットを使用して Web サイトホスティング機能を使用するために、バケットポリシーでバケットをパブリック公開します。オブジェクトの所有アカウントが異なるケースなど、必要に応じて ACL によるパブリック公開も併用します。
バケットポリシーの例
バケットポリシーで、パブリックへの公開を許可しつつ、コンテンツ更新に関しては VPC からのみしか行えないように制限する例です。( ユーザガイド )
{
"Id": "ContentManagerPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::blue_public_bucket2020/*"
]
},
{
"Sid": "DenyContentUploadFromOutsideVPC",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::blue_public_bucket2020/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1111111"
}
}
}
]
}3. VPC エンドポイントポリシーでアクセス先バケットを制御する
外部公開用 S3 バケットに配置するデータをどのように管理するかにもよりますが、データ更新を VPC 内の EC2 インスタンスから実行するケースでは、VPC エンドポイントポリシーでアクセス可能な S3 バケットを制限することを検討します。たとえ S3 バケットを外部公開する場合であっても、VPC 内の EC2 インスタンスには公開に適さないデータが存在することもあります。VPC エンドポイントポリシーで VPC からアクセス可能な S3 バケットを制限し、外部公開用ではないデータに関して、管理外の S3 バケットへの持ち出しを抑制することができます。
VPC エンドポイントポリシーの例
VPC エンドポイント作成時にポリシーをアタッチしない場合、VPCエンドポイントにはサービスへのフルアクセスを許可するデフォルトのポリシーがアタッチされます。以下の例のように、アクセス可能な範囲を限定して書くと、所定のバケット以外へのアクセスを制限できます。( ユーザガイド )
{
"Id": "ContentManagerPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Access-to-specific-bucket-only",
"Principal": "*",
"Action": [
"s3:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::blue_public_bucket2020",
"arn:aws:s3:::blue_public_bucket2020/*"
]
}
]
}機密データのレポジトリとしてS3を使用する
Amazon S3 は前述のようにデータを外部に公開するために利用できるサービスですが、それと同時に自組織内のみで使用する機密性の高いデータの保管に利用できるサービスでもあります。Amazon S3 にはパブリックアクセスブロックなどの多層的な防御機能が実装されていますので、これらを適切に利用していく形になります。
機密データ用 S3 バケットを統制するポリシーの構成イメージ
1. アイデンティティベースのポリシーを使用して S3 管理者の権限を統制する
繰り返しになりますが、まず基本として Amazon S3 の操作権限は必要な管理者やユーザにのみ割当たるように計画します。特に機密データを Amazon S3 に配置する場合には、たとえ管理者であっても単独では外部のアカウントやパブリックにデータを公開できないように権限を分離します。後述する AWS Organizations のサービスコントロールポリシー (SCP) と組み合わせて、パブリックアクセスブロックの解除権限を S3 管理者とは別の管理者に割り当てることも可能です。S3 上のデータは暗号化して鍵のアクセス管理権限を別の管理者に割り当てるようなシナリオも検討します。
なお、バケットやオブジェクトを他アカウントやパブリックに公開するための機能として ACL がありますが、自アカウント内に限定して S3 バケットを使用する今回のユースケースでは ACL によるクロスアカウント共有は必要ありませんから、ACL 関連権限は、無用に管理者に付与しないように管理します。特にオブジェクト単位に ACL を設定すると共有状態を管理するのが煩雑になりますから、これらの機能の利用は慎重に検討します。ACL の操作権限は留保しつつ使用状況を監視したい場合には、Amazon CloudWatch などのモニタリングサービスを使用して API 実行を監視することができます。
アイデンティティーベースのポリシーの例
以下の例では、S3 管理者にデータへアクセス権限以外の管理権限のみを付与しています。
{
"Id": "S3ManagerPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllManagementActions",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Sid": "DenyObjectAccess",
"Effect": "Deny",
"Action": [
"s3:*Object",
"s3:*ObjectVersion"
],
"Resource": "*"
}
]
}2. リソースベースのポリシーでS3へのアクセスを特定 VPC 内に制限する
バケットポリシーを使用して、バケットへアクセス可能な NW を自身の特定の仮想 NW(VPC) のみに制限します。また、暗号化や多要素認証を条件に設定し、安全なアクセス手段を用いたアクセス以外は拒否するなどの実装も可能です。
バケットポリシーの例
以下の例では、VPC 外からのデータアクセスを一律で禁止し、かつ AWS Key Management Service の所定の鍵で暗号化したデータしか保管できないように設定しています。管理上の不行届などで万が一バケットが公開されてしまった場合でも、鍵が適切に管理されていればサーバサイド暗号化済みのデータは意図せぬ公開から保護されます。同時に、この暗号鍵のキーポリシーで鍵の利用者を限定すれば、S3 管理者等からもデータを保護できます。
{
"Id": "ContentManagerPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyContentUploadFromOutsideVPC",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:*Object",
"s3:*ObjectVersion"
],
"Resource": [
"arn:aws:s3:::blue_plivate_bucket2020/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1111111"
}
}
},
{
"Sid":"DenyUnEncryptedObjectUploads",
"Effect":"Deny",
"Principal":"*",
"Action":"s3:PutObject",
"Resource":"arn:aws:s3:::blue_private_bucket2020/*",
"Condition":{
"StringNotEquals":{
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:acct-id:key/key-id"
}
}
}
]
}3. VPC エンドポイントポリシーで仮想 NW からアクセス可能な S3 バケットを制限する
VPC 内の仮想サーバ（EC2 インスタンス）からデータが他アカウントやパブリックアクセス可能な S3 バケットへ持ち出されないように、VPC エンドポイントポリシーを使用して予め許可した S3 バケット以外へのアクセスを遮断します。
VPC エンドポイントポリシーの例
以下の例では、該当の仮想ネットワークから所定のバケット以外へのアクセスを制限しています。
{
"Id": "ContentManagerPolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Access-to-specific-bucket-only",
"Principal": "*",
"Action": [
"s3:*"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::blue_private_bucket2020",
"arn:aws:s3:::blue_private_bucket2020/*"
]
}
]
}4. パブリックアクセスブロックをアカウント全体に適用する
アカウント単位でパブリックアクセスブロックを有効にします。バケット単位にブロックするだけでも効果はありますが、アカウント内に管理の行き届かないバケットが存在するとそこを中継して情報が持ち出されるようなインシデントの原因になりかねません。アカウント単位でブロックを有効にしておけば、管理の行き届かないバケットが発生しないように統制できます。
また、パブリックアクセス公開や Web サイトホスティングなど、本ユースケースでは絶対に使用しない Amazon S3 の機能については、サービスコントロールポリシーでアカウント内での利用ができないように制限します。これによりたとえ S3 管理者がアイデンティティベースのポリシーにてパブリック・アクセスの設定変更の権限を持っていたとしても、それを行使できなくなります。
マルチアカウント環境のデータ共有レポジトリとして S3 を使用する
マルチアカウントのAWS環境のデータ共有レポジトリとして S3 を利用する場合でも、実施すべきセキュリティ対策の基本は前述の機密レポジトリのユースケースと変わりありません。データの内容に応じて、4つのポリシータイプと ACL、パブリックアクセスブロック、サービスコントロールポリシーを組み合わせて S3 を保護します。マルチアカウントの S3 バケットの共用方法は、バケットポリシーと ACL の2つの実装パターンがありますので、ここではその使い分けを解説します。
バケットを共有してもオブジェクトは共有しないケースでは、バケットポリシーのみを使用してクロスアカウントでのバケット共有を定義します。バケットだけでなくオブジェクトをマルチアカウントで共有する必要があり、かつ以下の条件に該当する場合は ACL を使用します。また、AWS サービスの仕様から ACL を使用しなくてはいけないケースがあります。詳しい情報は公式ドキュメントにまとめられています。
- Amazon S3 のログ配信グループに、バケットへのアクセスログオブジェクトの書き込みアクセス許可を付与する場合は、バケット ACL を使用します。本記事の執筆時点(2020年6月24日)において、バケット ACL はログ配信グループに必要なアクセス許可を付与する唯一の方法です。
- バケットの所有者が所有していないオブジェクトへのアクセスを管理する場合、バケットポリシーが適用されないためオブジェクト ACL を使用します。
まとめ
本記事では、Amazon S3 を題材にAWSのセキュリティベストプラクティスの中でも権限管理の実装について解説しました。ポリシーには、アイデンティティベース、リソースベース、VPC エンドポイントポリシー、サービスコントロールポリシーの4つの主要な形態があり、それぞれ異なる目的でセキュリティ実装の使い分けができることをご紹介しました。また、これらのポリシーを補完するパブリックアクセスブロック機能もご紹介しました。皆さまのクラウド推進にご活用いただければ幸いです。
このブログの著者
中村 賢介 (Nakamura, Kensuke)
プロフェッショナルサービス本部 セキュリティコンサルタント