Regulaを使ってScalrデプロイのTerraformセキュリティを自動化する［チュートリアル］

RegulaとScalrのインテグレーションの概要

Regula

Regulaを使うと、クラウドチームはデプロイ前にTerraform、CloudFormation、Azure Resource Manager、KubernetesのInfrastructure as Code（IaC）を評価し、セキュリティやコンプライアンス上の違反を検出できます。Regulaは、Regoのオープンソース実装です。RegoはOpen Policy Agent（OPA）プロジェクトで使用されるクエリ言語です。該当する場合、RegulaのポリシーはCenter for Internet Security（CIS）のAmazon Web Services（AWS）、Azure、Google Cloud、Kubernetes Foundationベンチマークに対応付けられており、ユーザーはデプロイ前にIaCへこれらのポリシーを適用できます。

Regulaでデプロイ前にIaCの設定ミスをスキャンすることで、クラウドセキュリティとコンプライアンスの責任を、開発者にとって使いやすい形で開発チームにも広げられます。これにより、IaCを使ってクラウドインフラをデプロイする際のセキュリティ上のボトルネックを解消できます。RegulaはFugueのエンジニアが保守しています。

Scalr

Scalrは、プルリクエストの自動化、ネイティブのTerraform CLI、モジュール駆動のワークフローをサポートするTerraform Automation and Collaboration（TACO）ソフトウェアです。Scalrは、RBACなどの管理者業務、OPAによるポリシー制御、運用ビュー、プライベートモジュールレジストリを一元管理する階層型モデルを通じて、あらゆる規模の組織の拡張を支援します。これによりTerraform運用を適切に分散し、開発者は各自の環境でTerraformワークフローを独立して実行できます。

目的

Regulaの使いやすく強力なIaCスキャン機能と、ScalrのTerraform自動化・コラボレーション機能を組み合わせ、Terraformを使ったクラウドインフラの安全なデプロイを組織がどのように自動化できるかを紹介します。

前提条件

手順を一緒に進めるには、以下が必要です。

• カスタムフックが有効になっているScalrアカウント（注：有料機能です）。設定方法は後述します。

• Scalrアカウントで設定済みのワークスペース。ワークスペースには、Terraformで管理するリソースに関連するすべてのオブジェクトが保存・管理されます。

• Scalrアカウントに追加されたクラウドプロバイダーの認証情報（このデモではAWSを使用します）

• Scalrアカウントで設定済みのバージョン管理システム（VCS）プロバイダー（このデモではGitHubを使用します）

• scripts/security.bash を「Before plan」カスタムフックに、scripts/validate.bash を「After plan」カスタムフックに割り当てます

• /usr/local/bin ディレクトリに最新バージョンのRegulaを配置します（security.bash スクリプトがこれを取得してScalrパイプライン内で実行しますが、ローカルに用意しておけばコミット前にコードを評価できます）

必要に応じて、ターミナルで次のコマンドを実行して、私のリポジトリをクローンすれば作業を一部省略できます。

git clone https://github.com/fugue/fugue-scalr-integration.git

リポジトリの内容

上の図は私のリポジトリのファイル構成を視覚的に示したもので、主な内容は次のとおりです。

• main.tf：プロバイダーとモジュールの情報を宣言するTerraformファイル

• s3/：意図的に脆弱性を含めたTerraformファイルを格納するサブディレクトリ

• waivers.rego：特定のルールを免除または無効にするファイル

• .regula.yaml：このリポジトリでRegulaを実行する方法を指定する設定ファイル

• scripts/：前述のカスタムフックを格納するサブディレクトリ

S3モジュールの内容をさらに詳しく示したものです。すべてのインフラの設定状況を重ねて表示しています（CISベンチマーク違反は赤色）。

Scalrのカスタムフックを設定する

カスタムフックを使うと、コマンド、スクリプト、API呼び出しによって、Terraformの基本ワークフローをカスタマイズできます。このデモでは、Regulaによるセキュリティとコンプライアンスのスキャンに加え、シェルスクリプトでTerraformのフォーマットと検証もチェックします。

カスタムフックはワークスペースの作成時にも、その後いつでも追加できます。ワークスペースの設定で、planの前後とapplyの前後に実行する処理を指定します。以下にカスタムフックの設定方法を示します。

「Settings」ページの「Advanced」オプションでは、Terraformコマンドを実行する相対パスを選択できます（この例ではs3/ディレクトリを選択しました）。そのため、スクリプトのパスの前に“./../”を付けています。

最小限の手間でセキュリティスキャンを自動化する

