Cloud security may sound out of reach, but after all, the cloud is simply servers, routers, and switches in another organisation’s possession. There are many ways to protect your business and make sure you hold up your end of the responsibility model. You can keep your cloud secure while taking advantage of all that the cloud has to offer.
Before we discuss how to secure cloud architectures, let’s look at the cloud’s structure. Today’s cloud environment offers many options to choose from. There are three service models and four deployment models. These are defined by the National Institute of Standards and Technology (NIST) within their SP 800-145.
The service models are:
- Infrastructure as a Service – IaaS enables a company to build its own virtual Data Center (vDC).
- Platform as a Service – PaaS provides many options that allow the customer to provision, deploy, or create software.
- Software as a Service – In SaaS, the customer is provided with the use of software without the need for a computer or server to build it on. Some of the best examples are Microsoft 365 (formerly Office 365) and Gmail. The customer only needs a computer, tablet, or phone to access the online software.
Businesses use a variety of terms to highlight their products, as opposed to the more clinical descriptions from NIST – from DRaaS (disaster recovery) to HSMaaS (hardware security module) to DBaaS (database) and, finally, XaaS (anything). Depending on what a company is marketing, it can be difficult to determine whether a product is SaaS or PaaS, but in the end, understanding the cloud provider’s contractual responsibilities is more important. Cloud providers extend their contracts to add security on cloud formations through services such as HSMaaS (hardware security module) or DRMaaS (digital rights management).
The four deployment models are:
- Public – Available to anyone for purchase. The best examples today are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
- Private – This is built for one company, and the hardware is not shared with anyone else. The private model could be built on a public cloud or within your own data centre, or at a business that specialises in building private clouds, that is, a managed service provider.
- Community – This involves the concept of sharing between businesses. Service can be shared, or data can be shared on that service. One example might be government-built clouds shared by multiple agencies.
- Hybrid – This involves using at least two of the three deployment models listed above: public and private, private and community, or public and community. Another possibility is using all three.
Cloud architecture is the organisation of components and sub-components into a logical and hopefully efficient and effective structure. This structure should allow those components to work together towards a goal, maximising strengths and minimising weaknesses. The basic components required to create a cloud include networks, routers, switches, servers, and various others, such as firewalls and intrusion detection systems. The cloud also includes all the elements within the servers: the hypervisor and virtual machines, and of course, the software. Cloud architecture also requires a cloud provider, cloud architect, and cloud broker to create, manage, sell and buy cloud services.
Many terms relating to cloud architecture just add the word cloud to an old and familiar term, such as cloud consumer. If you understand the definition of consumer, then the new term is clear; it means a consumer of cloud services as opposed to, say, phone services.
Basic terminology found in NIST SP 500-299 include:
- Cloud consumer – The person or company that utilises the cloud service from a cloud provider.
- Cloud provider – The person or company with the resources to provide the services that consumers require. This involves the technology to create the servers, virtual machines, data storage, or whatever resources the customer needs.
- Cloud broker – The person or company that manages delivery, use, and performance of the cloud for the consumer, negotiating the relationship with the provider on the consumer’s behalf.
- Cloud carrier – The carrier is the service provider that connects a business to the cloud, for example, your internet service provider. For a business, this usually would be a multiprotocol label switching (MPLS) connection.
- Cloud auditor – The person or company that performs the audit of a cloud provider’s environment. These audits include privacy audits and security audits.
Cloud security architecture
Security in the cloud starts with cloud security architecture, which adds security elements to the basic architecture. Traditional security elements include firewalls (FW), anti-malware, and intrusion detection systems (IDS). Cloud auditors, security architects and security engineers are also needed to design secure structures within and through the cloud.
In other words, cloud security architecture is not limited to the hardware or software.
Cloud security architecture begins with risk management. Knowing what could possibly go wrong and how a business could be negatively impacted helps companies make responsible decisions. Three critical areas of discussion are business continuity, supply chain, and physical security.
What will happen to your business if your cloud provider has a failure? Putting servers, services, and data in the cloud does not eliminate the need for business continuity and disaster recovery planning.
What would happen if just anyone could walk into the cloud provider’s data centre? At the big three – AWS, GCP and Azure – this would not be easy, but that is the point. They have invested heavily in data centre security. What about other cloud providers? Request a walkthrough of potential any cloud provider’s data centre and to be involved in an audit. Note their answer. Were they willing to let you check out the data centre the next day? If it’s easy to get into the data centre, perhaps that provider deserves a second thought.
Smaller cloud providers may not have a physical data centre. More likely, they use and effectively resell the capability of the big cloud providers. That is an advantage and part of the beauty of using the cloud. If the relationship between the cloud providers is unknown, additional issues could emerge regarding laws, regulations and contracts. Ask this simple question: Where is my data? If there are multiple levels to the cloud provider, the answer could be hard to determine. There could also be legal consequences, such as an issue with the European General Data Protection Regulation (GDPR).
The elements that comprise a business’s cloud security architecture may have cloud security services as well. It is possible to purchase services like data leak prevention (DLPaaS). Other tools assist with security, such as a scanning tool that searches for personally identifiable information so it can be secured properly. Cloud security management is necessary to ensure that these services are working as they should.
Businesses need to be in compliance with many laws, regulations and contracts. When you put your data and services in someone else’s possession, the audits required to confirm compliance can get complicated.
Ask yourself: “What are my concerns?” This will help you determine what questions to ask your cloud provider. From a legal standpoint, organisations must comply with the European Union General Data Protection Regulation (EU GDPR), Sarbanes-Oxley – U.S. financial data protection (SOX), the Health Information Portability and Accountability Act – U.S. health care (HIPAA), and others. Also, credit card protection falls under contract law with Payment Card Industry - Data Security Standard (PCI-DSS).
Once the compliance subject is identified, many actions can be taken, one of which is an audit. The audit should be conducted using a standardised approach and proven methodology, such as the American Institute of Certified Public Accountants’ SSAE 18 (Statement of Standards on Attestation Agreements, No. 18). The audit’s findings will indicate what may not be in compliance. When deciding on a cloud provider, it is important to read these reports to know the DC’s level of security and what to expect.
Infrastructure as Code (IaC)
The short explanation of IaC is that infrastructure is treated like code, with the same logic of DevOps rather than configuring each and every individual router, server, switch, and software. If we applied the strengths of DevOps to the creation and management of our infrastructure, it would result in many benefits. In the cloud, your infrastructure becomes virtual, which means that it is just code, not hardware. A router really is just code that lives on a particular, or specially built, computer; when the hardware is removed, what’s left is the code.
Now let’s apply logic to the development and deployment of that code. Automation tools now allow for easier and more controlled methods of deploying and managing software. If we manage our virtual infrastructure with those tools, we might have a much easier and more controlled manner of deploying and managing clouds.