How to Make Your Demo Environment Easy, Accessible…AND Secure
A common misconception I’ve heard in the field is that a tradeoff exists between easy access for applications and network security. For example, companies want to allow their sales team, partners, and prospects access into demo environments. With traditional access solutions, there is a question of who gets what level of access. Issues like intellectual property exposure, open attack surfaces, and multiple untracked users add to the complication. Beyond demo access, demo creation and support is challenging to keep under control – platforms move swiftly from one release to the next and environments are moved around on-prem or into the cloud. Naturally, my response to all of this is: Akamai has the solution! Enterprise Application Access (EAA) supports all the above scenarios, allows visibility, and (for our EU friends) is GDPR compliant.
As a Solutions Engineer in the Enterprise division, I work directly with customers to configure their solutions, so I have a hands-on perspective on how EAA (and our other products) work. To help give you an idea of how we do it, I’ll share a real scenario with you. In this example, Web/HTTPS-based and RDP-based applications access was required.
To begin, connectors were installed inside the designated demo environments hosting the Web/HTTPS-based and RDP-based applications, which translated to specific zones within a security concept. There was no need to open inbound connections at firewalls, thus reducing the attack surface significantly.
For scalability clarification, in this specific case we had close to 100 different demo zones protected via proxies in different environments.
Since our installed connector is optimized to work with all common services (VMware-based, Docker-based, Hyper-V-based, Azure-based, Google-based, AWS-based, etc.) inside the zones, we could provide all users one user experience throughout the various demo zones.
In terms of security requirements, the initial authentication was secured by a third party Cloud identity provider with the usage of client certificates. Multi-factor authentication was not a requirement in this particular case, but it is supported. However, the second authentication and authorization stage was done against an LDAP server located in each of the demo environments, and against the Windows RDP Server. Finally, the client certificate was used again for the LDAP authentication.
For convenience purposes, the RDP username/password procedure was used with a cookie setting requiring the username/password information once every 30 days. This resulted in users accessing their specific applications via the EAA portal. All they had to do was select a link – whether the application on-premise or in the cloud. And just to clarify again, all this was without having to enter any credentials, but users were authenticated via their client certificates and their Identity.
All communication is encrypted and logged for visibility, and yet is still so simple and easy for the user.
Learn more by reading this white paper:
https://content.akamai.com/m-en-pg9257-managing-the-rise-of-third-party-users.html
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Michael Strobl. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/MpPXeX8tlyY/how-to-make-your-demo-environment-easy-accessibleand-secure.html
