しがないインフラエンジニアYasです。
ずぶずぶのオンプレインフラエンジニア（という名の何でも屋）だったのですがお仕事をきっかけにどっぷりAWSに浸かる事になりました。
そんな訳で過去の失敗を糧に色々書いていこうと思います。
Qiita投稿が初めてな上、技術投稿自体も初めてですので色々と表示や表現がおかしいところが多々あるかと思いますが、暖かい目で見守っていただければ幸いです。
すでにMarkdownで四苦八苦です・・・
さて、本日のお題は「S3」です。
S3の説明は公式サイトやいろんなブログで記載されているので割愛して、今回はセキュリティアンチパターンに着目します。
###１：気がついたら全公開 BucketPolicy編
BucketPolicyというS3のセキュリティ設定箇所があるのですが、いろんなブログのPolicy記載例をそのまま鵜呑みにして貼り付けるといつのまにやら全公開。
＜PolicyPattern＞
{ "Version":"2012-10-17", "Statement":[ { "Sid":"sid12345", "Effect":"Allow", "Principal": "*", ←これ "Action":["s3:*"], "Resource":["arn:aws:s3:::examplebucket/*"] } ] }
Principal意識しないと全公開したりします。
たまに昔のブログで見かけたりしますが、初心者トラップだなーと。
最近はコンソール画面上でパプリックアクセス可能なものはマークがでるので、意図しない場合は要チェックです。
↓こんな感じでPublicだよ！とお知らせしてくれます。
###2:気がついたら全公開：ツール編
S3へのファイルアップロードにCyberDuckとか使っている人もいるかと思います。
一部のバーションの頃ファイルパーミッション変更オプションで「パブリック」にしちゃってる場合がありました。
デフォルトなのかアップデートなのか仕様なのか・・・・
いろんな事情でPutObjectACLを付与しちゃってるときは注意しましょう。（やりがちなのは”Put*”で権限付与とか・・・）
↓事例はCyberduckです。いいツールデスYO！
ちなみにファイル単位で許可されている時は、コンソール上からは分かりません。（現時点では）
思わぬところで落とし穴がある場合がありますので、適宜見直ししましょう。
セキュリティに気をつけて、良いAWSライフを！
おまけの独り言：
AssumeRoleでAccessKeyを付与している時はPut先のAWSアカウントが異なると権限の関係で色々支障が出ちゃうんですよね。なのでPutObjectACLが必要になるというジレンマ。
原因はおそらくAssumerole先のオブジェクトに対し、Assume元のアクセス権限しか付与されないからだと思いますが・・・