OceanBase logo

OceanBase

トランザクション処理、分析、AIワークロードに最適な分散データベース

デプロイを自由に

OceanBase Cloud

OceanBaseの導入とスケーリングを最適化

エンタープライズ版

自社インフラ上での運用・管理に対応

オープンソース版を試す

コミュニティ版

開発者向けオープンソース分散データベース

OceanBase seekdb

AIネイティブなオープンソースの検索データベース

顧客事例

さまざまな業界の企業による導入事例を紹介します。

さらに見る
利用シーン別

あらゆるシナリオに対応するOLTP

ハイブリッドクラウドソリューション

大容量ストレージデータベースのコスト削減

リアルタイム分析混合ワークロード

複数インスタンスの統合

ドキュメント

会社概要

OceanBaseの企業情報、パートナーシップ、そして信頼性・セキュリティへの取り組みについて紹介します。

OceanBaseについて

法的情報

お問い合わせ

日本 - 日本語
International - English
中国站 - 简体中文
クラウドで始める

トランザクション処理、分析、AIワークロードに最適な分散データベース

デプロイを自由に

OceanBase Cloud

OceanBaseの導入とスケーリングを最適化

エンタープライズ版

自社インフラ上での運用・管理に対応

オープンソース版を試す

コミュニティ版

開発者向けオープンソース分散データベース

OceanBase seekdb

AIネイティブなオープンソースの検索データベース

顧客事例

さまざまな業界の企業による導入事例を紹介します。

さらに見る
利用シーン別

あらゆるシナリオに対応するOLTP

ハイブリッドクラウドソリューション

大容量ストレージデータベースのコスト削減

リアルタイム分析混合ワークロード

複数インスタンスの統合

OceanBaseの企業情報、パートナーシップ、そして信頼性・セキュリティへの取り組みについて紹介します。

OceanBaseについて

法的情報

お問い合わせ

クラウドで始める
编组
すべての製品
    • データベース
    • アイコンOceanBaseデータベース
アイコン

OceanBaseデータベース

