In a previous article, we saw the strategic approaches for migrating assets and/or services to the Public Cloud.
But first of all, should you embrace the Public Cloud or stay/revert to Private Cloud ? There are many decision criteria for this choice, from delivery time to financial optimization. One of the most important topics however is security.
N.B. This article is not intended to explain (in depth) what security is nor to provide a comprehensive single view (it does not exist!)
Types of Cloud
You may have already read the previous blog posts – there is different types of “Cloud”: Private (which you can find in company’s Datacenters), Public (offered by vendors like Amazon, Microsoft, Oracle, Google, Alibaba…) and Hybrid (a combination of Private to extend is some parts to Public).
Those 3 types have slight variations:
- Private Cloud – this means “operated by the company”, but not necessarily on a private data center. A Private Cloud can be built on the infrastructure of a public vendor/provider.
- Private Cloud could also be privately owned, but operated by an subcontractor/offshore company.
- Hybrid Cloud could be between private-only data centers operated by different companies, it’s still hybrid in its approach.
- Hybrid Cloud could consist of having a single operating model over multiple public infrastructure.
- Public Cloud could be a Cloud provider with a local presence and not with a myriad of locations.
Security, what does it mean?
When I say “security”, most people from IT Infrastructure and Network think of firewall – but this is only a (very!) small part of what security means. Security includes also (non-exhaustive list):
- what data is sent
- anonymize private technical data
- network connectivity
- accessibility of users and systems
- protocols used
- people and processes involved
- external companies with access to data
- operations by external company and compliance
- auditing and reporting capabilities
- communication systems to end customer
- training and prevention
While we mostly see the tooling part of security (pentest tools, vulnerability reports, etc.), “Security” is not only technical, it’s all about the data and the way in which it’s processed. The goals of security teams are to assess and reduce risks.
Clouds and localization
These Clouds (Private, Public, Hybrid) are located somewhere in the world. The tools, management plane, user interfaces are also located somewhere – not necessarily in the same location.
Location is very important – as you may know there are certain constraints, regulations or laws (GDPR for Europe is the most known and recent). Having all or part of the Cloud in certain locations will be a (valid) security concern. And this applies to all types of Clouds, not just conventional Public Clouds.
For example, you could have chosen a compute that is located in your geographic area and country (for example, Frankfurt, Germany), but if the administration UI is located in the United States and the authentication is replicated in Singapore , this is a security problem and will require a risk assessment, even though the infrastructure itself is on the correct location.
Security Challenges during Cloud Architecture
As a Cloud Architect, my main stakeholders are the Infrastructure, Cloud and Services teams, but rarely the Security teams – so the list of security requirements can be skewed. In this conditions, a typical workshop comes with its share of demands like “everything must be hardened”.
Security teams just need to understand what’s going on – they’re security experts, so they don’t have in-depth knowledge of solutions like Infrastructure or Cloud experts.
Remember it’s all about the data, you need to give security teams the information they need. This information could be something like “which authentication settings are required?” or “please give a list of sub-processors that operate this Cloud”.
If you are not familiar with security, there is a good chance that you can not answer such questions.. Some research and good contact will give you results. Cloud providers (any type, any service) typically produce documents for most questions, i.e. for vRealize Operations Cloud sub-processors: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/downloads/eula/vmw-vrealize-operations-cloud-sub-processors.pdf
What is valid then?
Security isn’t about patching everything, it’s about understanding, measuring and mitigating risks. They are the first to know that zero risk does not exist, it is not something they will ask for.
A Private Cloud managed by the company is, in essence, preferred because the company controls it and could act on the roots of risk to mitigate them. But an offshore managed Private Cloud could be seen as riskier than a public Cloud with proper operations and reporting.
An example is that Cloud engineers are usually asked to turn off SSH and completely disconnect from the Internet “because of hardening”. But SSH is an encrypted protocol, with a configuration that could be very secure even for PCI-DSS environments; Access to the Internet through a proxy will allow a faster reaction to security breaches. Leaving SSH enabled and the Internet accessible through protections will actually provide better security results than without.
There are 3 main types of data: Infrastructure, Application and Personal.
- Infrastructure data is what is used by IT staff but not by applications: metrics, logs, server inventory … This type of data is (generally) not a big threat and is eligible to be sent outside. Some data will need to be anonymized (such as server names in logs).
- Application data: this category is the most difficult to process. Depending on the criticality of the application, environment or intellectual property of the application and its data, this can be a red flag or a green light.
- Personal Data: It’s an “easy play” with recent compliance and regulations. With the GDPR for Europe for example, it becomes very difficult to move forward. A combination of the user’s first and last name is considered personal data, the Cloud service provider will need to fully explain why and by whom this is collected, stored and processed.
Data, classification and eligibility are different for each company. I can’t give a magic answer here, but you may imagine that a pre-production platforms or applications are mostly eligible. Home-made applications that are critical to the business, production data along with personal data has a small chance of going into something that is not under the full control of the company.
Communications are the subject of discussion generally due to misunderstandings of words. Security requirements often relate to “flows”, while the common understanding is made on “networks”, “subnets” or “underlay”.
For example, when we say that management flows must be encrypted, it does not just mean network or VPN encryption. Take the example of the SSH service: the password authentication is automatically encrypted asymmetrically – therefore considered secure, which means there is no need to (re)encrypt the underlay or create specific connectivity .
Of course, there are levels of security that require specific connectivity. But that’s usually not a problem with all those firewalls already out there somewhere, right?
Another Cloud security concern is access and reporting. It is often underestimated because it is not considered “Cloud” but linked to end users, although it is extremely important for security.
Accessibility and its security are one of the components of the “zero trust” approach. Access to Cloud services and infrastructures should go through directory (user base), authentication (authN) and authorizations (authZ) processes and technologies validated by the company. This could involves federation of directories, SAML or OIDC but also more secure controls such as geolocation, adaptive access and multi-factor authentication.
Besides accessibility, the report on who accessed what and when is another hot topic. This could be partially covered by logs, but there are other things to keep in mind: mapping the user and permissions to each tool, over time – one of the most difficult security requirements, if applicable.
Obviously, there are different levels of security requirements. A platform that will host assets for defense, federal or military systems will require more security than a traditional platform.
Importance of Reversibility
Reversibility is one aspect of a true Hybrid Cloud: it is the ability to move assets or services back and forth between Clouds.
This reversibility will allow the best of security recommendations to be applied, over time and change, while staying in business and optimizing costs.
OpenSource and Proprietary
Let’s talk a little about opensource and/or proprietary. While there are pros and cons for each on infrastructure and development perspective, security has concerns about this as well.
Proprietay’s infrastructure, software and Cloud services are the simplest: a single vendor must respond and is responsible for securing its services / software. The vendor may include open source software and may take partial responsibility for this.
Opensource as in “services © uses open source software” – like a Cloud infrastructure provider with its portal, authN / authZ, automation and management systems are home made. In this case of “open source”, regardless of how it is marketed, the vendor(s) are considered as if it was Proprietary.
Opensource “purely”, without any proprietary part (or from a proprietary solution), source code publicly available and susceptible to modification by anyone – this is a difficult theme for security because the code is never “final” and can be modified for malicious purposes. These must be validated each time, regularly, with in-depth checks and reports. This requires a huge and sustained effort from the security teams.
Refactoring and Legacy apps
A key aspect of a successful transition to the Cloud is the refactoring of these old legacy applications. Impact of refactoring to security is remarkable- in every sense of the word.
Refactoring could use more open source components, each with security concerns. It would also use more SaaS services, each of those services with its own pack of sub-processors, localization and access challenges. For example, a service mesh is technically interesting but it relies on several opensource components, with configuration (control plane) not hosted within application space and observability sending data to another location.
Besides the technical aspects, refactoring an existing application will be an investment in people – there will be (a lot) more developers, possibly from an external service company or an offshore development center, and those people will need access to infrastructure, data and to the company’s intellectual property.
Don’t get me wrong, I’m a big supporter of refactoring, but for security it’s easier to move that old closed source and unmaintained legacy application rather than replatform and refactor.
There is no single answer to all of these complex and different requirements. In architecture phases, challenge real needs to make sure you’ve captured and understood the ins and outs. Engage the security teams during the Cloud design, this will ensure a good understanding on both sides and a smoother journey.
Considering the different types of clouds, there are easy targets: stateless services / infrastructure could be anywhere, unlike databases where personal data such as credit card numbers or the mailing address of the company’s end customers should be protected and in infrastructure managed internally.
The biggest risk is not migrating to Private, Hybrid or Public – it’s data control and flaws, especially with shadow IT (often because IT is considered too slow). So yes, establishing a Multi-Cloud strategy within an enterprise can take time, but patience, waiting and embark is going to save you time.
None of the previous descriptions advocate Private, Hybrid or Public, but for “how data is managed at the end“. All types of Clouds can be valid targets for applications and data, as long as security teams are part of the journey and are able to assess, measure and recommend from the start.