1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【IBM Cloud】IBM Cloudでの監査ログの取得方法(Activity Tracker Event Routing)

Last updated at Posted at 2025-01-20

はじめに

2024年6月頃、IBM Cloudでは既存の監視ツールであるActivity Trackerの後継サービスであるIBM Cloud LogsをFrankfurtとMadridリージョンにGAし、2024年9月にはTokyoとOsakaリージョンでGAされました。
そのため、 今までのActivity Trackerインスタンスではなく、新たなCloud LogsおよびActivity Tracker Event Routingを使って監査ログを取得する方法を整理しました。

Cloud Logsとは?

IBM Cloud内外のシステムや、アプリケーションのログデータ・監査イベントの収集、管理ができます。
Activity Tracker Event Routingを使って監査ログをこのCloud Logsに転送、収集、表示させることができます。
image.png

特長

  • アプリやサービスのログ・監査イベントを一元的に保管・分析できる
  • 重要度に応じてログを効率的に管理・利用できる
  • ログの分析・構造化により検索・フィルター・分析が容易に
  • カスタマイズ可能なダッシュボードテンプレート
  • クエリ言語(Lucene、SQL、DataPrime)を利用したログの抽出が可能
  • ICOS(Object Storage)を利用したログの保管
  • Event Notificationsと連携し、重要なイベントやエラーのアラート通知が可能
  • Priority insights のログ・データ保管期間は7, 14,30, 60, 90日から選択可能

Activity Tracker Event Routingとは?

スクリーンショット 2024-10-02 17.23.00.png
Cloud LogsではプラットフォームログやAgentからのログをルーティングするLogs Routingと関西弁とをルーティングするEvent Routingの2種類があり、今回は前述の通り後者のEvent Routingについて整理しています。

繰り返しとなりますが、Event Routingとは、IBM Cloudサービスからの監査イベントを特定のインスタンス(Cloud Logs、Activity Trackerなど)に送信できるように設定する機能です。これによって、複数リージョンから発生するログを一つのインスタンスに集約することができます。

Activity Tracker Event Routingを介して管理できるイベントを生成するIBM Cloudサービスは、IBM Cloud services that generate events that are managed through Activity Tracker Event Routingに記載されていますのでご参考ください。

【補足】Activity Trackerは別物!

IBM Cloud Activity Trackerは、IBM Cloudでの作業の監査を行うためのサービスです。例えば、ユーザーを作成したとか、新しく設定を追加した、などの作業に対してAPIでの操作やポータルからの操作を問わず、履歴を残すことが可能です。これにより、不正な行為が行われていないかどかを確認することができます。
Activity Trackerについての概要はこちらの記事に詳しく紹介されていますのでご参考ください。

Activity Trackerは2025年3月30日でEOSされる予定です。
そのため、EOSまでに既存インスタンスのマイグレーションが必要となりますので、ご注意ください。

Activity Tracker Event RoutingはEOSにはなりません。
監査イベントを監視サービスへ転送するために、本記事の設定が必要です。

スクリーンショット 2025-02-04 16.04.13.png
Logs Routingとは、プラットフォームログや、Agentからのログを指定したCloud LogsやIBM Cloud Log Analysisにルーティング可能です。
詳しい設定の流れについては、こちらの記事をご参考ください。

構成手順

前提条件

今回の検証には以下を前提としています。

  • IBM Cloudのアカウント(無料利用可能)を持っている。
  • サービス間許可(S2S許可)がされていて(Event Routingだけではなく、Log Routingにも必要になります)、その際のアクセス権限付与対象に「すべてのリソース」を設定するため、管理者権限に近い権限が付与されている。
    • 詳細は本文に補足

全体的な構成の流れ(概要)

今回の監査ログ取得のためには、大きく以下の流れで操作します。
以下の内容はIBM Cloud Logsをターゲットとして設定するを参考に作成しています。

① 各インスタンスの作成(Object Storage、Cloud Logs)
② 作成したインスタンス間の接続のためのサービス間許可(S2S許可)の構成
③ 監査ログを収集するためのターゲット(送信元、送信先)の設定
④ 結果確認

監査ログを取得するために必要となるCloud Logsのインスタンスとイベント・ログデータの永続化のための保管ストレージとして必要なObject Storage(ICOS)インスタンスを作成します。その後、Cloud LogsとICOS間の接続のために、アクセス権限を付与するサービス間許可設定を行います。最後にターゲットとして予め作成した各インスタンスを指定して接続を完了し、結果を確認します。
スクリーンショット 2025-01-20 18.41.42.png

その詳細は以下に記載しています。

IBM Cloud Object Storage(ICOS)のインスタンス作成

