smhendrickson
commented
11 months ago Thank you for the feedback.
Our proposal focuses on proxying eligible third-party traffic. If the protected resource is loaded from a first party context, or the resource is in a third party context but not on our list of third-parties eligible for proxying, the client IP will not be that of a proxy, but the client's original IP.
We expect that most cases requiring this type of IP allowlisting will not be in our eligibility list, and will not be proxied.
For third-party resources that are eligible and need an IP allowlist (developer resources for example), one could disable IP protection for the browser they are developing from, or keep it enabled and allowlist our full set of IPs.
As you've indicated, it is not secure to use the proxy IPs in an allowlist as part of a 2FA or MFA strategy, because they are shared among many users. In the rare case a 2FA/MFA strategy is required for these resources, we recommend exploring other forms of authentication.
gui-poa
maxant
Many services in Azure have a built in access control list/service firewall feature that allows access to an instance of the service to be restricted based on the IP address of the client. Many management tasks are performed through the Azure Portal via the local browser and the local internet IP must be added to the allow list on the service in order to access it.
Entra ID has conditional access rules which can be configured to perform different authentication behaviours based on signals. One of those signals is the authenticating user's IP address and allows "safe locations" to be specified.
There are also many other cloud-based SaaS services which whitelist access based on source IP.
How will the implementation of IP Protection impact these security measures. If up to a million users will appear to come from a small number of shared IP addresses per geo, that doesn't provide the necessary granularity to enforce the best security.