CSP - Partner Security Requirements
we are currently reviewing the security requirements for a Cloud Solution Provider (CSP) as we are planning to switch from Security Defaults to Conditional Access.
The general terms and conditions in the partner agreement are:
- Enable multi-factor authentication (MFA) for all user accounts in your partner tenant.
- You must enforce MFA on all user accounts in your partner tenant(s).
- Partners are required to enforce MFA for all user accounts in their partner tenant, including guest users.
- No, it is not possible to exclude any user account from the requirement of having multi-factor authentication (MFA) enforced.
To my understanding, you need to fulfill these security requirements even if they are not technically enforced. Microsoft recommends using the Security Defaults to meet the security requirements. But when using the Security Defaults users are challenged for MFA verification only when necessary - for example when accessing from a new location or device. The user for Azure AD Connect and even technical users e. g. Teams Rooms are excluded from being MFA enforced. Legacy Authentication is still enabled and can be used when setting up app passwords. There is no MFA enforced/required for all users for all cloud apps. So, why does using the Security Defaults not violate the security requirements?
It appears to me that risk-based authentication, user exclusions and app passwords are compliant when using the security defaults, but it is not compliant to exclude users when implementing own conditional access policies. Could you confirm that? Can we exclude technical users from Conditional Access policies, as the Security Defaults do?
We have considered to implement the following conditional access policies:
- Require MFA for administrator roles and partner center agent groups for all cloud apps with exclusion for the Azure AD Connect user and emergency access user
- Require MFA for all users for Microsoft Azure Management with exclusion for the Azure AD Connect user and emergency access user
- Block legacy authentication for all users for all cloud apps with exclusion for the Azure AD Connect user and emergency access user
- Require MFA for all users for all cloud apps when on external networks with exclusion for technical users, the Azure AD Connect user and emergency access user
Will those conditional access policies meet the security requirements?
Why AAD Security Defaults is compliant with the requirements? Well, mainly because it is defined as such. When you look at the MPA (Microsoft partner Agreement), it says mentions explicitly AAD Security Defaults as one option to become compliant, and AAD Premium to enable MFA as another. I know, not really a technical argument, but still the direct answer why it is considered complaint.
I can understand the critics well that the Sec. Defaults MFA is not enforced for all users all of the time, while with Conditional Access you are not allowed to do as such - I know that does seem inconsistent. However, with AAD Security Defaults a certain fixed baseline is ensured, while when Microsoft would allow Partner to do their own exclusions as they see them fit it would probably not work out well towards the solution to ensure minimal security.
However, what is allowed is that you as Partner use Identity Protection (AAD Premium Plan 2) as well to allow for the same risk-based MFA as in AAD Sec. Defaults.
One note also on AAD Security Defaults: While blocking of basic auth. was not enforced for all Partners when they were introduced, afaik it should now be enforced for everybody (at least this is my experience with Partner I have worked with during recent months) - and basic auth. will soon not work anymore when Exchange teams disables it.
And another note on using App passwords with your own Conditional Access rules: This combination works well. You would enforce MFA for the accounts that are using basic auth. using conditional access, and additionally to that you set Per-User MFA to "enforced" on those users. When they then create and use app passwords, the CA condition "require MFA" is satisfied, as can be seen in the sign-in logs. Note that the future of app passwords is generally limited due to the fact that basic auth. will be deprecated altogether.
Note reg. enforcement: Usage of MFA is technically enforced for access to end customer, and access to CSP-related areas of Partner Center, as well as for using Partner Center API - regardless of the MFA configuration of the user.
On your plan:
- Emergency access users are not allowed to be excluded from MFA. So either ensure the emergency access user has not registered an MFA method at all (So you can do this step in emergency), or consider to add "emergency methods" as 2nd factor - e.g. add business phone number, multiple token apps etc.
- You are not required to block legacy auth. because of the security requirements for CSP Partners. However, you are required to enforce MFA for everybody. And since legacy(basic auth. dopes not support MFA this would only work when using App Passwords (btw - excluding AAD Connect and Emergency admin from this rule would not make sense, they are not using basic auth anyway)
- Not requiring MFA just because of the fact the user is in internal network is the - in my opinion - totally wrong approach. You can not assume that your internal network is a safe location, doing this would be major flaw in any security strategy ("zero Trust"). It is not compliant as well with regards to CSP Partners.
- Excluding "technical users" from MFA is the wrong idea as well because they are a know target of attackers, often have privileges - and also not compliant when it comes to CSP requirements.
The info that location based exclusions and exclusions for emergency admin are not compliant are also in the FAQ: Partner security requirements FAQ - Partner Center | Microsoft Docs
Finally, if there is any chance, consider to split the CSP management tenant from the tenant you use for internal production, this makes it much easier to fulfill the requirements.
Get consultations form Technical Presales & Deployment services team via https://aka.ms/technicalservices