翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# セキュリティのベストプラクティス
Terraform AWS プロバイダーを安全に使用するには、認証、アクセスコントロール、セキュリティを適切に管理することが重要です。このセクションでは、以下に関するベストプラクティスの概要を説明します。
+ 最小特権アクセスの IAM ロールとアクセス許可
+ AWS アカウントとリソースへの不正アクセスを防ぐための認証情報の保護
+ 機密データの保護に役立つリモート状態の暗号化
+ インフラストラクチャとソースコードのスキャンによる設定ミスの特定
+ リモートステートストレージのアクセスコントロール
+ ガバナンスガードレールを実装するためのセンチネルポリシーの適用
これらのベストプラクティスに従うことで、Terraform を使用して AWS インフラストラクチャを管理する際のセキュリティ体制を強化できます。
## 最小特権の原則に従う
[最小特権](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)は、ユーザー、プロセス、またはシステムが意図した機能を実行するために必要な最小限のアクセス許可のみを付与することを指す基本的なセキュリティ原則です。これは、アクセスコントロールの中核的な概念であり、不正アクセスや潜在的なデータ侵害に対する予防手段です。
最小特権の原則は、Terraform が などのクラウドプロバイダーに対して認証およびアクションを実行する方法に直接関係するため、このセクションでは複数回強調されます AWS。
Terraform を使用して AWS リソースをプロビジョニングおよび管理する場合、API コールを行うための適切なアクセス許可を必要とするエンティティ (ユーザーまたはロール) に代わって動作します。最低限の特権に従うことで、重大なセキュリティリスクが生じます。
+ Terraform に必要なアクセス許可を超えると、意図しない設定ミスによって望ましくない変更や削除が行われる可能性があります。
+ アクセス許可が過度に許可されると、Terraform 状態ファイルまたは認証情報が侵害された場合の影響範囲が拡大します。
+ 最小限の権限に従うことは、最小限のアクセスを許可するためのセキュリティのベストプラクティスと規制コンプライアンス要件に反します。
## IAM ロールの使用
Terraform AWS プロバイダーでセキュリティを強化するために、可能な限り IAM ユーザーの代わりに IAM ロールを使用します。IAM ロールは、自動的にローテーションする一時的なセキュリティ認証情報を提供するため、長期的なアクセスキーを管理する必要がなくなります。ロールは、IAM ポリシーを通じて正確なアクセスコントロールも提供します。
### IAM ポリシーを使用して最小特権アクセスを付与する
IAM ポリシーを慎重に構築して、ロールとユーザーがワークロードに必要な最小限のアクセス許可のセットのみを持つようにします。空のポリシーから開始し、許可されたサービスとアクションを繰り返し追加します。これを行うには、以下の手順を使用します。
+ [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-console) を有効にしてポリシーを評価し、削除できる未使用のアクセス許可を強調表示します。
+ ポリシーを手動で確認して、ロールの目的の責任に不可欠ではない機能をすべて削除します。
+ [IAM ポリシー変数とタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)を使用して、アクセス許可の管理を簡素化します。
適切に構築されたポリシーは、ワークロードの責任を達成するために十分なアクセス権を付与します。オペレーションレベルでアクションを定義し、特定のリソースで必要な APIs への呼び出しのみを許可します。
このベストプラクティスに従うことで、影響範囲が軽減され、職務の分離と最小特権アクセスという基本的なセキュリティ原則が適用されます。必要に応じて、オープンを開始して後でアクセスを制限するのではなく、厳格かつオープンなアクセスを徐々に開始します。
### ローカル認証用の IAM ロールを引き受ける
Terraform をローカルで実行するときは、静的アクセスキーを設定しないでください。代わりに、[IAM ロールを使用して、長期的な認証情報を公開せずに特権アクセスを一時的に付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)します。
まず、必要な最小限のアクセス許可を持つ IAM ロールを作成し、ユーザーアカウントまたはフェデレーティッド ID が IAM ロールを引き受けることを許可する[信頼関係](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/)を追加します。これにより、ロールの一時的な使用が許可されます。
信頼関係ポリシーの例:
```
{
"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 プロバイダーは、[ロールの引き受け](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#assuming-an-iam-role)を自動的に処理することもできます。
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 ロールと[インスタンスプロファイル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)を使用して、最小特権のアクセス許可を自動的に付与します。
まず、最小限のアクセス許可を持つ IAM ロールを作成し、そのロールをインスタンスプロファイルに割り当てます。インスタンスプロファイルにより、EC2 インスタンスはロールで定義されたアクセス許可を継承できます。次に、そのインスタンスプロファイルを指定してインスタンスを起動します。インスタンスは、アタッチされたロールを通じて認証されます。
Terraform オペレーションを実行する前に、ロールが[インスタンスメタデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html)に存在することを確認し、認証情報が正常に継承されたことを確認します。
```
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 を実行する場合は、[動的認証情報](https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/aws-configuration)を使用して AWS 認証を簡素化し、保護します。Terraform は、IAM ロールを引き受けることなく、実行ごとに一時的な認証情報を自動的に交換します。
利点には、シークレットのローテーションの簡素化、ワークスペース間の認証情報の一元管理、最小特権のアクセス許可、ハードコードされたキーの排除などがあります。ハッシュされたエフェメラルキーに依存すると、存続期間の長いアクセスキーと比較してセキュリティが向上します。
### で IAM ロールを使用する AWS CodeBuild
で AWS CodeBuild、[CodeBuild プロジェクトに割り当てられた IAM ロール](https://docs.aws.amazon.com/codebuild/latest/userguide/auth-and-access-control-iam-identity-based-access-control.html)を使用してビルドを実行します。これにより、各ビルドは長期キーを使用する代わりに、ロールから一時的な認証情報を自動的に継承できます。
### HCP Terraform で GitHub Actions をリモートで実行する
HCP Terraform ワークスペースで Terraform をリモートで実行するように GitHub Actions ワークフローを設定します。GitHub シークレット管理の代わりに、動的認証情報とリモート状態ロックに依存します。
### OIDC で GitHub Actions を使用し、 AWS 認証情報アクションを設定する
[OpenID Connect (OIDC) 標準を使用して、IAM を介して GitHub Actions ID をフェデレーション](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)します。[AWS 認証情報の設定 アクション](https://github.com/aws-actions/configure-aws-credentials)を使用して、長期アクセスキーを必要とせずに GitHub トークンを一時的な AWS 認証情報と交換します。
### OIDC と で GitLab を使用する AWS CLI
[OIDC 標準を使用して、一時的なアクセスのために IAM を介して GitLab ID をフェデレーション](https://docs.gitlab.com/ee/ci/cloud_services/aws/)します。OIDC に依存することで、GitLab 内で長期的な AWS アクセスキーを直接管理する必要がなくなります。認証情報はjust-in-timeで交換されるため、セキュリティが向上します。ユーザーは、IAM ロールのアクセス許可に従って最小特権アクセスも取得します。
## レガシーオートメーションツールで一意の IAM ユーザーを使用する
IAM ロールの使用をネイティブにサポートしていない自動化ツールやスクリプトがある場合は、個々の IAM ユーザーを作成してプログラムによるアクセスを許可できます。最小特権の原則は引き続き適用されます。ポリシーのアクセス許可を最小限に抑え、パイプラインまたはスクリプトごとに個別のロールに依存します。より最新のツールやスクリプトに移行するときは、ロールをネイティブにサポートし始め、徐々にロールに移行します。
**警告**
IAM ユーザーには長期的な認証情報があり、セキュリティ上のリスクがあります。このリスクを軽減するために、これらのユーザーにはタスクの実行に必要な権限のみを付与し、不要になったユーザーは削除することをお勧めします。
### Jenkins AWS 認証情報プラグインを使用する
[AWS Jenkins の認証情報プラグイン](https://plugins.jenkins.io/aws-credentials/)を使用して、 AWS 認証情報を一元的に設定し、ビルドに動的に挿入できます。これにより、シークレットをソースコントロールにチェックする必要がなくなります。
## 最小特権を継続的にモニタリング、検証、最適化する
時間の経過とともに、必要な最小ポリシーを超える可能性のある追加のアクセス許可が付与される可能性があります。アクセスを継続的に分析して、不要な使用権限を特定して削除します。
### アクセスキーの使用状況を継続的にモニタリングする
アクセスキーの使用を回避できない場合は、[IAM 認証情報レポート](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_getting-report.html)を使用して、90 日以上経過した未使用のアクセスキーを検索し、ユーザーアカウントとマシンロールの両方で非アクティブなキーを取り消します。アクティブな従業員とシステムのキーの削除を手動で確認するように管理者に警告します。
キーの使用状況をモニタリングすると、未使用の使用権限を特定して削除できるため、アクセス許可を最適化できます。[アクセスキーローテーション](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)でこのベストプラクティスに従うと、認証情報の有効期間が制限され、最小特権アクセスが適用されます。
AWS には、管理者のアラートと通知をセットアップするために使用できるいくつかのサービスと機能が用意されています。いくつかのオプションは次のとおりです。
+ [AWS Config](https://aws.amazon.com/config/): AWS Config ルールを使用して、IAM アクセスキーを含む AWS リソースの設定を評価できます。カスタムルールを作成して、特定の日数より古い未使用のアクセスキーなど、特定の条件を確認できます。ルールに違反すると、 は修復の評価を開始したり、Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信 AWS Config したりできます。
+ [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/): Security Hub CSPM は、 AWS アカウントのセキュリティ体制を包括的に把握し、未使用または非アクティブな IAM アクセスキーなど、潜在的なセキュリティ問題を検出して通知するのに役立ちます。Security Hub CSPM は、チャットアプリケーションで Amazon EventBridge および Amazon SNS または Amazon Q Developer と統合して、管理者に通知を送信できます。
+ [AWS Lambda](https://aws.amazon.com/lambda/): Lambda 関数は、Amazon CloudWatch Events や AWS Config ルールなど、さまざまなイベントで呼び出すことができます。カスタム Lambda 関数を記述して、チャットアプリケーションで Amazon SNS や Amazon Q Developer などのサービスを使用して、IAM アクセスキーの使用状況を評価し、追加のチェックを実行し、通知を送信できます。
### IAM ポリシーを継続的に検証する
[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html#access-analyzer-policy-generation-console) を使用して、ロールにアタッチされているポリシーを評価し、付与された未使用のサービスや余分なアクションを特定します。定期的なアクセスレビューを実装して、ポリシーが現在の要件を満たしていることを手動で確認します。
既存のポリシーを IAM Access Analyzer によって生成されたポリシーと比較し、不要なアクセス許可を削除します。また、ユーザーにレポートを提供し、猶予期間後に未使用のアクセス許可を自動的に取り消す必要があります。これにより、最小限のポリシーが引き続き有効になります。
古いアクセスをプロアクティブかつ頻繁に取り消すと、侵害中にリスクにさらされる可能性のある認証情報が最小限に抑えられます。自動化は、持続可能で長期的な認証情報の衛生とアクセス許可の最適化を提供します。このベストプラクティスに従うことで、 AWS アイデンティティとリソースに最小特権を積極的に適用することで、影響の範囲を制限できます。
## 安全なリモート状態ストレージ
[リモート状態ストレージ](https://developer.hashicorp.com/terraform/language/state/remote)とは、Terraform が実行されているマシンにローカルではなく、Terraform 状態ファイルをリモートに保存することです。状態ファイルは、Terraform によってプロビジョニングされたリソースとそのメタデータを追跡するため、重要です。
リモート状態を保護しないと、状態データの損失、インフラストラクチャの管理不能、不注意によるリソースの削除、状態ファイルに存在する可能性のある機密情報の漏洩などの重大な問題が発生する可能性があります。このため、本番稼働用グレードの Terraform の使用には、リモートステートストレージの保護が不可欠です。
### 暗号化とアクセスコントロールを有効にする
Amazon Simple Storage Service (Amazon S3) [サーバー側の暗号化 (SSE)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) を使用して、保管中のリモート状態を暗号化します。
### コラボレーションワークフローへの直接アクセスを制限する
+ HCP Terraform または Git リポジトリ内の CI/CD パイプラインでコラボレーションワークフローを構築し、直接的な状態アクセスを制限します。
+ プルリクエスト、実行承認、ポリシーチェック、通知に依存して変更を調整します。
これらのガイドラインに従うことで、機密性の高いリソース属性を保護し、チームメンバーの変更との競合を回避できます。暗号化と厳格なアクセス保護は攻撃対象領域の削減に役立ち、コラボレーションワークフローにより生産性が向上します。
## を使用する AWS Secrets Manager
Terraform には、状態ファイルにシークレット値をプレーンテキストで保存するリソースとデータソースが多数あります。シークレットを 状態に保存することは避けてください。[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)代わりに を使用してください。
[機密値を手動で暗号化](https://developer.hashicorp.com/terraform/plugin/best-practices/sensitive-state)するのではなく、Terraform の機密状態管理の組み込みサポートを利用してください。機密値を出力にエクスポートする場合は、その値が[機密](https://www.terraform.io/docs/configuration/outputs.html#sensitive-suppressing-values-in-cli-output)としてマークされていることを確認してください。
## インフラストラクチャとソースコードを継続的にスキャンする
インフラストラクチャとソースコードの両方をプロアクティブにスキャンして、公開された認証情報や設定ミスなどのリスクがないか確認し、セキュリティ体制を強化します。リソースを再設定またはパッチ適用して、検出結果に迅速に対処します。
### 動的スキャンに AWS サービスを使用する
[Amazon Inspector](https://aws.amazon.com/inspector/)、、[Amazon Detective](https://aws.amazon.com/detective/)[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)、[Amazon GuardDuty](https://aws.amazon.com/guardduty/) などの AWS ネイティブツールを使用して、アカウントとリージョン全体でプロビジョニングされたインフラストラクチャをモニタリングします。Security Hub CSPM で定期的なスキャンをスケジュールして、デプロイと設定のドリフトを追跡します。EC2 インスタンス、Lambda 関数、コンテナ、S3 バケット、およびその他のリソースをスキャンします。
### 静的分析を実行する
[Checkov](https://www.checkov.io/) などの静的アナライザーを CI/CD パイプラインに直接埋め込み、Terraform 設定コード (HCL) をスキャンして、デプロイ前にリスクを事前に特定します。これにより、セキュリティチェックが開発プロセスの以前の時点 (*左へのシフト*と呼ばれます) に移動され、インフラストラクチャの設定ミスが防止されます。
### プロンプトの修正を確認する
すべてのスキャン結果について、Terraform 設定の更新、パッチの適用、または必要に応じてリソースを手動で再設定することで、迅速な修復を確保します。根本原因に対処することで、リスクレベルを下げます。
インフラストラクチャスキャンとコードスキャンの両方を使用すると、Terraform 設定、プロビジョニングされたリソース、およびアプリケーションコード間のレイヤードインサイトが得られます。これにより、ソフトウェア開発ライフサイクル (SDLC) の早い段階でセキュリティを埋め込むと同時に、予防的、検出的、事後対応的なコントロールを通じてリスクとコンプライアンスのカバレッジを最大化できます。
## ポリシーチェックを強制する
[HashiCorp Sentinel ポリシー](https://developer.hashicorp.com/terraform/tutorials/policy)などのコードフレームワークを使用して、Terraform によるインフラストラクチャプロビジョニングのためのガバナンスガードレールと標準化されたテンプレートを提供します。
Sentinel ポリシーでは、組織の標準とベストプラクティスに合わせて Terraform 設定の要件または制限を定義できます。たとえば、Sentinel ポリシーを使用して次のことができます。
+ すべてのリソースにタグが必要です。
+ インスタンスタイプを承認済みリストに制限します。
+ 必須変数を適用します。
+ 本番稼働用リソースの破壊を防止します。
ポリシーチェックを Terraform 設定ライフサイクルに埋め込むと、標準とアーキテクチャガイドラインを積極的に適用できます。Sentinel は、未承認のプラクティスを防止しながら開発を加速するのに役立つ共有ポリシーロジックを提供します。