We're wanting to automatically rotate our Azure Search Admin and Query keys with our Key Vault on a regular basis. Is there a recommend way to do this?
Ideally we'd be able to use Managed Identity to access the Search service, but that doesn't seem to be supported yet.
The key rotation process relies on the fact that the services have both a primary and a secondary key. Both keys are valid for any requests, and they can be changed independently of each other. We’ll deploy our azure search, which will include referencing that key and making sure our application uses it. Then we’ll rotate the other key.
You could refer to this article to set up key rotation using Azure Automation.You'll use PowerShell combined with Azure Automation to change an Azure search admin key. You'll then update a key vault secret with that new key.
Related
I have an IdentityServer4 app running on App Engine. As I prepare for production, I have a lot of confusion using .AddSigningCredential() in this scenario. In app engine, I don't have a file system to cert store in a traditional sense, and it seems like I can only pass in a path to a cert/key or the contents itself.
As I'm hosting on Google Cloud, I would like to use KMS. The API for KMS gives me the ability to sign something, but Identity Server doesn't give me a way to use that, and I don't see a way for KMS to give Identity server what it wants.
The only workaround I came up with is to generate a key pair, save it as a secret, and pass that in to .AddSigningCredential(). The downside is that now I have to manage this key/secret manually. There must be another way.
I’m currently working with a customer where we are deploying a number of Azure PaaS services via ARM templates.
The deployment runs in VSTS in service principal context.
As part of the deployment we need to specify an application ID and key for ACS.
So far we have made do with a key which was manually generated and passed to us.
We would like however to be able to generate new keys on the fly, both when applications change and to be able to do basic key management to avoid having keys expire on us.
Looking at the options though it seems as if the only way to achieve this is by setting Read and Write to all Applications in Settings/API Access/Required Permissions/AAD for the requesting Application/SSPI.
Is that really the only way or am I going about this in the wrong manner?
Using the Microsoft Graph API I need to be able to update the attribute proxyAddresses as part of our provisioning process to enable self-service password management for our end users.
I see that this attribute is read-only from the Graph API but as of 8 months ago MS was entertaining the possibility of making it RW. Does anyone have any color on this, has anyone found a workaround to this issue via API?
This isn't supported in either v1.0 or Beta at the moment but this is an open OverVoice request for this feature: Ability to update the user's email aliases (proxyAddresses attribute).
Also if you are working with bigger customers - usually you want to sync their identities from local Active Directory using AD Connect tool. In that case you should implement things and change proxyaddresses attribute in local AD, because it is the "identity authority" (means that you can't change it on cloud side and it must be done in on-prem AD).
So it could be workaround for problem you are trying to solve.
Also if it is cloud only (not synced) identity - you can use PowerShell to modify proxyaddresses attribute on users.
Here is documentation on how to do that - https://technet.microsoft.com/en-us/library/bb123794(v=exchg.160).aspx
I accidentally deleted a bunch of entities earlier today in Google App Engine and found out later that some of them should not have been deleted. I have the keys for the entities I deleted as well as a lot of information about the entities stored in a secondary database. I was wondering if there was any way to create entities with specific keys in app engine or if there was alternative method of recovering these entities? I am very worried
I was wondering if there was any way to create entities with specific keys in app engine
You can create new entities with those same keys, just set the key property on the instance of the model before you put and it will use that key instead of generating a random one for you.
Also, check if your team has used datastore admin to take snapshots, if so, you may be able to recover them from there:
https://console.cloud.google.com/datastore/settings
What would be the least expensive and PaaS-agnostic ways to protect and separate sensitive data in a multi tenant application which is using a shared database?
Some background info and more specific questions:
We are a small startup company. We have successfully launched an intranet web application project for a customer, and now we feel ready to offer a cloud solution for similar kinds of customers.
As we are on Microsoft BizSpark program, we are investigating Azure App Services. We might migrate later to Cloud Services, but for now it seems that App Services will be enough. Still, we don't want to tie ourselves to Azure too much in case we would want to move to other SaaS provider later.
Our application will store some sensitive information which should be protected. Separate encrypted (Azure provides transparent encryption) databases for each tenant would offer the most security, but we have no budget for such solution and it would be hard to manage automatically.
Currently our plan is that we will offer our customers to register a subdomain under our wildcard domain and then internally we map the subdomain to tenant ID which will be used in each table.
This seems to be the most cost-effective solution for a startup company because there are no additional management for every additional tenant, and registration can be fully automatic. I understand that we'll have to be super careful to enforce the use of tenant ID in every SQL request (using SQL views and stored procs with built-in tenant ID query will help), but that's obviously is not enough. We need some mechanism to protect each tenant's sensitive data with some encryption key.
And then some questions come:
should we use a single encryption key for all the sensitive data for all tenants? or should we have a separate key for each tenant?
if we go for separate keys (generated randomly at the moment of registration, so the key won't be known even for us), then who and how should store and protect the tenant encryption key? Should we give the key to the tenant and then ask his employees to provide the key in addition to each employee's login name and password every time they log in through web browser?
what approach would work best considering that we might later need sharding or "elastic" database scaling as some PaaS providers call it, and that we might move from Azure and Microsoft SQL Server to something else?
If someone has experience with multi-tenancy & database protection, I'd really appreciate some advice, some do's and dont's and possible caveats. I have read some articles about the topic but they often are too specific to PaaS platforms or do not explain possible consequences and difficulties, but that knowledge comes only from day-to-day experience and trials&errors.
Adding some answers for completeness sake (2yrs later):
should we use a single encryption key for all the sensitive data for all tenants? or should we have a separate key for each tenant?
You should have a separate key for each tenant. Not sure how Azure does it but AWS has KMS for this usecase
if we go for separate keys (generated randomly at the moment of registration, so the key won't be known even for us), then who and how should store and protect the tenant encryption key? Should we give the key to the tenant and then ask his employees to provide the key in addition to each employee's login name and password every time they log in through web browser?
Use KMS (or something similar on other clouds, homegrown solution like Square's keywhiz). You don't need to give the key to tenant. All you care about is - if the user has authenticated using their password (or SSO), based on their permissions, they have access to some resources.
what approach would work best considering that we might later need sharding or "elastic" database scaling as some PaaS providers call it, and that we might move from Azure and Microsoft SQL Server to something else?
You need a tenantId which will help with data isolation. Now the actual data linked to tenantId can be encrypted based on a key stored in KMS.