こんにちは。k.sasakiです。
Oracle Cloud Infrastructure Advent Calendar 2023のDay16記事です。
タイトルの元ネタの本や映画は一切見ていません。

本日は、OCIにおけるイベント通知のパターンそれぞれについて簡単に説明し、その後、OCI監査ログに対してログ監視を設定し、Monitoringでアラームを設定するという手順を紹介します。検証環境がまだIDCS統合前のため、IAMユーザのログイン失敗を扱いますが、IDCS統合後のテナンシでログイン失敗を抽出する条件も記事の最後に記載します。

OCI上のイベントに対して通知を出す場合の構成パターン

OCIで特定のイベントが発生した際に通知を行う場合、いくつか手段が提供されています。

• パターン1 Eventsのイベントルールでイベントを検知して通知する方法
• パターン2 Cloud Guardのディテクタレシピでイベント検知してEventsに連携する方法
• パターン3 Loggingのログから文字列を検知して通知する方法
• パターン4 Loggingのログから文字列を検知してMonitoringに連携する方法

今回はパターン4について扱いますが、その前にそれぞれの違いについて説明します。

パターン1 Eventsのイベントルールで検知して通知する方法

イベントルールで特定のイベントを条件に指定し、アクションとしてNotificationsへ連携するパターンです。

通知メールの本文にはイベントデータとしてイベントが発生したリソース情報が含まれますが、操作者の情報は含まれません。

手間が少なく、単にイベントを通知させたいというだけであれば、ほとんどのケースで有効です。

パターン2 Cloud Guardのディテクタレシピでイベント検知してEventsに連携する方法

Cloud Guard上で、ディテクタレシピにてイベントを検知し、レスポンダレシピでイベントを発行します。後はパターン１と同様にEvetnsのイベントルールを設定して、Notificationsへ連携します。

イベントによっては、操作者の情報が通知メールに含まれます。ディテクタレシピで定義されているイベントのみが検知可能となるため、使用したい場合は確認が必要です。

コンポーネントが多くなり、Cloud Guardの運用が発生するので、パターン1とくらべると敷居が高いかもしれません。

パターン3 Loggingのログから文字列を検知して通知する方法

OCIのイベントは監査ログにも含まれる（はず）ので、Logging上の監査ログに対してServiceConnectorHubで文字列を条件とするフィルタを作成して、Notificationsに連携します。

メール本文にはRAWデータ（JSONデータ）か、フォーマットされたデータ(表＋JSONデータ)を選択することができます。

該当の監査ログのJSONが通知メール本文に含まれるため、操作者の情報も記載されますが、情報量が多くて読みづらいです。せめて表の部分に操作者の情報も入れてくれればもっと使いやすいのですが。。

通知のみが目的であればパターン1でよいため、あえてパターン3を選択する理由はないでしょう。

パターン4 Loggingのログから文字列を検知してMonitoringに連携する方法

パターン4はServiceConnectorHubからMonitoringに連携します。
Monitoringではアラームとして細かい条件の指定や、抑止なども可能なので、より幅広い要件に対応することができます。

通知メール上はイベントデータは含まれないので、メトリクス名やアラーム名などでどのイベントに対してのアラームであるのかを識別できるように設計が必要となります。

Loggingのログから文字列を検知してMonitoringに連携する

ここから本題のパターン4の詳細について説明します。環境は、IDCS統合前テナンシーでMFAを有効にしたIAMユーザのログイン失敗のイベントを対象とします。

ログイン失敗イベントの文字列を確認する

まず、ログイン失敗時にどういうイベントが発生するのか、確認する必要があります。

Eventsのドキュメントを参照するのが良いのですが、悲しいことに、認証失敗といったイベントの情報は記載が確認できません。

• Eventsサービス　IAMの生成するイベントに認証系のイベントはない。
  https://docs.oracle.com/ja-jp/iaas/Content/Events/Reference/eventsproducers.htm#iam-events

ServiceConnectorHubに設定する条件を調査するため、考えうるログイン失敗のパターンを実際に試してみて、監査ログ上のイベントを確認したので、主要なフィールドとともに記載します。

ログイン成功パターン

ログイン成功の場合は、パスワード認証の成功のイベントと、MFA認証の成功のイベントの2つが記録されます。

• パスワード認証成功

data.type: "com.oraclecloud.IdentitySignOn.InteractiveLogin"
data.eventName : "InteractiveLogin"
data.message : "InteractiveLogin succeeded"
data.response.payload.login_result : ""Successfully authenticated user""
data.response.status : "200"

• MFA認証成功

data.type: com.oraclecloud.IdentitySignOn.VerifyMFAToken
data.eventName : "VerifyMFAToken"
data.message : "VerifyMFAToken succeeded" 
data.response.payload.login_result : "MFA verification successful"
data.response.status:"200"

