簡易的なAWSアカウントへの緊急アクセス経路(Breakglass)を作成する

緊急時にAWSアカウントへアクセスできる経路(Breakglass) を作ってみます。 IAM Identity Center 、およびIAMロールを使って実現します。

以降でアーキテクチャ選定、設計・構築について記載します。

前提

今回は AWS Organizations を利用したマルチアカウント環境での 緊急アクセス経路を想定します。

"緊急時" というのは色んな解釈ができるため、 もう少し範囲を狭めておきます。 本ブログでは AWSアカウント上で何か障害が起きた際に、 「 通常の構築/運用担当者がアクセスできない状況 」を想定します。 そのときに、他のメンバー(例: セキュリティチーム)が 緊急でアクセスできる経路を作成します。

また設計にあたり、以下AWSブログやホワイトペーパーを参考にしています。

• AWS Organizations における組織単位のベストプラクティス | Amazon Web Services ブログ
• Break glass access - Organizing Your AWS Environment Using Multiple Accounts

アーキテクチャ選定

緊急アクセス経路の選定ポイントとして、 3つの分類を記載しました。それぞれ考えていきます。

認証基盤どれにする？

緊急アクセス経路で使う認証情報を考えます。 IAMユーザー と IAM Identity Center(SSO)ユーザー が候補です ¹ 。

それぞれの メリット/デメリット を簡単に記載します。

IAMユーザーを使う最大のメリットは、グローバルサービス であることです。 IAM Identity Center は リージョンサービス なので、 リージョン単位の障害が起きた際には、使えなくなる可能性があります。

一方、管理コスト面では IAM Identity Center の方が楽です。 IAM Identity Center 側で「通常のアクセス経路」と「非常時のアクセス経路」を併せて管理できます。 IAMユーザーを作る場合は、余分に認証情報やグループ管理が必要です。

アクセス方法どうする？

どのように対象のAWSアカウントへアクセスするかを決めます。 候補は「直接ログイン」もしくは「スイッチロール」です。

それぞれのアクセスイメージは以下のとおりです。

スイッチロールはいわゆる Jumpアカウント構成です。

– 画像: AWSにおけるマルチアカウント管理の手法とベストプラクティス(PDF) | AWS Summit

スイッチロールは各AWSアカウントへIAMロールを展開するのみなので、 スケールが容易です。

一方で直接ログイン、スケールは少し面倒です。 特にIAMユーザーを使う場合は、AWSアカウントが増えるたびにIAMユーザーを 新規作成しないといけません。

権限昇格を仕組み化する？

Breakglass アクセスの定義を色々と調べていると、 「非常時に承認フローを経て、アクセス権を自動昇格」のような記載が多いです。 ただ、今回は「簡易的」ということで、仕組み化しない選択肢も考慮します。

前提として「緊急アクセス経路の使用」を詳細にロギングすることは必須です。

仕組み化しない場合は、管理者の把握外で使われるリスクに注意します。 例えば「緊急アクセス経路の使用」を通知する環境を用意しておくと安心でしょう。

また、IAM Identity Center を使って権限昇格を仕組み化する場合は、 AWSソリューション(TEAM)を活用しても良さそうです。以下TEAMの参考ブログです。

• AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた | DevelopersIO

本ブログのアーキテクチャ

以上の選定ポイントをもって、 本ブログでは以下アーキテクチャで進めます。

• IAM Identity Center ユーザー を活用する
  • 認証認可を集中管理したいため
  • IAM Identity Center はリージョナルサービスであり、十分な可用性があると判断
• スイッチロールを活用する
  • スケールが容易なため
• 権限昇格を仕組み化しない
  • 仕組み化する場合の「仕組みのメンテナンス」や「フローの周知、徹底」コストが重たい
  • 最低限、緊急アクセス使用を管理者が把握できるように、整備することで許容する

設計〜構築

全体構成は以下のとおりです。

それぞれ詳細を以降で説明します。

AWSアカウント 構成

Breakglassアカウントを作成します。

Breakglassアカウントから 各メンバーアカウントへアクセスできるように、 以降の IAM Identity Center を構成していきます。

IAM Identity Center 構成

IAM Identity Center にて緊急アクセス用のグループを作成します。 そのグループに Breakglassアカウントへの アクセス割当を作成します。

割当で使用する許可セット(BreakglassAccess)には「スイッチロールできるポリシー」を設定します。 具体的には以下のようなポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "*"
    }
  ]
}

IAMロール 構成

各メンバーアカウントにIAMロール(Breakglass_Admin)を配置します。 この配置は CloudFormation StackSets などで自動化しておくと良いでしょう。

ロールの信頼関係ポリシーを適切に設定します。 具体的には Breakglass アカウントからの AssumeRole を許可するポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${BreakglassアカウントID}:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ロールのポリシーとして AdministratorAccess を付与しておきます。

実際に使ってみる

検証環境で実際のアクセスの流れを紹介します。

まずは IAM Identity Center ポータルにログインして、 Breakglassアカウントへアクセスします。

マネコンにてスイッチロールを行います。 右上から [ロールの切り替え] を選択します。

項目を記入して [ロールの切り替え] を行います。

スイッチロール、各種リソースを閲覧・更新できることを確認できました。

追加で必要な対応

緊急アクセスのロギング・通知

緊急アクセスを使ったこと、 およびアクセス先で実施した内容のロギングは必須です。

具体的には CloudTrail 証跡を設定しておきましょう。 組織的に設定を行い、メンバーアカウント上で更新されないような 予防的ガードレールを適用しておきます。

また、Breakglassアカウントからスイッチロールされたことを 通知する仕組みも作ると良いでしょう。 意図しない使用に気づけるので、管理者としては安心です。

緊急アクセス経路 使用フローの策定、周知

緊急アクセス経路の使用フローを明文化して、 周知しましょう。 「緊急アクセス経路を、いつ・どのように使うのか」 を管理者・利用者 共に把握しておきます。

おわりに

簡易的ですが Breakglass アクセスを実装してみました。

普段は滅多に使わない経路ですが、使用される際は重要な局面となります。 なので、「使用フローの策定・周知」を徹底することがとても大事です。

以上、参考になれば幸いです。

参考

• AWS Organizations における組織単位のベストプラクティス | Amazon Web Services ブログ
• Break glass access - Organizing Your AWS Environment Using Multiple Accounts