大規模なクラウド環境を運用する金融機関のセキュリティチームでは、急速に変化するデジタル環境においてセキュリティ脆弱性を効率的に管理することが常に重要な課題として認識されております。特に、ISMS-P、電子金融監督規定、ISO 27001のような複雑な国内外の規制遵守要件を満たしつつも、開発チームのサービスリリース速度を阻害しないセキュリティ戦略を策定することが中核的な目標です。開発チームはすでにInfrastructure as Code (IaC) を積極的に活用し、AWS、Azureといった多様なクラウドインフラをプロビジョニングしており、これに伴い、インフラ構築段階からセキュリティを内在化できる方法を模索しております。
このような背景のもと、弊チームは開発段階からセキュリティ脆弱性を事前に発見し修正することで、実際のサービス展開後に発生しうるセキュリティインシデントのリスクを最小限に抑えたいと考えておりました。究極的には、規制遵守と内部セキュリティ標準を自動化された方法で確保し、クラウド環境のセキュリティガバナンスを強化する方向へ進んでおります。インフラがコードとして定義される時代において、そのコード自体のセキュリティを検証することは、クラウドセキュリティの第一歩であり、最も重要な段階であると言えます。
クラウドインフラセキュリティ強化のための課題
弊チームが直面した最大の技術的、運用上の課題は、IaCコードのセキュリティレビューでした。従来は、インフラコードを手動でレビューする方法に依存しておりました。これは、莫大な時間の消費を引き起こすだけでなく、人為的ミスによるエラー発生の可能性が高いという限界を有しておりました。特に、Terraform、AWS CloudFormationなどで定義されたインフラコード内部に隠されたセキュリティ脆弱性や不十分な設定エラーを事前に発見することは非常に困難でした。
さらに、AWSとAzureを同時に使用するマルチクラウド環境では、一貫したセキュリティポリシーを適用し管理することが複雑でした。各クラウドプラットフォームの特性とIaCフレームワークに適したセキュリティ標準を確立し、これを開発パイプラインに統合することに困難が伴いました。既存のSAST (Static Application Security Testing) ツールは主にアプリケーションコードの脆弱性分析に重点を置いていたため、インフラコードのセキュリティ問題を効果的に検出することはできませんでした。加えて、クラウド環境にインフラがデプロイされた後に、CSPM (Cloud Security Posture Management) ツールを通じて問題が事後的に発見されるケースが多く、これはすでにデプロイされたインフラの設定エラーや脆弱性を修正するためには、はるかに多くの費用と労力が必要であることを意味しておりました。
このような状況において、弊チームは開発速度を阻害せずにセキュリティを強化しなければならないという二重の困難に直面しておりました。中核となる要件は以下の通りでした。
- IaCコード作成段階でセキュリティ脆弱性を自動的にスキャンし、開発者に即時フィードバックを提供する必要があります。
- Terraform, AWS CloudFormation, Kubernetes YAMLなど、多様なIaCフレームワークを幅広くサポートする必要があります。
- 内部セキュリティポリシー違反、規制遵守（例：S3バケットのパブリックアクセス制限、EC2セキュリティグループの不要なポート開放）に関連する設定エラーを正確に検出する必要があります。
- CI/CDパイプラインとの緊密な連携を通じてセキュリティ検証プロセスを自動化し、開発フローに自然に組み込む必要があります。
最適なIaCセキュリティスキャン技術の選定プロセス
これらの課題を解決するため、多様なIaCセキュリティスキャンツールを検討するプロセスを経てまいりました。主要な候補群としては、Checkov, Trivy, OPA/Conftest, Kics, Terrascanなどがありました。これらのツールはそれぞれ独自の強みと特徴を有しており、弊社の環境に最も適したソリューションを見つけるため、複数の基準を設けて比較分析を実施いたしました。
最も重要視した選択基準は以下の通りです。
- IaCフレームワークサポート範囲: Terraform, AWS CloudFormation, Kubernetes YAML, Azure Resource Managerなど、弊社が使用するすべてのIaCフレームワークをサポートしているかを確認いたしました。
- 検出ルールの正確性および豊富さ: CIS Benchmarks, OWASP Top 10, 特定のクラウドベンダーのセキュリティ標準（AWS Security Best Practicesなど）に基づき、いかに正確で多様なセキュリティ問題を検出するかを評価いたしました。
- CI/CDパイプライン統合の容易性: GitHub Actions, Jenkins, GitLab CIなど、弊社が使用するCI/CDツールといかに容易に連携できるかを重要視いたしました。
- オープンソースであるか否かおよびコミュニティサポート: オープンソースツールの場合、活発なコミュニティサポートと継続的なアップデートが重要な考慮事項でした。
- 結果レポートの可読性および活用性: スキャン結果が開発者とセキュリティチームの両方にとってどれだけ理解しやすく、改善活動に効果的に活用できる形で提供されるかを確認いたしました。
- ポリシー定義およびユーザー定義ルール追加の柔軟性: 弊社の組織特有のセキュリティ要件や規制遵守項目を反映するため、ユーザー定義ポリシーをいかに容易に追加および管理できるかが重要でした。
詳細なPoC (Proof of Concept) を実施した結果、多様なIaCフレームワークを幅広くサポートし、ポリシー規則が豊富なCheckovと、コンテナイメージスキャンだけでなくIaC構成エラー (misconfiguration) 検出に強みを持つTrivyを中核候補として選定いたしました。特に、弊社はAWSとAzureを同時に使用するマルチクラウド環境であるため、両方のクラウド環境のIaCをカバーできる柔軟性が重要でした。また、組織特有のセキュリティポリシーを定義し自動検証するために、OPA (Open Policy Agent) のRego言語を活用できるConftestも合わせて検討し、汎用ツールと特定機能に特化したツールを組み合わせるハイブリッドアプローチを選択することを決定いたしました。
このような意思決定プロセスを通じて、開発速度に支障をきたすことなく、多様なクラウド環境をカバーできる柔軟なIaCセキュリティスキャンソリューションを導入し、開発段階からセキュリティを内在化するShift-Leftセキュリティ戦略を実装する方向へ進んでおります。
IaCセキュリティスキャンツールの統合実装プロセス
選定されたIaCセキュリティスキャンツールを実際の開発およびデプロイパイプラインに統合するプロセスは、複数の段階にわたって進行いたしました。中核は、開発チームのワークフローを妨げずに、IaCコードのセキュリティを自動的に検証するシステムを構築することでした。
1. IaCセキュリティスキャン統合アーキテクチャ設計
弊チームは、CI/CDパイプライン内にIaCセキュリティスキャン段階を明確に追加するアーキテクチャを設計いたしました。これは、開発者がGitリポジトリにコードをコミットしたり、Pull Requestを作成したりする際に、自動的にトリガーされてスキャンが実行される方式です。具体的には、terraform planコマンドが実行された後や、IaCファイル（Terraform, CloudFormation, Kubernetes YAMLなど）が作成または修正された直後にスキャンを実行するように構成いたしました。スキャン結果は開発者に即座にフィードバックされ、脆弱性を迅速に修正できるよう支援するとともに、セキュリティチームにはSeekurity SIEMと連携し、集中管理された方法でセキュリティイベントを監視・分析できるよういたしました。さらに、FRIIM CNAPPのIaCスキャン機能を活用し、IaC段階からデプロイ後のクラウド資産まで統合的なセキュリティ視点を維持することを目標といたしました。
2. Checkovを活用したTerraformコードスキャン実装
Terraformコードのセキュリティ脆弱性分析には、Checkovを積極的に活用いたしました。Checkovは多様なクラウドリソースに対して数千の内蔵ポリシーを提供し、特にTerraform, CloudFormation, Kubernetesなど主要なIaCフレームワークをサポートするという強みがあります。以下は、GitHub Actionsを活用してTerraformコードにCheckovスキャンを適用する例です。
name: IaC Security Scan with Checkov
on: [push, pull_request]
jobs:
checkov_scan:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Install Checkov
run: pip install checkov
- name: Run Checkov Scan
run: |
checkov -d . --output cli --output json --output-file-path checkov_results.json
continue-on-error: true
- name: Upload Checkov results
uses: actions/upload-artifact@v3
with:
name: checkov-results
path: checkov_results.json
このGitHub Actionsワークフローは、コードがプッシュされるかPull Requestが作成されるたびにCheckovを実行し、現在のディレクトリ内のすべてのIaCファイルをスキャンします。スキャン結果はCLIに出力されるだけでなく、JSONファイルとして保存され、その後の分析や他のシステムとの連携に活用できます。特定のポリシー違反に対する例外処理が必要な場合、Checkovの--skip-check CKV_AWS_1のようなオプションを使用して特定のポリシーIDを除外できます。
3. Trivyを利用したKubernetes YAMLおよび設定ファイルスキャン
Trivyはコンテナイメージの脆弱性スキャナーとしてよく知られておりますが、IaCファイルの設定エラー (misconfiguration) 検出においても非常に強力な機能を提供します。特にKubernetes Manifest, Dockerfile, Terraformファイルなど、多様なIaC関連ファイル形式をサポートしており、設定エラーによるセキュリティ問題を効果的に検出できます。以下はKubernetes YAMLファイルをTrivyでスキャンする例です。
sudo apt-get update && sudo apt-get install -y wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb stable main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install -y trivy
trivy config deployment.yaml
trivy config main.tf
Trivyは実行後、発見された設定エラーをSeverity (CRITICAL, HIGH, MEDIUMなど) 別に分類して表示するため、開発者が優先順位をつけて問題を解決するのに役立ちます。この機能をCI/CDパイプラインに統合することで、Kubernetesクラスターにデプロイされる前に潜在的なセキュリティリスクを事前に排除することが可能になります。
4. OPA Conftestでユーザー定義セキュリティポリシーを適用
標準化されたポリシーに加え、弊社の組織独自の特殊なセキュリティ要件や規制遵守項目を検証するためにOPA Conftestを導入いたしました。OPA Conftestは、OPAのポリシー言語であるRegoを使用して、YAML、JSONなどの設定ファイルに対するポリシーを定義し、検証することを支援します。例えば、すべてのAWS S3バケットにパブリックアクセスが許可されないように強制するポリシーをRego言語で定義することができます。
package main
denied[msg] {
input.resource_type == "aws_s3_bucket"
input.attributes.acl == "public-read"
msg := "S3 bucket must not have public-read ACL set."
}
denied[msg] {
input.resource_type == "aws_s3_bucket"
input.attributes.block_public_acls == false
msg := "S3 bucket must block public ACLs."
}
上記のRegoポリシーは、S3バケットにpublic-read ACLが設定されている場合、またはパブリックACLブロック設定 (block_public_acls) が無効になっている場合にこれを検出し、deniedメッセージを返します。このポリシーをConftestと組み合わせてIaCファイルを検証すると以下のようになります。
conftest test my-s3-bucket.tf --policy ./policy.rego
このような方法でユーザー定義ポリシーをIaCパイプラインに統合することにより、標準化されたセキュリティガイドラインを超える組織特有のセキュリティ要件まで、自動化された方法で検証・遵守することが可能になります。これは規制遵守の側面においても非常に重要な役割を果たします。
成果および結果：IaCセキュリティスキャンの定量的/定性的効果
IaCセキュリティスキャンツールを導入し、CI/CDパイプラインに統合した結果、弊チームは複数の面で有意な成果を達成することができました。特に、セキュリティ脆弱性の発見および修正プロセスの効率性が大幅に改善され、全体的なクラウドセキュリティポスチャが強化される変化が顕著です。
定量的成果
- セキュリティ脆弱性の事前発見率70%増加: IaCコードデプロイ前にCheckov, Trivy, Conftestを通じて発見される重大なセキュリティ脆弱性および設定エラーの割合が、以前と比較して約70%増加いたしました。これは、実際のプロダクション環境にデプロイされる前に、ほとんどのセキュリティ問題を解決できるようになったことを意味します。
- デプロイ後重大セキュリティイベント50%削減: IaCスキャン導入後、クラウド環境にインフラがデプロイされた後にFRIIM CSPMで検出される重大なセキュリティイベント（例：誤ったセキュリティグループ設定、パブリックS3バケット）が約50%減少いたしました。これはShift-Leftセキュリティ戦略の成功的な適用を示す指標です。
- セキュリティレビュー時間30%短縮: セキュリティチームがIaCコードを手動でレビューするのに要していた時間が、自動化されたスキャンを通じて約30%短縮されました。これにより、セキュリティチームはより戦略的かつ高度なセキュリティ業務に集中できるようになりました。
定性的成果
- 開発チームのセキュリティ意識向上: CI/CDパイプラインに統合されたIaCスキャンツールは、開発者に即座のフィードバックを提供することで、開発者がセキュリティ脆弱性を早期に認識し、自ら解決する文化を形成することに大きく貢献いたしました。これは自然なShift-Leftセキュリティ文化の定着へと繋がります。
- 規制遵守および内部標準満足度向上: ユーザー定義ポリシー (OPA Rego) を通じて、ISMS-P, ISO 27001などの規制要件および組織内部のセキュリティ標準をIaC段階から強制できるようになり、全体的なコンプライアンス満足度が向上いたしました。
- セキュリティチームの業務効率向上: 反復的で手動であったIaCコードレビュー作業が自動化されたことで、セキュリティチームは脅威インテリジェンス分析、セキュリティアーキテクチャ設計、Seekurity SIEM/SOARを活用した脅威検出および対応の高度化など、中核的な業務に能力を集中できるようになりました。
前後比較
IaCセキュリティスキャンツールの導入前後における変化は、以下の表のように要約できます。
| 区分 | IaCセキュリティスキャン導入前 | IaCセキュリティスキャン導入後 |
|---|
| 脆弱性検出時点 | 主にクラウドデプロイ後 (CSPM) | IaCコード作成およびCI/CD段階 (Shift-Left) |
| セキュリティレビュー方式 | セキュリティチームの手動レビューが中心 | 自動化ツールスキャンが中心、セキュリティチームレビューは補助 |
| 脆弱性修正費用 | デプロイ後の修正 → 高コスト、高複雑性 | 開発段階での修正 → 低コスト、低複雑性 |
| 開発速度への影響 | 手動レビューによる遅延発生の可能性 | パイプライン内自動化により遅延を最小限に |
| 規制遵守管理 | 事後点検および手動措置が中心 | 事前ポリシー強制および自動検証 |
| 開発チームのセキュリティ意識 | 低い、「セキュリティはセキュリティチームの仕事」という認識 | 高い、「全員のセキュリティ」文化が拡散 |
これらの変化は、クラウドインフラセキュリティ管理のパラダイムを転換する重要な契機となり、より堅牢で効率的なセキュリティ体制の構築に大きく貢献いたしました。
教訓および振り返り：予測と現実の間のギャップ
IaCセキュリティスキャンツールの導入プロセスにおいて、いくつかの教訓を得ることができました。当初は、開発チームから新たなセキュリティ検証段階に対する抵抗があるものと予想しておりました。しかし、明確な導入目標の説明とともに、スキャン結果を開発者に迅速にフィードバックし、修正ガイドを提供することで、開発フローを妨げるどころか、むしろコード品質を高めることに貢献するという認識が広まりました。これは、開発チームとセキュリティチーム間の連携を促進するという肯定的な副次的効果として現れました。
もし再度このプロジェクトを実施するならば、ポリシー定義の高度化およびバージョン管理にさらに注力する必要があると考えております。Regoのようなポリシーコードは、一般的なコードと同様にバージョン管理が重要であり、ポリシー変更が及ぼす影響を事前に分析する体系が必要です。また、スキャン結果を単にテキストやJSON形式で確認するだけでなく、視覚化されたダッシュボードを構築してセキュリティ状況を一目で把握し、これをSeekurity SIEM/SOARとさらに緊密に連携させて、自動化された脅威検出および対応プロセスを強化する方向へ進むでしょう。特に、KYRA AI Sandboxを活用してIaCコードの潜在的脅威パターンを分析し、それに基づいて新たなセキュリティポリシーを作成したり、既存ポリシーを高度化する方策も検討に値します。AIベースの分析は、人間が見落としがちな複合的な脅威パターンを特定する上で大いに役立つと予測されます。
意外な副次的効果としては、インフラコードの全体的な品質向上が挙げられます。セキュリティポリシーを遵守するためにコード構造を改善し、モジュール化する過程で、開発チームはより堅牢で再利用可能なIaCコードを作成するようになりました。これは結果的にインフラの安定性と管理の容易性まで高める結果をもたらしました。IaCセキュリティスキャン導入は、単にセキュリティを強化するだけでなく、DevOps文化とクラウド運用全般に肯定的な影響を与える重要な転換点であったと言えるでしょう。
クラウド環境のためのIaCセキュリティスキャン適用ガイド
弊社の経験に基づき、類似のクラウド環境でIaCセキュリティスキャンツールを導入しようとする組織のために、実用的な適用ヒントと段階的なロードマップを提示いたします。
- 小規模から開始し、段階的に拡張: すべてのIaCコードに一度に適用するのではなく、重要度の高いサービスや新たに開発されるプロジェクトからIaCスキャンを導入することが効果的です。初期には警告 (warning) モードで運用し、開発フローへの影響を最小限に抑え、徐々にポリシー違反時にビルド失敗 (fail) モードに切り替えることを推奨いたします。
- セキュリティポリシーの継続的な更新と共有: クラウド環境と脅威は絶えず変化するため、セキュリティポリシーもそれに合わせて継続的に更新する必要があります。更新されたポリシーは開発チームと透明に共有し、全員が同一のセキュリティ基準を理解し適用できるようにする必要があります。
- 既存のクラウドセキュリティシステムとの連携: IaCスキャン結果は、FRIIM CNAPP/CSPMのような既存のクラウドセキュリティ管理システムと連携し、統合的なクラウドセキュリティポスチャを維持することが重要です。IaC段階で検出された脆弱性情報が、実際にデプロイされたクラウド資産のセキュリティ状況と接続されることで、全体的な可視性を確保できます。また、Seekurity SIEM/SOARのような脅威検出および対応システムと連携し、セキュリティイベントに対する迅速な対応体制を構築することが効果的です。
必須前提条件
- IaCコードの構成管理システム活用: すべてのIaCコードがGitのような構成管理システムに保存され、バージョン管理されている必要があります。
- CI/CDパイプライン構築: 自動化されたIaCスキャンのためには、機能するCI/CDパイプラインが不可欠です。
- セキュリティチームおよび開発チームの連携意思: IaCセキュリティは、開発チームとセキュリティチームの緊密な連携なしには成功が困難です。初期段階から両チーム間の円滑なコミュニケーションチャネルを構築することが重要です。
段階的導入ロードマップ
- 1段階 (基盤固め): 中核となるIaCフレームワーク（例：Terraform）に対する基本的なスキャンツール（Checkov, Trivy）を導入し、小規模プロジェクトに試験的に適用いたします。
- 2段階 (CI/CD統合): CI/CDパイプラインにIaCスキャンツールを統合し、スキャン結果を開発者にフィードバックする自動化されたワークフローを構築いたします。初期には警告モードで運用します。
- 3段階 (ポリシー拡張および可視性確保): OPA Conftestを活用して組織特有のユーザー定義セキュリティポリシーを拡張し、スキャン結果およびポリシー違反状況を視覚化するダッシュボードを構築いたします。Seekurity SIEM/SOARと連携し、集中監視および自動対応の基盤を構築します。
- 4段階 (統合セキュリティおよび最適化): FRIIM CNAPPとの連携を通じて、IaC段階からランタイムクラウド資産までを包括する統合クラウドセキュリティポスチャ管理体制を完成させます。継続的なポリシー最適化およびツール高度化を通じてセキュリティ自動化レベルを高めてまいります。
IaCセキュリティスキャンは、クラウド環境においてセキュリティを強化し、規制遵守を効果的に達成するための不可欠な戦略です。このアプローチを通じて、組織はより安全で効率的なクラウド運用環境を構築する方向へ進むことができます。
