Hi there. In this last video, we're going to focus on how to access the services that are sitting behind a specific service endpoint. Now, it was kind of hard for me to not touch on this during the previous videos, but we're actually going to focus on just that particular topic. When limiting access there's a number of different ways that it can be done. Let's talk first about how to use the service tags. We touched on it a little bit, but within the scope of a network security group or an Azure Firewall, you can actually use service tags to either allow or deny access to specific Azure past services within the scope of your particular subnet that the NSG has been applied to or even all the way down to a specific NIC card. You can use current point-in-time list of IP ranges that those service tags are associated with in your on-prem environment as well, and therefore use them in your own on-prem firewall rules such as the Cisco device, Barracuda, or so on.

You can leverage service endpoint policies which granted, right now, are storage account only, but they do provide the ability for you to limit access to specific storage accounts based off of individual names, resource groups, or subscription IDs. And then there are also specific path services that are associated with service endpoints that have their own access control list features. A couple of examples are storage accounts have additional control list actions such as shared access signatures, where you can actually define the availability of the data within the scope of a storage account container. For example, you can control it based off of incoming IP addresses, you can specify time windows, things along those lines. There's also the ability to control access to storage accounts via role-based access control inside of Azure, there's a number of different features related to storage accounts that are inherent to the storage accounts themselves. And then within the scope of key vault, for example, Key Vault has its own firewall as well as access policies, thereby allowing you to limit access to not just Key Vault itself but also to what data is inside of Key Vault.

And one of the things that you're going to find from a limiting access perspective is that Microsoft has provided an additional capability within the scope of any service that is data-oriented. Key Vault, storage accounts both store data, the database is all stored data. So, they all have additional access capabilities within those services to make sure that data is secured and the customer is happy with that security. Now, just as a quick example, we touched on it a little bit during the last video of service tags, but let's actually create a deny rule inside of a network security group and deny access to a specific past service that a service endpoint has been set up for. We are back in the portal and we have gone directly into the network security group that I created called endpoints. And what we're going to do is we're going to create a quick deny rule that will prevent access to any storage account within a specific region. And then we're going to apply that network security group to the subnet that we created the service endpoints for.

So, we go into inbound rules, and we create a new one. We want the Source to be anything because we want to block all traffic. The Destination on the other hand is going to be a specific 'Service Tag' and we are going to, remember we actually turned on both Key Vault and storage accounts. So, let's lockdown storage accounts that exist inside of GermanyNorth. We are going to deny all traffic to all storage accounts that sit inside of the GermanyNorth region. And in this case, we're going to, Destination ports ranges will be all, Protocol, 'Any'. We're going to do a 'Deny'. The priority number just needs to be higher than 65,500 so that it will take effect first. And then we're just going to give it a name, and we're done. Now, before this can actually work and prevent traffic from flowing into a storage account that sits in GermanyNorth, we have to apply it to the subnet.

So, let's go back to our resource group and specifically the vnet. And go to the 'Subnets' and go to the subnet endpoints. We're going to make sure that the network security group that we just modified has been applied to this subnet. So, in this instance now, we actually have dual layers of accessibility to storage accounts within the scope of this subnet. We turned on Microsoft.Storage as a service endpoint. However, we have a network security group that's blocking all traffic to storage accounts in GermanyNorth. And of course, we could add additional rules if we wanted to limit it even further. But then we also have a storage account endpoint policy that is also allowing two specific storage accounts. So, it allows you to create that multilayered approach of accessibility from a security perspective with respect to service endpoints. And of course, this can be leveraged here in network security groups. 

We can also create deny rules or allow rules inside of the Azure Firewall as well. And then as I mentioned, there are a number of other capabilities, especially within storage accounts that you can take advantage of to even layer your security or your accessibility to the data within those storage accounts even further. That's going to do it for this course. I hope that you've enjoyed all of the content. We'll wrap things up in a conclusion video next.