So let me start this post off with a story…
A Couple of weeks ago I had some issues with a demo environment I was hosting in Microsoft Azure, where I had automated all of the infrastructure setups using ARM but there was still a lot of work done manually. The demo environment was setup using a single admin account which had access to the domain. Now one day before I had a speaking session, I got into an issue that the account password expired and I didn’t have a simple way to access the environment since I wasn’t able to disable NLA I couldn’t reset the password remotely since I don’t have console access to the environment. So basically locked out of my own environment with the single user account I had, so how could I solve this in Microsoft Azure?
First of I intended to use the “Password reset” option that Azure provides in the portal but that is by design disabled if you want to run it on a domain controller so therefore that was not an option.
I ended up with using a Custom Script Azure Extension running a PowerShell Script (Set-ADUser -Identity $_.SamAccountName -PasswordNeverExpires:$FALSE) to disable the password expiration of my user before I had my presentation, which was run in Azure and therefore allowed me to gain access again. Of course I was thrilled that I got access again before my session, but… and this brings me to the point of this post which is to show about best practices and how we can properly secure an Azure environment, because in theory I didn’t have any access to the virtual environment but because of my access in Azure I could run some scripts and gain access in, this first post is going to be focused on Identity and role based access control in Microsoft Azure.
Identity:
First, of we need to start with securing the users which has access to Azure and also define a proper access control to resources and services. Azure access is given either on a subscription level or resource group. We have 4 different types of roles that can be given to a user.
- Owner (Has access to everything inside the subscription and also assign others to the same level)
- Contributor (Has access to everything inside the subscription but cannot assign others to the same level)
- Reader (Has read-only access to everything inside the subscription)
- Custom Predefined roles (Azure comes with many predefined roles)
- Custom Roles.
We should always as often as possible restrict the number of users with Owner access on a subscription level. When you are given an Azure role you are actually given access to perform actions within a resource provider. So, for instance, owner role is allowed to perform all Action against all registered Resource providers. So my ability to install a guest extension within a virtual machine in Azure is based upon my access against the Resource Provider Microsoft.Compute/virtualMachines/extensions and having Write access there.
All Resource Providers and Actions are documented here –> https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations
As a best practice, we should create custom roles to define proper access to users who need access to Microsoft Azure, so if we needed to create a custom role which only has certain actions they can perform against a resource provider, we would need to define a custom JSON file. Now within a custom role JSON there some required attributes.
Use of Custom Roles
Example Role:
Name: is the name of the role in Azure
Actions: Define which type of actions that a user can perform against a resource provider. (All Actions against the different resource providers can be found here –> https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations ) or you can view actions from a resource provider directly from PowerShell here –>
Get-AzureRMProviderOperation “Microsoft.Compute/virtualMachines/*” | FT OperationName, Operation, Description -AutoSize
AssignableScopes: Define if this role can be targeted directly at a subscription level or against a resource group. As an example we can have subscriptions listed here,
“AssignableScopes”: [ “/subscriptions/{subscriptionId1}”, “/subscriptions/{subscriptionId2}”, “/subscriptions/{subscriptionId3}”
{
“Name”: “VM Restarter”,
“Id”: “88888888-8888-8888-8888-888888888888”,
“IsCustom”: true,
“Description”: “Can restart virtual machines.”,
“Actions”: [
“Microsoft.Storage/*/read”, “Microsoft.Network/*/read”, “Microsoft.Compute/*/read”, “Microsoft.Compute/virtualMachines/restart/action”, “Microsoft.Authorization/*/read”, “Microsoft.Resources/subscriptions/resourceGroups/read”, “Microsoft.Insights/alertRules/*”, “Microsoft.Insights/diagnosticSettings/*”, “Microsoft.Support/*”
],
“NotActions”: [ ],
“DataActions”: [ ],
“NotDataActions”: [ ],
“AssignableScopes”: [
“/”
]
}
Once we have created this as a JSON file we can import this custom role into Azure using PowerShell or CLI –> az role definition create –role-definition ~/vmrestarter.json
Role Access in Azure
Also having a predefined role that we want to give to a particular user we also need to define that to the correct scope or level or access. Might be that we have a subscription with multiple resource group where we have multiple virtual machines or resources and we should ensure that we only give access on a certain level or to a certain resource beneath. In Azure we can define if a user should have access to multiple resource or multiple resource groups. It is important to remember that access that you assign at a parent scope is inherited at the child scope. Also important to define access to resources based upon groups and not using individual users.
Group based Access
Combining this with dynamic groups we can also ensure that once a user has access to the Azure Portal we can customize if the user should have access based upon department or if the user has a approved device or not (NOTE: Do not confuse this with Conditional Access. CA does a real-time check before the end-user is allowed to gain access to for instance the Azure Portal based upon conditions. Dynamic attribute groups can be used to limit access inside the Azure Portal itself) there are multiple attributes that we can use to configure dynamic groups, most of them are found here –> https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-dynamic-membership also combine this with proper naming standards on Azure AD Groups which can be done using the latest PowerShell modules on Azure AD here –> https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-naming-policy
Also moving forward, Microsoft is coming with RBAC within the resource itself such as Storage Accounts and different Storage Blob’s within (this is still in preview and you can view more about it here –> https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions
Use of Conditional Access to Azure Portal
Of course we can always restrict what kind of permissions an system administrator can have in the Azure Portal, but of course if we have an user with Owner level access on the subscription level, we always need to trust that the user says who he say he is, also we never get a good indication on if that user is coming in from an compliant endpoint.
Luckily we have Conditional Access which we can use to determine different conditions before an system administrator is allowed access to the Azure Management.
Remember a policy you create applies to all Azure management endpoints, including classic Azure portal, Azure portal, Azure Resource Manager provider, classic Service Management APIs, and Azure PowerShell.
It is also important that you don’t lock yourself out of the Azure enviroment, so you should also have a backup user that you can use to change the access rules. For instance if you have an a non compliant device and want to access the azure portal you might not get access until the device is compliant again. So therefore you should always combine multiple rules.
Password Protection and Smart Lockout
You can also define Authentication methods and Smart Lockout policies on your Azure AD tenant. Smart Lockout is kinda like lockout password policies in AD where if a user has to many failed authentication attempts they are temporary banned from logging in. Here we can define the lockout duration and threshold, but we can also define custom banned password combined with what Microsoft has implement as part of the standard for Azure AD as well.
A New feature that was introduced a couple of weeks ago was Password Protection for Windows Server Active Directory which allows us to (NOTE: Also requires Azure AD Premium license) This feature (in public preview) is made to enhance password policies in an organization. The on-premises deployment of Azure AD password protection uses both the global and custom banned password lists stored in Azure AD, and performs the same checks on-premises as Azure AD cloud-based changes. There
Restrict Azure AD Catalog
I also typically make some changes to the standard Azure AD catalog setup as well to ensure to restrict Azure B2B and notifications as well. First of ensure that you restrict end-user access to Azure AD Administrator Portal under the Azure AD Catalog.
External Collaboration Settings
Then under External Users, we should restrict who can invite guest users to the Azure AD Catalog. One issue here is that for instance if we have have MFA enabled for all our users, this will not apply for B2B users, so we can have for instance a owner user in our Azure subscription which might not have MFA enabled since we cannot control users which are contained within another Azure Directory. So I typically restrict who can invite and define which domain can be included as part of the B2B invite.
Auditing and logging
Azure AD also provides extensive logging for user sign-ins and different activies against an catalog and also changes made to an Catalog. As part of a best-pratices you should always check the logs every once in a while to see for suspicious activity.
You should also take note that Microsoft also has SIEM integration solutions which such as Splunk which has their own Splunk to get information about activities here –> https://splunkbase.splunk.com/app/3757/ or you can use a REST API Call to get a JSON based report on the audit log as well –> https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-api-audit-samples or you can use the Office 365 Addon to log analytics to get Azure AD Sign-in activity as well, note there is an delay here incoming activities but combining this with Azure Activity log we have a good summary of what an particular end-user has authenticated and changes they made in Microsoft Azure regardless of sources.
NOTE: (OfficeActivity is actually Azure AD activity here, but is collected by Office365 Log Analytics Module)
Microsoft also has two other reports which show information about unusual activity against Azure AD.
- Risky sign-ins – A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
- Users flagged for risk – A risky user is an indicator for a user account that might have been compromised.
Users appearing on this list can be an indication that a user has been compromised and is now being accessed from another location, or is logging in from an infected devices. So ensure as a best-pratices that you check trough users that come on in this list. Also ensure that after if you have verified that is was legitimate usage of that account that you approve the alert
However sometimes you might be to late and an user has been compromised and someone has been logging into your Office365 tenant and getting sensitive information from internal SharePoint site or OneDrive, so doing a manual check might not suffice. In those cases and you are a targeted organization you should also consider Azure Identity Protection, which can be triggered if Microsoft detect a user with a risk you can apply an action to it. Such as here, if Microsoft detects a user with high-risk Azure AD will automatically make sure that the user needs to change its password before continuing. Now the different risk levels can be found here –> https://docs.microsoft.com/nb-no/azure/active-directory/active-directory-reporting-risk-events
Identity Syncronization
When setting up Identity syncronization and authentication you have 3 possible setup’s, either using federated setup, where authentication happens on-premises against an ADFS solution, we have password hash or we have passtrough authentication. If we are using federated setup and our ADFS Servers are placed in Azure, remember to enable security center on those virtual machines combined with Security logs streaming into log Analytics. This allows us to see authentication attempts into our ADFS solution.
As mentioned earlier the Users with leaked credentials report in the Azure AD management warns you of username and password pairs, which have been exposed. An incredible volume of passwords is leaked via phishing, malware, and password reuse on third-party sites that are later breached. Microsoft finds many of these leaked credentials and will tell you, in the report, if they match credentials in our organization, but only if we enable password hash synchronization option.
Azure AD Access Review
Note: This is a service that requires Azure AD P2 or EMS E5 licenses –> https://docs.microsoft.com/en-us/azure/active-directory/active-directory-azure-ad-controls-access-reviews-overview
But this allows us to do
- We can recertify guest user access by using access reviews of their access to applications and memberships of groups. Reviewers can use the insights that are provided to efficiently decide whether guests should have continued access.
- We can recertify user access to applications and group memberships
- We can collect access review controls into programs that are relevant for your organization to track reviews for compliance or risk-sensitive applications.
- We can recertify the role assignment of administrative users who are assigned to Azure AD roles such as Global Administrator, or Azure subscription roles.
Summary: So a short summary of what I’ve written of the points to far, of what you need to consider from a how you can secure identity in Microsoft Azure.
* Use built-in tools to proper design role-based access control to ensure correct level of access to resources in Microsoft Azure, also access should be given on dynamic group level to ensure that access is given not on a static user level.
* Enable MFA on High level access users
* Logging and Audit those logs on access and ensure that you review users with delegated administrator rights. either using SIEM integration or built-in tools, but also verify risky sign-ins within Azure AD
* Use Conditional Access to lock down access to the management API to ensure that users are coming from a compliant device and ensure MFA based upon conditions.
* Make changes to the default Azure AD for external collabaration settings to ensure that you have control of guest user access to your tenant.
Stay tuned for more!