面倒なことは AWS CDKにやらせよう

2025/04/12（土）開催の「JAWS-UG 北陸新幹線 #3 in 上越妙高」および 2025/04/12（土）開催の「JAWS-UG浜松+Hamamatsu.js 勉強会202504」における私の発表「面倒なことは AWS CDKにやらせよう」の発表スライドです。

#jawsug #jawsug_niigata #jawsug_北陸新幹線
#jawsug_hamamatsu

Transcript

1. 面倒なことは ChatGPT AWS CDKにやらせよう KDDIアジャイル開発センター 名古屋オフィス 鈴木 正樹
2. 1 KDDI Agile Development Center Corporation 自己紹介 ◼ 氏名：鈴木 正樹 ◼ 所属：KDDIアジャイル開発センター（KAG） 名古屋オフィス ◼ 役割：クラウドアーキテクト ＆ バックエンドエンジニア AWS（特にサーバーレスやInfrastructure as Code）が大好きで、主にそれらに関する 情報発信を積極的に行っています。 好きなサービスはAWS LambdaとAWS CDKで、主にJAWS-UG名古屋 ＆ JAWS-UG CDK支部で活動。 ◼ Certification： ◼ AWS Solution Architect Associate（2023） ◼ AWS Community Builder（2023～） ◼ : @makky12（SUZUKI Masaki@クラウドエンジニア） ◼ Blog：https://makky12.hatenablog.com/
3. 2 KDDI Agile Development Center Corporation 本日のアジェンダ • はじめに • AWS CDKで楽にアクセス設定を行う • まとめ & 告知
4. 3 KDDI Agile Development Center Corporation 注意事項 ※IAM = Identity and Access Management の略です。（以後「IAM」と記載します） お話しすること • IAM Policyによるアクセス設定の難しさ • AWS CDK（以下「CDK」と略記します）で楽にアクセス設定を行う方法 お話ししないこと • IAM及びCDKの基本的な説明や使用方法など（公式ドキュメント、およびCDK公式リファレンスを参照ください） その他 • 発表資料・発言内容は、すべて個人の見解・知見になります • IAM及びAWS CDKの正式な情報は、AWS公式サイトをご確認ください
5. 4 KDDI Agile Development Center Corporation はじめに
6. 5 KDDI Agile Development Center Corporation はじめに AWSで「面倒なこと」 それは…
7. 6 KDDI Agile Development Center Corporation はじめに ※個人の感想です IAM Policyでのアクセス設定！
8. 7 KDDI Agile Development Center Corporation IAM Policyでのアクセス設定の難しさ • IAM PolicyはAWSのセキュリティにおいて、基本にして非常に重要な要素 • 一つ設定をミスるだけで、本来許可してはいけないアクセスを許可してしまう事態が起こりうる ◦ IPAの「情報セキュリティ10大脅威 2024(※1)」でも「不注意・設定不備による情報漏洩などの被害」は6位に ランクインしている • にもかかわらず、IAM Policyは慣れないとなかなか設定が難しく、想定外のアクセス許可をしがち（※2） ◦ 実際、JAWS DAYS 2025で株式会社SHIFTさん（ゴールドスポンサー）が実施した「クラウドで大変なこと」 アンケートでも「セキュリティなどの設定」に多数の票が集まっていた（私も投票した） ※1：https://www.ipa.go.jp/security/10threats/10threats2024.html ※2：単純なPolicyならともかく、色々条件が絡むと…（まず「Principal」や「Allow/Denyの挙動」の理解が大変）
9. 8 KDDI Agile Development Center Corporation 余談 ※個人的な宣伝ですが… • 「『Allow/Denyの挙動』の理解やIAM Policyの判定フロー」については、2/25開催の「JAWS-UG 名古屋 2月会 『アクセス権限管理の解体新書』」において、私が「IAMポリシーのAllow/Denyについて、改めて理解する」とい うLTを行っているので、よろしければそちらをご参照ください。（発表資料もSpeaker Deckに公開済みです） https://speakerdeck.com/smt7174/denynituite-gai-meteli-jie-suru
10. 9 KDDI Agile Development Center Corporation 閑話休題 アクセス設定、もっと楽できないの？
11. 10 KDDI Agile Development Center Corporation 本題 できるんです。 そう、AWS CDKならね
12. 11 KDDI Agile Development Center Corporation AWS CDKで楽にアクセス設定を行う
13. 12 KDDI Agile Development Center Corporation AWS CDKで楽にアクセス設定を行う 「grantXXX」メソッドの利用 • AWS CDKでは、大半のリソースに「grantXXX」というメソッドが用意されており、これを使用することでIAM Policyを自分で定義することなくアクセス設定が行える • 一例として、下記のようなメソッドが用意されている（リソースにより異なる） ◦ grantReadData/grantReadWrite：読み取りアクセス/読み書きアクセスのみ許可する ◦ grantFullAccess：読み取り＆書き込みを始め、全アクションを許可 etc. • CDKでの具体的な使用法は、下記ソースを参照 // grantXXXメソッドの使い方は下記の通り。 // 「アクセス先のリソース」は主にDBやストレージ、「アクセス元のリソース」は主にIAM UserやLambda関数などが該当。 // ちなみに「アクセス元のリソース」にIAM PolicyやIAM Roleを指定することもできます。(IGrantableインターフェースを実装しているので) アクセス先のリソース.grantXXX(アクセス元のリソース); // 例）Lambda関数とDynamoDBテーブルを定義する const lambda = new lambda.Function(…); const dynamo = new dynamodb.TableV2(…); // 下記の定義を行うことで、Lambda関数がDynamoDBに読み取りアクセス用のIAM Policyを自動で作成＆IAM Roleにアタッチしてくれる dynamo.grantReadData(lambda); // 「grant」メソッドで、許可するアクションを明示的に指定することも可能 dynamo.grant (lambda, “dynamodb:Scan”, “dynamodb:Query”);
14. 13 KDDI Agile Development Center Corporation grantXXXメソッドの注意点 ※やっぱり「銀の弾丸」はない 最終的に出力されるIAM PolicyをCDK上で確認できない ◦ 必要に応じて「cdk synth」コマンド/cdk.outファイル/デプロイ後の各種Policyで確認 「最小権限の原則」に100%沿っているかどうかという点では、確認が必要 ◦ もし沿っていない場合、運用上問題ないかの判断が不要（かも） 「人的な設定不備」について、100%解決できるわけではない（例：メソッドの指定間違い） ◦ それでも、IAM Policyを1から定義するよりはだいぶマシだと思う ◦ デプロイ前に単体テストなどで確認する（※1） ※1：CDKの単体テストについては、AWS HEROの後藤 健太さんがbuilders.flashに記事を寄稿していますので、詳し く知りたい方はそちらを参照ください。→ AWS CDK における単体テストの使い所を学ぶ
15. 14 KDDI Agile Development Center Corporation まとめ
16. 15 KDDI Agile Development Center Corporation まとめ AWS CDKの「grantXXX」メソッドで、IAM Policyを定義せずにアクセス設定が行える ◦ 「読み取り専用」「読み書きのみ」など各種メソッドが用意されており、柔軟に対応することができる ◦ 「grant」メソッドで、許可するアクションを自分で定義することも可能 「grantXXX」メソッドは非常に便利だが、やっぱり「銀の弾丸」ではない ◦ CDKソース上で最終的に出力されるIAM Policyを確認できない、「最小権限の原則」…など ◦ （IAM Policyほどではないにせよ）「人的な設定不備」を100%回避できるわけではない ◦ デプロイ前に単体テストなどで確認をすることが重要
17. 札幌オフィス SAPPORO OFFICE 秋田オフィス AKITA OFFICE 高崎オフィス TAKASAKI OFFICE 金沢オフィス KANAZAWA OFFICE 舞鶴オフィス MAIZURU OFFICE 広島オフィス HIROSHIMA OFFICE 福岡オフィス FUKUOKA OFFICE 那覇オフィス NAHA OFFICE 仙台オフィス SENDAI OFFICE 東京本社 TOKYO MAIN OFFICE 三島オフィス MISHIMA OFFICE 名古屋オフィス NAGOYA OFFICE 大阪オフィス OSAKA OFFICE
18. 採用募集中！ エンジニア・デザイナー
19. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る