Docs Menu
Docs Home
/
MongoDBマニュアル
/ / / /

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> },
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 での変更

0 - Success
18 - Authentication Failed
334 - Mechanism Unavailable
337 - Authentication Abandoned

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

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

バージョン 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 - Success
276 - Index build aborted.

監査メッセージには、 IndexBuildStateIndexBuildAbortedに設定されているcreateIndex監査イベントの結果コード276が含まれています。 監査メッセージには、 IndexBuildStateIndexBuildStartedまたは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 - Success
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>, ... ]
},
...
]
}

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

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

0 - 成功

updateRole

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

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

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

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

initialUsersupdatedUsersの各ドキュメントには次の内容が含まれています。
  • user: ユーザー名

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

バージョン 5.0 で追加

0 - 成功

startup

{
startupOptions: <document>,
initialClusterServerParameter: <array of documents>
}
  • startupOptions 起動後にノードが持つすべてのオプションが含まれます

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

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

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

バージョン 5.0 で追加

バージョン 6.1 での変更

0 - 成功

戻る

監査メッセージ