SEC03-BP03 緊急アクセスのプロセスを確立する - AWS Well-Architected フレームワーク
実装のガイダンス リソース

SEC03-BP03 緊急アクセスのプロセスを確立する

一元化された ID プロバイダーで万一障害が発生した場合に備え、ワークロードへの緊急アクセスを許可するプロセスを作成します。

緊急事態につながる可能性のある、さまざまな障害モードに対応するプロセスを設計する必要があります。例えば、通常の状況では、従業員ユーザーは一元化された ID プロバイダー (SEC02-BP04) を使用してクラウドにフェデレーションし、ワークロードを管理します。しかし、一元化された ID プロバイダーに障害が発生した場合や、クラウドのフェデレーションの設定が変更された場合、従業員ユーザーはクラウドにフェデレーションできなくなる可能性があります。緊急アクセスのプロセスでは、権限を持つ管理者がフェデレーション設定やワークロードの問題を解決するために、代替手段 (代替フェデレーションやユーザーの直接アクセスなど) を通じてクラウドリソースにアクセスすることを許可します。緊急アクセスのプロセスは、通常のフェデレーションメカニズムが復旧するまで使用されます。

期待される成果:

  • 緊急事態とみなされる障害モードを定義して文書化します。通常の状況と、ユーザーがワークロードの管理に使用するシステムを考慮してください。それぞれの依存関係でどのように障害が発生する可能性があるか、またその障害がどのように緊急事態を引き起こすかを検討します。信頼性の柱の質問とベストプラクティスは、障害モードを特定し、障害の可能性を最小限に抑えるための、より回復力のあるシステムの構築に役立ちます。

  • 障害が緊急事態であると確認する際に従うべき手順を文書化します。例えば、ID 管理者がプライマリ ID プロバイダーとスタンバイ ID プロバイダーのステータスを確認すること、両方とも使用できない場合は、ID プロバイダーに障害発生時の緊急事態を宣言することを要求できます。

  • 各種の緊急モードまたは障害モードに固有の緊急アクセスのプロセスを定義します。具体的に定義することで、ユーザーが緊急事態の種類にかかわらず一般的なプロセスを使いすぎる状況を軽減することができます。緊急アクセスのプロセスで、各プロセスを使用すべき状況、逆にそのプロセスを使用すべきでない状況、適用される可能性のある代替プロセスを説明します。

  • 詳細な指示とプレイブックを含めてプロセスを十分に文書化することで、迅速かつ効率的に実行できます。緊急事態はユーザーにとってストレスの多い時間であり、ユーザーは極度の時間的プレッシャーにさらされる可能性があるため、プロセスはできるだけシンプルに設計してください。

一般的なアンチパターン:

  • 緊急アクセスのプロセスの文書化およびテストが不十分である。ユーザーは緊急事態への備えができておらず、緊急事態が発生しても即席のプロセスに従う。

  • 緊急アクセスのプロセスで、通常のアクセスメカニズムと同じシステム (一元化された ID プロバイダーなど) を使用する。これにより、このようなシステムの障害が、通常および緊急の両方のアクセスメカニズムに影響を及ぼし、障害からの回復能力が損なわれる可能性があります。

  • 緊急アクセスのプロセスが、緊急ではない状況で使用される。例えば、ユーザーは、パイプラインを通じて変更を送信するよりも直接変更する方が簡単だと感じるため、頻繁に緊急アクセスのプロセスを誤用します。

  • 緊急アクセスのプロセスで、プロセスを監査するための十分なログが生成されていない、またはログが監視されておらず、プロセスの誤用の可能性について警告されない。

このベストプラクティスを活用するメリット:

  • 緊急アクセスのプロセスを十分に文書化し、十分にテストすることで、ユーザーが緊急事態に対応して解決するための時間を短縮できます。これにより、ダウンタイムが減少し、顧客に提供するサービスの可用性が高まります。

  • 緊急アクセスのリクエストをそれぞれ追跡し、緊急事態以外の場合にプロセスを誤用しようとする不正な試みを検出して警告することができます。

このベストプラクティスを活用しない場合のリスクレベル: 中

実装のガイダンス

このセクションでは、AWS 上にデプロイされたワークロードに関連する複数の障害モードに対する緊急アクセスのプロセス作成のためのガイダンスを提供します。すべての障害モードに適用される共通のガイダンスから始めて、次に障害モードの種類に基づいた具体的なガイダンスを示します。

