Cloud security may sound out of reach. The cloud is simply servers, routers, and switches in another organisation’s possession. There are many ways to protect your business to make sure you are holding up your end of the responsibility model. Keeping your cloud secure while taking advantage of all that the cloud has to offer.
Before we can 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 NIST within their SP 800-145.
The service models are:
- Infrastructure as a Service – IaaS allows a company to build its own virtual Data Centre (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) as well as DBaaS (Database) and, finally, XaaS (Anything aaS). 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 Service (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
- Private – This is built for one company. Fundamentally, the hardware itself is not shared with anyone else. The private model could be built on a public cloud or within your own data centre (DC), 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 strength 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. In addition to these components, the cloud also includes all the elements within the servers, such as the hypervisor and virtual machines, and of course, the software. Cloud architecture also requires a cloud provider, cloud architect, and cloud broker in order 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 the 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. They also negotiate 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, e.g., your internet service provider. For a business, this usually would be an MPLS connection.
- Cloud auditor – The person or company that performs the audit of a cloud providers environment. These audits include privacy audits and security audits.
Learn more about Cloud Architecture.
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). Those who design secure structure within and through the cloud are also needed, including a cloud auditor, security architect and security engineer.
In other words, cloud security architecture is not limited to only 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 our servers, services, and data in the cloud does not preempt the need for business continuity and disaster recovery planning.
What would happen if just anyone could walk into the cloud provider’s data centre (DC)? At the big three— AWS, GCP and Azure—this would not be easy, but that is the point. They have invested heavily in the security of the data centre itself. But what about the other cloud providers? With any cloud provider, request a walkthrough of the data centre and to be involved in an audit. Note their answer. Were they willing to let you check out the DC the next day? If it is easy to get into the DC, perhaps deciding to go with that one deserves a second thought.
More likely the smaller cloud providers do not have a physical DC. More likely, they use and effectively resell the capability of the big cloud providers. That is fine. That is an advantage and part of the beauty of using the cloud. If the relationship between the cloud providers is not known, that could cause additional issues regarding laws, regulations and contracts. Ask this simple question: Where is my data? If there are multiple levels to the cloud providers, the answer could be hard to determine, and there could 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 DLPaaS (Data Leak Prevention) or use tools to assist with security, such as a scanning tool that searches for personally identifiable information (PII) so that 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.
A good question to address is: What are your concerns? This will help to determine what questions to ask your cloud provider. From a legal standpoint, organisations must comply with EU GDPR (European Union General Data Protection Regulation), SOX (Sarbanes-Oxley - US financial data protection), HIPAA (Health Information Portability and Accountability Act - US health care), and others. Also, credit card protection falls under contract law with PCI-DSS (Payment Card Industry - Data Security Standard).
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.
Learn more about Cloud Compliance.
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.
Learn more about Infrastructure as Code.