VPN Servers are a great solution to add a layer of security on accessing private networks. They are often used to expose internal services to collaborators, allowing them to perform administrative tasks like querying a database, connecting to a server via SSH, accessing an internal web application.
Most of enterprise VPN solutions require users to install a client application and sign in on it. Starting the VPN make those private networks available in the user local network.
VPN's only enforce security in the network level, internal systems still need to have their own mechanism of authorization. But sometimes, they are used as a source of security and services are exposed without care.
Having only the VPN is not enough, internal services need to be secure and audited even from internal collaborators. Allowing internal services to be accessed without restrictions inside a VPN, generates a breach that could be exploited by targeting a VPN system and its users.
Administrators have to distribute and make sure clients work properly for each operating system. A VPN introduces another system to manage users in case it isn't integrated with an identity platform solution.
Configuring private networks from multiple environments is not a trivial task. Sometimes, a client needs to connect to distinct tenants or instances (depending of the VPN vendor) to map a private network locally.
Managed services from distinct vendors has their own network setup for their services. They require special configuration to reach them. e.g.: configuring a firewall rule to allow the IP of the VPN to reach in those services.
How about User Experience?
Users have to install a VPN client with credentials to connect to a VPN instance. Starting it, simply give users access to internal services. However, these services are not discoverable, administrators need to maintain some sort of list of services and how to reach them.
Local network problems tend to happen with clients, like an misconfiguration in the VPN itself or in the local router of a user.
Usually on medium to large organizations, VPN's are managed by a team of security specialists. They need to work together with infra-structure teams to understand how to map internal services to the VPN. This cross team dependency decreases the user experience due to slow down on fixing issues or mapping new services.
How hoop can help
Hoop only connects and expose what's necessary. Administrators are responsible to make connections available and apply policies to it, like: auditing, redacting, reviewing, etc. Security teams have more visibility of what's exactly being accessed , thus making internal processes more fluidly.
Service discovery is not necessary anymore, users know in advance which services are available for them to interact with it.
Accessing services through VPN
- Auditing must be configured to individual service (mysql audit, api audit)
- Have a broader scope to access other services in some cases
- Lack of service discovery. Require to know in advance the DNS or the IP of the services
- Policies cannot be enforced for individual services
- Users need credentials to access internal services
$ mysql -h mysql.vpn.prod.internal -D prod-db -umyuser -pmypasswd $ curl -XDELETE http://another-service:8000/api/resource/id01
Accessing services through hoop
- Each access is properly audited
- Decrease the scope of services
- Service Discovery
- Access can be revoked directly on the identity provider
- Policies also known as plugins can be applied to each individual service
- Credentials of internal services could be abstracted in connections
$ hoop connect prod-db-service --port 3306 $ mysql -h 127.0.0.1 -D prod-db $ hoop connect my-internal-service --port 8000 $ curl -XDELETE http://127.0.0.1:8000/api/resource/id01