AWSとGitHub Actionsの責任境界と 組織で安全に使用する取り組み

JAWS-UG 東京 ランチタイム LT 会 #38
資料です。

Transcript

1. JAWS-UG 東京 ランチタイム LT 会 #38 AWSとGitHub Actionsの責任境界と 組織で安全に使⽤する取り組み 〜 AWS が守ってくれる範囲と、GitHub 側で閉じる範囲 〜 株式会社ニーリー ⼤⽊ 建⼈ 2026.08.26 1
2. ⾃⼰紹介 ⼤⽊ 建⼈ / Kento Ogi 株式会社ニーリー プロダクト統括本部 プラットフォームエンジニアリング G SRE / プラットフォームエンジニアリング チームリーダー @2357gi 好きな AWS サービス 趣味 AWS Snowball 🧗 ボルダリング / 🏂 スノーボード 2
3. アジェンダ 01 必須要件を3つに整理する 02 AWS はどこまで強制できるのか 03 GitHub 側で組織全体に強制する 3
4. 必須要件を3つに整理する GitHub Actions は AWS 本番環境への最短経路 workflow ファイルの中⾝が AWS の認可境界の⼀部になっている。.github/workflows/*.yml を書き 換えられる⼈は、AWS 本番に⼿が届く。 GITHUB リポジトリ .github/workflows/deploy.yml OIDC TOKEN → ⼀時 credentials sts:AssumeRoleWithWebIdentity AWS → IAM ロール → 本番リソース 4
5. 必須要件を3つに整理する GitHub Actions から AWS を操作する上で考える必須3項⽬ 必須A 必須B 必須C ⻑期アクセスキーを使わない 信頼ポリシーを適切に絞る OIDC で⼀時 credentials を使う OIDC role ⽤の信頼ポリシーを branch や tag などに絞る 使う Actions を commit SHA で pin タグ参照をやめる 5
6. 必須要件を3つに整理する なぜ SHA pin が AWS の話になるのか タグは動く。SHA は動かない。 CVE-2025-30066 / tj-actions/changed-files 2025.03.14–15 v1〜v45.0.7 のタグが悪性コミットに張り替え 影響 ランナーのメモリから資格情報を抜いてログに出⼒ 規模 23,000+ リポジトリが利⽤ / CISA KEV 登録 修正 v46.0.1 AWS への接続 侵害された Action は、そのジョブが持つ AWS への到達 ⼿段（OIDC トークン、または Secrets の⻑期キー）に ⼿が届く。 必須A を守っていれば、盗まれるのは短命トークンだけ で済む。必須A と必須C は相互補完。 6
7. アジェンダ 01 必須要件を3つに整理する 02 AWS ではどこまで強制できるのか 03 GitHub 側で組織全体に強制する 7
8. AWS はどこまで強制できるのか 必須B 信頼ポリシーを適切に絞る では、AWS はどこまで守ってくれるのか “IAM checks the role trust policy condition to verify that the condition key token.actions.githubusercontent.com:sub is present and that its value is not solely a wildcard character (* and ?) or null. ... If the condition key ... is not present, or the key value doesn't satisfy the mentioned value criteria, the request will fail and return an error. ” → sub 条件が無い、または * だけの信頼ポリシーは、AWS が作成 そのものを拒否する 作成が拒否される "StringLike": { "&&.:sub": "*" } 通ってしまう "StringLike": { "&&.:sub": "repo:my-org&*:*" } 8
9. AWS はどこまで強制できるのか 必須B 信頼ポリシーを適切に絞る では、どう設定するのが望ましいのか "Condition": { "StringEquals" : { "&&.:aud": "sts.amazonaws.com", "&&.:sub": "repo:my-org/my-app:ref:refs/heads/main" } } 1 リポジトリ単位ではなく ref 単位 で書く。デプロイを許すブ 2 StringLike ではなく StringEquals で完全⼀致にす 3 aud も条件に加え 4 ロールは環境ごとに分ける 。1本のロールを全リポジトリで ランチ∕タグを1つに絞る る る 共⽤しない 9
10. AWS はどこまで強制できるのか AWS が強制できるもの / できないもの 必須要件 AWS 側から強制できるか 信頼ポリシーの sub を絞る ◎ IAM が作成を拒否する 使うリージョンを絞る ◎ SCP（aws:RequestedRegion） ロールは最⼩権限 ◎ 権限境界 必須A ⻑期キーを使わない × できない 必須B 信頼ポリシーを適切に絞る △ 最低限までは必須化されている 必須C Actions を SHA で pin × できない 必須A‧B‧C は AWS からは閉じきれない。しかも3つとも workflow ファイルの静的検査で判定できる。 9
11. GitHub 側で組織全体に強制する workflow ファイルを読むだけで判定できる 必須A｜⻑期アクセスキーの持ち込みを禁⽌ grep -rn 'aws-access-key-id\|AWS_SECRET_ACCESS_KEY' .github/workflows/ && exit 1 必須C｜SHA pin されていない uses を検出 grep -rhoP 'uses:\s*\K[^@]+@\S+' .github/workflows/ | grep -vP '@[0-9a-f]{40}$' && exit 1 12
12. アジェンダ 01 必須要件を3つに整理する 02 AWS はどこまで強制できるのか 03 GitHub 側で組織全体に強制する 10
13. GitHub 側で組織全体に強制する リポジトリ単位の設定では新規リポジトリで漏れる 検査を各リポジトリの CI に置く運⽤は、リポジトリが増え続ける組織では必ず漏れる。 テンプレートリ ポジトリは配った時点から古くなってしまう。 既存リポジトリ 検査あり 今⽇作られたリポジトリ 素通し 検査あり 検査あり 検査あり 11
14. GitHub 側で組織全体に強制する GitHub Organization Ruleset で組織全体に強制する 中央リポジトリ（organization-ci-repo）に検査 workflow を1つ置く Organization Ruleset で、その workflow の成功をマージ条件にする 対象は名前パターン / visibility / custom property で動的に指定 → 新規リポジトリも作成時点から⾃動で対象 bypass は明⽰的に管理される（誰が例外かが設定として⾒える） 前提: Organization レベルの ruleset は GitHub Team 以上（2025年6⽉に Enterprise 限定から開放） 13
15. まとめ 左と右で挟む GITHUB Organization Ruleset AWS → CI/CD パイプライン マージさせない ← IAM 信頼ポリシー / SCP assume させない‧触らせない 1 workflow ファイルは IAM 権限設定の⼀部。レビュー対象として扱う 2 AWS が強制してくれるのは sub の1点だけ。⾃分の信頼ポリシーが repo:org/*:* になっていないか確認する 3 AWS から閉じられない必須要件は、GitHub Organization Ruleset で組織全体に強制する 関連記事（ニーリー開発者ブログ） nealle-dev.hatenablog.com/entry/2026/07/28/114424 14