DevOpsナレッジハブ
DevOpsナレッジハブ

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

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

44 ビュー

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

Amazon Web Services (AWS) とコマンドラインインターフェース (CLI) を介してやり取りする際、認証情報を安全に管理することは最も重要です。アクセスキー (アクセスキーIDとシークレットアクセスキー) は、クラウドのリソースへのプログラムによるアクセスを許可するため、これらの漏洩は重大なセキュリティリスクとなります。この記事では、CLIを介してタスクを自動化したりリソースを管理したりする際に、認証情報の露出を最小限に抑え、堅牢なセキュリティ体制を維持するための、これらの認証情報の保存、管理、および利用に関する重要なベストプラクティスを概説します。

AWS CLIは、認証情報を特定するために特定の方法に依存しています。設定ファイルから環境変数、IAMロールまで、これらの方法を理解することが、環境を保護するための第一歩です。推奨される優先順位を探り、シークレットのハードコーディングに代わる、より現代的で安全な方法に焦点を当てます。

AWS CLIの認証情報ロード順序を理解する

AWS CLIは、定義された階層を使用して認証情報を解決します。この順序を知ることで、CLIがどこから認証情報を最初に探すのかを理解し、意図した最も安全な設定が優先されるようにすることができます。

CLIは以下の順序 (優先度の高いものから低いものへ) で認証情報を確認します。

  1. コマンドラインオプション: フラグ (--access-key-id および --secret-access-key) を介して直接渡される認証情報。
  2. 環境変数: 現在のシェルセッションで設定されている認証情報。
  3. 認証情報プロセス: 設定された認証情報プロセス (SSOまたは外部ツールでよく使用される) の出力。
  4. AWS認証情報プロバイダーチェーン: このチェーンは以下の順序で確認します。
    a. 実行中のEC2インスタンスまたはECSタスクに割り当てられたIAMロールからの認証情報。
    b. 共有認証情報ファイル (~/.aws/credentials) に保存されている認証情報。
  5. 設定ファイル: 認証情報が見つからない場合、CLIは検索を停止します。

セキュリティのヒント: コマンドラインフラグに依存することは、コマンド履歴 (.bash_history) が機密情報を公開する可能性があるため、通常の利用では一般的に推奨されません。

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

デフォルトでは、AWS CLIは認証情報を共有認証情報ファイル (通常 ~/.aws/credentials に配置) に保存します。これは便利ですが、このファイルは保護される必要があります。

ファイルの保護と権限

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

chmod 600 ~/.aws/credentials

プロファイルを使用した分離

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

~/.aws/credentials の例:

[default]
aws_access_key_id = AKIABCDEFGHIJKLMNO
aws_secret_access_key = xYzdEfGhIjKlMnOpQrStUvWxYz1234567890

[production-user]
aws_access_key_id = AKIA9876543210ZYXWVU
aws_secret_access_key = aBcDeFgHiJkLmNoPqRsTuVwXyZ9876543210

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

aws s3 ls --profile production-user

2. 環境変数の活用

環境変数は、CLIセッションに認証情報をディスクに書き込むことなく動的に提供する方法です。これは、一時的なアクセスや、ディスクへの書き込みが制限されている、または望ましくないスクリプト環境でよく好まれます。

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

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_DEFAULT_REGION="us-east-1"

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

セキュリティ警告: 特に共有端末やログに記録される可能性のあるスクリプトで環境変数をエクスポートする際は注意してください。使用後は直ちにそれらを解除してください。
bash unset AWS_ACCESS_KEY_ID unset AWS_SECRET_ACCESS_KEY

3. 最も安全な方法: IAMロール (インスタンスプロファイル/ウェブアイデンティティ)

AWSインフラストラクチャ (EC2インスタンス、Lambda関数、ECSタスクなど) で実行されるワークロードの場合、最も安全な方法は静的認証情報を使用しないことです。代わりにIAMロールを使用してください。

IAMロールを使用すると、インスタンスメタデータサービスを介して、一時的で自動的にローテーションされるセキュリティ認証情報をリソースに割り当てることができます。AWS CLIは、これらの認証情報がディスクや環境変数に保存されることなく、自動的に検出し使用します。

仕組み:

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

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

4. 認証情報プロセスとSSOの活用

現代の認証情報管理は、外部認証プロバイダーにますます依存しており、多くの場合 credential_process 設定を介して統合されています。

AWS SSO (シングルサインオン)

AWS SSOは、既存のIDプロバイダー (IdP) を使用して、複数のアカウントとロールにわたるアクセスを管理するための統一された方法を提供します。AWS CLIはSSOとシームレスに統合され、一時的なセッショントークンの管理を抽象化します。

SSOの使用を開始するには、まずログインコマンドを実行します。

aws sso login --profile <profile-name>

これにより、認証用のブラウザウィンドウが開きます。認証が成功すると、CLIは必要なセッショントークンを保存し、多くの場合 credential_process メカニズムを内部的に利用してトークンを自動的に更新するため、生のシークレットキーを自分で扱う必要はありません。

credential_process の設定

CLIが外部ツール (ボールトエージェントやSSOヘルパーなど) を呼び出して認証情報を動的にフェッチするように設定できます。これは設定ファイルで指定します。

~/.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ロール (インスタンスプロファイル) を使用します。
  • SSOを使用する: 人間が対話的に使用する場合、AWS SSOを活用して複数のアカウントへのアクセスを管理します。
  • キーをハードコードしない: アクセスキーをスクリプト、ソースコード、またはコマンド履歴に直接配置することは避けてください。
  • 認証情報ファイルを保護する: ~/.aws/credentials のファイルシステム権限を制限します (chmod 600)。
  • キーを定期的にローテーションする: 静的キーを使用する必要がある場合、厳格なローテーションスケジュールを強制します。

ディスクに保存された静的アクセスキーよりも、IAMロールやSSOのような動的な認証情報取得方法を優先することで、AWS CLIの使用に関連する攻撃対象領域を大幅に削減できます。