I am planning to write an Azure Function that will communicate to DocuSign through DocuSign API.
I am using JWT for authentication and what I am worried about is storing the Access Token.
The access token expires in 1 hour. As the Azure function is stateless, I have to put the access token somewhere to reuse it.
My question is about securely storing this token in Azure.
I think the below services from Azure can serve me
KeyVault
Memchaed
Azure Caching
Azure SQL
Which will be best? I do not want an expensive service to serve this purpose.
I think if you want to store the token, you can use KeyVault to realize your ideas. The communication between the resources in KeyVault and Azure is based on the Azure backbone network, so as long as Azure is safe, then KeyVault is safe. And, KeyVault was originally designed to acheive your current requirement.
I think you should use redis ( or maybe DB for your case is easier/better )
Azure has redis, you can simply use that.
And why not Azure Key Vault ?
Look at docs:
Docs
Secrets, managed storage account keys, and vault transactions:
Transactions type Maximum transactions allowed in 10 seconds, per vault per region1
All transactions 4,000
its because of transactions limits. You should not hit Azure KV so often.
Also interesting quote:
Cache secrets in your application for at least eight hours.
About redis, you can read it here: DocsRedis
The app uses a Redis cache as the backing store
tutorial
Related
Like most Azure Functions in the beginning we have a connection string to the associated storageaccount that includes the Accountkey like this
DefaultEndpointsProtocol=https;AccountName=ourstorageAccount;EndpointSuffix=core.windows.net;AccountKey=WQfbn+VBhaY1fi/l0eRBzvAvngiCiOwPmx/==
We obviously want to remove that AccountKey. I had hoped we could use ManagedIdentity and the 'Contributor' Role but what I am reading is telling me you cannot use Managed Identity to access Tables in a Storage Account only Blobs.
I know that we could move the whole connection string to KeyVault but that just becomes ann Azure Management Issue if we want to rotate the keys.
Has anyone succesfully controlled access to Azure Table Storage with Managed Identities?
If not what is the next best approach that preferably allows for simple rotation of keys?
Has anyone successfully controlled access to Azure Table Storage with Managed Identities?
Definitely it is unable to access azure table storage with MSI(managed identity, essentially it is a service principal in azure ad), when using MSI to access some azure resources, it essentially uses the azure ad client credential flow to get the token, then uses the token to access the resource.
However, azure ad auth just supported by azure blob and queue storage, table storage doesn't support it currently, see - Authorize access to blobs and queues using Azure Active Directory.
If not what is the next best approach that preferably allows for simple rotation of keys?
You could use azure function to do that, follow this doc - Automate the rotation of a secret for resources with two sets of authentication credentials, I think it completely meets your requirement, this tutorial rotates Azure Storage account keys stored in Azure Key Vault as secrets using a function triggered by Azure Event Grid notification.
Need to store some content in Azure Blob Storage, and want to encrypt prior to storing it on Azure Blob (we don't want to rely on Azure storage encryption on-rest). The issue is we do not want to store our encryption keys on Azure (e.g. Key vault), and store it outside of Azure. Any suggestion on strategies for achieving this?
The issue is we do not want to store our encryption keys on Azure (e.g. Key vault), and store it outside of Azure.
Azure Storage Service Encryption doesn’t allow us to use our own encryption keys until now. To use your own encryption keys and store it outside of Azure, you need to create a proxy for your storage service.
For example, you could create a Web API to handle all the blob read/write requests. In your Web API, you could use your own encryption keys to encrypt or decrypt data and then write or read the data to Azure Blob Storage.
The limit of this way is that we can’t use the Azure Storage Client library or other tools to access the storage proxy (Web API) since it is written by yourself.
Any suggestion of on-premise secret options we can use, which are accessible to components on Azure.
I suggest you store the key on your local side and create a internal API which could return this key. To access this internal API from azure components, you could use hybrid connections.
Access on-premises resources using hybrid connections in Azure App Service
I deploy Asp.Net Core web app and I need to build a storage for private keys of my clients (it is a lot of values). What should I use: Azure Key Vault or Data Protection APIs?
The second seems more easy to programming, however there is information from docs:
The ASP.NET Core data protection APIs are not primarily intended for
indefinite persistence of confidential payloads...
But I need to store keys long-term.
If you're using the keys to protect data for long term storage, I would advise you to use Azure Key vault.
Azure Key vault is a high availability service designed for storage of secrets and keys. Keys and secrets are automatically copied to Key vault instances in multiple regions and easily backed up securely using PowerShell cmdlets. You can store them in an HSM if you are dealing with highly sensitive data.
The Data Protection APIs are more designed to protect local or ephemeral data.
You should use Azure Key Vault to store your keys. The Data Protection API is always used in your application, for example it is used to encrypt and secure your session cookie.
But don't forget that you also do need to configure and store the data protection keys in a secure place. If you don't do it properly, then uses might be kicked out of your site when you redeploy.
See this document for more details:
Key storage providers in ASP.NET Core
If you do want to store the Data Protection Key ring in AKZ, then check out my implementation here:
Storing the ASP.NET Core Data Protection Key Ring in Azure Key Vault
I'm finding the documentation on the Azure storage REST services a bit confusing.
How do I authenticate and consume an endpoint from Azure storage services over cURL?
I have:
the url
primary key
secondary key
I just don't know what to do with them to make a proper request.
You can refer to this documentation: Authentication for the Azure Storage Services, both primary key and secondary key can be used for authentication, you can choose any of them.
I have a web role that talks to Azure Storage, Azure Shared Cache Service and Azure SQL Databases. It is only ever the web roles that communicate with these storage mediums, and never the client browser. The Azure Table Storage contains sensitive data, but the cache and SQL databases do not.
Question is, if all data access goes over plain HTTP, is there a risk that someone can intercept my packets, and read my storage key? If so, who can sniff these packets - just Microsoft employees, or do I need to worry about other Azure tenants that might have effected a jailbreak?
A few things to consider:
If your webrole and storage accounts are in the same data center, then the traffic is contained within data center. In that case, going of HTTP would not create any problems IMO. However if the webrole and storage accounts are in different data centers, then definitely make use of HTTPS.
Since you never send your storage account key with your requests to storage, you can be assured on that part. What you do is sign the requests using your key (or the storage client library does) and send that signature as a part of your requests. I don't think one would be able to reverse engineer that signature to get your storage account key.
HTH.
In addition to the previous answers, you should also take a look at the official security whitepaper: Windows Azure Security Overview. It talks about how isolation and packet filter secure the communication in the datacenter.