Team access to proxies: allowed IPs, credentials, and revocation
Corporate access should be built around capabilities the service actually provides. The team maintains an inventory of allowed IPs and issued credential sets, assigns owners, accounts for office NAT and VPN, and uses the platform's supported revocation or rotation process when roles change, projects end, or staff leave.
Key points in one minute
- Every access entry must map to a real system, an owner, and a revocation method supported by the service.
- A NAT, VPN, or backup-link change requires the observed external source address to be verified again.
- The revocation method must match the platform's actual capabilities.
- Staff departure includes verifiable access removal or rotation.
Maintain an access inventory
For each allowed IP or credential set, record the system, owner, purpose, issue date, review date, and available revocation action. Do not promise a per-user profile when the platform issues one shared set for a lease.
Record whether the platform can revoke one entry, requires rotation of a shared set, and which integrations the action affects. This avoids inventing unsupported features and makes the actual revocation impact and safe change order visible in advance.
Account for NAT and VPN
With IP-based access, the proxy observes the external address after the office gateway, NAT, or VPN rather than a workstation's local address. Verify that address from the required environment before adding a rule and document replacement during backup-link failover.
Do not allow a broad subnet when one stable address is enough. During planned replacement, add and verify the new address before removing the old one. Give an emergency exception a separate owner, short lifetime, and removal reminder.
Handle access lifecycle events
When staff join, provide only the required access and record the recipient. Review access when roles change. When a project ends or a person leaves, remove the allowed IP or perform the supported rotation of a shared credential set, then verify that the old configuration is rejected.
If the service cannot revoke one recipient selectively, rotation of the shared set becomes part of the departure process. Inventory every dependency, rotate the set, update approved recipients, and verify that the old configuration is rejected.
Verify revocation and emergency access
Record every access addition, removal, or change with actor, time, reason, and verification result. An emergency exception needs a short lifetime, separate approval, and an automatic removal reminder.
Regularly reconcile the inventory with active integrations and team membership. Track ownerless entries, expired exceptions, unused credential sets, and attempts after revocation. Emergency access requires separate approval, a time limit, and post-event review.
Practical checklist
- 1Inventory allowed IPs and credential sets.
- 2Record the supported revocation method for every entry.
- 3Verify the external address after NAT and VPN.
- 4Remove entries without an owner or business need.
- 5Test emergency access and subsequent revocation.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.