Over the last few months, I’ve been talking to many development and test teams who deliver their sites and applications through the Akamai Intelligent Platform. One common challenge they face is how to test their Akamai delivery configurations on the Internet against their private development and QA environments behind the firewall. Most operate on a DevOps model with the goal of performing end-to-end testing throughout the software development lifecycle in order to find bugs and interoperability issues (e.g. misconfigured headers) earlier in the development process. As noted by Ron Patton in “Testing Software”, the cost of finding a bug increases logarithmically as the development process progresses, so finding these issues early on in the process saves a lot of time and money. The historical challenge these teams have faced has been how to allow the Akamai delivery configuration access to these development and QA environments. Typically private and not exposed to the internet, the common approach has required a move into the DMZ.
Exposing these environments on the Internet creates both security and complexity concerns. From a security standpoint, how do you ensure only authenticated and authorized users get access to these servers? A common and less secure option is to whitelist IPs in the firewall as well as in the Akamai delivery configuration, but this greatly adds to the complexity – especially when you have remote developers and testers whose IPs can change. Adding to that, any applications that are exposed on the Internet generally need to be hardened, monitored, and maintained as if they were a production server which also adds to the complexity and level of effort to manage. Given these challenges, many organizations only expose one or two of these pre-production environments, but this greatly limits the ability of developers and testers to test end-to-end early in the development lifecycle.
A new approach that is both simple and secure has been needed, and we now have that: Enterprise Application Access (EAA). EAA provides a cloud DMZ service built on the zero trust model – authenticated and authorized application level (L7) access without ever exposing these internal environments to the Internet. The architecture consists of two components:
- Enterprise Application Access (EAA) Cloud – Enforces the following checks:
- Authentication (AD/LDAP, SAML, or built-in Cloud Directory)
- Authorization (per application)
- Optional Multi-Factor Authentication (MFA)
- Optional access control policies
- Enterprise Connector – Hardened and headless VM which:
- Calls from the inside out to the Akamai cloud on dual-authenticated TLS sessions
- Runs on practically any virtual platform (e.g. VMware, Hyper-V, Docker, AWS, Azure, etc.)
Once a user passes all security checks in the EAA Cloud, these 2 components act as transparent reverse proxies, enabling secure L7 connectivity between the user and the application. To complete the picture for this development/test use case, the Akamai delivery configuration simply goes forward to the EAA cloud service as the ‘origin’ in order to subsequently reach the internal and private origin server.
Just as important as the security architecture is the setup time and level of effort to manage. EAA can be deployed from start to finish within minutes and without additional hardware. No IP whitelisting or firewall holes are required. No changes to applications are needed since they remain internal and private. There is integration with existing user/group directories (e.g. Active Directory) for authentication and authorization as well as full RESTful API support.
I’ve heard a lot of excitement about this solution recently due to the simplicity in addressing the testing challenges mentioned above, but the benefits and use cases don’t stop there. This EAA service can also be used for the following use cases within these same development teams:
- Cloud-based test agent access:
- Automated testing tools (e.g. BrowserStack, Perfecto, etc.)
- Load testing through Akamai’s CloudTest
- Content developers accessing CMS
- Remote developer access to:
- Configuration & deployment tools (e.g. Jenkins)
- Project management & collaboration tools (e.g. Jira, Bitbucket, Confluence, SharePoint, etc.)
- Server/application infrastructure (web, RDP, SSH)
- Code repositories (e.g. GitHub, SVN)
- API calls from mobile apps
If you’d like to learn more, visit Akamai.com/EAA for more details.
This is a Security Bloggers Network syndicated blog post authored by Shaun Tamblin. Read the original post at: The Akamai Blog