「Security-JAWS【第32回】」での登壇資料です。 イベントURL:https://s-jaws.doorkeeper.jp/events/167836
© 2024 Mizuho Research & Technologies, Ltd.Security-JAWS 第32回0技術開発本部先端技術研究部IaC でセキュリティを強化しよう!~ IAMが苦手な開発者でも簡単に権限を絞れる。そう、AWS CDKならね! ~2024年2月14日
View full-size slide
© 2024 Mizuho Research & Technologies, Ltd.1自己紹介氏名:松尾 優成(Matsuo Yusei)所属:先端技術研究部 兼 プロジェクト推進部役割:社内向けAWS共通プラットフォームの構築・運用一言:#secjaws 3回目の登壇機会に感謝!
© 2024 Mizuho Research & Technologies, Ltd.2社内向けAWS共通プラットフォームの概要• 社員が安心してAWS環境を利用できるようにセキュアなAWSアカウントを迅速に提供するプラットフォーム• マルチアカウント管理にAWS Control Towerを導入し、開発にAWS CDKを活用Control Towerテナント AWSアカウント1提供サービスAWSアカウント管理クラウドセキュリティ開発システムテナントAWSアカウント2テナントAWSアカウント3マスターアカウントAuditアカウントLog Archiveアカウント・・・詳細は#secjaws31をCheck!
© 2024 Mizuho Research & Technologies, Ltd.3話すこと• セキュリティ観点でAWS CDKの良いところ(タイトルはIAMのみですが、IAM以外にも触れます)• 当社プラットフォームの設定例をコード付きで紹介話さないこと• IaC の概念• AWS CDKを利用するための権限設定(プラットフォーム側でどのように制御するかという話はしません)吹き出しなどで補足するためコードの詳細を理解する必要はありません
© 2024 Mizuho Research & Technologies, Ltd.4こんな悩みありませんか?• IAMポリシーやS3バケットポリシーを書くのが大変• CloudFormationでセキュリティ設定を定義しているが• 読みづらい ・・・• 変更時に抵抗がある・・・
© 2024 Mizuho Research & Technologies, Ltd.5こんな悩みありませんか?• IAMポリシーやS3バケットポリシーを書くのが大変• CloudFormationでセキュリティ設定を定義しているが• 読みづらい ・・・• 変更時に抵抗がある・・・→ AWS CDKで解決できます!
© 2024 Mizuho Research & Technologies, Ltd.6でもAWS CDKの要員は中々いない・・・なぜ?• ハードルが高いと思われている?• メリットが十分に伝わっていないかも?→ セキュリティ観点でのCDKメリットをお伝えします!
© 2024 Mizuho Research & Technologies, Ltd.7AWS CDK とは…「開発者体験に優れたOSS のIaCツール」• アプリもインフラも使い慣れたプログラミング言語で構築可• ベストプラクティスに沿った抽象化されたライブラリ(High-levels Constructs)により少ないコード量で記述可https://aws.amazon.com/jp/builders-flash/202309/awsgeek-aws-cdk/
© 2024 Mizuho Research & Technologies, Ltd.8AWS CDK は学習コンテンツが豊富!初心者にはワークショップ・ BlackBelt シリーズが特にオススメ!https://aws.amazon.com/jp/events/aws-event-resource/archive/https://aws.amazon.com/jp/builders-flash/202309/awsgeek-aws-cdk/https://catalog.workshops.aws/typescript-and-cdk-for-beginner/ja-JPhttps://catalog.us-east-1.prod.workshops.aws/workshops/10141411-0192-4021-afa8-2436f3c66bd8/ja-JP
© 2024 Mizuho Research & Technologies, Ltd.9IaC 関連の直近アップデートが熱い!更に IaC の世界へ飛び込みやすくなっています!https://speakerdeck.com/ohmura/managing-existing-environment-with-aws-cfn-iac-generatorhttps://aws.amazon.com/jp/blogs/news/announcing-cdk-migrate-a-single-command-to-migrate-to-the-aws-cdk/https://aws.amazon.com/jp/blogs/news/import-entire-applications-into-aws-cloudformation/
© 2024 Mizuho Research & Technologies, Ltd.10ここからセキュリティ観点でのAWS CDKメリットを4つ紹介!(サンプルコードはTypeScript)・cdk:v2.103.0・jest:v29.7.0
© 2024 Mizuho Research & Technologies, Ltd.11セキュリティ観点でのAWS CDKメリット①「ポリシー関連の設定が抽象化されて簡単!」
© 2024 Mizuho Research & Technologies, Ltd.12S3のRead権限についてCFn例(BlackBeltから引用)⇒ セキュアだが、参照を上下に追っていくのは認知負荷が高い?セキュリティ観点でのAWS CDKメリット①「ポリシーの抽象化」https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_AWS-CDK-Basic-1-Overview_0731_v1.pdf特定のバケットのみに制限特定のユーザーのみにアタッチ特定のActionに制限
© 2024 Mizuho Research & Technologies, Ltd.13CDKなら同じ内容をたった3行でかける!セキュリティ観点でのAWS CDKメリット①「ポリシーの抽象化」https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_AWS-CDK-Basic-1-Overview_0731_v1.pdfRead以外にWriteやReadWriteなど豊富な権限セットを提供
© 2024 Mizuho Research & Technologies, Ltd.14リソースベースポリシーも簡単にかける!セキュリティ観点でのAWS CDKメリット①「ポリシーの抽象化」当社事例のCDKコード(アセットを組織内に展開するS3バケット)ポリシー生成S3バケットポリシー抜粋grantReadの1行で組織IDに属する全AWSアカウントへ読み取り権限を付与(約40行のポリシーを生成)
© 2024 Mizuho Research & Technologies, Ltd.15SSLを強制するポリシーも1行で!セキュリティ観点でのAWS CDKメリット①「ポリシーの抽象化」当社事例のCDKコード(アセットを組織内に展開するS3バケット)ポリシー生成S3バケットポリシー抜粋enforeSSLを有効化するだけでSSL以外のリクエストを拒否(約35行のポリシーを生成)
© 2024 Mizuho Research & Technologies, Ltd.16S3以外にKMSなどでも簡単に権限付与!• サンプルでは組織IDに権限付与しているがIAM RoleやLambda関数にも付与可能(IGrantableに対応するリソースが対象)• 誰がどのリソースに触れるのか分かり易い!「アクセス先リソース.grantXX(アクセス者)」の形式セキュリティ観点でのAWS CDKメリット①「ポリシーの抽象化」当社事例のCDKコード(組織内で使用するCMK) KMSキーポリシー抜粋ポリシー生成
© 2024 Mizuho Research & Technologies, Ltd.17ベストプラクティスに沿って grant を積極的に使おう!• セキュリティグループやNACLの設定も簡単• その他に通知やメトリクスなども抽象化されていて、とにかく便利セキュリティ観点でのAWS CDKメリット①「抽象化」個別に用意したIAMロール・ポリシーも適用可!
© 2024 Mizuho Research & Technologies, Ltd.18セキュリティ観点でのAWS CDKメリット②「モジュール化と単体テストで設定ミス抑制」
© 2024 Mizuho Research & Technologies, Ltd.19CFnテンプレートで同様なセキュリティ設定が羅列しやすいセキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」CloudWatchでルートユーザーの使用を検知してSNSへ通知するCFn例この塊が沢山あるイメージ※Fn::ForEach未使用の前提
© 2024 Mizuho Research & Technologies, Ltd.20アラーム毎に対応するメトリクスフィルタとの連携設定が必要セキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」正常に通知を機能させるためにはMetricName/NameSpaceを揃えるCloudWatchでルートユーザーの使用を検知してSNSへ通知するCFn例アラーム側定義と一致する必要あり
© 2024 Mizuho Research & Technologies, Ltd.21アラーム毎に対応するメトリクスフィルタとの連携設定が必要セキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」丸々コピペして定義すると、うっかり修正漏れで通知がうまくいかないことも・・・CloudWatchでルートユーザーの使用を検知してSNSへ通知するCFn例
© 2024 Mizuho Research & Technologies, Ltd.22同様の処理をモジュール化することで保守性向上!AWS CDKではモジュールとして独自のコンストラクトを作成できる※本発表では、以後「独自のコンストラクト」を「カスタムConstruct」と呼びますセキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/constructs.html#constructs_author
© 2024 Mizuho Research & Technologies, Ltd.23アラーム/メトリクスフィルタをカスタムConstruct化するセキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」カスタムConstructのリソース定義抜粋当社事例のCDKコード(カスタムConstruct概要)MetricName/NameSpaceが一致するようにモジュール化呼び出し元から渡された値をリソース定義に使用
© 2024 Mizuho Research & Technologies, Ltd.24単体テストでカスタムConstructのロジックを確認!セキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」当社事例のCDKコード(カスタムConstructの単体テスト抜粋)メトリクスフィルタとアラームでMetricName/NameSpaceが一致していることを確認
© 2024 Mizuho Research & Technologies, Ltd.25単体テストでカスタムConstructのロジックを確認!セキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」単体テストにより変更容易性も高まる!テスト実行結果(npm test)当社事例のCDKコード(カスタムConstructの単体テスト抜粋)
© 2024 Mizuho Research & Technologies, Ltd.26テスト済のカスタムConstructなら、繰り返し処理が安全!セキュリティ観点でのAWS CDKメリット②「モジュール化と単体テスト」当社事例のCDKコード(スタック定義)カスタムConstructを呼び出し(アラーム・メトリクスフィルタを作成)メトリクスパターンの定義数に応じてループ処理メトリクスパターンの定義
© 2024 Mizuho Research & Technologies, Ltd.27セキュリティ観点でのAWS CDKメリット③「CloudFormationサポート外リソースをカスタムリソースで簡単かつセキュアに設定」
© 2024 Mizuho Research & Technologies, Ltd.28実務ではCFnサポート外のリソース操作に度々遭遇【CFnサポート外の操作例】1. GuardDutyのS3エクスポート設定2. Configルールのタグづけ3. Securiry Hub 標準コントロールの無効化(※2023年6月に対応済)4. Service Catalog ポートフォリオの IAM Principal 関連付けこれらは手動設定になりがちだが何度も設定するものはIaCにしたい一方、CFn カスタムリソースはLambdaが必要でハードルが高そう…セキュリティ観点でのAWS CDKメリット③「カスタムリソース」
© 2024 Mizuho Research & Technologies, Ltd.29AWS CDKでは、カスタムリソースを簡単に記述可能!セキュリティ観点でのAWS CDKメリット③「カスタムリソース」https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_AWS-CDK-Basic-3-AppDev_0831_v1.pdf
© 2024 Mizuho Research & Technologies, Ltd.30カスタムリソース上のAPIに応じたポリシーを簡単に作成!セキュリティ観点でのAWS CDKメリット③「カスタムリソース」当社事例のCDKコード(Service Catalog ポートフォリオの IAM Principal 関連付け) カスタムリソース(Lambda関数)のポリシー抜粋ポリシー生成
© 2024 Mizuho Research & Technologies, Ltd.31リソースの細かい指定もでき、最小権限にしやすい!※個別に用意したIAMロール・ポリシーも使用可能セキュリティ観点でのAWS CDKメリット③「カスタムリソース」当社事例のCDKコード(Service Catalog ポートフォリオの IAM Principal 関連付け)https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources.SdkCallsPolicyOptions.html
© 2024 Mizuho Research & Technologies, Ltd.32セキュリティ観点でのAWS CDKメリット④「 cdk-nag でセキュリティのシフトレフト」
© 2024 Mizuho Research & Technologies, Ltd.33Policy Validation:「cdk-nag」とは• セキュリティ・コンプライアンスチェックツール• デプロイ前に違反リソースがあれば、デプロイを強制停止• 簡単に導入でき、独自ルールの作成などカスタマイズも可能セキュリティ観点でのAWS CDKメリット④「cdk-nag」設計 実装ビルド(cdk synth)デプロイ(cdk deploy)システムテストcdk-nagUTやビルドで検査できる
© 2024 Mizuho Research & Technologies, Ltd.34様々なルールやそれらをまとめたマネージドのパックありセキュリティ観点でのAWS CDKメリット④「cdk-nag」当社では自社ポリシーに合わせて独自のルールパックを使用https://github.com/cdklabs/cdk-nagマネージドのルールパックS3のルール例
© 2024 Mizuho Research & Technologies, Ltd.35単体テストで cdk-nag を使うと早期に違反を検知できる!セキュリティ観点でのAWS CDKメリット④「cdk-nag」cdk-nag 単体テスト実行例サーバーアクセスログが無効化、SSLが強制されていない旨を指摘(近年、S3のサービスアップデートによりデフォルトでの指摘が減少している)デフォルト設定のS3バケット
© 2024 Mizuho Research & Technologies, Ltd.36cdk-nag の単体テスト Tips は以下記事をご参照!セキュリティ観点でのAWS CDKメリット④「cdk-nag」https://qiita.com/y_matsuo_/items/6ef17964ff3c557f6d1e
© 2024 Mizuho Research & Technologies, Ltd.37セキュリティ観点でのAWS CDKメリットになり得るかも?「integ-tests でアクセステストの自動化」
© 2024 Mizuho Research & Technologies, Ltd.38AWS CDK integ-tests とは• 実環境に一時的なリソースをデプロイして統合テストを行う• HTTPやAWS API、Lambda実行などで期待通りの挙動か確認セキュリティ観点でのAWS CDKメリットになり得るかも?「integ-tests」https://aws.amazon.com/jp/blogs/news/how-to-write-and-execute-integration-tests-for-aws-cdk-applications/CDKからAWS APIでテスト用の値を投入CDKからAWS APIでDBの期待値チェック※α版なので、破壊的変更が入る可能性あり
© 2024 Mizuho Research & Technologies, Ltd.39integ-testsを使えば、データ境界のような複雑な環境で正常系/異常系のアクセステストを自動化できる?セキュリティ観点でのAWS CDKメリットになり得るかも?「integ-tests」データ境界の当社例(#secjaws23 を参照)VPCS3 bucketVPCeLambdaIdentityPolicyResourcePolicyNetworkPolicyCDK integ-testsSDK① VPC内Lambdaを実行② AWS API Callを実行PUT GETAWS account(正常系)VPC内からはアクセス可(異常系)VPC外からはアクセス不可複数のポリシーが正しく機能しているか実環境で知りたい…!
© 2024 Mizuho Research & Technologies, Ltd.AWS account40データ境界における integ-tests の検証結果• テスト実行時間が約25分(早い時は7~9分程度だが、バラつきあり)• コードレスなAWS APIのメソッドでは正常アクセスのみ確認可(Access Deniedを確認したい場合は、Lambda関数が必要)セキュリティ観点でのAWS CDKメリットになり得るかも?「integ-tests」VPCS3 bucketVPCeLambdaSDK① VPC内Lambdaを実行② AWS API CallLambdaを実行PUT GET アクセス不可を確認するにはLambda関数のコードでエラーハンドリングが必要LambdaCDK integ-tests
© 2024 Mizuho Research & Technologies, Ltd.41データ境界のアクセステストにおける integ-tests の所感• integ-tests ではアクセステストに限定せず、データ入出力に着目した正常処理の一環で権限確認するのがよさそう→パイプラインがあるなら無理して integ-tests を導入しなくてもよいかも?(パイプライン上でもテストできる)• 各種ポリシーが固まっていない状況なら通常通りスタックをデプロイして手動テストする方が早そうセキュリティ観点でのAWS CDKメリットになり得るかも?「integ-tests」
© 2024 Mizuho Research & Technologies, Ltd.42まとめ• セキュリティ観点でのAWS CDKメリットは以下1. ポリシー関連の設定が抽象化されて簡単2. モジュール化と単体テストで設定ミス抑制3. CFnサポート外操作をカスタムリソースで簡単かつセキュアに設定4. cdk-nag でセキュリティのシフトレフト• 制限の厳しい環境で integ-tests を使用する場合、正常処理の一環で権限確認する方がよさそう• AWS CDKは便利!ぜひ使ってみよう!
43