人的ミスによる情報漏えいを回避！TerraformとSentinelでAWS S3のセキュリティベストプラクティスを実現

マルチクラウドのプロビジョニングを行うHashiCorp社のTerraformには、無償のOSS版と、チームや組織のガバナンスやコンプライアンスを実現する有償版のTerraform Cloud及びEnterpriseがあります。今回は有償版のメリットと、有償版でのみ利用できる機能「Sentinel」についてご紹介します。

なお、この記事はセキュリティガバナンスの観点からTerraformが企業にもたらすメリットを書いたHashiCorpブログを、同社の許可を得て日本語訳したものです。

Terraform Cloud及びEnterpriseってどんなもの？

AWSのS3バケットに対する誤ったセキュリティ設定が原因で、情報漏えいしてしまうことがあります。AWSがS3のセキュリティベストプラクティスを公開して数年が経つにも関わらず、未だに情報漏えいが発生しニュースになっています。これは、Amazon S3管理コンソールで作成するS3バケットには人的ミスが起こり得るからです。

HashiCorpのTerraformは、Infrastructure as Code^※1の理念に基づき人的ミスを回避します。
Terraform Cloud及びEnterpriseはSentinel^※2を使用して、プロビジョニングしたリソースを企業のセキュリティや運用の要件に合致させることでガバナンスを実現します。

※1 Infrastructure as Code：インフラの構成管理をコードで行うこと。インフラ構築プロセスの自動化やインフラ環境の再現性の担保、及びコンポーネントの再利用といったメリットがある。

※2 Sentinel：HashiCorp社が提供するOSS。有償版のTerraformにプラグインとして組み込まれ、インフラ環境を構築時に、指定したルールに基づくリソースの作成かどうかを検証する機能を持つ。

Terraform Cloud及びEnterpriseは、セキュアで信頼できる"Infrastructure as Code"のパイプラインです。このパイプラインには、組織のセキュリティや運用ガイドラインに従ってリソースを作成するためのガードレールが設置されています。下の図は、この理念を表したものです。

Terraform Cloud及びEnterpriseの使い方

それではこれから、Terraform Cloud及びEnterpriseの使い方をご紹介します。今回は、AWS S3のプロビジョニングプロセスを統制し、Terraformが作成する全てのS3バケットがAWSの公開するS3のセキュリティベストプラクティスに準拠することが目的です。

準備するもの

1. Terraform CloudまたはEnterpriseのアカウント。アカウントをお持ちでない方は、こちらからTerraform Cloudのトライアルアカウントを申請することができます。
2. S3バケットをプロビジョニングするためのAWSアカウント。（S3バケットのプロビジョニング自体は無償です。）
3. GitHubアカウント

手順

1. Terraform Cloudの無料アカウントを取得した後は、organization、VCS接続設定、S3用テストコードの配置するためのVCSリポジトリ、そしてリポジトリに紐づくAWSの認証情報を登録したworkspaceを作成します。
2. トライアルプランを開始します。プランにはTerraform Cloudのガバナンスが含まれ、上記手順で作成したorganizationの"Plan and Billing"画面から確認することができます。

• 3."policy set"を選択して、こちらのリポジトリをフォークした後に、ポリシーを適用するworkspaceを選択します。
  Terraform CloudまたはTerraform EnterpriseのorganizationがVCSリポジトリに接続するための手順は、こちらをご参照ください。

なお、フォークしたリポジトリのsentinel.hclを編集して、適用するポリシーや適用レベルを選択することもできます。

• 4.workspaceでPlanまたはRunを実行して、結果を確認します。

下記Terraformコードを実行した場合：

結果：

詳細な説明

上記の例では、パブリックな読み書き権限を含む適切なACLを設定したAWS S3バケットを作成しようとしました。planを実行した時に、Terraform Cloudはポリシーチェックを実行するための決められたアウトプットをSentinelに送信しました。今回用意したpolicy setの設定ファイル及びsentinel.hclでは、7つのポリシーをsoft-mandatoryに指定しました。

新規作成または更新するリソースは、planをapplyする前にチェックされます。この予防的な動作は、リソースを作成した後にポリシーに反するものを見つけ出すよりも優れています。

ここからは、disallow-s3-acl-public-read-write.sentinelというポリシーを詳しく見ていきましょう。

この記述は、planの出力データを格納するTerraform Sentinel tfplan/v2 importを、ポリシーで利用するためのものです。

"filter"を記述して、planで参照する全てのリソースから、リソースのサブセットを探します。上記の例では、新規作成または更新する全ての"aws_s3_bucket"リソースのうち、ACLプロパティで明示的に"パブリックの読み書き権限"を指定するものを探します。

そして、上記のforループで、S3バケットポリシーに反する全てのアドレスを出力します。

最後の記述では、S3バケットポリシーに反するリソースの数が0であることをmainルールで検証し、許可するか否かを決定します。

この例は、単純ですが強力です。このブログに掲載する全てのコード及び例はこちらのリポジトリから参照できます。自由にご利用いただけるので、これを使ってS3バケットの安全性を高めてください。