Chapter 10: Engaging with Cloud Providers

In previous chapters, we have covered cloud infrastructure fundamentals, common threats in cloud environments, and how to handle compliance and regulation. This chapter will cover fundamental steps prior to working with cloud services, such as engaging with cloud providers.

In the traditional data center, we control everything – from physical to logical security controls. To get assurance when working with cloud providers, there are several options, such as the following:

• Conduct a risk assessment prior to engaging with a cloud provider – one good option is to review SOC2 Type 2 reports (what controls the cloud provider has set and how effective they are).
• Have a good contract that clearly sets the obligations of the cloud provider (such as an Service Level Agreement (SLA) for handling security incidents and an SLA to notify us as customers).
• Conduct a penetration test at least once every 12 months on the system that stores or processes our data.

In this chapter, we will cover the following topics:

• Choosing a cloud provider
• What is a cloud provider?
• Tips for contracts with cloud providers
• Conducting penetration testing in cloud environments

Technical requirements

For this chapter, the reader needs to have a fundamental understanding of concepts such as cloud service models, business requirements, vendor evaluation, and penetration testing.

Choosing a cloud provider

Prior to choosing a cloud provider, we need to ask ourselves – what are we trying to achieve from migrating to the cloud or from using the cloud?

There are a few steps that we need to take before we begin working with a cloud provider:

• Decide on our business goals that the cloud provider will assist us to achieve.
• Get ourselves familiar with a potential cloud provider and try to understand its maturity level.
• Sign a contract with a cloud provider that will protect us as customers.
• Conduct an assessment of the cloud environment to make sure their security controls are effective.

The following diagram illustrates the steps involved while choosing a cloud provider:

Figure 10.1 – Choosing a cloud provider

What is the most suitable cloud service model for our needs?

This is the first question we need to ask ourselves. If we are still taking the first steps in the cloud, have legacy systems that we wish to migrate to the cloud, and don't have dependencies on specific vendors hardware (such as IBM AIX, Oracle SPARC, and so on), then Infrastructure as a Service (IaaS) is the most suitable model.

As long as our on-premises servers are based on x86 architecture and can be virtualized, we should be able to migrate or rebuild our systems based on any of the major IaaS providers.

One of the topics we should consider is our ability to connect to a cloud provider in a hybrid model and to extend our on-premises data center – what are the potential cloud providers' hybrid cloud capabilities?

Perhaps we have already chosen a cloud provider, but now we have a business or technical requirement to work with a specific service (such as Internet of Things (IoT), machine learning, and data analytics) that is considered superior, and it exists on another cloud provider. In this case, we need to consider multi-cloud architecture and review both cloud providers' multi-cloud capabilities.

We must remember that according to the shared responsibility model, we are responsible for the entire operating system maintenance, such as patch management, software upgrades, backup, hardening, and availability.

If we are planning to build new applications, based on serverless (or function-as-a-service) architecture, or if we prefer to use managed services (such as database services, machine learning, and data analytics), then Platform as a Service (PaaS) should be our preferred service model.

If we choose the PaaS model, we need to consider how are we planning to connect our development (or Continuous Integration/Continuous Delivery (CI/CD)) infrastructure to the cloud environment and how are we planning to connect our applications (whether they are located on-premises or in our IaaS environment) to the PaaS services.

Perhaps the easiest service model for organizations who wish to consume cloud services or replace a legacy on-premises system, such as Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), and messaging, with a fully managed service is to choose the SaaS model.

When choosing a mature SaaS provider (as explained later in this chapter, from the answers we received from the service provider to the questionnaire mentioned in the What is a cloud provider? section), we have the benefits of consuming a service, without the burden of ongoing maintenance, adding security controls, taking care of availability, and so on.

If we do decide to use a SaaS model, we need to understand that not all SaaS providers offer us the same level of security. Not all SaaS providers follow security best practices such as multi-tenancy (complete separation between customers of the service), protection against infrastructure-based or application-based attacks, audit reports, and security certifications.

Data privacy and data sovereignty

Prior to choosing a public cloud provider (from any of the service models), we need to consult with our data protection officer, our legal department, or an expert on data privacy to check what laws and regulations are required by our organization regarding our industry, our country, and the data we are planning to store or process in the cloud.

