Protecting Oracle Keys with Azure Key Vault
Has anyone used Azure Key Vault to protect keys for on-premises Oracle databases? From what I can see, it isn't a direct integration but rather using Oracle Key Vault for the key management and then integrating OKV with Azure Key Vault as the HSM. Has anyone done this, and is it a supported configuration?Temporary-Access-on-Azure-Resources
Sometimes developers need to access temporarily to Azure resources for troubleshooting purposes or just for the fun 😉 but they don't have always access on Azure to proceed by themselves. That's why I thought to afford them autonomy through Azure DevOps. Of course these pipelines/scripts can be adapted to answer your own context with different Azure services like Key Vault, Storage Account, Database, ... Azure DevOps pipelines Of course, these access, must be temporary, that's why I create: - One pipeline to allow developers to add their public Ip on Azure resources - One pipeline to remove automatically these access each day In our example, the target Azure resource is an App Service, and we add/remove access on Kudu portal. Add IP to Kudu The goal of that Pipeline, based on the allow_ips.yml file is to allow developers to add their public IP on Kudu for different environments like DEV, TST or UAT ones. Application Environment Region Resource Group App Service Variable Group MyApp DEV North Europe - EU MYAPPLICATION-DEV-EU-RG01 MyAppService1 var-devops-app1-dev-eu MyApp TST North Europe - EU MYAPPLICATION-TST-EU-RG01 MyAppService2 var-devops-app1-tst-eu MyApp UAT North Europe - EU MYAPPLICATION-UAT-EU-RG01 MyAppService3 var-devops-app1-uat-eu MyApp UAT East US 2 - US MYAPPLICATION-UAT-US-RG01 MyAppService4 var-devops-app1-uat-us MyApp UAT Australia East - AU MYAPPLICATION-UAT-AU-RG01 MyAppService5 var-devops-app1-uat-au To easily managed the Azure resources in Azure DevOps, I decided to create a varibale group per environment with information like! - Environment - ResourceGroupName - AppServiceName Remove IP from Kudu As mentionned previsouly, these access are temporary, so we created another Pipeline that will be triggered every day at a specific time to remove the IP on Kudu. How to Process to add your IP 1. First step is to add your public IP into the dev_team_ips.txt file combined with **/32** (The format could be different depending of the Azure services you'll need access): Example: **11.22.33.44/32** 1. Launch the first Pipeline by selecting your environment and the region 1. You should be able to connect on the App Service through Kudu Process to remove your IP Two ways to proceed: 1. Launch manually the pipeline to remove the IP 1. Wait until the configured hour that will automatically trigger the pipeline to remove the IP without any human intervention Sources All the content used for these pipelines are attached to that post or can be retrieve on my GitHub https://github.com/onag-fr/Temporary-Access-on-Azure-Resources/?WT.mc_id=AZ-MVP-5005062.NEW PUBLIC PREVIEW FEATURE | Integrate Key Vault with Azure Private Link
We wanted to make you aware of a new public preview feature available to try. Azure Private Link Service enables you to access Azure Services (for example, Azure Key Vault, Azure Storage, and Azure Cosmos DB) and Azure hosted customer/partner services over a Private Endpoint in your virtual network. Now, in preview, you can integrate a key vault with your Azure Private Link. Private endpoint ensures that no customer data leaves their virtual network. It eliminates exposure to your key vault from the public internet and keeps all customer traffic on Azure. If an organization used a public endpoint, they would have to configure a VPN or Expressroute connection to securely connect to key vault via the public internet. If an organization uses service endpoints, all their traffic would remain within Azure but they would have to allow their resource access to all traffic to / from the key vault service (not scoped to one particular vault). Now with private endpoint, you can give each resource access to only 1 particular key vault, which provides a higher level granularity of permissions. Many government, healthcare, and financial institutions have tight regulations and want to plan for "worst case" scenarios in the event of a breach. This provides more redundancy and greater protections. Prerequisites: A key vault An Azure virtual network A subnet in the virtual network Owner or contributor permissions for both the key vault and the virtual network Your private endpoint and virtual network must be in the same region See our public documentation for more information on how to try this feature.