V4.3.5

    OceanBase logo

    AI時代を支える分散データベース

    日本 - 日本語
    International - English
    中国站 - 简体中文
    プロダクト
    OceanBase Cloudエンタープライズ版コミュニティ版OceanBase seekdb
    会社概要
    OceanBaseについて法的情報お問い合わせ
    公式アカウント
    ConnpassXQiitaLumaGitHub

    © OceanBase 2026. All rights reserved

    クラウドサービス契約個人情報保護ポリシーセキュリティ
    お問い合わせ
    ドキュメントフィードバック
    1. ホーム
    2. OceanBaseデータベース
    3. V4.3.5
    アイコンOceanBaseデータベース
    V 4.3.5
    • V 4.3.5

    セキュリティ監査の有効化

    最終更新日:2026-04-09 02:53:56  更新
    シェア
    このページの内容
    監査範囲
    制限事項と注意点
    フィルターの作成
    構文
    例
    フィルターの設定
    構文
    例
    監査の有効化

    折りたたみ

    シェア

    一連のフィルターを通じて、特定のイベントに対するセキュリティ監査を実現します。

    適用対象

    この内容はOceanBaseデータベースEnterprise Editionにのみ適用されます。OceanBaseデータベースCommunity Editionは現在、監査機能をサポートしていません。

    監査範囲

    フィルターでフィルタリングできる次元には、アカウント、イベントタイプ、イベント属性などが含まれます。各フィルターでは、フィルタリングされたイベントを監査するかどうかを選択できます。

    制限事項と注意点

    • 式は、SELECT ステートメントの出力列(つまりselect item)に直接かつ一意に配置する必要があり、親式(parent expr)の制限はありません。
    • 式をサブクエリ内に記述することはできません。
    • フィルターを定義した後、ユーザーに設定して初めて最終的に有効になります。
    • フィルターとユーザーは1対多の関係にあり、つまり1つのフィルターを複数のユーザーに設定でき、1人のユーザーには1つのフィルターしか設定できません。
    • 接続を確立する際に、現在のセッションがどの監査フィルター(Audit Filter)を使用するかが決定され、そのセッションのライフサイクル全体で変更されることはありません。

    フィルターの作成

    フィルターを作成することでMySQLテナントの監査モードを有効にします。フィルターは監査イベントタイプに対する選択的なフィルタリングをサポートしており、現在ではすべてのイベントを記録、すべてのイベントを記録しない、ログイン・ログアウトのみを記録という3種類の選択肢があります。

    構文

    AUDIT_LOG_FILTER_SET_FILTER関数(式)を使用してフィルターを作成します。コマンドは以下のとおりです:

    AUDIT_LOG_FILTER_SET_FILTER('filter_name', 'definition_of_filters');
    

    各フィールドの説明は以下のとおりです:

    フィールド 説明
    filter_name フィルター名を指定します。

    説明

    AUDIT_LOG_FILTER_SET_FILTERはCREATE OR REPLACEのセマンティクスであり、既存のオブジェクトに対してDDLを実行すると上書きされます。

    definition_of_filters 監査フィルターの具体的な設定を定義するために使用され、JSON形式で表現されます。現在のバージョンのフィルター設計原則はMySQLと互換性がありますが、監査イベントタイプのみをフィルタリングできます。

    現在、フィルター設定の作成にサポートされているタイプは以下のとおりです:

    • すべてのイベントを記録します。

      {
      "filter": {
          "log": true
      }
      }
      

      または

      {
      "filter": {
          "log": true,
          "class": [
          { "name": "connection" },
          { "name": "general" },
          { "name": "table_access" }
          ]
      }
      }
      
    • すべてのイベントを記録しません。

      {
      "filter": {
          "log": false
      }
      }
      
    • ログインとログアウトのみを記録します。

       {
      "filter": {
          "log": true,
          "class": [
          { "name": "connection" }
          ]
      }
      }
      

    監査イベントの分類は以下のとおりです:

    イベントタイプ 説明
    connection ログインおよびログアウト。
    table_access DMLステートメント。
    general コマンドステートメント、パーサー失敗。

    例

    すべてのイベントを記録するフィルターlog_allを作成します。

    obclient [test]>SELECT AUDIT_LOG_FILTER_SET_FILTER('log_all', '{ "filter": { "log": true } }');
    
    • DDLが正常に実行された場合、式はOK返します。

      +-------------------------------------------------------------------------+
      | AUDIT_LOG_FILTER_SET_FILTER('log_all', '{ "filter": { "log": true } }') |
      +-------------------------------------------------------------------------+
      | OK                                                                      |
      +-------------------------------------------------------------------------+
      1 row in set
      
    • DDLが失敗した場合、SELECTステートメントは依然として正常に実行され、式の出力結果はエラーメッセージです。

      obclient [test]>SELECT AUDIT_LOG_FILTER_SET_FILTER('log_err', '1');
      

      実行結果は次のとおりです:

      +---------------------------------------------+
      | AUDIT_LOG_FILTER_SET_FILTER('log_err', '1') |
      +---------------------------------------------+
      | ERROR: JSON parsing error.                  |
      +---------------------------------------------+
      1 row in set
      

    mysql.audit_log_filterビューを使用して監査フィルターの定義を表示します。

    obclient [test]> select * from mysql.audit_log_filter;
    

    実行結果は次のとおりです:

    +---------+-------------------------------+
    | NAME    | FILTER                        |
    +---------+-------------------------------+
    | log_all | { "filter": { "log": true } } |
    +---------+-------------------------------+
    1 row in set (0.003 sec)
    

    各フィールドの説明は以下のとおりです:

    フィールド名 説明
    NAME フィルター名
    FILTER フィルター定義

    フィルターの設定

    フィルターを設定して対応するユーザーに付与した後、バックグラウンドスレッドは監査ログを出力できます。

    構文

    AUDIT_LOG_FILTER_SET_USER関数(式)を使用して、ユーザーにフィルターを設定します。

    AUDIT_LOG_FILTER_SET_USER('user_name', 'filter_name');
    

    各項目の説明は以下のとおりです:

    フィールド 説明
    user_name ユーザー名を指定するために使用されます。

    説明

    AUDIT_LOG_FILTER_SET_USERで指定されるuser@hostは、既存のユーザーである必要はありません。ワイルドカードや存在しないユーザーを指定することも可能です。存在しないユーザーを指定した場合、ログイン監査時に機能します。user_nameには以下の制限があります:

    • userはフィールド全体に対するワイルドカード、すなわち%のみをサポートしています。
    • hostフィールドやtest_%という部分ワイルドカードの指定はサポートされていません。hostまたはtest_%を指定した場合、フィルターを作成できません。

    filter_name フィルター名を指定するために使用されます。

    説明

    AUDIT_LOG_FILTER_SET_USERはCREATE OR REPLACEセマンティクスであり、既存のオブジェクトに対するDDL実行では上書きされます。指定されたfilter_nameが存在しない場合、DDLは有効になりませんが、エラーも報告されません。

    例

    フィルター log_all をユーザー user001 に設定します。

    obclient [test]> SELECT AUDIT_LOG_FILTER_SET_USER('user001', 'log_all');
    
    • DDL実行が成功した場合、式は OK を返します。

      +-------------------------------------------------+
      | AUDIT_LOG_FILTER_SET_USER('user001', 'log_all') |
      +-------------------------------------------------+
      | OK                                              |
      +-------------------------------------------------+
      1 row in set
      
    • DDL実行が失敗した場合でも、SELECT ステートメントは正常に実行され、式の出力結果はエラーメッセージとなります。

      obclient [test]>SELECT AUDIT_LOG_FILTER_SET_USER('log_err', '1');
      

      実行結果は次のとおりです:

      +--------------------------------------------+
      | AUDIT_LOG_FILTER_SET_USER('log_err', '1')  |
      +--------------------------------------------+
      | ERROR: Invalid character in the user name. |
      +--------------------------------------------+
      1 row in set (0.001 sec)
      

    mysql.audit_log_userビューを使用して、監査フィルターとユーザーのマッピング関係を確認します。

    obclient [test]> select * from mysql.audit_log_user;
    

    実行結果は次のとおりです:

    +---------+------+------------+
    | USER    | HOST | FILTERNAME |
    +---------+------+------------+
    | user001 | %    | log_all    |
    +---------+------+------------+
    1 row in set (0.003 sec)
    

    各フィールドの説明は以下のとおりです:

    フィールド名 説明
    USER ユーザー名
    HOST ホスト名
    FILTERNAME フィルター名

    監査の有効化

    構成パラメータaudit_log_enableを使用して、MySQLテナントの監査機能を有効にします。

    obclient> ALTER SYSTEM SET audit_log_enable=TRUE;
    

    前のトピック

    セキュリティ監査の概要
    最後

    次のトピック

    監査ルールの設定
    次
    このページの内容
    監査範囲
    制限事項と注意点
    フィルターの作成
    構文
    例
    フィルターの設定
    構文
    例
    監査の有効化