トップ > AWS Organizations > マルチアカウントへの権限集約のポイントと必要な移行ステップ

マルチアカウントへの権限集約のポイントと必要な移行ステップ

AWS Organizations AWS IAM Identity Center AWS IAM
記事タイトルとURLをコピーする

こんにちは！
エンタープライズクラウド部技術2課の日高です。

今回はマルチアカウントへの「権限集約のポイントと必要な移行ステップ」についてブログを記載しようと思います。

はじめに

最近、多くのお客様から以下のようなお悩みをいただいています。

  • AWSをシングルアカウントで運用を開始してからある程度の時間が経過し、現在はIAMユーザーやIAMポリシーが増えてしまい、これらが散乱している状態。そのため統制が十分に取れておらず、管理が困難になっている。
  • シングルアカウントからマルチアカウントへの移行を検討していますが、その際の具体的な手順や注意点についての知識が不足している。
  • 既にマルチアカウントを利用しているものの、各アカウントごとにIAMユーザーを作成し、それぞれでログインしているため、ユーザー認証の一元的な制御が難しい状況です。

これらの問題に加え、よく見受けられる現象として、退職者のIAMユーザーが未削除のまま残っていたり、本来必要のないIAMユーザーに管理者権限（例: AWSマネージドポリシーの「AdministratorAccess」）が付与されてしまっているケースがあります。

このような状態はセキュリティインシデントを引き起こす大きなリスクを伴います。
そのため、これらの問題を解消するために迅速な対応と改善が必要不可欠になります。

本ブログでは、マルチアカウントにおけるユーザー認証の選択基準、移行手順や考慮点について解説していきます。

マルチアカウントにおけるユーザー認証方法の選択基準

ユーザー認証方法の選択基準については、以下のフローチャートをご参照ください。

マルチアカウントでの主なユーザー認証方法には、IAM方式とSSO方式（AWS IAM Identity Centerのみの利用またはAWS IAM Identity Centerと外部プロバイダーの連携）が存在します。

ユーザー認証方法の説明については、詳しくは下記の弊社ブログをご覧ください。

blog.serverworks.co.jp

上記ブログにも記載されていますが、以下の理由から基本的にSSO方式を推奨します。

  • IAM方式は、IAMのサービスクォータにおいてAWSアカウントが数十から数百に増えると耐えられなくなるリスクがある。
  • IAM方式では、IAM管理アカウント以外での運用作業が発生するが、SSO方式では全てSSOアカウント内で完結する。
  • ユーザーにとって、SSO方式のUIはシンプルで理解しやすい。

しかしながら、AWS IAM Identity Centerには、AWS Organizationsを使用していないと利用不可といった制約もあります。
従って、利用しているサービスや、今後利用可能なサービスによって、最適なユーザー認証の方法は異なります。

そのためフローチャートを元に、最適な方法を選択していただければと考えています。

マルチアカウントにおけるユーザー認証への移行手順

全体像

前節「マルチアカウントにおけるユーザー認証方法の選択基準」で決定したユーザー認証方法へ移行する際の、ステップの概要を以下に示します。

No 項目 概要
1 アセスメント（情報収集） ・社内・社外の方が使用している現存するIAMユーザーやIAMグループのアセスメントを行います。
2 IAM権限設計 ・アセスメントした内容に基づき、IAMの権限設計を行います。
3 IAM権限構築 ・アクセス管理アカウント（IAM管理アカウント、SSOアカウント）や既存のAWSアカウントに対して、必要なIAMの権限構築を行います。
4 認証情報の連携 ・利用者に対して、ユーザーの認証情報を連携します。
5 MFAの有効化 ・利用者に対して、MFAの有効化を実施して頂きます。
6 運用切り替え（並行運用） ・並行運用期間とし、ログイン方式を順次切り替えて頂きます。
7 既存の不要なIAMリソースの削除 ・切り替えが完了したら既存の不要なIAMリソースの削除をしていただきます。

こちらの移行手順は、シングルアカウントからマルチアカウントへの移行や、既にマルチアカウントで運用中だがユーザー認証の制限が不十分な場合などに適用可能です。

次説以降で、No1.2.7の項目について解説していきます。

No.1 アセスメント（情報収集）

マルチアカウントへの権限集約をする上で、現状どのようなIAMの設定が行われているのかを把握し、問題点を洗い出すことが非常に重要になります。
特に、今回は「IAMグループ」と「IAMユーザー」に焦点を絞って確認を行います。

