Fully 30% of enterprises tell me they spend as much on acquiring capital equipment and software to support security technology as they do on network technology. With an investment this prodigious, you’d think enterprises were focusing on how the cloud might change security risks and options , but most security spending focuses on protecting current data center applications. Why is that, and what should enterprises actually be planning for security in the age of the cloud?
Our biggest problem in assessing the impact of cloud computing, and what we need to change when we adopt it, is the tendency to think of the cloud as nothing more than a transplanted data center. Since enterprises already secure data center applications, securing the cloud should be just a matter of transplanting data center security. That’s not the case, but the reasons why it isn’t are complicated.
In nearly all enterprise cloud applications, the cloud is used in partnership with the Internet to enhance the user interface for customer care, sales, and order entry, and to support partners and employees. In these applications, Internet access connects all these users to the cloud, and the cloud provider’s own network connects the components of the applications. Eventually, the work flows back to the data center in the form of transactions to core business applications.
This workflow is very different from that of traditional data center applications, where users access the applications via a virtual private network (VPN), but the APIs used for that traditional access are often reused by the cloud components. Security provided for these APIs and within the data center may still be in the workflow, but the entire front-end piece of the applications has now migrated outward beyond the data center and likely beyond data center security. Any security tools used within branch offices are likely bypassed when the user accesses applications outside the data center, through the web and cloud. In all, it’s possible that a hybrid-cloud version of an application could bypass all that expensive security enterprises have been adding.
The good news is that a cloud security model might actually be simpler and cheaper. There are only four steps needed, and with care they can secure your cloud operation.
The first step is to enforce login with two-factor authentication (2FA) for all cloud applications that serve your employees or partners, meaning those users with special access privileges. These days, virtually all websites require HTTPS encryption security, but that isn’t enough if critical application access is offered into the cloud via the Internet. Some enterprises even encourage their customers to enable 2FA for their own accounts.
The next step is to use Secure Access Service Edge (SASE) technology to secure the on-ramp to the cloud piece of the application. SASE combines traditional security tools like an access broker for applications, firewall, anti-malware tools, etc., with a software-defined WAN (SD-WAN) VPN. The VPN isolates cloud components from other traffic and also creates a secure link back to the data center via the Internet. If the company already uses an MPLS VPN, SD-WAN can extend it via the Internet to any location on the globe and to any application in the cloud.
Step three is optional; encrypt the in-the-cloud connections used by application components. This is optional for two reasons. First, most cloud providers offer strong user-to-user isolation and protection, and these capabilities may make it unnecessary to protect in-cloud traffic from access by others. Second, SASE/SD-WAN software may include encryption, in which case no additional security would be required. However, note that if cloud-hosted SASE/SD-WAN uses encryption, the overhead may impact not only performance but also cost since it may impact the load on the CPU of the cloud instances. Check to see how encryption will impact both cost and performance before you commit.
The final step is to protect the data center connection to the cloud. The level of additional protection you’ll need here depends on whether all application traffic from the cloud is coming through the enterprise VPN or if some is coming via the Internet. In the former case, current security precautions within the data center (network and software) are likely sufficient, but in the latter case the Internet connection creates a new potential point of attack.
Some software changes may be very helpful to reduce the attack surface. Enterprises use the cloud to support a variety of use cases, ranging from a prospect browsing for something to an employee with a need to access a lot of company data. In some cases, it’s possible to support multiple user classes from the same data center API just by changing the parameters of a transaction . However, this can make it easier to hack the application.
Instead, create multiple APIs, one for each class of user, and use an application access broker to act as a secure intermediary between those user-class APIs and the real data center APIs, to protect those APIs from exposure. This can provide software access security to any class of users with elevated access privileges. It’s also possible, if the SD-WAN used to implement the earlier recommendations in this blog supports identifying specific user/application flows to limit access to APIs with elevated security based on IP address.
The key point to remember here is that security is a holistic process, not a set of separate, disconnected products and processes . That’s particularly true for security in the age of the cloud because the cloud’s beneficial properties change the whole nature of application and data security. Enterprises will have to change too—when they create or expand their cloud commitments or risking turning their existing massive security efforts into a wasted exercise.