すべての障害モードに共通のガイダンス

障害モードに対する緊急アクセスのプロセスを設計する際は、次の点を考慮してください。

  • プロセスの前提条件と仮定事項 (プロセスを使用すべき場合と使用すべきでない場合) を文書化します。障害モードを詳しく説明し、他の関連システムの状態などの仮定事項を文書化しておくと役立ちます。例えば、障害モード 2 に対するプロセスでは、ID プロバイダーは使用可能ですが、AWS の設定が変更されているか、有効期限が切れていると仮定しています。

  • 緊急アクセスのプロセスで必要となるリソースを事前に作成しておきます (SEC10-BP05)。例えば、IAM ユーザーとロールを持つ緊急アクセス用の AWS アカウントと、すべてのワークロードアカウントでのクロスアカウントの IAM ロールを事前に作成します。これにより、緊急事態の発生時にリソースが準備され、使用可能な状態を確保できます。リソースを事前に作成することで、緊急時に使用できない可能性のある AWS コントロールプレーン API (AWS リソースの作成と変更に使用) への依存関係がなくなります。さらに、IAM リソースを事前に作成することで、結果整合性による潜在的な遅延を考慮する必要がなくなります。

  • インシデント管理計画に緊急アクセスのプロセスを含めます (SEC10-BP02)。緊急事態の追跡方法、同僚チームやリーダーシップなど組織内の他のメンバーへの伝達方法、該当する場合は外部の顧客やビジネスパートナーへの伝達方法を文書化します。

  • 既存のサービスリクエストワークフローシステム (ある場合) で緊急アクセスリクエストプロセスを定義します。通常、このようなワークフローシステムでは、リクエストに関する情報を収集する受付フォームを作成したり、ワークフローの各段階でリクエストを追跡したり、自動および手動の承認ステップを追加したりできます。各リクエストを、インシデント管理システムで追跡される、対応する緊急イベントに関連付けます。緊急アクセス用の統一されたシステムがあると、このようなリクエストを単一のシステムで追跡し、使用傾向を分析して、プロセスを改善できます。

  • 緊急アクセスのプロセスは権限を持つユーザーのみが開始できることと、必要に応じてそのユーザーの同僚または管理者の承認が必要であることを確認します。承認プロセスは、営業時間内、時間外を問わず、効果的に実施される必要があります。承認リクエストについて、一次承認者が不在の場合はどのように二次承認者を許可するのか、承認を得るまでに一連の管理層にリクエストをどのようにエスカレーションするのかを定義します。

  • 緊急アクセスに成功した場合と失敗した場合の両方について、詳細な監査ログとイベントが生成されることを確認します。リクエストプロセスと緊急アクセスメカニズムの両方を監視して、誤用や不正アクセスを検出します。インシデント管理システムで、進行中の緊急事態とアクティビティを関連付けて、想定時間外に障害が発生した場合に警告を発します。例えば、緊急アクセス AWS アカウントでのアクティビティを監視して警告する必要がありますが、こうしたアクティビティは通常の運用では使用されるべきではありません。

  • 緊急アクセスのプロセスを定期的にテストして、手順が明確であること、適切なレベルのアクセス権を迅速かつ効率的に付与できることを確認します。緊急アクセスのプロセスは、インシデント対応シミュレーション (SEC10-BP07) とディザスタリカバリテスト (REL13-BP03) の一部としてテストする必要があります。

障害モード 1: AWS へのフェデレーションに使用する ID プロバイダーが使用できない

「SEC02-BP04 一元化されたプロバイダーを使用する」で説明したとおり、ワークフォースユーザーをフェデレーションして AWS アカウントへのアクセス権を付与するには、一元化された ID プロバイダーを使用することを推奨します。IAM Identity Center を使用して AWS 組織内の複数の AWS アカウントにフェデレーションするか、IAM を使用して個別の AWS アカウントにフェデレーションすることができます。いずれの場合も、従業員ユーザーは、シングルサインオンのために AWS へのサインインエンドポイントにリダイレクトされる前に、一元化された ID プロバイダーで認証されます。

