When bringing any new technology into an enterprise, security is of course a paramount concern. Let’s go “under the hood” and examine in detail how Akumina safeguards business information to provide a trusted infrastructure.
The challenge: Delivering scalability with security
The Akumina AppManager and Service Hub provide the scalability and centralization service layers for the Akumina platform. They reside and execute within a Microsoft Azure account and as part of their function are in frequent contact with the Microsoft Graph, Office 365 APIs, and APIs or web service interfaces for other cloud or on-premises systems.
Microsoft Azure storage services provides client-side encryption as well as an encryption at rest technique to protect data that is transmitted and stored in Azure Storage such as Blob, File, Table, Queue, etc.
Security is of utmost importance to Akumina, and the encryption of tokens, access keys or other identifying information required for access to these systems is managed according to best practices from Microsoft Azure architects and consultants.
Inside our encryption
The Akumina AppManager and Service Hub provide a storage encryption layer built on top of Microsoft Azure Storage Services. The Akumina AppManager and Service Hub are designed to support custom, client-side and server-side encryption techniques using a simple configuration.
To begin work with Azure storage we need a connection string. The connection string can be stored within code or in locations such as web.config, app service settings, etc. Alternatively, the connection string may be stored in the Azure key vault, but to access the key vault the code still needs credentials such as Client ID, Client Secret, etc. Azure Managed Service Identity (MSI) solves this issue by automatically creating identity for the service instance in the Azure AD tenant.
Client-Side Encryption using Envelope techniques
Data can be encrypted using Azure Storage client library prior to sending the data to the Azure Storage.
- The object data is encrypted using a content encryption key (CEK) generated buy the storage client library.
- The CEK is then wrapped (encrypted) using a key encryption key (KEK).
- For tighter security, the encryption key is stored in the Azue Key Vault, ensuring that only authenticated users/applications can access it.
- Encrypted data along with the KEK are transmitted via https to Azue Storage.
- For data retrieval, the process is reversed. Encrypted data is retrieved from Azure Storage and decrypted using the encryption key stored in the Azure Key Vault.
- The following diagram explains the encryption/decryption flow:Server-Side Encryption Data can be encrypted in server side at rest using:
- Server-managed keys
- Customer-managed keys in Azure-Key Vault
- Customer-managed keys on customer-controlled hardware
- Server-Side Encryption using Storage Service Encryption
Storage service encryption is an additional layer of encryption that protects data at rest. Azure Storage Service encrypts your data as it’s written in Azure datacenters, and automatically decrypts it for you as you access it. This can be configured directly in your storage account using the Azure portal or through your APIs.
- Akumina Data Encryption The Akumina AppManager and Services Hub will not store any business data. However, any session-specific or performance-related data can be configured to use following encryption techniques:
- Custom Encryption: Customer configures Akumina in-build AES256 encryption or any custom implementation.
- Client-Side Encryption: Akumina implements client-side encryption suing Azure Key Vault and Storage SDK.
- Server-Side Encryption: Customers can configure server-side encryption in Microsoft storage service
- Combining Encryption Methods
- Note that client-side and server-side encryption can be used together to maximize the security of the data. However, keep in mind that with any encryption there is some overhead involved, which can have some impact on performance.