AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu
Docs Home
/ /
監査メッセージ
Docs Home
/ /
監査
/
監査メッセージ
Docs Home
/
管理
/
セキュリティ
/
監査
/
監査メッセージ

mongo スキーマ監査メッセージ

mongoスキーマでは、記録されたログメッセージの構文は次のとおりです。

{
  atype: <string>,
  ts : { $date: <timestamp> },
  uuid : { $binary: <string>, $type: <string> },
  local: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },
  remote: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },
  directRemote: { ip: <string>, port: <int> || unix: <string> },   // Added in MongoDB 9.0 *(also available in 8.3.9 and 8.0.33)*
  intermediates: [   // Added in MongoDB 8.1
     {
        // IP address and port for mongos or load balancer
        ip: <string>,
        port: <int>
     }, {
        //  IP address and port for mongos or load balancer
        ip: <string>,
        port: <int>
     }
  ],
  users : [ { user: <string>, db: <string> }, ... ],
  roles: [ { role: <string>, db: <string> }, ... ],
  param: <document>,
  result: <int>
}

以下の表では、mongoスキーマのフィールドを説明しています。

フィールド
タイプ
説明

atype

string

ts

ドキュメント

イベントの日付と UTC 時間を ISO 8601 形式で含むドキュメント。

uuid

ドキュメント

メッセージ識別子を含むドキュメント。

UUID はクライアント接続を識別します。 UUID を使用して、そのクライアントに接続されている監査するイベントを追跡します。

$typeフィールドの値はBSON 型04であり、 $binaryフィールドに UUID が含まれていることを示します。

バージョン 5.0 の新機能。

local

ドキュメント

実行中のインスタンスのipアドレスとport番号を含むドキュメント。

MongoDB 5.0 以降では、 は、次のいずれかのフィールドを含むドキュメントでもかまいません。

  • isSystemUser は、 イベントを発生させたユーザーがシステムユーザーであったかどうかを示します。 同じサーバー インスタンスで実行されるバックグラウンド プロセスによって開始された自己参照ジョブのログが記録されます。

  • unix クライアントが Unix ドメイン ソケット経由で接続する場合の MongoDB ソケット ファイル パスを含みます。

MongoDB5.0 local以降、localEndpoint フィールドは非推奨です。代わりに、clientMetadata監査するメッセージの フィールドを使用してください。

バージョン5.0で変更。

intermediates

ドキュメントの配列

MongoDB 8.1 以降では、クライアントアプリケーションがロードバランサーを介して mongos に接続する場合、元のクライアントコンピューターとロードバランサーのIPアドレスとポートが監査するログに含まれます。ログを使用して、監査するイベントと元のクライアントコンピューターを照合できます。

MongoDB 8.1 以降、mongos はプロキシプロトコルヘッダーを解析し、オリジンクライアントのIPアドレスとポートを remoteフィールドに保存します。また、ロードバランサーを使用している場合、intermediatesドキュメントにはロードバランサーのIPアドレスとポートが保存されます。

8.1 より前のバージョンのMongoDBでは、ロードバランサーのIPアドレスとポートは remoteフィールドに保存され、元のクライアントコンピューターのIPアドレスとポートは省略されます。

intermediates の各配列要素は、ip フィールドと port フィールドを含むドキュメントです。これらはロードバランサーのIPアドレスとポート、または元のクライアントコンピューターリクエストが渡すmongosの IP アドレスとポートのいずれかです。

発信元クライアントコンピューターリクエストがロードバランサーを通過する場合:

  • MongoDB 8.1 以降、remoteフィールドには、プロキシプロトコルヘッダーから読み取られたクライアントコンピューターのIPアドレスとポートが保存されます。intermediatesドキュメントには、ロードバランサーのIPアドレスとポートが含まれています。

  • MongoDBバージョン 8.1 より前のバージョンでは、remoteフィールドにロードバランサーのIPアドレスとポートが保存されます。intermediatesドキュメントは監査するログにありません。

監査するイベントがシャードで発生した場合:

  • MongoDB 8.1 以降では、remoteフィールドにクライアントコンピューターのIPアドレスとポートが保存されます。アドレスとポートはプロキシプロトコルヘッダーから読み取られます。クライアントコンピューターが mongos に接続している場合は、アドレスとポートは元のクライアントコンピューター接続から読み取られます。intermediatesドキュメントには mongos のIPアドレスとポートが保存されています。ロードバランサーが使用されている場合、intermediatesドキュメントにはロードバランサーのIPアドレスとポートも保存されます。

  • MongoDBバージョン 8.1 より前のバージョンでは、remoteフィールドに mongos IPアドレスとポートが保存されます。intermediatesドキュメントは監査するログにありません。

