DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

AWS CLI を使用した認証情報のセキュアな管理に関するベストプラクティス

AWS CLI 認証情報を安全に保護するための決定的なベストプラクティスを学びましょう。このガイドでは、認証情報の読み込み順序、設定ファイルの適切な使用、環境変数について網羅しており、とりわけ重要な点として、長期間有効な静的アクセスキーの保存リスクを排除するために IAM ロールと AWS SSO を活用する方法を解説しています。これらの戦略を実装することで、AWS の自動化および管理ワークフローにおいて堅牢なセキュリティを実現できます。

AWS CLI で認証情報を安全に管理するためのベストプラクティス

AWS CLI の認証情報は、実際のクラウドリソースを作成、削除、公開する可能性があるため、アクセスキーの漏洩は小さなミスでは済みません。最も安全な設定では、人間には IAM Identity Center を通じて短期間の認証情報を提供し、ワークロードにはロールを通じて一時的な認証情報を提供します。

AWS CLI で認証情報を安全に管理するためのこれらのベストプラクティスでは、CLI が認証情報を検索する場所、プロファイルを使用するタイミング、スクリプト内で長期間有効な静的キーを避ける方法について説明します。

AWS CLI 認証情報の読み込み順序を理解する

AWS CLI はプロバイダーチェーンを通じて認証情報を解決します。正確なチェーンは CLI のバージョンや設定によって異なる場合がありますが、トラブルシューティングで最も頻繁に遭遇する実用的な順序は次のとおりです。

  1. 環境変数: AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、およびオプションで AWS_SESSION_TOKEN。
  2. Assume-role および Web ID 設定: 一時的な認証情報を取得するために AWS STS を呼び出すように CLI に指示するプロファイル。
  3. IAM Identity Center 認証情報: aws configure sso または aws configure sso-session によって作成されたプロファイル。
  4. 共有認証情報ファイル: 通常は ~/.aws/credentials。
  5. 共有設定ファイル: 通常は ~/.aws/config。credential_process エントリを含みます。
  6. コンテナ認証情報: ECS タスクロールおよび互換性のあるコンテナ認証情報エンドポイント。
  7. EC2 インスタンスプロファイル認証情報: インスタンスメタデータサービス (IMDS) からの一時的な認証情報。

AWS CLI は、通常のコマンドで --access-key-id や --secret-access-key のコマンドラインフラグを使用しません。スクリプトでこれらを見かけた場合、おそらく AWS CLI の動作を別のツールや SDK と混同しています。

1. 設定ファイルでの認証情報の保護 (~/.aws/credentials)

共有認証情報ファイル（通常は ~/.aws/credentials）は便利ですが、IAM Identity Center やロールを使用できない場合のフォールバックとして使用する必要があります。そこに静的キーを保存する必要がある場合は、ファイルを保護し、アクセス許可を厳しく制限してください。

ファイルの保護とアクセス許可

このファイルへの読み取りアクセスを制限することが重要です。Linux/macOS システムでは、所有者のみがファイルを読み取りまたは書き込みできるようにアクセス許可を設定します。

chmod 600 ~/.aws/credentials

分離のためのプロファイルの使用

個別のプロファイルを使用すると、異なる環境（例：開発、ステージング、本番）や異なるアカウントの認証情報を分離できます。これにより、環境をまたいだ誤った操作を防ぐことができます。

~/.aws/credentials の例:

[default]
aws_access_key_id = AKIAEXAMPLE000000000
aws_secret_access_key = exampleSecretAccessKeyDoNotUse

[production-user]
aws_access_key_id = AKIAEXAMPLE111111111
aws_secret_access_key = anotherExampleSecretDoNotUse

名前付きプロファイルを使用する場合は、--profile フラグで指定する必要があります。

aws s3 ls --profile production-user

2. 環境変数の活用

環境変数は、AWS 設定ファイルを編集することなく、現在のプロセスとその子プロセスに認証情報を提供します。これらは一時的なセッションや CI ジョブに役立ちますが、プロセス環境、デバッグログ、または不注意なシェル履歴を通じて漏洩する可能性があります。

