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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SEC02-BP04 一元化された ID プロバイダーを利用する

SEC03-BP02 最小特権のアクセスを付与します

SEC10-BP02 インシデント管理計画を作成する

SEC10-BP07 ゲームデーを実施する

Set up emergency access to the AWS Management Console

SAML 2.0 フェデレーティッドユーザーが AWS Management Console にアクセス可能にする

Break glass access

AWS re:Invent 2022 - Simplify your existing workforce access with IAM Identity Center

AWS re:Inforce 2022 - AWS Identity and Access Management (IAM) deep dive

AWS Break Glass Role

AWS customer playbook framework

AWS incident response playbook samples