メンバーアカウントのベストプラクティス - AWS Organizations

メンバーアカウントのベストプラクティス

組織内のメンバーアカウントのセキュリティを保護するために、以下の推奨事項に従います。これらの推奨事項は、厳密に必要とするタスクにのみルートユーザーを使用するというベストプラクティスを遵守していることを前提としています。

すべてのメンバーアカウントのルートユーザーにグループメールアドレスを使用する

  • 会社が管理するメールアドレスを使用します。パブリックメールプロバイダや、サードパーティーによって管理されるメールアドレスは使用しないでください。

  • 受信したメッセージを上級管理者のリストに直接転送するメールアドレスを使用します。アクセス権の確認など、AWS からアカウントの所有者に連絡する必要が生じる事象では、メールは複数の当事者に送信されます。こうすることで、誰かが休暇中や病欠であるか、あるいはすでに退職している場合でも、応答の遅延のリスクを軽減できます。

メンバーアカウントのルートユーザーに複雑なパスワードを使用する

  • アカウントのルートユーザーのセキュリティは、パスワードの強度に依存します。長く、複雑で、他で使用していないパスワードを使用することをお勧めします。多数のパスワードマネージャー、複雑なパスワード生成のアルゴリズムとツールが、この目標を達成するのに役立ちます。

  • 先述のように強力なパスワードを使用し、ルートユーザーにアクセスすることがめったにないのであれば、パスワードは定期的に変更しないことをお勧めします。パスワードの実際の使用より変更の頻度が高いと、侵害のリスクが高くなります。

  • 長期保存と、メンバーアカウントのルートユーザーのパスワードに対するアクセスを管理するには、会社の情報セキュリティポリシーを使用してください。ただし、管理アカウントとは異なり、会社が承認した信頼できるパスワードマネージャーシステムまたはツールをパスワードの保存に利用することを検討できます。

    パスワードマネージャーシステムまたはツールにパスワードを保存する場合は、さらなる制御とプロセスが必要になります。パスワードマネージャーはオフラインで使用することをお勧めします。循環依存が生じるのを避けるには、保護されたアカウントでサインインする AWS のサービスに依存するツールでパスワードを保存しないようにします。

    どのような方法をとるにしても、その方法に弾力性を確保することと、共謀のリスクを低減するため、必ず複数のユーザーが操作に関与するよう設計することをお勧めします。

  • または、管理アカウントのルートユーザーに提供されているガイダンスに基づき、メンバーアカウントのルートユーザーのパスワードを安全な場所に保存します。

  • 作成したメンバーアカウントで、ルートユーザー用の認証情報を有効にしないようにしてください。デフォルトでは、Organizations はランダムで複雑な、非常に長いパスワードを割り当てます。このパスワードをユーザーが取得することはできません。代わりに、ルートユーザーにアクセスするには、パスワードの再設定の手順を行う必要があります。アカウントのルートユーザーでしか実行できないタスクを実行する必要がない限り、この操作は行わないことをお勧めします。詳細については、ルートユーザーとしてのメンバーアカウントへのアクセス を参照してください。

  • それでもルートユーザーのパスワードを手動で処理する場合は、サービスコントロールポリシー (SCP) を適用し、メンバーアカウントのルートユーザーによって AWS API コールが実行されないようにします。しかし、メンバーアカウントに生じた重大なセキュリティイベントに対処する必要が生じたら、そのアカウントのルートユーザーにすばやくアクセスしなければならないかもしれません。そのため、メンバーアカウントのルートユーザーに複雑なパスワードを使用することと、アクセスと使用のための手続きを事前に作成しておくことは、前のセクションでも言及しましたが、ここでも推奨される手法です。

MFA を有効にしてルートユーザーの認証情報に使用する

