Building secure cloud applications
with Azure Key Vault
Tom Kerkhove
Azure Consultant at Codit, MSFT Azure MVP
Expo Sponsors
Event Sponsors
Expo Light Sponsors
Nice to meet you
Tom Kerkhove
• Azure Consultant at Codit
• Microsoft Azure MVP & Advisor
• Belgian Azure User Group (AZUG)
blog.tomkerkhove.be
@TomKerkhove
tomkerkhove
Web
Worker
Appsettings.json
Great! Let’s ship it?!
× No centralized secret management
× No secure storage for sensitive information
× No way to revoke access for a specific user/application
× No way to updating secrets when they have expired/been rolled
× No control over whom has access
Introducing Azure Key Vault
• Provides secure storage for sensitive information, including storing
cryptographic keys in hardware security modules (HSM)
• Automatically failing over to secondary region in read-only mode
• Allows you to :
• Store sensitive information as secret
• Use keys for cryptographical purposes
• Manage certificates
Keys & Secrets
• Secret
• Used to store sequences of bytes
• Consumers can read & write
secret values to it
• Encrypted before stored in vault
• Limited to 10 kB
• Typically used for connection
strings, authentication keys, etc.
• Key
• Stores a RSA 2048, 3072 & 4096 key
• Can be used to perform crypto
operations such as encryption &
signing
• Can’t be read back
• Higher latency
Different types of keys
• Software Keys
• Operations performed on VM in
Azure
• Typically used for Dev/Test
• Cheap
• HSM Keys
• Stored encrypted in HSM
• Operations performed on HSM
directly
• Requires Premium Vault
• More secure
https://twitter.com/IrisClasson/status/976768821217415168
https://blog.nuget.org/20180322/Incident-Report-NuGet-org-downtime-March-22.html
Use
Certificates
Certificate
lifecycle
management
Personas
Authenticating to Azure Key Vault
• Authentication is fully handled by Azure Active Directory
• Only works for the default Azure AD directory
• Use basic or certificate authentication
• However, you still need to store authentication information in your
configuration
private async Task<string> AuthenticationCallback(string authority, string resource, string scope)
{
var adApplicationId = configuration.Get<string>("KeyVault.Auth.ApplicationId");
var adApplicationSecret = configuration.Get<string>("KeyVault.Auth.AppSecret");
var authContext = new AuthenticationContext(authority);
var clientCredential = new ClientCredential(adApplicationId, adApplicationSecret);
var token = await authContext.AcquireTokenAsync(resource, clientCredential);
return token.AccessToken;
}
Authenticating to Azure Key Vault
Web
Worker
Appsettings.json
Vault Owner
Receive Token
Authenticate
Demo
Great! Let’s ship it?!
✓ Control over whom has access
✓ Centralized secret management
✓ Secure storage for sensitive information
✓ Capability to revoke access for a specific user/application
✓ Capability to update secrets when they have expired/been rolled
× Keys to the kingdom are still stored as before
Enter Azure AD Managed Service Identity (MSI)
• Delegate authentication to the Azure resource that runs your app
• Azure Resource Manager will create & assign an Azure AD
Application to your resource
• Currently only supports system-defined
AD Application names
• Not all Azure services support this, yet
• No authentication information nor
authentication logic required
• Super easy and more secure
Demo
Web
Worker
Receive Token
Authenticate
MSI
Great! Let’s ship it?!
✓ Control over whom has access
✓ Centralized secret management
✓ Secure storage for sensitive information
✓ Capability to revoke access for a specific user/application
✓ Capability to update secrets when they have expired/been rolled
✓ Authentication delegated to Azure
❕ Not all Azure services already support MSI
Authorization
Authorization
• Managing vault instance (“control-plane”)
• Based on RBAC roles
• Managing vault contents (“data-plane”)
• Defined in “Advanced Access Policies”
• Granular control over assigned permissions
• Permissions defined on a vault-level
• Assigned to AD user, group or application
• Ie. only set secrets without being able to see them
Demo
Authorization
• Be careful about whom can manage your vault instance
• Take into account that people can add themselves to permissions to the
vault contents
• Use least-priviledge principle
• If they don’t need it, don’t give it to them
Web
Worker
MSI
Admin
Console
DB
MSI
Great! Let’s ship it?!
✓ Secrets securely stored
× Everybody can access each others secrets
× Single point of failure
• Think about your security boundaries
• Vault level permissions – Be careful whom can do what
• Use multiple Key Vault instances if they have different security boundaries
• Use resource locks on your vault instance
• Prevent people from accidentally deleting all your secrets
Web
Worker
MSI
Admin
Console
DB
MSI
Customer PortalAdmin Console
Web
Worker
MSI
Admin
Console
DB
MSI
Customer PortalAdmin Console
Web
Worker WorkerWorkerWorker Worker
Worker WorkerWorkerWorker Worker
Web WebWebWeb
Web Web WebWebWeb
Great! Let’s ship it?!
✓ Secrets securely stored
✓ Seperation of domains
× Not scalable
• Cache secrets
• Avoids hitting Azure Key Vault when scaling out
• Avoids unrequired network calls
• Use in-memory cache only and make it short-lived
• Your application should be aware of this
Web
Worker WorkerWorkerWorker Worker
Worker WorkerWorkerWorker Worker
Web WebWebWeb
Web Web WebWebWeb
Cache Cache CacheCacheCache
Cache Cache CacheCacheCache
Web
Worker
Appsettings.json
“Using API Key ‘XYZ’”
Cache
Great! Let’s ship it?!
× You cannot trust your vault consumers
× People leave the company, but what do they take with them?
× Leaked credentials are not being revoked
• Automatically generate new authentication keys
• Limits risk of leaked credentials usage
• (Azure) Automation is your best friend
• Your application should be aware of this
❕ You cannot do this with all secrets
❕ Be careful – Other applications might be using the same credentials
WebCache
Key: foo
Secret: ServiceBus
Name: ServiceBus
Secret: foo
Step 1: Generate new secondary key
Step 2: Update secret to use secondary key
Step 3: Generate new primary key
Step 4: Update secret to use primary key
Generate keys
Name: ServiceBus
Secret: bar
WebCache
Key: foo
Secret: ServiceBus
Name: ServiceBus
Secret: foo
Step 1: Generate new secondary key
Step 2: Update secret to use secondary key
Step 3: Generate new primary key
Step 4: Update secret to use primary key
Generate keys
Get uncached secret
Key: bar
Demo
Key Vault enables new scenarios
Key Vault enables new scenarios
• Sync on-premises HSMs to Azure Key Vault
• Enables Bring-Your-Own-Key
• Azure SQL Database / SQL Server
• Azure Data Lake Store
• Azure Storage
• Automatically rotatation Azure Storage keys
Encryption with SQL - BYOK
Encryption with SQL - BYOK
Auditing & Operations
Auditing & Operations
• Full audit trail containing every action
• “Azure Key Vault Analytics” solution in Log Analytics
(http://bit.ly/key-vault-log-analytics)
Miscellanious
Miscellanious
• Be transparent
• Secrets & keys are versioned, make sure that consumers are aware of these
• This is important for cryptographical scenarios where decryption needs to
use the correct version of the key
• Key Vault is not a configuration store
• You need to build your own configuration store
• Dependencies fail
• Make sure you handle downtime of your dependency, if possible at all
• Key Vault integration in VSTS
Managing secrets in VSTS
Variable Groups*
Build / Release
Environment
Built-in Task*
Inline**
* Integration with Azure Key Vault
Using Key Vault in variable groups
Getting secrets inside your build/release
Wrap-Up
Takeaways
• Security should not be an after thought
• It is about limiting the risk of exposure, not removing it
• Go Key Vault all the way, including build & release
• Do not use one central Key Vault, use one per security domain
• Delegate authentication to Azure with Azure AD MSI
• Automatically roll your secrets and keep your vault up to date
53

Intelligent Cloud Conference 2018 - Building secure cloud applications with Azure Key Vault

  • 2.
    Building secure cloudapplications with Azure Key Vault Tom Kerkhove Azure Consultant at Codit, MSFT Azure MVP
  • 3.
  • 4.
    Nice to meetyou Tom Kerkhove • Azure Consultant at Codit • Microsoft Azure MVP & Advisor • Belgian Azure User Group (AZUG) blog.tomkerkhove.be @TomKerkhove tomkerkhove
  • 5.
  • 6.
    Great! Let’s shipit?! × No centralized secret management × No secure storage for sensitive information × No way to revoke access for a specific user/application × No way to updating secrets when they have expired/been rolled × No control over whom has access
  • 7.
    Introducing Azure KeyVault • Provides secure storage for sensitive information, including storing cryptographic keys in hardware security modules (HSM) • Automatically failing over to secondary region in read-only mode • Allows you to : • Store sensitive information as secret • Use keys for cryptographical purposes • Manage certificates
  • 8.
    Keys & Secrets •Secret • Used to store sequences of bytes • Consumers can read & write secret values to it • Encrypted before stored in vault • Limited to 10 kB • Typically used for connection strings, authentication keys, etc. • Key • Stores a RSA 2048, 3072 & 4096 key • Can be used to perform crypto operations such as encryption & signing • Can’t be read back • Higher latency
  • 9.
    Different types ofkeys • Software Keys • Operations performed on VM in Azure • Typically used for Dev/Test • Cheap • HSM Keys • Stored encrypted in HSM • Operations performed on HSM directly • Requires Premium Vault • More secure
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
    Authenticating to AzureKey Vault • Authentication is fully handled by Azure Active Directory • Only works for the default Azure AD directory • Use basic or certificate authentication • However, you still need to store authentication information in your configuration private async Task<string> AuthenticationCallback(string authority, string resource, string scope) { var adApplicationId = configuration.Get<string>("KeyVault.Auth.ApplicationId"); var adApplicationSecret = configuration.Get<string>("KeyVault.Auth.AppSecret"); var authContext = new AuthenticationContext(authority); var clientCredential = new ClientCredential(adApplicationId, adApplicationSecret); var token = await authContext.AcquireTokenAsync(resource, clientCredential); return token.AccessToken; }
  • 16.
  • 17.
  • 18.
  • 19.
    Great! Let’s shipit?! ✓ Control over whom has access ✓ Centralized secret management ✓ Secure storage for sensitive information ✓ Capability to revoke access for a specific user/application ✓ Capability to update secrets when they have expired/been rolled × Keys to the kingdom are still stored as before
  • 20.
    Enter Azure ADManaged Service Identity (MSI) • Delegate authentication to the Azure resource that runs your app • Azure Resource Manager will create & assign an Azure AD Application to your resource • Currently only supports system-defined AD Application names • Not all Azure services support this, yet • No authentication information nor authentication logic required • Super easy and more secure
  • 21.
  • 22.
  • 23.
    Great! Let’s shipit?! ✓ Control over whom has access ✓ Centralized secret management ✓ Secure storage for sensitive information ✓ Capability to revoke access for a specific user/application ✓ Capability to update secrets when they have expired/been rolled ✓ Authentication delegated to Azure ❕ Not all Azure services already support MSI
  • 24.
  • 25.
    Authorization • Managing vaultinstance (“control-plane”) • Based on RBAC roles • Managing vault contents (“data-plane”) • Defined in “Advanced Access Policies” • Granular control over assigned permissions • Permissions defined on a vault-level • Assigned to AD user, group or application • Ie. only set secrets without being able to see them
  • 26.
  • 27.
    Authorization • Be carefulabout whom can manage your vault instance • Take into account that people can add themselves to permissions to the vault contents • Use least-priviledge principle • If they don’t need it, don’t give it to them
  • 28.
  • 29.
    Great! Let’s shipit?! ✓ Secrets securely stored × Everybody can access each others secrets × Single point of failure • Think about your security boundaries • Vault level permissions – Be careful whom can do what • Use multiple Key Vault instances if they have different security boundaries • Use resource locks on your vault instance • Prevent people from accidentally deleting all your secrets
  • 30.
  • 31.
  • 32.
    Web Worker WorkerWorkerWorker Worker WorkerWorkerWorkerWorker Worker Web WebWebWeb Web Web WebWebWeb
  • 33.
    Great! Let’s shipit?! ✓ Secrets securely stored ✓ Seperation of domains × Not scalable • Cache secrets • Avoids hitting Azure Key Vault when scaling out • Avoids unrequired network calls • Use in-memory cache only and make it short-lived • Your application should be aware of this
  • 34.
    Web Worker WorkerWorkerWorker Worker WorkerWorkerWorkerWorker Worker Web WebWebWeb Web Web WebWebWeb Cache Cache CacheCacheCache Cache Cache CacheCacheCache
  • 35.
  • 36.
    Great! Let’s shipit?! × You cannot trust your vault consumers × People leave the company, but what do they take with them? × Leaked credentials are not being revoked • Automatically generate new authentication keys • Limits risk of leaked credentials usage • (Azure) Automation is your best friend • Your application should be aware of this ❕ You cannot do this with all secrets ❕ Be careful – Other applications might be using the same credentials
  • 37.
    WebCache Key: foo Secret: ServiceBus Name:ServiceBus Secret: foo Step 1: Generate new secondary key Step 2: Update secret to use secondary key Step 3: Generate new primary key Step 4: Update secret to use primary key Generate keys
  • 38.
    Name: ServiceBus Secret: bar WebCache Key:foo Secret: ServiceBus Name: ServiceBus Secret: foo Step 1: Generate new secondary key Step 2: Update secret to use secondary key Step 3: Generate new primary key Step 4: Update secret to use primary key Generate keys Get uncached secret Key: bar
  • 39.
  • 40.
    Key Vault enablesnew scenarios
  • 41.
    Key Vault enablesnew scenarios • Sync on-premises HSMs to Azure Key Vault • Enables Bring-Your-Own-Key • Azure SQL Database / SQL Server • Azure Data Lake Store • Azure Storage • Automatically rotatation Azure Storage keys
  • 42.
  • 43.
  • 44.
  • 45.
    Auditing & Operations •Full audit trail containing every action • “Azure Key Vault Analytics” solution in Log Analytics (http://bit.ly/key-vault-log-analytics)
  • 46.
  • 47.
    Miscellanious • Be transparent •Secrets & keys are versioned, make sure that consumers are aware of these • This is important for cryptographical scenarios where decryption needs to use the correct version of the key • Key Vault is not a configuration store • You need to build your own configuration store • Dependencies fail • Make sure you handle downtime of your dependency, if possible at all • Key Vault integration in VSTS
  • 48.
    Managing secrets inVSTS Variable Groups* Build / Release Environment Built-in Task* Inline** * Integration with Azure Key Vault
  • 49.
    Using Key Vaultin variable groups
  • 50.
    Getting secrets insideyour build/release
  • 51.
  • 52.
    Takeaways • Security shouldnot be an after thought • It is about limiting the risk of exposure, not removing it • Go Key Vault all the way, including build & release • Do not use one central Key Vault, use one per security domain • Delegate authentication to Azure with Azure AD MSI • Automatically roll your secrets and keep your vault up to date
  • 53.

Editor's Notes

  • #19 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #22 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #25 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #27 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #40 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #41 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #45 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #47 Evangelistisch overkomen – adviseren Gevoel: heeft visie .
  • #52 Evangelistisch overkomen – adviseren Gevoel: heeft visie .