Snyk IaCでクラウドのセキュリティ問題をソースから迅速に修正

現在のクラウドセキュリティツールは、デプロイ後の脆弱性の特定に重点を置く一方で、クラウドエンジニアがその結果に基づいて行動できるよう支援する機能が不足しており、エンジニアリングチームとセキュリティチームの間にサイロを生み出しています。その結果、開発者は問題を修正するために作業をさかのぼるか、「ClickOps」の罠にはまり、チケットの管理や管理コンソールでのポリシー変更に膨大な時間を費やすことになります。そのため、より戦略的な業務に集中できなくなります。

クラウドはコードです。したがって、クラウドインフラをInfrastructure as Codeとして保護し、統合されたPolicy as CodeエンジンでIaCとクラウドセキュリティを一体化するのが理想的なアプローチです。組織はIaCを事前にスキャンして設定ミスやコンプライアンス上の問題を検出し、本番環境への流出を防ぐとともに、IaCコードでクラウドの問題を修正して再デプロイすることで、セキュリティ態勢の改善とスケールの実現を目指すべきです。

プラットフォームチームに寄せられるセキュリティ関連の依頼が増え続けると、アラート疲れやチケットの過多から、重要なセキュリティツールへの関心や利用が低下しかねません。開発ワークフローへの統合やコンテキストの不足によって、信頼が損なわれることもあります。修正を適用すべき担当者や場所を特定するために、何時間も無駄になることもあります。

クラウドの問題をソースから修正

クラウドプロバイダーのポリシー設定を使って本番環境に修正を適用すると、IaCとクラウドの設定にずれが生じ、IaCが「信頼できる唯一の情報源」ではなくなってしまいます。この構成ドリフトにより、IaCワークフローに重大な変更が生じたり、元のテンプレートから同じ問題を再びデプロイしたりすることになりかねません。ほとんどのクラウドセキュリティソリューションは開発者向けに構築されていないため、パイプラインまたは本番環境でしか機能しません。「自動化された」修復ワークフローは、クラウドプロバイダーのAPIを使って本番環境の問題にパッチを適用することを目指します。一見優れた選択肢に思えますが、実際には構成ドリフトの問題を悪化させるだけです。

可視性を確保するだけでは不十分です。クラウドインフラのセキュリティを向上させるには、継続的なテストとクラウドアプリケーションの全体像を踏まえた、修正を重視するアプローチが必要です。しかし、修正にたどり着くのは必ずしも簡単ではありません。

Snyk IaCでコード内の問題を修正

Snyk IaCは、エンジニアリングチームが開発の初期段階からクラウドを保護できるようにする、従来とは異なるアプローチを採用しています。このプロアクティブなアプローチでは、ビルド前および本番稼働前にIaCコードの設定ミスを検出し、修正できるようにすることで、デプロイ済みインフラのリスク態勢を改善し、開発者とセキュリティチームの手戻りを削減します。また、稼働中のクラウド環境で見つかった問題に対し、開発者の視点に立ったコンテキストとIaCでの修正パスを提示することで、開発者はクラウドエンジニアリングのライフサイクル全体を保護し、IaCコードからクラウド、そしてコードへと、セキュリティ基準をコード化できます。

Snyk IaCの最新機能では、クラウドの問題をデプロイ元のIaCファイルに対応付け、SCM内のIaCソースファイルへのリンクを表示します。IaCソースとの直接的な対応付けにより、クラウドエンジニアはクラウド環境の問題をIaCソースコードまでたどって修正を適用し、変更を再デプロイする作業にかかる時間を大幅に節約できます。

IaCパイプラインと稼働中のクラウド環境にわたる可視性とガバナンスを統合することで、セキュリティチームはより実行につながる結果を得られ、クラウドチームやプラットフォームチームは修正箇所の特定に時間を費やす必要がなくなります。その結果、セキュリティチームと開発チームの連携が向上し、クラウドインフラの安全性も高まります。