Category: Azure

Azure Backup Center

Azure recently made the “Backup Center” a public preview, where you can now quickly validate if your IaaS workloads (VMs) are being backed up via Azure Backup. This provides a single pane of glass to quickly get an overview of your subscription (or subscriptions) and provides you a single and simplified management experience. As of today, Backup Center supports Azure Backup VM backup and Azure Database for PostgreSQL. This list will continue to grow as Backup Center continues to mature and as its adoption rate increases.

The solution should already be available within your Azure tenant as it is available for all Azure regions.

Some of the key benefits of Azure Backup Center:

  • Simplified and a Single pane of glass to manage your Azure Backups
  • Native Integration with Azure Policy
  • Native Integration with Azure Monitor
  • Built in Reporting

To get started, search for Backup Center within the Azure Portal and navigate to the built-in dashboard. You should see something like this, assuming you have already some IaaS (VMs) deployed within your environment.

Next up, building reports with Log Analytics!

Azure Default Service Principals vs Customer Created

The other day, a customer asked me to provide the number of Service Principals (SP) in their Azure tenant. Well, that is pretty easy right? Head over to the Azure AD service within the Azure Portal and browse the App registrations (Service Principals) here… But wait, I now want to extract the list of SPs to a file. Great, I can use the following CLI or PowerShell query “az ad sp list” or “Get-AzADServicePrincipal” to retrieve that information. Wait a second… now why do I see nearly 700 SPs in PowerShell, yet when I take a look at the Portal, I can see there are maybe 100 Service Principals at best. This cannot be right! Why is PowerShell/CLI generating a list of nearly 700 Service Principals, whereas the portal only shows me ~100 SPs? Something is up… Let’s take a deeper dive here.

Well, after some research, I ran into the following blog post from fellow Microsoft MVP, Rick Van Rousselt you can find that post HERE. Learning Microsoft creates a handful, ~600 Service Principals that are needed for various Azure services, ie. Azure AD, Office 365, Azure Policy, etc. This ia default behaviour for any Azure tenant, and is common for any tenant.

After you execute the following query (“az ad sp list” or “Get-AzADServicePrincipal“) you can see that for some of these ~600 SPs the Tenant ID does not match my customers… The appOwnerTenantId belongs to a Microsoft/Azure tenant. Interesting….

So how do you figure out which Service Principals are customer created/owned, and how do we differentiate between the customer and Microsoft?

Below is what I did, and this should help you identify which Service Principals belong to you (as the customer) and which belong to Microsoft/Azure.

  $result = az ad sp list --query "[].{ServicePrincipalName:appDisplayName,AppID:appId,TenantID:appOwnerTenantId}" --output table --all -o json | ConvertFrom-Json 
  $result | export-csv -Path "C:\temp\ServicePrincipals.csv"  -NoTypeInformation

Now I can filter the Service Principals based on the appOwnerTenantId to differentiate between customer created versus Microsoft/Azure created.

I hope this helped, and now you know Microsoft/Azure creates hundreds of Service Principals in every Azure tenant that are needed for various services, and roles.

Azure Virtual WAN – Now supports 3rd Party Network Virtual Appliances (NVA)

Following up on a previous post for Azure Virtual WAN, one of the key items I brought up was that lack of integration for 3rd Party Network Virtual Appliances (NVA) and how you are encouraged to use Azure’s Firewall service. Well, as of today, July 21, 2020, you can now deploy NVA’s within the vWAN. This is great news, as many customers prefer 3rd party firewalls, ie. Palo Alto, CheckPoint, etc.

Looking forward to testing this out.

For more information, read up on the following post HERE.

 

Azure Virtual WAN (Hub-Spoke v2.0)

Over the past few years I have been promoting customers to adopt the Microsoft/Azure’s Hub-Spoke (Hub and Spoke) network topology and its architecture. Not too long ago (Ignite 2019), Azure has made some significant improvements with their architecture and best practices by introducing “Virtual WAN“. I like to call this new service and evaluation as the new Hub-Spoke architecture version 2.0.

