Posts Tagged Azure

Zero Trust approach

We talk a lot about security and protecting ourselves from external threats, threats started to emerge from inside your enterprise fence, hence protecting your business assets became a necessity. The question we hear a lot now is how do we protect our business? The answer is by embracing the “Zero Trust model”.

So, what is “Zero Trust model”? I hear you say! It is a set of rules and principles that dictates the way we should look at our identity, network/data and infrastructure security, and devices (both corporate and with companies implementing BYOD).

Lets look at those principles in more detail and define a simple strategy in setting our goal for more secure environment without impeding productivity.

Identity – people when they hear identity they think of two-factor authentication straight away, problem solved! or is it? Unfortunately, it’s not as simple as implementing 2FA or multi-factor authentication (MFA), it’s about knowing who, what, where and which:
Who – who are you in the context of a username and password, a lot of business are going passwordless (i.e. bio-metrics)
What – what device are you using to access, does the device comply with company policy (such as patches, anti-virus etc)
Where – where are you accessing from (i.e. geo location), are there any anomalies, such as login attempt from distant geo locations in a short period of time.
Which – which service/data are you trying to access, so having appropriate permissions set is a key, using least privilege as the base for applying permissions. Not to forget auditing those permissions and their access is also a must to ensure access is being evaluated appropriately.

There are many factors that need to be surfaced in order for the IT department to be able to understand how their staff are authenticating and being authorised to access corporate data or service.

As we discussed earlier that businesses are facing a lot of threats not just from external sources but internal ones as well, including rouge admins (whom hold the key to the kingdom!). Implementing identity management is important in the era of cyber wars, having services such as Azure AD that integrates and compliments your on premise AD enables you to detect and prevent suspicious logon’s by taking all the above into consideration.

Azure AD uses Machine Learning in the core to look at billions of signals received to learn and detect anomalies, conditional access would also complement this solution, through understanding the context and risks of sing ins and provide the right access.

How can you start protecting yourself?
Identity management life-cycle management is a key topic, policies to enforce strong passwords but also making it easier for users to remember them without the need to write them on a sticky note and leave them on their laptop, or even better
The use of multi-factor authentication, so just a password isnt enough anymore. How can I verify my staff identities? With something they are (i.e. username), something they remember (i.e. password) and something they have (i.e. phone or physical token).
Some of the points above might not be news to you, but ensuring appropriate policies are in place with audit trail and appropriate assessment of access is a must, through assume breach approach.

The high level architecture above shows level of security taken by corporations such as Microsoft to secure their assets and services, Microsoft doesnt take it lightly when it comes to security, it’s the heart of their service of which Microsoft Azure, Microsoft 365 and Dynamics 365 are built.

As shown through the simplistic architecture above, the extensive use of Azure AD services such as MFA, Conditional access, in addition to enrolling devices into Microsoft Intune to manage device health would ensure that access is traced and authorised appropriately. This approach would provide a cloud scale and an enterprise grade service.

Its important now days to minimise the blast radius when it comes to a compromise, by minimising lateral movements through the appropriate use of network segmentation, using encryption through all user access sessions and between different tiers, in addition to using analytics to get visibility and drive threat detection and improve defences such as Azure Sentinel.

Using this as the core topic for our next discussions, by building security and zero trust model in the core of our design offerings.


Leave a comment

Azure Key Vault Access Policies

Azure-KeyVault_COLORAzure Key Vault is used to safeguard system critical data, such as keys, secrets and certificates that are part of your infrastructure core operations.

Key Vault access is managed through two interfaces: management plane – this dictates access to the Key Vault itself but not managing its content which is based on RBAC model, data plane – this enables granular control of keys/secrets/certificates, which relies on Access Policy.

This brings us nicely to Access Policies which is meat of this article. I have had to deal with a situation lately while applying access policy for a colleague while a restriction is imposed on my Azure AD account (see example below)




This would have limited access to my account (which is external) to AAD, which means I cant read or search AAD which is required when adding access policy via the GUI – Setting RBAC without access to AAD works (as an exception) if you know the full FQDN of the user you are adding.

