アクセスキーを保護する - AWS Identity and Access Management
アクセスキーの監査

アクセスキーを保護する

アクセスキーを持っているユーザーなら誰でも、AWS リソースに対して同じレベルのアクセス権を持ちます。したがって、AWS でのアクセスキーの保護は非常に困難で、しかも責任共有モデルに沿って行う必要があります。

アクセスキーを保護するのに役立つガイダンスについては、以下のセクションを参照してください。

注記

組織によっては、セキュリティ要件とポリシーがこのトピックに記載されているものとは異なる可能性があります。ここで示すのは、一般的なガイドラインとしての提案です。

アカウントを保護する最善の方法の 1 つは、AWS アカウントのルートユーザー のアクセスキーを持たないことです。ルートユーザーのアクセスキーを持つ必要がある場合 (まれに) を除いて、キーを生成しないことをお勧めします。代わりに、日常の管理タスクのために AWS IAM Identity Center で管理ユーザーを作成してください。IAM Identity Center で管理ユーザーを作成する方法については、IAM Identity Center ユーザーガイドの「はじめに」を参照してください。

アカウントのルートユーザーアクセスキーが既にある場合は、そのキーを現在使用しているアプリケーション (ある場合) の場所を見つけ、ルートユーザーアクセスキーを IAM ユーザーアクセスキーに置き換えることをお勧めします。次いで、ルートユーザーアクセスキーを無効にして削除します。アクセスキーを更新する方法の詳細については、「アクセスキーを更新する」を参照してください。

多くの場合、期限のない長期のアクセスキー (IAM ユーザーのアクセスキーなど) は必要ありません。その代わり、IAM ロールを作成し、一時的なセキュリティ認証情報を生成できます。一時的なセキュリティ認証情報は、アクセスキー ID とシークレットアクセスキーで構成されていますが、認証情報がいつ無効になるかを示すセキュリティトークンも含んでいます。

IAM ユーザーやルートユーザーに関連付けられているものなどの長期的なアクセスキーは、それらを手動で取り消すまで有効です。ただし、IAM ロールや AWS Security Token Service の他の機能を使用して取得した一時的なセキュリティ認証情報は、短期間で期限が切れます。認証情報が誤って開示された場合のリスクに備えて、一時的なセキュリティ認証情報を使用することができます。

以下のシナリオでは、IAM ロールと一時的なセキュリティ認証情報を使用します。

  • Amazon EC2 インスタンスで実行されているアプリケーションまたは AWS CLI スクリプトがある場合。アプリケーション内で直接アクセスキーを使用しないでください。アクセスキーをアプリケーションに渡したり、アプリケーションに埋め込んだり、ソースからアクセスキーを読み取ったりしないでください。代わりに、アプリケーションに適したアクセス許可を持つ IAM ロールを定義し、EC2 のロールを使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動します。これにより、IAM ロールが Amazon EC2 インスタンスに関連付けられます。この方法により、アプリケーションは AWS へのプログラムされた呼び出しに使用することもできる、一時的なセキュリティ認証情報を取得します。AWS SDK および AWS Command Line Interface (AWS CLI)は、そのロールから一時的なセキュリティ認証情報を自動的に取得できます。

  • クロスアカウントアクセス許可を付与する必要がある場合。IAM ロールを使用してアカウント間の信頼を確立し、信頼できるアカウントへ制限されたアクセス許可を 1 つのアカウントのユーザーに付与します。詳細については、「IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」を参照してください。

  • モバイルアプリを持っている場合。暗号化ストレージ内であっても、アクセスキーをアプリに埋め込まないでください。代わりに、Amazon Cognito を使用して、アプリでユーザー ID を管理してください。このサービスでは、Login with Amazon、Facebook、Google、または OpenID Connect (OIDC) に対応している任意の ID プロバイダを使用してユーザーを認証できます。さらに、Amazon Cognito 認証情報プロバイダを使用して、AWS にリクエストを送信するためにアプリが使用する認証情報を管理できます。

  • AWS に連携しようとしており、組織が SAML 2.0 をサポートしている場合。SAML 2.0 をサポートする ID プロバイダーを持つ組織で作業する場合は、SAML を使用するようにプロバイダーを設定します。SAML を使用して、AWS と認証情報を交換し、一連の一時的なセキュリティ認証情報を取り戻すことができます。詳細については、「SAML 2.0 フェデレーション」を参照してください。

  • AWS に連携しようとしており、組織にオンプレミスのアイデンティティストアがある場合。ユーザーが組織内で認証できる場合、AWS リソースにアクセスするための一時的なセキュリティ認証情報を発行できるアプリケーションを記述することができます。詳細については、「AWS コンソールへのカスタム ID ブローカーアクセスを有効にする」を参照してください。