What is Azure Virtual WAN?

Azure Virtual WAN, or vWAN is a networking solution/service that allows you to integrate key functionalities such as networking, routing and security within a single pane. Azure vWAN is really a software-defined (SD) solution of WAN based technologies, and similar to service endpoints, and private links, Azure vWAN leverages the Microsoft network backbone to build a highly-available and high-speed global transit network. These functionalities include branch connectivity such as Site to Site VPNs, Point to Site VPN, ExpressRoute and intra-cloud/transitive networks, Azure Firewall and encrypted private connectivity.

Azure vWAN SKU Type

Microsoft has made it simple with the options you get with Azure vWAN, either basic or standard. Once you deploy Azure vWAN, you can get started with one of the use cases (as mentioned above) and add functionalities as your network evolves.

With Basic, you can only leverage vWAN for a Site to Site VPN connection. However once you go to the Standard SKU, you can now leverage all of the functionalities mentioned above, ie. Site to Site, Point to Site, ExpressRoute and Inter-Hub and VNet to VNet transiting via the vHUB.

Architecture (simplified) Overview

The image below depicts a high level but comprehensive with its capabilities on how Azure Virtual WAN can be integrated for various scenarios. With the “Any to Any” connectivity model, the Global transit network enables to connect your branch offices, remote users, datacenters, Azure VNets to one another. The image and model below, a spoke can be your Azure VNet, or a branch office, or a remote user, or perhaps the Internet. This architecture enables logical one-hop transit connectivity between the networking endpoints.

Source: https://docs.microsoft.com/en-us/azure/virtual-wan/media/virtual-wan-global-transit-network-architecture/figure1.png

Conclusion

The Azure vWAN architecture is a hub and spoke architecture that incorporates scalability, resilience and performance built in for branches (VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2), ExpressRoute circuits, and Azure virtual networks (VNets). There are some excellent benefits of using Azure Virtual WAN within your architecture as it simplifies the overall network topology and provides a handful of opportunities to integrate your on-premises datacenters, branch offices, remote users into a global transit network architecture. There are some limitations I can already see today, and that being not being able to leverage 3rd party network virtual appliances (NVA) such as Palo Alto, Checkpoint, etc., however I am sure that is already within the roadmap.

(more…)

Azure Service Endpoints versus Azure Private Links

Recently a lot of folks have been asking about Azure Service Endpoints and Azure Private Links — what’s the difference? when to use which? and why?

For starters, let’s review what is a Service Endpoint, and what is a Private Link? Followed by which solution is better to use, and why….

Azure Service Endpoints

With any Azure Virtual Network (VNet) you can leverage a ‘service endpoint’ that provides a secure connection and a direct connection to Microsoft Azure’s service over Microsoft’s backbone network infrastructure. The service endpoints allow you to run services/resources over the VNet and enables private IP Address within the VNet to communicate with the Azure service without the requirement of having a public IP on the VNet. Service Endpoints work by enabling your VNet or subnet(s) to support the Service Endpoint, and once enabled, you can configure which PaaS resource(s) can accept traffic from those subnet(s)/VNets. There is no requirement to do any IP filtering and/or NAT translation, all you need to tell is the PaaS resource(s) which VNet/Subnet to allow traffic from. When Service Endpoints are enabled, the PaaS resource sees traffic coming from your VNet private IP, not the public IP.

Azure Private Link

Azure Private Link allows you to access Azure (PaaS) services, like Key Vault, Storage, Log Analytics, etc., over a private endpoint within your Azure VNet. The communication between the Private Link (endpoint) and your VNet continue to travel over the Microsoft’s backbone network, however your service is no longer exposed over the Internet. One drawback with Private Link is that to support resolution of the PaaS resources using the same name, you do need to implement DNS to resolve the private link zone for that resource. There is integration with Azure Private DNS to set this up for you, but this can be problematic if you have your DNS service already running, or do not want to use Azure Private DNS with your VNet. Once enabled, you have now granted access to a specific PaaS resource within your VNet. Meaning, you can control the egress to the PaaS resource. Unlike Service Endpoints, Private Link allows access from your on-premises infrastructure to Azure resources over an ExpressRoute circuit, or Site to Site VPN tunnel, or via its peered VNets.

