管理アカウントのベストプラクティス - AWS Organizations

管理アカウントのベストプラクティス

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

注記

AWS Organizations は、「マスターアカウント」の名称を「管理アカウント」に変更します。変更されたのは名称だけです。機能に変更はありません。新しい名称への移行が完全に終わるまでは、表記に従来の名称が使用されている場合があります。名称が従来のままになっていることにお気づきになりましたら、ページ上部のフィードバックリンクからご報告ください。

管理アカウントを必要とするタスクにのみ使用する

管理アカウントとそのユーザーおよびロールは、そのアカウントでしか実行できないタスクにのみ使用することをお勧めします。すべての AWS リソースは組織内の他の AWS アカウント に保存し、管理アカウントからは切り離します。ただし、唯一の例外として、AWS CloudTrail を有効にし、関連する CloudTrail 追跡とログを管理アカウントで保持することをお勧めします。

リソースを他のアカウントで保持する重要な理由の一つは、管理アカウントのユーザーとロールに対する制限に Organizations サービスコントロールポリシー (SCP) を使用できないためです。

また、リソースを管理アカウントから分離することで、請求書に記載される請求額が理解しやすくなります。

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

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

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

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

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

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

  • 長期保存と、ルートユーザーのパスワードに対するアクセスを管理するには、会社の情報セキュリティポリシーを使用してください。この実施例としては次のようなものが考えられます。

    • パスワードを出力して安全な場所に保管する。

    • パスワードを分割し、上級管理者に配布する。

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

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

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

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

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

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

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

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

  • この管理アカウントの保護以外の目的に物理的な MFA を使い回さないことを強くお勧めします。物理的な MFA の使い回しは、運用上の混乱、および MFA の漏洩の原因となります。

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

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

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

  • 固定電話、SIP、携帯電話番号に対する確かな攻撃ベクトルはいくつかあるものの、全体的には、そうしたベクトルをより複雑にするとリスクは低減します。ルートアクセスの復旧にこのメカニズムを使用する場合、AWS Support 代表者は、他の要素を利用してこうしたリスクを管理できます。そのため、プロセスの保護を強化する有効な手段として、電話番号を追加することをお勧めします。

  • 電話番号をプロビジョニングするためのいくつかのオプションがありますが、推奨されるのは、専用の SIM カードと電話を安全な場所に長期保存することです。重要な点として、この携帯電話の契約料金の支払いを担当するチームは、通話の受発信が長期間にわたって確認できないとしても、これが重要な番号であることを理解していなければなりません。

  • また、この電話番号を社内で公開しないようにすることも重要です。番号はAWS 連絡先情報のコンソールページでドキュメント化し、その詳細を経理担当チームと共有します。他の場所では一切ドキュメント化しません。こうすることで、SIM に関連付けられた電話番号を別の SIM に移すことに関連する攻撃ベクトルのリスクを軽減できます。

  • 電話は、既存の情報セキュリティポリシーに従って保管します。ただし、保管場所は、関連する他の認証情報と同じにしてはなりません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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