In a cloud, public or private, you don’t think about the underlying hardware. You deal in virtual machines and networks. But of course, there is hardware there. And if you’re building a private cloud you have many options for how to build it. Each has different features, security capabilities, and costs, but in every case, you retain a great deal of security responsibility.
These options parallel the conventional modes of server deployment: You can deploy on your own servers on-premises; you can deploy in a co-location center; you can even use a conventional hosting service on a “hosted-but-dedicated” basis.
These guidelines apply to hybrid clouds as well as private. In fact, most organizations cannot justify a fully private cloud, but they can make a good case for a hybrid model. In a hybrid cloud, you integrate a cloud running on the systems you manage directly with a public cloud service. The major public clouds — Amazon Web Services, Microsoft Azure, and Google Cloud Platform — have extensive support for this kind of integration.
There are many reasons why you would need to run part or all of your systems in a private environment. Compliance, security, and performance are usually at the top of the list, and these concerns may also drive how and where you build your private cloud.Y
ou may be obligated to keep data in a certain country, for instance. Or you may need to install specialty hardware or use unconventional configurations. Perhaps the canned CPU/RAM configurations for VMs in a public cloud don’t suit your needs. Perhaps you have GPU-based big data analysis systems. You may also be concerned about network latency. You may be able to provide faster service in some locations, especially if local processing is needed, by using a private cloud.
On-premises, you need to provide a data center with power and power redundancy, HVAC, physical security, physical network infrastructure, and a lot of staff. This may be difficult to justify for most organizations. Much cheaper and often just as good, is to run your systems in a co-location center with your hardware in a locked cage. In such an arrangement, you own the compute, storage, and network hardware, and you have complete control over all data until it hits the point of transit.
The co-location provider is responsible for the facility, the physical security, fire safety, power and power redundancy, HVAC, and network connectivity, as well as the ability for you to run dedicated lines. These services offload a lot of expense and trouble, which probably aren’t core to your business mission. A co-location arrangement can allow for specialty hardware and unorthodox configurations, and it may well improve your Internet performance.
Nothing the co-location provider does can prevent you from making mistakes that expose your systems and data to attack, however, particularly if any are Internet-facing. The usual entreaties apply here: Ensure that data is encrypted at rest and in transit; maintain control over identity, authentication, and authorization; secure internet-facing workloads with a virtual next-generation firewall; and follow the principle of least privilege. (We’ll discuss these in future posts.
Hosted private clouds are the next cost-step down. These companies, which may be running in the co-location facilities described just above, promise dedicated hardware but often share other resources and sometimes limit your control options. You may not get an isolated network segment or the ability to manage the server fully. There’s definitely greater isolation than you’d have in a multitenant, public cloud environment, but you need to read the fine print carefully to ensure that the hosted service meets your needs and fulfills all the security responsibilities you require from a computing host.
Large, complex organizations often need to maintain control of some of their systems for a variety of reasons. Cloud architecture is still the future for these use cases, but with that control they retain the obligation to secure their data and software.