AWS アクセス監視を CloudTrail と CloudWatch で行う

はじめに

今回はAWS アクセス監視として CloudTrail と CloudWatch を使った監視方法について解説します。

CloudTrail とは

AWS 上で行われた操作をすべて記録するサービスです。「誰が・いつ・どのリソースに・何をしたか」が記録されます。

SSH はポートに直接接続するため操作ログが残りませんでしたが、SSM に移行したことで接続のたびに CloudTrail に記録が残るようになりました。

CloudTrail で SSM 接続ログを確認する

イベント履歴を開く

AWSコンソール
→ CloudTrail（サービス検索で「CloudTrail」）
→ 左メニュー「イベント履歴」

StartSession でフィルターをかける

デフォルトでは、自動ログが大量に表示されます。これはインスタンスが定期的に「生きています」と AWS に報告しているだけの自動ログで正常な動作です。

接続ログだけを確認するには以下でフィルターをかけます。

ルックアップ属性: イベント名
値: StartSession
→ 検索

確認できる内容

項目	内容
イベント時間	いつ接続したか
ユーザー名	誰が接続したか
リソース名	どのインスタンスに接続したか
ソースIPアドレス	どこから接続したか

正常な状態の見方

• 自分が登録した IAM ユーザー（例: hoge-ssm）のみ表示される
• AWSコンソールから接続した場合は自分の IAM ユーザーで記録される

hoge-ssm はローカルのターミナルから alias コマンドで接続したときの記録です。自分のユーザー名はAWSコンソールのブラウザから接続したときの記録です。どちらも SSM 経由ですが接続経路が違うので別ユーザーとして記録されます。

不正アクセスを検知するポイント

□ 知らない IAM ユーザー名が出ていないか
□ 知らい IP アドレスからの接続がないか
□ 深夜など業務時間外の接続がないか

CloudWatch で CPU スパイクのアラームを設定する

SSH 閉鎖の効果を確認するために CPUUtilization（CPU 使用率）の監視アラームを設定します。

メトリクスの種類と使い分け

メトリクス	意味	今回の用途
CPUUtilization	CPU 使用率（%）	スパイク検知に使う
CPUCreditBalance	貯まっているCPUクレジット残高	t系インスタンスのバースト残量確認
CPUCreditUsage	消費したCPUクレジット量	バーストをどれだけ使ったか
CPUSurplusCreditBalance	クレジット枯渇後の借り分	超過使用の確認

CPU スパイクの監視には CPUUtilization を使います。

アラームの設定手順

AWSコンソール
→ CloudWatch
→ 左メニュー「アラーム」→「アラームの作成」
→「メトリクスの選択」
→ EC2 → インスタンス別のメトリクス
→ 対象インスタンスの CPUUtilization を選択
→「メトリクスと条件の指定」

条件の設定

しきい値の種類: 静的
アラーム条件: 以上（>=）
しきい値: 30
データポイント: 5分間のうち 3 回以上

今回僕のスパイクは 45〜50% まで上昇していたので、30% をしきい値にすることで余裕を持って検知できます。

通知の設定

→「次へ」
→ アラーム状態トリガー: アラーム状態
→「新しいトピックの作成」
→ トピック名: hoge-alert
→ 通知先メールアドレスを入力
→「トピックの作成」
→「次へ」

アラーム名の設定

アラーム名: hoge-alert
説明: hoge CPU 30% 超過アラート（SSH閉鎖後の監視）
→「次へ」→「アラームの作成」

設定後の確認

CloudWatch
→「アラーム」
→ 作成したアラームが「データ不足」または「OK」になっていれば設定完了

監視の運用方針

僕の場合 SSH 閉鎖後 1ヶ月間 CloudWatch で以下を監視します。

確認項目	監視方法	判断基準
CPU スパイクが解消されたか	CloudWatch CPUUtilization	特定の% 超のアラートが来なくなる
不正な接続試行がないか	CloudTrail StartSession	知らないユーザー・IP が出ない
SSM 経由の接続のみになっているか	CloudTrail StartSession	SSH の記録が存在しない

まとめ

SSH から SSM に移行したことで操作ログが自動で残るようになり、不正アクセスの検知がしやすくなりました。CloudWatch のアラームと合わせて 1ヶ月監視し、CPU スパイクの原因が SSH スキャンだったかどうかを確認していきます。