IaCセキュリティとは

IaCセキュリティが重要な理由

ビジネス上のニーズやDevOpsの導入により、アプリケーションはかつてないほど迅速に配信、展開されるようになっています。しかし、各種規制やサイバー脅威が絶えず進化している今、この流れはコンプライアンスやセキュリティの領域にマイナスの影響を及ぼしかねません。

開発者がコンプライアンス要件を認識していなかったり、コンプライアンス要件に関する情報にアクセスできなかったりすれば、本番環境に脆弱性が持ち込まれてしまう可能性があります。セキュリティに関する業務責任および説明責任は急速にDevOpsエンジニアに移行しているため、組織はセキュリティ部門とDevOps部門の隔たりを埋め、この問題に対処しなければなりません。

この問題の根底には、手動のプロセスやサイロ化したツールへの依存があります。こうしたプロセスやツールは、求められる開発スピードや継続的なリリース サイクルに対応できていないのです。そこで、開発者が迅速に問題を特定および修正するための、摩擦のないコラボレーション プラットフォームを用意する必要があります。これによって、スピードを犠牲にすることなく、一貫したセキュリティ ポリシーの適用とコンプライアンスの確保を可能にします。

IaCセキュリティに求められるのは以下の要素です。

• コードのスキャン：セキュリティ標準に反する構成エラー、脆弱性、安全性の低い展開を検出します。
• 構成のチェック：セキュリティに関するベスト プラクティスやコンプライアンス要件に対する適合性を確認します。
• 開発者/エンジニアへのアラートおよびガイダンス：修復や安全な展開のための情報を提供します。
• ガードレールの適用：重大な脆弱性が潜むプル リクエストやCI/CDのビルドを、開発者が使用するツール上で直接エラーとして判定し、関連する領域の潜在的な違反をブロックします。

IaCセキュリティの重要性について詳しく説明する前に、次のセクションでは、IaCとは何か、IaCが現代の運用において重要なのはなぜかを見ていきます。

IaC (Infrastructure as Code)とは

IaC (Infrastructure as Code)は通常、マークアップ言語(JSON、YAMLなど)や独自の言語(Terraform HCLなど)で書かれた記述的なコードであり、クラウド インフラストラクチャーのリソース構成のプロビジョニングおよび管理に使用されます。生産性やアジリティーの向上、ヒューマン エラーの低減、展開の標準化、インフラストラクチャー構成のバージョン管理に役立ちます。

IaCツールには多くの形態があり、専用のインフラストラクチャー管理プラットフォームから構成管理ツール、オープン ソースまで、選択肢はさまざまです。特に人気のあるIaCツールとしては、HashiCorp Terraform、AWS CloudFormation、Azure Resource Managerなどが挙げられます。

IaCのメリット

IaCを利用することで、主に柔軟性とスピードの面で数多くのメリットを得られます。具体的には以下のようなことが可能になります。

• クラウド リソースのプロビジョニングと管理の迅速かつ簡単な実施
• クラウド インフラストラクチャーのコード化による展開プロセスの自動化
• クラウドを活用したインフラストラクチャーの拡張

これによって、時間のかかる手動での構成の必要がなくなり、ヒューマン エラーのリスクも軽減されます。さらに、エンジニアがバージョン管理を行えるようになり、DevOps部門の柔軟性が向上します。この点についてもう少し詳しく見ていきましょう。

DevOpsにとってIaCが重要な理由

IaCを活用することで、IT部門では、記述されたファイルを使用してデータ センターの管理とプロビジョニングを行えるようになります。これにより、アプリケーションの構築と実行のコストを削減できるほか、チーム間でのデータ共有やスクリプト作成の自動化が容易になり、クラウド アプリ開発を担当するDevOps部門の負担を軽減できます。

さらに、DevOps部門では、多数のテスト環境のプロビジョニングと実行が可能になり、開発者は必要に応じてより多様な言語を使用できるようになります。このような柔軟性の向上によって、DevOps部門は、高品質なアプリケーションの構築、テスト、実行に専念できるようになり、作業にかかる時間やコストも削減できます。

しかし、IaCのこうした特長が、インフラストラクチャーの脆弱性を高めてしまう可能性があります。

IaC関連するセキュリティ リスク

IaCには、命令型ではなく宣言型のアプローチでITインフラストラクチャーを迅速にプロビジョニングできるなどの運用上の利点があります。一方、IaCがリソースに及ぼし得る影響はセキュリティにも関係し、これが大きな課題となります。