Since the data stored in the cloud can (potentially) be replicated around the world, we need to understand whether there are laws that require us to keep our data locally in a specific country.

Whether we serve customers in a specific country or multiple locations (or perhaps globally), we need to know whether a cloud provider has a data center presence in specific countries.

There are scenarios where we have regulation requirements (such as Payment Card Industry (PCI) and FedRAMP), and we need to build an entire cloud environment to be compliant with such regulations – in this case, we need to check whether the cloud provider has environments compliant with those regulations in specific regions.

One good example is AWS GovCloud and Azure for US Government, which are dedicated cloud environments just for government agencies. Another example is AWS China and Microsoft Azure in China, which are completely separated cloud environments for storing and processing data in China.

For the IaaS and PaaS models, it should not be an issue, since most IaaS or even PaaS services are regional – once we choose a target region, our data will not leave the region (unless we chose a global service or we decided to replicate data between regions to get closer to our customers).

One of the alternatives for making sure our data will not be copied outside a specific region is to encrypt our data, since encryption keys are regional resources, making sure that our data will not be replicated or be available outside a specific region.

For SaaS services, there is no one answer to whether we can keep data sovereignty. Some SaaS providers replicate our data across regions to allow better service availability, or they might store our backups in a different region to better protect our data. The best solution for the IaaS and PaaS services is to read the vendor's documentation.

For SaaS services, other than reading the vendor's documentation, it is strongly recommend consulting with the SaaS vendor and asking specific questions regarding data privacy or data sovereignty prior to signing a contract with SaaS vendors.

Auditing and monitoring

As we previously talked about in Chapter 6, Monitoring and Auditing of Your Cloud Environments, auditing is crucial to protect cloud environments, to gain insights about what is going on in your cloud environment, and as part of incident response and forensics if the cloud environment has been breached.

Mature cloud providers will offer you documented APIs to pull activity audit logs to your Security Information and Event Management (SIEM) systems for further analysis of who logged into the service and what actions were taken (both successes and failures).

Another type of log is a service log (such as object storage, load balancers, and managed databases). Most mature cloud providers offer us documented APIs to pull those logs.

Another type of audit log is a host log (such as an Operating System (OS), security, and application logs). Look for a cloud provider that offers you a way to pull host logs and store them in a centralized logging service that exposes an API. This will allow us to connect to the API and pull the logs to our SIEM systems for further analysis.

From an infrastructure point of view, look for cloud providers who offer you documented APIs to pull performance data and allow you to anticipate performance issues before you get complaints from your customers.

From an application point of view, look for cloud providers who offer you documented APIs to pull application insights, error logs, and statistics about the number of failed actions inside the system that enable you to ingest data into an Application Performance Management (APM) tool.

From a financial point of view, look for cloud providers who offer you documented APIs to pull billing information that enable you to ingest data into cost management tools, generate billing alerts, and so on.

An important thing to consider regarding logs is cost. Some of the services offer us a free tier (such as lasting for 30 days), and if we wish to store logs for a long period of time (for example, due to a regulation requirement), we need to consider the cost.

Another important thing to consider is log retention. Cloud providers (such as SaaS providers) might keep logs for 60–90 days. If we are required to keep logs for a longer period, we need a way to pull those logs and copy them to an external log repository.

Migration capabilities

When evaluating a cloud provider, it is important to review what your migration capabilities are in an on-premises environment or even from hosting on another cloud provider.

Consider topics such as the following:

• Secure data transfer: A mechanism for transferring files into cloud storage
• Database migration: Managed services to allow transfer of an entire database (including database schema) into a managed service in the cloud, or migration between one database engine to another
• Virtual machine migration: The ability to transfer (in either real time or offline) an entire server stack from on-premises to the cloud
• Lift and shift capabilities: The ability to migrate existing workloads, as is, assuming the cloud provider supports the same OS or database engine and versions

Authentication

Before using a cloud service, we must consider how are we going to authenticate our internal users or our external customers. We have discussed authentication in Chapter 5, Effective Strategies to Implement IAM Solutions.

When evaluating a cloud service, we need to check what authentication mechanisms are available. Some cloud providers offer us internal authentication and authorization capabilities that come built in as part of the cloud solution.

As best practice, we should avoid using cloud services that do not support standard authentication mechanisms, such as Azure Active Directory (AD) or any of the known SAML-based or OAuth 2.0 protocols, which allows us to federate our existing directory service into the cloud service without having to provision new accounts for our end users.