注記

AWS リソースへのプログラムによるアクセスを必要とするアプリケーションで Amazon EC2 インスタンスを使用していますか? その場合には、EC2 の IAM ロール を使用します。

プログラムによる AWS へのアクセスを設定したい場合、IAM ユーザー用にアクセスキーを作成して、必要なアクセス許可のみをユーザーに付与します。

IAM ユーザーアクセスキーを保護するために、以下の注意事項を守ってください。

  • アクセスキーを直接コードに埋め込まないでください。AWS SDK と AWS コマンドラインツール では、既知の場所にアクセスキーを置くことができるため、それらをコードで保持する必要がありません。

    次のいずれかの場所にアクセスキーを置きます。

    • AWS 認証情報ファイル。AWS SDK と AWS CLI では、AWS 認証情報ファイルに保存した認証情報が自動的に使用されます。

      AWS 認証情報ファイルの使用については、SDK のドキュメントを参照してください。例としては、AWS SDK for Javaデベロッパーガイドの「AWS 認証情報とリージョンを設定する」および AWS Command Line Interface ユーザーガイドの「設定と認証情報ファイル」などがあります。

      AWS SDK for .NET と AWS Tools for Windows PowerShell の認証情報を保存するには、SDK ストアの使用をお勧めします。詳細については、AWS SDK for .NET デベロッパーガイドの「SDK Store の使用」を参照してください。

    • 環境変数。マルチテナントシステムでは、システム環境変数ではなくユーザー環境変数を選択します。

      環境変数を使用した認証情報の保存の詳細については、AWS Command Line Interface ユーザーガイドの「環境変数」を参照してください。

  • 異なるアプリケーションには、異なるアクセスキーを使用します。こうすることで、アクセスキーが公開された場合に、アクセス許可を分離して、個々のアプリケーションに対するアクセスキーを無効化できます。アプリケーションごとに別々のアクセスキーを持つと、AWS CloudTrail ログファイルに個別のエントリが生成されます。この設定により、特定のアクションを実行したアプリケーションを簡単に判別できます。

  • 必要に応じてアクセスキーを更新してください。アクセスキーが危険にさらされる可能性がある場合は、アクセスキーを更新し、以前のアクセスキーを削除してください。詳細については、「アクセスキーを更新する」を参照してください。

  • 使用していないアクセスキーを削除します。ユーザーが退職したら、そのユーザーがリソースにアクセスできないようにするため、対応する IAM ユーザーを削除します。アクセスキーが最後に使用された日時を調べるには、GetAccessKeyLastUsed API (AWS CLI コマンド: aws iam get-access-key-last-used) を使用します。

  • 一時的な認証情報を使用し、最も機密性の高い API 操作ができるよう、多要素認証を設定します。IAM ポリシーを使用して、ユーザーが呼び出すことができる API オペレーションを指定できます。場合によっては、ユーザーが特に機密性の高いアクションを実行することを許可する前に、このユーザーに AWS MFA で認証することを求める追加のセキュリティが必要となることもあります。たとえば、ユーザーにAmazon EC2 RunInstances、DescribeInstances、および StopInstances アクションの実行を許可するポリシーがすでに存在する可能性があります。ただし TerminateInstances のような有害なアクションを制限し、AWS MFA デバイスによって認証される場合に限り、ユーザーがそのアクションを実行できるように管理することもできます。詳細については、「MFA を使用した安全な API アクセス」を参照してください。

