SAP-C02-115 · セクション 13 / タスク 3.2
User / Service操作のTraceabilityを改善する
AWS CloudTrail / User Activity / Service Activity / API Call / Audit Trail / Centralized Logging / Traceability
CloudTrailを導入していても、
ログは存在する
でも
誰が実行したのか分からない
どのサービスが実行したのか分からない
どのAPIコールだったのか分からない
複数アカウントをまたぐ操作を追えないという状態では、十分な追跡可能性があるとはいえません。
既存環境では、
ログを収集しているかだけではなく、
監査やインシデント調査で
必要な質問へ答えられるかを確認します。
ゴール
既存環境について、
- ユーザー操作をCloudTrailから追跡する
- IAMロール経由の操作で元の主体を確認する
- AWSサービスによる操作を人の操作と区別する
- APIコールの内容・時刻・送信元・結果を確認する
- クロスアカウント操作を追跡する
- 必要な操作が監査証跡へ記録されているか確認する
- 集中ログ記録に必要な監査情報が揃っているか確認する
- ログの存在ではなく、調査可能性を基準に改善する
ことを目指します。
1. 追跡可能性は「ログがあること」ではない
例えば、本番環境の設定が変更されたとします。
監査では、
変更されただけでなく、
誰が？
いつ？
どの認証情報で？
どのAPIを？
どのアカウントで？
どのリージョンで？
どこから？
成功した？まで確認できることが重要です。
したがって、
CloudTrailログが保存されている
=
追跡可能性が十分ではありません。
目標は、発生した操作を主体・操作・時間・場所・結果まで関連付けられる状態です。
2. 最初に「監査で答える質問」を決める
既存環境を評価するときは、先にログ項目を眺めるのではなく、必要な監査質問を整理します。
例えば、
誰がIAMポリシーを変更した？
どのロールで実行した？
そのロールを使った元の主体は誰？
AWSサービスが自動で実行した操作か？
どのAPIコールだった？
どのAWSアカウントのリソースへ作用した？
どのIPアドレスから実行した？
失敗した操作か、成功した操作か？です。
その後、
必要な質問
↓
必要なCloudTrailイベント
↓
必要なイベントフィールド
↓
現在のログで答えられるかを確認します。
3. APIコールは複数のフィールドを組み合わせて読む
CloudTrailイベントでは、操作を1つのフィールドだけで判断しません。
代表的には、
userIdentity
→ 誰の認証情報か
eventTime
→ いつ
eventSource
→ どのAWSサービスか
eventName
→ どの操作か
awsRegion
→ どのリージョンか
sourceIPAddress
→ どこから
userAgent
→ どのクライアント系統から
requestParameters
→ 何を指定したか
responseElements
→ どのような結果を返したか
errorCode / errorMessage
→ 失敗した場合の情報を組み合わせます。
例えば、
eventSource
iam.amazonaws.com
eventName
AttachRolePolicyなら、IAMに対する AttachRolePolicy
APIコールだったと判断できます。
4. 「誰が実行したか」はuserIdentityを見る
ユーザー操作の追跡では、userIdentity
が中心になります。
CloudTrailでは、状況に応じて、
Root
IAMUser
AssumedRole
FederatedUser
IdentityCenterUser
AWSService
AWSAccountなどのIDタイプが記録されます。
したがって、eventNameだけ確認するのではなく、userIdentity
と eventName を関連付けます。
5. IAMロール名だけでは元の利用者を特定できない場合がある
例えば、多数の管理者が同じIAMロールを使用しているとします。
CloudTrailで、
AssumedRole
↓
AdminRoleと確認できても、
AdminRoleを使った
具体的な元の主体は誰かまで必ず分かるとは限りません。
そのため、ロールを利用する環境では、
ロール
↓
セッション
↓
元の主体を関連付けられる状態を確認します。
6. sourceIdentityで引き受けたロールの元の主体を残せる
AWS STSでロールを引き受けるとき、適切に構成していれば
sourceIdentity を記録できます。
利用者
↓
AssumeRole
↓
sourceIdentity
↓
IAMロール
↓
AWS APIコールその後にロールの一時的な認証情報でAWSサービスを操作した場合も、CloudTrailイベントのセッションコンテキストから
sourceIdentity を確認できます。
つまり、
AdminRoleが実行しただけでなく、
誰を起点とした
AdminRoleセッションなのかを追跡しやすくなります。
ただし、CloudTrailが元の主体を自動的に推測して付与するわけではありません。 元のID情報を引き継げる認証方式になっている必要があります。
7. IAM Identity Centerではユーザー名だけに依存しない
IAM Identity Centerが出力する対象CloudTrailイベントでは、
userIdentity
└─ onBehalfOf
├─ userId
└─ identityStoreArnから、操作の背後にいるIAM Identity Centerユーザーを識別できます。
現在の監査処理では、userNameが必ずあるはずという前提にしません。
IAM Identity Centerでは、userId と
identityStoreArn
を利用してユーザーを関連付けることが重要です。
8. AWSサービス自身が操作する場合もある
すべてのAPIコールが、人間によって直接実行されるとは限りません。
例えば、
利用者
↓
AWSサービス
↓
別のAWSサービスAPIを実行という処理があります。
CloudTrailでは、AWSサービスによるリクエストの場合、userIdentity
や invokedBy
などから、リクエストを実行したAWSサービスを確認できる場合があります。
例えば、
invokedBy
autoscaling.amazonaws.comなら、人が直接そのAPIを呼び出したのではなく、Amazon EC2 Auto Scalingによる操作である可能性を確認できます。
9. AWSサービスの操作を人の操作へ誤って帰属させない
例えば、IAMロールを使ったAPIコールというだけで、そのロールを作った人がそのAPIを直接実行したとは判断できません。
確認するのは、
userIdentity.type
sessionContext
sourceIdentity
invokedByなどです。
これによって、ユーザー自身の操作、引き受けたロールによる操作、AWSサービスによる操作を区別します。
10. AWSサービスイベントという形式もある
CloudTrailには、通常のAPIコールとは別に、eventType = AwsServiceEvent
となるサービスイベントがあります。
サービスイベントでは、serviceEventDetails
に、イベントを発生させた条件や結果に関する追加情報が含まれる場合があります。
したがって、すべてのCloudTrailイベントが人間が発行したAPIコールとは考えません。
11. sourceIPAddressも文脈を見て解釈する
sourceIPAddress
は、リクエスト元を調査する重要な情報です。
例えば、203.0.113.10
のようなIPアドレスが確認できれば、利用者の接続元調査へ利用できます。
しかしAWSサービスによる操作では、IPアドレスではなくAWSサービスを示す名前が記録される場合があります。
そのため、sourceIPAddress = 常に利用者端末のIP
とは判断しません。userIdentity や invokedBy
と組み合わせて確認します。
12. APIコールの成功・失敗も追跡する
監査では、APIを呼んだだけではなく、成功したのか失敗したのかも重要です。
イベントによっては、errorCode、errorMessage
から失敗内容を確認できます。
例えば、
DeleteTrail
↓
AccessDeniedなら、削除操作を試みたものの、成功していない可能性を確認できます。
したがって、操作イベントが存在することと変更が成功したことを同一視しません。
13. クロスアカウント操作では「実行したアカウント」と「受けたアカウント」を分ける
クロスアカウントアクセスでは、操作した主体のAWSアカウントと、操作対象リソースを所有するAWSアカウントが異なる場合があります。
CloudTrailでは、userIdentity.accountId と
recipientAccountId
が異なるイベントになる場合があります。
例えば、
アカウントA
↓
アカウントBのKMSキーを利用なら、誰が操作したかだけでなく、どのアカウントがその操作を受けたかまで確認します。
15. 監査証跡で最初に確認するのは「必要な操作が記録されているか」
どれだけCloudTrailイベントの読み方を知っていても、監査したい操作そのものが記録されていないなら追跡できません。
例えば、誰が機密データへアクセスしたかを監査したいのに、その操作が現在の記録対象に含まれていなければ、中央ログを検索するだけでは解決しません。
改善では、
監査要件
↓
必要な操作
↓
現在記録されている？を確認します。
イベント種別や記録方式そのものは既習の設計知識を利用します。
16. 集中ログ記録も「集めているか」だけでは不十分
複数アカウントのCloudTrailログを中央へ集約していても、
アカウントA
→ 必要イベントあり
アカウントB
→ 一部イベントなし
アカウントC
→ 別リージョンが欠落なら、組織全体の追跡可能性には穴があります。
したがって集中ログ記録では、中央に保存しているかだけでなく、必要なアカウント、必要なリージョン、必要な操作、必要なID情報が揃っているか確認します。
17. 中央化されていてもID情報が弱ければ追跡できない
例えば、100アカウントのログを中央ログアーカイブへ集約していても、多数のユーザーが同じロールを使用し、元の主体を関連付けられないなら、「誰が実行したか」という監査質問には十分に答えられません。
つまり追跡可能性は、
イベントの記録範囲
+
主体を識別する情報
+
中央集約
+
検索可能性の組み合わせで考えます。
18. CloudTrailログを「処理の順番そのもの」と考えない
CloudTrailログファイルは、アプリケーションの順番どおりのスタックトレースではありません。
イベントがログ内に並んでいる順番だけを根拠に、Aの直後にBがあるから必ずAがBを発生させたとは判断しません。
調査では、eventTime、eventID、requestID、ID情報、対象リソース、必要に応じてsharedEventIDなどを利用して関連付けます。
19. 代表的な追跡可能性の欠落
共有ロールしか分からない
AdminRoleが操作までは確認できるが、元の利用者を関連付けられない。
→ ID情報の引き継ぎを改善します。
AWSサービス操作を人の操作として扱う
AWSサービスによるAPIコールなのに、ロール名だけを見て人の操作と判断する。
→ userIdentity や invokedBy
を確認します。
中央ログはあるが必要イベントがない
ログアーカイブ自体は存在するが、監査対象操作が記録されていない。
→ 記録対象を監査要件へ合わせます。
1つのアカウントだけで調査を終える
クロスアカウント操作なのに、呼び出し側だけ、または受信側だけしか確認しない。
→ 実行主体と受信アカウントを関連付けます。
20. 追跡可能性を改善する手順
1. 監査で答える質問を定義
↓
2. 必要な操作を特定
↓
3. 現在記録されているか確認
↓
4. userIdentityを確認
↓
5. ロール利用時は
元の主体を追えるか確認
↓
6. AWSサービス操作を区別
↓
7. API / 時刻 / リージョン /
接続元 / 結果を確認
↓
8. クロスアカウントなら
両側の情報を関連付け
↓
9. 中央ログへ必要情報が
揃っているか確認
↓
10. 実際の監査シナリオで
検索・追跡できるか検証21. 混同しやすいポイント
| 誤りやすい判断 | 正しい考え方 |
|---|---|
| CloudTrailを使っているので追跡可能性は十分 | 必要な監査質問へ答えられるか確認 |
| IAMロール名が分かれば元の人も分かる | 元の主体を示すID情報が必要な場合がある |
sourceIPAddress は常に人の端末IP |
AWSサービスによるリクエストでは異なる場合がある |
| CloudTrailイベントがあるので操作は成功した | errorCode 等も確認 |
| APIコールはすべてユーザーが直接実行 | AWSサービスが実行する操作もある |
| 中央ログへ集約すればすべて追跡可能 | イベントの記録範囲とID情報も必要 |
| ログファイルの行順 = 操作の因果順 | 時刻・ID・リクエスト情報などで関連付ける |
| クロスアカウント操作は1つのアカウントだけ見ればよい | 実行主体側と対象側を関連付ける |
22. SAP-C02での判断手順
問題文で、CloudTrailは有効だが、誰が変更したか分からない、サービス操作とユーザー操作を区別できない、複数アカウントの操作を追えない、とあれば、
必要な操作は
記録されている？
↓
誰の認証情報？
↓
IAMロールなら
元の主体を追える？
↓
AWSサービスによる操作？
↓
どのAPI？
↓
どの時刻？
↓
どのリージョン？
↓
どこから？
↓
成功した？
↓
どのアカウントが受けた？
↓
中央で横断的に調査できる？と確認します。
決定打は、ログ量を増やすことではなく、ユーザー・サービス・APIコールを一貫して関連付けられる監査証跡を作ることです。
まとめ
追跡可能性の改善では、
監査質問
↓
記録対象
↓
ユーザー / サービスID
↓
APIコール
↓
時刻 / リージョン / 接続元
↓
成功 / 失敗
↓
クロスアカウント関係
↓
集中ログ記録
↓
実際に追跡できるか検証という順序で考えます。
重要なのは、
CloudTrailがある
≠
十分に追跡できる
IAMロールが分かる
≠
元の利用者まで分かる
イベントがある
≠
操作が成功した
中央ログがある
≠
必要な監査証跡が完全という点です。
AWS CloudTrailを、単なるログ保存先ではなく、ユーザーとAWSサービスの操作を監査可能な形で関連付ける証跡として評価します。
主要AWS公式資料
- AWS Certified Solutions Architect - Professional (SAP-C02) — Domain 3 / Task 3.2
- AWS CloudTrail — CloudTrailイベント
- AWS CloudTrail — CloudTrailイベントレコードの内容
- AWS CloudTrail — userIdentity要素
- AWS IAM Identity Center — CloudTrailユースケース
- AWS CloudTrail — 組織の証跡