All systems in the same network can communicate with each other freely, from the lowest layers of sending frames and packets, to RPC calls, etc. This implies that we have the same trust in all systems, for example, they are all managed by the same IT team. Sometimes you have systems in the same network that mostly don't trust each other, for example, system interfaces that are Internet facing. So you create rules using firewalls, proxies, VPNs, API calls authenticated with API keys, etc, to enable trusted communication among the systems and applications that your either manage, or you decide to use. IP whitelisting, which should be better called IP allow listing, is very widely used. This is bad news, for several reasons:
- It is an inflexible system. When something changes you have to synchronize the changes on both sides of any pair. This makes moving any system to a business continuity mode very unreliable, complicated and slow.
- It is obscure. Only administrators with access to privileged operations understand what has been configured, why an how.
- It is often poorly documented or undocumented. When there is any kind of incident, it makes troubleshooting complicated.
Probably the two main unnecessary reasons companies face expensive incidents that take several days to fix are expired digital certificates and brittle architectures resulting from using IP whitelising. There are many solutions depending on what you are trying to achieve with IP whitelisting:
- An ethernet cable for systems that have free interfaces and are close to each other.
- A point to point VPN for systems that you manage but need to cross untrusted networks to communicate.
- API keys for authentication of services outside your network.
- Among others…
The silver lining is: If you change jobs every couple of year, it will be someone else who will have to fix the mess. Yupee!
Top comments (0)