Continuing with the do’s of Identity and supposing that you are in part of your journey that you have either Hybrid or fully cloud-based identities.
In the last part I covered how you can create your own roles and use Privileged Identity Management and Privileged Access Groups to secure the existing and new roles.
And also how to use that group to make an M365 Group and keep the communication between the corresponding admins.
In this part we will see how to secure your applications with Conditional access and other methods.
Create custom security attributes
This feature is currently under Preview but it can help you with the following:
- Extend user profiles, such as add Employee Hire Date and Hourly Salary to all my employees.
- Ensure only administrators can see the Hourly Salary attribute in my employees’ profiles.
- Categorize hundreds or thousands of applications to easily create a filterable inventory for auditing.
- Grant users access to the Azure Storage blobs belonging to a project.
And you can enable it to the assets:
- Azure AD users
- Azure AD enterprise applications (service principals)
- Managed identities for Azure resources
To good with Custom security attributes is that they are available tenant-wide, support different data types (Boolean, integer, string), you can add single or multiple values or user-defined free-form and predefined values
You can also assign custom security attributes to directory synced users from an on-premises AD.
How to create them?
You can create them from https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/CustomAttributesCatalog
Then use them with …
Filtering permissions for applications
Custom security attributes must be managed by delegated users since they are security-sensitive. Custom security attributes do not even have default permissions for global administrators.
Users who handle or report on these attributes should be given one or more of the following roles.
|Attribute assignment administrator||Assign custom security attribute keys and values to supported Azure AD objects.|
|Attribute assignment reader||Read custom security attribute keys and values for supported Azure AD objects.|
|Attribute definition administrator||Define and manage the definition of custom security attributes.|
|Attribute definition reader||Read the definition of custom security attributes.|
Where to enable?
When you create a new Conditional access policy, you will find it under Cloud apps or actions.
But you could also …
Use Conditional Access authentication context
Instead of only at the app level, Conditional Access authentication context (auth context) enables you to apply specific controls to sensitive data and actions. While reducing user friction, making users more productive, and increasing the security of your resources, you may improve your Zero Trust policies for least privileged access.
You need to have E5 licenses to use context with SharePoint sites.
How to create?
Create context from CA control plane.
Then create a new policy
And open Compliance portal and assign the policy https://compliance.microsoft.com/informationprotection?viewid=sensitivitylabels
Or with PowerShell
Set-SPOSite -Identity https://cloudnoso.sharepoint.com/sites/HRSite -ConditionalAccessPolicy AuthenticationContext -AuthenticationContextName "SPO Auth Context"
And now when we are talking about Conditional access, we can also talk about MFA. Did you know that …
On-premises MFA is deprecating
This was excepted move from Microsoft and makes complete sense. Multifactor authentication requests will no longer be supported after September 30th 2024, which could result in authentication failures for your organization.
What can I do?
You can setup MFA NSPS extension and use the migration tool to transfer your users MFA methods to the cloud.
See more from my previous post.
And once your transform is done, how about to …
Enable Secure authentication methods
For push notifications in Microsoft Authenticator in all tenancies, number matching is a nice illustration of protection for an authentication technique that is currently optional. Customers have the option to enable or disable number matching for push notifications for users and groups in Microsoft Authenticator. Users cannot opt out of number matching, which is already the default behavior for passwordless alerts in Microsoft Authenticator.
Where to enable?
What Microsoft Managed is?
Microsoft Managed means Azure AD can enable or disable protection based upon the current landscape of security threats. Customers can choose whether to allow Microsoft to manage the protection. They can change from Microsoft managed to explicitly make the protection Enabled and not mentioning to Disabled as this will be enabled by default in 27th of February 2023
And also use …
Identity risk protection
Microsoft’s Identity Protection combines the knowledge it has gained from its roles in gaming with Xbox, enterprises with Azure Active Directory, and the consumer market with Microsoft Accounts to safeguard your users. Microsoft analyzes trillions of signals every day to spot risks and defend consumers.
Identity Protection performs a real-time analysis of hundreds of signals during each sign-in and determines a sign-in risk level, which expresses the likelihood that the particular authentication request isn’t permitted. After Conditional Access receives this risk level, the organization’s specified policies are reviewed.
By examining user account signals, Identity Protection determines a risk score depending on the likelihood that the user has been compromised. Identity Protection will evaluate these signals to determine the user risk level if a user exhibits dangerous sign-in behavior or if their login credentials have been compromised.
Where to enable?
You can enable it with Conditional access for enforcement.
And enforce MFA if you chose User and Sign-in risks as conditions Authentication strengths
If you choose “Require password change” you can only use user-based risks.
And to monitor your users with Identity protection Overview page.
If you want to see more on what are the different detection methods for risks.
Service Principals aka Workloads
But you can also see the risky behavior from your App registrations, they can be used to escalate permissions if not protected correctly.
With Conditional access you Block and Grant access based the the risk detection
And more information here,
In this part we discovered how we can protect your applications from leaking content. Keep your Identities secure and how to keep using MFA after on-premises MFA Server will not work anymore.
Once you have protected your users and admins, it will be equally important to protect your applications for external threats.
In the next part more Identity do’s and don’ts, Stay tuned!
Links to previous parts
Hackers don’t break in – they log in.