インフラストラクチャのドリフトとドリフト検出を解説

期待どおりに現実が進むとは限りません。インフラストラクチャの管理にInfrastructure as Code（IaC）を使い始めているなら、クラウドのプロビジョニングプロセスをより安全にするための第一歩をすでに踏み出しています。しかし、インフラストラクチャのライフサイクルにはもう一つ重要な点があります。クラウド内で、まだIaCによって管理されていないリソースをどうすれば把握できるでしょうか。また、管理対象のリソースは、コードで定義したときと同じ状態をクラウド内で保っているでしょうか。

クラウドワークロードは常に変化しています。クラウドで稼働するワークロードが増えるほど、複数のクラウド環境にわたって、インフラとやり取りする人や認証済みサービスも増えていきます。IaCの導入が進み、IaCのコードベースが大きくなるにつれて、変更を追跡したり、手動での構成変更がコードに反映されていることを確認したりするのがますます難しくなります。そのため、デプロイ後にクラウドで稼働している自動化対象を安全に保つには、ドリフト検出が重要です。

この記事では、インフラストラクチャのドリフトとは何か、発生する原因、管理のヒントを、個人の開発者から大規模な組織まで幅広くご紹介します。インフラストラクチャのドリフトを検出・防止する方法について詳しくは、こちらの記事をご覧ください。

インフラストラクチャのドリフトとは？

インフラストラクチャのドリフト（以下「ドリフト」）とは、インフラストラクチャの実際の状態が、IaC構成で定義された状態と一致しないことです。コードで定義された状態とクラウド上に存在する状態とのこの差異は、さまざまな理由で発生します。

IaCを使用する、またはクラウドリソースのIaCカバー率を高めるメリットの一つは、ドリフトの発生を最小限に抑えられることです。デプロイ前に意図した構成とセキュリティのベストプラクティスを定義しておくことで、後からクラウドコンソールで構成を変更する必要を減らせます。それでも、緊急事態や人的ミスによる変更は避けられません。

ドリフトの原因には人による操作、不適切な構成、アプリケーションによる意図しない変更などがあります。特に一般的な原因のうち2つは、プロセスやワークフロー上の問題に関連しています。たとえば、クラウドコンソールでの手動変更がコードに反映されない、あるいは一部の環境に適用した変更が他の環境に反映されない、といった問題です。

インフラストラクチャのドリフトの一般的な原因：

1. 手動での変更：Terraform、CloudFormation、その他のIaCを使わずに、コンソール上でリソースを手動で作成または変更する

2. 認証済みアプリケーション：マイクロサービスが想定どおりに動作しない

3. 同期されていないIaC環境：環境ごとに隠れた変更や把握されていない変更がある

ドリフト検出とは？

ドリフト検出とは、IaCで管理されているクラウドインフラストラクチャのドリフトを継続的に検出するプロセスです。特に、組織にセキュリティリスクをもたらすIaCとの差異を検出します。理想的なドリフト検出ツールは、開発者が問題をすばやく理解し、デプロイ済みのインフラストラクチャを修正できるよう、開発者にわかりやすい形式（たとえば、Terraformリソースを適切にフォーマットして直接報告する形式）で検出結果を提示します。

これはIaCセキュリティの第2段階と考えることができます。開発中やビルドパイプラインで構成ミスを見つけ、IaCにセキュリティガードレールを適用するだけでなく、本番環境に反映された後も対策を続けます。

「ドリフトが発生するたびに、不確実性が生じ、解決に時間がかかり、セキュリティ上の問題につながる可能性があります。」

DevOpsのインタビュー回答者

ドリフト検出が重要なのは、クラウド環境に実際にデプロイされ、稼働しているものだけがセキュリティの対象だからです。IaCでインフラストラクチャの管理を自動化すると、安心しきってしまうことがあります。しかし、状況は変化します。だからこそ、ドリフト検出が必要です。自動化された内容を常に把握し、IaC構成の作成からクラウドへのデプロイ後まで、_インフラストラクチャのライフサイクル全体を通じて_セキュリティを確保することが重要です。

ドリフトを放置するとどうなる？

意図的かどうかにかかわらず、開発者はIAMキーとSDKだけで大きな損害を引き起こす可能性があります。不適切な判断をすばやく検出し、健全で安全な状態に戻せることが重要です。

インフラストラクチャ構成のドリフトが招く望ましくない結果には、次のようなものがあります。