万一、一元化された ID プロバイダーが使用できない場合、従業員ユーザーは AWS アカウントにフェデレーションすることも、ワークロードを管理することもできなくなります。こうした緊急事態では、AWS アカウントにアクセスするための緊急アクセスのプロセスを少数の管理者に提供し、一元化された ID プロバイダーのオンライン復帰を待つ余裕のない重要なタスクを実行できるようにします。例えば、ID プロバイダーを 4 時間利用できない間に、顧客トラフィックの想定外の急増に対応するために、本番稼働用アカウントの Amazon EC2 Auto Scaling グループの上限を変更する必要が生じたとします。この場合、緊急管理者は、緊急アクセスのプロセスに従って、特定の本番稼働用 AWS アカウントへのアクセス権を取得し、必要な変更を加える必要があります。

緊急アクセスのプロセスでは、事前に作成された緊急アクセス用 AWS アカウントを使用します。このアカウントは緊急アクセスの目的でのみ使用され、緊急アクセスのプロセスに対応するための AWS リソース (IAM ロールや IAM ユーザーなど) が設定されています。通常の運用中は、緊急アクセスアカウントへのアクセスを全面的に禁止し、このアカウントの誤用を監視し、警告する必要があります (詳細については、前述の「共通のガイダンス」セクションを参照してください)。

緊急アクセスアカウントには、緊急アクセスを必要とする AWS アカウントでクロスアカウントロールを引き受ける権限を持つ、緊急アクセス IAM ロールがあります。これらの IAM ロールは事前に作成され、緊急アカウントの IAM ロールを信頼する信頼ポリシーで設定されます。

緊急アクセスのプロセスでは、次のいずれかの方法を使用できます。

  • 緊急アクセスアカウントでは、関連する強力なパスワードと MFA トークンを使用して、緊急管理者用の一連の IAM ユーザーを事前に作成します。これらの IAM ユーザーには、IAM ロールを引き受け、緊急アクセスが必要な AWS アカウントへのクロスアカウントアクセスを許可する権限があります。このようなユーザーはできるだけ少人数にし、各ユーザーを 1 人の緊急管理者に割り当てることをお勧めします。緊急時には、緊急管理者ユーザーがパスワードと MFA トークンコードを使用して緊急アクセスアカウントにサインインし、緊急アカウントで緊急アクセス IAM ロールに切り替え、最後にワークロードアカウントで緊急アクセス IAM ロールに切り替えて、緊急の変更アクションを実行します。この方法の利点は、それぞれの IAM ユーザーが 1 人の緊急管理者によって割り当てられるため、CloudTrail イベントを確認することで、どのユーザーがサインインしたかを把握できることです。欠点は、複数の IAM ユーザーと、それぞれに関連付けられた永続的なパスワードおよび MFA トークンを管理する必要があることです。

  • 緊急アクセス AWS アカウントルートユーザーを使用して緊急アクセスアカウントにサインインし、緊急アクセスの IAM ロールを引き受け、ワークロードアカウントでクロスアカウントロールを引き受けることができます。ルートユーザーには、強力なパスワードと複数の MFA トークンを設定することをお勧めします。また、パスワードと MFA トークンは、強力な認証と承認を実行する安全なエンタープライズ認証情報ボールトに保存することをお勧めします。パスワードと MFA トークンのリセット要因を確保する必要があります。アカウントの E メールアドレスをクラウドセキュリティ管理者が監視するメール配布リストに設定し、アカウントの電話番号は、セキュリティ管理者が同様に監視する共有電話番号に設定します。この方法の利点は、管理するルートユーザーの認証情報が 1 セットだけであることです。欠点は、これが共有ユーザーであるため、複数の管理者がルートユーザーとしてサインインできてしまうことです。エンタープライズボールトのログイベントを監査して、どの管理者がルートユーザーのパスワードをチェックアウトしたかを特定する必要があります。

障害モード 2: AWS の ID プロバイダー設定が変更された、または有効期限が切れている

従業員ユーザーが AWS アカウントにフェデレーションできるようにするには、外部 ID プロバイダーを使用して IAM Identity Center を設定するか、IAM ID プロバイダーを作成します (SEC02-BP04)。通常、これらを設定するには、ID プロバイダーが提供する SAML メタデータ XML ドキュメントをインポートします。メタデータ XML ドキュメントには、ID プロバイダーが SAML アサーションの署名に使用する、プライベートキーに対応する X.509 証明書が含まれています。

AWS 側でのこれらの設定は、管理者が誤って変更または削除する可能性があります。もう 1 つのシナリオとして、AWS にインポートされた X.509 証明書の有効期限が切れ、新しい証明書を含む新しいメタデータ XML が AWS にインポートされていない場合があります。いずれの場合も、従業員ユーザーの AWS へのフェデレーションが失敗し、緊急事態が発生する可能性があります。