あるリソースの構成を誤った場合、手動での作業であれば影響範囲はそのリソースのみに限定されます。しかし、100以上のリソースの自動プロビジョニングに使用するコードに1つでもミスがあれば、発生するセキュリティ上のリスクははるかに大きなものになります。

そこで、多くの組織で課題となっているのが、包括的なIaCセキュリティの実現です。IaCは、非常に多くのメリットをもたらす可能性がある一方、危険な脆弱性の原因にもなりかねないのです。

IaCの5つのリスク

IaCは、組織に以下のようなリスクをもたらす可能性があります。

• 攻撃対象領域の拡大：IaCの構成を誤ると、攻撃対象領域の拡大につながる可能性があります(セキュリティ グループの構成ミスによって資産が意図せずインターネット上に露出するなど)。
• データの露出：IaCテンプレートには、データの露出につながるおそれのある脆弱性や、安全性の低いデフォルトの構成が含まれている可能性があります(ソース管理のためにチェックされるTerraformコードに埋め込まれた秘密情報など)。
• 過剰な特権：開発者は、クラウド アプリや基盤となるインフラストラクチャー リソースのプロビジョニングを、特権アカウントを使用して行うことが多く、これが機密データへの不正アクセスや侵害を招くおそれがあります。
• コンプライアンス違反：組織はGDPR、HIPAA、PCI DSS、SOC2など、多くの規制の基準を順守する必要があります。IaCのプロセスにこうした基準に基づくポリシー ガードレールが適用されていない場合、コンプライアンス違反につながるおそれがあります。
• 部門間の摩擦：開発者は、厳しい納期で高品質の製品を提供するために展開を加速させています。一方、セキュリティ担当者は、コードをほとんど見ることができず、コミットされた変更についてもほとんど制御できません。DevOpsとSecOpsの溝を埋めなければ、コンプライアンス要件またはベスト プラクティス、企業ポリシーに基づくセキュリティ ガイドラインを適用することは非常に困難です。

IaCセキュリティの仕組み

IaCセキュリティは、「シフトレフト」のアプローチによってコードを保護します。つまり、開発者とDevOpsエンジニアは、プロセスの早い段階でコードに関するセキュリティ上のフィードバックを受け取ります。IaCセキュリティでは、以下のようなプロセスを通じてこのような可視性を実現します。

• ソース管理を開始する前の段階でのIaCテンプレートのスキャン
• 各種基準に基づく構成の評価
• 構成ミス、脆弱性、ポリシー違反の特定

こうしたプロセスを導入することで、アプリの展開前に修正が必要な問題がある場合、SecOps部門が直ちに通知を受け取れます。

IaCセキュリティのベスト プラクティス

ここで、開発ライフサイクルに簡単に組み込めるIaCセキュリティのベスト プラクティスをいくつか紹介します。

資産インベントリーの可視化

IaCの運用にあたっては、展開される資産のインベントリーの識別、タグ付け、監視、メンテナンスが不可欠です。タグ付けされていないリソースは追跡が難しく、ドリフトの原因となるため、慎重な監視が必要です。リソースが不要になった際は必ず関連する構成を削除し、データは保護または削除します。

環境のドリフトの特定および修正

構成は、開発者の環境全体で統一したいところです。しかし、アプリケーションのオーナーは、アプリケーションやその基盤となるインフラストラクチャーに変更を加えなければならない場合もあります。適切な監視やツールの導入を行わず、こうした変更の蓄積を確認せずにいると、構成のドリフトにつながり、インフラストラクチャーがリスクにさらされたり、セキュリティやコンプライアンス上の問題が生じたりする可能性があります。

ハードコードされた資産の保護

IaC内でハードコードされた秘密鍵やプライベートキー、SSH鍵、アクセス/シークレットキー、APIキーといった機密データの存在は、基盤となるサービスやオペレーションへのアクセスを簡単に許し、攻撃者によるラテラル ムーブメントを助長してしまう恐れがあります。資格情報が散りばめられたIaCコードがソース管理ツール(GitHubなど)にコミットされれば、その情報を露出させることになり、組織にとって大きなリスクとなる可能性があります。

開発者アカウントの保護

