SW BBANG J

EC2上のアプリケーションにS3アクセスを与えようとしたとき、最初に思いつくのは「IAM Userを作ってアクセスキーを発行すればいい」という方法だ。実際、多くの現場でこのパターンが使われてきたが、これは後になって必ず問題を起こす。IAM UserとIAM Roleの違いを正確に理解していないと、セキュリティインシデントの温床になる設計を量産することになる。 TL;DR — IAM UserとIAM Roleの比較 観点 IAM User IAM Role 認証方式 長期クレデンシャル（アクセスキー／パスワード） 一時的なSTSトークン（自動ローテーション） 主な用途 人間のオペレーター、CLIを使う開発者 AWSサービス、アプリケーション、クロスアカウントアクセス EC2からS3アクセス 非推奨（アクセスキーをインスタンスに配置するリスク） 推奨（インスタンスプロファイル経由で自動取得） クレデンシャル管理 手動ローテーションが必要 STSが自動でローテーション 最小権限の実装 ユーザー単位またはグループ単位 ロール単位、引き受けるエンティティを信頼ポリシーで制御 IAM UserとIAM Roleの仕組みを理解する IAM Userは「人」に対応するアイデンティティだ。ユーザー名とパスワード、またはアクセスキーID／シークレットアクセスキーというロングタームクレデンシャルを持つ。このクレデンシャルは明示的にローテーションしない限り有効であり続ける。 IAM Roleはそれとは根本的に異なる。Roleは「引き受けるもの」であり、それ自体はクレデンシャルを持たない。エンティティ（EC2インスタンス、Lambda関数、別アカウントのユーザーなど）がRoleを引き受けると（AssumeRole）、AWS Security Token Service（STS）が一時的なクレデンシャルを発行する。このトークンは有効期限付きで、自動的に更新される。 IAM Userのアクセスキーは、金庫の鍵を複製して誰かに渡すようなものだ。IAM Roleは、必要なときだけ開く電子錠に近い。鍵そのもの...

カスタムVPCを作成してパブリックサブネットにEC2インスタンスを起動したのに、 ping google.com が通らない。この問題はVPC構築時に最もよく遭遇するトラブルで、原因はほぼ必ずInternet GatewayのアタッチかRoute Tableのルート設定の抜け漏れにある。デフォルトVPCと違い、カスタムVPCはこれらのリソースを明示的に構成しなければインターネット疎通は一切得られない。 TL;DR — EC2インターネット接続不可の原因と対処 確認レイヤー よくある原因 対処 Internet Gateway 作成済みだがVPCにアタッチされていない IGWをVPCにアタッチ Route Table 0.0.0.0/0のルートが存在しない IGWへのデフォルトルートを追加 サブネット関連付け パブリックサブネットがカスタムRoute Tableに関連付けられていない サブネットをRoute Tableに明示的に関連付け パブリックIPアドレス インスタンスにパブリックIPが割り当てられていない サブネットの自動割り当て設定を有効化、またはElastic IPを割り当て Security Group アウトバウンドルールが制限されている アウトバウンド0.0.0.0/0を許可 Network ACL サブネットレベルのACLがトラフィックを拒否している インバウンド/アウトバウンドルールを確認 カスタムVPCのインターネット接続がどのように機能するか デフォルトVPCはAWSが自動的にIGWのアタッチとRoute Tableの設定を済ませた状態で提供される。カスタムVPCにはそれがない。EC2インスタンスがインターネットに到達するには、パケットが通過しなければならないレイヤーが複数存在する。 graph LR EC2["EC2インスタンス パブリックIP必須"] --> SG["Security Group ステートフル"] SG --> NACL["Network ACL ...

新しいEC2インスタンスを起動してSSH接続を試みたとき、 ssh: connect to host xx.xx.xx.xx port 22: Connection timed out というエラーで止まった経験は多くのエンジニアにある。アプリケーションのエラーではなく、パケットがインスタンスに届いていないことを示すタイムアウトだ。原因の大半はセキュリティグループのインバウンドルール設定にあるが、それだけで解決しないケースも存在する。 TL;DR — EC2 SSHタイムアウトの主な原因と対処 原因レイヤー 確認項目 修正方向 セキュリティグループ ポート22のインバウンドルールが存在するか TCP 22をソースIPに対して許可 ネットワークACL サブネットレベルでポート22がブロックされていないか インバウンド/アウトバウンド両方のルールを確認 パブリックIPアドレス インスタンスにパブリックIPが割り当てられているか ElasticIPの関連付けまたはパブリックIP自動割り当ての有効化 インターネットゲートウェイ VPCにIGWがアタッチされているか IGWを作成してVPCにアタッチ ルートテーブル サブネットのルートテーブルに0.0.0.0/0 → IGWのルートがあるか デフォルトルートをIGWに向ける EC2 SSH接続の仕組み — パケットが届くまでの経路 SSHタイムアウトを正確に診断するには、クライアントのパケットがEC2インスタンスに到達するまでに通過するレイヤーを理解する必要がある。セキュリティグループだけを見て終わりにすると、別のレイヤーでブロックされているケースを見逃す。 graph LR Client["クライアント ローカルマシン"] -->|"TCP SYN port 22"| IGW["インターネット ゲートウェイ (IGW)"] IGW --> RT["ルートテーブル 0.0.0.0/0 → IGW"] RT --> ...

S3に画像をアップロードしてオブジェクトACLを「public-read」に設定したのに、URLにアクセスすると「Access Denied」が返ってくる。オブジェクト単体の設定は正しいはずなのに、なぜ拒否されるのか——この問題の原因はほぼ確実に、バケットレベルの「Block Public Access」設定にある。オブジェクトACLより上位のレイヤーが存在することを知らないと、何度設定を変えても解決しない。 TL;DR：S3パブリックアクセス拒否の原因まとめ 確認レイヤー 設定項目 影響範囲 アカウントレベル S3 Block Public Access（アカウント全体） 全バケットに適用 バケットレベル S3 Block Public Access（バケット個別） そのバケット内の全オブジェクト バケットポリシー Principal: * を許可するポリシーの有無 ポリシーで指定したリソース オブジェクトACL public-read ACL 個別オブジェクト 結論： オブジェクトACLを「public-read」にしても、バケットまたはアカウントレベルの「Block Public Access」が有効な場合、そのACLは無効化される。上位レイヤーの設定が下位を上書きする構造になっている。 S3パブリックアクセス制御の仕組み：なぜオブジェクトACLだけでは不十分か S3のアクセス制御は複数のレイヤーが重なって機能する。オブジェクトACLはその中で最も下位のレイヤーに位置する。AWSは2018年以降、誤ったパブリック公開によるデータ漏洩を防ぐため「Block Public Access」という上位の制御機構を導入した。この設定が有効な場合、オブジェクトACLやバケットポリシーで「public」を許可しようとしても、Block Public Accessがそれを遮断する。 Block Public Accessには4つの独立した設定項目がある。それぞれが異なるシナリオをカバーしており、全部オフにしないとパブリックアクセスが通らないケースもある。 graph TD A[...