【要約】cdk-nagが良さそうなので使ってみる [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がAWS CDKを用いてインフラを構築する際、構成のセキュリティ妥当性を判断できない課題がある。特にレビュー工程において、以下の問題が発生する。
- ・レビュワーがAWSの専門知識を持たない場合、判断が困難になる。
- ・デプロイ後に脆弱性が発覚すると、修正コストとリスクが増大する。
- ・手動レビューでは、ログ設定や権限管理などの細かな設定漏れを見逃しやすい。
// Approach
著者はcdk-nagを導入し、デプロイ前のsynth工程でセキュリティ不備を自動検知するアプローチを採用した。具体的な手順は以下の通りである。
- ・cdk-nag v3をインストールし、AppにAwsSolutionsChecksを適用する。
- ・verboseモードを有効化し、指摘の理由を可視化する。
- ・正当な理由がある例外には、acknowledge機能を用いて抑制を行う。
- ・抑制の副作用を防ぐため、テストコード内でスタックごとに検証を行う。
// Result
検証の結果、生成AIアプリの構成において19件の指摘を検出し、設定の修正と適切な抑制により指摘ゼロを実現した。得られた成果は以下の通りである。
- ・IAM権限の最小化や暗号化設定などの不備を、設計段階で即座に特定できた。
- ・レビューの主眼を「脆弱性の発見」から「抑制理由の妥当性確認」へ転換できた。
- ・CI/CDのゲートとして利用可能な、自動化されたガードレールを構築できた。
- ・一方で、最新のBedrock等に対するルール不足という課題も明確になった。
Senior Engineer Insight
> 実戦投入における評価は高い。特にレビューの対象を「指摘の有無」から「抑制理由の妥当性」へシフトできる点は、大規模開発の効率化に直結する。しかし、v3における抑制機能のスコープ問題は無視できない。抑制がApp全体に波及し、他のスタックの脆弱性を隠蔽するリスクがある。これを防ぐには、CI/CDのゲートをsynthではなく、スタックごとに独立したAppを生成するテストフェーズに置く設計が必須だ。また、最新サービスへのルール不足も考慮し、多層的な防御を検討すべきである。