What’s the difference, and when to use?
  • The biggest difference between Private Links and Service Endpoints, is Public IPs. With Private Link, there is never any Public IP created and traffic can never go through the Internet, whereas with Service Endpoints, you have the option to limit access.
  • Second key difference with Private Link is, once enabled, you have now granted access to a specific PaaS resource within your VNet. Meaning, you can control the egress to the PaaS resource.
  • Service Endpoints are much simpler to implement and significantly reduce the complexity of your VNet/Architecture design.
  • Private Link will always ensure traffic stays within your VNet.
  • Another key difference between Private Links and Service Endpoints, is cost. There is a $0 cost to implement Service Endpoints, as the cost is already integrated within the VNet cost itself. Whereas Private Links costs can quickly grow depending on the total ingress and egress traffic and the runtime of the link. For example, within Azure Canada Central, to have a Private Link that is available for 730 hours in a given month, and that allows 100TB of ingress and egress (for both) can run over $2,000 monthly.
    • This is something to factor when designing or implementing either solution, as Private Links will quickly add to your monthly spend.
  • Another consideration is, availability, meaning Service Endpoints and Private Links are not generally available for all services, for example. There is no Service Endpoint as of writing this post, for Azure Log Analytics. However, there is a solution for Private Links for Log Analytics. Both services are available but not for all resources/services. For the complete list you can visit the links below, Service Endpoints: HERE ; Private Link: HERE.

Ultimately, if you are considering either solution, Private Link versus Service Endpoint, then you are probably concerned with security and with that said, Private Link is superior to Service Endpoints. The services available to Private Link will continue to grow like Service Endpoints, but based on my observation, it appears Private Link has a much deeper portfolio with Azure services integration.

Azure Policy – Approved VM Extensions

I work with many customers where Security is no longer a second-thought, but the key driver for any conversation/engagement. One of the many Governance standards and policies that typically comes up during these conversations, is to ensure their Azure environment resources can only have approved extensions deployed. The policy also falls under the highly recommended CIS benchmarks. Ensuring your environment is following CIS benchmarks and controls is a very good starting point.

First, you need to understand which extensions are available. To get the list of all extensions available, within your Azure region, and dump it to a file, you can use the following PowerShell code:

Get-AzVmImagePublisher -Location "canadacentral" | Get-AzVMExtensionImageType | Get-AzVMExtensionImage | Select Type, PublisherName, Version | Format-Table -AutoSize | Out-File -FilePath .\VMextensionsCanadaCentral.txt

Next, now that we know which extensions are available, we need to understand which extensions we want to allow. Once we have that list, it is simply adding the list of extensions (separated with a semicolon; ensure no whitespace exists!!).

Once you have the list, deploy the Policy “Only approved VM extensions should be installed” and set it to ‘Deny‘. Or on the flipside, you can set the Policy to ‘Disabled’, which would allow the Policy to allow extensions, but the following within the list. Depending on your security stance, you can either allow explicit extensions and deny all by default. Or, allow any extension by default, however disable only the following extensions based on your list. I would think the former provides more control.

Once you have the policy deployed, configured and enabled, your users will get an error something like this, if the extension the VM is requesting is not a part of the approved list…

To get this policy in your environment, you can either go to the Azure Policy service and look up the definition, or visit the following link HERE, and access the JSON/Policy from Azure’s GitHub repo.

Azure Security Center – Continuous Export via Azure Policy