シェルセッションで以下の変数を設定します。

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="temporary-session-token-if-using-sts"
export AWS_DEFAULT_REGION="us-east-1"

優先順位に関する重要な注意: 環境変数で設定された認証情報は、認証情報の読み込みチェーンで上位に表示されるため、~/.aws/credentials ファイルにあるものよりも常に優先されます。

セキュリティ警告: 特に共有ターミナルやログ記録される可能性のあるスクリプトでは、環境変数をエクスポートする際は注意してください。使用後はすぐに設定を解除してください。

unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

3. AWS ワークロードには IAM ロールを優先する

EC2、Lambda、ECS、EKS などの AWS インフラストラクチャで実行されるワークロードの場合は、静的認証情報を避けてください。IAM ロールを使用すると、AWS が自動的に一時的な認証情報を発行します。

EC2 では、インスタンスプロファイルが IMDS を通じて一時的な認証情報を公開します。ECS では、タスクロールがコンテナ認証情報エンドポイントを通じて認証情報を公開します。EKS では、サービスアカウント用の IAM ロールが Web ID トークンを使用します。AWS CLI と SDK は、長期間有効なキーをディスクに保存することなく、これらのプロバイダーを使用する方法を認識しています。

仕組み:

  1. EC2 インスタンスが、インスタンスプロファイルを通じて関連付けられた IAM ロールとともに起動されます。
  2. そのインスタンスで実行されている CLI は、インスタンスメタデータサービス (IMDS) に一時的な認証情報を照会します。
  3. CLI は、後続のすべての API 呼び出しにこれらの一時的な認証情報を使用します。

これにより、長期間有効なアクセスキーに関連するリスクが完全に排除されます。

4. 人間によるアクセスには IAM Identity Center を使用する

ラップトップから AWS CLI を使用するエンジニアにとって、IAM Identity Center は通常、IAM ユーザーのアクセスキーよりも安全です。ブラウザーを通じてサインインし、アカウントとロールを選択すると、CLI はキャッシュされた短期間の認証情報を使用します。

次のように設定します。

aws configure sso

次に、セッションの有効期限が切れたときにログインします。

aws sso login --profile <profile-name>

IAM Identity Center は以前は AWS SSO と呼ばれていたため、CLI コマンドや設定キーに sso が表示される場合があります。

5. 外部ブローカーには credential_process を使用する

CLI が外部ツール（ボールトエージェントやエンタープライズ認証情報ブローカーなど）を呼び出して、動的に認証情報を取得するように設定できます。これは ~/.aws/config で指定します。

~/.aws/config の例:

[profile my-vault-profile]
region = us-west-2
credential_process = /usr/local/bin/my-vault-cli get-aws-creds --profile my-vault-profile

この方法は、HashiCorp Vault などのシークレット管理ツールと統合する場合に重要です。

ベストプラクティスのまとめとチェックリスト

AWS CLI 操作のセキュリティを最大化するには、以下の基本原則に従ってください。

  • 最小権限の原則: すべての IAM ユーザーとロールが、そのジョブを実行するために厳密に必要な権限のみを持つようにします。
  • キーよりもロールを優先: AWS インフラストラクチャ内で操作する場合は、常に IAM ロール（インスタンスプロファイル）を使用します。
  • IAM Identity Center を使用: 人間による対話型使用には、IAM Identity Center を使用して複数のアカウントへのアクセスを管理します。
  • キーをハードコードしない: アクセスキーをスクリプト、ソースコード、またはコマンド履歴に直接配置しないでください。
  • 認証情報ファイルを保護: ~/.aws/credentials のファイルシステムのアクセス許可を制限します（chmod 600）。
  • キーを定期的にローテーション: 静的キーを使用する必要がある場合は、厳格なローテーションスケジュールを適用します。

デフォルトは一時的な認証情報にすべきです。人には IAM Identity Center、ワークロードには IAM ロール、仲介されたエンタープライズアクセスには credential_process を使用します。静的アクセスキーは、他に良い方法がない場合にのみ使用し、その場合は厳密にスコープを設定し、ローテーションし、依存関係がなくなったらすぐに削除します。