IaCを使ってクラウドを利用する最も手軽な方法は、初心者も経験者も、インターネット上や同僚・チームから入手したTerraformコードを使うことです。コードは安全でコンプライアンスに準拠していると思い込んでしまいがちです。こうしたコードは、利用可能なフォーマット、lint、検証のチェックをすべて通過しても、使用する人を深刻な脆弱性にさらす可能性があります。

潜在的な脆弱性を明らかにする：Regulaでインフラをスキャンする

このデモでは、できるだけ早くS3バケットをデプロイできるTerraformコードを探し、あえて最も手軽な方法を選びました。まず、このTerraformコードがどれほど脆弱かを示すため、リポジトリ内でregula runをローカル実行します。

このコマンドを実行すると、Regulaは次の処理を行います。

• リポジトリ全体から、サポート対象のIaCファイルを自動検出する

• 検出したサポート対象のIaCファイルすべてに対して、セキュリティとコンプライアンスのスキャンを実行する

• スキャン結果を重大度の高い順に出力し、次の情報を表示する。

  • FugueのルールID（例：FG_R00099）とタイトル

  • ルールの重大度（例：[High]）

  • ルールの修正手順へのハイパーリンク（例：https://docs.fugue.co/FG_R00099.html）

  • IaCファイル別に示されたルール違反の箇所

上記のスキャン結果は、DevOpsエンジニアにもセキュリティエンジニアにも看過できないものです。脆弱なコードをコピーしてデプロイすれば、脆弱性を自動検出して悪用するハッカーに自らをさらすことになります。さらに、私はパイプライン（Scalrのパイプラインなど）に統合せず、手動でスキャンを実施しました。つまり、最も手軽な方法ではありませんでした。過去の侵害事例から、クラウドを狙うハッカーは自動化によって脆弱性を見つけ、それを足掛かりにして、守るべきインフラやデータを攻撃することが分かっています。クラウドに到達する前にリソースを適切に設定する自動化を怠れば、こうしたハッキングは「起こるかどうか」ではなく「いつ起こるか」の問題になります。

コードの一部を見て、これらのルール違反を詳しく確認しましょう（手順を一緒に進めている場合、以下のコードはs3/bucket.tfの18～26行目です。見やすいようにインデントを左に寄せています）。

18server_side_encryption_configuration {
19  rule {
20    apply_server_side_encryption_by_default {
21      #Un-comment below to satisfy FG_R00099
22      #kms_master_key_id = aws_kms_key.mykey.arn
23      #sse_algorithm     = "aws:kms"
24    }
25  }
26}

このコードに意図的に含めた脆弱性には、Regulaに標準搭載されている番号付きルールに準拠するための修正箇所を示すコメントを添えています。現在のコードは、CISベンチマークで重大度が高い違反とされるルールFG_R00099に違反しています。適切に修正せずにデプロイすると、このAWS Simple Storage Service（S3）バケットによって、保存データが外部にさらされます。この記事を読んでいる初心者の方には、銀行の金庫と貸金庫を開けたままにしておくようなものだと考えると分かりやすいでしょう。現金を装甲車で運んだとしても（この例では転送時の暗号化に相当します）、金庫と貸金庫に鍵をかけなければ（サーバー側の暗号化を適用しなければ）、データを守る取り組みは無意味になりかねません。

この例で恐ろしいのは、コードの出典であるTerraformのドキュメントが、できるだけ簡単にS3バケットをデプロイする方法を説明している点です（ドキュメントではよくあることです）。必須パラメーターの例を優先し、サーバー側の暗号化などのオプションパラメーターは、見落としやすい後半部分に記載されています。結局、クラウドリソースを設定する責任は利用者にあります。クラウドプロバイダーが提供するのは、クラウドインフラを安全にデプロイして利用するための手段です。

簡単に自動化できるのに、なぜセキュリティを運任せにするのでしょうか？

柔軟に適用する：ルールを免除・無効化する

重大度が低または中のルールが、重要なビジネス要件と相反する場合もあります。たとえば、静的ウェブサイトをホストするS3バケットを通じたコンテンツ配信に依存するビジネスなら、対象のS3バケットがFG_R00229（S3バケットではすべての「パブリックアクセスをブロック」オプションを有効にする）に違反しているという警告が表示され続けることに、うんざりするのも無理はありません。Regulaでは、特定のリソースに対する特定のルールを免除したり、特定のルールを完全に無効化したりできます。このデモでは、ロギング用バケットについてFG_R00274を免除し、免除設定ファイル（waivers.rego）を使ってFugueのルールFG_R00275を完全に無効にしました。Regulaでルールを免除・無効化する方法は、以下のとおり簡単です。

