構成ドリフトを検出・防止する方法

組織全体で構成ドリフトを検出する方法

自動化、手動、オンプレミス、クラウドベース、あるいはその組み合わせなど、組織がどのような方法でインフラを運用していても、日々の小さな変更は避けられません。システムは利用され、社内外のニーズに合わせて変更されることを前提に構築されているため、時間の経過とともに変化していきます。 

複数のエンジニアやチームが適切な手順に従わず、その場しのぎでインフラに変更を加えると、小さな変更がすぐに積み重なり、現在のシステム構成と本来あるべき状態の基準との間に不整合が生じます。これが構成ドリフトです。不適切な方法で変更が実装され、時間の経過とともにインフラに問題を引き起こします。

構成ドリフトはあらゆる種類のインフラ環境で発生しますが、Infrastructure as Code（IaC）環境を利用する企業には、ドリフトの修正や事前防止において特有の課題がいくつかあります。IaCにはバージョン管理などの仕組みがあるため、文書化されていない変更がデプロイされにくく、原因の一部は標準で抑制されます。しかし、自動化されたクラウドプロビジョニングの速いペースが、別の問題を引き起こすこともあります。DevOpsやCI/CDなどの自動化された開発環境では、変更が急速に行われるため、構成ドリフトが特に短期間で積み重なる可能性があります。 

最終的に、IaCにおけるドリフトは、インフラの現在の状態が、コード化されたIaC構成と一致しないときに発生します。その結果、エンジニアは最新ではないインフラのバージョンをもとに作業する一方、実稼働システムには食い違ったバージョンが存在することになります。 

構成ドリフトの原因とは？

構成ドリフトは、システムの構造に加えられたさまざまな変更によって発生します。よくある原因をいくつかご紹介します。

• システムへの手動変更。 TerraformやCloudFormationなど、確立されたIaCシステムの外部でリソースを手動で作成または変更すると、その変更はコード化された構成に反映されません。 

• 認証済みアプリケーション。 これは、スクリプトの読み取りやバケットへの書き込みなど、自動処理を実行するマイクロサービスが、何らかのバグにより意図したとおりに動作していない状態を指します。こうした自動化のエラーはドリフトにつながる可能性があります。

• IaC内の隠れた変更、見落とされた変更。 予期しない変更によってIaC環境に不整合が生じ、エンジニアが作業している内容と、実環境で実際に起きていることとの間に隔たりが生まれます。 

• パッチとアップグレード。 新しいパッチやアップグレードをリリースするには、エンジニアがシステムに大小さまざまな変更を加える必要があります。それぞれの変更がドリフトを引き起こす可能性があります。 

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

構成ドリフトはチームに深刻な問題を引き起こす可能性があり、特にIaCを利用しているチームは注意が必要です。インフラの現在の状態がコード化されたIaC構成と一致しなくなると、エンジニアは最新ではないインフラのバージョンをもとに作業する一方、実稼働システムには食い違ったバージョンが存在することになります。エンジニアのシステムに関する知識と実際のシステムとの隔たりが大きくなるほど、セキュリティ態勢、パフォーマンス、コンプライアンスは悪化します。 

セキュリティリスク

ドリフトを放置すると、深刻なセキュリティ問題を招き、システムが攻撃者にさらされる可能性があります。その場しのぎで文書化されていない変更によって、未知のバックドアが生じることがあるためです。多くの場合、本当のリスクは、システムに加えられた変更を把握できず、脆弱性が放置されることにあります。たとえば、2020年に発生したTwilioの情報漏えいは、S3バケットの構成ドリフトが原因でした。エンジニアが以前の問題を修正した際、バケットの構成を安全でない状態にしてしまいました。構成を検出して元の安全な状態に戻す対処が行われなかったため、ドリフトは何年も見過ごされ、最終的に攻撃者に悪用されてユーザーの個人データが窃取されました。

パフォーマンスの問題