まずは上記の通り、ログデータの永続化のためには保管ストレージとしてICOSが必要であるため、ICOSインスタンスを作成します。(今回はICOSから作成していますが、後に記載したCloud Logsインスタンスの作成手順から行っても問題ございません)
ICOS画面にてインスタンスの作成をクリックします。
スクリーンショット 2024-07-11 17.19.45.png
インフラの選択やインスタンス名、リソースグループなどの設定を行ってインスタンスを作成します。
FireShot Capture 008 - Cloud Object Storage - IBM Cloud - cloud.ibm.com.png

ICOSのインスタンスが作成されたら、次は「バケット」を作成します。
「バケット」とは、インタンス内で実際ログデータが保管される論理的区域であり、名前通りデータを入れておく箱のようなものとなります。

まずはバケットの作成をクリックします。
スクリーンショット 2024-07-11 17.20.23.png

Quick Startテンプレートを含め、複数のテンプレートが用意されていますが、今回はカスタムテンプレートにて作成しました。
スクリーンショット 2024-07-11 17.21.28.png

バケット名や可用性の設定、リージョン、Storage Tierなどを設定し、バケットを作成します。こちらの設定はバケット作成後には変更ができませんのでご注意ください。
なお、今回の検証を実施した際にはアカウントの制限上、フランクフルト(eu-de)リージョンで作成していますが、必要に応じて国内リージョンを含めロケーションを選択ください。
FireShot Capture 009 - Cloud Object Storage - IBM Cloud - cloud.ibm.com.png

Cloud Logsのインスタンス作成

次はログデータを集約するためのCloud Logsのインスタンスを作成します。(上記の通りICOSインスタンス作成との順番は前後して問題ございません)

コンソールでロギングインスタンスにアクセスすると、既存のLog Analysisに加え、Cloud Logsのカテゴリーが新たに表示されています。ここで作成をクリックします。
スクリーンショット 2024-07-11 17.04.31.png

また、リージョンはICOSと同様にフランクフルトに設定し、7日間の保管で作成しています。こちらの設定はご用件に応じて適宜可能です。
FireShot Capture 002 - Cloud Logs - IBM Cloud - cloud.ibm.com.png
スクリーンショット 2024-07-11 17.13.38.png

Cloud LogsとICOSを接続

ICOSのバケットが作成されたら、Cloud Logsからのログデータを永続的に保管するためにCloud LogsとICOSを間でマウントさせる必要があります。
Cloud Logsインスタンスのストレージタブに入ってメトリック・データ接続にて、使用するICOSのバケットとマウントします。なお、項目のログ・データはLog Analysisからのログを接続する項目となり、今回は使用しません。
スクリーンショット 2024-10-02 17.03.12.png

こちらの段階ではS2S許可が前提となります。もしS2S許可前の場合、サービス許可が必要ですという画面が表示されるケースがありますが、今すぐ許可をクリックするとインスタンスが表示されます。
スクリーンショット 2025-01-20 11.11.04.png

先ほど作成したICOSのインスタンスを検索し、使用するバケットを選択して接続します。
スクリーンショット 2024-07-11 17.52.50.png

【補足】S2S許可の流れ

上記の手順の通りICOSバケットを接続する際に許可を行うことも可能ですが、IBM Cloud IAMにて直接許可設定を行うことも可能です。詳しくは、S2Sを作成して IBM Cloud Logsにバケットへのアクセスを許可するをご参照ください。

まず、IBM Cloudコンソールにて、管理IAMをクリックします。
スクリーンショット 2025-01-20 17.14.10.png

IAMの画面が表示されたら、許可カテゴリーをクリックします。
スクリーンショット 2025-01-20 17.14.21.png

許可画面が表示されたら、アクセス権限を付与するために作成ボタンをクリックします。
スクリーンショット 2025-01-20 17.14.32.png

サービス許可を付与する画面が表示されたら、まずはソースの設定を行います。アクセス権限を付与するソース・アカウントを選択し、次へをクリックします。
スクリーンショット 2025-01-20 17.14.53.png

次はソース・サービスを選択しますが、検索欄にてCloud Logsを検索し選択します。その後、次へをクリックします。
スクリーンショット 2025-01-20 17.23.45.png

その後、アクセス権限の範囲を指定するソース・リソースを選択しますが、前提条件に記載した通り、すべてのリソースを選択し次へをクリックします。これで各ソース設定は完了です。
スクリーンショット 2025-01-20 17.25.07.png

次はターゲットを選択します。
ソースとして設定したCloud Logsからアクセスできるターゲットインスタンス(今回は前提の通りICOSになります)を選択するため、Object Storageを検索して選択します。その後次へをクリックします。
スクリーンショット 2025-01-20 17.15.44.png

