Cloud Security, Part 1
Key topics within Cloud Security:
Part 1
- Cloud security planning and design
- Governance and operations
- Multitenant security
Part 2
- Security in an automation cloud environment
- Identity management and federation
- Data sovereignty and on-shore operations
- Cloud security standards and certifications
Part 3
- Cloud security best practices
Part 1: Cloud Security
Firms need to understand security in light of the unique pertaining to cloud environments. It is recommended to read the National Institute for Standards and Technology (NIST) Special Publication 500-299 as a good baseline cloud-security reference model and detailed specifications. Cloud computing is usually a shared model – especially as it pertains to public cloud deployments. Figure 1 summarises.
Figure 1: Security Responsibility in the Cloud
Cloud Security Planning and Design
Security must be built into the design for any cloud migration and deployment. Security cannot be an afterthought.
- PLANNING
The first step to consider is what IT systems, applications, and data should or must remain within a legacy enterprise datacenter. Not all workloads are ideal candidates for transition to the cloud due to data sensitivity concerns, mission criticality, or industry regulations on security and data controls.
Security experts need to work with application and business owners to determine which applications and data you can easily move to a cloud and which you should evaluate further or even delay moving to a cloud. You need to repeat this assessment on all key applications and data repositories to develop a priority list with specific notations on the desired sensitivity,regulatory,or other security classifications.
Key Take-Away
You should perform assessments of each application and data repository to deter- mine the security posture, suitability, and priority for transition to the cloud. Match security profiles to the cloud architecture, controls, and targeted security compliance standard.
Figure 2: NIST Security Controls Checklist
A logical next step in planning is to consider the cloud model(s) to be procured or deployed. Although public cloud services provide solid infrastructure security, they often do not have the level of security or customization your organization might need. A private cloud can be heavily customized to meet security or feature requirements, but you still need to control costs, scope creep, and over- building the initial cloud.
In a hybrid or multivendor cloud, security becomes even more complicated when evaluating, selecting, and using cloud services that are not all at the same level of security or accreditation. If you know from the beginning that your organization is likely to form a hybrid cloud with multiple cloud providers, consider establishing a minimum-acceptable security posture that all providers must meet.
- GOVERNANCE
The first and most obvious consideration is to define who establishes the security posture, policies, and potential accreditation of the system. Based on the assessment of each application and data repository, determine the overall cloud security model including any industry standard you will follow. Remember that you can select a security model or standard with which to be compliant, but you do not necessarily need to go through the actual certification process unless you’re required to by industry or government regulations. An example is NIST, ISO and Data Privacy Acts such as GDPR.
Figure 3: Levels of Security Frameworks
Organizations should determine who the consumers of the cloud services will be. If multiple departments or peer agencies will be using the cloud service, determine which security team or organization controls the standards for the overall cloud or each application. You might want to form a committee of security experts from each consuming agency, but ultimately some of the overall security strategy—and a tie-breaker for difficult decisions—will need to come from the organization that is leading or sponsoring the cloud effort.
Figure 4: NIST Risk Controls
You should also consider daily security operations, response to events, and ongoing security reviews. Regardless of where the cloud services are hosted (a provider or on-premises enterprise datacenter), you need to determine whether a third party or your internal staff will be responsible for continuous monitoring, incident response, and reporting.
Publishing the security operations process, ownership, and visibility, or statistics, events, and reports should be documented and well understood to ensure acceptance of the cloud by consuming agencies and users.
- MULTITENANT SECURITY
One of the fundamental benefits of a cloud is the ability to host multiple consuming organizations on a shared pool of network, servers, storage, and application resources. Even though public clouds heavily rely on multiple tenants to achieve a profitable scale of economy, a private cloud might or might not be deployed for use by multiple consumer organizations; however, there can still be multiple departments or project/application development teams that desire isolation of cloud services, data, network traffic, or billing and chargeback.
Key Take-Away
Multitenancy features apply to almost all cloud environments. Public clouds heavily rely on a multiple tenant sales and data isolation model. Private clouds can be deployed for just one organization but there might be multiple departments, project, or application development teams that require isolation.
From a security standpoint, it is critical to understand how multitenancy is configured so that each consuming organization or department is isolated from all the others. The cloud management system, including customer-facing portal and backend automation systems, is the primary mechanism to manage multiple tenants. The cloud management system can integrate or synchronize with an identity-management system that is either hosted by the cloud provider or connected to an internal enterprise directory services such as Active Directory or a LightweightDirectoryAccessProtocol(LDAP)service.
Using the authenticated user and group hierarchy, you can define multiple organization names in the cloud- management system and create access control list (ACL) groups. Users from the identity-management system fall within one or more of the organizations that are defined or synchronized to the cloud management portal. Each ACL group is then assigned cloud portal permissions for such activities as administration, finance and procurement, approvers, or auditors. When a user or administrator is authenticated into the customer-facing cloud management portal, he only has permissions and a view to cloud services that are assigned to his organization and within the ACL permissions.
Figure 5: Security Components
The cloud management system and portal controls which users and ACL groups have access and permissions for ordering and managing services. You can define other unique ACL groups to control access to server remote logon, virtual machines (VMs), applications, and data.
The key aspect to remember here is that all of the aforementioned access controls are software based and do not provide any level of physical separation of servers, VMs, or data in the cloud. In a normal multitenant cloud, there are pools of physical servers and storage that are segregated up using software and permissions to isolate one customer from another. Technically, one physical server will host multiple VMs—each VM being owned by a different customer or department. This VM isolation is managed through ACLs in the cloud management system and the hypervisor platform.
Key Take-Away
Most clouds use software-based access controls and permissions to isolate customers from one another in a multitenant cloud environment. Hardware isolation is an option for some clouds but is also an additional cost.
In a public cloud, the use of software-based access controls, roles-based permissions, storage, and hypervisor separation is commonplace. If more levels of isolation or separation of workloads and data between customers is required, other options such as a virtual private cloud (VPC) or a private cloud are often more suitable.
Figure 6: AWS VPC example
In a VPC, a cloud provider can still host the services, but you can configure your cloud with physically separate networks, physical servers, pools of VMs, and storage. This physical separation, often referred to as an air gap, will normally cost more than cloud services in a multitenant shared environment.
For a private cloud, you have the most flexibility to customize how networks, servers, and storage are separated, and if or how multiple consuming organizations are isolated from one another. This is where security experts need to match the value of applications and data security against the cost of the cloud infrastructure to find the right match.
One of the biggest steps in making these decisions is a thorough knowledge of multitenancy, identity and authentication systems, hypervisor, and storage security controls. With this knowledge, security personnel will begin to realize that clouds are not inherently less secure than legacy enterprise IT; in fact, they are potentially more secure with more flexibility and more alignment of data protection needs to security policy.
End of Part 1.