アクセスキーが漏洩して甚大な被害に及んだ、というセキュリティニュースは本当によく耳にします。
攻撃者は常にアクセスキーを狙っていると言っても過言ではないかもしれません。
今や人間が永続アクセスキーを持つこと自体がリスクとなっています。
このリスクを低減するために有効な AWS サービスが IAM Identity Center です。
AWS アカウントへの接続目的で触ってみましたのでご紹介します。
本記事は、IAM Identity Center と AWS Organizations を整理していくシリーズの入口の位置付けです。
シリーズ記事
IAM Identity Center
- IAM Identity Center 簡単セットアップ
- IAM Identity Center のインスタンスとは？リージョンはどう影響する？
- IAM Identity Center 設計は AWS アカウント構成から順に考える
- IAM Identity Center での AWS CLI ログインを最速化する
- IAM Identity Center の推奨認証方式はなぜ推奨なのか
AWS Organizations
- クレジット付きアカウントを AWS Organizations に統合したい
- なぜ AWS Organizations で作ったアカウントはルート設定不要なのか？
- AWS Organizations の管理アカウントは何のためにあるのか
- SCP の抜け漏れをどう防ぐか ― 公式サンプルの 6 観点で学び直した話
0. 背景
個人の AWS アカウントに CLI で繋ぎたいからアクセスキー発行しようかなー。
詳細はこちら のリンク
To avoid security risks, don't use IAM users for authentication when developing purpose-built software or working with real data. Instead, use federation with an identity provider such as AWS IAM Identity Center.
超意訳
セキュリティエンジニアなら、IAM ユーザーなんて作らずに IAM Identity Center でできるよね？？
そう、IAM ユーザーからアクセスキーを払い出すことは、AWS のベストプラクティスに沿っていないのです。
入手したら即その権限を使用できる永続クレデンシャルを人間が管理することは、現在では推奨されない設計になっています。
そこで IAM Identity Center を利用します。
1. IAM Identity Center とは
AWS IAM Identity Center とはなんでしょうか？
IAM Identity Center は、フェデレーションを前提としたアクセス管理の仕組みです。
ユーザーが AWS コンソールや AWS CLI、さらには AWS 上で動作する各種アプリケーション (Kiro など) へのログインに利用できます。
また以下のような特徴があります。
- ユーザーや AWS アカウントが増えても権限を管理しやすい
- 監査ログを残しやすい
- SSO でログインの利便性を高められる
都度 AWS アカウントログイン用に一時クレデンシャルが払い出されるため、永続的なアクセスキーと比べてセキュリティリスクは低いと言えます。
有効期限付きのクレデンシャルであるため、万が一漏洩した場合に影響範囲を限定できるためです。
Identity Center ではこのような「人間に永続クレデンシャルを持たせない設計」が前提になっています。
2. 実際にこう変わる
コンソールログイン
IAM ユーザー
AWS マネジメントコンソールの画面から、AWS アカウント ID、ユーザー名、パスワード、MFA などを入力してログインします。
手軽ではありますが、ログインするアカウント数が増えると、比例してユーザー、パスワード、MFA 管理も増えます。
IAM Identity Center
AWS access portal の画面から、ユーザー名、パスワード、MFA などを入力してポータルにログインします。
対象アカウントの対象ロール (許可セット) をクリックして AWS アカウントにログインします。
1 つの ID で複数の AWS アカウントへのログインを設定できます。
CLI
IAM ユーザー
IAM ユーザーを作成し、クレデンシャルを取得した後、AWS CLI の aws configure --profile で認証情報そのものを設定します。
裏側では credential と config ファイルに各種情報が書き込まれます。
アカウントの数だけ、保管するクレデンシャル情報が増えていきます。
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
[user1]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
[default]
region=us-west-2
output=json
[profile user1]
region=us-east-1
output=text
IAM Identity Center
AWS CLI の aws configure sso で認証に必要な情報を設定します。
SSO セッション情報と、ログインプロファイルの情報の 2 種類を登録します。
ローカルに長期保存されるのはアクセスキーではなく、SSO セッション情報という点が、IAM ユーザーとの大きな違いです。
[profile my-dev-profile]
sso_session = my-sso
sso_account_id = 123456789011
sso_role_name = readOnly
region = us-west-2
output = json
[sso-session my-sso]
sso_region = us-east-1
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access
その後 aws sso login --profile コマンドで、対象アカウントの対象ロール (許可セット) に接続します。
3. 導入の流れ、ハマりポイント
実際導入してみると、あれこれポイントがありました。
追ってご紹介します。
→ シリーズ記事として冒頭に移動しました。
まとめ
アクセスキー前提の運用から、フェデレーション前提の設計へ。
その第一歩が IAM Identity Center です。
次回以降、IAM Identity Center の内部構造や AWS Organizations との関係について、順に整理していきます。
大切なインフラはセキュアに管理・運用していきたいものですね。
今日も小さな学びを。