機密情報を保存するAmazon S3バケットへのアクセスをホワイトリストで許可するポリシーの作成方法
Amazon S3バケットへのアクセスを保護するために、AWSは様々な選択肢を提供しており、アクセスコントロールリスト（ACL）や、IAMユーザーポリシー、S3バケットポリシーを利用できます。S3バケットポリシーでさえ、いくつかの設定の選択肢があります。例えば、AWSアカウントのリストに対してアクセス権を付与するために、デフォルト拒否のポリシーが適用される Principalエレメントを使用することができます。Principalエレメントの兄弟分であるNotPrincipalエレメントはしばしば見落とされがちですが、これを利用するとより細かく柔軟にホワイトリストを作成することができます。NotPrincipalエレメントを使って、どのユーザーも - 一部の選ばれたユーザーを除いて - 特定のリソースにアクセスできないように、明示的に設定することができます。
このブログポストでは、 機密情報が保存されたS3バケットに対して、NotPrincipalエレメントを使ってS3アクセスポリシーを作成し、ホワイトリストを作成する方法を紹介します。
Principalエレメント
以前私はこのブログで、NotPrincipalエレメントを使用するユースケースについてDive Deepしてご紹介しましたが、Principalエレメントについては初めてご紹介します。
Principalエレメントには、ユーザーやアカウント、サービスなどが指定され、これらのエンティティからリソースへのアクセスの許可・拒否がポリシーの中で定義されます。Principalエレメントは、IAMロールの信頼関係や、リソースベースのポリシー - つまりS3バケットやSQSキューのようなリソースに直接アタッチされるポリシー - の中で使われています。
Principalエレメントは、IAMユーザーやグループにアタッチされるポリシーでは使用されません。同じように、IAMロールのアクセスポリシーでもPrincipalは指定しません。これらのケースでは、Principalは暗黙的に、そのポリシーがアタッチされたIAMユーザーや、ロールがAssumeされたユーザー(ロールアクセスポリシー)とみなされます。ポリシーがIAMグループにアタッチされていれば、リクエストを要求するグループのメンバーがPrincipalとなります。
NotPrincipalエレメントの使い方
NotPrincipalエレメントを使って、Principalエレメントのリストに対する例外を指定することができます。例えば、特定のアカウント以外の全AWSアカウントを許可することができます。逆に、NotPrincipalエレメントで指定された以外のユーザーのアクセスを全て拒否することもできます。Principalエレメントと同じように、権限を許可・拒否するユーザーかアカウントを指定します。違いは、NotPrincipalエレメントは、指定したユーザーかアカウント“以外”の全てに適用される、という点です。明示的に特定のリソースに対するアクセスを許可するIAMユーザーポリシーと同時に使用された場合は、NotPrincipalエレメントにより、 必要なパーティだけがS3バケットのセンシティブな情報にアクセスできるように、確実に保護することができます。
NotPrincipalエレメントの効果的な使い方として、S3バケットに統合されたクレデンシャル(認証情報)ストアを作成する、というものがあります。統合管理されたクレデンシャルストアを作成したい場合には、不正な利用からクレデンシャルを確実に保護しなければなりません。S3は、複数の仕組みでネイティブにデータ保護の機能を提供します。このポストでは以下の機能の詳細は解説しませんが、有効にすることを推奨します。
- S3サーバーサイド暗号化は、保存されたクレデンシャルを保護するのに役立ちます。
- バージョニングは、ファイルに対する変更をキャプチャするのに役立ちます。
- サーバーアクセスのロギングは、クレデンシャルへのアクセス要求を追跡するのに役立ちます。
- IAMユーザーポリシーは、認可されたユーザーのみがバケット設定を変更できるように制限するのに役立ちます。
暗号化された通信（HTTPSなど）からのみバケットにアクセスできるようにするのがベストプラクティスであり、S3バケットポリシーでこれを強制することもできます。
バケットが作成されて適切に設定された後、この新しいクレデンシャルストアを運用・利用するために必要なIAMロールの検討が必要です。このユースケースの目的を考慮して、次の2つのアクセスレベルを作成することにします。
- クレデンシャル管理者
- クレデンシャル利用者
クレデンシャル管理者ロールには、バケットに新しいクレデンシャルやキーファイルを配置できるように、READおよびWRITEのアクセス権が付与されます。クレデンシャル利用者は、特定のバケットディレクトリに対して、READアクセスのみを持ちます。このブログポストの目的から、クレデンシャル管理者には、バケット内の全サブディレクトリに対するアクセス許可を付与することにします。より細かくアクセスを制御したい場合は、クレデンシャル管理者の権限を、特定のサブディレクトリに制限することもできます。さらにセキュリティを高めるために、クレデンシャル利用者ロールに、多要素認証（MFA）による認証を強制することも有効です。
S3リソースポリシーから始めましょう。はじめに、クレデンシャル管理者(CredMgr)とクレデンシャル利用者(CredUsr)の両者に、クレデンシャルバケット(CredentialBucket)を参照するための権限を付与します。DenyステートメントとNotPrincipalエレメントを使って、ポリシーに明示的にリストされた対象に対してのみ、S3バケットのクレデンシャルへのアクセスを許可します。リソースポリシーは以下のようになるでしょう（赤字のテキスト部分は、組織固有の情報に置き換えてください）。
{
"Sid": "ListRelevantDirectories20150907",
"Effect": "Deny",
"NotPrincipal": {
"AWS": [
"arn:aws:iam::123456789012:role/CredMgr",
"arn:aws:iam::123456789012:role/CredUsr",
"arn:aws:sts::123456789012:assumed-role/CredMgr/Mgr1",
"arn:aws:sts::123456789012:assumed-role/CredUsr/User1",
"arn:aws:sts::123456789012:assumed-role/CredUsr/User2"
]
},
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::CredentialBucket"
}
これで、認可されたユーザーがCredentialBucketを見られるようになったので、次にCredMgrユーザーが、バケットにオブジェクトをPUTし、バケットからオブジェクトをGETできるようにしなければなりません。以下のポリシーによって、このロールがバケットに保存されたクレデンシャルを更新できるようになります。
{
"Sid": "UseRelevantDirectories20150907",
"Effect": "Deny",
"NotPrincipal": {
"AWS": [
"arn:aws:iam::123456789012:role/CredMgr",
"arn:aws:sts::123456789012:assumed-role/CredMgr/Mgr1"
]
},
"Action": [
"s3:PutObject",
],
"Resource": "arn:aws:s3:::CredentialBucket/*"
}
最後に、クレデンシャル利用者とクレデンシャル管理者が、許可された特定のサービスのクレデンシャルを取得できるように、ポリシーを作成する必要があります。
{
"Sid": "ReadOnlyServiceB20150522",
"Effect": "Deny",
"NotPrincipal": {
"AWS": [
"arn:aws:iam::123456789012:role/CredUsr",
"arn:aws:sts::123456789012:assumed-role/CredUsr/User2"
"arn:aws:iam::123456789012:role/CredMgr"
"arn:aws:sts::123456789012:assumed-role/CredMgr/Mgr1"
]
},
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::CredentialBucket/ServiceB/*"
}
それぞれのポリシーで、NotPrincipalエレメントとDenyステートメントが組み合わせられていることに注意してください。これにより、IAM管理者が、CredentialBucketにアクセスできる新しいIAMユーザーやIAMロールを作成したとしても、それらのユーザーやロールは、明示的にホワイトリストとしてアクセスを許可されていないので、機密レベルの高いクレデンシャル情報にアクセスすることはできません。上のポリシーのNotPrincipalエレメントの中に、IAMロール(CredMgr と CredUser)だけでなく、CredMgrとCredUserロールが割り当てられたユーザーにSTSが生成するARNが定義されていることにも注意してください。NotPrincipalエレメントが正しく動作するには特定のARNを指定する必要があるので、それらの設定が必要なのです。
S3バケットに保存された機密情報のセキュリティを確保するための方法は多くあります。NotPrincipalエレメントも、AWS上にセキュアにリソースをデプロイするための方法の1つです。
コメントや質問があれば、コメント欄またはIAMフォーラムにお願いします。
- Matt
（翻訳はSA国政が担当しました。原文はこちら。）
コメント