開発者のアカウントは攻撃者から保護する必要があります。そこで重要となるのは、開発者アカウントの強化および監視、IaC構成の変更の追跡、変更が承認を受けた意図的なものであることの確認です。承認なしでの変更は、IaCのテンプレートや構成の改ざん、ひいてはコードの漏洩を招きかねません。

環境へのアクセスの制限

セキュリティ部門には、特権アカウント、資格情報、機密情報をそれぞれの開発環境およびコンピューティング環境全体にわたって一貫して管理できるような、単一の制御ポイントが必要です。こうした制御ポイントを持つことで、特権資格情報に関する現在および今後の使用状況を管理し、アクセス設定の問題を必要なコンテキストとあわせて検出できるほか、アイデンティティーのアクセス権や権限を適正化し、一貫した最小特権ポリシーを適用できます。

ガードレールの適用

セキュリティ部門は、マルチクラウド インフラストラクチャーを構成のドリフトから保護し、違反時にアラートを発するためのチェック機能を組み込んだクラウド ネイティブのポリシー ガードレールを適用する必要があります。これによって、構築と実行時に一貫したセキュリティ ポリシーを適用し、開発者は脆弱性やリスクの解決方法について明確なガイダンスを得られます。たとえば、セキュリティに関する特定の基準が満たされなかった場合に、CI/CDのビルドを中断するといったケースが考えられます。

ここまで見てきたとおり、IaCは組織に大きなメリットをもたらすものの、そこには無視できないセキュリティ リスクも伴います。IaCを最大限活用するには、DevSecOpsを念頭に置いて構築されたソリューションを持ち、クラウド データ保護に精通し、何よりIaCへの投資効果の最大化を支援してくれるサイバーセキュリティ パートナーが必要です。こうした条件を満たすパートナーとなるのがZscalerです。

Posture Controlを利用するメリット

Posture Controlはクラウド ネイティブ アプリケーション保護プラットフォーム(CNAPP)で、包括的なIaCセキュリティ プログラムをゼロから構築するにあたり、開発部門とセキュリティ部門の連携を支援します。

主な機能

可視性とコントロール

• コード リポジトリーについて、問題を特定し、セキュリティおよびコンプライアンス態勢を可視化できます。
• カテゴリー、ポリシーの重大度、コンプライアンス制御、タグ、ステータス別に、違反を簡単に調査および修復できます。
• コード違反、コード リポジトリー、プル リクエスト、CI/CDのビルド、その他の重要な情報を詳細に把握し、問題の原因をトレースできます。

継続的な評価

• コードが更新されるか、コード リポジトリーにプッシュされてCI/CDシステムでビルドがトリガーされた際に、IaCテンプレート(Terraform HCL、AWS CloudFormationテンプレート、KubernetesアプリのYAML形式のマニフェスト ファイルやHelmチャートなど)を継続的にスキャンできます。
• できる限り早い段階(開発者IDE)でコードをスキャンしてセキュリティ ポリシー違反の有無を確認し、開発者に直ちにフィードバックを提供できます。
• IaCテンプレートにセキュリティ上の問題やコンプライアンス違反、その他の構成ミス、安全でないデフォルトの構成(暗号化が行われていない、アイデンティティーや資格情報が追跡されているなど)がないか評価し、過剰な権限、ワークロードとして公開されているリソース、ストレージ バケット、脆弱なセキュリティ グループ ロールなどを検出できます。
• 確認された構成と望ましい構成を継続的に比較し、想定外の構成のドリフトをレポート、通知、修復できます。
• コード リポジトリーにコミットされたコードをスキャンし、重大な脆弱性が特定された際にCI/CDシステムでビルドを中断できます。

生産性の向上

• DevOpsエコシステムのツール(IDEやコード リポジトリー、CI/CDシステムなど)から直接問題を発見するとともに、適切なコンテキスト、統合されたセキュリティ ガイダンス、推奨事項を提示して問題解決を支援し、開発者のエクスペリエンスを向上させることができます。
• IaCセキュリティを自動化して既存のプロセスに組み込むことで、開発者とセキュリティ部門、運用部門、コンプライアンス部門のメンバー間の摩擦を軽減できます(DevSecOpsのベスト プラクティス)。

アラート

• チケット ツールと統合してほぼリアルタイムのアラートを生成し、適切なオーナーおよび部門に対して、問題とその影響、問題の修復に必要なアクションに関するコンテキストとあわせて通知できます。