翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

セキュリティに関するベストプラクティス

Terraform AWS プロバイダーを安全に使用するには、認証、アクセスコントロール、セキュリティを適切に管理することが重要です。このセクションでは、以下に関するベストプラクティスの概要を説明します。

これらのベストプラクティスに従うことで、Terraform を使用して AWS インフラストラクチャを管理する際のセキュリティ体制を強化できます。

最小特権の原則に従う

最小権限は、ユーザー、プロセス、またはシステムが意図した機能を実行するために必要な最小限のアクセス許可のみを付与することを指す基本的なセキュリティ原則です。これは、アクセスコントロールの中核的な概念であり、不正アクセスや潜在的なデータ侵害に対する予防策です。

最小特権の原則は、Terraform がクラウドプロバイダーに対して認証してアクションを実行する方法に直接関係するため、このセクションでは複数回強調されます AWS。

Terraform を使用して AWS リソースをプロビジョニングおよび管理する場合、API コールを行うための適切なアクセス許可を必要とするエンティティ (ユーザーまたはロール) に代わって動作します。最小特権に従わないと、重大なセキュリティリスクが生じます。

IAM ロールの使用

Terraform AWS プロバイダーでセキュリティを強化するために、可能な限り IAM ユーザーの代わりに IAM ロールを使用します。IAM ロールは、自動的にローテーションする一時的なセキュリティ認証情報を提供するため、長期的なアクセスキーを管理する必要がなくなります。ロールは、IAM ポリシーを通じて正確なアクセスコントロールも提供します。

IAM ポリシーを使用して最小特権アクセスを付与する

IAM ポリシーを慎重に構築して、ロールとユーザーがワークロードに必要な最小限のアクセス許可のセットのみを持つようにします。空のポリシーから開始し、許可されたサービスとアクションを繰り返し追加します。これを行うには、以下の手順を使用します。

適切に構築されたポリシーは、ワークロードの責任を達成するために十分なアクセス権を付与し、それ以上のアクセスは許可しません。オペレーションレベルでアクションを定義し、特定のリソースで必要な APIs への呼び出しのみを許可します。

このベストプラクティスに従うことで、影響範囲が軽減され、職務の分離と最小特権アクセスという基本的なセキュリティ原則が適用されます。必要に応じて、オープンを開始して後でアクセスを制限するのではなく、厳格かつオープンなアクセスを徐々に開始します。

ローカル認証用の IAM ロールを引き受ける

Terraform をローカルで実行するときは、静的アクセスキーを設定しないでください。代わりに、IAM ロールを使用して、長期的な認証情報を公開することなく、特権アクセスを一時的に付与します。

まず、必要な最小限のアクセス許可を持つ IAM ロールを作成し、ユーザーアカウントまたはフェデレーション ID が IAM ロールを引き受けることを許可する信頼関係を追加します。これにより、ロールの一時的な使用が許可されます。

信頼関係ポリシーの例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/terraform-execution"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

次に、aws sts assume-role AWS CLI コマンドを実行して、ロールの存続期間の短い認証情報を取得します。これらの認証情報は通常 1 時間有効です。

AWS CLI コマンドの例：

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/terraform-execution --role-session-name terraform-session-example