package fugue.regula.config

waivers[waiver] {
  waiver := {
    #Waiving bucket logging (for the logging bucket)
    "rule_id": "FG_R00274",
    "resource_id": "module.s3.aws_s3_bucket.logbucket"
  }
}

rules[rule] {
  rule := {
    #Disabling cross region replication (budgetary purposes)
    "rule_id": "FG_R00275",
    "status": "DISABLED"
  }
}

IaCセキュリティを運用に組み込む：設定ミスをクラウドへ持ち込まない

ここからは、RegulaとScalrのTerraformリモートステートおよび運用バックエンドを連携させ、設定ミスのあるインフラがクラウドにデプロイされるのを防ぐ方法を見ていきましょう。

最初のカスタムフックスクリプト（security.bash）は、最新バージョンのRegulaを取得、展開、移動して実行します。すべてのTerraformファイル（HashiCorp Configuration Language（HCL）またはTerraform JavaScript Object Notation（JSON）プラン）をスキャンし、終了コードが0以外の場合はメッセージを出力してScalrのビルドを停止します。終了コードが0の場合は、ビルドを続行します。

次のカスタムフックスクリプト（validate.bash）は、このリポジトリのTerraformが有効で、HCLの標準形式に従って適切にフォーマットされていることを確認します。Terraformが無効な場合、このスクリプトは0以外の終了コードを返します。有効な場合は、Scalrがビルドの残りを実行し、自動的にterraform planとterraform applyを実行して、インフラをクラウドにデプロイします。Terraformの状態は使いやすいインターフェースで管理されます。

ビルドを試す（失敗例）

次に、脆弱なTerraformコードをGitHubリポジトリにコミットした場合の動作を紹介します。まず、以下のコマンドを実行します（<files>は、GitHubにコミットしてプッシュするファイルを指定するプレースホルダーです）。

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

Scalrはリポジトリへの変更を検出し、指定したスクリプトを使ってTerraformコードのセキュリティとコンプライアンスの問題をスキャンします。

Regulaで設定の問題を解決する

Terraformファイルに設定ミスがあると分かったので、VSCodeでリポジトリを開き、regula runをローカル実行して問題を修正できます（または、Scalrの実行時に行われたregula runの出力をエクスポートする方法もあります）。このリポジトリでは、コメントアウトを解除するだけでTerraformコードの修正を簡単に適用できるようにしていますが、インフラを適切に設定する方法は、regula runの実行後に各ルールとともに表示されるハイパーリンクをクリックするだけです。修正するルール（FG_R00036とFG_R00101）はいずれも1行のコードで解決できます。このコードは、コマンドの出力にあるリンク先のルール修正手順から直接取得したものです。これ以上開発者にとって使いやすい方法は、なかなかありません。

ビルドを試す（成功例）

インフラを適切に設定できたので、ScalrのTerraform自動化機能を最大限に活用するため、もう一度GitHubリポジトリにコミットします。カスタムフックスクリプトが再度実行され、問題がなければScalrがterraform planとterraform applyを実行します。

これを実証するため、最初に実行したコマンドをもう一度実行します。

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

…その結果、ビルドに成功しました。

これで完了です。RegulaとScalrのおかげで、Terraformを使ったクラウドインフラのデプロイを安全に自動化するパイプラインができました。

次のステップ

上記の例では、CIS Benchmarksに準拠してIaCを保護する方法を紹介しました。HIPAA、SOC2、ISO 27001、NIST 800-53、GDPR、PCI DSS、AWS WAF、CSAなど、ほかのコンプライアンス基準への対応が必要な場合は、www.fugue.coをご覧ください。また、上記の例ではカスタムフック（Scalrの有料機能）も紹介しました。クラウドインフラのコスト見積もり、セルフホスト型エージェント、SSO、ポリシーのプレビューなど、より便利な機能をお求めの場合は、https://www.scalr.com/をご覧ください。

Regulaについて詳しく知りたい方は、GitHubリポジトリとドキュメントをご覧ください。Regulaは、Terraform HCL、Terraform plan JSON、CloudFormation YAML/JSON、Kubernetes YAMLマニフェスト、Azure Resource Managerテンプレートを評価し、セキュリティやコンプライアンス上の違反を検出します。また、免除、カスタムルール、ルールの有効化・無効化などにも対応しています。

クラウドインフラの安全なデプロイを自動化する別の方法に興味がありますか？RegulaとTravis CIの統合に関するブログ記事、またはRegulaとBitbucket Pipelinesの統合に関するブログ記事をご覧ください。