0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

S3のログにCloudWatchLogsのAlarmを設定する(コンソール編)

Last updated at Posted at 2021-12-30

はじめに

VPCの不正トラフィックにアラームを設定する方法を、コンソールCloudFormationの2手法で記事にしましたが、今回はS3のログに同様のことを行う方法を記事にしました。

目的

S3に置いた機密情報が、想定外の取得をされていないか、がわかる環境の構築を目的としました。
悪意あるサービス等からの取得があったら、すぐにメール通知が飛ぶ、という環境がゴールのイメージです。

S3を監視するサービス

調べたところ、以下がありました。

2つある、S3アクセスログ

参考にしたページなどからの情報によると、以下のような違いがありそうです。

CloudTrail使用 サーバアクセスログ
料金 少し掛かる 安価
改ざん防止 可能 不可
出力先 CloudWatch
S3
S3
監視対象バケット 全て
任意(複数)
任意(1つ)
アクセス元がわかるか sourceIPAddress Remote IP
プロキシやFW経由だと実際のアドレスが不明確になる)とあり

アラームを送信することまでを目的としているため、CloudWatchに出力できる方が良いです。
S3だと、Athenaを作って、Lambda等で周期的に不正トラフィックの有無を取得するSelect文を流して、SNSで通知、という作りこみが必要になりそうです。
また改ざん防止やアクセス元の特定の用途から、CloudTrailの方法を用いました。

標準のメトリクスではダメ?

標準機能として、CloudWatchメトリクスがありますが、使ってみたところ出来合いのメトリクスであり、”特定のアクセス元(以外)からのアクセス数”のような細かい内容での検出は出来なそうでした。

これだけでは不十分

ここで行うことは”検出”だけで、不正アクセスを未然に防ぐことはできません。
IAMポリシーやバケットポリシーを適切に設定する必要があります。

やったこと

コンソールから、以下のことを行いました。

  1. 監視するバケットの作成
  2. CloudTrailで、証跡の作成
    1. 保存先S3バケットは、操作の中で作成できます。
    2. CloudWathLogsのロググループも、操作の中で作成できます。
    3. IAMロールも、操作の中で作成できます。
  3. CloudWatchLogsから、メトリクスの作成
  4. アラームの作成
    1. 作成時に、SNSトピックも作成できます。

構成

image.png

実際の手順

監視するバケットの作成

普通にバケットを作成します。
image.png

CloudTrailで、証跡の作成

[CloudTrail]-[証跡]から、[証跡の作成]をクリック。

image.png

image.png

  • 証跡名
    • 任意の名前で。
  • ストレージの場所
    • 今回は新しく作ります
  • 証跡ログバケット及びフォルダ
    • 自動でバケット名が入ります
    • フォルダまで指定できますが、末尾のスラッシュ(/)はつけないでください。
      • 作成されるバケットポリシーで、リソースに指定する出力先バケットのパスのスラッシュが重複してしまいます。
      • 下部の「ログはxxxxに保存されます」を見て問題ないか確認ください。
  • ログファイルの SSE-KMS 暗号化
    • 今回は無効で。
  • ログファイルの検証
    • 有効にしました。
  • SNS 通知の配信
    • 無効にしました。

image.png

  • CloudWatch Logs
    • 有効
  • ロググループ
    • 今回は新規としました。
  • ロググループ名
    • 任意で。
  • IAMロール
    • 新規に作ります。
  • ロール名
    • 任意で。

image.png

  • イベントタイプ
    • データイベントのみ選択。

image.png

  • [基本的なイベントセレクターに切り替えます]をクリックします。

image.png

  • データイベントソース
    • S3を選択。
  • S3バケット
    • 現在および将来のすべての S3 バケットの”読み取り”と”書き込み”のチェックを外す。
      • 今回は、作成したバケットのみを監視します。
      • こちらを使うと、「他の証跡の出力先バケットのログ」や「自身の出力先バケットのログ」も対象になるようです。
    • 個々のバケットの選択
      • 監視するバケットを指定して、”読み取り”と”書き込み”のチェックを入れる。