多要素認証 (MFA) を有効にする方法については、AWS での多要素認証 (MFA) の使用を参照してください。

  • バッテリーに依存しないハードウェアベースのデバイスを使用し、ワンタイムパスワード (OTP) を生成することをお勧めします。こうすることで、MFA が複製不可能になり、長期保存中にバッテリーの消耗に伴うリスクの影響を受けずに済みます。

    • バッテリーベースの MFA を使用する場合は、デバイスを定期的にチェックするプロセスを追加し、使用期限が近づいたらバッテリーを交換するようにします。

    • 有事に備えて、トークンへの 24 時間 365 日アクセスの維持に必要となる、デバイスの手配のプランを作成してください。

  • 仮想 MFA アプリケーションを使用する場合は、管理アカウントのルートユーザーに関する推奨事項とは異なり、複数のメンバーアカウントに対して 1 つの MFA デバイスを繰り返し使用できます。仮想 MFA アプリケーションでアカウントを設定するために使用する QR コードを作成して安全に保存することで、地理的な制限に対処できます。情報セキュリティポリシーに従い、QR コードの目的を文書化し、オペレーションが行われるどのタイムゾーンからでもアクセス可能な安全な場所に、厳重に保管してください。その後、別の地理的場所でアクセスが必要になったら、QR コードのローカルコピーを取得し、その場所での仮想 MFA アプリケーションの設定に使用できます。

  • 情報セキュリティポリシーに従って MFA デバイスを保存します。保存場所は、ルートユーザーの関連付けられたパスワードと同じであってはなりません。パスワードにアクセスするプロセスと、MFA デバイスにアクセスするプロセスでは、それぞれ必要なアクセス手順がリソース (人、データ、ツール) によって異なるようにしてください。

  • MFA デバイスとその保存場所のアクセスはすべてログに記録し、モニタリングする必要があります。

  • MFA デバイスを紛失または破損した場合は、アカウントから MFA を削除するため、カスタマーサポートへの連絡が必要になることがあります。削除を実行するにあたり、カスタマーサポートは、アカウントに関連付けられたメールアドレス、電話番号、秘密の質問をその申請者が所有していることを確認する必要があります。そのため、そうした情報を自身で確認して、変更があればその都度更新し、安全に保管してください。

管理アカウントの電話番号をメンバーアカウントの連絡先情報に追加する

  • 通常は、重大なアカウント復旧には常に組織の管理アカウントの電話番号が使用されます。したがって、各メンバーアカウントの連絡先情報に登録されたばらばらの電話番号を 1 つずつ管理することは、運用上の不要なオーバーヘッドであると言えます。その代わりに、管理アカウントと同じ電話番号を追加することをお勧めします。管理アカウントと同じ番号を使用するかどうかにかかわらず、使用されている電話番号の正確なリストと、有効な秘密の質問は、認証情報と同様に安全な場所に保管してください。

誰がアクセスできるかを確認、追跡する

  • 管理アカウントの推奨事項にもあったように、メンバーアカウントのルートユーザーのメールアドレス、パスワード、MFA、電話番号に社内の誰がアクセスできるかについては、定期的に確認する必要があります。確認は既存のビジネス上の手続きに則って行うことができます。または、担当者だけに適切にアクセスを限定できるよう、月ごとや四半期ごとにこの情報を確認することも有効です。

  • ルートユーザーの認証情報へのアクセスを回復またはリセットするプロセスが、特定の個人に依存しないようにしてください。すべてのプロセスは、誰かが不在だったとしても問題なく進められるよう設計します。

