What is Azure SQL
Azure SQL databases are coming more and more used. They can be expanded on the go with elastic pools or you can use them inside servers like inside on-premises installations.
You can have multiple SQL services in different subscriptions and you can connect them thru VNET-peering or just publish them directly to internet or thru ExpressRoute to on-premises applications to use.
The multiple options with these building blocks that Microsoft provides.
What about the monetary compensation?
For SQL usage you will be billed by usage and cores. The more you want the more you pay, easy as that.
You can check the pricing for Azure SQL in the the following link. There is pricing calculator for Single DB and for Elastic Pools.
Security features will be an extra costs, not all but some example Defender for SQL.
Here is my previous post about the history of SQL and future with Defender.
But there is also free features
Like Ledger which is still in preview.
Azure SQL Ledger
With Ledger you can verify the integrity of your data and detect possible tampering.
Ledger helps protect data from any attacker or high-privileged user, including database administrators (DBAs), system administrators, and cloud administrators. As with a traditional ledger, the feature preserves historical data. If a row is updated in the database, its previous value is maintained and protected in a history table. Ledger provides a chronicle of all changes made to the database over time.
Each transaction that the database receives is cryptographically hashed (SHA-256). The hash function uses the value of the transaction, along with the hash of the previous transaction, as input to the hash function. (The value includes hashes of the rows contained in the transaction.) The function cryptographically links all transactions together, like a blockchain.
Ledger functionality is introduced to tables in Azure SQL Database in two forms:
- Updatable ledger tables, which allow you to update and delete rows in your tables.
- Append-only ledger tables, which only allow insertions to your tables.
You create and database with the Ledger with the following instructions.
There is also on option to use system or user assigned managed identities, which is still is preview.
Here are some of the benefits of using Managed identities:
- You don’t need to manage credentials. Credentials are not even accessible to you.
- You can use managed identities to authenticate to any resource that supports Azure Active Directory authentication including your own applications.
- Managed identities can be used without any additional cost.
And there are description for the identities that can be used.
- System-assigned Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity an identity is created in Azure AD that is tied to the lifecycle of that service instance. So when the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
- User-assigned You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it.
How to use the managed identities as a Developer?
Managed identities for Azure resources can be used to authenticate to services that support Azure AD authentication. For a list of Azure services that support the managed identities for Azure resources feature, see Services that support managed identities for Azure resources.
Transparent Data Encryption
With TDE you will bring your own certificates to encrypt the data just like in Azure Information Protection.
You will have keys to access your data not Microsoft. So you have to keep them safe.
Benefits of TDE
Customer-managed TDE provides the following benefits to the customer:
- Full and granular control over usage and management of the TDE protector;
- Transparency of the TDE protector usage;
- Ability to implement separation of duties in the management of keys and data within the organization;
- Key Vault administrator can revoke key access permissions to make encrypted database inaccessible;
- Central management of keys in AKV;
- Greater trust from your end customers, since AKV is designed such that Microsoft cannot see nor extract encryption keys;
How customer-managed TDE works?
For server to be able to use TDE protector stored in AKV for encryption of the DEK, key vault administrator needs to give the following access rights to the server using its unique Azure Active Directory (Azure AD) identity:
- get – for retrieving the public part and properties of the key in the Key Vault
- wrapKey – to be able to protect (encrypt) DEK
- unwrapKey – to be able to unprotect (decrypt) DEK
Requirements for configuring Azure Key Vault
- Key vault and SQL Database/managed instance must belong to the same Azure Active Directory tenant. Cross-tenant key vault and server interactions are not supported. To move resources afterwards, TDE with AKV will have to be reconfigured. Learn more about moving resources.
- Soft-delete and Purge protection features must be enabled on the key vault to protect from data loss due to accidental key (or key vault) deletion.
- Soft-deleted resources are retained for 90 days, unless recovered or purged by the customer. The recover and purge actions have their own permissions associated in a key vault access policy. The Soft-delete feature can be enabled using the Azure portal, PowerShell or Azure CLI.
- Purge protection can be turned on using Azure CLI or PowerShell. When purge protection is enabled, a vault or an object in the deleted state cannot be purged until the retention period has passed. The default retention period is 90 days, but is configurable from 7 to 90 days through the Azure portal.
- Grant the server or managed instance access to the key vault (get, wrapKey, unwrapKey) using its Azure Active Directory identity. When using the Azure portal, the Azure AD identity gets automatically created when the server is created. When using PowerShell or Azure CLI, the Azure AD identity must be explicitly created and should be verified. See Configure TDE with BYOK and Configure TDE with BYOK for SQL Managed Instance for detailed step-by-step instructions when using PowerShell.
- Depending on the permission model of the key vault (access policy or Azure RBAC), key vault access can be granted either by creating an access policy on the key vault, or by creating a new Azure RBAC role assignment with the role Key Vault Crypto Service Encryption User.
- When using firewall with AKV, you must enable option Allow trusted Microsoft services to bypass the firewall.
Azure Key Vault Managed HSM
Azure SQL now supports using a RSA key stored in a Managed HSM as TDE Protector. This feature is in public preview. Azure Key Vault Managed HSM is a fully managed, highly available, single-tenant, standards-compliant cloud service that enables you to safeguard cryptographic keys for your cloud applications, using FIPS 140-2 Level 3 validated HSMs. Learn more about Managed HSMs.
Pricing for Managed HSM
|RSA 2048-bit keys||N/A||€0.863 per key per month1 + €0.026/10,000 transactions|
|Advanced key types1—|
RSA 3072-bit, RSA 4096-bit, and Elliptic-Curve Cryptography (ECC) keys
|N/A||First 250 keys€4.312 per key per monthFrom 251 – 1500 keys€2.156 per key per monthFrom 1501 – 4000 keys€0.777 per key per month4001+ keys€0.345 per key per month+ €0.130/10,000 transactions|
If you want to go really private you can use a Dedicated HSM but bear in mind that the pricing is per hour.
Hourly usage fee per HSM
|Azure Dedicated HSM||€4.183|
As we can see there is multiple options for protecting your data with Azure SQL in rest and in motion.
There is multiple security features built-in to SQL services but also a lot of features outside the pricing of the service itself.