アセスメントする観点としては以下です。

  • IAMグループ
    • グループに関連付けられているIAMユーザー
    • 管理ポリシー（AWS管理ポリシーとカスタマー管理ポリシーの両方）
    • インラインポリシー
  • IAMユーザー
    • ユーザーに関連付けられているIAMグループ
    • 管理ポリシー
    • インラインポリシー
    • マネジメントコンソールへのアクセス許可
    • AWS CLIへのアクセス許可
    • MFA（多要素認証）の設定状況

これらのアセスメントを効率的に実施するために、IAMの現在の状態をマークダウン形式で出力するスクリプトを作成しました。
作成したスクリプトの詳細については下記をご覧ください。

blog.serverworks.co.jp

上記で取得した情報を元に次フェーズの「IAM権限設計」を行ないます。
紹介したスクリプトで取得できる表については、下記画像のイメージとなります。

No.2 IAM権限設計

権限設計

IAM権限の設計では、前節の「アセスメント」の情報を元に現存のIAMユーザーに与えられている権限を元に設計します。
「アセスメント」の情報を元に権限を設計する方法については、例を用いて後述するので、ここでは権限設計の概要について記載します。

IAM権限設計の際の最大の前提は、「最小権限の法則」です。
これは、ユーザーやシステムに必要最小限の権限のみを付与するという原則です。
権限を細分化していけばいくほど、不正アクセスやデータの漏洩リスクは低減します。

しかし、その一方で管理や運用のコストが増加してしまうというジレンマがあります。
このため、権限設計では、セキュリティの確保と運用コストのバランスを取る必要があります。

極端に権限を制限しすぎると業務の効率が悪化する可能性がある一方、過度に権限を付与してしまうとセキュリティのリスクが増大する性質があります。

私の経験上、実務でのIAM権限設計では、以下の5つの大枠の権限に分けると、バランス良く権限を管理することができると考えています。

  • 管理者権限: システムやサービス全体の設定や変更が可能な権限。全てのリソースにアクセスできる。
  • 閲覧権限: データや設定情報の読み取りのみを許可される権限。変更や削除は行えない。
  • 構築権限: システムやサービスの初期構築や変更が行える権限。
  • 運用権限: 日々の業務運用や一部の設定変更が可能な権限。
  • カスタム権限: 特定の目的や業務に特化したカスタマイズされた権限。必要に応じて設定する。

具体的な権限の内容や範囲は、組織やプロジェクトの特性に応じて調整することが重要です。
上記はあくまで一例としての分類ですので、実際の運用に合わせて最適な権限設計を行ってください。

MFA有効化の検討

ここまで権限管理について記載をしていましたが、パスワードポリシーやMFAの有効化も重要な検討事項になります。
特に、MFAの有効化は必須にすることを推奨します。

MFAを有効果しないことリスクや問題として下記が考えられます。

  • 不正アクセスリスク
    • MFAを使用しない場合、パスワードのみでアカウントにアクセスできてしまうため、万が一パスワードが漏洩した場合や弱いパスワードが使われている場合、不正アクセスのリスクが高まります。
  • アカウント乗っ取りのリスク
    • MFAを使用しない場合、攻撃者が成功率の高い総当たり攻撃などを用いて、アカウントにアクセスできる可能性が高まります。
  • 責任追跡の困難
    • MFAを使用しない場合、誰がいつ、どのような方法でアクセスしたかを正確に追跡することが難しくなります。

また、不正な手段でAWSアカウントにログインされると、AWS環境に対して悪意を持ってさまざまな操作を行うことが可能となります
不正アクセスされることの具体的な例については下記です。

  • 機密情報の漏洩
    • 攻撃者はアカウントにアクセスして、企業の機密情報や顧客の個人情報などを盗み出すことが可能になります。
  • システムの停止やデータの改ざん
    • 攻撃者がシステムの制御を奪い、AWSリソースを停止させたり、データを改ざんすることができます。
  • サービスの不正利用
    • 不正なアクセス権限を持つアカウントを使用して、AWSリソースを不正に利用し、コンピューティングリソースの無駄遣いや課金額の増加を引き起こすことが考えられます。

MFAの有効化は、利便性の低下を招く可能性はありますが、そのデメリットはセキュリティ上の大きなメリットに比べると小さいものです。
したがって、MFAの有効化を強く推奨します。

具体例

「アセスメント」の結果が下記のように示されている場合の権限設計方法について記載していきます。

User Name Group Managed Policy Inline Policy Management Console Access CLI Access MFA States
administrator Administrator Yes Yes Not Enable
UserA AmazonS3FullAccess No No Not Enable
UserB AmazonAPIGatewayAdministrator,
AmazonCognitoDeveloperAuthenticatedIdentities,
AmazonCognitoPowerUser 		Yes Yes Not Enable
UserC AmazonSSMFullAccess,
AmazonEC2ReadOnlyAccess, 		Yes Yes Enable
UserD CloudWatchReadOnlyAccess
CloudWatchReadOnlyAccess, 		No Yes Not Enable
UserE ReadOnlyAccess No No Not Enable
UserF PowerUserAccess Yes No Not Enable
UserG AmazonEC2ReadOnlyAccess, Yes No Not Enable