ルートユーザーの認証情報の使用プロセスをドキュメント化する

  • 組織の管理アカウントの作成などの重要なプロセスは、複数の担当者で複数のステップを行うよう、プランニングされたプロセスであることが一般的です。実施するステップとそれらの順序を含め、そのプランをドキュメント化して公開することをお勧めします。こうすることで、意思決定が常にプランどおりに行われるようにできます。

  • 重要なプロセスの実行をドキュメント化し、各ステップに関与した個人と使用された値の記録が実行時に確実に残るようにします。また、例外や予期しないイベントが発生した場合についてのドキュメントを提供することも重要です。

    例外や予期しないイベントが発生した場合は、発生した時間、退室した人、持ち出されたものをドキュメント化します。その後、再入室した人、戻ってきたものもドキュメント化します。

  • ルートユーザーの認証情報の使用方法についてのプロセスは、パスワードのリセットなど、さまざまなシナリオを想定したうえで作成、公開します。特定のシナリオで AWS Support の操作プロセスが不明な場合は、サポートチケットを作成し、そのタスクの実行方法に関する最新のガイダンスをリクエストします。

    ドキュメント化の対象となるシナリオには次のようなものが含まれます。

    • ルートユーザーでしか実行できないオペレーションを行うための、ルートユーザーへのアクセス。

    • アクセスを失った場合の、ルートユーザーのパスワードのリセット。

    • アクセスがある状態での、ルートユーザーのパスワードの変更。

    • デバイスへのアクセスを失った場合の、ルートユーザーの MFA のリセット。

    • バッテリーベースのデバイスを使用している場合の、ルートユーザーの MFA の変更。

    • メールアカウントへのアクセスを失った場合の、ルートユーザーのメールアドレスのリセット。

    • アクセスがある状態での、ルートユーザーのメールアドレスの変更。

    • 電話番号へのアクセスを失った場合の、ルートユーザーの電話番号のリセット。

    • アクセスがある状態での、ルートユーザーの電話番号の変更。

    • 組織の管理アカウントの削除。

  • ルートユーザーに引き続きアクセスできること、およびメンバーアカウントの携帯電話番号 (割り当てた場合) が運用されていることのテストと妥当性確認を、少なくとも四半期ごとに実施します。このようにスケジューリングすることで、プロセスが機能していることと、担当者がアクセスを保持していることを組織的に保証できます。また、プロセスの正常な実施のために行う必要があるステップをアクセスの管理者が理解していることの実証にもなります。プロセスの関係者が何をすべきかを理解していないという状況は確実に避けなければなりません。火災訓練などにも見られるように、練習によって人の能力は向上し、とっさの状況でも冷静でいられるようになります。

    各テストでは、体感したことについて熟考し、プロセスの改善を提案する機会を設けます。特に、正しく実施されなかったステップや、予期しない結果になったステップを調べます。どのようにプロセスを変更すれば、次回の結果を改善できるでしょうか。

    パスワードをローテーションする機会としてこうしたテストを実施しているユーザーもいますが、そうする代わりに、複雑に設定した同じパスワードを使用し続けることをお勧めします。パスワードは、侵害された疑いがある場合にのみ更新を検討してください。

SCPを使用し、メンバーアカウントのルートユーザーで行えることを制限する

サービスコントロールポリシー (SCP) を組織内に作成して組織のルートにアタッチし、すべてのメンバーアカウントに適用されるようにすることをお勧めします。次の SCP の例では、AWS サービスの API コールを実行できないよう、すべてのメンバーアカウントのルートユーザーを制限しています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } } } ] }

多くの場合、管理タスクは、関連する管理者用アクセス許可を持つメンバーアカウントの AWS Identity and Access Management (IAM) ロールのいずれかで実行することが可能です。このようなロールには、アクティビティの制限、ログ記録、モニタリングを行う適切なコントロールが適用されている必要があります。

ルートユーザーの認証情報へのアクセスをモニタリングするコントロールを適用する

  • ルートユーザーの認証情報へのアクセスを有効にした場合も、そのアクセスは頻繁に行われるべきではありません。ルートユーザーの認証情報のログインと使用が通知されるよう、Amazon CloudWatch Events のようなツールを使用してアラートを作成します。この通知は、使用が適正か不正かにかかわらず重要度の高いものとし、関係者が確実に確認できるようにします。設定例については、Monitor and Notify on AWS アカウント Root User Activity を参照してください。

  • こうした通知を受け取る担当者は、ルートユーザーのアクセスが適正であることを確認する方法、およびセキュリティインシデントが発生していると判断した場合のエスカレーションの方法を理解している必要があります。