コマンドの出力には、次の認証に使用できるアクセスキー、シークレットキー、およびセッショントークンが含まれています AWS。

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:terraform-session-example",
        "Arn": "arn:aws:sts::111122223333:assumed-role/terraform-execution/terraform-session-example"
    },
    "Credentials": {
        "SecretAccessKey": " wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": " AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2024-03-15T00:05:07Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

AWS プロバイダーは、ロールの引き受けを自動的に処理することもできます。

IAM ロールを引き受けるプロバイダー設定の例：

provider "aws" {
  assume_role {
    role_arn     = "arn:aws:iam::111122223333:role/terraform-execution"
    session_name = "terraform-session-example"
  }
}

これにより、Terraform セッションの期間に対してのみ昇格された権限が付与されます。一時キーは、セッションの最大期間後に自動的に期限切れになるため、リークできません。

このベストプラクティスの主な利点には、存続期間の長いアクセスキーと比較したセキュリティの向上、最小特権のロールに対するきめ細かなアクセスコントロール、ロールのアクセス許可を変更してアクセスを簡単に取り消す機能などがあります。IAM ロールを使用すると、シークレットをスクリプトまたはディスクに直接保存する必要もなくなるため、チーム間で Terraform 設定を安全に共有できます。

Amazon EC2 認証に IAM ロールを使用する

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスから Terraform を実行する場合は、長期的な認証情報をローカルに保存しないでください。代わりに、IAM ロールとインスタンスプロファイルを使用して、最小特権のアクセス許可を自動的に付与します。

まず、最小限のアクセス許可を持つ IAM ロールを作成し、そのロールをインスタンスプロファイルに割り当てます。インスタンスプロファイルにより、EC2 インスタンスはロールで定義されたアクセス許可を継承できます。次に、そのインスタンスプロファイルを指定してインスタンスを起動します。インスタンスは、アタッチされたロールを通じて認証されます。

Terraform オペレーションを実行する前に、ロールがインスタンスメタデータに存在することを確認し、認証情報が正常に継承されたことを確認します。

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

このアプローチにより、永続的な AWS キーをスクリプトやインスタンス内の Terraform 設定にハードコーディングする必要がなくなります。一時的な認証情報は、インスタンスのロールとプロファイルを通じて Terraform が透過的に利用できるようになります。

このベストプラクティスの主な利点には、長期的な認証情報に対するセキュリティの向上、認証情報管理のオーバーヘッドの削減、開発、テスト、本番環境間の一貫性などがあります。IAM ロール認証は、最小特権アクセスを適用しながら、EC2 インスタンスからの Terraform 実行を簡素化します。

HCP Terraform ワークスペースに動的認証情報を使用する

HCP Terraform は HashiCorp が提供するマネージドサービスで、チームが Terraform を使用して複数のプロジェクトや環境にわたってインフラストラクチャをプロビジョニングおよび管理できるようにします。HCP Terraform で Terraform を実行するときは、動的認証情報を使用して AWS 認証を簡素化し、保護します。Terraform は、IAM ロールを引き受けることなく、実行ごとに一時的な認証情報を自動的に交換します。

利点には、シークレットのローテーションの簡素化、ワークスペース間の認証情報の一元管理、最小特権のアクセス許可、ハードコードされたキーの排除などがあります。ハッシュされたエフェメラルキーに依存すると、存続期間の長いアクセスキーと比較してセキュリティが向上します。

で IAM ロールを使用する AWS CodeBuild

で AWS CodeBuild、CodeBuild プロジェクトに割り当てられた IAM ロールを使用してビルドを実行します。これにより、各ビルドは、長期キーを使用する代わりに、ロールから一時的な認証情報を自動的に継承できます。

HCP Terraform で GitHub アクションをリモートで実行する

HCP Terraform ワークスペースで Terraform をリモートで実行するように GitHub Actions ワークフローを設定します。GitHub シークレット管理の代わりに、動的認証情報とリモートステートロックに依存します。

OIDC で GitHub Actions を使用し、 AWS 認証情報アクションを設定する

OpenID Connect (OIDC) 標準を使用して、IAM を介して GitHub Actions ID をフェデレーションします。AWS 認証情報の設定アクションを使用して、長期アクセスキーを必要とせずに GitHub トークンを一時的な AWS 認証情報と交換します。

OIDC と で GitLab を使用する AWS CLI

OIDC 標準を使用して、一時的なアクセスのために IAM を介して GitLab ID をフェデレーションします。OIDC に依存することで、GitLab 内で長期的な AWS アクセスキーを直接管理する必要がなくなります。認証情報はjust-in-timeで交換されるため、セキュリティが向上します。ユーザーは、IAM ロールのアクセス許可に従って最小特権アクセスも取得します。

レガシーオートメーションツールで一意の IAM ユーザーを使用する

IAM ロールの使用をネイティブにサポートしていないオートメーションツールやスクリプトがある場合は、個々の IAM ユーザーを作成してプログラムによるアクセスを許可できます。最小特権の原則は引き続き適用されます。ポリシーのアクセス許可を最小限に抑え、パイプラインまたはスクリプトごとに個別のロールに依存します。より最新のツールやスクリプトに移行するときは、ロールをネイティブにサポートし、徐々にロールに移行します。

Jenkins AWS 認証情報プラグインを使用する

Jenkins AWS の認証情報プラグインを使用して、 AWS 認証情報を一元的に設定し、ビルドに動的に挿入します。これにより、シークレットをソースコントロールにチェックする必要がなくなります。

最小特権を継続的にモニタリング、検証、最適化する

時間の経過とともに、必要な最小ポリシーを超える追加のアクセス許可が付与される可能性があります。アクセスを継続的に分析して、不要な使用権限を特定して削除します。

アクセスキーの使用状況を継続的にモニタリングする

アクセスキーの使用を回避できない場合は、IAM 認証情報レポートを使用して、90 日以上経過した未使用のアクセスキーを検索し、ユーザーアカウントとマシンロールの両方で非アクティブなキーを取り消します。アクティブな従業員とシステムのキーの削除を手動で確認するように管理者に警告します。

キーの使用状況をモニタリングすると、未使用の使用権限を特定して削除できるため、アクセス許可を最適化できます。アクセスキーローテーションでこのベストプラクティスに従うと、認証情報の有効期間が制限され、最小特権アクセスが適用されます。

AWS には、管理者のアラートと通知をセットアップするために使用できるいくつかのサービスと機能が用意されています。いくつかのオプションは次のとおりです。

IAM ポリシーを継続的に検証する

IAM Access Analyzer を使用して、ロールにアタッチされているポリシーを評価し、未使用のサービスや付与された余分なアクションを特定します。定期的なアクセスレビューを実装して、ポリシーが現在の要件を満たしていることを手動で確認します。

既存のポリシーを IAM Access Analyzer によって生成されたポリシーと比較し、不要なアクセス許可を削除します。また、ユーザーにレポートを提供し、猶予期間後に未使用のアクセス許可を自動的に取り消す必要があります。これにより、最小限のポリシーが有効になります。

古いアクセスをプロアクティブかつ頻繁に取り消すと、侵害中にリスクにさらされる可能性のある認証情報が最小限に抑えられます。自動化は、持続可能で長期的な認証情報の衛生とアクセス許可の最適化を提供します。このベストプラクティスに従うことで、 AWS アイデンティティとリソースに最小特権を積極的に適用することで、影響の範囲を制限できます。

安全なリモート状態ストレージ

リモート状態ストレージとは、Terraform が実行されているマシンにローカルではなく、Terraform 状態ファイルをリモートに保存することです。状態ファイルは、Terraform によってプロビジョニングされたリソースとそのメタデータを追跡するため、重要です。

リモート状態を保護しないと、状態データの損失、インフラストラクチャの管理不能、不注意によるリソースの削除、状態ファイルに存在する可能性のある機密情報の漏洩などの重大な問題が発生する可能性があります。このため、本番稼働用グレードの Terraform の使用には、リモートステートストレージの保護が不可欠です。

暗号化とアクセスコントロールを有効にする

Amazon Simple Storage Service (Amazon S3) サーバー側の暗号化 (SSE) を使用して、保管中のリモート状態を暗号化します。

コラボレーションワークフローへの直接アクセスを制限する

これらのガイドラインに従うことで、機密性の高いリソース属性を保護し、チームメンバーの変更との競合を回避できます。暗号化と厳格なアクセス保護は攻撃対象領域の削減に役立ち、コラボレーションワークフローにより生産性が向上します。

を使用する AWS Secrets Manager

Terraform には、状態ファイルにシークレット値をプレーンテキストで保存するリソースとデータソースが多数あります。シークレットを 状態で保存することは避けてください。AWS Secrets Manager代わりに を使用してください。

機密値を手動で暗号化する代わりに、Terraform の機密状態管理の組み込みサポートを利用してください。機密値を出力にエクスポートする場合は、その値が機密としてマークされていることを確認してください。

インフラストラクチャとソースコードを継続的にスキャンする

インフラストラクチャとソースコードの両方を継続的にプロアクティブにスキャンして、公開された認証情報や設定ミスなどのリスクがないか確認し、セキュリティ体制を強化します。リソースを再設定またはパッチ適用して、検出結果に迅速に対処します。

動的スキャンに AWS サービスを使用する

Amazon Inspector、、Amazon DetectiveAWS Security Hub、Amazon GuardDuty などの AWS ネイティブツールを使用して、アカウントとリージョン全体でプロビジョニングされたインフラストラクチャをモニタリングします。Security Hub で定期的なスキャンをスケジュールして、デプロイと設定のドリフトを追跡します。EC2 インスタンス、Lambda 関数、コンテナ、S3 バケット、およびその他のリソースをスキャンします。

静的分析を実行する

Checkov などの静的アナライザーを CI/CD パイプラインに直接埋め込み、Terraform 設定コード (HCL) をスキャンして、デプロイ前にリスクを事前に特定します。これにより、セキュリティチェックが開発プロセスの以前のポイント (左シフトと呼ばれます) に移動され、インフラストラクチャの設定ミスが防止されます。

プロンプトの修正を確認する

すべてのスキャン検出結果について、Terraform 設定の更新、パッチの適用、または必要に応じてリソースを手動で再設定することで、迅速な修復を確保します。根本原因に対処することで、リスクを軽減します。

インフラストラクチャスキャンとコードスキャンの両方を使用すると、Terraform 設定、プロビジョニングされたリソース、およびアプリケーションコード間のレイヤードインサイトが得られます。これにより、ソフトウェア開発ライフサイクル (SDLC) にセキュリティを早期に埋め込むと同時に、予防的、検出的、事後対応的なコントロールを通じてリスクとコンプライアンスのカバレッジを最大化できます。

ポリシーチェックを強制する

HashiCorp Sentinel ポリシーなどのコードフレームワークを使用して、Terraform によるインフラストラクチャプロビジョニングのためのガバナンスガードレールと標準化されたテンプレートを提供します。

センチネルポリシーは、組織の標準とベストプラクティスに合わせて Terraform 設定の要件または制限を定義できます。たとえば、Sentinel ポリシーを使用して次のことができます。

ポリシーチェックを Terraform 設定ライフサイクルに埋め込むと、標準とアーキテクチャガイドラインを積極的に適用できます。Sentinel は、未承認のプラクティスを防止しながら開発を加速するのに役立つ共有ポリシーロジックを提供します。