The course is part of these learning pathsSee 2 more
Azure Security Solutions
About This Course
Security is a critical concern for anyone who uses the cloud. Microsoft takes this seriously and built and operates the Azure Platform with security as a key principle. Microsoft secures data centers, and management applications; and provides pay-as-you-go security services. Learn how to take advantage of these security features and services to enable strong security practices in your organization and to protect and secure your own cloud applications.
This course is for security engineers, chief security officers, solution architects, information technologists or anyone wanting to understand security options within the Azure platform.
Viewers should have a basic understanding of cyber security, authentication and authorization best practices, and encryption. Some familiarity with the Azure platform will also be helpful but is not required.
Understand the shared responsibility model
Learn how to secure Azure resources such as virtual machines and storage accounts
Learn how to secure your Azure-based applications
Learn how to monitor your Azure resources with Azure Security Center
Welcome and Introduction: A brief introduction to the course and an overview of what Bill and Maura will be covering.
Shared Responsibility: In this lesson we'll cover Cyber Security, using CIA Principle: Confidentiality – Integrity. Availability; what security professionals do to ensure the parts of CIA: Prevent – Detect – Respond.
Microsoft’s responsibilities and their own security/compliance processes. What a customer is responsible for. And finally the tools that Azure provides, including AAD, Encryption, secure networking
Protecting Accounts: In this lesson we'll cover Azure Active Directory, and Mult-Factor Authorization.
Securing the Azure Portal: In this lesson we'll cover role-based access control.
Indentity Management for Apps: In this lesson we'll cover AAD protection and integration for business Apps.
Network Security: In this lesson we'll cover Virtual Private Networks and firewalls.
Data Security: In this lesson we'll cover Encryption and Masking.
Secrets Management: In this lesson we'll cover Key Vault and Shared Access Signatures.
Monitoring and Audting: In this lesson we'll discuss the Azure Security Center.
Course Conclusion: Course Wrap-Up
In this lecture we discuss Azure Key Vault and Shared Access Signatures. Azure Key Vault is a pay-as-you-go service for managing secrets and digital certificates. Azure Key Vault represents a mind shift for developers who are accustomed to deploying database connection strings, passwords and other secrets along with their code. Azure Key Vault simplifies implementing a clean separation of duties so that developers can code, release engineers can deploy applications and services, and security focused people can manage secrets and digital certificates.
With this model, services and application code will retrieve the keys, passwords and connection strings at runtime from Azure Key Vault instead of reading them from a local config file that was deployed along with the application. This has a few obvious benefits. It reduces the risk and exposure of accidentally checking in config files containing sensitive secrets, it simplifies changes to passwords, keys, and other secrets between deployments, and it supports a separation of duties operational model where the people in charge of writing and deploying code don't need access to sensitive credentials. Key Vault can perform cryptographic operations on behalf of users. For example, a certificate can be generated within Key Vault with a policy setting that prevents the certificate's private key from ever being retrievable from Azure Key Vault.
The private key can never leave Azure Key Vault. Yes, this means that you can have certificates that live within Azure Key Vault that you can never get out of Azure Key Vault. You may wonder what good is that. Well, here's the benefit. You can still use those certificates. You can ask Azure Key Vault to perform cryptographic operations on your behalf using those certificates, such as signing or decryption without ever exposing the key to application code. Certificates created in this manner are just not inaccessible to you, but Microsoft employees can't access them either. Important side note, Azure Key Vault does natively support disaster recovery scenarios. Key Vault also includes logging of key access and updates, which is useful for auditing activity.
Security administrators can see who has accessed the keys, when they were rotated, and so forth. Keys are referenced by a universal resource identifier, or URI for short. Individual keys can be versioned. The latest version of a key is identified by a certain URI, and then individual versions of that key are identified by appending a GUID with each version of the key being assigned a specific GUID. As mentioned, services and application code retrieve keys, passwords, connection strings, and other secrets from Azure Key Vault over the network.
This access is privileged, meaning that not just any caller can access a given vault. In particular, the only way to get a security token for accessing a particular Azure Key Vault resource is to first go through Azure Active Directory itself. Access to the Azure Key Vault API requires that you provide a valid security token and this is a Java web token or JWT token issued to you by Azure Active Directory. So how do you get one of these security tokens? Azure Active Directory will issue a valid JWT security token upon proof that you are an AAD principal, and that you are permissioned for the Azure Key Vault resource that you are trying to access. So you might wonder how is this proof performed? For humans, you simply authenticate through Azure Active Directory, such as through your web browser.
If you're a server trying to prove your identity, you'd do so through a client ID, which is a GUID, and either a client secret or a digital certificate. After you've proven who you are, whether a human or a server, Azure Active Directory will return to you a valid JWT security token containing appropriate assertions about what you're allowed to do with this Azure Key Vault.
Let's have a look at Key Vault in the portal and from the command line. Here we are in the Azure portal. We'll go to the Key Vault's blade, and you can see there are two vaults created, one called bookstorekeys and one called secretplace. Let's first look at bookstorekeys. In bookstorekeys, we can see that there are two principals who are listed as having access to this vault. Let's look at who those principals are. One of them is the AAD Global Admin, and that's me, the user I'm logged in as. And another is the claimdumpdemo application that we demonstrated in an earlier lecture. So in order for this claimdumpdemo application to access the keys and secrets within this vault, it will have to provide a client ID, and either a client secret or a digital certificate. For this interactive user to access the keys and secrets, the user simply needs to be logged in. Either way, AAD will issued the needed JWT security token. Let's look at secretplace briefly. We can see that has only one principal, and in this case the principal is the AAD Global Administrator. And we'll look at the keys. You can see there are no keys listed.
Let's look at secrets. We can see there's one secret in this vault. Let's have a peek at it, and it tells us there is a versioned secret. This is the long name for this secret. This is essentially a GUID that identifies through all of time this specific value. We could add a new version of this secret. Let's give that a try. I typed in fromportal. We can set an activation date of May 1st. We can set an expiration date of let's say August 13th and hit create.
So now we can see that the same secret name, called privatedata, has two different values with its own version identifier. On one, we've set an activation and expiration date. On the other, we haven't. Here we are at a command line window and let me tell you what I've done so far. I set up a few environment variables so that we can use them later in commands to make the commands more convenient to type. I set up a location, a storename, that'll become the Azure vault name, a secretname, this is a data item, a secret within the vault, and the initial value of the secret I've called secretvalue.
This next command az account show is using the Azure Command Line Interface version 2 to show that I'm currently logged in. I'm logged in as the Azure bookstore administrator. Then I used az group create to create an Azure resource group that I'll need later. And then I created an Azure key vault. This vault's name is secretplace. It's located in the East US data center region. It uses the standard tier of Azure Key Vault, which is software based. There's also an option to do a hardware-based Azure key vault, which is stored in an actual hardware security module, or HSM. Scroll down and then the next CLI command I entered was az keyvault list and it shows two key vaults returned as a result.
One is called bookstorekeys and the other is called secretplace. And as you may recall, these are the same two key vaults that we saw in the portal. Jump back over to the portal and we see bookstorekeys and secretplace as the two vaults listed. So the information is consistent. We did an az keyword secret list command for our secretplace vault and it didn't return any secrets, which was true at the time I ran the command. Then I used az keyvault secret set to create a secret. The name of the secret is privatedata, and you can see it in this URI and this GUID-like thing at the end is the version number, and the value I gave it is canyoukeep123secret.
And again, let's jump over to the portal, and we can see my privatedata secret and the values have versions. The initial version that I created started with 2fac4, and we can see that that's the same version number we see here. Next we do an az vault secret list to show all of our secrets, and it shows that we, at this point, had exactly one secret, and it was our privatedatasecret. And then finally we did an az keyvault secret show to retrieve the value of our secret. And it returned the value.
So this is showing that we can create a key vault, we can interrogate the key vault to ask what it has in it, whether it has secrets or keys, and so forth, and it will tell us what is available. And we can put secrets in the vault, and we can retrieve secrets from the vault, and we can version secrets. We can only accomplish any of this, we're only permitted to do this because we've authenticated with Azure Active Directory, and Azure Active Directory looks us up and it sees that the policies for the particular key vault we're trying to access includes us and we have permissions to do the operations that we talked about.
For example, we can get keys, we can update keys, we can list keys, and so forth. We don't have all permissions, but we have the ones that we performed. Besides Azure Key Vault, Azure has another useful tool for helping to secure access to resources. That feature is shared access signatures. Shared access signatures are available for some Azure services such as Azure Storage and Service Bus, and here we're gonna take a look at the case of Azure Storage. Shared access signatures allow you to grant access to a storage account resource without giving out and compromising your private storage keys.
A private storage key gives complete access to all resources within a storage account, but that doesn't follow least privilege practices. Let's work through an example. Suppose you have an application that allows users to upload files, and these files are stored in Blob storage. You can have an application architecture that passes the files through your web application code like shown in the image on the left, or using shared access signatures, you could approach it as shown in the image on the right.
Both approaches have similar security profiles, but the shared access signature approach has some infrastructure advantages since it would allow direct and faster uploads, and it would save on web application server load. Imagine an extreme case where the files being upload are gigabytes in size, for example. Let me explain in a little more detail what's happening in the image on the right. The client, shown as a laptop in the image on the right, is planning to upload some files. After authenticating with the application, the application issues the client a shared access signature. Then the client can use the shared access signature to directly upload into Blob storage in a predetermined location, without having any of the file upload bits go through the web application. Azure Blob storage is highly scalable, and this architecture really takes advantage of that. Azure Blob storage is highly scalable and this approach really takes advantage of that.
We've mentioned that shared access signatures give focused access to various resources within a storage account without compromising the overall access. Shared access signatures can also be timebound. For instance, you can give access for just a few minutes or for days. You can give shared access signatures that allow reads but not writes, and so forth. There's a lot you can do with shared access signatures, and if you're writing Azure applications where end users integrate with storage, you'll want to consider using these for efficiencies such as in the prior example. As an aside, the general approach of issuing a shared access signature with limited powers is known as the valet key pattern. From a security point of view, there are additional use cases around either enforcing least privilege or timebound access control. Here's another example.
Consider a virtual machine processing video files from Blob storage based on processing requests that are transmitted through a queue. This is a queue-centric workflow pattern. One way to handle this processing is for the virtual machine to have standing access to the storage account with a storage key. This is the key that gives complete access to that storage account. With that key in hand, that virtual machine can read and write any Blobs that it needs to, to access videos that need processing and to write back videos after processing.
A least privilege approach could be designed such that the queue messages include a shared access signature that only allows reading the one video file referenced in the queue message. As an extension of that, one could perhaps also include a second shared access signature that the virtual machine could use to write out the results. So such a queue message, with two shared access signatures, would really limit the attack surface and limit the scope of what that virtual machine was allowed to do. Not only does this help make your system more secure, but similar to the impact of Azure Key Vault best practices, this also makes your architecture more flexible.
For example, if the videos being processed were distributed across hundreds or thousands of storage accounts, it would obviously be unwieldy to manage such access centrally from the VM. You could even have customers or partners sending queue messages with shared access signatures to storage accounts that are otherwise unknown to you, and this architecture would still work, be secure and be quite flexible.
Before we leave this lecture, let's point out a couple of additional resources. This first resource about Azure Key Vault includes the programming model and shows how you would access the client ID and the client secret needed to perform server to server calls (https://docs.microsoft.com/en-us/azure/key-vault/key-vault-use-from-web-application). Mentioned the valet key pattern, and that's described in two books. One is my book, Cloud Architecture Patterns (https://www.amazon.com/gp/product/1449319777/ref=as_li_ss_tl), and another is the Cloud Design Patterns book from Microsoft. And the final two links provide more information about the mechanics of using the valet key pattern in storage (https://docs.microsoft.com/en-us/rest/api/storageservices/delegating-access-with-a-shared-access-signature) and in Azure Service Bus (https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas).
About the Author
Bill Wilder is a hands-on architect currently focused on building cloud-native solutions on the Microsoft Azure cloud platform. Bill is CTO at Finomial which provides SaaS solutions to the global hedge fund industry from the cloud, co-founded Development Partners Software in 1999, and has broad industry experience with companies of all sizes – from modest startups to giant enterprises. Bill has been leading the Boston Azure group since founding it in 2009, has been recognized as a Microsoft MVP for Azure since 2010, and is author of Cloud Architecture Patterns (O’Reilly Media, 2012). He speaks frequently at community events, and occasionally at conferences, usually on topics relating to cloud, cybersecurity, and software architecture.