Your web application by default is accessible to the entire planet. This exposure can open your site up to unnecessary risk. Akamai's Request Control Cloudlet can quickly allow or deny access to website content based on the IP or Geography associated with an inbound request. For example, you may deny access to users in embargoed countries or allow it only to a specific region where your users live. Manage the cloudlet via easy-to-manage whitelist and blacklists based on the IP address or geographic location associated with the inbound request. Activate the cloudlet policies in seconds by using the dedicated user interface.
However, user location is only one of the capabilities that the Request Control Cloudlet allows. The recent update of this Cloudlet (formerly known as IP / Geo Access Cloudlet) expands its capabilities by adding the following match rules by:
- Header Value - Deny bad objects such as spam sites or quickly update your blacklist via an authentication header match.
- Request Type - Allow or deny requests of a certain type. For example: if your API should not accept POST requests, then block it at the Edge.
- URL Path, Cookie, and Query String - Specify a particular path to block.
The feature set above allows you to implement a wide variety of use cases:
- Allow only known IP addresses to access a pre-production web property for maintenance, QA testing or business purposes.
- Quickly deny IP addresses that post unwanted comments or exhibit other undesirable behaviors.
- During critical business events, denying traffic from low-priority geographies to free up capacity for your intended audience.
- Deny requests from a geographic region that has a high probability of illegitimate traffic and a low priority to your business.
The examples below take the cases above and discuss them in more detail:
Let's start with a simple case: you want to block users from a particular country from accessing your site properties. You may wish to restrict access to your website from one or more countries, based on any number of factors. Political factors (such as your country's trade policies) could play a part in this decision, or perhaps you seek to limit traffic from countries where you simply don't conduct business. With the Request Control Cloudlet, you can quickly add a simple geography-based blacklist, which can block users from a country (as identified by the Akamai EdgeScape database).
Pre-Production Environment Access Control:
Pre-production sites (used for development, quality assurance, etc.) often contain confidential information, secret product information not ready for exposure, or even debugging code. Having this potentially sensitive information unsecured and vulnerable to casual snooping by the general public should not be overlooked. However, securing these environments from prying eyes can be a challenge:
- Many corporations use more than one development vendor, have remotely distributed workforces, and have valid users with varying levels of technical proficiency who legitimately need to view these sites.
- Simple origin server password authentication set at the origin can present challenges with cached objects (requiring advanced authentication methods at the Akamai layer, beyond the scope of this article).
- Origin server logins often dilute the experience of the production site which wouldn't normally require one.
- Changes to IP whitelists (such as in hardware-based firewalls) might require engaging several highly technical teams, and could take hours or days to alter.
The Request Control Cloudlet can help simplify all of these challenges, by leveraging built in, flexible functionality
- Allowing access to your environments via IP address - white list your company's IP ranges, the IP ranges of your development vendors, or even home/remote offices.
- Allowing access via HTTP header (such as a cookie) - if IP management isn't for you, provide your personnel with a secret request cookie, which the Request Control Cloudlet can inspect for.
- Allowing by a combination (either/or) of the above methods - you can look for both the IP OR the cookie as allowed means to access the site.
The Request Control Cloudlet can easily facilitate these access control settings for the pre-production environments. It can accommodate rapid changes to the lists as well, such as if you need to add an overlooked IP to the access whitelist.
It also separates the administration of these settings from the Akamai delivery configurations (Property Manager) that control your sites' main Akamai functionality. This reduces functional risk to the site by separating the access control from the functional control, and expedites changes to the access settings.
Another use for the Request Control cloudlet is for protecting time-sensitive elements of your site, and then "revealing" them to your user-base at an exact moment. Time sensitive deployments and exact-moment unveilings on your site can be high-stress affairs, depending on architecture and complexity of build processes. Oftentimes, content and functionality must be launched with very little room for error, and even less validation time.
Why not simplify your launch experience by blocking the new elements of your site in advance using the Request Control Cloudlet, and then deploying your content into production, knowing that only the users you explicitly authorize will be able to see the content in advance. This would make for a less hectic operational experience, allowing additional time for deployment and quality assurance in the production environment, as well as piece-of-mind knowing that when the time-limit expires, everything will work as you had planned.
Similar to the previous use case (Pre-Production Access Control), you would identify the directories on your site, which are new and time-sensitive, and add them to a Request Control policy. For example: www.example.com/newproduct/* and www.example.com/images/newproduct/*. You would program similar access control parameters (whitelist IP addresses, whitelist cookies, etc.), blocking them from prying eyes. Critically for this case, you would also add a Start Date/Time and End Date/Time for the access control. Essentially, you are "locking down" access prior to the End Time, but as soon as the End Time arrives, the Request Control Cloudlet will expire access control from that policy, resulting in the pages, directories, and site assets becoming available to the world -- automatically, and at the exact second!
The Request Control Cloudlet is certainly not limited to these use cases, but should give you an idea of the simplicity, flexibility and power of the Cloudlet to meet your site access control needs.
This is a post from Viktoriya Reyzelman and Daniel Murphy, Engagement Manager of the Services team.