+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

KEY MANAGEMENT FOR SQL AZURE DATABASE

Posted by Patrick Townsend on Nov 15, 2022 4:57:20 PM

 

Our customers often ask about encryption key management for the Microsoft SQL Azure Database on the Azure cloud. SQL Azure Database is the Microsoft Azure Database-as-a-Service offering based on SQL Server. It is a natural question because SQL Server has a convenient interface for plugging in a key management solution through their Extensible Key Management (EKM) interface. And our Alliance Key Manager has supported this for more than a decade and is available in the Azure marketplace. 

Here’s the rub: 

Unlike normal SQL Server, the Azure SQL Database offering does not support the normal SQL Server key management interface. It does support encryption of the database, but only by using the Microsoft Key Vault service. So Azure customers are locked out of managing and controlling the encryption keys when using SQL Azure Database. 

This is not a problem with Azure itself! We have customers who have deployed SQLEncryption Key Management in Windows Azure Server in a virtual machine on Azure and use our Alliance Key Manager in Azure with no problems! Microsoft does not allow the use of a key manager and only allows the Azure Key Vault or a Bring Your Own Key (BYOK) option..

Is there anything you can do? 

Sure! Let me describe one approach you can use in a web application that uses SQL Azure Database that gives you exclusive control and access to your encryption keys, and supports a real time mirroring of encryption keys to a key server outside of the cloud. And a bonus is that if you are mirroring data out of the cloud to an on-premise SQL Server database, the key management synchronization and failover will be automatic.

Here is what to do in Azure:

First, deploy Alliance Key Manager right from the Azure Marketplace. It will automatically license for a 30 day no-cost evaluation period (Azure charges may apply). When you access the key manager in Azure Marketplace you will have a link to documentation, and you will be eligible for technical support. Create an AES key to use for encrypting data in SQL Azure Database. Here is the quick start guide to help you get started:

https://docs.townsendsecurity.com/akm_for_microsoft_azure_quick_start_guide

Then, modify your Windows .NET application to make a call to Alliance Key Manager to encrypt or decrypt information using the AES key you created before you insert or update data in a column. Alliance Key Manager provides a simple Windows .NET SDK to make this easy. There is no charge for the SDK and you can download it from the Townsend Security website. Here is the link to the Windows .NET SDK:

https://docs.townsendsecurity.com/akm_guide_for_windows_dot_net_developers

Backups of the Azure SQL Database and all data you copy out of Azure will now be encrypted and under your control. 

What to do in your data center:

You can easily mirror encryption keys from Azure to your own data center. Download Alliance Key Manager for VMware, launch it in your VMware environment, and set up mirroring between Alliance Key Manager in Azure and Alliance Key Manager in your data center. Keys are mirrored in real time and your on-premise applications can use the same logic as in the cloud to decrypt data as needed. Here is the VMware quick start guide:

https://docs.townsendsecurity.com/akm_for_vmware_quick_start_guide

Your applications in your on-premise deployment can now use the same Windows .NET SDK as mentioned above to do decryption when needed.

Voila!

You now have your data encrypted in SQL Azure Database, in your on-premise SQL Server database, and you have full control of your encryption keys! You also have a lot more flexibility about your choice of Cloud Service Providers. 

A few more thoughts:

Triggers, UDFs and Stored Procedures

If modifying your applications is not feasible or costly, consider adding Triggers and Stored Procedures to the database to achieve encryption and decryption tasks. This can be much easier to implement than making code changes. See the resources below to get started.

How to implement User Defined Functions and Stored Procedures in Azure SQL Database:

https://bookshelf.erwin.com/bookshelf/public_html/2020R1/Content/User%20Guides/erwin%20Help/Define_SQL_Azure_Stored_Procedures.html

And

https://www.sqlshack.com/executing-stored-procedures-from-data-pipelines-in-azure-data-factory/

And Alliance Key Manager provides guidance on Triggers and Stored Procedures:

https://docs.townsendsecurity.com/akm_guide_for_windows_dot_net_developers

Mirroring keys in the cloud

Sometimes you are not mirroring SQL Azure Database data to your on-premise database. If you have a backup strategy that involves failover to another Azure availability zone be aware that you can run a second copy of Alliance Key Manager in that zone. Alliance Key Manager will mirror encryption keys across any availability zones and regions.

Mirroring keys to AWS

If you really want to mirror your encryption keys out of the Azure cloud, but don’t want to bring the keys in-house, you can mirror them to AWS! Alliance Key Manager is also available in AWS and fully supports cross-cloud key mirroring.

Alliance Key Manager for Windows Azure - complimentary product evaluation

Topics: Encryption, Microsoft Azure, KMS

Your KMS as an Early Warning System for a cyber attack

Posted by Patrick Townsend on Jun 2, 2022 1:28:54 PM

Cyber-attacks are executing at much faster speeds now. In the past you might find that an attacker waited weeks or months after gaining access to your system before stealing sensitive data. Those days are mostly gone. An attacker now can execute in a few minutes or hours. Early detection is critical for interrupting an attack. And a fast response is crucial to stopping the attack.Encryption Strategies for VMware Environments

There is a good chance that you are already encrypting your sensitive data to prevent it from being used for extortion by a ransomware attacker. If you are already encrypting your data, you are also probably using a key management system (KMS) to store your encryption keys. That is a security best practice, and the right thing to do.

Are you ready for the next step?

Did you know that your KMS can play an important part in early detection of an attack? Your key management system should be collecting key retrieval activity into real-time logs. For example, our Alliance Key Manager logs every single action that takes place including key creation, retrieval, deletion, and so forth. Why not use these logs to help detect an attack? After all, the attacker is going to try to steal the data, and that means there will likely be activity on the key manager. And that means a KMS log can help you thwart an attack.

How can we implement this in a real environment?

Our Alliance Key Manager solution comes with log forwarding capability already built in. It is easy to start forwarding the KMS activity log to your SIEM solution using the common syslog-ng protocol. All SIEMS can ingest the KMS activity log, so just start forwarding them.

Next, train your SIEM to detect anomalies. A good SIEM is really good at anomaly detection! So let’s put it to work. Here are some KMS events that should be early warning signs of an attack in progress:

  • Retrieving an encryption key at an unusual time of the day.
  • Retrieving an encryption key on an unusual day.
  • Failure to retrieve a key for an extended period of time.
  • Unusually high level of key retrieval requests.
  • Unexpected user attempts to retrieve a key.
  • Attempts to retrieve a key that does not exist.
  • Failed TLS negotiation to retrieve a key.
  • Key retrieval request from an unusual IP address.

As you can see there are many events or patterns that can indicate the activity of an attacker. And KMS logs are likely to show this activity early in the attack. Training your SIEM to alert on this activity is usually pretty easy to do, but that depends on the functions of the SIEM.

Another big bonus for integrating the KMS with your SIEM is that many SIEMS can now take pro-active and automatic steps to thwart an attack. In addition to alerting the IT staff of a potential attack, some SIEM solutions can execute scripts that take a database off-line, or even take the key manager off-line. You can get very creative with the automatic responses to a cyber-attack.

Your KMS can be your “canary in a coal mine”. The features are there ready to be put to use.

If you are running our Alliance Key Manager solution just raise a problem ticket with our support team to get some pointers on how to forward logs to your SIEM. It will be easy to do.

PatrickPodcast: State of Encryption Key Management

Topics: Encryption, Key Management, Ransomware, KMS

Blog-CTA-VMware-CSP
 
The Definitive Guide to AWS Encryption Key Management
 
Definitive Guide to VMware Encryption & Key Management
 

 
 

Recent Posts

Posts by Topic

see all