Security has become more and more important as we move to the cloud and countries & companies are being hacked – remember the Sony hack? But how do we securely store sensitive data such as connection strings to our databases? Where do we store our encryption keys? Can I share them with my customers? How do I prevent abuse of my secrets and block them from doing so? That’s what this session is all about – I will introduce you to the concepts of Microsoft Azure Key Vault where you can use this as it allows you to securely store keys, credentials and other secrets in the cloud. We will also have a look at how it enables us to store encryption keys for SQL Server TDE and how it can help you safeguard your cloud solutions even more.

1. Securing sensitive data with
Azure Key Vault
Tom Kerkhove
Tweet and win an Ignite 2016 ticket #itproceed

2. Who am I?
Tom Kerkhove
• Integration Professional at Codit
• IoT Competency Lead at Codit
• Kinect for Windows MVP
• Microsoft Azure Advisor

3. How can Codit help?
Integration services
• Advice
• Projects
• Implementation
• SOA Governance
• Managed Services
• Integration as a Service
• Integration Cloud
• API Management
• Internet of Things

5. Demo Scenario
• Customer applies to the SaaS
– Gives Twilio & Azure Storage credentials
• Application uses API to send text messages

6. SPAMMER ‘INSECURE’

7. Demo Summary
• Security flaws
– Storing sensitive data as clear text in DB
– Google authentication as clear text
– Unencrypted connection string
– Unsecured API
– Probably more
• On the other hand...
– Transport security with SSL (Although default Azure cert)
– External login

10. Introducing Azure Key Vault

11. What is Azure Key Vault?
• Storing sensitive data in hardware security modules
(HSM)
• Giving back control to the customer
– Full controll over key lifecycle with audit logs
– Management of all keys in one place
– Store encryption keys in HSMs
• Removes responsibility from developers
– Secure storage for passwords, encryption keys & certificates
– Protects sensitive data in production

12. Keys Secrets
Azure Key Vault

13. Secrets
• Used to store sequences of bytes
• Consumers can read & store secrets
• Encrypted before stored in vault
• Limited to 10 kB
• Versioned
• Typically used for connection strings, certificates, etc.

14. Keys
• Stores a RSA 2048 key
• Created by Key Vault owner
• Can be used to decrypt/sign with
• Can’t be read back
• Higher latency
• For frequent usage of keys, store it as a Secret

15. Different Key Types
• Software Keys
– Stored encrypted in
HSM
– Operations performed
on VM in Azure
– Typically used for
Dev/Test
– Cheaper
• HSM Keys
– Stored encrypted in
HSM
– Operations performed
on HSM directly
– Requires Premium Vault
– More secure

16. Basic LOB Scenario
Database
3. Connect to DB
1. Deploy application
2. Read from settings
Fabricam Customer X
Single-tenant app
App Settings
Developer

17. (More) Secure LOB Scenario
Database
Single-tenant app
1. Create vault
2. Authorize apps & users
3. Create CS Secret
4. Deploy Application
6. Negotiate Secret
Fabricam Customer X
App Settings
5. Retrieve
Vault URI
Manages key / monitor logs
Vault Consumer
Developer
Vault Owner

18. Vault Owners vs Consumers
• Vault Owners
– Has full control over vault
– All keys & secrets in one
place
– Ability to change
permissions
– Ability to fully revoke
consumer
– Ability to regenerate keys
without breaking apps
– Audit logs for monitoring
• Vault Consumers
– Authenticate with Azure AD
– Not able to see encrypted
keys
– Limited to granted
permissions

19. Access Control
• Access control based on Azure AD
• Access assigned at the Vault-level
– Permissions to keys
– Permissions to secrets
• Authentication against Azure AD
– Application ID & Key
– Application ID & Certificate
• No isolation between clients, they see everything

20. Access Control

21. Sharing credentials with control
Codito Subscription
Azure
Active Directory
Web App
Azure SQL database
Storage (Azure)
SaaS Subscription
Azure Key Vault
1 2
3
5
6
7
Azure Key Vault
4

22. SPAMMER ‘MORE SECURE’

23. Summary
• Security flaws
– Vault credentials stored as plain-text
– Unsecured API
• On the other hand...
– Message encryption supported based on customer vault
– External vault authentication stored in internal vault
– Customers data is securely stored in their vault
– Encrypted database

24. PS C:Demo> Start-Demo

25. But there is more!
• Azure Storage Client-Side encryption
• VM Encryption (CloudLink)
• SQL Server Encryption
• Bitlocker Encryption

26. VM Encryption (CloudLink)

27. Bring-Your-Own-Key (BYOK)

28. SQL Server Encryption
• SQL Server Extensible Key Management
provider available (Preview)
– Transparent Data Encryption (TDE)
– Column Level Encryption (CLE)
– Backup Encryption
• Requires SQL Server Enterprise
• Available on-prem & in Azure

30. SQL SERVER TDE DEMO

31. Vault Isolation
• Vault dedicated to one region
– Vault, Keys & Secrets stay within same region
• Stored in physical HSMs
• Reason - Laws & compliances
– Each vault has its own URL
– Manual synchronisation if required

32. Replication
North Europe
Azure Key Vault
West Europe
Azure Key Vault
Manually Sync

33. Pricing Overview(*)
• Vault owner pays for everything
Standard Premium
Secrets & Software-protected keys
$0.0112 / 10,000
operations
$0.0112 / 10,000
operations
HSM Protected keys N/A
$0.0112 / 10,000
operations
$0.3724 per key per
month
(For every version of the key)
* = 50% discount during public preview

34. Public Preview
• Currently only available in 6 regions
• PowerShell, .NET & REST API
• No SLA

35. What’s coming?
• Available in all regions with 99.9+ SLA
• Portal Support
• GA ‘real soon’
• Audit logs

36. 36

37. And win a Lumia 635
Feedback form will be sent to you by email
Give me feedback

38. Follow Technet Belgium
@technetbelux
Subscribe to the TechNet newsletter
aka.ms/benews
Be the first to know

39. 39
“The question is not if you will be
hacked,
the real question is when.”

40. Thank you!

41. Belgiums’ biggest IT PRO Conference