Okta システムログを EventBridge のパートナーイベントソース経由で CloudWatch Logs にストリーミングする
Okta システムログのエクスポートについて
Okta 内の各イベントは 90 日間システムログとして保持されますが、それ以上保持したい場合は外部に連携して保持する必要があります。
Okta でのイベントの保持期間は 90 日間です。
https://help.okta.com/ja-jp/content/topics/reports/syslog-filters.htm
90 日以上保存する必要があり、AWS を保存先として考えた場合、下記 3 通りの方針が存在します。
① EventBridge → CloudWatch Logs (Okta システムログを EventBridge のパートナーイベントソース経由で CloudWatch Logs にストリーミングする)
② EventBridge → Data Firehose → S3 (Okta システムログを EventBridge のパートナーイベントソース経由で S3 にストリーミングする)
③ CloudWatch マネージド 3rd パーティコネクタ (マネージド 3rd パーティコネクタで CloudWatch ログに連携)
Okta は EventBridge のパートナーイベントソースに対応しているため、システムイベントを EventBridge のイベントとして受け入れることが可能です。
イベントとして受け入れてしまえば、EventBridge ルール経由で S3 でも CloudWatch ログでも好きな所に保存できます。
その上で CloudWatch Logs Insights を利用した分析の手軽さやサブスクリプションフィルターを利用したリアルタイム検知を重視するなら CloudWatch ログ、コストを重視するなら S3 に保存するのが良いでしょう。
「③ マネージド 3rd パーティコネクタ」は、re:Invent 2025 で追加された新機能で CloudWatch 側から Okta 側にデータを取りに行く挙動になります。
この方法のメリットはマネージドなパイプライン機能を利用できることで、コードレスで Open Cybersecurity Schema Framework 形式に変換することが可能です。
料金に関して整理すると下図のようになります。
※ S3 に対する GET 料金や CloudWatch Logs Insights のクエリ料金など運用上他にも課金が発生するポイントはありますが、一旦考慮外としています。また全ての構成でログを gzip 等で圧縮して保存可能ですが、一旦考慮外とします。
EventBridge 料金
CloudWatch ログ料金
S3 料金
Data Firehose 料金
EventBridge をパートナーイベントソースとして構成した場合は 1USD/100 万イベントの料金が発生する一方で 3rd パーティコネクタは無料で利用できることは着目に値します。
とはいえ、基本的には CloudWatch ログの取り込み料金や保存料金の方が大きくなるはずなので、この点はそれほど大きなメリットにはなり辛いかなと思います。
コストから考えると低い方から「② EventBridge → Data Firehose → S3」、「③ CloudWatch マネージド 3rd パーティコネクタ」、「① EventBridge → CloudWatch Logs」の順になりそうです。
後は Okta の利用頻度や利用ユーザーからコスト感を見積もって CloudWatch を利用できるかを判断すると良いと思います。
一番高いと思われる「① EventBridge → CloudWatch Logs」において、システムログが平均 2KB、ユーザー数は 200 人、1 人 1 日あたり 500 イベントを生成するとします。
システムログは 3 年保持する前提で常に 3 年分のデータが CloudWatch Logs に溜まっている想定とすると、ざっくり下記のような月額料金になります。
月間イベント数：200 × 500 × 30 ≒ 3000000 (イベント)
月間データサイズ：3000000 × 2(KB) ≒ 6 (GB)
月額料金：3000000 ÷ 1000000 × 1 + 6 × 0.76 + 6 × 36 × 0.033 ≒ 3 + 4.56 + 7.128 ≒ 14.7 USD
1 ユーザーあたりの平均イベント数にほぼ根拠が無いので机上の計算も良い所ですが、休日が存在することや Okta の利用頻度もユーザー次第と考えると、最初から正確に試算することはほぼ不可能だと思います。
そうなると Okta 側からログイベント数を確認するか、一旦ログを出力してみながら確認する他ありません。
一方で、分析や環境構築の手軽さで言えば明確に 「① EventBridge → CloudWatch Logs」と「③ CloudWatch マネージド 3rd パーティコネクタ」に軍配が上がります。
S3 と Athena で分析を行おうとした場合、パーティションを扱うための設定も面倒ですし、Data Firehose から S3 に配信する際に上手く 5KB 以上にしつつ改行して配置するといった設計が必要です。
そのため、今後のログ量が見積もり辛く、特別こだわりが無い場合、「① EventBridge → CloudWatch Logs」で始めるのが良いと思っています。
パートナーイベントソース経由で EventBridge ルールに連携しておけば、ターゲットの切り替えのみで 「② EventBridge → Data Firehose → S3」 にも変更できます。
CloudWatch Logs Insights を利用した分析をしながら、特定イベントを S3 に後から振り分けるような手法も可能です。
実際にやってみる
「① EventBridge → CloudWatch Logs」のパターンを試してみます。
Okta のログストリーミング設定
Okta の管理コンソールにログインして、レポート > ログストリーミング から「ログストリームを追加」をクリックします。
タイプとして AWS EventBridge を選択して「次へ」をクリックします。
連携するアカウント ID やリージョンなどを設定して、「保存」をクリックします。
パートナーイベントソースと EventBridge バスの関連付け
EventBridge のサービスページで 統合 > パートナーイベントソース に移動して、「イベントバスを関連付ける」をクリックします。
「関連付ける」をクリックします。
EventBridge ルールの作成
Okta のシステムイベントが連携されるようになったので、作成されたイベントバスに EventBridge ルールを作成していきます。
「ルールを作成」をクリックします。
ルール名を入力して「次へ」をクリックします。
今回は特に絞らず全てのイベントを CloudWatch ログに連携する設定とします。
ターゲットとして、CloudWatch ログを指定します。
既存のロググループを選択する場合はリソースポリシーの設定を忘れないようにして下さい。
今回は新しいロググループを作成しているので、自動で設定されます。
タグは特に設定せずに「次へ」をクリックします。
内容を確認して「ルールを作成」をクリックします。
分析してみる
ここまで設定が完了すると CloudWatch ログにログが連携されます。
「Logs Insights で表示」をクリックして分析してみます。
まずイベントタイプ別に回数を集計していみます。
fields @timestamp, detail.eventType
| stats count() as event_count by detail.eventType
| sort event_count desc
失敗したイベントの数と種類を集計してみます。
fields @timestamp, detail.eventType, detail.outcome.result, detail.outcome.reason
| filter detail.outcome.result = "FAILURE"
| stats count() as failure_count by detail.eventType, detail.outcome.reason
| sort failure_count desc
最後に
Okta システムログを EventBridge のパートナーイベントソース経由で CloudWatch Logs にストリーミングする案、良いんじゃないでしょうか！
手軽に分析を始められて、ログ量が増えて料金が気になり始めたら Data Firehose → S3 構成に変更しやすい点も非常に魅力的だと思います。