[次へ]-[証跡の作成]で完了です。

CloudWatchLogsから、メトリクスの作成

VPCフローログの際の作業と同じですので省略します。
フィルターパターンは前回と異なりJSON形式のログなので、公式を参考に作成します。

# GetObject、かつ送信データが1KBを超えるアクセス
{ ($.eventName = "GetObject") && ($.additionalEventData.bytesTransferredOut > 1000 )}

# VPCエンドポイントを経由していないアクセス
{ ($.vpcEndpointId NOT EXISTS) }
# { ($.vpcEndpointId = "" ) } や { ($.vpcEndpointId IS NULL ) }はダメでした。

# 特定のIP以外からのアクセス
{ ($.sourceIPAddress!="123.123.123.123") }

# GetObject、かつ送信データが1KBを超え、特定のIP以外またはVPCエンドポイント以外のアクセス
{ ($.eventName = "GetObject") && ($.additionalEventData.bytesTransferredOut > 1000 ) && ( ($.sourceIPAddress!="123.123.123.123") && ( ($.vpcEndpointId != "vpce-xxxxxxxx" ) || ($.vpcEndpointId NOT EXISTS) ) ) }
# 多分あっている、はず

アラームの作成

こちらもVPCフローログの際と同じになりますので省略します。

作成したアラームが動くかチェック

作った構成が機能するか確かめます。

  • 1KBのファイルをアップし、CloudShell(決められたIP以外)から、GetObjectしました。
    • 結構待ちます。
      • 公式によると、15分以内といっています。

CloudTrail は、通常、API コールから平均 15 分以内にログを配信します。この時間は保証されません。

アラームが飛ぶと、以下のようになりました。

image.png

片づけ

  • アラームの削除
    • [CloudWatch]-[すべてのアラーム]から、作成したアラームをチェックし、[アクション]-[削除]。
  • SNSの削除
    • [Amazon SNS]-[トピック]-[(作成したトピック)]をクリックして、"サブスクリプション"から対象のアドレスを選択し、削除。
    • その後、対象のトピックを削除。
  • メトリクスフィルターの削除
    • 対象のメトリクスフィルターの右上にチェックをして、削除。
  • 証跡の削除
    • [CloudTrail]-[証跡]から、作成した証跡をチェックし、削除。
  • S3の削除
    • 監視対象バケット、および保存先バケットを両方とも空にして削除します。
  • IAMロールの削除
    • 作成されたロールを選択し、削除。
  • ロググループの削除
    • [CloudWatch]-[ロググループ]から、作成したロググループを選択し、[アクション]-[ロググループの削除]。
  • メトリクスの削除は・・・

課題

  • VPCエンドポイント経由以外のアクセスをフィルタから除外する方法
    • パブリック経由のアクセス
    • パブリックサービスからのアクセス
      • Athena、Lambda、Glue等
    • コンソールからのアクセス

見たところ、以下のようなことが確認できました。
見落とし、見間違いあると思われますので、ご自身で確認ください。

サービス vpcEndpointId sourceIPAddress その他
パブリック経由のEC2 なし パブリックIP
コンソールからのアクセス ない? 接続元のIP
CloudShellからのアクセス なし AWSのIP範囲のうち、region=="ap-northeast-1" service=="AMAZON"のIPか?
Athenaからのアクセス なし "athena.amazonaws.com"` がセット テーブル名は見当たらない(見落としたかも?)
Lambdaからのアクセス なし AWSのIP範囲のうち、region=="ap-northeast-1" service=="EC2"のIPか? ・userAgentにAWS_Lambda_python3.9 の文字列あり
・$.userIdentity.sessionContext.sessionIssuer.userNameに、関数名あり

これらを除外するフィルターを作るのは難しそうです。VPC内部からのアクセスに出来るのであれば、そちらが楽かもしれません。

まとめ

「S3ログから不正アクセスを検出」というテーマで環境を構築する方法をまとめました。
次はCloudFormationを用いて作る方法を記事にしたいと思います。
CloudFormationを用いた記事はこちらになります。

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?