ログイン失敗パターン

パスワード認証の失敗と、MFA認証の失敗においては4種類のログの出力を確認しました。元となる情報がないので全てのパターンとは言えませんが、主要なパターンは網羅できていると思います。

• パスワード認証失敗 パスワード間違い or パスワード設定前

data.type: "com.oraclecloud.IdentitySignOn.InteractiveLogin"
data.eventName : "InteractiveLogin"
data.message : "InteractiveLogin failed"
data.response.payload.login_result : "PASSWORD_INVALID"
data.response.status : "400"

• パスワード認証失敗 ユーザロック中

data.type: "com.oraclecloud.IdentitySignOn.InteractiveLogin"
data.eventName : "InteractiveLogin"
data.message : "InteractiveLogin failed"
data.response.payload.login_result : "USER_BLOCKED"
data.response.status : "400"

• パスワード認証失敗 存在しないユーザ or ユーザ削除済み

data.type: "com.oraclecloud.IdentitySignOn.InteractiveLogin"
data.eventName : "InteractiveLogin"
data.message : "InteractiveLogin failed"
data.response.payload.login_result : "unresolved user"
data.response.status : "400"

• MFA認証失敗 古いコード or コード誤り

data.type: "com.oraclecloud.IdentitySignOn.VerifyMFAToken"
data.eventName : "VerifyMFAToken"
data.message : "VerifyMFAToken failed" 
data.response.payload.login_result : "Client error: Incorrect mfa code"
data.response.status:"401"

条件の抽出

各イベントの出力より、ある程度共通化されていそうな data.type + data.messageの値を条件として採用することとしました。

ServiceConnectorHub設定

ServiceConnectorHubで条件を指定する際に、過去6時間のログを検索して、条件に一致するログがあるかチェックしてくれる機能があるので、ログイン失敗の操作をしてから、設定を進めることをおすすめします。

LoggingのメニューからServiceConnectorHubを作成します。今回のリソースは全てルートコンパートメントに作成します。

• リソース名

リソース名は以下に設定します。説明欄は適当に入力します。

Log2Mon2(iam_login_failure)

• サービス・コネクタの構成

ソースとターゲットのサービスで設定項目が変わります。

ロギング　 から　モニタリング

• ソースの構成
  プルダウンから選択して条件を作っていきます。
  今回対象とするログイン失敗のイベントはルートコンパートメントのみで発生するので、ルートコンパートメントの監査ログのみを対象にします。

ソース接続の構成

コンパートメント：ルート
ログ・グループ：_Audit
（"サブコンパートメントに_Auditを含める"のチェックボックスはチェックしない）

ログフィルタに、ログの検索条件を指定します。イベント・タイプや属性名はプルダウンで選択肢が出てきますが、属性値は新規入力が必要となります。

ログフィルタ・タスク

フィルタタイプ : イベント・タイプ
サービス名：Identity SignOn
イベント・タイプ：
 Interactive Login
 Verify MFA Token

フィルタタイプ：属性
属性名：data.message
属性値：
 InteractiveLogin failed
 VerifyMFAToken failed

ソースの構成の画面で、過去6時間のログのヒット数を表示してくれます。

• タスク構成

不要

• ターゲットの構成

ここでMonitoring側のリソースについて設定します。ネームスペース名やメトリクス名について新規に設定します。

同じように監査ログからServiceConectorHubで連携する際に共通で利用する用途とするため、ネームスペース名は"audit_log"とし、メトリクス名は今回作成する条件に対応する"IAM_Login_Failure"とします。

コンパートメント : ルートコンパートメント
ネームスペース: audit_log
メトリクス名: IAM_Login_Failure

• ディメンション設定

ディメンションとして、特定のフィールドを指定することができます。
今回ログイン失敗の種類は4種類あり、このエラーの種類ごとに集計できるとアラームの定義の際に幅が出るので、"login_result"を指定しました。（仕様上、ここではlogContentからの指定が必要です。）

なお、"パスの選択"画面でログレコードを開くと、フィールドの一覧が出てきて、チェックボックスを入れてディメンションとして指定することができます。

パスの編集

ディメンション名：login_result
値: logdata.response.payload.login_result

• ポリシーの作成

初めて作る場合は下記の画像のようにポリシー作成ボタンが出ますので、、作成ボタンを押して作ってしまうのがおすすめです。（画像はポリシー作成ボタンを出すため、ルート以外のコンパートメントにしています。）

ただし、ポリシー名を指定できないので、ステートメントをコピーして別の管理しやすいポリシー名で作り直しましょう。ステートメントは下記となりした。