バージョン8.1の新機能。

remote

ドキュメント

イベントに関連付けられた着信接続の ip アドレスと port 番号を保存するドキュメント。

MongoDB 8.1 以降、mongos はプロキシプロトコルヘッダーを解析し、オリジンクライアントのIPアドレスとポートを remoteフィールドに保存します。また、ロードバランサーを使用している場合、intermediatesドキュメントにはロードバランサーのIPアドレスとポートが保存されます。

8.1 より前のバージョンのMongoDBでは、ロードバランサーのIPアドレスとポートは remoteフィールドに保存され、元のクライアントコンピューターのIPアドレスとポートは省略されます。

MongoDB 5.0 以降では、 は、次のいずれかのフィールドを含むドキュメントでもかまいません。

  • isSystemUser は、 イベントを発生させたユーザーがシステムユーザーであったかどうかを示します。 同じサーバー インスタンスで実行されるバックグラウンド プロセスによって開始された自己参照ジョブのログが記録されます。

  • unix クライアントが Unix ドメイン ソケット経由で接続する場合の MongoDB ソケット ファイル パスを含みます。

directRemote フィールドは、ロード バランサー またはリバース プロキシーがクライアント アドレスを主張するときに、接続を開くホストをレコードします。

バージョン8.1で変更。

directRemote

ドキュメント

インスタンスに直接接続するホストの ip アドレスと port 番号を保存するドキュメント。クライアントが Unix ドメイン ソケットを介して接続する場合、ドキュメントは ip および port フィールドの代わりに unix フィールドを保存 (する)します。

ロードバランサーまたはリバースプロキシが異なるクライアントアドレスを主張している場合でも、このアドレスは接続を開くホストを識別します。

MongoDB は特定のポートでプロキシプロトコル接続を受け入れます。そのポートにアクセスできるホストは、任意のクライアントアドレスをアサートできます。記録されたアドレスを信頼できる状態に保つには、ロードバランサーまたはリバース プロキシへのそのポートへのアクセスを制限します。

シャードによって記録された監査するイベントの場合、報告されるアドレスは、シャードがリクエストをどのように受信するかによって異なります。

  • mongosインスタンスがリクエストをルーティングする場合、アドレスは mongos が転送するクライアントアドレスを繰り返します。

  • リクエストが `mongos` から直接来る場合、アドレスは `mongos` インスタンスをレコードします。

バージョン 9.0 の新機能（8.3.9、8.0.33 以降でも利用可能）

users

配列

ユーザー識別ドキュメントの配列。 MongoDB ではデータベースごとに異なるユーザーによるセッションが許可されているため、この配列には複数のユーザーを含めることができます。 各ドキュメントには、ユーザー名のuserフィールドと、そのユーザーの認証データベースのdbフィールドが含まれています。

roles

配列

ユーザーに付与されたロールを指定するドキュメントの配列。 各ドキュメントには、ロールの名前のroleフィールドと、ロールに関連付けられたデータベースのdbフィールドが含まれています。

param

ドキュメント

result

integer

監査イベントのアクション、詳細、および結果

次の表は、各atypeまたはアクション タイプの 、関連付けられているparamの詳細と、 result値（存在する場合）を示しています。

atype
param
result

authenticate

{
  user: <user name>,
  db: <database>,
  mechanism: <mechanism>
}

MongoDB 5.0 以降では、 authenticate :

  • 不完全な認証試行がログに記録されます。

  • X.509 やAmazon Web Services Identity and Access Management（AWS-IAM）などの外部認証メカニズム用に、原則名と識別子を mechanism に含めます（authMechanism を参照）。

バージョン5.0で変更。

0 - 成功
18 - 認証に失敗しました
334 - メカニズムが利用できません
337 - 認証が中止されました

authCheck

{
  command: <name>,
  ns: <database>.<collection>,
  args: <command object>
}

データベースへの読み取りまたは書き込みに対するユーザーの試行に対する承認チェックをログします。

ns フィールドは任意です。
args フィールドは隠される可能性があります。

デフォルトでは、監査システムは認可の失敗のみを記録します。 システムが認可の成功をログに記録できるようにするには、 auditAuthorizationSuccessパラメーターを使用します。

auditAuthorizationSuccessを有効にすると、認可の失敗のみをログに記録する場合よりもパフォーマンスが低下します。

MongoDB 5.0 以降では、内部で生成されたアクションはauthCheckではログに記録されません。

バージョン5.0で変更。

0 - 成功
13 - 操作を実行する権限がありません。

clientMetadata

{
   localEndpoint : {
      ip : <IP address of running instance>,
      port : <port of running instance>
   } || {
      unix : <MongoDB socket file path if connecting through
              a Unix domain socket>
   },
   clientMetadata : {
      driver : {
         name : <client driver name>,
         version : <client driver version>
      },
      os : {
         type : <client operating system type>,
         name : <client operating system name>,
         architecture : <client operating system architecture>,
         version : <client operating system version>
      },
      platform : <client platform name>,
      application : {
         name : <client application name>
      }
   }
}

クライアントのメタデータが含まれています。 クライアントがhelloコマンドを実行したときにログに記録されます。

詳細については、「 クライアント データ 」を参照してください。

バージョン 5.0 の新機能。

0 - 成功

{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}

次の場合にログに記録されます。

  • コレクションが作成されます。

  • ビューが作成され、ビュー名がnsフィールドに記録されます。

MongoDB 5.0 以降では、この追加情報は ビューのログに記録されます。

  • viewOn フィールド（データベースとビューのコレクション）。

  • pipeline フィールド（ビューの集計パイプライン定義 ）。

バージョン5.0で変更。

0 - 成功

createDatabase

{ ns: <database> }

0 - 成功

{
  ns: <database>.<collection>,
  indexName: <index name>,
  indexSpec: <index specification>,
  indexBuildState: <index build state>
}

indexBuildStateに指定できる値は次のとおりです。

  • IndexBuildStarted

  • IndexBuildSucceeded

  • IndexBuildAborted

MongoDB 5.0 以降、 createIndexの監査イベントは次のようになります。

  • インデックス作成の開始時と終了時にログが記録され、インデックスが正常に作成されたかどうかを示すメッセージが含まれます。

  • createIndex監査イベントの原因となったアクションの元のユーザーに割り当てられます。

  • コレクションにインデックスがある場合、 createCollectionイベントがログに記録されます。

バージョン5.0で変更。

0 - 成功
276 - インデックス構築が中止されました。

監査メッセージには、 IndexBuildStateがIndexBuildAbortedに設定されているcreateIndex監査イベントの結果コード276が含まれています。 監査メッセージには、 IndexBuildStateがIndexBuildStartedまたはIndexBuildSucceededに設定されているcreateIndex監査イベントの結果コード0が含まれています。

directAuthMutation

{
   document: {
      <collection modifications>
   },
   ns: <database>.<collection>,
   operation: <database operation>
}

データベース操作がadmin.system.usersまたはadmin.system.rolesコレクションの内容を直接変更する場合にログに記録されます。

バージョン 5.0 の新機能。

0 - 成功

renameCollection

{
  old: <database>.<collection>,
  new: <database>.<collection>
}

0 - 成功

{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}

次の場合にログに記録されます。

  • コレクションが削除されます。

  • ビューが削除され、ビュー名がnsフィールドに記録されます。

MongoDB 5.0 以降では、この追加情報は ビューのログに記録されます。

  • viewOn フィールド（データベースとビューのコレクション）。

  • pipeline フィールド（ビューの集計パイプライン定義 ）。

さらに MongoDB 5.0 以降では、 イベントが発生すると、dropCollection dropDatabase監査イベントがログに記録されます。

バージョン5.0で変更。

0 - 成功
26 - NamespaceNotFound

コレクションまたはビューが存在しない場合、監査メッセージには戻りコードがresult: 26として表示されます。

{ ns: <database> }

0 - 成功

{
  ns: <database>.<collection>,
  indexName: <index name>
}

0 - 成功

