MapReduce is a core component of the Apache Hadoop software framework.

Powered by WPeMatico

Why you should not worry about cross-tenant cloud attacks

We’ve all heard the concerns: While public clouds do a good job protecting our cloud-based systems from outside attackers, what about attacks that may come from other public cloud users? These are known as cross-tenant attacks (sometimes called side-channel attacks), where other tenants on the same public cloud somehow access your data. Should you pay more attention to this fear?

No, you should not pay more attention to cross-tenant attack fears. Here’s why.

First, there are much easier attack vectors to exploit when it comes to public clouds, such as human error. The cloud breaches that I hear about are caused almost 100 percent by human error. Often, people misconfigured their cloud machine instances and thus exposed data that was not meant to be exposed. If enterprises focus on dealing with cloud security, they should be focused there.

Second, most enterprises encrypt data on public clouds, both in-flight and at rest. Even if one tenant could access server instances held in other tenants’ account, that miscreant wouldn’t be able to read the data. Encryption also protects against hacking that comes from outside the cloud.

Third, the public cloud providers have the security systems in place to ensure that a cross-tenant attack is unlikely. It’s true that the tenant-management systems manage resources for many tenants at the same time, which is why enterprises get nervous. But there are well-thought-out virtual demarcation lines between tenants, which is a fundamental aspect of a multitenant system. Each public cloud provider has its own way of accomplishing these separation goals, and while you have no way of understanding every aspect of the approaches they use, you need to trust them at the end of the day.

With all of that said, this is a legitimate concern, and enterprises should always have a healthy level of skepticism about any type of provider services. However, you have more pressing concerns right now. Don’t let this one take more time than needed and divert you from those more serious issues.

Powered by WPeMatico

Don’t fall for the ‘pluggable cloud’ siren call

People once made requests for hybrid cloud because of the perception of flexibility. Now they make multicloud requests, for the same reasons. Multicloud is just part of a cloud architecture that uses more than two clouds, private and/or public. However, most multicloud deployments involve more than two public clouds, typically AWS, Microsoft, and sometimes one other, such as Google.

Although the concept of having “pluggable clouds” is not at all new, I get more and more inquiries about multicloud patterns that promote the notion of pluggable clouds.

A pluggable cloud is a multicloud setup where you can swap out the public or private clouds without having to change much of the underlying application dependencies. The term is often used to describe any multicloud architecture where changing out clouds is something that enterprises do to deal with price and functionality changes.

Is this type of architecture even feasible? Consider the facts.

First, this can only work if you use a cloud service broker (CSB), a cloud management platform (CMP), or other tools that provide abstraction away from the native cloud services. Otherwise it becomes too complex to manage the native cloud services of each public cloud provider, because you have to deal with each native cloud service on its own terms.

Second, you need to understand the “pluggable” requirement. If the expectations are that you can unplug AWS and plug in Alibaba, for example, without significant alterations to how the applications and data storage systems use those services, you’re smoking something. In reality, there are vast differences between how AWS does storage, and how Microsoft or Google or Alibaba does storage. Even if you do a great job creating abstraction and orchestration layers, there is a great deal of work needed to make it actually work. I’m not sure “pluggable” would be the word I’d use.

Third, while it might be possible to make your multicloud setup pluggable, you would do so at the expense of services. You would be forced into a least-common-denominator approach, which means that you’ll only use the basic functions to make your workloads work across cloud providers. In other words, you’ll only use a fraction of what the clouds can offer in terms of services such as storage and compute.

Keep in mind that both CSBs and CMPs are proven tools that can manage multicloud complexity. Just be aware that the use of these tools does not mean you can add and remove public clouds without significant remapping of cloud services to your workloads.

Powered by WPeMatico