(テナンシIDは..以降省略)
allow any-user to use metrics in compartment id ocid1.tenancy.. where all {request.principal.type='serviceconnector', target.metrics.namespace='audit_log', request.principal.compartment.id='ocid1.tenancy.oc1..'}

• ServiceConnectorHubの設定反映

以上で、ServiceConnectorHubの設定項目を全て埋めたので、作成ボタンを押してリソースを作成します。

注意点としては、作成したServiceConnectorHubを編集ボタンから開くとディメンションの追加画面でエラーが表示されることを確認しました。条件を重ねたため、フィルタに指定したクエリが拡張モードで表示されてしまうことが原因のようです。編集する場合は作り直してもいいかもしれません。

情報として設定から自動的に作成したログフィルタの内容を記載します。

(テナンシIDは..以降省略)
search "ocid1.tenancy.oc1../_Audit" | (type='com.oraclecloud.identitysignon.interactivelogin' or type='com.oraclecloud.identitysignon.verifymfatoken') and (data.message='InteractiveLogin failed' or data.message='VerifyMFAToken failed')

メトリクスの表示確認

ネームスペースの作成し、OCIコンソールからアクセスが可能になるまで時間がかかります。検証環境では、実際にログイン失敗のイベントを起こして、30分程度経つとOCIコンソールで確認できるようになりました。

今回作成したLog2Mon2(iam_login_failure)というServiceConnectorHubのリソース詳細画面からリンクでメトリクスに遷移できます。

メトリクスの画面が開いたら"Query"の下矢印を開くことで4種類のデータポイントが存在することが確認できます。これはディメンションで"login_result"を追加指定したため、"login_result"の4種類の各値ごとに判別できたとうことです。

グラフから表の表示に切り替えることができます。こちらの方がわかりやすいですね。

アラーム設定はOCIチュートリアルなど参照のこと

あとは、このメトリクスに対してアラームを設定するという流れになります。特別な手順はないので、アラーム設定以降はOCIチュートリアルでご確認をお願いします。

モニタリング機能でOCIのリソースを監視する

おわりに

以上で、ServicecConnectorHubからMonitoringに連携する方法について解説しました。さらにいくつか余談として記載しますので、ご興味のある方は最後までご覧ください。

みなさん良いお年を。

余談 パターン4で検出されたログレコード数より、Monitoringのデータポイント数が多い

メトリクスで統計を"Sum"(または"Count")とすることで、時間あたりのデータポイント数の合計値に切り替えることができます。

この合計数について、実際の監査ログのレコード数と一致するかを確認したところ、ログのレコード数よりも件数が多い状況が一時的に確認できました。

ServiceConnectorHub側のログを取得して確認したのですが、再現しなくなってしまいましたので、原因について確認できていません。見る限りは、ログ上はログのレコード件数だけデータポイントを出力しているようなのです。一部レコードについて複数回検知された〜という可能性があります。
ログのレコード数よりデータポイント数が少なくなるケースは確認できませんでしたので、SumやConutで集計した値より、ログレコード数が少ないケースがあるという点は留意が必要です。

余談 IDCS統合済みのテナンシでログイン失敗の通知を行う場合

ほとんどのテナンシがIDCSに統合を近々完了すると思われますので、同じくパターン4での構成する場合、ServiceConnectorHubのログクエリを以下の条件を指定してください。

(テナンシIDは..以降省略)
search "ocid1.tenancy.oc1../_Audit" | (type='com.oraclecloud.Identitysignon.Interactivelogin') and (data.additionalDetails.eventId = 'sso.authentication.failure')

既存のIDCSユーザの出力に寄せたらしく、IDCS統合済みのテナンシでは"sso.authentication.failure"というeventidでイベントを拾うことができます。data.messageのフィールドで、MFAのパスコードNGやパスワード認証NGも、ロック中のアクセスなどの識別ができますが、data.messageの文章量が多く、Monitoring画面で表示しきれないため、ディメンションの追加はお勧めしません。特定イベントに絞る場合は、data.messageの値も含めてServiceConnectorHub側で条件を絞ると良いでしょう。

余談 その他のパターン

他のパターンについての記事も見つけたのでまとめておきます。

• Notificationsではなく、EmailDeliveryを使用して通知する方法

Notifications使いたくないケース用？

OCIモニタリングでのOracle Cloud Infrastructure Eventsの電子メール通知の設定

• EventからFunctionsに連携してFunctionsからMonitoringに連携する方法

パターン4の方が簡単です。

OCI Monitoringでの電子メール対応のOCIイベント通知

ちなみにEvents--> Notifications だと、Base64エンコード済みのJSONが含まれる通知が届くので、電子メール通知には不向きです。