ソース・リソースと同様、ターゲット・リソースもすべてのリソースを選択し次へをクリックします。
スクリーンショット 2025-01-20 17.15.55.png

最後にアクセス権限のレベルである「役割」を選択しますが、ここではリソース作成や編集が可能な管理者権限レベルの権限が必要です。今回はWriter権限を付与しています。役割を選択した後にレビューをクリックします。
スクリーンショット 2025-01-20 17.16.52.png

設定したソースとターゲットの許可を確認し、問題なければ許可ボタンにてアクセス権限を付与します。
スクリーンショット 2025-01-20 17.17.06.png

Cloud LogsとICOSのS2S許可の設定は以上です。

上記と同じ流れでActivity Tracker Event RoutingとCloud LogsのS2S許可も必要です。
詳しい流れはIBM Cloud Logsにデータを送信するアクセス権IBM Cloud Activity Tracker Event Routingに付与する S2Sを作成するをご参照ください。

ソースはActivity Tracker Event Routing、ターゲットはCloud Logsを選択し、許可をクリックすることで、Activity Tracker Event RoutingとCloud LogsのS2S許可設定は完了です。
スクリーンショット 2025-01-20 18.11.46.png

Activity Tracker Event Routingの設定

Activity Tracker Event RoutingとCloud LogsのS2S許可設定が完了したら、次は監査イベントの宛先や経路を設定します。

左メニューにあるActivity Trackerの「ルーティング」カテゴリーにアクセスします。
スクリーンショット 2024-07-23 16.15.07.png

経路タブにて、監査イベントを収集するアカウント内インスタンスを指定するため、作成ボタンにて経路を作成します。
スクリーンショット 2024-07-23 17.28.05.png

次に、経路のルート名やルーティング・ルールの送信元とターゲットなどを設定します。
送信元として、ワイルドカード、あるいはロケーションが選択できます。
ロケーションにはプラットフォーム・イベント(グローバル)かロケーション・ベースイベントを選択することができます。

グローバルイベントとは、IAM設定・ポータル操作やICOSなどの特定のサービスを起因としたイベント監査ログです。
グローバルイベントを生成するサービスについて、詳しくは以下Docsを参照ください。
IBM Cloud docs: グローバル・イベント

ロケーション・ベースのイベントは、IBM Cloud データ・センターの特定のロケーション (ダラスやフランクフルトなど) 内でホストされている IBM サービスによってアカウント内でアクティビティーが生成されたことを報告するものです。
ロケーション・ベースのイベントについて、以下Docsを参照ください。
IBM Cloud docs: ロケーション・ベースのイベント

ターゲットは監査イベントの使い方によって複数のタイプのターゲットを選択することができますが、今回はCloud Logsに表示させるための設定となるため、そのままCloud Logsを選択しています。
スクリーンショット 2024-07-23 17.28.16.png
スクリーンショット 2025-01-17 13.30.53.png

今回はグローバルイベント、ロケーションイベントを合わせた全てのログとして、ワイルドカードを選択しています。
スクリーンショット 2024-07-23 17.28.37.png

また、ターゲットタブにて監査イベントの収集場所を設定します。
作成ボタンにてターゲットを作成することができますが、タイプとしてはCloud LogsやObject Storageのインスタンスなどを選択することができますので適宜設定します。
今回はCloud Logsに表示させるため、予め作成したCloud Logsインスタンスを設定しています。
スクリーンショット 2024-07-23 17.24.48.png
スクリーンショット 2024-07-23 17.25.44.png

イベント・ログの確認

マイグレーション実行から少し時間が経ったら、最初デプロイしてCloud LogsとマウントしたICOSのバケットにデータが入ってきていることがわかります。
FireShot Capture 010 - Cloud Object Storage - IBM Cloud - cloud.ibm.com.png
また、Cloud Logsのダッシュボードを確認したら、デプロイした時間からのイベント・ログが記録されていることがわかります。
スクリーンショット 2024-07-11 20.38.24.png
スクリーンショット 2025-01-20 11.24.49.png
今回のEvent Routingにより、ibm-audit-eventbvtなどが追加され、Activity Trackerの監査イベント項目が確認できたら接続完了です。
表示されるログの内容についてはIBM Cloud Logs のアクティビティー・トラッキング・イベントに詳しく記載されているのでご参照ください。
スクリーンショット 2024-07-25 16.34.10.png
また、ログの詳しい見方についてはこちらの記事に詳しく紹介されているので、あわせてご参考ください。

参考

1
0
3

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
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?