IAMアクセス許可またはバケットポリシーによるAWS S3リソースアクセスコントロール？
組織でバケットを作成し、その周りに正しいACLを確保する方法は、S3バケットをプロビジョニングする自動ツール（内部でTerraformを使用）を提供することです。したがって、ユーザーがtestBucketという名前の新しいバケットをリクエストすると、testBucketという名前のバケットが作成され、testBucket-userという名前のIAMユーザーも作成されます。自動化により、testBucket-userのポリシーは、このユーザーに対して許可されるアクションのみが次のようになるようになっています。
"s3:ListBucket",
"s3:PutObject",
"s3:GetObject"
上記のアクションが許可される唯一の許可されたリソースは、testBucketバケットです。
同様に、自動化は、自動化がバケットポリシーを配置することを保証し、その上で許可される唯一のアクションが上記の3つのアクションであり、ユーザーのみが保証するようにしますtestBucket-user
ただし、必要に応じて（ビジネス上正当な場合は）、作成されたバケットポリシーを必要に応じて変更します。そのため、最近、そのような要件が1つありました。特定のバケットには、公的に意図されたすべての画像を保持するためのフォルダーを含める必要がありました。
上記の要件をプロビジョニングするために、2つのオプションがありました。
- バケットポリシーを変更して、バケット内のフォルダに対して
principal:*を許可し、バケット内のそのフォルダ内のすべてのオブジェクトをデフォルトでパブリックにできるようにします。 - そのバケットにアクセスできるIAMユーザーにPutObjectACLアクセス許可を変更して付与し、開発者がフォルダー内のどのオブジェクトを公開できるか、または公開できないかを管理できるようにします。
セキュリティチームとして、私たちは最初のオプションがより論理的に見えたという理由だけで、より確信していました。ただし、最初のオプションの問題は、このフォルダー内のすべてのオブジェクト（公的に意図されているか、それ以外の場合でも）がデフォルトでパブリックになることです。
コミュニティはこのあたりでどう思いますか？ AWS/IAMエキスパート、上記の2つのオプションからどのようなものを選択しますか、またその理由は何ですか？
次の方法でS3バケットまたはオブジェクトへのアクセスを制限します。
- 特定のバケットやオブジェクトにアクセスできるユーザーを指定するAWS Identity and Access Management（IAM）ユーザーポリシーを記述します。 IAMポリシーは、複数のユーザーのAmazon S3アクセス許可をプログラムで管理する方法を提供します。ユーザーポリシーの作成とテストの詳細については、 AWS Policy Generator および IAM Policy Simulator を参照してください。
- 特定のバケットおよびオブジェクトへのアクセスを定義するバケットポリシーを記述します。バケットポリシーを使用して、AWSアカウント全体にアクセスを許可し、パブリックまたは匿名のアクセス許可を付与し、条件に基づいてアクセスを許可またはブロックできます。バケットポリシーの作成とテストの詳細については、 AWS Policy Generator を参照してください。 [[注：ユーザーがIAMでアクセスを許可されている場合でも、バケットポリシーで拒否ステートメントを使用して、特定のIAMユーザーへのアクセスを制限できます。ポリシー。]]
- Amazon S3 Block Public Accessを使用して、パブリックアクセスを集中的に制限します。パブリックアクセスのブロック設定は、バケットポリシーとオブジェクト権限をオーバーライドします。パブリックアクセスを許可しないすべてのアカウントおよびバケットに対して、必ず[パブリックアクセスのブロック]を有効にしてください。
- バケットとオブジェクトの設定アクセス制御リスト（ACL）。 [[注：アクセス許可をプログラムで管理する方法が必要な場合は、ACLの代わりにIAMポリシーまたはバケットポリシーを使用してください。ただし、バケットポリシーが最大ファイルサイズの20 KBを超える場合は、ACLを使用できます。または、ACLを使用して、Amazon S3サーバーアクセスログまたはAmazon CloudFrontログへのアクセスを許可できます。]]
追加ポイント！
ポリシー、パブリックアクセスのブロック、ACLの使用に加えて、次の方法で特定のアクションへのアクセスを制限することもできます。
- MFA Delete を有効にします。これにより、ユーザーはオブジェクトを削除する前に多要素認証（MFA）デバイスを使用して認証する必要があります。バケットのバージョン管理を無効にします。
- MFAで保護されたAPIアクセス をセットアップします。これは、ユーザーが特定のAmazon S3 APIを呼び出す前にAWS MFAデバイスで認証する必要があります操作。
- S3オブジェクトを別のユーザーと一時的に共有する場合は、署名済みURLを作成して、オブジェクトへの時間制限付きアクセスを許可します。詳細については、「 オブジェクトを他のユーザーと共有する 」を参照してください。
参照リンク：https://aws.Amazon.com/premiumsupport/knowledge-center/secure-s3-resources/
それがあなたの質問への答えではないことはわかっています-しかし、一般公開されているアイテム用に完全に別個のバケットを用意することは、バケット内の単一のフォルダーを制限することよりも意味があると思います。バケットは自由に作成できます。したがって、暗号化、ストレージ、アーカイブ、ライフサイクルの要件が異なる可能性が高いため、すべてのプライベートオブジェクトとパブリックオブジェクトを1つのバケットに保持する価値はほとんどありません。
公開されている画像は、S3 API経由でアクセスされる可能性は低く、http経由である可能性が高いため、Cloudfront経由でのS3アクセスを制限し、http経由でバケットへのすべての相互作用を制限することをお勧めします-公開する必要があります。
最後に、本当に必要な場合は、問題のフォルダにprincipal:*を配置する傾向があります。これにより、簡単に検出して一目で確認できます。バケットポリシーでは、この「フォルダー」内のオブジェクトに対してs3:GetObjectのみを許可する必要があります。また、s3:ListBucketは、バケット内のフォルダだけでなく、バケット全体にも適用されます。注意してください。
S3にはファイルシステムがないことを思い出してください。S3は単にフォルダーのように見えますが、S3は内部でfolder/itemのキーを解析してフォルダー内のアイテムのように見えます。
私自身はS3の専門家ではないと思いますが、いくつかの理由から、最初のオプションの方が意味があると思います。最も重要なのは、開発者が必然的に間違ったACLを設定し、パブリックアクセスを許可することです。悪意からではなく、怠惰からではなく、無知からです（たとえば、あなたの会社の開発者の離職率は何ですか？.
したがって、very重要な点は、実際には両方を実行できることです（バケットポリシー+ IAM）。これは、推奨される安全なアプローチだと感じています。ユーザーは、バケットポリシーとIAMを介して割り当てられた権限の共通部分である操作のみを実行できます。これについて私が好きなのは、それが可能なことへの境界を提供することですが、バケット自体に適用されます。私の提案は、バケットをロックしたままにすることですが、フォルダーへのパブリックアクセスのみを許可し、おそらくパブリックフォルダー内のオブジェクトに対するPutObjectACLを許可します。
わずかに正接しているが関連性が高い場合は、cloudfrontを使用できるため、S3バケットの名前が明らかになることはありません。さらに、cloudfrontにパブリックフォルダーへのアクセスのみを許可できます。このようにして、バケットはロックされたままになり、cloudfrontはパブリックフォルダーのみに制限されます。