明確にするために編集:*バケットは、データを処理し、その一部をユーザーに表示するEC2インスタンスによって使用されます。 EC2-S3の相互作用はユーザーには見えません。 *
非常に長く複雑なURLがある場合、パブリックS3バケットが検出されないと想定できますか?
例えば s3://5eb63bbbe01eeed093cb22bb8f5acdc8/
これは「あいまいさによるセキュリティ」ではなく、「秘密によるセキュリティ」であると主張することができます。
まず、標準的な免責事項:セキュリティはオールオアナッシングの命題ではありません。匿名のお気に入り猫投票サイトのセキュリティ手順は、核サッカーのセキュリティ手順ほど厳格ではありません。 your組織のコストと使いやすさのバランスをとるセキュリティレベルを決定する必要があります。
そうは言っても、私は keithRozario's の回答に同意し、私が個人的にバケット名だけに依存しない理由に加えて、さらにいくつかの理由を説明します。
多くの研究は、すべてのデータ侵害の約半分が内部で始まることを示しています。 「public」がバケット名を推測しない場合でも、すべてのデータ侵害の半分を担当するグループ(別名:従業員)がバケットを知っている場合、これは役に立ちません名前。他と同様に、本番データが含まれている場合、本番データへのアクセスを必要とする従業員のみがアクセスできるようにする必要があります。 「秘密の」バケット名を持っているが、それを誰もが見ることができるソースコードに埋め込む場合、それは実際には秘密ではなく、実際には将来問題が発生する可能性があります。
コメントで、長いバケット名がAPIアクセス認証情報と異なる理由を尋ねました。それらが実際に非常に異なるのには非常に単純な理由があります。本番システムを担当する従業員が不満を残している場合は、彼らのアクセス認証情報を無効にし、新しい認証情報を作成して、システムを更新できます。ただし、バケットの名前を変更するのは必ずしも簡単ではありません。
それは、磁気カードエントリがある建物と単一のマスターキーの違いのようなものです。磁気カードキーを使用すると、誰かが去った場合、そのアクセスを取り消すことができます。誰もが単一のマスターキーを持っている場合は、ロックを変更し、1人が離れたときに全員のキーを置き換えるしかありません。つまり、実際にはロックは変更されません。セキュリティをバケット名に依存することは、あなたのために働くすべての人にマスターキーを配布することと同じです。いいえ、結構です。
結論として、答えはノーです。
S3バケットがパブリックであり、それをWebサイトにすると、バケット名は完全にパブリックな証明書ログに表示されます。このようなS3バケットを見つけるためだけに証明書ログをスニッフィングするツールがあります。
また、それをWebサイトにすると、共有していると思われるリンクに表示されます。
S3バケットを保護する方法は、S3バケットをプライベートにして、アクセスを必要とする特定のIAMロールへのアクセスを許可することです。長く複雑な名前に頼って単独で保護しないでください。
とはいえ、バケット内のアイテムを本当に見つけてほしくない場合は、長く複雑な名前を付けますandプライベートにします。どこかのスクリプトがどこかで公開するような場合に備えて、少なくともある程度の保護レイヤーを追加します(AWSは複雑です!)
また、S3バケットのウェブサイトを公開するための推奨される方法は通常CloudFrontです。この場合、バケットは完全に非公開のままでありながら、そのコンテンツをインターネットに公開できます。この方法では、特定の権限が付与されていないと、list buckets
のようなバケット操作を実行できません。