The way around is to use PowerShell, but this requires a prerequisite which is the Azure AD object ID for the user you want to add, this can be achieved by adding them temporarily on management plane to access their user properties and copy object ID before deleting that rule.

Now to the command I used to apply that permission:

Set-AzKeyVaultAccessPolicy -ObjectId *** -VaultName **** -PermissionsToKeys **** -PermissionsToSecrets **** -PermissionsToCertificates **** -BypassObjectIdValidation 


Key property here is the BypassObjectIdValidation, if the Object ID exists in AAD then it will be linked and the user will have their access policy applied to Azure Key Vault.

, , ,

Leave a comment

DevTest Labs and Auto-start

DevTestIconLargeWhile working with DevTest Labs on Microsoft Azure, it’s a good idea to make sure you have Auto-start and Auto-shutdown policies to keep cost down on resource utilisation while not being used.

The mistake or misconception I had form customers and I see this continuously that they forget to opt the VM in or out of the policy when scheduling these machines to shutdown or start at certain times.

This needs to be enforced on a per VM basis, see below.


, , ,

Leave a comment

Application Gateway bug – Jan 2017

bug-512I have been working with Microsoft lately on an issue that I was experiencing with an Azure application gateway (appGW) deployment that require both internal and external interfaces handling traffic over HTTPS.

If you try to attach the same AppGW front end port to internal and external front end configuration, this would cause the appGW to misbehave. In my scenario I had a rule attached to external interface for handling incoming traffic but no rule attached on the internal interface and as a consequence the internal interface started processing traffic while the external interface was rejecting all connections (not even 502 error! would you believe!). Just to note that all my appGW deployments are scripted using PowerShell/JSON.

Microsoft managed to replicate this internally and issued a bug report, they are working on it as we speak but without ETA currently.

I had to drop my second listener (internal) in order to bring the appGW back to it’s expected behaviour!

, , , ,


Azure resource re-allocation and Resource Groups

Azure-logoInfrastcuture in the cloud (IaaS) is such an evolving topic from the architectual point of view. As services do evolve and more functionalities get added in order to enable the end user to untilise these services in best forms, complexities do start to add to it.

IaaS require a lot of initial planning to minimise any downtime required to re-allocate services/servers for production (Prod).

If breaking to Azure services started as a proof of concept (PoC) initially and changed suddenly to being the business critical service that your business can’t function without – without the necessary transitional planning then we are on the same page here.

Microsoft Azure does add a lot of value to the business and continuity of its business operations.

In this article I will go over Azure different resources and the way they could be organised for ease of management and billing. Billing is an important topic if you want to understand how your services are being utilised in the cloud or in order to bill each business unit if your business is using the charge back model.

If you have just started building your infrastructure on Azure, ensure your business units use Azure Resource Groups to group their services/servers and that could save you a lot of time in the long run.

The way to move resources between different resource groups are a complex ‘PowerShell driven process’. First you need to understand the limitiation of resource move:

  1. vNet’s can’t be moved
  2. Re-allocated Azure resources will retain their source region, even if your destination resource group is in a different region.
  3. You can’t move a single VM attached to a cloud service, the cloud service and all VM’s attached to it will have to move together.
  4. From experience, move storage accounts seperately. When I try to move a storage account with the rest of resources I get error (“One resource move request can contain resources of only 1 provider.”) :storage-err
  5. If you would like to migrate the VM to a new vNet then the VM needs to be deleted and reprovisioned on the vNet – the VM will down for that duration.
  6. If you would like to move the VM to a new storage account, then the downtime will be much greater depending how big the VHD files are and the region. I won’t talk much about this process, you will find it detailed here.

Now we will talk about the interesting part, the move and re-allocation process.

  1. Download the latest Azure Powershell module (We will be using the latest Azure Resource Management module) as illustrated here
  2. Login to your subscription using Login-AzureRmAccount
  3. Get the content of your source resource group on Azure: Get-AzureRmResource
  4. Feed the output to Move-AzureRmResource

I have written a short script to demonstrate this process (MS Azure Resource Group Management(MS Azure Resource Group Management), I have added comments necessary to each of the steps in the script so you should be able to customize it to your needs.


Leave a comment