AWS Config ルールの自動修復を利用して一定期間未利用の IAM ユーザーを無効化してみた
2024.06.26AWS Config ルールと Systems Manager オートメーションを組み合わせることで、指定した日数利用されていない IAM ユーザーのコンソールパスワードとアクセスキーを無効化することができます。
AWS Config ルールには AWS が管理しているマネージドルールとユーザーが作成するカスタムルールがありますが、一定期間利用されていない IAM ユーザーの検出はマネージドルールで実現できます。そのルールを利用して検出した非準拠の IAM ユーザーのコンソールパスワードとアクセスキーを無効化する自動修復も AWS 管理の Systems Manager オートメーションランブックとして提供されています。そのため、一連の仕組みを AWS 提供の機能を用いて実現できます。
本ブログでは、検証目的で 5 日間以上利用していない IAM ユーザーのコンソールパスワードを無効化してみます。
未利用の IAM ユーザーの無効化
事前準備として、下記 2 種類の IAM ユーザーを作成しています。
2 つの IAM ユーザーは共にコンソールパスワードとアクセスキーを持ちます。コンソールに最後にサインインした日に違いがあります。アクセスキーは両方とも 24 時間以内に利用した状態にしています。
| IAM ユーザー名 | コンソールに最終サインインした日 | アクセスキーを最終利用した日 |
|---|---|---|
| test-user-20240613 | 11 日前 | 24 時間以内 |
| test-user-20240624 | 24 時間以内 | 24 時間以内 |
以降では、これらの IAM ユーザーに対して未利用期間が 5 日以上のクレデンシャルを持つ IAM ユーザーを非準拠にする例とその自動修復を試してみます。
Config ルールの作成
利用するマネージドルール名は「iam-user-unused-credentials」です。指定した日数で使用されていないコンソールパスワードまたはアクティブなアクセスキーがあるかどうかを確認するルールです。
iam-user-unused-credentials- チェック - AWS Config
AWS Config の「ルール」メニューから「ルールの作成」を実行して作成します。
ルールタイプの選択は「AWS によって管理されるルールの追加」を選択し、さらに「iam-user-unused-credentials-check」を選択して次へ進みます。
パラメータとして非準拠とするクレデンシャルの未利用期間を指定します。今回は検証目的のため 5 日を指定しています。
次の画面に進み、設定内容を確認してから実行すると Config ルールの設定は完了です。
作成完了後は、作成したルールを選択することで評価結果を確認できます。test-user-20240613はコンソールにサインインした日が 11 日以上前なので非準拠となっています。一方で、test-user-20240624はコンソールパスワードとアクセスキーの両方を 24 時間以内に利用しているため準拠となっています。
なお、Config ルールが多数あり、作成したルールを探しにくい場合は Config ルール名を含めた URL でもアクセスできます。今回の場合のルール名は「iam-user-unused-credentials-check」であり、次の URL でアクセスできます。
https://ap-northeast-1.console.aws.amazon.com/config/home?region=ap-northeast-1#/rules/details?configRuleName=iam-user-unused-credentials-check
以上で、Config ルールを用いた一定期間未利用のクレデンシャルを持つ IAM ユーザーの評価は終わりです。IAM ユーザーの無効化までは自動化せずに、このまま定期的に確認する運用もできます。
Config ルールの自動修復の設定
次に、Systems Manager オートメーションを利用して、上記で作成した AWS Config ルールにおいて非準拠となった IAM ユーザーを自動で無効化する仕組みを構築してみます。
IAM ユーザーの無効化は AWS が管理しているランブック「AWSConfigRemediation-RevokeUnusedIAMUserCredentials」を利用できます。パラメータで指定した日数利用されていないコンソールパスワードとアクセスキーを無効化（非アクティブ化）します。
AWSConfigRemediation-RevokeUnusedIAMUserCredentials - AWS Systems Manager オートメーションランブックリファレンス
事前準備として、Systems Manager オートメーションが利用する IAM ロールを作成します。
まずは、下記の内容で IAM ロールにアタッチする IAM ポリシーを作成します。利用するアクションはランブックのユーザーガイド（上記の URL）に記載れているため、それを参考に設定しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"config:ListDiscoveredResources",
"ssm:GetAutomationExecution",
"iam:DeleteAccessKey",
"ssm:StartAutomationExecution",
"iam:GetAccessKeyLastUsed",
"iam:UpdateAccessKey",
"iam:GetUser",
"iam:GetLoginProfile",
"iam:DeleteLoginProfile",
"iam:ListAccessKeys"
],
"Resource": "*"
}
]
}
作成した IAM ポリシーをアタッチした IAM ロールを作成します。IAM ロール名は任意の名前でよいです。その際に信頼ポリシーは Systems Manager を信頼する下記内容を指定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
自動修復は、作成した Config ルールの確認画面において「アクション」→「修復の管理」から設定します。
今回は自動で修復したいため「自動修復」を選択し、修復アクションとして「AWSConfigRemediation-RevokeUnusedIAMUserCredentials」を指定します。
リソース ID パラメータはIAMResourceIdを指定します。この設定により、非準拠となった IAM ユーザーのリソース ID をオートメーションに渡すことができます。パラメータのAutomationAssumeRoleには事前に作成した IAM ロールの ARN を指定します。クレデンシャルの未利用期間を指定するMaxCredentialUsageAgeは Config ルールで設定した日数と合わせて 5 日を設定します。他の設定は、今回の検証ではデフォルトにしています。
最後に「変更を保存」すれば設定完了です。
Config ルールのページにも修復アクション設定が反映されていることを確認できました。
Config ルールのページから「アクション」→「再評価」をしてみます。
しばらくすると非準拠の IAM ユーザーにおいて、アクションの実行がキューに入り、実行される状況を確認できました。
修復アクションが実行された IAM ユーザーを確認したところ、コンソールパスワードは想定通り無効になっていました。24 時間に利用していたアクセスキーは Active のまま存在しています。アクセスキーも 5 日以上利用していなかった場合は削除されると思われます。コンソールパスワードとアクセスキーを組み合わせて利用している環境の場合は、本修復アクションの導入前に想定パターンで検証しておいた方がよさそうです。もしくは、何かあればすぐに対処できる手動修復も候補となるかもしれません。
改めて事前に作成した IAM ユーザーを確認したところ、24 時間以内にアクセスしていたtest-user-20240624のコンソールパスワードは削除されておらず、「パスワードが作成されてから経過した期間」が表示されていました。
修復アクションで利用している Systems Manager オートメーションの実行結果は Systems Manager からも確認できます。ステータスがSuccessであることから正常に実行されていたことが分かります。
以上で、Config ルールの自動修復のお試しは終わりです。
さいごに
AWS Config のマネージドルールと AWS 管理の Systems Manager オートメーションランブックを利用して、一定期間使用されていない IAM ユーザーのコンソールパスワードを無効化する仕組みを試してみました。アクセスキーの無効化までは試していませんが、導入した場合はアクセスキーの無効化も実行されると思われるため、事前にユースケースに応じた検証はした方がよさそうです。
今回は IAM ユーザーの無効化を試しましたが、IAM ユーザーを削除するランブックも提供されています。
AWSConfigRemediation-DeleteIAMUser - AWS Systems Manager オートメーションランブックリファレンス
また、自動で修復するのではなく、手動で修復をキックすることもできます。
以上、このブログがどなたかのご参考になれば幸いです。
