Tag: Azure

Azure Backup Center

· Leave a comment ·

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 MSI & Policy Governance

· Leave a comment ·

Last few weeks I have been really pushing customers to use Azure Managed Service Identity (MSI) as much as possible, assuming the MSI capability exists with the Azure service. Note, not all Azure services support MSI’s today, however for the most part all services do support the traditional Service Principal (SP).

If are are unclear what the difference is between an SP and MSI is, I would welcome you to visit the following link HERE.

With that said, how do we ensure as services are deployed and are leveraging MSIs and not SPs? Azure Policy! Simple right? Yes, it really is. Below is a list of policies that exist today, however this list will continue to grow as more Azure services incorporate MSIs. And of course, if you’re willing, you can always create your own custom policy to ensure the Azure service is using an MSI. Note, the policies availability and the Azure services that support MSIs, is not 1:1. There are more services that support MSIs, than the out of the box policies that support MSIs today. If you are not willing to wait for Microsoft to push out new policies, then you should go ahead and create your own.

Once you have selected the policy, enabled/enforced it, you can now track to see if (for example, Azure Function), if a new Function is deployed and it is not using an MSI, it will be flagged, or you can go further and reject the deployment if it is not using an MSI.

Below is a link that provides which Azure services support MSI’s as of today. Note, this list will only continue to grow. https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities

Azure Default Service Principals vs Customer Created

· Leave a comment ·

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 Service Endpoints versus Azure Private Links

· 1 Comment ·

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

· 1 Comment ·

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.

Automate and Deploy Microsoft Defender Advanced Threat Protection (MDATP) via PowerShell

· 1 Comment ·

A few days ago, I needed to on-board Azure Windows Server VMs with Microsoft Windows Defender Advanced Threat Protection, or in short, MDATP. Sometimes Azure Security Center (ASC) has issues with on-boarding VMs and deploying the MDATP agent. As a result, I wrote the following PowerShell script that will download the MDATP.cmd file from my Azure Blob container and install it locally to the VM. This script allows you to automate it for many VMs to the scope of a Resource Group.

Now there are a few assumptions here…

  1. Download the MDATP.cmd file from the Defender Security Center portal
  2. Remove the requirement for user consent for the MDATP execution
  3. Upload the modified MDATP file to an Azure Blob container
  4. Generated a SAS URI for the MDATP file

There are many examples on the Internet on how to go step #4. Maybe in time I will do another post.

To remove the requirement of the MDATP agent to execute based on user interaction/consent can be done by removing, or commenting out the following lines of code. Launch the MDATP.cmd file within Notepad, and add a “:” before each line of code from lines 9 through 19, except line 14. Should look something like this.

Now, update and run the following PowerShell code. You can validate the VM is calling back to the Defender Security Center portal or by running the MDATPClientAnalyzer on the VM.

#update resource as needed
$resourcegroup = "YOUR_RESOURCE_GROUP"
#get only Windows Server VMs
$vms = Get-AzVM -ResourceGroupName $resourcegroup | Where-Object {$_.StorageProfile.OSDisk.OSType -eq "Windows"} | Select-Object Name
foreach ($vm in $vms)
{
    #friendly start message to indicate which server has started
    Write-Host "Server $vm has started..."
    #create folder, do not display error if folder already exists
    New-Item -Path "C:\" -Name "MDATP" -ItemType "directory" -ErrorAction SilentlyContinue
    #download MDATP.cmd file from Storage Account with SAS URI. Execute the cmd file. Passing "Y" to continue with installation.
    Invoke-WebRequest -Uri "YOUR_URI_SAS" -OutFile WindowsDefenderATPLocalOnboardingScript.cmd; Start-Process -FilePath "C:\MDATP\WindowsDefenderATPLocalOnboardingScript.cmd" -Verb RunAs
    #sleep for 5 seconds
    Start-Sleep -Seconds 5
    #restart-server
    Restart-Computer -ComputerName $vm
    #friendly finished message to indicate which server has completed and will now reboot
    Write-Host "Server $vm has completed, reboot initiated..."
}

Get Azure Global Administrators

· Leave a comment ·

Recently a customer asked me to retrieve all users that have Global Administrator access to their Azure environment. The PowerShell code below will allow you to query the Azure environment against Azure Active Directory (AAD). Nothing new here or unique here, but this quick two-liner should do the trick. 😉

$role = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Company Administrator'}
Get-AzureADDirectoryRoleMember -ObjectId $role.ObjectId | Sort-Object DisplayName | Select-Object DisplayName, UserPrincipalName, ObjectId

Hope this was helpful!

Azure Bastion – What is it?

· Leave a comment ·