構成ドリフトはセキュリティ上の脆弱性を引き起こすだけでなく、パフォーマンスの低下やダウンタイムにつながる可能性もあります。インフラの現在の状態が実際のIaCコードと一致しないと、過剰にプロビジョニングされたワークロードや、最適化されていないリソースやプロセスが生じます。こうした小さな不整合が積み重なると、多くのパフォーマンス問題を招きます。

コンプライアンス違反

IaCは、現在のシステムの状態を示す生きたドキュメントとして機能するべきです。構成ドリフトによってコード化されたIaCの正確性が損なわれると、小さな変更がセキュリティポリシーに従って適切に対処されなくなります。たとえば、エンジニアがIaCに変更を反映せずにポートを開放したとします。この変更に問題がなくても、システムの現在の状態がIaCで定義された状態や、それに付随するセキュリティポリシーから「乖離」します。監査では、これがコンプライアンス違反と見なされます。

構成ドリフトを検出する方法

構成ドリフトの管理手法を取り入れることで、チームはドリフトが根本的な問題を引き起こす前に検出し、修正できます。インフラを確認してドリフトを検出し、修正に向けた具体的な次の手順を提示するツールが数多くあります。 

管理対象リソースと非管理対象リソース

チームで構成ドリフト検出ツールを検討する際には、管理対象リソースに特化したソリューションと、非管理対象リソースへの対応を目的とするソリューションがあることに注意してください。Terraformのリソースなど、管理対象リソースのドリフトを検出するには、特定済みのアセットを定期的にスキャンし、ドリフトの兆候を調べられるソリューションが必要です。 

一方、非管理対象リソースに対応するには、文書化されておらず、そのためドリフトを定期的に確認されていないアセットをすべて洗い出せるツールが必要です。非管理対象リソースを特定したら、IaCの管理下に置くための手順を実施する必要があります。 

構成ドリフト管理ツール

• Terraform plan。 Terraformのインスタンスで実行できるコマンドです。管理対象リソース内のドリフトを特定し、発生した未文書化の変更と、ドリフトを修正するための計画を説明します。ただし、このコマンドラインツールで検出できるのは管理対象リソース内の変更のみで、非管理対象リソースには対応していません。

• Snyk IaC。 当社の構成ドリフト管理ツールは、チームがドリフト検出を迅速かつ簡単に導入できるよう支援します。非管理対象リソースをTerraformの管理下に置き、クラウドのIaCカバレッジを向上させる機能を備えています。使いやすいレポートを通じて、開発とセキュリティの連携を促進します。 

• CloudQuery。 このオープンソースのクラウドアセットインベントリツールは、クラウドリソースをすばやく列挙し、非管理対象リソースを検出して、複数のstateファイルをスキャンできます。クラウドアセットの可視化には役立ちますが、ドリフトの修正にはいくつかの欠点があります。CloudQueryはS3バケットのドリフト検索の精度に欠けることがあり、バックエンドのstateファイルストレージへの対応が限られています。また、SQLデータベースが必要で、すべてのTerraformリソースをサポートしているわけではありません。

• Driftctl。 Snykがメンテナンスしているこのオープンソースのリソース管理ツールは、ドリフトを検出、追跡し、アラートを出せます。非管理対象リソースのドリフトを検出し、複数のstateファイルをスキャンできるなど多用途ですが、いくつかの不足もあります。たとえば、すべてのTerraformリソースに対応しているわけではありません。また、APIのスロットリングエラーや、ディープモードでのスキャンに時間がかかるといった問題を経験したユーザーもいます。 

システムは時間とともに進化し変化するため、構成ドリフトは避けられません。しかし、組織がドリフトを発生後すぐに特定して修正することに注力すれば、後の工程で問題に発展するのを防ぎ、時間とリソースを節約できます。組織がSnyk IaCを活用してドリフトを管理・防止できるよう、当社はこの製品を開発しました。実際の動作をご覧になりたい場合は、ぜひデモをご依頼ください。