AWS モバイルアプリを使用して、限定された AWS サービスと機能にアクセスできます。モバイルアプリは、外出先でもインシデント対応をサポートするのに役立ちます。詳細およびアプリのダウンロードについては、「AWS コンソールモバイルアプリケーション」を参照してください。

コンソールのパスワードまたはアクセスキーを使用して、モバイルアプリにサインインできます。ベストプラクティスとして、ルートユーザーアクセスキーは使用しないでください。その代わりに、モバイルデバイスでパスワードまたは生体認証ロックを使用することに加えて、モバイルアプリを使用して AWS リソースを管理するための IAM ユーザーを作成することを強くお勧めします。モバイルデバイスを紛失した場合は、その IAM ユーザーのアクセス権を削除します。

アクセスキーを使用してサインインするには (モバイルアプリ)

  1. モバイルデバイスでアプリを開きます。

  2. デバイスに ID を初めて追加する場合は、[Add an identity (ID を追加)]、[Access keys (アクセスキー)] の順に選択します。

    別の ID を使用して既にサインインしている場合は、メニューアイコンを選択し、[Switch identity (ID を切り替える)] を選択します。次に、[Sign in as a different identity (別の ID としてサインイン)]、[ Access keys (アクセスキー)] の順に選択します。

  3. [Access keys (アクセスキー)] ページで、情報を入力します。

    • Access key ID (アクセスキー ID) – アクセスキー ID を入力します。

    • Secret access key (シークレットアクセスキー) – シークレットアクセスキーを入力します。

    • Identity name (ID 名) – モバイルアプリに表示される ID の名前を入力します。これは、IAM ユーザー名と一致する必要はありません。

    • Identity PIN (ID PIN) – 今後のサインイン時に使用する個人識別番号 (PIN) を作成します。

      注記

      AWS モバイルアプリで生体認証を有効にすると、作成した PIN ではなく、指紋認証または顔認識を使用して検証するように求められます。生体認証に失敗した場合は、代わりに PIN の入力を求められることがあります。

  4. [Verify and add keys] (確認してキーを追加) を選択します。

    モバイルアプリを使用して、一部のリソースにアクセスできるようになりました。

以下のトピックでは、アクセスキーを使用するために AWS SDK および AWS CLI を設定するためのガイダンスを示しています。

アクセスキーの監査

コード内の AWS アクセスキーを確認して、キーが所有するアカウントのものであるかどうかを判断できます。アクセスキー ID は、aws sts get-access-key-info AWS CLI コマンドまたは GetAccessKeyInfo AWS API オペレーションを使用して渡すことができます。

AWS CLI および AWS API オペレーションは、AWS アカウント アクセスキーが属するアカウントの ID を返します。AKIA で始まるアクセスキー ID は、IAM ユーザーまたは AWS アカウントのルートユーザー の長期的な認証情報です。ASIA で始まるアクセスキー ID は、AWS STS オペレーションを使用して作成される一時的な認証情報です。レスポンスのアカウントがユーザーに属している場合、ルートユーザーとしてサインインしてルートユーザーのアクセスキーを確認できます。次に、認証情報レポートを取得して、キーを所有している IAM ユーザーを確認できます。ASIA アクセスキーの一時認証情報をリクエストしたユーザーを確認するには、CloudTrail ログで AWS STS イベントを表示します。

セキュリティ上の理由から、AWS CloudTrail ログを確認して、AWS でアクションを実行したユーザーを調べることができます。ロール信頼ポリシーで sts:SourceIdentity 条件キーを使用すると、ユーザーがロールを引き受けるときに ID を指定するように要求できます。例えば、IAM ユーザーがセッション名として自分のユーザー名を指定するように要求できます。これにより、AWS の特定のアクションを実行したユーザーを特定できます。詳細については、「sts:SourceIdentity」を参照してください。

このオペレーションは、アクセスキーの状態を示しません。キーは、アクティブ、非アクティブ、または削除済みのいずれかです。アクティブなキーにオペレーションを実行するアクセス許可がない場合があります。削除済みアクセスキーを指定すると、キーが存在しないというエラーが返されることがあります。