AZ-303: Microsoft Azure Architect Technologies certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

Implementing Security

6. Access Reviews

It's important to ensure that users have the right access to what they need and only what they need. And to achieve this, it's important to conduct regular reviews in order to ensure compliance. However, as organizations grow larger and more complex, this task becomes increasingly difficult, particularly in hybrid scenarios where user access extends not only to on-premises systems but also to cloud-based ones. Azure provides a facility called Access Reviews.

These allow you to specify a user group to review. This review can be conducted by the individual users themselves, group managers, or another named individual. In this way, you can place the responsibility on the appropriate people. By enforcing regular access reviews for teams, you can ensure that users maintain only the level of access they need, and as users leave the company or even change roles, the review process helps capture and remediate Louvre user access levels.

7. Perform an Access Review

In this lecture, we're going to kick off an Access review. So what we want to do is take one of our groups, which is the End Users Group, and we're going to ask the group owner to perform a review of all the members of that group to ensure that they should still be within that group. Before we can create an access review, we first need to actually onboard our directory. So we're going to do that by going to Azure Active Directory and then the Identity Governance Blade. When we go in, we can see that it tells us that we need to onboard our organization first, which we do by clicking the Onboard option on the left with your default directory highlighted.

Now, click on board and wait for the process to complete. It's important to understand that you need to have the "P2" option enabled in Active Directory with the licenses assigned to your users. Create an access review by clicking here. Give the review a name and an optional description, give a start date and an end date, and also set the frequency so we can have it be a one-time, one-off review, or we can set weekly, monthly, quarterly, and so on. I'm just going to set this as a one-time review for now. If we do set it monthly or quarterly, we can tell it how many occurrences to have, whether to have ten by a certain date, and so on.

Next, we're going to tell it what to review. So we're going to review the members of a group and scope it to either guest users only or everyone, and then we go ahead and select the group. Then we tell it who will be reviewing it. So I'm going to say group owners because we set our second user as the group owner. And then we click "Linked Program." We can tell it whether to automatically apply results to the resource. We can also tell it what to do if reviewers don't respond.

And finally, we could have various options here for whether to show recommendations, require approval, and so on. Once we're ready to go, simply hit Start. That will create and initialise a new access review. And then we have to wait around 20 minutes, about half an hour, for an email to be sent to our user who needs to do the review. So eventually you'll receive an email asking you to complete the Access Review.

Simply click on the email to start the review. This takes you to the My Access portal. So in the review we can see here, it's asking us to perform the End Users Group view, it's showing us all the users, and it's giving recommendations as to whether we should approve or deny access to that user. So I'm going to say "approve and prove." And then, back in the main portal, in the Access Reviews, we go to the overview. We can see that we've got one reviewed group; it has one member, and it's currently active. Go to the access reviews, and in here we can see that this one user has been approved.

8. Azure Keyvault

Many applications and solutions need to secure information that is used by the system. For example, connection strings, especially those containing passwords such as a database connection string, You may also need to store things like API keys and secrets or even certificates that are used in secure communications between components.

Good security practices also recommend rotating these keys and passwords to keep them secure. Such information is typically stored in configuration files, such as a web configuration in an ASP.NET web application. This means it has to be available to the developers or anyone with direct access to that hosting platform. Not only is it then difficult to control access in this way, but rotating those key certificates becomes a very manual process.

So Azure Key Vault was created as a tool for securing, restoring, and accessing these sensitive items. You must first authenticate to a key vault before performing any operations in it. And there are three ways we can authenticate with that key vault. First, we can use managed identities. When you deploy an app on a virtual machine in Azure, you can assign an identity to that virtual machine that has access to the key vault. You can also assign identities to other Azure resources. The main benefit of this approach is that the app service isn't managing the rotation of the first secret. Azure automatically rotates those identities for you. This is frequently recommended as the best practice.

The other option is to use the service principle and certificate. You can use a service principal and an associated certificate that have access to the key vault. This is not recommended because the application or developer must then rotate the certificate manually. Finally, you can use a service principal with a secret.