For external customers, choose solutions that support the OpenID Connect protocol, which allows your customers to authenticate using their personal Facebook, Apple, LinkedIn, Twitter, and other identity providers.

Summary

In this section, we discussed the methods and best practices to consider before choosing a suitable cloud provider.

What is a cloud provider questionnaire?

To evaluate a cloud provider, prior to engagement, it is very common to send the cloud provider a questionnaire, with all the topics your team believes need to be asked, to get familiar with the cloud provider.

Mature cloud providers have, most likely, shared information about their compliance and security controls.

For more information, please refer to the following resources:

AWS CSA Consensus Assessments Initiative Questionnaire (CAIQ):

https://d1.awsstatic.com/whitepapers/compliance/CSA_Consensus_Assessments_Initiative_Questionnaire.pdf

Microsoft Azure Responses to Cloud Security Alliance Consensus Assessments Initiative Questionnaire v3.0.1:

https://azure.microsoft.com/en-us/resources/microsoft-azure-responses-to-cloud-security-alliance-consensus-assessments-initiative-questionnaire-v301/

GCP CSA Consensus Assessments Initiative Questionnaire (CAIQ):

https://services.google.com/fh/files/misc/sep_2021_caiq_self_assessment.pdf

When reviewing a potential cloud provider, consider the shared responsibility model. The answers of the cloud provider will allow us a clear understanding of what the cloud provider's responsibilities are (for protecting our data) versus our responsibilities (and capabilities) as customers for protecting our data.

Questions are a part of a risk assessment process and they can come from various domains.

I'm open for suggestions, perhaps, we should ask other cloud providers, the following questions:

• Cloud infrastructure-related:
  • What is the cloud service model (IaaS, PaaS, and SaaS)?
  • What is the cloud infrastructure provider's name?
  • Where are the cloud provider's data center locations?
• Architecture-related:
  • Does the cloud provider offer full multi-tenant separation between customers (compute, storage, database, and networking)?
  • Does the cloud provider offer separation between production and development or test environments (compute, storage, database, and networking)?
• Network-related:
  • Does the cloud provider offer site-to-site (or point-to-site) Virtual Private Network (VPN) connectivity from on-premises (or from anywhere on the internet) to the cloud environment?
  • Does the cloud provider offer a dedicated network connection (such as AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect) from on-premises to the cloud environment?