Earlier this week, I highlighted how you can use Azure Security Center (ASC) and its Continuous Export feature to send Security Alerts and Recommendations to Event Hubs (and/or Log Analytics) — you can find that post HERE. Today I want to show you how to can use Governance best practices, and leverage Azure Policy to ensure ASC is configured to forward to either Event Hubs and/or Log Analytics.

As a quick intro, Azure Security Center (ASC) is a holistic solution provided by Microsoft to not only assess your Azure resources, but can also be extended to your On-Premises infrastructure as well. ASC is a security management solution that improves your overall security posture within your Azure environment and on-premises infrastructure. I work with a lot of customers where they require an “agnostic” SIEM solution. ASC generates detailed security recommendations and alerts that can be viewed through the ASC portal. However when customers have a requirement to send this telemetry to some third party SIEM, such as QRadar, Splunk, etc. In short, your Azure resources can send their security events directly to Event Hubs (via Diagnostic Agents) or can be configured (the easier approach) with ASC.

To get these policies, go HERE to the Azure GitHub repo. Next post, I will walk you through the setup and all the necessary parameters that are required to get this policy up and ‘governing’.

Azure Security Center – Continuous Export

Azure Security Center (ASC) is a great holistic solution provided by Microsoft to not only assess your Azure resources, but can also be extended to your On-Premises infrastructure as well. ASC is a security management solution that improves your overall security posture within your Azure environment and on-premises infrastructure. I work with a lot of customers where they require an “agnostic” SIEM solution, so they don’t have all of their eggs in one basket (sort of speak) with a single vendor. Azure Sentinel is a great solution, but still lacks maturity in comparison to other products like IBM’s QRadar, Splunk and some others.

ASC also generates detailed security recommendations and alerts that can be viewed through the ASC portal. However when customers have a requirement to send this telemetry to some third party SIEM, Azure’s Event Hubs is a great middleman solution.

In short, your Azure resources can send their security events directly to Event Hubs (via Diagnostic Agents) or can be configured (the easier approach) with ASC. Choosing the latter, we can also configure ASC to Continuously Export the data being collected in ASC to be forwarded to Event Hubs. Which in turn will allow the third party SIEM to ingest the data within Event Hubs.

Once you have enabled ASC, enrolled your resources, (assuming you have already configured Event Hubs and a third party SIEM) you can then setup Continuous Export within the ASC console as shown below.

Setting up ASC Continuous Export is pretty straightforward, provided you have already configured Event Hubs, and your SIEM to ingest from Event Hubs. Within ASC, select Continuous Export. Enable which workspace to send the data to, either Event Hubs, or Log Analytics (Sentinel). Select the type of alerts and recommendations (All, Low, Medium, High). Specify the Subscription where Event Hubs lives, the Event Hub Namespace, Name, and Policy Name. Hit Save, and that is it!

That is, pretty simple. Definitely a much easier solution than deploying Linux and Windows Agent Diagnostic (LAD/WAD) — another post for another day 🙂

Azure Security Center – Secure Score Enhancements

Over the last few days, Azure Security Center (ASC) made an update to how Secure Score is calculated. This new enhancement simplifies how the Secure Score is calculated, and in this post I would like to show how this is done.

As previously mentioned, Azure Security Center is a high-level, holistic assessment of your Azure environment. Azure Security Center can also be extended to your on-premises environment as well. Nevertheless, one of the key functionalities ASC provides is a Secure Score. Secure Score is a calculation based on your specific environment, and the resources deployed within your environment. The Secure Score provides a ratio between your healthy resources and total resources deployed within your environment as per recommendation for each security/vulnerability.

To see your Secure Score, go to Azure Security Center, and looked for your score within the Policy & Compliance blade:

Now let’s look at how the Secure Score is calculated.

If you drill down to your recommendations section, you can see how each control and its potential score. You can also review how you can achieve a higher score by implementing the suggested recommendations.

If we select one of the many recommendations, we can see by implementing MFA in the environment, our overall Secure Score has the potential to increase by 10 points, or 18%.

To get the full list of Security Controls and each recommendations, please see Microsoft’s documentation HERE.