CODEWITHSUNDEEP
azureazure-sql-databaseazure-resource-manager
cody.codes
cody.codes

Reputation: 1537

Enabling auditing settings on Azure SQL database via ARM Template

I have been working on a template to deploy SQL/XSS injection detection. All is well except for enabling the auditing settings. In the docs I see the following:

{
  "name": "default",
  "type": "Microsoft.Sql/servers/databases/auditingSettings",
  "apiVersion": "2017-03-01-preview",
  "properties": {
    "state": "string",
    "storageEndpoint": "string",
    "storageAccountAccessKey": "string",
    "retentionDays": "integer",
    "auditActionsAndGroups": [
      "string"
    ],
    "storageAccountSubscriptionId": "string",
    "isStorageSecondaryKeyInUse": boolean
  }
}

I believe I've followed this structure. See my full code here or the snippet here:

  - apiVersion: 2017-03-01-preview
    type: Microsoft.Sql/servers/auditingSettings
    name: "[concat(parameters('sqlServerName'), '/auditing-default')]"
    dependsOn:
      - "[resourceId('Microsoft.Sql/servers', parameters('sqlServerName'))]"
    properties:
      state: Enabled
      storageEndpoint: "[reference(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')),
        '2018-03-01-preview').PrimaryEndpoints.Blob]"
      storageAccountAccessKey: "[listKeys(resourceId('Microsoft.Storage/storageAccounts',
        parameters('storageAccountName')), '2018-03-01-preview').keys[0].value]"
      retentionDays: 0
      storageAccountSubscriptionId: "[subscription().subscriptionId]"
      isStorageSecondaryKeyInUse: false'

I am seeing that there is a discrepancy between the servers/databases and just /servers for the type, but I actually borrowed this code from the Azure Quick Starts and the specific file here where the code is the following: 

{
        "apiVersion": "2017-03-01-preview",
        "type": "Microsoft.Sql/servers/auditingSettings",
        "name": "[concat(parameters('sqlServerName'), '/', 'default')]",
        "properties": {
          "state": "Enabled",
          "storageEndpoint": "[reference(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), '2018-03-01-preview').PrimaryEndpoints.Blob]",
          "storageAccountAccessKey": "[listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), '2018-03-01-preview').keys[0].value]",
          "retentionDays": 0,
          "auditActionsAndGroups": null,
          "storageAccountSubscriptionId": "[subscription().subscriptionId]",
          "isStorageSecondaryKeyInUse": false
        }
      }

The official docs don't seem to have info on adding the auditingSettings on a server level, but then here the type is directly under server, so I'm a bit lost. I haven't looked into the schema yet, but any help/guidance as to what might be going on here would be much appreciated!

Upvotes: 2

Views: 4471

Answers (3)

vainolo
vainolo

Reputation: 6987

We recently published a template that shows how to deploy an Azure SQL Server with server auditing enabled.

The full example is here: https://github.com/Azure/azure-quickstart-templates/tree/master/quickstarts/microsoft.sql/sql-auditing-server-policy-to-blob-storage

Upvotes: 3

Matt
Matt

Reputation: 13349

As the other answers are returning 404s here's a full list of instructions to get the basics working in ARM for auditing at the SQL Server level. This will therefore audit all databases within the SQL Server.

Firstly, create a parameter for the name of your SQL Server and storage account:

"sqlServerName": {
  "type": "string"
},
"auditingStorageAccountName": {
  "type": "string"
}

Then in your resources section create a storage account to store your audit records, this example will replicate the audit blobs to the paired region (RA-GRS). It was necessary to add network ACLs explicitly as shown so that Azure can write the audit logs. This example also uses storage account assigned keys but managed identities are also possible:

{
  "type": "Microsoft.Storage/storageAccounts",
  "apiVersion": "2019-06-01",
  "name": "[parameters('auditingStorageAccountName')]",
  "location": "[resourceGroup().location]",
  "sku": {
    "name": "Standard_RAGRS",
    "tier": "Standard"
  },
  "kind": "StorageV2",
  "properties": {
    "networkAcls": {
      "bypass": "AzureServices",
      "virtualNetworkRules": [],
      "ipRules": [],
      "defaultAction": "Allow"
    },
    "supportsHttpsTrafficOnly": true,
    "allowBlobPublicAccess": false,
    "encryption": {
      "services": {
        "blob": {
          "keyType": "Account",
          "enabled": true
        }
      },
      "keySource": "Microsoft.Storage"
    },
    "accessTier": "Hot"
  }
},
...

Finally add the auditing settings themselves - this example is for a resource added at the root (i.e. directly within "resources": {}), to add it as sub-resource to the SQL Server itself the type needs to be just "auditingSettings". A retention days of zero means audit records will be kept indefinitely. It was necessary to add the subscription ID explicitly otherwise the settings do not appear correctly when viewed in the portal:

{
  "type": "Microsoft.Sql/servers/auditingSettings",
  "name": "default",
  "apiVersion": "2020-11-01-preview",
  "dependsOn": [
    "[resourceId('Microsoft.Sql/servers/', parameters('sqlServerName'))]",
    "[resourceId('Microsoft.Storage/storageAccounts', parameters('auditingStorageAccountName'))]"
  ],
  "properties": {
    "retentionDays": 0,
    "state": "Enabled",
    "storageEndpoint": "[reference(resourceId('Microsoft.Storage/storageAccounts', parameters('auditingStorageAccountName'))).primaryEndpoints.blob]",
    "storageAccountAccessKey": "[listKeys(parameters('auditingStorageAccountName'), '2019-06-01').keys[0].value]",
    "storageAccountSubscriptionId": "[subscription().subscriptionId]"
  }
},
...

Upvotes: 0

adam
adam

Reputation: 317

For those looking for guidance on enabling server level auditing to a Log Analytics workspace, I found this github link

Upvotes: -1

Related Questions