インフラのドリフトおよびドリフトの検出について
March 9, 2022
0 分で読めます期待は必ずしも現実と一致しません。インフラの管理に Infrastructure as Code (IaC) を使用することにすれば、クラウドプロビジョニングプロセスのセキュリティを確保する点ですでに進歩を遂げているといえます。ただし、インフラのライフサイクルにはもう一つの要素があります。クラウド上の IaC でまだ管理されていないリソースをどのように把握すればいいのでしょうか。また、マネージドリソースは、定義したコードの状態でそのままクラウド内に残りますか？
クラウド上のワークロードは常に変化しています。クラウドで実行されるワークロードの量が増加するということは、複数のクラウド環境でインフラを操作するユーザーや認証サービスの数が増えるということです。IaC の採用が広がり、IaC のコードベースが拡大するにつれ、変更を追跡したり、手動による設定変更を考慮したりすることが一層難しくなっています。そのため、クラウド上に導入され、稼働していて、自動化されているもののセキュリティ確保については、ドリフト検出が重要になります。
このブログでは、インフラのドリフトの定義、ドリフトの原因、ドリフトを管理するヒントについて、個人の開発者から大企業に至るまで、幅広く説明します。
インフラのドリフトとは
インフラのドリフト、または単に「ドリフト」とは、インフラのリアルタイムの状態が IaC の設定で定義されたものと一致しない状態をいいます。このように、定義したコードとクラウド上に存在するものが違うという状況はさまざまな理由で起こり得ます。
IaC を使用すること、または IaC で多数のクラウドリソースをカバーすることのメリットは、ドリフトの発生を最小限に抑えられることにあります。導入前に目的の設定とセキュリティのベストプラクティスを定義することで、クラウドコンソールの設定を後から変更しなくてすみます。それでも、緊急事態や人為的なミスによって避けられない変更が生じることもあります。
ドリフトが発生する原因には、人間による入力、設定の不備、アプリケーションによる不要な変更などがあります。ドリフトの最も一般的な原因の 2 つは、プロセスやワークフローの問題に関連しています。たとえば、クラウドコンソールで手動で行った変更がコードに反映されていないこと、または特定の環境に適用した変更が他の環境に伝播されていないことです。
一般的なインフラのドリフトの原因:
手動による変更: 誰かがコンソールにアクセスし、Terraform、CloudFormation などの IaC 以外でリソースを手動で作成、変更した
認証済みアプリケーション: マイクロサービスが本来のパフォーマンスを発揮していない
IaC 環境が同期されていない: 環境ごとに隠れた変更や見えない変更がある
ドリフト検出とは
ドリフト検出とは、IaC によって管理されるクラウドインフラのドリフト、特に組織にセキュリティリスクをもたらす IaC からの逸脱を検出する継続的なプロセスです。ドリフト検出ツールの結果には、開発者が問題をすばやく把握し、導入されたインフラで問題を修正できるように、開発者フレンドリーな方法で報告されたドリフト結果 (適切なフォーマットで直接報告できる Terraform リソース) が含まれることが理想的です。
これは、IaC セキュリティの第二段階と考えることができます。開発やビルドパイプラインの最中だけでなく、本番環境に移行した後も、設定ミスの問題を発見し、IaC でセキュリティガードレールを適用できます。
「すべてのドリフトイベントで不確実性が生じ、解決に時間がかかり、潜在的なセキュリティ問題を引き起こします。」
DevOps インタビュー回答者
ドリフト検出は重要です。セキュリティが確保されているのは、実際にクラウド環境に導入され実行されているものだけだからです。IaC でインフラの管理を自動化すると、セキュリティが確保されたように感じがちですが、状況は変わることがあります。ドリフト検出が必要になるのはそのためです。IaC 設定が書き込まれた瞬間からクラウドに導入された後まで、インフラのライフサイクル全体を通じて、自動化に対応し、セキュリティを構築することが重要です。
ドリフトが管理されない場合
意図的かどうかに関わらず、開発者は IAM キーと SDK だけで多大な損害をもたらす可能性があります。誤った判断にすばやく気づき、健全で安全な状態に戻せるようにすることが非常に重要です。
インフラ設定のドリフトで生じる悪影響の例は、次のとおりです。
データの漏洩: ドリフトによって、重要なデータが流出する可能性があります。
アプリケーションの停止: ドリフトによって、アプリケーションがクラッシュする可能性があります。
導入の失敗: ドリフトによって、導入が失敗する可能性があります。
このような場合、IaC のカバレッジを高め、IaC で管理するインフラの割合を増やすことで、IaC で管理しない場合と比べてドリフトを最小限に抑え、問題をすばやく改善できます。IaC によって自動化されたインフラの導入とは対照的に、手動で設定されたリソース、つまりアンマネージドリソースは、セットアップに時間がかかり、エラーが発生しやすくなります。IaC を使用すると、インフラのセットアップを標準化できるため、セットアップ時のエラーや依存関係の削除 (セキュリティグループルールや IAM ポリシーの欠落など) が発生する可能性が低下します。
データ漏洩が発生した場合、すべてのリソースが IaC によって管理されていれば、セキュリティ管理を標準化し、S3 バケットが公開されるなどの問題を防止するか、軽減できます。ダウンタイムが発生した場合でも、インフラを効率的に追跡し、障害発生前の最後の正常なバージョンを再度導入することが可能です。
ドリフト検出とドリフト管理の比較
ドリフト管理はドリフトのリスクを軽減し、ドリフトをすばやく処置する包括的なセキュリティソリューションです。マネージドリソースのドリフトを検出し、クラウド環境内のアンマネージドリソースを検出してコントロールできるようにします。
セキュリティチームと開発チームが IaC でクラウドリソースを 100% カバーし、ワークフローを次のようにするのが理想的です。つまり、アンマネージドリソースを検出し、コードとしてインポートしてから、自社の定義した IaC セキュリティのベストプラクティスとコンプライアンスポリシーに従ってテストを実施し、健全でセキュアな状態にするというフローです。
インフラのセキュリティを確保してコードと同期する
IaC セキュリティの包括的な手順は、以下のとおりです。
クラウド環境全体でクラウドリソースに対する IaC カバレッジを拡大する。
IaC セキュリティツールを採用して開発中に設定をスキャンし、設定ミスの問題を早期に発見した上でセキュリティレビューを実施する。
IaC (Terraform または AWS CloudFormation) を活用し、同期したインフラを検出する。
オープンソースのドリフト検出ツール (driftctl) を使用して、本番環境でのドリフトの問題を検出し、開発者の言葉でドリフト結果を開発者に報告する。
driftctl の結果に基づいて、開発者がコードを追加し、Terraform でそのままインポートすることによってアクションを実行する。
IaC セキュリティツール (または
snyk iac test) を使用して、新しく作成された Terraform コンフィギュレーションのセキュリティを確保し、フィードバックループを閉じる。必要に応じて、十分なカバレッジが得られるまで地域ごとに繰り返し実行する。
最後に、アラートとして必要な繰り返しジョブを作成する (たとえば、IAM の変更がないか 1 時間ごとにチェックするジョブや、重要度が低いクラウドサービスは毎日チェックするジョブなど)。
ドリフトを軽減する際の考慮事項
最近では、ドリフトの検出・管理用のツールが数多く存在します。ツールを選ぶ際には、考慮すべき点がいくつかあります。
決定するにあたり、ツールにどのレベルのアクセス権限を与えるかを確認します (例: フルアクセス、読み取り専用アクセス、最小特権ポリシーなど)。Terraform のような特定のツールでは完全に認証されたアクセスが必要ですが、その他のツールでは読み取り専用アクセスが必要です。前述の driftctl は、最小特権アクセスまたはドリフトの検出に必要な最小限のアクセスで動作します。
Snyk IaC によるドリフト管理
マネージドリソースのドリフトを検出するだけでなく、アンマネージドリソースを IaC で管理することも目的であれば、Snyk がまさにこの点で最適です。Snyk IaC のドリフト管理では、問題や修正について直接、開発者が理解しやすい言葉で報告することで、インフラのセキュリティをすばやく確保できます。クラウドセキュリティと開発チームの間にすばやいフィードバックループを構築することで、開発者はコードからクラウドまでの Terraform を自ら管理し、導入のインフラ設定のセキュリティを確保できるようになります。また、クラウド環境全体でアンマネージドリソースを特定することで、リソースを IaC で管理するようにし、初期段階からドリフトのリスクを軽減できます。
