With my on-prem KMS, I rotate keys monthly. Can I also do that with Cloud KMS? Is there a better recommended frequency compared to my on-prem use? Is data re-encrypted when I rotate a key?
Your desired frequency of key rotation depends on your use case and threat model. You want to limit the amount of very sensitive data encrypted with a single version of an encryption key.
On Google Cloud Platform, Google's Cloud KMS can be set to automatically rotate keys as often as once per day. This means that a new key version is automatically generated, and made the primary version used to encrypt new data. Most customers will typically choose 30 or 90 day rotation periods, based on business requirements.
Data is not re-encrypted when a key is rotated - rather, the new key version is used to encrypt any new data, but old data is not re-encrypted. You can manually do this by decrypting and re-encrypting the data.
For further discussion on key rotation in Cloud KMS: https://cloud.google.com/kms/docs/key-rotation#frequency_of_key_rotation
To set the rotation period on a key, using gcloud run:
gcloud beta kms cryptokeys set-rotation-schedule CRYPTOKEY_NAME \
--location LOCATION --keyring KEYRING_NAME \
--rotation-period ROTATION_PERIOD \
--next-rotation-time NEXT_ROTATION_TIME
Related
Good morning everyone,
I have been dealing with the topic of CMEK/CSEK/KMS for a few days now, and I can't get any further with the documentation available to me from Google. My latest reading was the following: About customer-managed encryption keys (CMEK)
Scenario: data in the GCS bucket is encrypted with the current primary CMEK. A key rotation occurs after x days. If I want to disable the old key, then I would need to initiate a manual re-encrypt of all data in the bucket as described in Re-encrypting data. Correct?
Scenario: I have a managed SQL (PostgreSQL/MySQL) instance initially encrypted with a CMEK. There is a key rotation after x days. If I want to deactivate the old key, what do I do with the data in the managed SQL instance?
The document About customer-managed encryption keys (CMEK) reads as if a deactivation of old CMEKs is not intended, because with a deactivation of the key among other things backups would not be accessible, which is understandable. What do I do if I suspect that my key has been lost? How could I, for example, make the instance available to an audit? Is it possible to re-encrypt a managed SQL instance or VM and if so, how?
I ask myself the same question for VMs. How do I re-encrypt VMs so that I can deactivate the old key after successful rotation? My current thoughts are: create new VMs and copy data. For managed SQL: create a secondary (replica) and promote it to primary. Alternative: SQL dumps. But this seems a bit...
Thanks for your help,
Cheers
I have an Azure EventHub which already has records. I need to get a list of unique partition keys within this EventHub. This I need to use for a specific custom logic in my processor/consumer. Appreciate any suggestions or workarounds.
I'm not sure if you're possibly conflating a partition id and partition key; the former is a core concept for Event Hubs and can be queried using the SDKs for any of the supported languages, the command line, or the REST interface directly. An example for the .NET client library can be found here.
The Event Hubs service does not persist or expose the partition keys used when publishing an event. When an event batch with partition key is published, the service produces a hash based on that key and uses that hash value to select a partition to which the event should be routed. The same key is guaranteed to produce the same hash and route to the same partition. Since the hash value is stable for a given key and the key itself does not have meaning to the service, it is calculated on-demand.
In your case, it sounds like you'd like to understand what key was used when the event was published in your downstream consumer as you're reading it from the service. I'd recommend using the Properties bag of the event to hold hold onto the key that you've chosen and associate it with the event.
The Properties are intended to hold arbitrary data that is meaningful to your application and bundle it with your event as it passes through the system. An example of including custom metadata in the Properties using the .NET client library can be found here.
When encrypting symmetrically with Google Cloud's KMS, Google Cloud automatically chooses the primary key version:
Each symmetric encryption key has a designated primary version which is used at that point in time to encrypt data. In order for a key to be available for use to encrypt data, it needs to have a primary key version which is enabled.
When a key is used to encrypt plaintext, its primary key version is used to encrypt that data. The information as to which version was used to encrypt data is stored in the ciphertext of the data. Only one version of a key can be primary at any given point in time.
The EncryptResponse includes the ciphertext and the version of the key that was used.
If you haven't saved the version of the key at the time of encryption, is it possible to determine the key version later? The key version is stored in the ciphertext, and the KMS service is able to determine the key version to decrypt with, but the DecryptResponse only includes the plaintext, not the key version.
This is not currently possible but we've taken a feature request to provide the version when decrypting. Thanks for the suggestion and thanks for using GCP and Cloud KMS!
I have a requirement to secure the private key which is used for signing a blockchain transaction. While we are evaluating option of using HSM (Hardware Security Module), I was equally wondering about the applicability of Google Cloud KMS. Your help will be highly appreciated if you can answer my following queries :)
Can we save a key in Google Cloud KMS which may have been generated outside?
Assume that I have already saved my private key in Google Cloud KMS, which one of the following is true/possible?
Using an API call, the key stored in KMS is retrieved first and then it can be used to sign the blockchain transaction. But in this case, security can be compromised once the key is outside the KMS.
The key never leaves Google Cloud KMS once stored. Instead, a blockchain transaction can be sent to Google Cloud KMS for signing the transaction using the key managed by it. Here I assume that KMS may provide me some customization features so that I can execute the signing process or KMS may have capability to execute a piece of code.
Google Cloud KMS can't execute specialized tasks (like signing a Blockchain transaction), it just does the encryption/decryption only.
Cloud KMS doesn't store keys for retrieval; instead, it stores keys and keeps them secret. I believe your third bullet is closest to the situation.
In your situation, I would suggest wrapping the blockchain private key with a KMS key and then storing the wrapped private key somewhere. To sign a transaction, the app would use KMS to unwrap the key then sign it in software locally.
Yes, this exposes the calling app to the private key and makes you responsible for that security.
A question: what algorithm would you like signing support for? Google NEXT is next week, look for some announcements from us that you might be interested in.
I have a security issue with one of our distributors. I need to prevent them from accessing certain data in our database. Because they administer the database I can't use password controls on the database itself to protect the data. I'm thinking that I need to encrypt the sensitive data in the database and have the encryption key embedded in software that we create. That way the distributor can poke around in the database all they want but the sensitive data will be unintelligible to them. I see how this might be done in MYSQL. There is are ENCODE and DECODE functions that allow me to pass a key in as a parameter. I can embed these keys in a piece of software, lock the software down, and this will allow me to insert and retrieve information. But what about MS SQL. How can I encrypt data so that even someone who is an administrator of the database cannot read that data?
Thank you,
Elliott
For MS SQL there is tons of documentation on encryption, and based on what you said about MYSQL I think you will be most interested in the Cryptographic Functions.
Note that I would be careful on which methods you encrypt with your own key, as a trace on the database or other means could be used to still obtain the key by inspecting the SQL commands you are sending.
There is definitely encrypt/decrypt functionality in MSSQL:
http://blogs.msdn.com/b/lcris/archive/2007/10/03/sql-server-2008-transparent-data-encryption-feature-a-quick-overview.aspx
http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/ [this one is a tutorial]
You probably want the code based one, as opposed to file encryption...
From this article: http://www.sql-server-performance.com/articles/dev/encryption_2005_2_p1.aspx
(Which BTW is the first result for a google search of encrypt data sql server)
Symmetric Keys
A Symmetric Key is a one key that is used for both encryption and decryption. This is a fast, commonly used method for encryption. As with a certificate, many parameters are available when creating Symmetric Keys. In most cases, we only need a limited set of parameters. You can refer to Books Online for all the parameters.
CREATE SYMMETRIC KEY TestSymKey
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY CERTIFICATE CertificateTest2
You can specify an encryption algorithm for a symmetric key. DES, TRIPLE_DES, RC2, RC4, DESX, AES_128, AES_192, and AES_256 are the encryption algorithms available for SQL Server data encryption. AES encryption algorithms are currently supported only on Windows 2003. If you are using Windows 2000 or Windows XP, you do not have access to AES encryption algorithms from SQL Server. If you try to use an AES encryption algorithm, you will get an error:
Either no algorithm has been specified or the bit length and the algorithm specified for the key are not available in this installation of Windows.
You can encrypt a Symmetric Key using PASSWORD, SYMMETRIC KEY, ASYMMETRIC KEY, or CERTIFICATE.
The ALTER SYMMETRIC KEY and DROP SYMMETRIC KEY commands are also available to improve maintenance.
After the creation of a Symmetric Key, it is just a matter of using it. There are three functions you can use with Symmetric Keys: Key_GUID, EncryptByKey, and DecryptByKey.
OPEN SYMMETRIC KEY TestSymKey
DECRYPTION BY CERTIFICATE CertificateTest2;
DECLARE #Encryptvalsym varbinary(MAX)
SET #Encryptvalsym = EncryptByKey( key_guid('TestSymKey'),'scott')
SELECT convert(varchar(max),DecryptByKey(#Encryptvalsym))
Before using SYMMETRIC KEY, you need to open it by using the OPEN SYMMETRIC KEY command. To encrypt data you need to pass the GUID of the Symmetric Key. However, to decrypt it you don't have to pass the GUID. Instead, you have to open the encrypted Symmetric Key using the correct decryption method and value.
To increase the security of Symmetric Keys, you can add an authenticator during encryption. You have to use the same value during decryption.
OPEN SYMMETRIC KEY TestSymKey
DECRYPTION BY CERTIFICATE CertificateTest2;
DECLARE #Encryptvalsym1 varbinary(MAX)
SET #Encryptvalsym1 = EncryptByKey(key_guid('TestSymKey'),'scott',1,'SQL Server')
-- Decryption with Symmetric Keys
SELECT convert(varchar(max),DecryptByKey(#Encryptvalsym1,1,'SQL Server'))
I would skip the database centric algorithms and move it to a software managed solution. That way you can completely avoid the key ever being sent over the wire and compromised by a packet sniffing admin. (This is of course assuming you are using default transports for your database connection)
I've used this link as a reference for creating my DataSecurity library. I prefer the software managed scenario because it allows you to go as heavy or as lightweight as the solution requires, and it allows you to manage the keys in a way that compromising your database does not mean that your data gets compromised as well.