• Data-related:
  • Does the cloud provider have an official privacy policy?
  • Does the cloud provider have a full-time Data Protection Officer (DPO)?
  • Is the cloud infrastructure service provider compliant with data privacy laws and regulations (such as the General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) in California)?
  • Does the cloud provider offer a built-in mechanism for data classification (such as PII, credit card information, or healthcare data)?
  • Does the cloud provider offer documentation on how to deploy and protect PCI environments (such as containing, storing, or processing credit card information)?
  • Does the cloud provider offer documentation on how to deploy and protect environments containing personal information (such as European citizens' information as defined by the GDPR)?
  • Does the cloud provider offer documentation on how to deploy and protect environments containing healthcare information (such as US healthcare information as defined by the Health Insurance Portability and Accountability Act (HIPAA)?
• API-related (the ability to pull logs from the cloud provider):
  • Does the cloud offer documented APIs for pulling audit logs to a SIEM system?
  • Does the cloud offer documented APIs for pulling performance data?
  • Does the cloud offer documented APIs for pulling application insights?
  • Does the cloud offer documented APIs for deploying new environments in an automated way (such as infrastructure as code)?
• Authentication and authorization-related:
  • Does the cloud provider support standard authentication and authorization protocols for connecting from on-premises or any type of external environment to the cloud (protocols such as SAML and OAuth 2.0)?
  • Does the cloud provider support authentication protocols (such as OpenID Connect) for authenticating external identities (such as Facebook, Apple, LinkedIn, and Twitter)?
  • Does the cloud provider support Role-Based Access Control (RBAC)?
  • Does the cloud provider allow managing permissions to cloud resources based on Identity Provider (IdP) groups (such as Azure AD groups) and match groups to roles?
  • Does the cloud provider support Multi-Factor Authentication (MFA)?
  • Does the cloud contain default passwords? If so, can we disable or replace all default passwords?
  • Does the cloud contain default accounts (such as administrator and root)? If so, can we disable or remove those accounts?
• Session management:
  • Does the cloud provider support automatic session disconnection after 15 minutes of inactivity?
  • Does the cloud provider generate random and time-restricted session IDs for each identity authenticated to the service?
  • Does the cloud provider enforce session disconnection at the end of each session?
  • Does the cloud provider enforce a single session for each authenticated identity?
• Encryption at transit:
  • Does the cloud provider enforce encryption at rest using secured protocols (such as TLS 1.2 or above) for each of the supported services?
  • If the cloud provider is exposing HTTPS services to the internet, do all services (or URLs) achieve a score of A+ in an SSL Labs test (https://www.ssllabs.com/ssltest)?
• Encryption at rest:
  • Does the cloud provider offer encryption at rest for databases?
  • Does the cloud provider offer encryption at rest for object storage?
  • Does the cloud provider offer encryption at rest for file-sharing protocols (such as Network File Transfer (NFS) or Common Internet File Transfer (CIFS)/Server Message Block (SMB))?
  • For each of the supported mechanisms for encryption at rest, does the cloud provider offer a key rotation mechanism?
  • For each of the supported mechanisms for encryption at rest, does the cloud provider support customer-managed keys?
• Incident response:
  • Does the cloud provider have built-in mechanisms to detect security incidents on its infrastructure or the infrastructure serving its customers?
  • Does the cloud provider have a documented incident response process?
  • Does the cloud provider have a dedicated incident response team?
  • What is the cloud provider's SLA for handling security incidents?
  • What is the cloud provider's SLA for handling critical vulnerabilities?
• Penetration testing and security assessment:
  • Has the cloud provider conducted a security assessment by an external auditor in the past 12 months?
  • If the cloud provider conducted security assessments in the past, were all the vulnerabilities fixed?
  • Has the cloud provider conducted penetration testing by an external auditor in the past 12 months?
  • If the cloud provider conducted penetration testing in the past, were all the vulnerabilities fixed?
  • Will the cloud provider allow its customers to schedule penetration testing?
• Secure development life cycle:
  • Does the cloud provider conduct ongoing training for its employees (and its third-party suppliers) regarding secure development?
  • Does the cloud provider follow known secure development life cycle methodology (such as the Microsoft Security Development Lifecycle, NIST Secure Software Development Framework, or some other methodology)?
  • Does the cloud provider implement Static Application Security Testing (SAST) as part of its secure development life cycle?
  • Does the cloud provider implement Dynamic Application Security Testing (DAST) as part of its secure development life cycle?
  • Does the cloud provider implement Interactive Application Security Testing (IAST) as part of its secure development life cycle?
  • Does the cloud provider implement Software Composition Analysis (SCA) as part of its secure development life cycle?
  • How does the cloud provider store secrets (such as API keys, privileged credentials, and SSH keys) as part of its infrastructure and code?
  • What security controls are been implemented by the cloud provider for handling file uploads?
• Audit and monitoring:
  • Does the cloud provider keep an audit trail of every login attempt to its services (both successes and failures)?
  • Does the cloud provider keep an audit trail of actions done on its services (both successes and failures)?
  • What records are saved by the cloud provider as part of its logging process?
  • Does the cloud provider keep a record of actions done by its own system administrators (including third-party suppliers), with access to customers' infrastructure and data?
• Business continuity:
  • Does the cloud provider share information about service outages and historical information about past outages?
  • Does the cloud provider have documented business continuity and disaster recovery processes?
  • What is the cloud provider's Recovery Time Objective (RTO)?
  • What is the cloud provider's Recovery Point Objective (RPO)?
  • Does the cloud provider have documented change management processes?
  • Does the cloud provider have documented backup processes?
• Compliance-related:
  • What cloud and cloud security-related ISO standard does the cloud provider have from the past 12 months?
  • Has the cloud provider published a CSA Security, Trust, Assurance and Risk (STAR) report?
  • Has the cloud provider published a SOC 2 report in the past 12 months?
  • Does the cloud provider have a documented information security policy?
  • Does the cloud provider have a dedicated Chief Information Security Officer (CISO)/Chief Strategy Officer (CSO)?
  • What logical controls are implemented by the cloud provider to protect its infrastructure?
  • What logical controls are offered by the cloud provider to protect customers' data?
  • What logical controls have been enforced on cloud providers employees with access to customers' infrastructure and data (such as anti-malware, device control, full disk encryption, MFA, and a VPN client)?
  • What physical controls are implemented by the cloud provider to protect its data centers?
  • Does the cloud provider perform an ongoing vulnerability assessment?
  • Does the cloud provider perform ongoing patch management?
  • Does the cloud provider's infrastructure (compute, storage, and network) comply with known hardening standards (such as CIS benchmarks, NIST, and more)?
  • Does the cloud provider conduct ongoing training for its employees (and its third-party suppliers) regarding information security and data privacy?

The CSA Cloud Controls Matrix (CCM) is a cybersecurity control framework for cloud computing. For more information, please refer to the following resources:

https://cloudsecurityalliance.org/research/cloud-controls-matrix/

The What, Why, and How on Answering Security Questionnaires:

https://learn.g2.com/security-questionnaire

7 Cloud Service Evaluation Criteria to Help You Choose the Right Cloud Service Provider:

https://www.threatstack.com/blog/7-cloud-service-evaluation-criteria-to-help-you-choose-the-right-cloud-service-provider

8 criteria to ensure you select the right cloud service provider:

https://www.cloudindustryforum.org/content/8-criteria-ensure-you-select-right-cloud-service-provider

Summary

In this section, we have suggested many questions to assist organizations in the reviewing process of cloud providers. Most of the topics can be answered by reviewing mature cloud providers' SOC2 Type 2 reports or the CSA Cloud Control Matrix (as explained in detail in Chapter 9, Handling Compliance and Regulation). I strongly recommend conducting a cloud provider assessment – a questionnaire is one of the effective ways to find out the maturity level and transparency of cloud providers.

Tips for contracts with cloud providers

A good contract protects your organization when engaging with cloud providers, since you do not have physical control over your data. You do not always have the ability to influence contracts with cloud providers.

To consume IaaS services, all you need is a credit card number. As a small organization, you will get the same contract as all other customers receive, and once you agree with the contractual terms, you cannot make any changes.

If you are able to commit to a large consumption of cloud services, you may contact your IaaS provider and sign an agreement, such as the AWS Enterprise Discount Program (EDP) or Azure EA agreements, to be able to negotiate pricing terms.

To use SaaS services, you sign a contract with your chosen SaaS provider, where you have the ability to influence the contract terms – much more than just pricing topics.

In this section, we will review common topics that should be negotiated and be embedded in contracts with cloud providers:

• Exit terms:
  • What are the customers' options for terminating a contract?
  • Are there any penalties from the customers' side for terminating a contract?
• Data location:
  • Does the contract specify what the exact data location is (that is, the country)?
  • Does the contract contain a data processing agreement for setting where customers' data is located and whether data can be processed outside a specific country?
  • Does the contract specify how the cloud provider will protect customers' data?
• Data deletion:
  • Is the cloud provider obligated to erase customers' data when terminating a contract?
  • What data erase standards does the cloud provider use when terminating a contract with its customers?
  • How long will the cloud provider keep customers' data after terminating a contract?
• Data export:
  • Is there an obligation from the cloud provider's side to return customers' data after contract termination?
  • What options does the cloud provider offer its customers to export backups of their data after terminating a contract?
• Incident response:
  • Does the contract specify what the cloud provider's obligations are regarding handling security incidents for the systems that store or process customers' data?
  • What is the cloud provider's SLA for fixing security vulnerabilities on the systems that store or process customers' data?
  • What is the cloud provider's SLA for notifying its customers about security incidents that affect the systems that store or process customers' data?
  • Does the contract specify what the cloud provider's third-party suppliers' obligations are regarding systems that store or process customers' data?
  • Does the contract contain information about security awareness, privacy, and secure development for the cloud provider's employees and third-party providers?

For more information, please refer to the following resources:

Custom terms and pricing in AWS Marketplace:

https://aws.amazon.com/marketplace/features/custom-terms-pricing/

Azure EA agreements and amendments:

https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/ea-portal-agreements

Summary

In this section, we have reviewed the important topics that should appear in any contract with cloud providers in order to protect customers' data while being stored or processed by them.

Conducting penetration testing in cloud environments

One of the ways to raise our assurance with a cloud provider is to conduct a penetration test to measure the effectiveness of their security controls.

In the SaaS model, a penetration test allows us to measure how the SaaS provider protects our data. In the IaaS model, a penetration test allows us to measure the effectiveness of the security controls we have implemented. In IaaS environments, we are in charge of the OS layer and the network environment around the virtual machines or containers.

In PaaS environments, specifically in serverless (or Function as a Service (FaaS)), we are not in charge of the lower layer of the OS; however, since we import our code, we are in charge of making sure we follow a secure development life cycle.

In SaaS environments, we are only in charge of inserting data and controlling access to the service.

If we expose a service to the internet or use a SaaS service, we need to evaluate topics such as the following:

• Is the service allowing only the minimum number of ports/protocols to the public internet?
• Is the service enforcing proper authentication controls to make sure only authenticated identities can access it?
• Is the service enforcing proper authorization controls to make sure authenticated identities have the minimum amount of access required to achieve their tasks?
• Is the service performing proper input validation to make sure all data inserted into the system is sanitized and the system is protected from injection attacks, cross-site scripting, and any other attacks originating from improper input validation?
• Is the service performing an escape before inserting data into a backend database – data that potentially can return to the end customer and impact them?
• Is the service keeping an audit log of any access attempt and request performed by its end customer?

A penetration test, together with a vulnerability assessment, allow us to measure the service security controls; however, we must always remember that cloud environments are different than on-premises.

By design, cloud environments are public and shared with many customers.

We must follow the cloud provider's terms of use. Unless we are using a SaaS service from one of the hyper-scale cloud providers, the chances are that the SaaS service is deployed above one of the hyper-scale IaaS providers, meaning we must follow the entire supply chain – both the lower layer IaaS and upper layer SaaS providers' terms of use.

Mature cloud providers build their services in a fully multi-tenant model, meaning that each customer will have its own dedicated infrastructure (such as servers, database, storage, and network separation).

It is not that rare to come across a SaaS provider that offers us their services while sharing resources between their customers (such as sharing virtual servers and databases).

In scenarios where the SaaS provider hasn't embraced modern cloud architecture (that is, multi-tenancy), one customer being targeted by an attacker will increase the chances of our organization being impacted while working with the same SaaS provider.

Most IaaS providers will allow you to run security tools against virtual servers in your IaaS environment, port scanning, or application layer tests (such as injection attacks) against virtual servers in your IaaS environment.

SaaS providers will allow you to conduct security tests against your environment, assuming the SaaS was originally built in a multi-tenant environment.

It is likely that no cloud provider will allow you to run denial-of-service-type attacks against the cloud infrastructure or any type of attempt to breach or impact other customers' environments or resources.

For more information, please refer to the following resources:

AWS – Penetration Testing:

https://aws.amazon.com/security/penetration-testing/

Azure – Penetration Testing Rules of Engagement:

https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement

Google – Cloud Security FAQ:

https://support.google.com/cloud/answer/6262505

Cloud Penetration Testing Playbook:

https://cloudsecurityalliance.org/artifacts/cloud-penetration-testing-playbook

Summary

In this section, we have reviewed the concept of penetration testing, which allows you to test the effectiveness of the cloud service security controls.

The most important thing to remember is to always follow the cloud provider's terms of use.

Summary

In this chapter, we focused on engagement with cloud providers. We reviewed topics that will assist an organization to choose a cloud provider (always focusing on business goals).

We then reviewed the cloud provider questionnaire, which allows organizations to get familiar with and select mature cloud providers once they have decided to sign up with one.

We reviewed important topics that should appear in any contract with a cloud provider, ensuring that both the legal and purchase departments have a solid understanding of what to look out for in the contractual phase.

Finally, we reviewed our ability as customers to measure the effectiveness of cloud environments (whether they are IaaS environments that we deploy and control, or SaaS offerings that we use) by conducting penetration testing on cloud environments, and the importance of following the cloud vendor's terms of use.

Understanding the topics discussed in this chapter will give customers confidence in using cloud services that store or process data outside their data centers.

In the next chapter, we will review hybrid clouds (such as the hybrid cloud strategy, identity management, network connectivity, storage and compute-related services in hybrid cloud environments, and monitoring and security-related topics).