• データ侵害：ドリフトによって重要なデータが公開される可能性があります。

• アプリケーションのダウンタイム：ドリフトによってアプリケーションがクラッシュする可能性があります。

• デプロイの失敗：ドリフトによってデプロイが失敗する可能性があります。

いずれの場合も、IaCのカバー率を高める、つまりIaCで管理するインフラストラクチャの割合を増やすことで、ドリフトを最小限に抑えたり、IaCで管理されていない場合よりも迅速に問題を修正したりできます。IaCで自動化されたインフラストラクチャのデプロイと比べ、手動で構成されたリソース、つまり管理対象外のリソースは、セットアップに時間がかかり、エラーも発生しやすくなります。IaCを使えばインフラストラクチャのセットアップを標準化できるため、設定ミスや依存関係の削除（セキュリティグループのルールやIAMポリシーの欠落など）の可能性を減らせます。

データ侵害の場合、すべてのリソースがIaCで管理されていれば、セキュリティコントロールを標準化して、S3バケットが一般公開されるといった問題を防止または軽減できます。ダウンタイムが発生した場合も、インフラストラクチャをより効率的に追跡し、障害発生前の最後の正常なバージョンを再デプロイできます。

ドリフト検出とドリフト管理の違い

ドリフト管理は、ドリフトのリスクを低減し、迅速な修正を可能にする、より包括的なセキュリティソリューションです。管理対象リソースのドリフトを検出するだけでなく、クラウド環境内の管理対象外リソースも検出し、それらを管理下に置けるようにします。

理想的な環境では、セキュリティチームと開発チームがクラウドリソースの100%をIaCで管理でき、次のようなワークフローを実現できます。まず管理対象外のリソースを検出し、コードとしてインポートします。次にテストを行い、組織で定めたIaCセキュリティのベストプラクティスとコンプライアンスポリシーに従って、健全で安全な状態にします。

インフラストラクチャを安全に保ち、コードと同期させる

包括的なIaCセキュリティを実現するには、次の取り組みが効果的です。

1. クラウド環境全体で、クラウドリソースのIaCカバー率を高める。

2. IaCセキュリティツールを導入し、開発中やビルドパイプラインで構成をスキャンする。構成ミスを早期に検出し、セキュリティレビューを通過させる。

3. IaC（TerraformまたはAWS CloudFormation）を活用して、同期されたインフラストラクチャを検出する。

4. オープンソースのドリフト検出ツール（driftctl）を導入し、本番環境のドリフトを検出する。開発者が理解しやすい用語で、ドリフトの検出結果を報告する。

5. 開発者がコードを追加し、現状のままTerraformにインポートすることで、driftctlの検出結果に対処する。

6. IaCセキュリティツール（またはsnyk iac test）を使って新たに作成したTerraform構成を保護し、フィードバックループを完結させる。

7. 必要に応じてリージョンごとに、十分なカバー率を達成できるまで繰り返す。

8. 最後に、アラート用の定期ジョブを必要な数だけ設定します（たとえば、IAMの変更を1時間ごとにチェックし、重要度の低いクラウドサービスを毎日チェックするなど）。

ドリフトを軽減する際の留意点

現在、ドリフト検出やドリフト管理のツールは数多くあります。ツールを選ぶ際には、いくつか考慮すべき点があります。

ツールを決める際は、そのツールにどのレベルのアクセス権を付与するか（フルアクセス、読み取り専用アクセス、最小権限のポリシーなど）を確認しましょう。Terraformのように完全な認証済みアクセスを必要とするツールもあれば、読み取り専用アクセスを必要とするツールもあります。前述のdriftctlは、最小権限のアクセス、つまりドリフト検出に必要な最低限のアクセス権で動作します。

Snyk IaCによるドリフト管理

管理対象外のリソースをIaCの管理下に置くとともに、管理対象リソースのドリフトも検出したい場合は、Snykがその両方を実現します。Snyk IaCのドリフト管理は、開発者にわかりやすい形式で問題と修正方法を直接伝え、インフラストラクチャのセキュリティ確保を迅速化します。クラウドセキュリティチームと開発チームのフィードバックループを短縮することで、開発者はコードからクラウドまでTerraformを主体的に管理し、デプロイ後のインフラストラクチャ構成も安全に保てるようになります。さらに、クラウド環境全体の管理対象外リソースも可視化できるため、それらをIaCの管理下に置き、最初からドリフトのリスクを軽減できます。