サイクルの早い段階でコードの構成ミスを検出し、実行時の脆弱性を防ぐのに役立ちます。サイクル全体にわたりIaCテンプレートにセキュリティ対策を適用できます。Controlを利用するメリットおすすめのリソース関連するトピックIaCセキュリティが重要な理由ビジネス上のニーズやDevOpsの導入により、アプリケーションはかつてないほど迅速に配信、展開されるようになっています。各種規制やサイバー脅威が絶えず進化している今、この流れはコンプライアンスやセキュリティの領域にマイナスの影響を及ぼしかねません。開発者がコンプライアンス要件を認識していなかったり、コンプライアンス要件に関する情報にアクセスできなかったりすれば、本番環境に脆弱性が持ち込まれてしまう可能性があります。セキュリティに関する業務責任および説明責任は急速にDevOpsエンジニアに移行しているため、組織はセキュリティ部門とDevOps部門の隔たりを埋め、この問題に対処しなければなりません。この問題の根底には、手動のプロセスやサイロ化したツールへの依存があります。サイクルに対応できていないのです。プラットフォームを用意する必要があります。ポリシーの適用とコンプライアンスの確保を可能にします。IaCセキュリティに求められるのは以下の要素です。低い展開を検出します。プラクティスやコンプライアンス要件に対する適合性を確認します。開発者/エンジニアへのアラートおよびガイダンス:修復や安全な展開のための情報を提供します。リクエストやCI/CDのビルドを、開発者が使用するツール上で直接エラーとして判定し、関連する領域の潜在的な違反をブロックします。IaCセキュリティの重要性について詳しく説明する前に、次のセクションでは、IaCとは何か、IaCが現代の運用において重要なのはなぜかを見ていきます。インフラストラクチャーのリソース構成のプロビジョニングおよび管理に使用されます。エラーの低減、展開の標準化、インフラストラクチャー構成のバージョン管理に役立ちます。ソースまで、選択肢はさまざまです。Managerなどが挙げられます。IaCのメリットIaCを利用することで、主に柔軟性とスピードの面で数多くのメリットを得られます。具体的には以下のようなことが可能になります。エラーのリスクも軽減されます。エンジニアがバージョン管理を行えるようになり、DevOps部門の柔軟性が向上します。この点についてもう少し詳しく見ていきましょう。センターの管理とプロビジョニングを行えるようになります。アプリ開発を担当するDevOps部門の負担を軽減できます。DevOps部門では、多数のテスト環境のプロビジョニングと実行が可能になり、開発者は必要に応じてより多様な言語を使用できるようになります。このような柔軟性の向上によって、DevOps部門は、高品質なアプリケーションの構築、テスト、実行に専念できるようになり、作業にかかる時間やコストも削減できます。IaCのこうした特長が、インフラストラクチャーの脆弱性を高めてしまう可能性があります。リスクIaCには、命令型ではなく宣言型のアプローチでITインフラストラクチャーを迅速にプロビジョニングできるなどの運用上の利点があります。IaCがリソースに及ぼし得る影響はセキュリティにも関係し、これが大きな課題となります。あるリソースの構成を誤った場合、手動での作業であれば影響範囲はそのリソースのみに限定されます。100以上のリソースの自動プロビジョニングに使用するコードに1つでもミスがあれば、発生するセキュリティ上のリスクははるかに大きなものになります。そこで、多くの組織で課題となっているのが、包括的なIaCセキュリティの実現です。IaCは、非常に多くのメリットをもたらす可能性がある一方、危険な脆弱性の原因にもなりかねないのです。IaCの5つのリスクIaCは、組織に以下のようなリスクをもたらす可能性があります。グループの構成ミスによって資産が意図せずインターネット上に露出するなど)。データの露出:IaCテンプレートには、データの露出につながるおそれのある脆弱性や、安全性の低いデフォルトの構成が含まれている可能性があります(ソース管理のためにチェックされるTerraformコードに埋め込まれた秘密情報など)。リソースのプロビジョニングを、特権アカウントを使用して行うことが多く、これが機密データへの不正アクセスや侵害を招くおそれがあります。DSS、SOC2など、多くの規制の基準を順守する必要があります。ガードレールが適用されていない場合、コンプライアンス違反につながるおそれがあります。部門間の摩擦:開発者は、厳しい納期で高品質の製品を提供するために展開を加速させています。セキュリティ担当者は、コードをほとんど見ることができず、コミットされた変更についてもほとんど制御できません。ガイドラインを適用することは非常に困難です。IaCセキュリティの仕組みIaCセキュリティは、「シフトレフト」のアプローチによってコードを保護します。開発者とDevOpsエンジニアは、プロセスの早い段階でコードに関するセキュリティ上のフィードバックを受け取ります。IaCセキュリティでは、以下のようなプロセスを通じてこのような可視性を実現します。構成ミス、脆弱性、ポリシー違反の特定こうしたプロセスを導入することで、アプリの展開前に修正が必要な問題がある場合、SecOps部門が直ちに通知を受け取れます。プラクティスをいくつか紹介します。資産インベントリーの可視化IaCの運用にあたっては、展開される資産のインベントリーの識別、タグ付け、監視、メンテナンスが不可欠です。タグ付けされていないリソースは追跡が難しく、ドリフトの原因となるため、慎重な監視が必要です。リソースが不要になった際は必ず関連する構成を削除し、データは保護または削除します。構成は、開発者の環境全体で統一したいところです。アプリケーションのオーナーは、アプリケーションやその基盤となるインフラストラクチャーに変更を加えなければならない場合もあります。適切な監視やツールの導入を行わず、こうした変更の蓄積を確認せずにいると、構成のドリフトにつながり、インフラストラクチャーがリスクにさらされたり、セキュリティやコンプライアンス上の問題が生じたりする可能性があります。ムーブメントを助長してしまう恐れがあります。資格情報が散りばめられたIaCコードがソース管理ツール(GitHubなど)にコミットされれば、その情報を露出させることになり、組織にとって大きなリスクとなる可能性があります。開発者のアカウントは攻撃者から保護する必要があります。そこで重要となるのは、開発者アカウントの強化および監視、IaC構成の変更の追跡、変更が承認を受けた意図的なものであることの確認です。承認なしでの変更は、IaCのテンプレートや構成の改ざん、ひいてはコードの漏洩を招きかねません。それぞれの開発環境およびコンピューティング環境全体にわたって一貫して管理できるような、単一の制御ポイントが必要です。した制御ポイントを持つことで、特権資格情報に関する現在および今後の使用状況を管理し、アクセス設定の問題を必要なコンテキストとあわせて検出できるほか、アイデンティティーのアクセス権や権限を適正化し、一貫した最小特権ポリシーを適用できます。ガードレールを適用する必要があります。ポリシーを適用し、開発者は脆弱性やリスクの解決方法について明確なガイダンスを得られます。セキュリティに関する特定の基準が満たされなかった場合に、CI/CDのビルドを中断するといったケースが考えられます。パートナーが必要です。した条件を満たすパートナーとなるのがZscalerです。プログラムをゼロから構築するにあたり、開発部門とセキュリティ部門の連携を支援します。リポジトリーについて、問題を特定し、セキュリティおよびコンプライアンス態勢を可視化できます。カテゴリー、ポリシーの重大度、コンプライアンス制御、タグ、ステータス別に、違反を簡単に調査および修復できます。リクエスト、CI/CDのビルド、その他の重要な情報を詳細に把握し、問題の原因をトレースできます。ファイルやHelmチャートなど)を継続的にスキャンできます。ポリシー違反の有無を確認し、開発者に直ちにフィードバックを提供できます。ロールなどを検出できます。確認された構成と望ましい構成を継続的に比較し、想定外の構成のドリフトをレポート、通知、修復できます。リポジトリーにコミットされたコードをスキャンし、重大な脆弱性が特定された際にCI/CDシステムでビルドを中断できます。ガイダンス、推奨事項を提示して問題解決を支援し、開発者のエクスペリエンスを向上させることができます。ツールと統合してほぼリアルタイムのアラートを生成し、適切なオーナーおよび部門に対して、問題とその影響、問題の修復に必要なアクションに関するコンテキストとあわせて通知できます。クラウドを活用して、ビジネスの簡素化と保護を実現するソリューションを世界中の大手企業に提供しています。その他の商標はすべて、それぞれの所有者に帰属します。