SCP を利用して IAM Identity Center ユーザーの権限を即座に剥奪してみた

IAM Identity Center を利用している Organizations 環境で、AWS の認証情報が漏洩した時のことについて調べてみました。

IAM Identity Center で AWS 権限を不正取得された場合にどうするか

GuardDuty 等を利用することで、 AWS 権限の不正利用が疑われる場合は検知可能です。
ただ、検知された時にどうするかまできちんとシミュレーションできていない方もいらっしゃるのではないでしょうか？
特に IAM Idnetity Center を利用している場合は即座に対応できそうな手段が複数あります。

• パスワードをリセット
• アクティブなセッションの削除
• ユーザー無効化
• ユーザーと権限セットの割当てを解除する
• ユーザー削除

結論からいうと、即座に権限を取り消したい場合は上記方法はいずれも効果がありません。
これらの方法は、 IAM Identity Center で設定したセッション期間が切れるまで既に作成された一時クレデンシャルを利用した操作を禁止することはできないからです。
一見「アクティブなセッションの削除」と「パスワードをリセット」の組み合わせは効果がありそうですが、ここでのセッションは AWS access portal(IAM Identity Center から各マネジメントコンソールにログインするためのポータル)のセッションを指しており、各アカウントへアクセスするための一時クレデンシャルには影響を与えません。

Modifying the AWS access portal session duration and terminating AWS access portal sessions have no effect on the AWS Management Console session duration that you define in your permission sets.
Manage IAM Identity Center integrated application sessions

ではどうすれば良いのかという話になりますが、SCP を使うことで即座に権限を剥奪することができます。
こちらの方法については下記 AWS Security Blog に記載されています。

IAM ポリシーは各リクエストの度に評価されるため、SCP で上から権限を剥奪してしまえば即座に操作を止めることができるというわけですね。
ちなみに IAM User の場合は、ユーザー削除で即座に権限を奪うことが可能です。

IAM Identity Center の場合は、許可セットに紐づく IAM Role(AWSReservedSSO_XXX) が IAM Identity Center のユーザー削除では消えない所が問題になります。
許可セットごと消してしまえば良いのですが、マルチアカウント環境で許可セットを消すのは影響が大きく、復旧も面倒です。
また、許可セットに紐づく IAM Role でアクティブなセッションを無効化することもできません。
こちらは既に発行済みのトークンによる操作を禁止するポリシーを挿入してくれる機能ですが、AWS が管理する IAM Role を直接無効化しようとすると、this role is only modifiable by AWS と怒られます。

IAM Identity Center 側から許可セットに手動で同様のポリシーを追加することも可能ですが、一つのユーザーに複数の許可セットが結びついている場合は面倒ですし、現状はセキュリティブログの内容に基づいて SCP で実施するのが良いかと思います。(許可セットの変更も影響は十分大きいので...)
例外として、組織の管理アカウントへアクセスできる認証情報が漏洩した場合は許可セットを直接修正する必要があります。
この辺りも考えると、組織の管理アカウントへ権限できるユーザーは絞るべきと改めて認識させられますね。

権限を剥奪してみた

実際に SCP で権限を剥奪してみます。
今回は test-user で AWS の権限が奪われたと仮定します。 こちらのユーザーで事前にコマンドを実行して、権限があることを確かめておきます。

$ aws ec2 describe-instances
{
    "Reservations": []
}

認証情報の漏洩が疑われるユーザーを特定する際は、GuardDuty が活用できます。
例えば Discovery:S3/AnomalousBehavior が検知されていた場合を考えると Principal ID が xxxxxxxxxxx:IAM Identity Centerのユーザー名 という形で確認できます。
今回漏洩が疑われるユーザーは test-user なので、こちらの操作を禁止するポリシーを作成します。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Deny",
			"Action": "*",
			"Resource": "*",
			"Condition": {
				"StringLike": {
					"aws:userid": [
						"*:test-user"
				]
			}
		}
	},
	{
			"Effect": "Deny",
			"Action": "*",
			"Resource": "*",
			"Condition": {
				"StringEquals": {
					"aws:SourceIdentity": [
						"test-user"
					]
				}
			}
		}
	]
}

AWS Organizations のコンソールからサービスコントロールポリシーを選択します。

ポリシーを作成をクリックします。

ポリシー名を入力して、先程作成したポリシーを貼り付けます。

Root に作成したポリシーをアタッチします。

再度先程と同じコマンドを実行した所、即座に権限を剥奪できていることを確認できました。

$ aws ec2 describe-instances
An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation.

復旧する際もセッションが切れたことを確認してから、パスワードをリセットしてポリシーをデタッチするだけなので簡単です。

まとめ

焦っている時に SCP や許可セットを修正するのは怖いので、 IAM Identity Center 側からボタンひとつで revoke できると嬉しいなと思ったりしましたが、現状は上記手順が最適解になるかと思います。
もしもの時のことをきちんと想定してシミュレーションしておきましょう。