The hybrid cloud has 100s if not 1000s of APIs in use at any time. API security therefore becomes a crucial part of any hybrid cloud environment. There are only so many ways to secure an API: we can limit its access, check the commands, encrypt the data transfer, employ API-level role-based access controls, ensure we use strong authentication, etc. However, it mostly boils down to depending on the API itself to be secure, because while we can do many things on the front end, there is a chance that once the commands and actions reach the other end (cloud or datacenter), the security could be suspect. So how do we implement API security within the hybrid cloud today?
We use APIs to gain access to our data and control planes within the hybrid cloud. Those APIs could be talking to any aspect of the hybrid cloud, not just the cloud-specific tools but within the data center, into and out of analytics. There are APIs for all aspects of the hybrid cloud (as shown in Figure 1).
- Transition – The transitional component of a secure hybrid cloud contains all those items that either allow access to or move data between multiple cloud instances, between those clouds and a data center or centers, and between the end user computing device and clouds and data centers. The transitional component is fairly fluid.
- Cloud – The cloud includes all those places outside our immediate control where data could end up or be taken from. In some cases, it is even used to further our transitional goals. This is where APIs tend to live.
- Data Center – The data center is generally within our control and could be a private cloud or just a collection of virtual and physical machines. The data center may transfer data between multiple data centers or back and forth to the cloud.
API Security in the Hybrid Cloud
There is a clear need to protect our API usage so that bad actors cannot inadvertently access the control planes where our data is stored and affect its availability, integrity, or confidentiality. We currently do this within the virtual environment (the left side of figure 1) by limiting access to the APIs to a select few systems. We do this by employing several tools:
API Security, Know what APIs are in Use
The first step to API security is to understand what APIs are in use, which really implies knowing which applications and cloud services are in use within your network.
- Sky High Networks provides a tool to monitor your network for access to cloud services, report on them, and inform you which have a higher risk than others.
- Logging Proxy Server is one roll-your-own way to provide a list of which services are being accessed from within your network or between networks.
- RSA NetWitness and other packet filtering tools can also be used with a big data security analytics engine to determine what applications are in use on the network and what applications in the cloud are being accessed from inside the data center.
API Security, Limiting Access
First we can limit access to APIs by limiting access to systems that are allowed to talk to those APIs. We do this by never installing an API endpoint to any system but those allowed and by limiting what systems can access the API endpoint. These tools are designed to limit human interaction, not system or program interaction.
- HyTrust is a control point that inspects the APIs in use and applies role-based access controls at the API command level. While HyTrust is intended for a VMware vSphere environment, it covers other aspects required for hardware access, such as remote access devices (DRAC, ILO, and IPMI), network switch access, and many other components that live within a VCE Vblock (which is not just VMware vSphere). Hytrust is an API proxy/router that lives just before the elements it is protecting.
- Xceedium can be used to govern access to those jump machines and the applications that it is using. Via Xceedium we can not only limit access to the jump machine, but present a way to access an application directly on the jump machine, such as a client that makes use of APIs.
- VMware Horizon App Manager and the other similar tools can also be used to limit access to given APIs by not only providing a link to those APIs but by maintaining a set of strong authentication (random long keys) independent of the humans involved.
API Security, Limiting Use
However, humans are not the only ones involved; there are also systems and programs, which are written by humans, but which run independently of them. So we need to also limit which APIs are in use and which systems can make calls to those APIs.
- Strong Authentication is a must and those tools that maintain it for humans can usually maintain the authentication for applications and systems.
- Unique Usernames are required for each system and application that independently accesses an API. This way you know what accessed the control plane on the other side. Using a username used by a human can be misleading.
- HotLink Express is a tool that allows you to use one API (the VMware vSphere API) to manage and control all your hypervisors (vSphere, Hyper-V, Xen, KVM) and clouds (Amazon Web Services).
API Security, Limit Location
Another key aspect of API security is to limit the location from which the APIs can be used; in other words, to enforce the use of APIs from specific systems and programs instead of everywhere. This may be difficult for mobile devices, unless you can control how those APIs are accessed.
- Jump Machines are used by administrators to access any API used to manage the virtual environment, from hardware to software, including all hypervisors. In effect, we are limiting which systems can access the APIs. This may also entail a proxy that blocks API traffic from unknown sources.
- Virtual Desktops where what is on those desktops is controlled can also be used to limit from where APIs can be accessed and to tie the virtual desktop to a introspective layer 3 and higher firewall. It is also possible to limit access to APIs to just those systems which have been granted that access. Is is the combination of these tools that work well, not virtual desktops themselves.
Closing Thoughts
At the moment, API security is more about limiting usage, access, and enforcement points while we depend upon the transfer of those APIs to be properly encrypted and otherwise protected, which will imply good SSL hygiene as well as proper choice of APIs. While we did not discuss API choice, it is an important consideration. However, you may be forced to use a bad API and secure it, as that is the choice of the individuals within the organization. Security is playing catch-up where APIs are concerned. The organization’s users have been using APIs whether you know it or not; we need to defend how those APIs are used while NOT limiting the user experience. Security should be invisible.
How do you secure your APIs?
Comments are closed.