こんにちは、臼田です。
みなさん、GuardDutyで脅威検出してますか？(挨拶
今回は、GuardDuty Findingsの詳細を確認していくシリーズです。SAMLで利用しているユーザーの情報をGuardDutyがどのように拾ってくるかを確認します。
概要
GuardDutyのFindingsでは、IAMタイプなどのAPI実行ユーザーの情報を必要とするものがあります。インシデントがあった際、その操作者のアイデンティティを確認することができます。
しかし、一口にアイデンティティといっても、AWS上ではIAM UserとIAM Roleなどがあり、さらにIAM Roleの場合には人が利用したりサービスが利用したり、同じRoleが複数のエンティティから利用されたりするため特定の個人に紐づけられないことがあるなど、バラエティがあります。
というわけで、今回はOktaを利用した場合にGuardDuty上ではどのようにアイデンティティを取得するのか確認してみました。
ちなみにOktaとのSAML連携は事前にされている状態から始めます。Oktaとの連携は以下のブログやこのあたりのドキュメントを参考にしてください。
やってみた
まずOktaのユーザーでマネジメントコンソールにアクセスして、以下のブログなど適当なGuardDutyの検出を出します。
しばらくすると検出するので確認してみましょう。詳細値は置き換えていますが、マネジメントコンソール上ではUser nameの値がIAM Role名となっているため、共通のIAM Roleを利用している場合には操作者を特定できません。一方でPrincipal IDはコロン以降にOktaユーザーのメールアドレスが付加されているため、こちらを用いれば適切に操作者を識別できそうです。
Findingsのjsonデータは以下のようになっています。
"Resource": {
"AccessKeyDetails": {
"AccessKeyId": "ASIAXXXXXXXXXXXXXXXX",
"PrincipalId": "AROAXXXXXXXXXXXXXXXXX:test-user@example.com",
"UserName": "okta-admin-role",
"UserType": "AssumedRole"
},
"ResourceType": "AccessKey"
},つまりResource.AccessKeyDetails.PrincipalIdを取得してあげればOKということですね。必要に応じてコロン以降だけ抽出するといいでしょう。
おまけ: CloudTrailのログ
CloudTrailではGuardDutyと違うフォーマットになっていますので一緒に確認してみます。
jsonでは以下のようになっています。
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAXXXXXXXXXXXXXXXXX:test-user@example.com",
"arn": "arn:aws:sts::999999999999:assumed-role/okta-admin-role/test-user@example.com",
"accountId": "999999999999",
"accessKeyId": "ASIAXXXXXXXXXXXXXXXX",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAXXXXXXXXXXXXXXXXX",
"arn": "arn:aws:iam::999999999999:role/okta-admin-role",
"accountId": "999999999999",
"userName": "okta-admin-role"
},
"attributes": {
"creationDate": "2024-03-11T12:46:55Z",
"mfaAuthenticated": "false"
}
}
},通常IAM Roleのユーザーを確認する場合にはsessionContext.sessionIssuer.userNameを確認していきますが、そもそもsessionContext内は活用できません。principalIdをGuardDutyと同じようにコロン以降だけ抽出することになります。
まとめ
SAML利用時にGuardDuty検出結果がどのようになるか確認しました。
IAMの種類が色々ある場合にはそれぞれのリソースタイプに合わせて値を抽出しましょう。
12