Although you can't, you can use a service principle and a secret to authenticate with Key Vault. Again, it's not recommended. And again, that's because it's hard to automatically rotate that secret when it's used. Anyone with an Azure subscription can create and use key vaults. Although Key Vault benefits developers and security administrators most, it can be implemented and managed by an organization's administrator, who then manages other Azure resources.

This administrator can then give the developers the urge to make calls from their applications. This provides the administrator with key usage and log information, centralising the storage of application secrets and ensuring KeyVault allows for control over that distribution. Key Vault significantly reduces the possibility of secrets being accidentally leaked. So when using Key Vault, application developers no longer need to store that security information within their applications, and not having to store security information in applications eliminates the need to make this information even part of the code.

9. Azure Keyvault Walkthrough

Okay, let's go ahead and create and use a key vault in the marketplace. Search for key vault and then click Create on the Microsoft keyboard. Fill in the usual information. Again, we're going to create a new resource group for this. Give the vault a name.

This has got to be unique as a location. Next, select the pricing tier. We've got standard and premium. Premium essentially means it supports hardware and module-backed up keys. Unless you've got a specific requirement for that, the standard is usually fine. We have an option to enable something called "Soft Delete." So that's kind of like a trashcan for a key. So with Soft Delete enabled, if you delete a key, it actually retains that key until you go and purge it. And again, we can have purge protection even against that. That's kind of like a second-stage recycling process. Next, we go to the access policy.

So we can set various access policies, and we can do this later on, but it asks you if you want to set some default ones. For example, enable access to Azure Virtual Machines for deployment and Azure disc encryption. We'll leave those disabled for now; we can always enable them later. Attend a networking event. Again, we can tie this down to our internal networks or public networks. If you want to secure it only for services covered by your subscription, you should probably use it on specific networks.

But for testing purposes, we're just going to leave it public. Go to Tags and then review and create. Once that's created, we can go and take a look at the vault. And as you'll be able to see here, we've got three main options that we'll use here. So we'll have keys, secrets, and certificates. So these are the various classifications for the various types of information you may require to cure. But before we can do any of that, we actually have to create an access policy. And an access policy is how you define what you've got access to. So by default, the user who used it to create it will create an access policy. And if we have a look at these various different options here, we can see that the different options So for key permissions, we've got "get list update" and so on, and again, graphic options.

So the idea is that you would set an existing policy either for an individual user, a managed service account, or a managed identity. If we're doing it that way, because we're just testing with my signs and account, I can just do everything I need to do with the default certificate permissions that have been set here. We're going to use PowerShell to just show you how you can store and create keys. The first thing we'll do is hide a secret within our key vault. So using PowerShell, first of all, I'm going to create a secret value, and the secret is going to be a string. But I'm going to convert the string to a secure string.

Then we've got that secret value. I'm going to store it in the key vault and do that using Set AZ Key Vault Secret. The first thing we need to do is tell it the vault name. Next, we need to give it a name for the secret that we're storing. So we'll say "I secure secret," then set the value, which will be our dollar secret. So that's what created the secret in here.

And in fact, what we could do just to have a look at the different keys is to get the AZ key vault secret and pass in the vault name. And this list, the fact that we've got a vault name with a secret in it called my secure secret, And if we actually want to get the value from the secret, we can do it again through PowerShell, and I just put that half in the wrong place there.

Then finally, we can access the actual value, do the secret value text property there, and see our secret that we stored. If we go back to our actual key vault and go to secrets again, we can see our secret there. You can drill down into it and click right through. We can set options to do things like expire or activate it. By default, the secret value is blanked out. But if we click "Show Secret" again, we get to see it. So obviously, we did that through PowerShell. Normally, what you would do would be done programmatically within your application. However, rather than storing the secret values in configuration files, the idea is to use that to retrieve them.

Prepaway's AZ-303: Microsoft Azure Architect Technologies video training course for passing certification exams is the only solution which you need.