自己管理型配置におけるシステムイベント監査メッセージ

項目一覧

監査メッセージ

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

注意

システムイベント監査メッセージは、 MongoDB Enterpriseと MongoDB Atlas で利用できます。

MongoDB Atlas のこの機能の詳細については、Atlas のドキュメントデータベース監査の設定と MongoDB ログの表示とダウンロードを参照してください。

監査メッセージ

イベント監査機能は、イベントを JSON 形式で記録できます。監査出力を構成するには、「自己管理型配置での監査の構成」を参照してください。

バージョン 5.0 での変更。

記録された JSON メッセージの構文は次のとおりです。

{
  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> },
  users : [ { user: <string>, db: <string> }, ... ],
  roles: [ { role: <string>, db: <string> }, ... ],
  param: <document>,
  result: <int>
}

フィールド	タイプ	説明
`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 での変更。
`remote`	ドキュメント	イベントに関連付けられた着信接続の`ip`アドレスと`port`番号を含むドキュメント。 MongoDB 5.0 以降では、は、次のいずれかのフィールドを含むドキュメントでもかまいません。 `isSystemUser` は、イベントを発生させたユーザーがシステムユーザーであったかどうかを示します。同じサーバーインスタンスで実行されるバックグラウンドプロセスによって開始された自己参照ジョブのログが記録されます。 `unix` クライアントが Unix ドメインソケット経由で接続する場合の MongoDB ソケットファイルパスを含みます。バージョン 5.0 での変更。
`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 での変更。

- Success
- Authentication Failed
- Mechanism Unavailable

authCheck

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

ns field is optional.

args field may be redacted.

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

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

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

バージョン 5.0 での変更。

0 - Success

13 - Unauthorized to perform the operation.

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コマンドを実行したときにログに記録されます。

Tip

以下も参照してください。

クライアントデータ

バージョン 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 - Success

276 - Index build aborted.

監査メッセージには、 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 - Success

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

戻る

フィルターを構成する

ネットワークと設定の強化