<- Back to the blog

Cloud Crypto Providers Part III - Logging Crypto Operations

Graham Steel
March 28, 2018
compare cloud crypto providers

This is the third post in a series about cloud crypto functionality provided by the "big three" cloud providers - Amazon Web Services, Microsoft Azure, and Google Cloud Platform (you can find parts one and two here). Having set up an application and protected its keys with the cloud provider's crypto API, we'd like to be able to monitor usage of these keys and any key management operations that take place, to be sure all is well and to meet audit requirements. What facilities do the big three providers offer for this?


In Amazon cloud your KMS operations can be linked up to CloudTrail to provide a log of all operations. Looking at a sample entry for, e.g., a Decrypt operation, we can see that the entity that requested the call is identified, as well as the return code from the operation, in this case "InvalidCiphertextException". There is also a function to add monitors to CloudWatch for certain KMS events. You can get an alert if a KMS CMK is deleted or if imported key material is nearing expiration for example.


Google Cloud Audit Logging records by default all KMS admin operations, such as key creation or destruction, but not data access operations like encrypt and decrypt - these have to be specifically enabled. There are no samples in the docs but the description of the log suggests they contain similar info to AWS: the user who made the request, the resource, and the outcome. Stackdriver Monitoring can be used to set up alerts for any of the events in the logs.


In Azure Keyvault logging all events are logged including admin operations and data access operations. A sample JSON blob shows how this looks in practice. Again we can see the usual requester, resource identifier and result information.Surprisingly, Azure Key vault doesn't seem to support alerts e.g. for expiring key material. There is an unanswered question about it on MSDN.


Three three big providers offer similar functionality, with a few small differences in how logging is set up and the facilities for alerts. However, none of the logs are detailed enough to monitor cryptographic policy. For example, one cannot see whether associated data is used or not in encrypt/decrypt operations. The Key import command in AWS does not appear to be logged, so one can't check that the secure RSA padding was used, and this level of detail seems to be absent from Azure logs as well. It is clear that a more fine-grained analysis is required to be sure our application uses its cloud KMS in a secure way.

For more information on cloud KMS offerings read our white paper.