このような緊急事態が発生した場合は、フェデレーションの問題を解決するために、ID 管理者に AWS へのアクセスを提供します。例えば、ID 管理者は緊急アクセスのプロセスを使用して緊急アクセス用 AWS アカウントにサインインし、Identity Center 管理者アカウントのロールに切り替え、ID プロバイダーから提供された最新の SAML メタデータ XML ドキュメントをインポートして外部 ID プロバイダーの設定を更新することで、フェデレーションを再有効化することができます。フェデレーションが修正されたら、従業員ユーザーは引き続き通常の操作プロセスに従って、ワークロードアカウントにフェデレーションできます。

前述の「障害モード 1」で説明した方法に従って、緊急アクセスのプロセスを作成します。Identity Center 管理者アカウントだけにアクセスし、そのアカウントで Identity Center 上でのアクションを実行するための、最小特権のアクセス許可を ID 管理者に付与できます。

障害モード 3: ID センターの中断

万一、IAM Identity Center または AWS リージョンが中断した場合に備えて、AWS Management Consoleへの一時的なアクセスを提供するための構成を設定しておくことをお勧めします。

緊急アクセスのプロセスでは、ID プロバイダーから緊急アカウントの IAM への、直接フェデレーションを使用します。プロセスと設計上の考慮事項の詳細については、「AWS Management Consoleへの緊急アクセスを設定する」を参照してください。

実装手順

すべての障害モードで共通の手順

  • 緊急アクセスのプロセス専用の AWS アカウントを作成します。IAM ロール、IAM ユーザー、IAM ID プロバイダー (オプション) など、アカウントで必要となる IAM リソースを事前に作成しておきます。さらに、緊急アクセスアカウントで対応する IAM ロールとの信頼関係を持つクロスアカウントの IAM ロールを、ワークロード AWS アカウントで事前に作成します。AWS CloudFormation StackSets with AWS Organizations を使用して、組織内のメンバーアカウントでこうしたリソースを作成できます。

  • メンバー AWS アカウント内のクロスアカウント IAM ロールの削除と変更を拒否する、AWS Organizations サービスコントロールポリシー (SCP) を作成します。

  • 緊急アクセス AWS アカウントの CloudTrail を有効にし、ログ収集 AWS アカウントの中央の S3 バケットに証跡イベントを送信します。AWS Control Tower を使用して AWS マルチアカウント環境を設定・管理している場合は、AWS Control Tower を使用して作成した、または AWS Control Tower に登録したすべてのアカウントで CloudTrail がデフォルトで有効になっており、専用のログアーカイブ AWS アカウントの S3 バケットに送信されます。

  • 緊急 IAM ロールごとのコンソールログインと API アクティビティに一致する EventBridge ルールを作成して、緊急アクセスアカウントのアクティビティを監視します。インシデント管理システムで追跡中の進行中の緊急事態以外でアクティビティが発生した場合は、セキュリティオペレーションセンターに通知を送信します。

「障害モード 1 : AWS へのフェデレーションに使用する ID プロバイダーが使用できない」、および「障害モード 2: AWS の ID プロバイダー設定が変更された、または有効期限が切れている」での追加手順

  • 緊急アクセス用に選択したメカニズムに応じて、リソースを事前に作成します。

    • IAM ユーザーを使用する: 強力なパスワードおよび関連付けられた MFA デバイスを持つ IAM ユーザーを事前に作成します。

    • 緊急アカウントのルートユーザーを使用する: ルートユーザーに強力なパスワードを設定し、そのパスワードをエンタープライズ認証情報ボールトに保存します。複数の物理 MFA デバイスをルートユーザーに関連付け、緊急管理チームのメンバーがすぐにアクセスできる場所に保存します。

「障害モード 3: ID センターの中断」での追加手順

  • 「AWS Management Consoleへの緊急アクセスを設定する」で説明しているとおり、緊急アクセス AWS アカウントで IAM ID プロバイダーを作成し、ID プロバイダーからの直接 SAML フェデレーションを有効にします。

  • ID プロバイダーで、メンバーのいない緊急オペレーショングループを作成します。

  • 緊急アクセスアカウントで、緊急オペレーショングループに対応する IAM ロールを作成します。

リソース

関連する Well-Architected のベストプラクティス:

関連ドキュメント:

関連動画:

関連する例: