/ /

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> },
  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 ソケットファイルパスを含みます。 MongoDB 5.0以降、 `local`フィールドは非推奨です。代わりに、 clientMetadata監査メッセージの`localEndpoint`フィールドを使用してください。 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 ソケットファイルパスを含みます。 8.1バージョンでの変更。
`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 - 成功

createCollection

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

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

コレクションが作成されます。
ビューが作成され、ビュー名がnsフィールドに記録されます。

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

viewOn フィールド（データベースとビューのコレクション）。
pipeline フィールド（ビューの集計パイプライン定義）。

5.0バージョン での変更。

0 - 成功

createDatabase

{ ns: <database> }

0 - 成功

createIndex

{
  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 - 成功

dropCollection

{
   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として表示されます。

dropDatabase

{ ns: <database> }

0 - 成功

dropIndex

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

0 - 成功

createUser

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

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

0 - 成功

dropUser

{
  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 - 成功

createRole

{
  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 - 成功

dropRole

{
  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 - 成功

enableSharding

{ ns: <database> }

0 - 成功

shardCollection

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

0 - 成功

addShard

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

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

0 - 成功

refineCollectionShardKey

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

0 - 成功

removeShard

{ shard: <shard name> }

0 - 成功

shutdown

{ }

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

0 - 成功

applicationMessage

{ 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