まず、多くのユーザーがMFAを有効化していないことが明確になりました。
この点に対して、MFAの有効化を推奨・必須とする措置を取ることを検討します。

IAMユーザーごとに設定されている主要な権限は以下の通りです。

  • AmazonS3FullAccess
  • AmazonAPIGatewayAdministrator
  • AmazonCognitoDeveloperAuthenticatedIdentities
  • AmazonCognitoPowerUser
  • AmazonSSMFullAccess
  • AmazonEC2ReadOnlyAccess
  • CloudWatchReadOnlyAccess
  • ReadOnlyAccess
  • PowerUserAccess

これらの権限を抽象化をすると、以下のようになります。

  • 管理者権限
  • 構築者権限
  • 閲覧者権限
  • Cognitoの操作
  • SSMの操作
  • EC2の閲覧権限
  • CloudWatchの閲覧権限

この分類を、前述の「概要」で説明した権限の枠組みに適用すると、以下のような権限設計になります。

  • 管理者権限: システムやサービス全体の設定や変更が可能。全リソースへのアクセス可能。
  • 閲覧権限: データや設定情報の読み取りのみ許可。変更や削除は不可。
  • 構築権限: システムやサービスの初期構築や変更が可能。
  • 運用権限:
    • 日々の業務運用や一部の設定変更が可能。
    • SSMの操作
    • Cognitoの操作
  • カスタム権限: 特定の目的や業務に特化した権限（現状は設定なし）

今回は対象の権限が少なかったので上記のようになりましたが、実際の権限設計の際もアセスメント結果を抽象化して概要でお伝えした権限にマッピングしていくことで権限設計をすることができます。

No.7 既存の不要なIAMリソースの削除

この章では、No.1から6のステップを完了した後、不要となったIAMリソースを削除する前段の特定方法に焦点を当て記載します。

No 項目 概要
1 アセスメント（情報収集） ・社内・社外の方が使用している現存するIAMユーザーやIAMグループのアセスメントを行います。
2 IAM権限設計 ・アセスメントした内容に基づき、IAMの権限設計を行います。
3 IAM権限構築 ・アクセス管理アカウント（IAM管理アカウント、SSOアカウント）や既存のAWSアカウントに対して、必要なIAMの権限構築を行います。
4 認証情報の連携 ・利用者に対して、ユーザーの認証情報を連携します。
5 MFAの有効化 ・利用者に対して、MFAの有効化を実施して頂きます。
6 運用切り替え（並行運用） ・並行運用期間とし、ログイン方式を順次切り替えて頂きます。
7 既存の不要なIAMリソースの削除 ・切り替えが完了したら既存の不要なIAMリソースの削除をしていただきます。

以下のステップで不要なIAMリソースを削除します

  • 不要なIAMユーザーの削除
  • 不要なIAMグループの削除
  • 不要なIAMロールの削除
  • 不要なIAMポリシーの削除

不要なIAMユーザーの特定

移行後、ほとんどはアクセス管理アカウントにしかIAMユーザーを存在させないため、その外のIAMユーザーは大部分が削除可能です。
ただし、例外としてプログラムが利用しているIAMユーザーや特定のケースでの削除が難しいユーザーも存在します。

ただ、大抵は90日以上使われていないIAMユーザーは不要なことが多いです。

そのため、複数アカウントから指定した日付以上マネジメントコンソールにログインしていないIAMユーザーを洗い出すスクリプトを作成しました。
PROFILESで指定したアカウントをスイッチロールして情報を取得するスクリプトなのでAWS CLIの設定が前提として必要になります。

#!/bin/bash

# アカウントのプロファイル名を配列として定義します
PROFILES=("profile1" "profile2" .....) # このリストに実際のAWSプロファイル名を追加してください

# 日付を計算
DAYS_AGO=90  # 今回の場合は90日以上前を指定
CUTOFF_DATE=$(date -j -v-"$DAYS_AGO"d "+%s")

# 出力ファイルの定義
OUTPUT_FILE="user-unused.md"

echo "| アカウント番号 | IAMユーザー名 | 最終ログイン日 |" > $OUTPUT_FILE
echo "|----------------|--------------|--------------|" >> $OUTPUT_FILE