A little late to the party but nevertheless, I wanted to quickly show what is and how to use Azure Bastion. Azure Bastion is still in “public preview” but the solution is mature enough to start implementing now. Azure Bastion reduces the risk significantly in comparison to your traditional jumpbox approach, as it forces users to authenticate over SSL/443.

So what is Azure Bastion? Azure Bastion is a fully managed service by Azure/Microsoft that allows you to RDP and/or SSH into any Azure VM. Azure Bastion allows you to connect to your Azure VMs over HTML5-based browsers and using SSL.

Key Benefits:

  • Protection against 0-Day exploits:
    • Because Bastion sits at the perimeter of your VNet, you do not need to worry about hardening each of your VMs (although you should harden everything!!) The Azure platform will protect you keeping Azure Bastion hardened and is always up-to-date.
  • No Public IP(s) required for your Azure VMs:
    • By using Bastion, you can remove PIPs from your Azure VMs and can force your users to go through the Bastion host to connect to your VMs in your Azure environment.
  • Remote Sessions over SSL:
    • Since Azure Bastion uses HTML5 modern browsers, users can RDP/SSH over SSL (443) enabling you traverse corporate firewalls securely.
  • Simplified Management of NSGs:
    • Since Bastion is fully managed PaaS service by Azure, you no longer need to apply Network Security Groups (NSGs) on your Bastion subnet.  Since Bastion connects to your VMs over a Private IP, you can configure your NSGs to allow RDP/SSH from Azure Bastion only.

Architecture:

Source: Microsoft, https://docs.microsoft.com/en-us/azure/bastion/bastion-overview

The architecture diagram above shows use the workflow how Azure Bastion works.

  • The Bastion host is deployed within a VNet and with its own dedicated subnet
  • Users can connect with any modern HTML5 browser
  • No Public IPs on Azure VMs

Base Requirements:

Before getting setup with Azure Bastion there are some key things to know for example.

  • You must have a Virtual Network
  • The VNet must have a subnet dedicated for Bastion and its name must be “AzureBastionSubnet”
  • It is always recommended to have the subnet with a /27 CIDR. It is easy to grow your subnet as needed, much more difficult to shrink. Always start small and grow as needed.
  • No User Defined Routing (UDR) or Network Security Groups (NSG) can be applied to the subnet.

 

Next step, how to deploy and configure Azure Bastion. If you want to get started with Azure Bastion, you can enroll with the Public Preview here, https://aka.ms/BastionHost.

Azure Policy – Audit for Network UDR Changes

· Leave a comment ·

Azure Policy has been available for some time now, but for folks getting start with Cloud Governance, Azure Policy is a service in Azure that allows you to manage, assign, and create custom policies. These policies can be used to enforce a global set of rules or specific set of controls for a specific environments, ie. less control and governance in a “development” environment. This allows resources to stay compliant with you enterprise standards. Azure policies can enforce different rules, from Denying specific services, for example, ensuring only resources are built within a specific region, ie. resources can only be built within the Canadian regions. Conversely, rather than enforcing, policies can also be configured to Audit, where resources will be marked if they are not compliant, for example, a Storage Account is not configured with secure transfer.

Before diving into the policy itself, I want to quick go over the types of conditions that are available, and that can be used to enforce different compliance rules. The following table shows how different policy effects work with the condition evaluation for the resulting compliance state. Although you don’t see the evaluation logic in the Azure portal, the compliance state results are shown. The compliance state result is either compliant or non-compliant.

Resource StateEffectPolicy EvaluationCompliance State
ExistsDeny, Audit, Append, DeployIfNotExist, AuditIfNotExist*TrueNon-Compliant
ExistsDeny, Audit, Append, DeployIfNotExist, AuditIfNotExist*FalseCompliant
NewAudit, AuditIfNotExist*TrueNon-Compliant
NewAudit, AuditIfNotExist*FalseCompliant
  • *The Append, DeployIfNotExist, and AuditIfNotExist effects require the IF statement to be TRUE. The effects also require the existence condition to be FALSE to be non-compliant. When TRUE, the IF condition triggers evaluation of the existence condition for the related resources.

Source: https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-portal

In this example today, I want to show a real world example, where a customer recently asked to monitor any changes being made to their UDRs (User Defined Routes/Routing).

The following will continuously monitor all UDRs in the environment. If any changes are made to a single UDR table, it will be audited and its changes will be tracked. Once the policy is enabled, you can see it in action by creating/modifying a UDR.

“policyRule”: {
   “if”: {
      “anyOf”: [
       {
            “source”: “action”,
            “like”: “Microsoft.Network/routeTables/*”
       }
    ]
    },
   “then”: {
   “effect”: “audit”
    }
}

See below for the compliance once a change has been made to a UDR. Once you drill down to the event, the user, the activity log, you can then see the exact changes that were made to the UDR.

I hope this was helpful!