Amazon
Web Services
Microsoft Azure
Google Cloud PlatformAudit log reference
Note
This feature requires the Premium plan or above.
This article provides you with a comprehensive reference of available audit log services and events. By understanding which events are logged in the audit logs, your enterprise can monitor detailed Databricks usage patterns in your account.
The easiest way to access and query your account’s audit logs is by using system tables (Public Preview).
If you’d like to configure a regular log delivery, see Configure audit log delivery.
Audit log services
The following services and their events are logged by default in audit logs.
Workspace-level services
Workspace-level audit logs are available for these services:
Service name |
Description |
|---|---|
Events related to accounts, users, groups, and IP access lists. |
|
Events related to cluster policies. |
|
Events related to clusters. |
|
Events related to AI/BI dashboard use. |
|
Events related to Databricks SQL use. |
|
Events related to Lakehouse Monitoring. |
|
Events related to DBFS. |
|
Events related to Delta Live Table pipelines. |
|
Events related to the Databricks Feature Store. |
|
Events related to file management, which includes interacting with files using the Files API or in the volumes UI. |
|
Events related to workspace access by support personnel. |
|
Events related to Git credentials for Databricks Git folders. See also |
|
Events related to global init scripts. |
|
Events related to account and workspace groups. |
|
Events related to IAM role permissions. |
|
Events related to file uploads. |
|
Events related to pools. |
|
Events related to jobs. |
|
Events related to consumer actions in Databricks Marketplace. |
|
Events related to provider actions in Databricks Marketplace. |
|
Events related to ML Flow artifacts with ACLs. |
|
Events related to ML Flow experiments. |
|
Events related to the workspace model registry. For activity logs for models in Unity Catalog, see Unity Catalog events. |
|
Events related to notebooks. |
|
Events related to Partner Connect. |
|
Events related to predictive optimization. |
|
Events related to adding a removing GitHub Credentials. |
|
Events related to Databricks Git folders. See also |
|
Events related to secrets. |
|
Events related to model serving. |
|
Events related to the legacy Hive metastore table access control. |
|
Events related to SSH access. |
|
Events related to Mosaic AI Vector Search. |
|
Events related to the web terminal feature. |
|
Events related to workspaces. |
Account-level services
Account-level audit logs are available for these services:
Service name |
Description |
|---|---|
Actions related to billable usage access in the account console. |
|
Actions related to account-level access and identity management. |
|
Actions related to account-level access control rules. |
|
Actions performed in the account console. |
|
Actions related to managing budget policies. |
|
Log delivery configuration for such as billable usage or audit logs. |
|
Actions related to OAuth SSO authentication to the account console. |
|
Actions related to service principal credentials. |
|
Single sign-on settings for the account. |
|
Actions performed in Unity Catalog. This also includes Delta Sharing events, see Delta Sharing events. |
Additional security monitoring services
There are additional services and associated actions for workspaces that use the compliance security profile (required for some compliance standards such as FedRAMP, PCI, and HIPAA) or Enhanced security monitoring.
These are workspace-level services that will only generate in your logs if you are using the compliance security profile or enhanced security monitoring:
Service name |
Description |
|---|---|
Actions related to file integrity monitoring. |
|
Actions related to antivirus monitoring. |
|
Actions related to the process monitor. |
|
Actions related to the system logs. |
Audit log example schema
In Databricks, audit logs output events in a JSON format. The serviceName and actionName properties identify the event. The naming convention follows the Databricks REST API.
The following example is for a createMetastoreAssignment event.
{
"version":"2.0",
"auditLevel":"ACCOUNT_LEVEL",
"timestamp":1629775584891,
"orgId":"3049056262456431186970",
"shardName":"test-shard",
"accountId":"77636e6d-ac57-484f-9302-f7922285b9a5",
"sourceIPAddress":"10.2.91.100",
"userAgent":"curl/7.64.1",
"sessionId":"f836a03a-d360-4792-b081-baba525324312",
"userIdentity":{
"email":"crampton.rods@email.com",
"subjectName":null
},
"serviceName":"unityCatalog",
"actionName":"createMetastoreAssignment",
"requestId":"ServiceMain-da7fa5878f40002",
"requestParams":{
"workspace_id":"30490590956351435170",
"metastore_id":"abc123456-8398-4c25-91bb-b000b08739c7",
"default_catalog_name":"main"
},
"response":{
"statusCode":200,
"errorMessage":null,
"result":null
},
"MAX_LOG_MESSAGE_LENGTH":16384
}
Audit log schema considerations
If actions take a long time, the request and response are logged separately but the request and response pair have the same
requestId.Automated actions, such as resizing a cluster due to autoscaling or launching a job due to scheduling, are performed by the user
System-User.The
requestParamsfield is subject to truncation. If the size of its JSON representation exceeds 100 KB, values are truncated and the string... truncatedis appended to truncated entries. In rare cases where a truncated map is still larger than 100 KB, a singleTRUNCATEDkey with an empty value is present instead.
Account events
The following are accounts events logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user is reactivated after being deactivated. See Deactivate users in workspace. |
|
|
|
A user is added to a Databricks workspace. |
|
|
|
A user is added to a workspace-level group. |
|
|
|
A user account is added using an X509 certificate for authentication |
|
|
|
A user logs in to Databricks using X509 certification. |
|
|
|
A user’s Databricks SQL permissions are changed. |
|
|
|
Permissions to a workspace are changed. |
|
|
|
When permissions on a token are changed. |
|
|
|
A user’s password is changed. |
|
|
|
Password changing permissions are changed in the account. |
|
|
|
When a service principal’s permissions are changed. |
|
|
|
A workspace-level group is created. |
|
|
|
An IP access list is added to the workspace. |
|
|
|
A user is deactivated in the workspace. See Deactivate users in workspace. |
|
|
|
A user is deleted from the Databricks workspace. |
|
|
|
An IP access list is deleted from the workspace. |
|
|
|
A user runs a garbage collect command on expired tokens. |
|
|
|
When someone generates a token from User Settings or when the service generates the token. |
|
|
|
A user attempts to connect to the service through a denied IP. |
|
|
|
|
|
|
|
User logs into Databricks using a JWT. |
|
|
|
User logs into the workspace. |
|
|
|
User logs out of the workspace. |
|
|
|
User registers a new security key. |
|
|
|
User deletes a security key. |
|
|
|
User logs into Databricks using MFA. |
|
|
|
When an API call is authorized through a generic OIDC/OAuth token. |
|
|
|
|
|
|
|
When the current number of non-expired tokens exceeds the token quota |
|
|
|
A user is revoked of workspace admin permissions. |
|
|
|
A group is removed from the workspace. |
|
|
|
A user is removed from a group. |
|
|
|
A user’s password is reset. |
|
|
|
A user’s token is dropped from a workspace. Can be triggered by a user being removed from the Databricks account. |
|
|
|
User logs in to Databricks through SAML SSO. |
|
|
|
A user is granted account admin permissions. |
|
|
|
A user logs into Databricks using a token. |
|
|
|
An IP access list is changed. |
|
|
|
An account admin updates a user’s account. |
|
|
|
When a user validates their email after account creation. |
|
Clusters events
The following are cluster events logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user changes the cluster ACL. |
|
|
|
A user creates a cluster. |
|
|
|
Results from cluster creation. In conjunction with |
|
|
|
A cluster is terminated. |
|
|
|
Results from cluster termination. In conjunction with |
|
|
|
A user makes changes to cluster settings. This logs all changes except for changes in cluster size or autoscaling behavior. |
|
|
|
A cluster is deleted from the UI. |
|
|
|
Cluster resizes. This is logged on running clusters where the only property that changes is either the cluster size or autoscaling behavior. |
|
|
|
Results from cluster resize. In conjunction with |
|
|
|
A user restarts a running cluster. |
|
|
|
Results from cluster restart. In conjunction with |
|
|
|
A user starts a cluster. |
|
|
|
Results from cluster start. In conjunction with |
|
Cluster libraries events
The following are clusterLibraries events logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User installs a library on a cluster. |
|
|
|
User uninstalls a library on a cluster. |
|
|
|
A workspace admin schedules a library to install on all cluster. |
|
|
|
A workspace admin removes a library from the list to install on all clusters. |
|
Cluster policy events
The following are clusterPolicies events logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user created a cluster policy. |
|
|
|
A user edited a cluster policy. |
|
|
|
A user deleted a cluster policy. |
|
|
|
A workspace admin changes permissions for a cluster policy. |
|
Dashboards events
The following are dashboards events logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user accesses the draft version of a dashboard either by viewing it in the UI or requesting the dashboard definition using the API. Only workspace users can access the draft version of a dashboard. |
|
|
|
A user accesses the published version of a dashboard by viewing in the UI or requesting the dashboard definition using the API. Includes activity from both workspace users and account users. Excludes receiving a PDF snapshot of a dashboard using scheduled email. |
|
|
|
A user executes a query from a dashboard. |
|
|
|
A user cancels a query from a dashboard. |
|
|
|
A user receives the results of a query from a dashboard. |
|
|
|
A PDF snapshot of a dashboard is sent through a scheduled email. The request parameters values depend on the type of recipient. For a Databricks notification destination, only the |
|
|
|
A user accesses details of a draft dashboard, such as datasets and widgets. |
|
|
|
A user creates a new AI/BI dashboard using the UI or API. |
|
|
|
A user makes an update to an AI/BI dashboard using the UI or API. |
|
|
|
A user clones an AI/BI dashboard. |
|
|
|
A user publishes an AI/BI dashboard with or without embedded credentials using the UI or API. |
|
|
|
A user unpublishes a published AI/BI dashboard using the UI or API. |
|
|
|
A user moves an AI/BI dashboard to the trash using the UI or API. |
|
|
|
A user restores an AI/BI dashboard from the trash. |
|
|
|
A user migrates a DBSQL dashboard to an AI/BI dashboard. |
|
|
|
A user creates an email subscription schedule. |
|
|
|
A user makes an update to an AI/BI dashboard’s schedule. |
|
|
|
A user deletes an AI/BI dashboard’s schedule. |
|
|
|
A user subscribes an email destination to an AI/BI dashboard schedule. |
|
|
|
A user deletes an email destination from an AI/BI dashboard schedule. |
|
Databricks SQL events
The following are databrickssql events logged at the workspace level.
Note
If you manage your SQL warehouses using the legacy SQL endpoints API, your SQL warehouse audit events will have different action names. See SQL endpoint logs.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A widget is added to a dashboard. |
|
|
|
A query execution is cancelled from the SQL editor UI. This does not include cancellations that originate from the Query History UI or Databricks SQL Execution API. |
|
|
|
A warehouse manager updates permissions on a SQL warehouse. |
|
|
|
A user updates permissions on an object. |
|
|
|
A user clones a dashboard. |
|
|
|
Only in verbose audit logs. Generated when a command is submitted to a SQL warehouse, regardless of origin of the request. |
|
|
|
Only in verbose audit logs. Generated when a command on a SQL warehouse completes or is canceled, regardless of the origin of the cancellation request. |
|
|
|
A user creates an alert. |
|
|
|
A workspace admin creates a notification destination. |
|
|
|
A user creates a dashboard. |
|
|
|
A user creates a data preview dashboard. |
|
|
|
A user with the cluster create entitlement creates a SQL warehouse. |
|
|
|
A user creates a new query. |
|
|
|
A user creates a query draft. |
|
|
|
A user creates a query snippet. |
|
|
|
A user creates a sample dashboard. |
|
|
|
A user generates a visualization using the SQL editor. Excludes default results tables and visualizations in notebooks that utilize SQL warehouses. |
|
|
|
A user deletes an alert either from the alert interface or through API. Excludes deletions from the file browser UI. |
|
|
|
A workspace admin deletes a notification destination. |
|
|
|
A user deletes a dashboard either from the dashboard interface or through API. Excludes deletion via the file browser UI. |
|
|
|
A user deletes a dashboard widget. |
|
|
|
A warehouse manager deletes a SQL warehouse. |
|
|
|
A user deletes a query, either from the query interface or through API. Excludes deletion via the file browser UI. |
|
|
|
A user deletes a query draft. |
|
|
|
A user deletes a query snippet. |
|
|
|
A user deletes a visualization from a query in the SQL Editor. |
|
|
|
A user downloads a query result from the SQL Editor. Excludes downloads from dashboards. |
|
|
|
A warehouse manager makes edits to a SQL warehouse. |
|
|
|
Generated by one of the following:
|
|
|
|
A user runs a saved query. |
|
|
|
Generated by any event that executes a query such that a dashboard panel refreshes. Some examples of applicable events include:
|
|
|
|
A user favorites a dashboard. |
|
|
|
A user favorites a query. |
|
|
|
A user clones a query. |
|
|
|
A user opens the query listing page or calls the list query API. |
|
|
|
A user moves an alert to the trash. |
|
|
|
A user moves a dashboard to the trash. |
|
|
|
A user moves a query to the trash. |
|
|
|
A user restores an alert from the trash. |
|
|
|
A user restores a dashboard from the trash. |
|
|
|
A user restores a query from the trash. |
|
|
|
A warehouse manager sets the configuration for a SQL warehouse. |
|
|
|
A user requests a snapshot of a dashboard. Includes scheduled dashboard snapshots. |
|
|
|
A SQL warehouse is started. |
|
|
|
A warehouse manager stops a SQL warehouse. Excludes autostopped warehouses. |
|
|
|
A workspace admin transfers the ownership of a dashboard, query, or alert to an active user through the transfer object ownership API. Ownership transfer done through the UI or update APIs is not captured by this audit log event. |
|
|
|
A user removes a dashboard from their favorites. |
|
|
|
A user removes a query from their favorites. |
|
|
|
A user makes updates to an alert. |
|
|
|
A workspace admin makes an update to a notification destination. |
|
|
|
A user makes an update to a dashboard widget. Excludes changes to axis scales. Examples of applicable updates include:
|
|
|
|
A user makes an update to a dashboard property. Excludes changes to schedules and subscriptions. Examples of applicable updates include:
|
|
|
|
A workspace admin makes updates to the workspace’s SQL settings. |
|
|
|
A user makes an update to a query. |
|
|
|
A user makes an update to a query draft. |
|
|
|
A user makes an update to a query snippet. |
|
|
|
A user updates a visualization from either the SQL Editor or the dashboard. |
|
Data monitoring events
The following dataMonitoring events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User creates a monitor. |
|
|
|
User makes an update to a monitor. |
|
|
|
User deletes a monitor. |
|
|
|
Monitor is refreshed, either by schedule or manually. |
|
DBFS events
The following tables include dbfs events logged at the workspace level.
There are two types of DBFS events: API calls and operational events.
DBFS API events
The following DBFS audit events are only logged when written through the DBFS REST API.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User appends a block of data to the stream. This is used in conjunction with dbfs/create to stream data to DBFS. |
|
|
|
User opens a stream to write a file to DBFs. |
|
|
|
User deletes the file or directory from DBFs. |
|
|
|
User creates a new DBFS directory. |
|
|
|
User moves a file from one location to another location within DBFs. |
|
|
|
User uploads a file through the use of multipart form post to DBFs. |
|
Delta pipelines events
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user changes permissions on a pipeline. |
|
|
|
A user creates a Delta Live Tables pipeline. |
|
|
|
A user deletes a Delta Live Tables pipeline. |
|
|
|
A user edits a Delta Live Tables pipeline. |
|
|
|
A user restarts a Delta Live Tables pipeline. |
|
|
|
A user stops a Delta Live Tables pipeline. |
|
Feature store events
The following featureStore events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A consumer is added to the feature store. |
|
|
|
A data source is added to a feature table. |
|
|
|
A producer is added to a feature table. |
|
|
|
Permissions are changed in a feature table. |
|
|
|
A feature table is created. |
|
|
|
Features are created in a feature table. |
|
|
|
A feature table is deleted. |
|
|
|
Tags are deleted from a feature table. |
|
|
|
A user makes a call to get the consumers in a feature table. |
|
|
|
A user makes a call to get feature tables. |
|
|
|
A user makes a call to get feature table IDs. |
|
|
|
A user makes a call to get features. |
|
|
|
A user makes a call to get Model Serving metadata. |
|
|
|
A user makes a call to get online store details. |
|
|
|
A user makes a call to get tags for a feature table. |
|
|
|
A feature table is published. |
|
|
|
A user searches for feature tables. |
|
|
|
Tags are added to a feature table. |
|
|
|
A feature table is updated. |
|
Files events
The following filesystem events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User downloads a file using the Files API or the volumes UI. |
|
|
|
User uploads a file using the Files API or the volumes UI. |
|
|
|
User deletes a file using the Files API or the volumes UI. |
|
|
|
User gets information about a file using the Files API or the volumes UI. |
|
Genie events
The following genie events are logged at the workspace level.
Note
This service is unrelated to AI/BI Genie spaces.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A Databricks personnel is authorized to access a customer environment. |
|
Git credential events
The following gitCredentials events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user gets a git credentials. |
|
|
|
A user lists all git credentials |
none |
|
|
A user deletes a git credential. |
|
|
|
A user updates a git credential. |
|
|
|
A user creates a git credential. |
|
Global init scripts events
The following globalInitScripts events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A workspace admin creates a global initialization script. |
|
|
|
A workspace admin updates a global initialization script. |
|
|
|
A workspace admin deletes a global initialization script. |
|
Groups events
The following groups events are logged at the workspace level. These actions are related to legacy ACL groups. For actions related to account- and workspace-level groups, see Account events and Account-level account events.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
An admin adds a user to a group. |
|
|
|
An admin creates a group. |
|
|
|
An admin views group members. |
|
|
|
An admin views a list of groups |
none |
|
|
An admin views inherited groups |
none |
|
|
An admin removes a group. |
|
IAM role events
The following iamRole event is logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A workspace admin changes permissions for an IAM role. |
|
Ingestion events
The following ingestion event is logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user uploads a file to their Databricks workspace. |
|
Instance pool events
The following instancePools events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user changes an instance pool’s permissions. |
|
|
|
A user creates an instance pool. |
|
|
|
A user deletes an instance pool. |
|
|
|
A user edits an instance pool. |
|
Job events
The following jobs events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A job run is cancelled. |
|
|
|
A user cancels all runs on a job. |
|
|
|
A user updates permissions on a job. |
|
|
|
A user creates a job. |
|
|
|
A user deletes a job. |
|
|
|
A user deletes a job run. |
|
|
|
A user makes an API call to get a run output. |
|
|
|
A user repairs a job run. |
|
|
|
A job is reset. |
|
|
|
A user requests the change of a job’s permissions. |
|
|
|
Available when verbose audit logs are enabled. Emitted after a command in a notebook is executed by a job run. A command corresponds to a cell in a notebook. |
|
|
|
A job run fails. |
|
|
|
A user triggers an on-demand job run. |
|
|
|
Emitted when a job run starts after validation and cluster creation. The request parameters emitted from this event depend on the type of tasks in the job. In addition to the parameters listed, they can include:
|
|
|
|
A job run is successful. |
|
|
|
A job schedule is triggered automatically according to its schedule or trigger. |
|
|
|
A webhook is sent either when the job begins, completes, or fails. |
|
|
|
A user sets values for a task. |
|
|
|
A user submits a one-time run via the API. |
|
|
|
A user edits a job’s settings. |
|
Marketplace consumer events
The following marketplaceConsumer events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user gets access to a data product through the Databricks Marketplace. |
|
|
|
A user requests access to a data product that requires provider approval. |
|
Marketplace provider events
The following marketplaceProvider events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A metastore admin creates a listing in their provider profile. |
|
|
|
A metastore admin makes an update to a listing in their provider profile. |
|
|
|
A metastore admin deletes a listing in their provider profile. |
|
|
|
A metastore admins approves or denies a data product request. |
|
|
|
A metastore admin creates a provider profile. |
|
|
|
A metastore admin makes an update to their provider profile. |
|
|
|
A metastore admin deletes their provider profile. |
|
|
|
A provider uploads a file to their provider profile. |
|
|
|
A provider deletes a file from their provider profile. |
|
MLflow artifacts with ACL events
The following mlflowAcledArtifact events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user makes call to read an artifact. |
|
|
|
A user makes call to write to an artifact. |
|
MLflow experiment events
The following mlflowExperiment events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user creates an MLflow experiment. |
|
|
|
A user deletes an MLflow experiment. |
|
|
|
A user moves an MLflow experiment. |
|
|
|
A user restores an MLflow experiment. |
|
|
|
A user renames an MLflow experiment. |
|
MLflow model registry events
The following mlflowModelRegistry events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A user approves a model version stage transition request. |
|
|
|
A user updates permissions for a registered model. |
|
|
|
A user posts a comment on a model version. |
|
|
|
A user creates a model version. |
|
|
|
A user creates a new registered model |
|
|
|
User creates a webhook for Model Registry events. |
|
|
|
A user creates a model version stage transition request. |
|
|
|
A user deletes a comment on a model version. |
|
|
|
A user deletes a model version. |
|
|
|
A user deletes a model version tag. |
|
|
|
A user deletes a registered model |
|
|
|
A user deletes the tag for a registered model. |
|
|
|
User deletes a Model Registry webhook. |
|
|
|
A user cancels a model version stage transition request. |
|
|
|
Completed asynchronous model copying. |
|
|
|
Batch inference notebook is autogenerated. |
|
|
|
Inference notebook for a Delta Live Tables pipeline is autogenerated. |
|
|
|
A user gets a URI to download the model version. |
|
|
|
A user gets a URI to download a signed model version. |
|
|
|
A user makes a call to list a model’s artifacts. |
|
|
|
A user makes a call to list all registry webhooks in the model. |
|
|
|
A user rejects a model version stage transition request. |
|
|
|
A user renames a registered model |
|
|
|
A user updates the email subscription status for a registered model |
|
|
|
A user sets a model version tag. |
|
|
|
A user sets a model version tag. |
|
|
|
A user updates their email notifications status for the whole registry. |
|
|
|
A user tests the Model Registry webhook. |
|
|
|
A user gets a list of all open stage transition requests for the model version. |
|
|
|
A Model Registry webhook is triggered by an event. |
|
|
|
A user post an edit to a comment on a model version. |
|
|
|
A user updates a Model Registry webhook. |
|
Model serving events
The following serverlessRealTimeInference events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User updates permissions for an inference endpoint. |
|
|
|
User creates a model serving endpoint. |
|
|
|
User deletes a model serving endpoint. |
|
|
|
User disables model serving for a registered model. |
|
|
|
User enables model serving for a registered model. |
|
|
|
Users makes a call to get the query schema preview. |
|
|
|
User updates a model serving endpoint. |
|
|
|
User updates the rate limits for an inference endpoint. Rate limits only apply to Foundation Model APIs pay-per-token and external model endpoints. |
|
Notebook events
The following notebook events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A notebook is attached to a cluster. |
|
|
|
A user clones a notebook. |
|
|
|
A notebook is created. |
|
|
|
A notebook folder is deleted. |
|
|
|
A notebook is deleted. |
|
|
|
A notebook is detached from a cluster. |
|
|
|
A user downloads query results too large to display in the notebook. |
|
|
|
A user downloads the query results. |
|
|
|
A user imports a notebook. |
|
|
|
A notebook folder is moved from one location to another. |
|
|
|
A notebook is moved from one location to another. |
|
|
|
A notebook is renamed. |
|
|
|
A deleted folder is restored. |
|
|
|
A deleted notebook is restored. |
|
|
|
Available when verbose audit logs are enabled. Emitted after Databricks runs a command in a notebook. A command corresponds to a cell in a notebook.
|
|
|
|
Notebook snapshots are taken when either the job service or mlflow is run. |
|
Partner Connect events
The following partnerHub events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A workspace admin sets up a connection to a partner solution. |
|
|
|
A workspace admin deletes a partner connection. |
|
|
|
A workspace admin downloads the partner connection file. |
|
|
|
A workspace admin sets up resources for a partner connection. |
|
Predictive optimization events
The following predictiveOptimization events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Recorded when predictive optimization updates table and workload metrics so the service can more intelligently schedule optimization operations. |
|
|
|
An account admin enables or disables predictive optimization for a metastore. |
|
Remote history service events
The following remoteHistoryService events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User adds Github Credentials |
none |
|
|
User removes Github Credentials |
none |
|
|
User updates Github Credentials |
none |
Git folder events
The following repos events are logged at the workspace level.
Service |
Action name |
Description |
Request parameters |
|---|---|---|---|
|
|
A user checks out a branch on the repo. |
|
|
|
A user commits and pushes to a repo. |
|
|
|
A user creates a repo in the workspace |
|
|
|
A user deletes a repo. |
|
|
|
A user discards a commit to a repo. |
|
|
|
A user makes a call to get information about a single repo. |
|
|
|
A user makes a call to get all repos they have Manage permissions on. |
|
|
|
A user pulls the latest commits from a repo. |
|
|
|
A user updates the repo to a different branch or tag, or to the latest commit on the same branch. |
|
Secrets events
The following secrets events are logged at the workspace level.
Service |
Action name |
Description |
Request parameters |
|---|---|---|---|
|
|
User creates a secret scope. |
|
|
|
User deletes ACLs for a secret scope. |
|
|
|
User deletes a secret scope. |
|
|
|
User deletes a secret from a scope. |
|
|
|
User gets ACLs for a secret scope. |
|
|
|
User gets a secret from a scope. |
|
|
|
User makes a call to list ACLs for a secret scope. |
|
|
|
User makes a call to list secret scopes |
none |
|
|
User makes a call to list secrets within a scope. |
|
|
|
User changes ACLs for a secret scope. |
|
|
|
User adds or edits a secret within a scope. |
|
SQL table access events
Note
The sqlPermissions service includes events related to the legacy Hive metastore table access control. Databricks recommends that you upgrade the tables managed by the Hive metastore to the Unity Catalog metastore.
The following sqlPermissions events are logged at the workspace level.
Service |
Action name |
Description |
Request parameters |
|---|---|---|---|
|
|
Workspace admin or owner of an object transfers object ownership. |
|
|
|
User creates a securable object. |
|
|
|
Object owner denies privileges on a securable object. |
|
|
|
Object owner grants permission on a securable object. |
|
|
|
User drops a securable object. |
|
|
|
User renames a securable object. |
|
|
|
User requests permissions on a securable object. |
|
|
|
Object owner revokes permissions on their securable object. |
|
|
|
User views securable object permissions. |
|
SSH events
The following ssh events are logged at the workspace level.
Service |
Action name |
Description |
Request parameters |
|---|---|---|---|
|
|
Agent login of SSH into Spark driver. |
|
|
|
Agent logout of SSH from Spark driver. |
|
Vector search events
The following vectorSearch events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User creates a vector search endpoint. |
|
|
|
User deletes a vector search endpoint. |
|
|
|
User creates a vector search index. |
|
|
|
User deletes a vector search index. |
|
Web terminal events
The following webTerminal events are logged at the workspace level.
Service |
Action name |
Description |
Request parameters |
|---|---|---|---|
|
|
User starts a web terminal sessions. |
|
|
|
User closes a web terminal session. |
|
Workspace events
The following workspace events are logged at the workspace level.
Service |
Action name |
Description |
Request parameters |
|---|---|---|---|
|
|
Permissions to the workspace are changed. |
|
|
|
A setting is deleted from the workspace. |
|
|
|
User creates a file in the workspace. |
|
|
|
User deletes a file in the workspace. |
|
|
|
User opens the file editor. |
|
|
|
User gets a workspace’s user roles. |
|
|
|
Recorded when in-house OAuth authorization code is minted at the workspace level. |
|
|
|
OAuth token is minted for workspace. |
|
|
|
A workspace admin moves workspace node. |
|
|
|
A workspace admin purges workspace nodes. |
|
|
|
An existing home folder is re-attached for a user that is re-added to the workspace. |
|
|
|
A workspace admin renames workspace nodes. |
|
|
|
Home folder special attributes are removed when a user is removed from the workspace. |
|
|
|
A workspace admin updates a workspace user’s role. |
|
|
|
A workspace admin adds a principal to the workspace. |
|
|
|
A workspace admin configures a workspace setting. |
|
|
|
Workspace admin makes updates to a setting, for example enabling verbose audit logs. |
|
|
|
User exports a notebook from a workspace. |
|
|
|
OAuth client is authenticated in workspace service. |
|
Billable usage events
The following accountBillableUsage events are logged at the account level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
User accessed aggregated billable usage (usage per day) for the account via the Usage Graph feature. |
|
|
|
User accessed detailed billable usage (usage for each cluster) for the account via the Usage Download feature. |
|
Account-level account events
The following accounts events are logged at the account level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
An OAuth client is authenticated. |
|
|
|
IP permissions validation fails. Returns statusCode 403. |
|
|
|
A user is reactivated after being deactivated. See Deactivate users in account. |
|
|
|
A user is added to the Databricks account. |
|
|
|
A user is added to an account-level group. |
|
|
|
Users are added to an account-level group using SCIM provisioning. |
|
|
|
An account-level group is created. |
|
|
|
A user is deactivated. See Deactivate users in account. |
|
|
|
A user is deleted from the Databricks account. |
|
|
|
Account admin removes a setting from the Databricks account. |
|
|
|
A user runs a garbage collect command on expired tokens. |
|
|
|
User generates a token from User Settings or when the service generates the token. |
|
|
|
A user logs into the account console. |
|
|
|
A user logs out of the account console. |
|
|
|
Recorded when in-house OAuth authorization code is minted at the account level. |
|
|
|
An account-level OAuth token is issued to the service principal. |
|
|
|
A user logs into their account with the OpenID Connect browser workflow. |
|
|
|
An OIDC token is authenticated for an account admin login. |
|
|
|
A user’s password is verified during account console login. |
|
|
|
An account admin removes account admin permissions from another user. |
|
|
|
A group is removed from the account. |
|
|
|
A user is removed from an account-level group. |
|
|
|
Users are removed from an account-level group using SCIM provisioning. |
|
|
|
An account admin assigns the account admin role to another user. |
|
|
|
An account admin updates an account-level setting. |
|
|
|
A user logs into Databricks using a token. |
|
|
|
An account admin updates a user account. |
|
|
|
An account admin updates an account-level group. |
|
|
|
When a user validates their email after account creation. |
|
Account-level access control events
The following accountsAccessControl event is logged at the account level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
When a rule set is changed. |
|
Account management events
The following accountsManager events are logged at the account level. These events have to do with configurations made by account admins in the account console.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Admin accepts a workspace’s terms of service. |
|
|
|
Account admin resets a users password. Also logs whether the user changed the password after the reset. |
|
|
|
Account owner role is transferred to another account admin. |
|
|
|
The account was consolidated with another account by Databricks. |
|
|
|
Account admin created a credentials configuration. |
|
|
|
Account admin created a customer-managed key configuration. |
|
|
|
Account admin created a network configuration. |
|
|
|
Account admin created a private access settings configuration. |
|
|
|
Account admin created a storage configuration. |
|
|
|
Account admin created a VPC endpoint configuration. |
|
|
|
Account admin creates a new workspace. The |
|
|
|
Account admin deleted a credentials configuration. |
|
|
|
Account admin deleted a customer-managed key configuration. |
|
|
|
Account admin deleted a network configuration. |
|
|
|
Account admin deleted a private access settings configuration. |
|
|
|
Account admin deleted a storage configuration. |
|
|
|
Account admin deleted a VPC endpoint configuration. |
|
|
|
Account admin deleted a workspace. |
|
|
|
Account admin requests details about a credentials configuration. |
|
|
|
Account admin requests details about a customer-managed key configuration. |
|
|
|
Account admin requests details about a network configuration. |
|
|
|
Account admin requests details about a private access settings configuration. |
|
|
|
Account admin requests details about a storage configuration. |
|
|
|
Account admin requests details about a VPC endpoint configuration. |
|
|
|
Account admin requests details about a workspace. |
|
|
|
Account admin lists all credentials configurations in the account. |
|
|
|
Account admin lists all customer-managed key configurations in the account. |
|
|
|
Account admin lists all network configurations in the account. |
|
|
|
Account admin lists all private access settings configurations in the account. |
|
|
|
Account admin lists all storage configurations in the account. |
|
|
|
Account admin lists all account billing subscriptions. |
|
|
|
Account admin listed all VPC endpoint configurations for the account. |
|
|
|
Account admin lists all workspace in the account. |
|
|
|
Account admin lists all encryption key records in a specific workspace. |
|
|
|
Account admin lists all encryption key records in the account. |
|
|
|
An email was sent to a workspace admin to accept the Databricks Terms of Service. |
|
|
|
The account details were changed internally. |
|
|
|
The account billing subscriptions were updated. |
|
|
|
Admin updated the configuration for a workspace. |
|
Budget policy events
The following budgetPolicyCentral events are logged at the account level and are related to budget policies. See Attribute serverless usage with budget policies.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Workspace admin or billing admin creates a budget policy. The new |
|
|
|
Workspace admin, billing admin, or policy manager updates a budget policy. |
|
|
|
Workspace admin, billing admin, or policy manager deletes a budget policy. |
|
Log delivery events
The following logDelivery events are logged at the account level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Admin created a log delivery configuration. |
|
|
|
Admin requested details about a log delivery configuration. |
|
|
|
Admin listed all log delivery configurations in the account. |
|
|
|
Admin updated a log delivery configuration. |
|
Oauth SSO events
The following oauth2 events are logged at the account level and are related to OAuth SSO authentication to the account console.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A workspace admin creates custom app integration. |
|
|
|
A workspace admin creates an app integration using a published app integration. |
|
|
|
A workspace admin deletes custom app integration. |
|
|
|
A workspace admin deletes published app integration. |
|
|
|
A workspace admin enrolls account in OAuth. |
|
|
|
A workspace admin updates custom app integration. |
|
|
|
A workspace admin updates published app integration. |
|
Service principal credentials events (Public Preview)
The following servicePrincipalCredentials events are logged at the account level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Account admin generates an OAuth secret for the service principal. |
|
|
|
Account admin lists all OAuth secrets under a service principal. |
|
|
|
Account admin deletes a service principal’s OAuth secret. |
|
Single-sign on events
The following ssoConfigBackend events are logged at the account level and are related to SSO authentication for the account console.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Account admin created an account console SSO configuration. |
|
|
|
Account admin requested details about an account console SSO configuration. |
|
|
|
Account admin updated an account console SSO configuration. |
|
Unity Catalog events
The following audit events are related to Unity Catalog. Delta Sharing events are also logged under the unityCatalog service. For Delta Sharing events, see Delta Sharing events. Unity Catalog audit events can be logged at the workspace level or account level depending on the event.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
Account admin creates a metastore. |
|
|
|
Account admin requests metastore ID. |
|
|
|
Account admin requests details about a metastore. |
|
|
|
Account admin requests a list of all metastores in an account. |
|
|
|
Account admin makes an update to a metastore. |
|
|
|
Account admin deletes a metastore. |
|
|
|
Account admin makes an update to a metastore’s workspace assignment. |
|
|
|
Account admin creates an external location. |
|
|
|
Account admin requests details about an external location. |
|
|
|
Account admin request list of all external locations in an account. |
|
|
|
Account admin makes an update to an external location. |
|
|
|
Account admin deletes an external location. |
|
|
|
User creates a catalog. |
|
|
|
User deletes a catalog. |
|
|
|
User requests details about a catalog. |
|
|
|
User updates a catalog. |
|
|
|
User makes a call to list all catalogs in the metastore. |
|
|
|
User creates a schema. |
|
|
|
User deletes a schema. |
|
|
|
User requests details about a schema. |
|
|
|
User requests a list of all schemas in a catalog. |
|
|
|
User updates a schema. |
|
|
|
|
|
|
|
User creates a table. The request parameters differ depending on the type of table created. |
|
|
|
User deletes a table. |
|
|
|
User requests details about a table. |
|
|
|
|
|
|
|
User makes a call to list all tables in a schema. |
|
|
|
User gets an array of summaries for tables for a schema and catalog within the metastore. |
|
|
|
User makes an update to a table. The request parameters displayed vary depending on the type of table updates made. |
|
|
|
Account admin creates a storage credential. You might see an additional request parameter based on your cloud provider credentials. |
|
|
|
Account admin makes a call to list all storage credentials in the account. |
|
|
|
Account admin requests details about a storage credential. |
|
|
|
Account admin makes an update to a storage credential. |
|
|
|
Account admin deletes a storage credential. |
|
|
|
Logged whenever a temporary credential is granted for a table. You can use this event to determine who queried what and when. |
|
|
|
Logged whenever a temporary credential is granted for a path. |
|
|
|
User makes a call to get permission details for a securable object. This call doesn’t return inherited permissions, only explicitly assigned permissions. |
|
|
|
User makes a call to get all permission details for a securable object. An effective permissions call returns both explicitly assigned and inherited permissions. |
|
|
|
User updates permissions on a securable object. |
|
|
|
User queries the metadata from a previous table version. |
|
|
|
User queries the metadata and permissions from a previous table version. |
|
|
|
User updates the metadata from a previous table version. |
|
|
|
User makes a call to get details about a foreign key. |
|
|
|
User makes a call to get details about a schema. |
|
|
|
User creates a constraint for a table. |
|
|
|
User deletes a constraint for a table. |
|
|
|
User creates a Unity Catalog pipeline. |
|
|
|
User updates a Unity Catalog pipeline. |
|
|
|
User requests details about a Unity Catalog pipeline. |
|
|
|
User deletes a Unity Catalog pipeline. |
|
|
|
Resource fails to delete |
none |
|
|
User creates a Unity Catalog volume. |
|
|
|
User makes a call to get information on a Unity Catalog volume. |
|
|
|
User updates a Unity Catalog volume’s metadata with the |
|
|
|
User deletes a Unity Catalog volume. |
|
|
|
User makes a call to get a list of all Unity Catalog volumes in a schema. |
|
|
|
A temporary credential is generated when a user performs a read or write on a volume. You can use this event to determine who accessed a volume and when. |
|
|
|
Tag assignments for a securable are fetched |
|
|
|
Tag assignments for a subentity are fetched |
|
|
|
Tag assignments for a securable are updated |
|
|
|
Tag assignments for a subentity are updated |
|
|
|
User creates a Unity Catalog registered model. |
|
|
|
User makes a call to get information on a Unity Catalog registered model. |
|
|
|
User updates a Unity Catalog registered model’s metadata. |
|
|
|
User deletes a Unity Catalog registered model. |
|
|
|
User makes a call to get a list of Unity Catalog registered models in a schema, or list models across catalogs and schemas. |
|
|
|
User creates a model version in Unity Catalog. |
|
|
|
User makes a call to “finalize” a Unity Catalog model version after uploading model version files to its storage location, making it read-only and usable in inference workflows. |
|
|
|
User makes a call to get details on a model version. |
|
|
|
User makes a call to get details on a model version using the alias. |
|
|
|
User updates a model version’s metadata. |
|
|
|
User deletes a model version. |
|
|
|
User makes a call to get a list of Unity Catalog model versions in a registered model. |
|
|
|
A temporary credential is generated when a user performs a write (during initial model version creaiton) or read (after the model version has been finalized) on a model version. You can use this event to determine who accessed a model version and when. |
|
|
|
User sets an alias on a Unity Catalog registered model. |
|
|
|
User deletes an alias on a Unity Catalog registered model. |
|
|
|
User gets a Unity Catalog model version by alias. |
|
|
|
A new foreign connection is created. |
|
|
|
A foreign connection is deleted. |
|
|
|
A foreign connection is retrieved. |
|
|
|
A foreign connection is updated. |
|
|
|
Foreign connections in a metastore are listed. |
|
|
|
User creates a new function. |
|
|
|
User updates a function. |
|
|
|
User requests a list of all functions within a specific parent catalog or schema. |
|
|
|
User requests a function from a parent catalog or schema. |
|
|
|
User requests a function from a parent catalog or schema. |
|
|
|
|
|
|
|
|
Delta Sharing events
Delta Sharing events are broken up into two sections: events recorded in the data provider’s account and events recorded in the data recipient’s account.
Delta Sharing provider events
The following audit log events are logged in the provider’s account. Actions that are performed by recipients start with the deltaSharing prefix. Each of these logs also includes request_params.metastore_id, which is the metastore that manages the shared data, and userIdentity.email, which is the ID of the user who initiated the activity.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A data recipient requests a list of shares. |
|
|
|
A data recipient requests details about a shares. |
|
|
|
A data recipient requests a list of shared schemas. |
|
|
|
A data recipient requests a list of all shared tables. |
|
|
|
A data recipient requests a list of shared tables. |
|
|
|
A data recipient requests a details about a table’s metadata. |
|
|
|
A data recipient requests a details about a table version. |
|
|
|
Logged when a data recipient queries a shared table. |
|
|
|
Logged when a data recipient queries change data for a table. |
|
|
|
Logged after a data recipient gets a response to their query. The |
|
|
|
Logged after a data recipient gets a response to their query. The |
|
|
|
A data recipient requests a list of shared notebook files. |
|
|
|
A data recipient queries a shared notebook file. |
|
|
|
A data recipient requests a list of functions in a parent schema. |
|
|
|
A data recipient requests a list of all shared functions. |
|
|
|
A data recipient requests a list of function versions. |
|
|
|
A data recipient requests a list of shared volumes in a schema. |
|
|
|
A data recipient requests all shared volumes. |
|
|
|
Provider updates their metastore. |
|
|
|
Provider creates a data recipient. |
|
|
|
Provider deletes a data recipient. |
|
|
|
Provider requests details about a data recipient. |
|
|
|
Provider requests a list of all their data recipients. |
none |
|
|
Provider rotates a recipient’s token. |
|
|
|
Provider updates a data recipient’s attributes. |
|
|
|
Provider updates a data recipient’s attributes. |
|
|
|
Provider updates a data recipient’s attributes. |
|
|
|
Provider requests details about a share. |
|
|
|
Provider adds or removes data assets from a share. |
|
|
|
Provider requests a list of their shares. |
none |
|
|
Provider requests details on a share’s permissions. |
|
|
|
Provider updates a share’s permissions. |
|
|
|
Provider requests details about a recipient’s share permissions. |
|
|
|
Provider requests details about activity on their activation link. |
|
|
|
Temporary credential is generated for the recipient to access a shared volume. |
|
|
|
Temporary credential is generated for the recipient to access a shared table. |
|
Delta Sharing recipient events
The following events are logged in the data recipient’s account. These events record recipient access of shared data and AI assets, along with events associated with the management of providers. Each of these events also includes the following request parameters:
recipient_name: The name of the recipient in the data provider’s system.metastore_id: The name of the metastore in the data provider’s system.sourceIPAddress: The IP address where the request originated.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A data recipient requests a details on a shared table version. |
|
|
|
A data recipient requests a details on a shared table’s metadata. |
|
|
|
A data recipient queries a shared table. |
|
|
|
A data recipient queries change data for a table. |
|
|
|
A data recipient creates a provider object. |
|
|
|
A data recipient updates a provider object. |
|
|
|
A data recipient deletes a provider object. |
|
|
|
A data recipient requests details about a provider object. |
|
|
|
A data recipient requests a list of providers. |
none |
|
|
A data recipient activates a provider object. |
|
|
|
A data recipient requests a list of a provider’s shares. |
|
|
|
Temporary credential is generated for the recipient to access a shared volume. |
|
|
|
Temporary credential is generated for the recipient to access a shared table. |
|
System log events
Note
The response JSON object in the audit log has a result field that includes the original system log content.
The following syslog event is logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
The system log processes an event. |
|
Process monitor log events
The following monit events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
The monitor is not running. |
|
|
|
The monitor is restarting. |
|
|
|
The monitor started. |
|
|
|
The monitor is running. |
|
Additional security monitoring events
For Databricks compute resources in the classic compute plane, such as VMs for clusters and pro or classic SQL warehouses, the following features enable additional monitoring agents:
Compliance security profile. The compliance security profile is required for the compliance controls for PCI-DSS, HIPAA, and FedRAMP Moderate.
For serverless compute resources, the monitoring agents run if the compliance security profile is enabled and the complaince standard supports serverless compute resources. See Which compute resources get enhanced security and Compliance security profile compliance standards with serverless compute availability.
File integrity monitoring events
The following capsule8-alerts-dataplane events are logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
A regular event to confirm the monitor is on. Currently runs every 10 minutes. |
|
|
|
Memory is often marked executable in order to allow malicious code to execute when an application is being exploited. Alerts when a program sets heap or stack memory permissions to executable. This can cause false positives for certain application servers. |
|
|
|
Monitors the integrity of important system files. Alerts on any unauthorized changes to those files. Databricks defines specific sets of system paths on the image, and this set of paths might change over time. |
|
|
|
Changes to systemd units could result in security controls being relaxed or disabled, or the installation of a malicious service. Alerts whenever a |
|
|
|
Repeated program crashes could indicate that an attacker is attempting to exploit a memory corruption vulnerability, or that there is a stability issue in the affected application. Alerts when more than 5 instances of an individual program crash via segmentation fault. |
|
|
|
As containers are typically static workloads, this alert could indicate that an attacker has compromised the container and is attempting to install and run a backdoor. Alerts when a file that has been created or modified within 30 minutes is then executed within a container. |
|
|
|
Memory is often marked executable in order to allow malicious code to execute when an application is being exploited. Alerts when a program sets heap or stack memory permissions to executable. This can cause false positives for certain application servers. |
|
|
|
Interactive shells are rare occurrences on modern production infrastructure. Alerts when an interactive shell is started with arguments commonly used for reverse shells. |
|
|
|
Evading command logging is common practice for attackers, but might also indicate that a legitimate user is performing unauthorized actions or trying to evade policy. Alerts when a change to user command history logging is detected, indicating that a user is attempting to evade command logging. |
|
|
|
Detects some types of kernel backdoors. The loading of a new Berkeley Packet Filter (BPF) program could indicate that an attacker is loading a BPF-based rootkit to gain persistence and avoid detection. Alerts when a process loads a new privileged BPF program, if the process that is already part of an ongoing incident. |
|
|
|
Attackers commonly load malicious kernel modules (rootkits) to evade detection and maintain persistence on a compromised node. Alerts when a kernel module is loaded, if the program is already part of an ongoing incident. |
|
|
|
Attackers might create or rename malicious binaries to include a space at the end of the name in an effort to impersonate a legitimate system program or service. Alerts when a program is executed with a space after the program name. |
|
|
|
Kernel privilege escalation exploits commonly enable an unprivileged user to gain root privileges without passing standard gates for privilege changes. Alerts when a program attempts to elevate privileges through unusual means. This can issue false positive alerts on nodes with significant workloads. |
|
|
|
Internal kernel functions are not accessible to regular programs, and if called, are a strong indicator that a kernel exploit has executed and that the attacker has full control of the node. Alerts when a kernel function unexpectedly returns to user space. |
|
|
|
SMEP and SMAP are processor-level protections that increase difficulty for kernel exploits to succeed, and disabling these restrictions is a common early step in kernel exploits. Alerts when a program tampers with the kernel SMEP/SMAP configuration. |
|
|
|
Alerts when a program uses kernel functions commonly used in container escape exploits, indicating that an attacker is escalating privileges from container-access to node-access. |
|
|
|
Privileged containers have direct access to host resources, leading to a greater impact when compromised. Alerts when a privileged container is launched, if the container isn’t a known privileged image such as kube-proxy. This can issue unwanted alerts for legitimate privileged containers. |
|
|
|
Many container escapes coerce the host to execute an in-container binary, resulting in the attacker gaining full control of the affected node. Alerts when a container-created file is executed from outside a container. |
|
|
|
Modification of certain AppArmor attributes can only occur in-kernel, indicating that AppArmor has been disabled by a kernel exploit or rootkit. Alerts when the AppArmor state is changed from the AppArmor configuration detected when the sensor starts. |
|
|
|
Attackers might attempt to disable enforcement of AppArmor profiles as part of evading detection. Alerts when a command for modifying an AppArmor profile is executed, if it was not executed by a user in an SSH session. |
|
|
|
If not performed by a trusted source (such as a package manager or configuration management tool), modification of boot files could indicate an attacker modifying the kernel or its options in order to gain persistent access to a host. Alerts when changes are made to files in |
|
|
|
Log deletion not performed by a log management tool could indicate that an attacker is trying to remove indicators of compromise. Alerts on deletion of system log files. |
|
|
|
Newly created files from sources other than system update programs might be backdoors, kernel exploits, or part of an exploitation chain. Alerts when a file that has been created or modified within 30 minutes is then executed, excluding files created by system update programs. |
|
|
|
Modification of the root certificate store could indicate the installation of a rogue certificate authority, enabling interception of network traffic or bypass of code signature verification. Alerts when a system CA certificate store is changed. |
|
|
|
Setting |
|
|
|
Attackers often create hidden files as a means of obscuring tools and payloads on a compromised host. Alerts when a hidden file is created by a process associated with an ongoing incident. |
|
|
|
Attackers might modify system utilities in order to execute malicious payloads whenever these utilities are run. Alerts when a common system utility is modified by an unauthorized process. |
|
|
|
An attacker or rogue user might use or install these programs to survey connected networks for additional nodes to compromise. Alerts when common network scanning program tools are executed. |
|
|
|
Attackers might start a new network service to provide easy access to a host after compromise. Alerts when a program starts a new network service, if the program is already part of an ongoing incident. |
|
|
|
An attacker or rogue user might execute network sniffing commands to capture credentials, personally-identifiable information (PII), or other sensitive information. Alerts when a program is executed that allows network capture. |
|
|
|
Use of file transfer tools could indicate that an attacker is attempting to move toolsets to additional hosts or exfiltrate data to a remote system. Alerts when a program associated with remote file copying is executed, if the program is already part of an ongoing incident. |
|
|
|
Command and Control channels and cryptocoin miners often create new outbound network connections on unusual ports. Alerts when a program initiates a new connection on an uncommon port, if the program is already part of an ongoing incident. |
|
|
|
After gaining access to a system, an attacker might create a compressed archive of files to reduce the size of data for exfiltration. Alerts when a data compression program is executed, if the program is already part of an ongoing incident. |
|
|
|
Use of process injection techniques commonly indicates that a user is debugging a program, but might also indicate that an attacker is reading secrets from or injecting code into other processes. Alerts when a program uses |
|
|
|
Attackers often use account enumeration programs to determine their level of access and to see if other users are currently logged in to the node. Alerts when a program associated with account enumeration is executed, if the program is already part of an ongoing incident. |
|
|
|
Exploring file systems is common post-exploitation behavior for an attacker looking for credentials and data of interest. Alerts when a program associated with file and directory enumeration is executed, if the program is already part of an ongoing incident. |
|
|
|
Attackers can interrogate local network and route information to identify adjacent hosts and networks ahead of lateral movement. Alerts when a program associated with network configuration enumeration is executed, if the program is already part of an ongoing incident. |
|
|
|
Attackers often list running programs in order to identify the purpose of a node and whether any security or monitoring tools are in place. Alerts when a program associated with process enumeration is executed, if the program is already part of an ongoing incident. |
|
|
|
Attackers commonly execute system enumeration commands to determine Linux kernel and distribution versions and features, often to identify if the node is affected by specific vulnerabilities. Alerts when a program associated with system information enumeration is executed, if the program is already part of an ongoing incident. |
|
|
|
Modifying scheduled tasks is a common method for establishing persistence on a compromised node. Alerts when the |
|
|
|
Changes to systemd units could result in security controls being relaxed or disabled, or the installation of a malicious service. Alerts when the |
|
|
|
Explicit escalation to the root user decreases the ability to correlate privileged activity to a specific user. Alerts when the |
|
|
|
Alerts when the |
|
|
|
Deleting the history file is unusual, commonly performed by attackers hiding activity, or by legitimate users intending to evade audit controls. Alerts when command line history files are deleted. |
|
|
|
An attacker might add a new user to a host to provide a reliable method of access. Alerts if a new user entity is added to the local account management file |
|
|
|
Attackers might directly modify identity-related files to add a new user to the system. Alerts when a file related to user passwords is modified by a program unrelated to updating existing user information. |
|
|
|
Adding a new SSH public key is a common method for gaining persistent access to a compromised host. Alerts when an attempt to write to a user’s SSH |
|
|
|
Adding a new user is a common step for attackers when establishing persistence on a compromised node. Alerts when an identity management program is executed by a program other than a package manager. |
|
|
|
Deleting the history file is unusual, commonly performed by attackers hiding activity, or by legitimate users intending to evade audit controls. Alerts when command line history files are deleted. |
|
|
|
User profile and configuration files are often modified as a method of persistence in order to execute a program whenever a user logs in. Alerts when |
|
Antivirus monitoring events
Note
The response JSON object in these audit logs always has a result field that includes one line of the original scan result. Each scan result is represented typically by multiple audit log records, one for each line of the original scan output. For details of what could appear in this file, see the following third-party documentation.
The following clamAVScanService-dataplane event is logged at the workspace level.
Service |
Action |
Description |
Request parameters |
|---|---|---|---|
|
|
The antivirus monitoring performs a scan. A log will generate for each line of the original scan output. |
|
Deprecated log events
Databricks has deprecated the following databrickssql audit events:
createAlertDestination(nowcreateNotificationDestination)deleteAlertDestination(nowdeleteNotificationDestination)updateAlertDestination(nowupdateNotificationDestination)muteAlertunmuteAlert
SQL endpoint logs
If you create SQL warehouses using the deprecated SQL endpoint API (the former name for SQL warehouses), the corresponding audit event name will include the word Endpoint instead of Warehouse. Besides the name, these events are identical to the SQL warehouse events. To view descriptions and request parameters of these events, see their corresponding warehouse events in Databricks SQL events.
The SQL endpoint events are:
changeEndpointAclscreateEndpointeditEndpointstartEndpointstopEndpointdeleteEndpointsetEndpointConfig