Espaces de travail Microsoft.Synapse/extendedAuditingSettings 2019-06-01-preview
Définition de ressource Bicep
Le type de ressource workspaces/extendedAuditingSettings peut être déployé avec des opérations qui ciblent :
- Groupes de ressources - Voir commandes de déploiement de groupe de ressources
Pour obtenir la liste des propriétés modifiées dans chaque version d’API, consultez journal des modifications.
Format des ressources
Pour créer une ressource Microsoft.Synapse/workspaces/extendedAuditingSettings, ajoutez le Bicep suivant à votre modèle.
resource symbolicname 'Microsoft.Synapse/workspaces/extendedAuditingSettings@2019-06-01-preview' = {
name: 'default'
parent: resourceSymbolicName
properties: {
auditActionsAndGroups: [
'string'
]
isAzureMonitorTargetEnabled: bool
isStorageSecondaryKeyInUse: bool
predicateExpression: 'string'
queueDelayMs: int
retentionDays: int
state: 'string'
storageAccountAccessKey: 'string'
storageAccountSubscriptionId: 'string'
storageEndpoint: 'string'
}
}
Valeurs de propriétés
workspaces/extendedAuditingSettings
| Nom | Description | Valeur |
|---|---|---|
| name | Nom de la ressource Découvrez comment définir des noms et des types pour des ressources enfants dans Bicep. |
'default' |
| parent | Dans Bicep, vous pouvez spécifier la ressource parente pour une ressource enfant. Vous devez uniquement ajouter cette propriété lorsque la ressource enfant est déclarée en dehors de la ressource parente. Pour plus d’informations, consultez Ressource enfant en dehors de la ressource parente. |
Nom symbolique pour la ressource de type : espaces de travail |
| properties | Propriétés de ressource. | ExtendedServerBlobAuditingPolicyProperties |
ExtendedServerBlobAuditingPolicyProperties
| Nom | Description | Valeur |
|---|---|---|
| auditActionsAndGroups | Spécifie les Actions-Groups et actions à auditer. L’ensemble recommandé de groupes d’actions à utiliser est la combinaison suivante : cela permet d’auditer toutes les requêtes et procédures stockées exécutées sur la base de données, ainsi que les connexions réussies et ayant échoué : BATCH_COMPLETED_GROUP, SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP. Cette combinaison ci-dessus est également l’ensemble configuré par défaut lors de l’activation de l’audit à partir du Portail Azure. Les groupes d’actions pris en charge à auditer sont (remarque : choisissez uniquement des groupes spécifiques qui couvrent vos besoins d’audit. L’utilisation de groupes inutiles peut entraîner de très grandes quantités d’enregistrements d’audit : APPLICATION_ROLE_CHANGE_PASSWORD_GROUP BACKUP_RESTORE_GROUP DATABASE_LOGOUT_GROUP DATABASE_OBJECT_CHANGE_GROUP DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP DATABASE_OBJECT_PERMISSION_CHANGE_GROUP DATABASE_OPERATION_GROUP DATABASE_PERMISSION_CHANGE_GROUP DATABASE_PRINCIPAL_CHANGE_GROUP DATABASE_PRINCIPAL_IMPERSONATION_GROUP DATABASE_ROLE_MEMBER_CHANGE_GROUP FAILED_DATABASE_AUTHENTICATION_GROUP SCHEMA_OBJECT_ACCESS_GROUP SCHEMA_OBJECT_CHANGE_GROUP SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP USER_CHANGE_PASSWORD_GROUP BATCH_STARTED_GROUP BATCH_COMPLETED_GROUP Il s’agit de groupes qui couvrent toutes les instructions sql et procédures stockées exécutées sur la base de données, et ne doivent pas être utilisés en combinaison avec d’autres groupes, car cela entraîne des journaux d’audit en double. Pour plus d’informations, consultez Groupes d’actions d’audit au niveau de la base de données. Pour la stratégie d’audit de base de données, des actions spécifiques peuvent également être spécifiées (notez que les actions ne peuvent pas être spécifiées pour la stratégie d’audit du serveur). Les actions prises en charge pour l’audit sont les suivantes : SELECT UPDATE INSERT Suppression Exécutez RECEIVE REFERENCES La forme générale pour définir une action à auditer est la suivante : {action} ON {object} BY {principal} Notez que {object} au format ci-dessus peut faire référence à un objet tel qu’une table, une vue ou une procédure stockée, ou une base de données ou un schéma entier. Pour ces derniers cas, les formulaires DATABASE::{db_name} et SCHEMA::{schema_name} sont utilisés, respectivement. Par exemple : SELECT sur dbo.myTable by public SELECT on DATABASE::myDatabase by public SELECT on SCHEMA::mySchema by public Pour plus d’informations, consultez Actions d’audit au niveau de la base de données |
string[] |
| isAzureMonitorTargetEnabled | Spécifie si les événements d’audit sont envoyés à Azure Monitor. Pour envoyer les événements à Azure Monitor, spécifiez « state » comme « Enabled » et « isAzureMonitorTargetEnabled » comme true. Lorsque vous utilisez l’API REST pour configurer l’audit, les paramètres de diagnostic avec la catégorie de journaux de diagnostic « SQLSecurityAuditEvents » sur la base de données doivent également être créés. Notez que pour l’audit au niveau du serveur, vous devez utiliser la base de données « master » en tant que {databaseName}. Format de l’URI des paramètres de diagnostic : PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Sql/servers/{serverName}/databases/{databaseName}/providers/microsoft.insights/diagnosticSettings/{settingsName}?api-version=2017-05-01-previewPour plus d’informations, consultez API REST des paramètres de diagnostic. ou Paramètres de diagnostic PowerShell |
bool |
| isStorageSecondaryKeyInUse | Spécifie si la valeur storageAccountAccessKey est la clé secondaire du stockage. | bool |
| prédicateExpression | Spécifie la condition de la clause where lors de la création d’un audit. | string |
| queueDelayMs | Spécifie la durée (en millisecondes) qui peut s'écouler avant que le traitement des actions d'audit ne soit forcé. La valeur minimale par défaut est 1000 (1 seconde). Le maximum est de 2 147 483 647. |
int |
| retentionDays | Spécifie le nombre de jours à conserver dans les journaux d’audit dans le compte de stockage. | int |
| state | Spécifie l’état de la stratégie. Si l’état est Activé, storageEndpoint ou isAzureMonitorTargetEnabled sont requis. | 'Désactivé' 'Enabled' (obligatoire) |
| storageAccountAccessKey | Spécifie la clé d’identificateur du compte de stockage d’audit. Si l’état est Activé et que storageEndpoint est spécifié, le fait de ne pas spécifier le storageAccountAccessKey utilise l’identité managée affectée par le système SQL Server pour accéder au stockage. Conditions préalables à l’utilisation de l’authentification d’identité managée : 1. Attribuez SQL Server une identité managée affectée par le système dans Azure Active Directory (AAD). 2. Accordez à SQL Server d’identité l’accès au compte de stockage en ajoutant le rôle RBAC « Contributeur aux données blob de stockage » à l’identité du serveur. Pour plus d’informations, consultez Audit du stockage à l’aide de l’authentification d’identité managée |
string |
| storageAccountSubscriptionId | Spécifie l’ID d’abonnement au stockage blob. | string |
| storageEndpoint | Spécifie le point de terminaison de stockage d’objets blob (par exemple https://MyAccount.blob.core.windows.net). Si l’état est Activé, storageEndpoint ou estAzureMonitorTargetEnabled est requis. |
string |
Définition de ressources de modèle ARM
Le type de ressource workspaces/extendedAuditingSettings peut être déployé avec des opérations qui ciblent :
- Groupes de ressources - Voir commandes de déploiement de groupes de ressources
Pour obtenir la liste des propriétés modifiées dans chaque version de l’API, consultez journal des modifications.
Format des ressources
Pour créer une ressource Microsoft.Synapse/workspaces/extendedAuditingSettings, ajoutez le code JSON suivant à votre modèle.
{
"type": "Microsoft.Synapse/workspaces/extendedAuditingSettings",
"apiVersion": "2019-06-01-preview",
"name": "default",
"properties": {
"auditActionsAndGroups": [ "string" ],
"isAzureMonitorTargetEnabled": "bool",
"isStorageSecondaryKeyInUse": "bool",
"predicateExpression": "string",
"queueDelayMs": "int",
"retentionDays": "int",
"state": "string",
"storageAccountAccessKey": "string",
"storageAccountSubscriptionId": "string",
"storageEndpoint": "string"
}
}
Valeurs de propriétés
workspaces/extendedAuditingSettings
| Nom | Description | Valeur |
|---|---|---|
| type | Type de ressource | « Microsoft.Synapse/workspaces/extendedAuditingSettings » |
| apiVersion | Version de l’API de ressource | '2019-06-01-preview' |
| name | Nom de la ressource Découvrez comment définir des noms et des types pour des ressources enfants dans des modèles ARM JSON. |
'default' |
| properties | Propriétés de ressource. | ExtendedServerBlobAuditingPolicyProperties |
ExtendedServerBlobAuditingPolicyProperties
| Nom | Description | Valeur |
|---|---|---|
| auditActionsAndGroups | Spécifie les Actions-Groups et Actions à auditer. L’ensemble recommandé de groupes d’actions à utiliser est la combinaison suivante : cela permet d’auditer toutes les requêtes et procédures stockées exécutées sur la base de données, ainsi que les connexions réussies et ayant échoué : BATCH_COMPLETED_GROUP, SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP. Cette combinaison ci-dessus est également l’ensemble configuré par défaut lors de l’activation de l’audit à partir du Portail Azure. Les groupes d’actions pris en charge à auditer sont (remarque : choisissez uniquement des groupes spécifiques qui couvrent vos besoins d’audit. L’utilisation de groupes inutiles peut entraîner de très grandes quantités d’enregistrements d’audit) : APPLICATION_ROLE_CHANGE_PASSWORD_GROUP BACKUP_RESTORE_GROUP DATABASE_LOGOUT_GROUP DATABASE_OBJECT_CHANGE_GROUP DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP DATABASE_OBJECT_PERMISSION_CHANGE_GROUP DATABASE_OPERATION_GROUP DATABASE_PERMISSION_CHANGE_GROUP DATABASE_PRINCIPAL_CHANGE_GROUP DATABASE_PRINCIPAL_IMPERSONATION_GROUP DATABASE_ROLE_MEMBER_CHANGE_GROUP FAILED_DATABASE_AUTHENTICATION_GROUP SCHEMA_OBJECT_ACCESS_GROUP SCHEMA_OBJECT_CHANGE_GROUP SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP USER_CHANGE_PASSWORD_GROUP BATCH_STARTED_GROUP BATCH_COMPLETED_GROUP Il s’agit de groupes qui couvrent toutes les instructions sql et les procédures stockées exécutées sur la base de données, et qui ne doivent pas être utilisés en combinaison avec d’autres groupes, car cela entraîne des journaux d’audit en double. Pour plus d’informations, consultez Groupes d’actions d’audit au niveau de la base de données. Pour la stratégie d’audit de base de données, des actions spécifiques peuvent également être spécifiées (notez que les actions ne peuvent pas être spécifiées pour la stratégie d’audit de serveur). Les actions prises en charge à auditer sont les suivantes : SELECT UPDATE INSERT Suppression Exécutez RECEIVE REFERENCES La forme générale permettant de définir une action à auditer est la suivante : {action} ON {object} BY {principal} Notez que {object} au format ci-dessus peut faire référence à un objet tel qu’une table, une vue ou une procédure stockée, ou une base de données ou un schéma entier. Pour ces derniers cas, les formulaires DATABASE::{db_name} et SCHEMA::{schema_name} sont utilisés, respectivement. Par exemple : SELECT sur dbo.myTable by public SELECT on DATABASE::myDatabase by public SELECT on SCHEMA::mySchema by public Pour plus d’informations, consultez Actions d’audit au niveau de la base de données |
string[] |
| isAzureMonitorTargetEnabled | Spécifie si les événements d’audit sont envoyés à Azure Monitor. Pour envoyer les événements à Azure Monitor, spécifiez « state » comme « Enabled » et « isAzureMonitorTargetEnabled » comme true. Lorsque vous utilisez l’API REST pour configurer l’audit, les paramètres de diagnostic avec la catégorie de journaux de diagnostic « SQLSecurityAuditEvents » sur la base de données doivent également être créés. Notez que pour l’audit au niveau du serveur, vous devez utiliser la base de données « master » en tant que {databaseName}. Format de l’URI des paramètres de diagnostic : PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Sql/servers/{serverName}/databases/{databaseName}/providers/microsoft.insights/diagnosticSettings/{settingsName}?api-version=2017-05-01-previewPour plus d’informations, consultez API REST des paramètres de diagnostic. ou Paramètres de diagnostic PowerShell |
bool |
| isStorageSecondaryKeyInUse | Spécifie si la valeur storageAccountAccessKey est la clé secondaire du stockage. | bool |
| predicateExpression | Spécifie la condition de la clause where lors de la création d’un audit. | string |
| queueDelayMs | Spécifie la durée (en millisecondes) qui peut s'écouler avant que le traitement des actions d'audit ne soit forcé. La valeur minimale par défaut est 1000 (1 seconde). Le maximum est de 2 147 483 647. |
int |
| retentionDays | Spécifie le nombre de jours à conserver dans les journaux d’audit du compte de stockage. | int |
| state | Spécifie l’état de la stratégie. Si l’état est Activé, storageEndpoint ou isAzureMonitorTargetEnabled sont requis. | 'Désactivé' 'Enabled' (obligatoire) |
| storageAccountAccessKey | Spécifie la clé d’identificateur du compte de stockage d’audit. Si l’état est Activé et que storageEndpoint est spécifié, le fait de ne pas spécifier storageAccountAccessKey utilise l’identité managée affectée par le système SQL Server pour accéder au stockage. Conditions préalables à l’utilisation de l’authentification d’identité managée : 1. Attribuer SQL Server une identité managée affectée par le système dans Azure Active Directory (AAD). 2. Accordez SQL Server accès d’identité au compte de stockage en ajoutant le rôle RBAC « Contributeur aux données Blob de stockage » à l’identité du serveur. Pour plus d’informations, consultez Audit dans le stockage à l’aide de l’authentification d’identité managée. |
string |
| storageAccountSubscriptionId | Spécifie l’ID d’abonnement au stockage d’objets blob. | string |
| storageEndpoint | Spécifie le point de terminaison de stockage d’objets blob (par exemple https://MyAccount.blob.core.windows.net). Si l’état est Activé, storageEndpoint ou isAzureMonitorTargetEnabled est requis. |
string |
Définition de ressource Terraform (fournisseur AzAPI)
Le type de ressource workspaces/extendedAuditingSettings peut être déployé avec des opérations qui ciblent :
- Groupes de ressources
Pour obtenir la liste des propriétés modifiées dans chaque version d’API, consultez journal des modifications.
Format des ressources
Pour créer une ressource Microsoft.Synapse/workspaces/extendedAuditingSettings, ajoutez le Terraform suivant à votre modèle.
resource "azapi_resource" "symbolicname" {
type = "Microsoft.Synapse/workspaces/extendedAuditingSettings@2019-06-01-preview"
name = "default"
parent_id = "string"
body = jsonencode({
properties = {
auditActionsAndGroups = [
"string"
]
isAzureMonitorTargetEnabled = bool
isStorageSecondaryKeyInUse = bool
predicateExpression = "string"
queueDelayMs = int
retentionDays = int
state = "string"
storageAccountAccessKey = "string"
storageAccountSubscriptionId = "string"
storageEndpoint = "string"
}
})
}
Valeurs de propriétés
workspaces/extendedAuditingSettings
| Nom | Description | Valeur |
|---|---|---|
| type | Type de ressource | « Microsoft.Synapse/workspaces/extendedAuditingSettings@2019-06-01-preview » |
| name | Nom de la ressource | « valeur par défaut » |
| parent_id | ID de la ressource qui est le parent de cette ressource. | ID pour la ressource de type : espaces de travail |
| properties | Propriétés de ressource. | ExtendedServerBlobAuditingPolicyProperties |
ExtendedServerBlobAuditingPolicyProperties
| Nom | Description | Valeur |
|---|---|---|
| auditActionsAndGroups | Spécifie les Actions-Groups et actions à auditer. L’ensemble recommandé de groupes d’actions à utiliser est la combinaison suivante : cela permet d’auditer toutes les requêtes et procédures stockées exécutées sur la base de données, ainsi que les connexions réussies et ayant échoué : BATCH_COMPLETED_GROUP, SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP. Cette combinaison ci-dessus est également l’ensemble configuré par défaut lors de l’activation de l’audit à partir du Portail Azure. Les groupes d’actions pris en charge à auditer sont (remarque : choisissez uniquement des groupes spécifiques qui couvrent vos besoins d’audit. L’utilisation de groupes inutiles peut entraîner de très grandes quantités d’enregistrements d’audit : APPLICATION_ROLE_CHANGE_PASSWORD_GROUP BACKUP_RESTORE_GROUP DATABASE_LOGOUT_GROUP DATABASE_OBJECT_CHANGE_GROUP DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP DATABASE_OBJECT_PERMISSION_CHANGE_GROUP DATABASE_OPERATION_GROUP DATABASE_PERMISSION_CHANGE_GROUP DATABASE_PRINCIPAL_CHANGE_GROUP DATABASE_PRINCIPAL_IMPERSONATION_GROUP DATABASE_ROLE_MEMBER_CHANGE_GROUP FAILED_DATABASE_AUTHENTICATION_GROUP SCHEMA_OBJECT_ACCESS_GROUP SCHEMA_OBJECT_CHANGE_GROUP SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP USER_CHANGE_PASSWORD_GROUP BATCH_STARTED_GROUP BATCH_COMPLETED_GROUP Il s’agit de groupes qui couvrent toutes les instructions sql et les procédures stockées exécutées sur la base de données, et qui ne doivent pas être utilisés en combinaison avec d’autres groupes, car cela entraîne des journaux d’audit en double. Pour plus d’informations, consultez Groupes d’actions d’audit au niveau de la base de données. Pour la stratégie d’audit de base de données, des actions spécifiques peuvent également être spécifiées (notez que les actions ne peuvent pas être spécifiées pour la stratégie d’audit de serveur). Les actions prises en charge à auditer sont les suivantes : SELECT UPDATE INSERT Suppression Exécutez RECEIVE REFERENCES La forme générale permettant de définir une action à auditer est la suivante : {action} ON {object} BY {principal} Notez que {object} au format ci-dessus peut faire référence à un objet tel qu’une table, une vue ou une procédure stockée, ou à une base de données ou un schéma entier. Dans ces derniers cas, les formulaires DATABASE::{db_name} et SCHEMA::{schema_name} sont utilisés, respectivement. Par exemple : SELECT on dbo.myTable by public SELECT on DATABASE::myDatabase by public SELECT on SCHEMA::mySchema by public Pour plus d’informations, consultez Actions d’audit au niveau de la base de données |
string[] |
| isAzureMonitorTargetEnabled | Spécifie si les événements d’audit sont envoyés à Azure Monitor. Pour envoyer les événements à Azure Monitor, spécifiez « state » comme « Enabled » et « isAzureMonitorTargetEnabled » comme true. Lorsque vous utilisez l’API REST pour configurer l’audit, les paramètres de diagnostic avec la catégorie journaux de diagnostic « SQLSecurityAuditEvents » sur la base de données doivent également être créés. Notez que pour l’audit au niveau du serveur, vous devez utiliser la base de données « master » en tant que {databaseName}. Format d’URI des paramètres de diagnostic : PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Sql/servers/{serverName}/databases/{databaseName}/providers/microsoft.insights/diagnosticSettings/{settingsName}?api-version=2017-05-01-previewPour plus d’informations, consultez API REST paramètres de diagnostic. ou Paramètres de diagnostic PowerShell |
bool |
| isStorageSecondaryKeyInUse | Spécifie si la valeur storageAccountAccessKey est la clé secondaire du stockage. | bool |
| prédicateExpression | Spécifie la condition de la clause where lors de la création d’un audit. | string |
| queueDelayMs | Spécifie la durée (en millisecondes) qui peut s'écouler avant que le traitement des actions d'audit ne soit forcé. La valeur minimale par défaut est 1000 (1 seconde). Le maximum est de 2 147 483 647. |
int |
| retentionDays | Spécifie le nombre de jours à conserver dans les journaux d’audit dans le compte de stockage. | int |
| state | Spécifie l’état de la stratégie. Si l’état est Activé, storageEndpoint ou isAzureMonitorTargetEnabled sont requis. | « Désactivé » « Enabled » (obligatoire) |
| storageAccountAccessKey | Spécifie la clé d’identificateur du compte de stockage d’audit. Si l’état est Activé et que storageEndpoint est spécifié, le fait de ne pas spécifier le storageAccountAccessKey utilise l’identité managée affectée par le système SQL Server pour accéder au stockage. Conditions préalables à l’utilisation de l’authentification d’identité managée : 1. Attribuez SQL Server une identité managée affectée par le système dans Azure Active Directory (AAD). 2. Accordez à SQL Server d’identité l’accès au compte de stockage en ajoutant le rôle RBAC « Contributeur aux données blob de stockage » à l’identité du serveur. Pour plus d’informations, consultez Audit du stockage à l’aide de l’authentification d’identité managée |
string |
| storageAccountSubscriptionId | Spécifie l’ID d’abonnement au stockage blob. | string |
| storageEndpoint | Spécifie le point de terminaison de stockage d’objets blob (par exemple https://MyAccount.blob.core.windows.net). Si l’état est Activé, storageEndpoint ou estAzureMonitorTargetEnabled est requis. |
string |