LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

サービス・製品 | 

ドリフト検知~クラウドインフラの設定とIaCの差分を検出する~

ソリューションコンサルティング部の鈴木です。

昨今、効率性、信頼性、一貫性、スケーラビリティ、テストのしやすさなどといったさまざまな理由から、Infrastructure as Code(以下、IaC)により、クラウドインフラの設定、管理を行っている組織は多いのではないでしょうか。

今回は利用が拡大しているIaCで発生している問題点と、その解決策について紹介します。

IaCにおける構成ドリフトの発生とその対策

IaCとは、クラウドインフラの構成管理をコードで行う手法を指します。

従来はクラウドサービスプロバイダの提供するGUI画面でマシンタイプの選択、ディスク容量、アクセス制御などを1画面、1項目ずつクリックして設定していました。この方法では少数のサーバを設定するような場合には比較的容易に設定できる一方、数十台~数百台を設定、管理する場合、非常に手間がかかる上に設定ミスも起きやすくなります。この問題を解決するためにIaCが利用されます。

IaCには以下のメリットがあります。

  • クラウドインフラの設定画面(GUI)を1画面、1項目ずつ設定していくのではなく、全てコード化して設定を行うため、大量のクラウドインフラを迅速に立ち上げ可能。
  • 一度作成したコードは共有・再利用が可能。
  • 作成されたコードを第三者が検証できる。誤った設定が原因のクラウドインフラの破壊や、脆弱性の発生を未然に防げる。

ラックではHashiCorp Terraformの販売、導入支援を行っており、クラウドインフラ設定のためにIaCが広く普及していることを実感しています。

Infrastructure as Codeのイメージ
Infrastructure as Codeのイメージ

構成ドリフトとその対策

一方でIaC導入時には想定していなかった、設定ミスによるクラウドインフラの脆弱性も発生しています。

Terraformではプロビジョニング時に利用するコードと、現状のクラウドインフラの構成を記録したStateファイルでクラウドインフラを構成管理しています。クラウドインフラを設定変更する場合、まずコードを修正し、Terraformを使いプロビジョニングすることで実環境とStateファイルが変更されます。常にクラウドインフラとStateファイル、コードが同期されているのが本来の運用方法です。

ところが最初にTerraformを使ってクラウドインフラを設定したにも関わらず、以下の手順で設定変更を行い、Stateファイルと実際のクラウドインフラ設定内容に差異が発生します。これを「構成ドリフト」と言います。

  • クラウドサービスプロバイダ(AWS、Azure、Google Cloudなど)の提供するGUI画面やコマンドライン(CLI)で設定変更する。
  • Terraform以外のIaCツール(AWS CloudFormationやAzure Resource Managerなど)で設定変更する。

上記手順で、以下のような設定変更を行ったまま放置された事例がありました。

  • S3バケットに、暗号化してデータを保管する設定を誤って解除してしまった。
  • セキュリティブロックのCIDRブロックレンジを一時的に0.0.0.0/0と設定変更し、クラウドインフラに誰でもアクセス可能な状態にしたまま放置してしまった。

システム管理者はStateファイルの内容を正と考えているので、知らぬ間にデータ保管の暗号化が解除されたり、セキュリティブロックのCIDRブロックレンジを上記設定に変更したまま放置されたりしていても気付けないかもしれません。データが漏えいして初めて事態を認識する可能性もあります。

これらを防ぐにはクラウドインフラの構成変更は「必ずTerraformを使用して実施する」を徹底することになりますが、それだけでは不十分です。クラウドインフラの状態を常に監視し、構成ドリフトが発生した場合は速やかに検知する仕組みが必要です。これがドリフト検知(Drift detection)です。

構成ドリフトが発生する要因
構成ドリフトが発生する要因

Terraformによるドリフト検知

Terraformの商用版(HCP Terraform Plus/Terraform Enterprise)でドリフト検知が可能です。

通常Terraformはデプロイを行う必要が発生した際にオンデマンドで実行しますが、ドリフト検知機能が有効になっているWorkspaceに対しては、Terraformが「自動的」にバックグラウンドで構成ドリフトを検知します。

ドリフト検知の仕組み
ドリフト検知の仕組み

Terraformのドリフト検知設定手順

HCP Terraform Plus/Terraform Enterpriseに以下の設定を行うことによりドリフト検知が有効となります。

①Terraformトップ画面からOrganization Settings→Healthをクリックします。下記では全てのワークスペースに適用するのではなく、個別のワークスペースに設定するため、Pre workspace settingsにチェックし、Update Settingsをクリックします。

Organization SettingsのHealth設定を反映する

②Workspace Overview画面から、Settings→Healthをクリックします。

Workspace Overview画面からSettingsのHealth画面へと移動する

③Health Assessments Enableを選択し、Save settingsをクリックします。

Health Assessmentsの設定を反映する

④Health→Driftをクリックします。

Workspace Overview画面からHealthのDrift画面に移動する

⑤構成ドリフトが発生すると、どのリソースにおいて差異があるか表示されます。

構成ドリフトが発生した場合、どのリソースにおいて差異があるか表示される

⑥Workspace Overview画面でもドリフト検知が可能です。

Workspace Overview画面でもHealth表示部分に構成ドリフトが起きたリソース数が表示される

ドリフト検知後の対応について

ここまで記述したとおり、構成ドリフトは実際のクラウドインフラとTerraformで管理しているStateファイルに差分が発生している状態です。この問題を解消するためには、以下作業が有効です。

ドリフト検知後の対応
ドリフト検知後の対応

①と②は設定内容の追加、③は設定内容の削除にあたります。

①「Refresh state」を行い、TerraformのStateファイルを更新

Refresh stateはあくまで「Terraformで管理しているStateファイル」の更新であり、クラウドインフラ設定の元となるソースコードは修正されません。ソースコードに記述されていない設定であれば、本作業のみで問題ありませんが、ソースコードに書かれている設定が変更されたのであれば、後述のソースコード変更作業が必要です。

Refresh stateを実行

②更新されたクラウドインフラの設定内容をソースコードに反映

ソースコードを変更すると、Terraform上で自動的にplan、applyのRunが起動します。変更内容に現状のクラウドインフラと差分がなければ、planの実行結果にNo Changesと表示され、applyは実行されません。

Runs画面

③「Plan and apply」を行い、元の設定内容を反映

構築時と同様、new runボタンをクリックし、表示されたポップアップのRun Typeに「Plan and apply」が選択されていることを確認して「Start」ボタンをクリックします。plan、applyと進んで現在のstateファイルを元にした情報にクラウドインフラを更新します。

Plan and applyを実行

さいごに

IaCにおいてドリフト検知は、クラウドインフラの誤った設定を防ぐために極めて重要であることがお分かりいただけたかと思います。構成ドリフトが頻発するとコードの信頼性がなくなり、IaCのメリットも失われます。

また管理者がドリフトにより発生した脆弱性に気付かないことは、自社のクラウドインフラを極めて危険な状態に晒すことにもなります。こういった事態を防ぐためTerraformのドリフト検知機能で常時クラウドインフラを監視することは非常に有効です。

クラウドインフラを安全に運用する方法をご検討中の方は、どうぞお気軽にお問い合わせください。

プロフィール

鈴木 真人

鈴木 真人
主にアプリ開発プロセスにおけるセキュリティや、クラウドセキュリティを実現するソリューションの提案に取り組んでいます。DevOpsに「+セキュリティ」する方法について、今後も発信を行っていきます。

「クラウドインフラの運用」に関するお問い合わせ

この記事は役に立ちましたか?

はい いいえ