{
  user: <user name>,
  db: <database>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

customDataフィールドは任意です。

0 - 成功

{
  user: <user name>,
  db: <database>
}

0 - 成功

dropAllUsersFromDatabase

{ db: <database> }

0 - 成功

getClusterParameter

{
    requestedClusterServerParameters: <parameters>
}

0 - 成功

setClusterParameter

{
    originalClusterServerParameter: <original parameter value>,
    updatedClusterServerParameter": <new parameter value>
}

0 - 成功

updateCachedClusterServerParameter

{
    originalClusterServerParameter: <original parameter value>,
    updatedClusterServerParameter": <new parameter value>
}

次の理由でパラメータが変更されたときにログが記録されます。

  • setClusterParameterコマンドの伝達

  • ロールバックなどのレプリケーション イベント

  • コンフィギュレーションサーバーから新しいクラスター パラメータ値を更新 mongos

0 - 成功

updateUser

{
  user: <user name>,
  db: <database>,
  passwordChanged: <boolean>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

customDataフィールドは任意です。

0 - 成功

grantRolesToUser

{
  user: <user name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - 成功

revokeRolesFromUser

{
  user: <user name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - 成功

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ],
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

rolesとprivilegesフィールドは任意です。

リソースドキュメントの詳細については、自己管理型配置に関するリソース ドキュメント を参照してください。アクションのリストについては、特権アクションを参照してください。

0 - 成功

updateRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ],
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

rolesとprivilegesフィールドは任意です。

リソースドキュメントの詳細については、自己管理型配置に関するリソース ドキュメント を参照してください。アクションのリストについては、特権アクションを参照してください。

0 - 成功

{
  role: <role name>,
  db: <database>
}

0 - 成功

dropAllRolesFromDatabase

{ db: <database> }

0 - 成功

grantRolesToRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - 成功

revokeRolesFromRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - 成功

grantPrivilegesToRole

{
  role: <role name>,
  db: <database>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

リソースドキュメントの詳細については、自己管理型配置に関するリソース ドキュメント を参照してください。アクションのリストについては、特権アクションを参照してください。

0 - 成功

revokePrivilegesFromRole

{
  role: <role name>,
  db: <database name>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

リソースドキュメントの詳細については、自己管理型配置に関するリソース ドキュメント を参照してください。アクションのリストについては、特権アクションを参照してください。

0 - 成功

replSetReconfig

{
  old: {
   _id: <replicaSetName>,
   version: <number>,
   ...
   members: [ ... ],
   settings: { ... }
  },
  new: {
   _id: <replicaSetName>,
   version: <number>,
   ...
   members: [ ... ],
   settings: { ... }
  }
}

レプリカセット構成ドキュメントの詳細については、「自己管理型レプリカセット構成 」を参照してください。

0 - 成功

{ ns: <database> }

0 - 成功

shardCollection

{
  ns: <database>.<collection>,
  key: <shard key pattern>,
  options: { unique: <boolean> }
}

0 - 成功

{
  shard: <shard name>,
  connectionString: <hostname>:<port>,
}

シャードがレプリカセットである場合、 connectionStringにはレプリカセット名が含まれ、レプリカセットの他のノードを含めることができます。

0 - 成功

{
  ns: <database>.<collection>,
  key: <shard key pattern>
}

0 - 成功

{ shard: <shard name> }

0 - 成功

{ }

データベースのシャットダウンが開始されたことを示します。

0 - 成功

{ msg: <custom message string> }

logApplicationMessage を参照してください。

0 - 成功

logout

{
  reason: <string>,
  initialUsers: [ <document>, ... ],
  updatedUsers: [ <document>, ... ],
}
reason は、次のいずれかになります。

  • <database>"明示的なログアウトからの明示的なログアウト"

  • 「クライアント接続が閉じられたため、暗黙的なログアウト」

initialUsers は、ログアウト前に現在のクライアントで認証されたユーザーを含むドキュメントの配列です。

updatedUsers は、ログアウト イベント後に現在のクライアントで認証されることが予想されているユーザーを含むドキュメントの配列です。

initialUsersとupdatedUsersの各ドキュメントには次の内容が含まれています。

  • user: ユーザー名

  • db: データベースuserは認証されています

バージョン 5.0 の新機能。

0 - 成功

startup

{
    startupOptions: <document>,
    initialClusterServerParameter: <array of documents>
}

  • startupOptions 起動後にノードが持つすべてのオプションが含まれます

  • initialClusterServerParameters には、起動時にノードが持つクラスター サーバー パラメーターの初期値が含まれます。

    • ストレージから読み込まれた後（ mongodの場合）

    • は、コンフィギュレーションサーバーから更新された後（ mongosの場合）。

バージョン 5.0 の新機能。

バージョン6.1で変更。

0 - 成功

戻る
監査メッセージ
次へ
OSCF Schema
このページを評価

項目一覧