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

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

Clock Icon2023.08.28

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

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

前提

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

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

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

アーキテクチャ選定

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

img

認証基盤どれにする?

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

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

メリット ?‍ デメリット ☔
IAMユーザー IAM Identity Center 障害時にも使える 余分に認証情報やグループを管理
IAM Identity Center ユーザー グループ・アクセス管理が楽 IAM Identity Center 障害への考慮

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

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

アクセス方法どうする?

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

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

img

メリット ? デメリット ☔
直接ログイン アクセスが直感的 スケールが手間
スイッチロール スケールが容易 スイッチロールが手間

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

img

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

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

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

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

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

メリット ? デメリット ☔
仕組み化する 厳密なアクセス管理 管理・運用コストが高い
仕組み化しない 管理・運用コストが低い 不用意に使われるリスク

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

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

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

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

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

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

設計〜構築

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

img

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

AWSアカウント 構成

img

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

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

IAM Identity Center 構成

img

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

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

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

IAMロール 構成

img

各メンバーアカウントに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アカウントへアクセスします。

img

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

img

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

img

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

img

追加で必要な対応

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

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

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

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

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

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

おわりに

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

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

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

参考


  1. もうひとつの候補として外部プロバイダー(IdP)からの IDフェデレーション もあります。自社でIdPを保有している際は候補として検討ください。 

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.