Impact to firewalls, access control lists and whitelisting via source IP

[mistermay123]

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.

[smhendrickson]

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]

Hi, @smhendrickson !

If I understood correctly your reply, this feature (IP protection) may be silent for "3d party context navgitation" if the 3d host is in the "eligibility list". So if I access directly the 3d party host, it will be not proxied, right?

If my site (a news publisher) is in that list, is there any chance to appeal for removal?

ps: When I read #19, I was thinking in a simple flag (on/off) for every site in the Chrome.

[maxant]

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.

I don't fully understand what a first party or third party is. If someone using Chrome were to access a website hosted on my web server, am I right in thinking that their original IP address will be visible to my web server, but if the web page that they are served goes on to load a resource from a different web server, the users original IP address will not be visible to that other web server?