Chapter 12: Managing Multi-Cloud Environments
In previous chapters, we covered hybrid cloud and how to connect your on-premises data centers to Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP), and how to create a hybrid cloud architecture. In this chapter, we will cover one of the most complex scenarios in the cloud – managing multi-cloud environments. Multi-cloud is about using more than one cloud or cloud provider to setup a common environment, infrastructure, or even an application layer.
Organizations taking their first steps using cloud services consider a multi-cloud approach as a solution for protecting themselves against a vendor lock-in scenario – a scenario where our entire infrastructure or applications rely on a single cloud provider's ecosystem.
One of the questions organizations ask themselves is, what do we do if the cloud provider goes out of business? How do we migrate our assets to another cloud provider? In theory, a multi-cloud approach might resolve the vendor lock-in risk; however, organizations need to be aware of the complexities that come with multi-cloud environments.
Business continuity is another major concern. A multi-cloud architecture allows us to deploy workloads on more than one cloud provider, which reduces the impact on a business that might happen with a single cloud provider (for example, an outage to an authentication service that blocks us from working with services deployed on the cloud).
A multi-cloud architecture allows us to create disaster recovery solutions, where one cloud provider is configured as a failover for another cloud provider. These architectures, based on containers, allow us portability between cloud providers while decreasing the dependencies on a specific cloud ecosystem (from Virtual Machines (VMs), storage services, managed databases, and so on). Multi-cloud allows us to have the benefits of each cloud provider's ecosystem, including the latest versions of Kubernetes, the most scalable NoSQL database, and the latest GPU processors.
In this chapter, we will cover the following topics:
- Multi-cloud strategy
- Identity management over multi-cloud environments
- Network architecture for multi-cloud environments
- Data security in multi-cloud environments
- Cost management in multi-cloud environments
- Cloud Security Posture Management (CSPM)
- Cloud Infrastructure Entitlement Management (CIEM)
- Patch and configuration management in multi-cloud environments
- Monitoring and auditing of multi-cloud environments
Technical requirements
For this chapter, you need to have a solid understanding of concepts such as identity management, network, compute, and how to secure cloud environments.
Multi-cloud strategy
Prior to using a multi-cloud architecture, we need to ask ourselves, what are we trying to achieve through a multi-cloud strategy? Some of the most common use cases for choosing a multi-cloud strategy are discussed in the following sections.
Freedom to select a cloud provider
Most cloud providers offer us the same fundamental services (such as compute, storage, and database). Having the freedom to select a cloud provider allows us to decide for each workload where we wish to deploy our resources (VMs, containers, database, and so on), in case one of the cloud providers changes its Service Level Agreement (SLA) or pricing model.
Freedom to select your services
This freedom means that if one of the cloud providers offers a certain service that is not available on other cloud providers, such as data analytics for large datasets, or a Function-as-a-Service offering that supports a certain development language that is not supported by other cloud providers, you are free to select a multi-cloud strategy.
Reduced cost
In most cases, spreading your workloads over several cloud providers will increase the cost, due to outbound (or egress) traffic costs over the internet and between cloud providers, and the knowledge required to train your staff to work with multiple cloud providers.
There are scenarios where you are able to consume the same service from multiple cloud providers, while the cost of using the service is cheaper with one of the cloud providers, in a region close to your customers.
Organizations need to take into consideration that spreading their workloads over multiple cloud providers will impact volume-based discounts, where they may not achieve economies of scale. In the context of this section, an organization must consider what capabilities it must establish in all cloud providers.
Data sovereignty
Even though most major cloud providers have data centers in central locations in US and Europe, there are cases where your organization is required by local laws or regulations to keep customer data locally in a specific country. There might be scenarios where a specific cloud provider has no local presence in one of your customer's origins, making a multi-cloud approach a suitable solution.
Backup and disaster recovery
Storing data in multiple locations, with multiple cloud providers, will decrease the risk of your organization losing data or overcoming cloud provider service availability in a certain region or even overcoming global service availability issues.
Improving reliability
Even though most major cloud providers offer Distributed Denial of Service (DDoS) protection services, there might be scenarios where one of the cloud providers is currently under a DDoS attack themselves, cloud providers might suffer from service outages, internet providers may encounter latency, or workloads may fail for various reasons.
To improve reliability, consider topics such as the following:
- Data replication between cloud providers, which impacts cost (redundant storage, data transfer cost, and so on).
- Failover scenarios – where do you manage your DNS records and update them in case of failover between providers?
- Automation – what tools or services will you use for failover between providers?
- Knowledge – does your IT or development staff have enough knowledge to switch between cloud providers?
Having the ability to switch your workloads to another cloud provider (assuming you have already built an entire production environment on another cloud provider and synched data) will allow you to mitigate the risk of having your services unavailable.
Identity management
A multi-cloud strategy must address identity management. Each cloud provider has its own Identity and Access Management (IAM) solution, which causes challenges and opportunities for a centralized identity life cycle (onboarding, access management, and offboarding) and credential management.
The aforementioned challenges increase the motivation to centralize on a single IAM solution that must be integrated with each cloud provider.
Data security
A multi-cloud strategy must address data security issues. Common examples of data security in a multi-cloud environment are as follows:
- Keeping data residency, while working with multiple cloud providers
- Data replication between cloud providers and within a single cloud provider over multiple regions
- Access control of your data over multiple cloud providers
- Encryption and key management over multiple cloud providers
- Audit access to data over decentralized audit solutions
- Misconfigurations when working with multiple cloud providers, each with its own services and capabilities
Asset management
A multi-cloud strategy makes asset management a challenge for any organization. An organization must have visibility or a real-time, centralized inventory of its entire cloud environment – what assets it has, where its assets are located (which cloud provider and which account), who owns its assets, and who has access to its assets.
Skills gap
A multi-cloud strategy must address the fact that working with multiple cloud providers requires hands-on experience in architecture, development, and operations, working with multiple cloud solutions. An organization must invest in employee training as an ongoing process to allow employees the necessary knowledge to maintain multiple cloud platforms. An important topic to invest in is automation, to scale the impact of employees and to reduce the operational burden.
For more information, refer to the following resources:
How computing has evolved, and why you need a multi-cloud strategy:
https://cloud.google.com/blog/topics/hybrid-cloud/future-isnt-just-cloud-its-multi-cloud
The Multi-Cloud & How To Create A Multi-Cloud Strategy:
https://www.bmc.com/blogs/multi-cloud-strategy
Summary
A multi-cloud strategy helps organizations decide in which scenario to select a different cloud provider or different cloud service. Such a strategy must address data security topics (including data residency, availability, and protection mechanisms).
One important topic that organizations should consider is the fact that a multi-cloud approach demands highly experienced and trained employees, and as such, organizations must invest in employee training.
Identity management over multi-cloud environments
One of the first things to decide on, prior to using a multi-cloud strategy, is identity management. Organizations would like to keep their existing Identity Provider (IdP), have a single identity for each of their end users (while preserving existing credentials), and still be able to access resources in the cloud. If an organization is already using Office 365 for managing mailboxes and collaboration, consider using Azure Active Directory (AAD) and its central identity management service.
Azure AD is considered the most used IdP. It supports identity federation to most major cloud providers and is able to integrate with most Software as a Service (SaaS) solutions. Other popular identity management providers that are outside the scope of this book are Okta, Ping Identity, and OneLogin, which allow you a universal directory service for managing your users, groups, and devices, enforcement of Multi-Factor Authentication (MFA), and single sign-on for multiple cloud providers and SaaS applications.
How to manage identity in AWS over multi-cloud environments
AWS provides the following services to manage identity over multi-cloud environments:
- AWS Single Sign-On (SSO) – a service that allows single sign-on across AWS organizations or connection to identities in external cloud identity services based on the SAML protocol, such as Azure AD or Google G Suite.
- Amazon Cognito – a service that allows single sign-on for web or mobile applications while allowing customers to connect using external IdPs, such as Apple, Facebook, or Google, or SAML-based authentication, such as Azure AD.
Best practices are as follows:
- Use AWS SSO as an IdP to federate and manage access to cloud applications (such as Salesforce, Box, and Office 365). AWS SSO can also provide federated access by accepting inbound SAML for services such as Okta.
- Use Amazon Cognito to manage access to customer-facing web or mobile applications, using external IdPs such as Azure AD, Apple, Facebook, or Google.
- Use AWS CloudTrail to log all AWS SSO API calls.
- Use AWS CloudTrail to log all Amazon Cognito API calls.
- Use Amazon GuardDuty to generate security events (based on AWS CloudTrail) about suspicious activities (such as a brute-force attempt using an external identity) and send notifications using as AWS Simple Notification Service (SNS), to services such as SMS, mobile, email notifications, or trigger a Lambda function to take some action (such as blocking network access using a security group). The best use of Amazon GuardDuty is to aggregate events into AWS Security Hub or to a centralized Security Information and Event Management (SIEM).
- Use TLS 1.2 when sending API calls to Amazon Cognito.
- When working with AWS SSO, if you need to configure fine-grain access to resources, based on external identity attributes (such as title and location), use Attribute-Based Access Control (ABAC) in conjunction with an IAM policy (such as conditions in the IAM policy).
- When working with AWS SSO with an external IdP, or AWS SSO as an IdP that supports MFA, enforce the use of MFA in your external IdP settings to allow strong authentication.
- When working with Amazon Cognito to allow access to web or mobile applications, enforce the use of MFA to a user pool to allow strong authentication.
- Use Amazon CloudWatch or any other SIEM or analytics tools to monitor Amazon Cognito user pools and raise an alarm when a certain threshold is passed (such as a high number of unsuccessful federation login attempts from an external IdP).
- Use Amazon Cognito compromised credentials protection features to detect whether a user's credentials were compromised and block access attempts from that user.
For more information, refer to the following resources:
Automate SAML 2.0 federation for AWS multi-account environments that use Azure AD:
Adding SAML identity providers to a user pool:
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html
Adding multi-factor authentication (MFA) to a user pool:
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-mfa.html
How to use G Suite as an external identity provider for AWS SSO:
https://aws.amazon.com/blogs/security/how-to-use-g-suite-as-external-identity-provider-aws-sso/
How to manage identity in Azure over multi-cloud environments
Azure provides the following services to manage identity over multi-cloud environments:
- Azure AD – an Azure IdP that allows access to Azure resources or SaaS applications using external SAML-based IdPs such as AWS SSO or Google Identity.
- Azure AD B2C – an Azure IdP that allows access to customer-facing applications or non-Microsoft SaaS services, using external identities such as Gmail and Facebook.
Best practices are as follows:
- Use Azure AD, combined with AWS SSO, to allow central identity management for both Azure and AWS resources.
- Use Azure AD, combined with Google Identity or Google IAM to allow central identity management for both Azure and GCP resources.
- Use Azure AD B2C to allow access to customer-facing applications or third-party SaaS services.
- Use Conditional Access to enforce the use of MFA when connecting using external IdPs.
- When using AWS SSO as an IdP, integrated with Azure AD, configure Azure Privileged Identity Management (PIM) to configure just-in-time access to the Azure portal and Azure resources.
- Use Microsoft Defender for Cloud Apps to monitor protected services (using a combined identity).
- Use Microsoft Defender for Cloud Apps to protect your combined environment from risky users or data exfiltration.
- Use TLS 1.2 when sending API calls to Azure AD B2C.
- When using Azure AD B2C to authenticate web applications, create separate environments – split between development, testing, and production.
- Audit each of the web applications that are using Azure AD B2C using audit log events stored in Azure Monitor and send the logs to a SIEM service (such as Azure Sentinel).
For more information, refer to the following resources:
Multi-cloud security and identity with Azure and Amazon Web Services (AWS):
https://docs.microsoft.com/en-us/azure/architecture/aws-professional/security-identity
Azure Active Directory integration with Amazon Web Services:
https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/aws-multi-accounts-tutorial
Recommendations and best practices for Azure Active Directory B2C:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/best-practices
How to manage identity in GCP over multi-cloud environments
Google provides Cloud IAM as a service that allows integration with other IdPs such as AWS or Azure AD.
Best practices are as follows:
- When integrating Google Cloud with external IdPs (such as AWS or Azure AD), use short-lived Google access tokens such as AWS Security Token Service to impersonate a service account.
- When integrating Google Cloud with Azure AD, enforce the use of MFA on Azure AD.
- When integrating between Google Cloud and Azure AD, sync groups from Azure AD instead of managing groups in Google Cloud.
- Avoid automatic user provisioning for identities with consumer accounts to avoid creating duplicate accounts.
- When connecting Google identities to Azure AD, the user identities become guest accounts on Azure AD. As best practice, do the following:
- Provision guest users on Google Cloud inside a dedicated organizational unit.
- Apply policy to restrict the maximum session duration for guests' users to 8 hours.
- Set the re-authentication method to using a password to force the user to re-authenticate using their Azure AD credentials.
For more information, refer to the following resources:
Configuring workload identity federation:
https://cloud.google.com/iam/docs/configuring-workload-identity-federation
Federating Google Cloud with Azure Active Directory:
https://cloud.google.com/architecture/identity/federating-gcp-with-azure-active-directory
Azure AD user provisioning and single sign-on:
Summary
Selecting an authentication and authorization method allows an organization to reuse its existing IdPs and to keep a single identity for each of its end users in a central repository.
When possible, it is recommended to manage user identities using a central Identity Management (IDM) system for provisioning and de-provisioning on your chosen cloud IdP.
Network architecture for multi-cloud environments
The second important thing to consider when building a multi-cloud architecture is how to set up network connectivity between the various cloud providers, and between on-premises software and cloud providers.
The recommended way to connect to cloud environments is a secure and permanent network connection using dedicated interconnect (such as AWS Direct Connect or Azure ExpressRoute) for connecting from the on-premises to the cloud or using a site-to-site Virtual Private Network (VPN) (either from on-premises to the cloud or between cloud providers).
A secured and permanent connection will allow access control (layer 4 firewall rules) to be set between cloud providers and cloud segments, and keep access to resources in the cloud (or allowing access to cloud resources) according to business needs.
When considering network architecture, you need to consider the following:
- Which resources should be kept private (such as data transfer and backend service-to-service communication)?
- Which resources can be public (such as public API calls, frontend services, and VPN endpoints)?
Figure 12.1 – Network connectivity from GCP to AWS
Let's now proceed to look at how to create connectivity between AWS and GCP in the next section.
How to create network connectivity between AWS and GCP
To create an IPsec VPN tunnel between AWS and GCP, follow these high-level guidelines:
- Create a dedicated AWS Virtual Private Cloud (VPC) with a new subnet for the VPN tunnel.
- Create a dedicated GCP VPC with a new subnet for the VPN tunnel.
- If network redundancy is not required, create a connection between an AWS virtual private gateway (using an AWS-managed VPN) and Google Cloud VPN.
- If network redundancy is required, create a connection between an AWS transit gateway and Google High Availability (HA) VPN.
Best practices are as follows:
- Always think about Classless Inter-Domain Routing (CIDR) prior to configuring network segments in the cloud to avoid IP conflict between the cloud providers.
- On the AWS side, use network Access Control Lists (ACLs) and security groups to protect resources inside your AWS VPC.
- On the GCP side, use firewall rules to protect resources inside your GCP VPC.
For more information, refer to the following resources:
Connecting an AWS and GCP VPC using an IPSec VPN Tunnel with BGP:
Build HA VPN connections between Google Cloud and AWS:
https://cloud.google.com/architecture/build-ha-vpn-connections-google-cloud-aws
Multi-Cloud Architecture using VPN between GCP and AWS:
https://blog.searce.com/multi-cloud-architecture-using-vpn-between-gcp-and-aws-167a5e739079
How to create network connectivity between AWS and Azure
To create an IPsec VPN tunnel between AWS and Azure, follow these high-level guidelines:
- Create a dedicated AWS VPC with a new subnet for the VPN tunnel.
- Create a dedicated Azure VNet with a new subnet for the VPN tunnel.
- Create a connection between an AWS virtual private gateway (using an AWS-managed VPN) and Azure VPN Gateway.
Important Note
For network redundancy, create two VPN tunnels.
Best practices are as follows:
- Always think about CIDR prior to configuring network segments in the cloud to avoid IP conflict between the cloud providers.
- On the AWS side, use network ACLs and security groups to protect resources inside your AWS VPC.
- On the Azure side, use network security groups to protect resources inside your Azure VNet.
For more information, refer to the following resource:
How to create a VPN between Azure and AWS using only managed solutions:
How to create network connectivity between Azure and GCP
To create an IPsec VPN tunnel between Azure and GCP, follow these high-level guidelines:
- Create a dedicated Azure VNet with a new subnet for the VPN tunnel.
- Create a dedicated GCP VPC with a new subnet for the VPN tunnel.
- If network redundancy is not required, create a connection between Azure VPN Gateway and Google Cloud VPN.
- If network redundancy is required, create a connection between Azure VPN Gateway and Google HA VPN.
Important Note
For network redundancy, create two VPN tunnels.
Best practices are as follows:
- Always think about CIDR prior to configuring network segments in the cloud to avoid IP conflict between the cloud providers.
- On the Azure side, use network security groups to protect resources inside your Azure VNet.
- On the GCP side, use firewall rules to protect resources inside your GCP VPC.
For more information, refer to the following resource:
Creating a Site to Site VPN Connection Between GCP and Azure with Google Private Access:
Summary
According to your business requirements, you can have a secured and redundant connection between cloud providers using a site-to-site VPN connection.
Data security in multi-cloud environments
Data security in the cloud relates to protecting data as it transfers over the network, at rest, and in use.
Encryption in transit
To secure your cloud environment, make sure that all data traverses through secured protocols. Some alternatives to secured protocols are as follows:
- Enforce the use of TLS 1.2 for accessing resources over your entire multi-cloud environment.
- Configure IPsec VPN tunnels between your on-premises and cloud environments, and between cloud providers.
Encryption at rest
All major cloud providers have their own Key Management Services (KMSes), for managing keys, secrets, credentials, and so on. Although the built-in KMSes can store, manage, retrieve, and rotate keys and secrets, they are integrated into their own cloud provider's ecosystem. When selecting a solution for handing encryption at rest, look for the following capabilities:
- The ability to encrypt data at rest over multiple cloud providers – each cloud provider has its own KMS. If you need to share encryption keys across multiple cloud providers, you need to deploy a third-party solution to achieve this goal.
- The ability to handle the scale of your cloud environment (generating thousands of keys from multiple cloud providers).
Important Note
Consider a Hardware Security Module (HSM)-based solution when you need to comply with regulations (such as PCI DDS), since HSM devices are tamper-resistant and tamper-proof.
- The ability to create, store, retrieve, and rotate both keys and secrets from multiple cloud provider services.
- The ability to configure role-based access control – who can generate keys/secrets on which cloud account or cloud provider.
- The ability to generate a full audit log for the KMS solution for further investigation.
Encryption in use
The concept of encryption in use is to be able to protect data while running in memory on a VM or a container. The best-known concept for encryption in use is confidential computing. Common confidential computing alternatives are as follows:
- AWS Nitro Enclaves
- Azure confidential computing
- Google Confidential Computing
To protect data in multi-cloud environments, combined with central provisioning solutions, aim to deploy VMs or containers that support one of the aforementioned confidential computing solutions.
Summary
In this section, we have reviewed various ways to protect data in cloud environments. Enforcing the use of encryption in all layers (at transit, at rest, and in use) will allow you to protect your cloud environment, even when working in multi-cloud environments.
Cost management in multi-cloud environments
Although cost management (also known as financial management or FinOps) may not seem directly related to security, it has implications on a multi-cloud environment.
Cost management is part of having visibility over your entire multi-cloud environment, from a cost point of view. All major cloud providers have their own built-in cost management services that allow you the necessary visibility of your cloud accounts, subscriptions, or projects.
When organizations are moving from a single cloud provider (in many cases, with multiple accounts at the same cloud provider, for different environments or business needs) to a multi-cloud setup, they begin to realize that they lack the necessary visibility regarding cloud cost.
Some of the concerns organizations often have are as follows:
- Data transfer cost (also known as egress data)
- Redundant resources being spent (such as multiple log systems, backup services, and anti-malware solutions)
The possible risks of not having cost visibility are as follows:
- High payments from multiple cloud providers, without knowing what resources are been consumed and whether we need those resources.
- Identifying anomalous spend, such as charges in unexpected regions, unexpected services, or anomalous volumes, which may be indicators of compromise, specifically when working in a multi-cloud environment.
- A potential denial-of-wallet scenario, where a hacker gains access to one of our cloud accounts, consuming expensive compute resources for bitcoin mining. Without proper visibility or an alerting mechanism, by the time we become aware that someone is using our resources, we will have to pay thousands of dollars to the cloud providers.
Best practices are as follows:
- Deploy a cost management solution that supports multiple cloud providers.
- Tag all resources in all your cloud accounts, in all your cloud providers.
- Create billing alerts for each of your cloud accounts when a certain threshold is passed (for example, when the total monthly consumption of a test environment account passes $500 or when the total monthly consumption of a production environment account passes $1,500).
- Configure a budget for each of your cloud accounts. Once the budget has been configured, generate an automatic budget alert once a certain threshold of the budget (such as 75%) has been passed.
- Deploy automation capabilities to remove unused resources (such as VMs, containers, and managed databases). Automation will allow you to deploy development or testing environments when resources are needed.
- Review cost recommendation reports and follow the recommendations, such as the following:
- Rightsizing a VM to a smaller VM type (with less CPU or memory).
- Shut down underutilized VMs.
- Change the purchase options of VMs from on-demand (or pay as you go) to a reserved instance (a commit for 1 or 3 years in advance) or even spot (or pre-emptible), according to the expected VM runtime.
- Switch to cheaper block storage (disk volumes) according to the actual usage (disk utilization).
- Migrate objects on object storage services to a cheaper tier (from hot or real-time storage to cool or near real-time, or even to cold or archive storage).
- Delete unneeded backups or snapshots.
For more information, refer to the following resources:
The 2021 Guide to Multi-Cloud Billing and Cost Management:
https://www.meshcloud.io/2020/12/23/the-2021-guide-to-multi-cloud-billing-and-cost-management/
How to take control of your multi-cloud costs:
Summary
In this section, we have reviewed the importance of having visibility of your cloud costs over multi-cloud environments, as part of multi-cloud governance. Having visibility over costs in a multi-cloud environment will allow you to mitigate the risk of high payments or potential hidden bitcoin mining in one of your cloud accounts.
Cloud Security Posture Management (CSPM)
As part of having visibility in your multi-cloud environments, over the past couple of years, a new concept has emerged.
There are multiple offers from many third-party CSPM vendors, but the fundamental idea behind all CSPM solutions is to have visibility of misconfigurations – a crucial topic when working in a multi-cloud environment and managing multiple cloud accounts. When selecting a CSPM solution, look for the following capabilities:
- Support for multiple cloud providers.
- Visibility of misconfigurations (such as an opened port and publicly accessible object storage).
- Visibility of IAM (such as API keys located in publicly accessible object storage, access keys or passwords that were not rotated in the past 90 days, users' permissions, and accounts missing MFA).
- Visibility of your entire cloud assets across a multi-cloud environment.
- The ability to assess risks over your entire multi-cloud environment.
- The ability to prioritize risk mitigations – your staff needs to know what risks need to be handled immediately.
- Contextualized visibility – a publicly accessible web server must be patched first, while servers that reside in a private subnet, protected with strict access network controls, can be patched later.
- The ability to remediate misconfigurations automatically.
- Get insights into attack vectors – understand how a potential attacker can take advantage of misconfiguration to breach your cloud environment.
- Visibility in vulnerable components (such as missing security patches on a VM or an old open source library inside a container).
- Get insights into mitigation actions – your staff needs to know what actions to take in order to resolve a misconfiguration or potential risk.
- Check for compliance in your entire multi-cloud environment against well-known security frameworks (such as ISO 27001) and regulations (such as General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA)).
- Continuous monitoring of your entire multi-cloud environment – detecting threats and misconfiguration must be an ongoing process.
- Integration with SIEM systems for further investigation.
- Integration with a ticketing system for submitting tasks to allow your staff to handle alerts from the CSPM solution.
For more information, refer to the following resources:
Cloud Security Posture Management (CSPM):
https://searchcloudsecurity.techtarget.com/definition/Cloud-Security-Posture-Management-CSPM
The Past, Present And Future Of Cloud Security And CSPM Solutions:
Summary
In this section, we have reviewed the concept of CSPM solutions to have visibility of our entire cloud environments. We have also reviewed the CSPM capabilities when selecting a CSPM solution.
Cloud Infrastructure Entitlement Management (CIEM)
A new concept developed in the past couple of years is CIEM. Some vendors offer a combined solution of both CSPM and CIEM into a single product, which factors in a multi-cloud partner strategy.
CIEM solutions allow us to monitor and manage identities (both human and machine) and access privileges in a multi-cloud environment, from a central console, while applying the principle of least privilege access to our cloud infrastructure. When selecting a CIEM solution, look for the following capabilities:
- Support for multiple cloud providers
- An inventory of existing entitlements
- Detecting and remediating IAM misconfigurations
- The ability to control access to resources, services, and administrative accounts
- Identifying risks associated with configuration errors
- Identifying shadow admin accounts in a multi-cloud environment
- Suggestions for policy correction
- Auto-generation of access policies according to actual identity needs
- Detecting excessive permissions to identities
- Detecting external and cross-account access permissions
For more information, refer to the following resource:
What is CIEM and why should CISOs care?
https://searchcloudsecurity.techtarget.com/post/What-is-CIEM-and-why-should-CISOs-care
Summary
In this section, we have reviewed the concept of CIEM solutions for detecting and remediating misconfiguration regarding IAM. We have also reviewed the CIEM capabilities when selecting a CIEM solution.
Patch and configuration management in multi-cloud environments
One of the challenges in multi-cloud environments is controlling software updates and configuration changes from a central place. When selecting a patch management solution, look for the following capabilities:
- The ability to centrally manage patch deployment from a central place
- Support for deploying security patches on both Windows and Linux platforms
- Support for asset inventories
- Support for patch rollback in case of a problematic security patch
- Support for deploying security patches over secured protocols (such as the TLS tunnel between the central patch server and the remote VM)
- The ability to deploy security patches to a group of servers (such as different environments and a different patch cycle to avoid breaking availability in case of server clustering)
- The ability to deploy third-party security patches (such as patches to self-managed database servers, web servers, and client tools)
- The ability to configure minimal credentials to access remote VMs over your entire multi-cloud environment for patch deployment
- The ability to configure a maintenance window for patch deployment (to avoid deploying patches during working hours)
- The ability to generate compliance reports (such as what percentage of your servers were already deployed with a patch and which servers are still missing a patch)
- The ability to integrate a patch management solution with a ticketing system to allow your staff to take care of vulnerable VMs
Another topic that needs to be addressed when working with development teams is taking care of open source libraries, also known as Software Composition Analysis (SCA). When selecting an SCA solution, look for the following capabilities:
- The ability to centrally manage your entire multi-cloud environment from a central location
- The ability to integrate with multiple source code repositories
- The ability to integrate with multiple container registries in multi-cloud environments
- The ability to search for outdated open source library repositories
- The ability to detect both a vulnerable or outdated open source library and all of its dependencies
- The ability to configure minimal credentials to access a remote source code or container registries
- The ability to integrate the SCA solution with Continuous Integration/Continuous Delivery (CI/CD) processes (in multi-cloud and multi-account environments, it is common to have multiple CI/CD pipelines)
- The ability to generate reports to allow you to see which vulnerable components exist in your development or production environments
- The ability to break a build process if you are using vulnerable components
- The ability to set the vulnerability severity that is allowed in your environments before breaking a build process (for example, do not allow the completion of a build process if critical vulnerabilities exist in one of the open source libraries or dependencies)
- The ability to integrate an SCA solution with a ticketing system to allow your staff to take care of vulnerable components as part of the build process
Configuration and change management are also crucial topics to take care of in multi-cloud environments. When selecting configuration and change management solutions, look for the following capabilities:
- The ability to manage your entire multi-cloud environment from a central place
- The ability to configure minimal credentials to access assets in multiple cloud providers and multiple cloud accounts
- The ability to detect compliance against well-known standards, such as a Centre of Internet Security (CIS) benchmark or National Institute of Standard and Technology (NIST)
- The ability to detect a configuration change in a multi-cloud environment
- The ability to automate a configuration change in multiple cloud accounts
- The ability to integrate a configuration or change management solution with a ticketing system to allow your staff to take care of the changes
- The ability to integrate with a SIEM system to raise alerts when a configuration change is detected in one of your systems
Summary
In this section, we have reviewed patch management and configuration/change management in a multi-cloud environment. Since multi-cloud environments face many challenges in these areas, we have reviewed important capabilities to look out for when searching for a solution to manage security patches and configuration management.
The monitoring and auditing of multi-cloud environments
Monitoring is a crucial part of multi-cloud visibility. It can have multiple layers, such as the following:
- Resource utilization (performance logging)
- Monitoring running applications for errors (application logging)
- Security auditing and logging to detect security incidents
In this section, we will focus on security monitoring. When selecting a security monitoring solution for multi-cloud environments, look for the following capabilities:
- The ability to connect to multiple cloud providers, using the native cloud provider APIs
- The ability to connect to remote APIs using secured protocols (such as TLS 1.2)
- Built-in connectors for multiple cloud solutions (both common Infrastrucure as a Service (IaaS)/Platform as a Service (PaaS) and SaaS)
- The ability to receive feeds from threat detection services such as Amazon GuardDuty, Microsoft Defender for Cloud, and Google Security Command Center
- The ability to receive feeds from third-party vulnerability management solutions
- The ability to receive feeds from configuration management solutions to detect a misconfiguration or deviation from standards
- The ability to detect anomalous user behavior (such as a user trying to access a resource for the first time or outside the normal working hours) and raise an alert
- The ability to store all logs encrypted at rest
- The ability to configure role-based access control of the monitoring solution to various employees in various roles (such as IT staff, security analysts, and auditors) and in different places in your organization (for example, not all teams need access to view information about your entire cloud environment)
- The ability to receive real-time and continuous monitoring from your entire multi-cloud environment
- The ability to create correlation rules between various log sources (such as audit logs, endpoint detection solutions, and network traffic flow logs)
- The ability to run automated remediation actions (such as closing an open port and disabling a compromised account)
- The ability to create alerts based on logs and send them to a central SIEM system
- The ability to integrate with a ticketing system to allow your staff to take care of discovered security incidents
Summary
In this section, we have reviewed security monitoring and auditing in a multi-cloud environment. We have also reviewed the important capabilities to look for when searching for a solution for security monitoring in multi-cloud environments.
Summary
In this chapter, we have focused on multi-cloud environments. We have reviewed the importance of having a multi-cloud strategy to allow organizations to adopt multi-cloud environments. We have also discussed the various IAM solutions from AWS, Azure, and GCP that allow organizations to have a central directory service that can keep a single identity for each end user.
We looked at the various methods that AWS, Azure, and GCP allow organizations to connect between different cloud environments on different cloud providers using a site-to-site VPN tunnel. We also discussed the various data security mechanisms (encryption at transit, encryption at rest, and confidential computing). Then, we reviewed the importance of cost management in multi-cloud environments. We reviewed the concepts of CSPM and CIEM. Finally, we looked at patch management, configuration management, and monitoring in multi-cloud environments.
Understanding the topics mentioned in this chapter will provide organizations with the necessary tools when they build multi-cloud architectures.
In the final chapter of the book, we will review security in large-scale cloud environments (such as configuring governance and policies using infrastructure as code for automation, patch management, compliance, and vulnerability management).