for profile in "${PROFILES[@]}"; do
  # ユーザーを取得
  users=$(aws iam list-users --profile $profile | jq -c ".Users[] | select((.PasswordLastUsed == null) or ((.PasswordLastUsed | gsub(\"[+-][0-9]{2}:[0-9]{2}$\"; \"Z\") | strptime(\"%Y-%m-%dT%H:%M:%SZ\") | mktime) <= $CUTOFF_DATE))")

  for user in $users; do
    ACCOUNT_ID=$(echo $user | jq -r ".Arn" | cut -d':' -f5)
    USERNAME=$(echo $user | jq -r ".UserName")
    LAST_LOGIN=$(echo $user | jq -r ".PasswordLastUsed")

    # マークダウン形式で出力
    echo "| $ACCOUNT_ID | $USERNAME | $LAST_LOGIN |" >> $OUTPUT_FILE
  done
done

このスクリプトは、出力形式としてマークダウンを使用し、アカウント番号、IAMユーザー名、最終ログイン日を一覧表として出力します。
出力結果の例は下記です。

不要なIAMグループの特定

不要なIAMユーザー削除後に、再度アセスメントで使用した下記のスクリプトを実行します。

blog.serverworks.co.jp

スクリプト結果を確認すると、下記画像のようにIAMユーザーが紐づいていないIAMグループを簡単に見つけることができます。

不要なIAMロールの特定

ここではプログラムによって作られるAWSServiceRoleForから始まるIAMロール以外（IAMユーザーが作成したIAMロール）からIAMロール名と最終使用日をマークダウン形式で出力するスクリプトを作成しました。

#!/bin/bash

# スクリプト内でプロファイルを指定
PROFILES=("profile1" "profile2" .....)  # この配列に実際に使用するAWSプロファイル名を追加

# 出力ファイルの定義
OUTPUT_FILE="role-unused.md"

# マークダウンのヘッダー部分
echo "| Profile名 | IAMロール名 | 最終使用日 |" > $OUTPUT_FILE
echo "|---------|---------------|-----------|" >> $OUTPUT_FILE

for PROFILE in "${PROFILES[@]}"; do
    # `AWSServiceRoleFor`で始まらないIAMロールをリストアップし、そのロールの名前と最終使用日を取得
    aws iam list-roles --profile $PROFILE --query='Roles[?!(starts_with(RoleName,`AWSServiceRoleFor`))]' \
    | jq -r  '.[].RoleName' | xargs -I {} aws iam get-role --role-name {} --profile $PROFILE \
    | jq -r --arg profile "$PROFILE" '.Role | "| \($profile) | \(.RoleName) | \(.RoleLastUsed.LastUsedDate // "N/A") |"' >> $OUTPUT_FILE
done

下記画像のようにAWSServiceRoleForから始まるIAMロール以外の、IAMロール名と最終使用日が出力されます。
最終使用日等でソートして不要なIAMロールを特定してください。

不要なIAMポリシーの特定

ここではIAMユーザーが作成、かつ現在使用されていないIAMポリシーを特定します。
下記スクリプトを実行することで、IAMユーザーが作成、かつ現在使用されていないIAMポリシー（ユーザー、グループ、ロールに紐づいていないもの）をマークダウン形式で出力します。

#!/bin/bash

# スクリプト内でプロファイルを指定
PROFILES=("profile1" "profile2" ....)  # この配列に実際に使用するAWSプロファイル名を追加

# 出力ファイルの定義
OUTPUT_FILE="policy-unused.md"

# マークダウンのヘッダー部分
echo "| Profile名 | IAMポリシー名 | 作成日 |" > $OUTPUT_FILE
echo "|---------|---------------|-----------|" >> $OUTPUT_FILE

for PROFILE in "${PROFILES[@]}"; do
    # IAMユーザーが作成し、現在使用されていないIAMポリシーをリストアップ
    aws iam list-policies --profile $PROFILE --scope Local --query='Policies[?AttachmentCount==`0`]' \
    | jq -r --arg profile "$PROFILE" '.[] | "| \($profile) | \(.PolicyName) | \(.CreateDate) |"' >> $OUTPUT_FILE
done

下記画像のように、かつ現在使用されていないIAMポリシー（ユーザー、グループ、ロールに紐づいていないもの）をマークダウン形式で出力されます。

まとめ

長くなってしまいましたが、マルチアカウントへの権限集約のポイントと必要な移行ステップについてまとめさせてもらいました。
本ブログで移行ステップについて記載しましたが、不要なIAMユーザーを産まない仕組み等の運用も移行の段階で考える必要があります。

本記事が誰かの助けになれば幸いです。

日高 僚太(執筆記事の一覧)

EC部ソリューションアーキテクト2課 / AWS認定資格 12冠

2022年IT未経験で新卒入社しました。
最近はダーツとサウナが気になっています！
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp