In the first post of this series, we introduced the concept of cloud security. We considered the fact that security concerns change as soon as data leaves the protected corporate network. Concepts such as location of the data, who really owns the data, and accessibility were discussed.
As you continue reading, please keep your environment in mind and think about how you feel regarding security. It could be a show stopper, an acceptable risk, or a nonissue for you. Regardless, it’s a fine conversation-starter to ensure your journey to the cloud is orderly and secure.
The dreaded DoS can occur in a cloud environment. However, denial of service is not always malicious.
Recall that the cloud is just a multitenant datacenter environment. Multitenant environments can suffer from the noisy neighbor effect: while you're operating just fine, other tenants may be out of control and disrupt your performance and availability.
Think about your virtualization environment. Do you over-commit? This could include storage, network, CPU, or memory. Virtual environments tend not to use all of the available resources at once. The cloud is no different. Cloud providers still rely upon some level of over-commit to ensure availability and performance and allow for expansion when necessary.
Additionally, a zero-day vulnerability may hit a number of hosts inside the cloud environment. BPDU packets may be unprotected and crash the hypervisor, for example. Any number of situations can arise by accident (or on-purpose) that degrade or remove service availability.
Trusting an external entity is difficult. We trust the guy we just hired off the street because we need to. We trust consultants to properly design solutions that we don't understand. But why is it we cannot trust service providers?
There must be some level of trust in service providers and some way to ensure the trust is realistic. Once my data leaves my network, I need to be able to trust that:
People are flocking to the larger cloud providers because they are established. The theory is, if a provider had a high rate of failure, they would not still be around.
What should we expect a less established service provider to do to earn our trust? Some suggestions:
I guess that trust, in this case, takes a little leap of faith.
Getting your data to the cloud is the easy part. Open an agreement with a provider and upload data over an encrypted connection or send an external hard disk somewhere to be sucked into the environment.
The bigger issue becomes how to get your data out. It may be the case that the cloud is not what you thought it was going to be. So, you need to pull your data back to your private environment or to another cloud provider. Did you just enter the Hotel California?
The key is reading the contract. Look for sections pertaining to termination of the contract, procedures and processes around termination, and what happens to your data when that cloud provider goes away.
The immediate reaction may be that your production environment is more sensitive. Therefore, production is the last to make the move to the cloud. Development environments are usually the first to make the jump, because they do not have the critical sensitivity production does.
However, consider for a moment that your data and intellectual property is what makes up your business. In many instances intellectual property is designed and refined in a development environment. Production ends up being a subset of the IP that your company provides. Pushing development to the cloud first can actually put your IP at risk.
Cloud provider failures may result in the cloud provider losing data, making your data available to other individuals, or even closing up shop. Your IP is what makes you stand out from the crowd. Losing it for any reason could be the downfall of your company. Be sure to have a good backup.
The IT industry is moving toward XaaS solutions hosted in the cloud. It’s tempting to enter into an agreement and start throwing content into a cloud. But taking a moment to perform some due diligence and ensure this is not a shotgun decision is a must. Ask the questions, evaluate the risk, and make the jump if it fits your business.
Ensure connections are properly encrypted to protect you from outside influence; you may have the keys to the house, but determine who has a key to the backdoor. Look for SLAs and protection against availability (or lack thereof). Where encryption is concerned, ensure you know who has the keys and whether they can reset your access in the event you lose your encryption key (hint: if they can reset encryption, run the other way as fast as possible).
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.