System and method for implementing decoys in a cloud environment

Abstract

A system and method are described for employing and monitoring decoy cloud entities within a cloud computing environment 100 for the purposes of intrusion detection. Intruders who attempt to access en

Description

Technical field The present disclosure generally relates to cloud computing security, in particular to methods and systems for securing cloud computing environments. Background The adoption of cloud computing platforms and environments is increasing year-on-year. And increasingly, organizations are building and running applications based on cloud-native technologies rather than using an approach commonly known as a “lift-and-shift” whereby existing data and applications are simply copied to a cloud environment from those systems on which they have previously been implemented. Many organizations are instead using the abstractions and services provided by the cloud computing platform to run their workloads and store their data. For instance, sensitive and valuable data may be stored in AWS S3 (Amazon Web Services Simple Storage Service) Buckets. Cloud platforms and the abstractions that they provide have enabled uniform and standardized interfaces for providing for the storage of data and secrets and for identity and access management. They also allow great flexibility in the configuration and interconnection of these resources. However, as the use and complexity of cloud computing environments has increased, so too have the risks to organizations operating workloads in those environments. Threat actors who target organizations may seek to exploit any misconfigurations that can provide them access to the environment. If they can do this, the uniform and standardized interfaces of the cloud platform may then be employed to readily and rapidly discover, access, and exploit the “crown jewel” cloud resources of the organization, whether for data exfiltration, lateral movement or other malicious purposes. Furthermore, where organizations may be vulnerable to unauthorized access to their data and systems without the knowledge that they have been compromised, this represents a significant additional risk. There is therefore a great need to discover possible intrusions in a cloud environment quickly and reliably. This is a difficult problem, compounded by the rise of agile development practices and speed of development available in cloud platforms, wherein the workloads, access patterns, configurations and cloud resources employed within a cloud environment are frequently changing. Techniques such as anomaly detection or static rules that define expected behavior and identify exceptions are therefore ineffective. Summary The system and method for detecting intrusions within a cloud environment claimed here is by employing the use of decoy cloud entities. Decoy cloud entities are deployed into cloud platforms, alongside the cloud entities that the system will protect. If an intruder gains access to the cloud environment, they are likely to attempt to discover cloud entities that may be exploited. In doing so, they are likely to interact with any number of the decoy cloud entities deployed into the environment. Cloud platforms typically provide audit logging services for recording activity against cloud entities. The cloud entity decoy security system can thereby detect possible intrusions by monitoring activities performed against the decoy cloud entities. The fact that the decoys have been specifically deployed with this intent allows for much higher confidence that the activity detected is suspicious. The decoys may also serve to distract or lure the attacker away from the other valuable cloud entities in the environment. Decoys have previously been employed in computer security, but implementation of the novel system and method described here within a cloud environment leads to significant and surprising improvements over the state of the art. Traditional approaches to decoys might include SSH (secure shell) servers, FTP (file transfer protocol) servers, and the like. The code and systems realizing such decoys will need to be patched and maintained by an organization in accordance with security best practices. But even where this is done diligently, there is a risk of the use of such systems as “footholds” for an attacker to execute code themselves, establish persistence and to further compromise the environment in which they are located. This makes the risk-benefit tradeoff of such an approach somewhat marginal. In contrast, the decoy cloud entities employed in the disclosed method and system are those virtualized, serverless or otherwise abstracted entities provided by the cloud platform providers, whereby the maintenance of any underlying code and servers implementing these entities is the responsibility of the cloud platform provider and is not specific to any organization using these services. Further, organizations are increasingly likely to implement their “crown jewels” resources using cloud entities, for instance storing their most critical and sensitive data in AWS S3 Buckets rather than on file servers. Attackers intruding in a cloud environment are correspondingly increasingly likely to look for these cloud entities directly. Given this, decoy cloud entities can represent a much more effective detection mechanism than any prior approach. Prior approaches may involve dedicated decoy environments that are not fully integrated within the organization’s cloud environment. These attempt to mitigate risk by means including but not limited to attempting to: reducing other undesirable interactions within the existing cloud environment; attempting to gain threat intelligence about attackers with less risk to the existing cloud environment; or attempting to lure attackers away from the existing cloud environment. This is disadvantageous in that: such environments appear less plausible to an attacker; may be harder for an attacker to discover; and because activities uncovered within them are not occurring in the environment that is ultimately to be protected and so do not so clearly represent an intrusion of concern. The disclosed method of deploying decoy cloud entities directly into the same cloud platforms and environments as those cloud entities to be protected is therefore surprisingly advantageous as well as novel. Prior approaches involving decoy servers offering networked services are difficult to deploy in an environment in a fashion that will look plausible to an attacker when compared to the other servers and services in the environment. There are many factors which may distinguish them from existing servers, for example hostnames, hardware resource allocation, open ports, operating system versions, licenses assigned, users and groups, services operated etc. This can make it impractical to effectively resemble the other servers on the network. In contract, the abstract cloud entities provided by cloud providers typically only have a few degrees of freedom in terms of the configuration options offered. The decoy cloud entities configuration options can be readily made to match the existing cloud entities, thereby making the decoy cloud entities more plausible. Prior approaches may also necessitate emulation, whereby for example, the decoy server purports to be an SSH server and emulates some of the expected capabilities of an SSH server. This may be to try to limit the aforementioned risks of attackers gaining footholds in non-emulated decoy SSH servers, or for economical reasons whereby a server can purport to offer many different decoy servers or otherwise. Emulation however increases the chance of a sophisticated attacker “fingerprinting” the emulated system as a decoy, due to the inherent limitations and complexity introduced by emulation. The disclosed method and system has the advantage that those decoy cloud entities deployed are cloud entities in their own right with no element of emulation necessary. The decoy cloud entities therefore may be much harder for an attacker to distinguish as decoys and therefore avoid. The disclosed approach is also advantageous in that the virtualized, serverless or otherwise abstracted cloud entities are often offered at no cost, or are billed based on usage (whether traffic or storage volume) by cloud providers. For decoy cloud entities, the usage and storage volume experienced is typically very small given their purpose, with the corresponding costs being very low. This makes it cost effective to deploy a wide variety and large number of such decoys in the cloud environment where prior techniques may prove cost prohibitive. Having many decoys deployed may be advantageous in that it increases the chance of an attacker discovering and accessing them, thereby being detected. It also increases the chance of the attacker devoting attention to decoy cloud entities rather than those existing cloud entities to be protected. An additional benefit of the use of decoy cloud entities is that they may be monitored by using the capabilities of cloud platform audit logging services. These typically provide richer data than would otherwise be available, are harder to maliciously interfere with without detection and since they may also monitor activity on non-decoy cloud entities, provide a uniform and ready means by which to correlate and investigate the source of an intrusion and other activities performed by the intruder within the cloud environment. Brief description of drawings Figure 1 illustrates the cloud entity decoy security system as it relates to the cloud computing environment and in particular how the decoy cloud entities relate to the existing cloud entities and cloud platform in which they are deployed. Figure 2 is a flow diagram illustrating a process by which decoy cloud entities may be deployed and monitored in the cloud environment by a cloud entity decoy security system. Figure 3 is a hardware block diagram illustrating a cloud entity decoy security system. Detailed Description The embodiments presented in this document serve as examples of the numerous beneficial applications of the novel concepts introduced. The descriptions provided in this application's specification are not intended to restrict the scope of the various embodiments claimed. Aspects disclosed in the examples may be variously combined and omitted. Singular elements of the system may be understood as plural and vice-versa unless otherwise stated. Figure 1 is an example diagram of a cloud environment 100 for the purpose of describing the various embodiments. The cloud environment 100 represents the cloud resources of an organization. It may include any number of constituent public cloud platforms, 110-1 to 110-n, (hereafter 110) including public clouds such as, but not limited to, Amazon Web Services, Microsoft Azure, Google Cloud and so on. Each such cloud platform 110 may include multiple cloud entities, 120-1-1 through 120-1-r (hereafter 120). Cloud entities 120 as included in a cloud platform 110 are those virtual components, resources, devices, identities, systems, cloud-native constructs and the like configured within the cloud platform. Examples of cloud entities 120 for the methods, systems and descriptions herein include, without limitation, AWS S3 Buckets, AWS S3 Objects, AWS DynamoDB Tables, AWS Systems Manager Parameters, AWS Secrets Manager Secrets, AWS IAM Roles, and the like. Decoy cloud entities 130-1-1 through 130-1-s (hereafter 130) are cloud entities 120 which exist within the cloud platform 110 for the purpose of the detection of intrusions in a cloud platform. It may be understood that intrusions in the cloud platform include but are not limited to policy violations, credential theft, malware, spyware, lateral movement, command-and-control systems, exploitation of vulnerable applications, exploitation of vulnerable servers, including any combination thereof. Additionally decoy cloud entities 130 can serve to mitigate the risks caused by an intrusion by distracting the efforts of an intruder from the existing cloud entities 120. It will also be understood that decoy cloud entities 130 are themselves cloud entities 120. Cloud platforms 110 typically provide audit logging capabilities for monitoring activity within the cloud platform. Monitored activities can include, but are not limited to, activities performed by cloud entities 120, against cloud entities 120, pertaining to cloud entities 120, and the like. These cloud platform audit logging capabilities are exposed by the cloud platform 110 itself via a cloud platform audit logging service 150-1 through 150-n (hereafter 150). Examples of cloud platform audit logging services for the methods, systems and descriptions herein include, without limitation, AWS CloudTrail, AWS S3 Access Logs, AWS VPC Flow logs, Azure Monitor Logs, Google Cloud Audit Logs, and the like. It will be understood that the logging provided may include activity pertaining to decoy cloud entities 130 as these are themselves cloud entities 120. It will also be understood that some audit logging services permit logging and aggregation spanning whole organizations, across boundaries related to accounts, services and the like. Cloud platforms 110 typically provide a cloud platform control plane 140-1 through 140-n (hereafter 140). These control planes 140 can be used, for example and without limitation, to create, provision, deploy, control, configure, access, list, describe, interrogate, destroy, decommission and the like cloud entities 130. The cloud platform control plane 140 can comprise, without limitation, an API (application programming interface), an SDK (software development kit), a CLI (command line interface), an infrastructure-as-code provisioning tool, a CDK (cloud development kit), a web console, and the like, including a plurality thereof. In many cases the cloud platform control plane 140 can be used to configure the cloud platform audit logging service 150 itself. It may be understood that the cloud platform control plane 140 may also be used by other software, services and tooling, for instance, and without limitation, Terraform, Ansible and the like. In an embodiment, a cloud entity decoy security system 160 may be used to detect intrusions in a cloud environment 100 by deploying one or more decoy cloud entities 130 into any number of cloud platforms 110. The cloud entity decoy security system 160 can subsequently monitor the activity performed within the cloud environment 110 pertaining to decoy cloud entities 130 using the cloud platform audit logging service 150. In an embodiment, a cloud entity decoy security system 160 may use one or more cloud platform control planes 140 to identify existing cloud entities 120 within the cloud environment 100 for the purposes of determining the decoy cloud entities 130 which should be deployed and the properties thereof. By way of example, and without limitation, this determination may include factors such as the type of cloud entities discovered, their apparent naming conventions, the regions into which they are deployed, their configuration, policies applied to them, metrics and activity data, apparent sensitivity, apparent criticality, including any combination thereof. Alongside many other benefits, this allows the decoy cloud entities 130 to blend into the cloud environment 100 amongst the other cloud entities 120. In an embodiment, a cloud entity decoy security system 160 may, by use of the cloud platform control plane 140 or otherwise, enable, scope or configure the cloud platform audit logging service 150 to facilitate the monitoring of decoy cloud entities 130. For instance, and without limitation, a cloud entity decoy security system 160 such as AWS CloudTrail may where necessary be enabled, configured to enable logging of more event types (e.g. “data events”), and scoped to include events pertaining to decoy cloud entities 130. Byway of an example, the cloud entity decoy security system 160 may enable a higher level of granularity of logging for decoy cloud entities 130 in particular where to enable such a setting for cloud entities 120 more widely may otherwise be prohibitive in terms of data volumes or costs. In an embodiment, the cloud entity decoy security system 160 may facilitate the deployment of the decoy cloud entities 130 by generating an intermediary infrastructure-as-code representation of the intended decoy cloud entities 130. This representation can subsequently be used by other services, tools or software, or any combination thereof to deploy the decoy cloud entities 130. There are many advantages to doing so, including without limitation: enabling a static review of the generated infrastructure-as-code, maintaining conformity with other cloud entities 120 with respect to deployment methods and tools, and not requiring to grant the cloud entity decoy security system 160 itself permissions to deploy or change cloud entities 120 within the cloud environment. In an embodiment, infrastructure-as-code generation facility may use a static infrastructure-as-code module which references dynamic configuration (names, settings, variety of decoy cloud entities etc) from the cloud entity decoy security system 160. In this way the remit, scope and security model of the cloud entity decoy security system’s 160 capability to affect the cloud environment 100 may be statically verified by an organization while still permitting the dynamic creation, removal, configuration and the like of decoy cloud entities. This mitigates potential concerns around the possibility of the cloud entity decoy security system 160 inadvertently, maliciously or otherwise affecting other cloud entities 120 in the environment. In an embodiment, the cloud entity decoy security system 160 may automate the deployment of the decoy cloud entities 130. It may be understood that this may include, but is not limited to, the provisioning, deprovisioning, configuration changes and the like, including any combination thereof. There are many advantages to doing so, including without limitation, enabling the variety of decoy cloud entities 130 to change over time to better reflect the changing variety of cloud entities 120 deployed, and varying any associated creation data with the decoy cloud entities 130 so as to make them harder to distinguish from other cloud entities 120. In an embodiment, the cloud entity decoy security system 160 may classify activities with reference to, without limitation, the nature of the activity performed against the decoy cloud entities 130, the cloud principal which performed the activity, and the like, including combinations thereof. For instance, and without limitation, the cloud entity decoy security system may classify an event that corresponds to retrieving data from a decoy cloud entity 130 as a higher-severity activity than an event corresponding to inspecting metadata pertaining to a decoy cloud entity 130. The cloud entity decoy security system 160 may also automatically classify activity against decoy cloud entities as benign where the activity is performed by a cloud principal that is expected to access a plurality of cloud entities 120, including decoy cloud entities 130. For instance, cloud principals that are determined by the cloud entity decoy security system 160 to be associated with known systems or services responsible for, without limitation, the inventory, configuration management, or security of cloud entities 130 within a cloud environment 100. These features may be combined, for instance the cloud entity decoy security system 160 may classify activity by aforementioned cloud principals as benign unless the nature of the activity is anomalous with the expected activities performed by the cloud principal. For example if the cloud principal performs read activity against decoy cloud entities 130 where it is only expected to write; or reads data where it is only expected to read metadata. It will be understood that by using these and the myriad possible variations thereof the cloud entity decoy security system 160 may, among other benefits, reduce the rate of false positives in its alerting while retaining the capability to detect intrusions associated with those cloud principals which are to some extent expected to interact with decoy cloud entities 130. In an embodiment, the cloud entity decoy security system 160 may modify the identity and access management systems associated with the cloud platforms 110 and cloud environment 100, including modifying existing cloud entities 120 and decoy cloud entities 130 as required. This may be done, without limitation, at the time of deployment, on an ongoing or periodic basis or any combination thereof. It will be understood that many cloud platforms 110 do not permit access to cloud entities 120 by default. Modification of the identity and access management systems, including and without limitation the roles, policies, users, service principals, cloud entities 120, decoy cloud entities 130 and the like to permit a wider range of access to the decoy cloud entities 130 without necessarily permitting a wider range of access to existing cloud entities 120 is valuable. Permitting a cloud principal to access decoy cloud entities 130 where it otherwise wouldn’t have been able to increases the possibility of that cloud principal, in the case of compromise, performing activity against the decoy cloud entities 130 and thereby the compromise being detected by the cloud entity decoy security system 160. In an embodiment, the cloud entity decoy security system 160 may monitor the cloud platforms 110 to assert the continued existence of the decoy cloud entities 130 within the cloud environment. This can be achieved for instance via the cloud platform control plane 140 or the cloud platform audit logging service 150. As the decoy cloud entities 130 are a critical element of the capabilities of the cloud entity decoy security system 160, detecting their removal whether inadvertent, malicious or otherwise is valuable. In an embodiment, the cloud entity decoy security system 160 may itself periodically perform activities against the decoy cloud entities 130 to assert that it detects a corresponding record of that activity from the cloud platform audit logging service 150. This is helpful in controlling for and detecting a wide variety of failure scenarios, including but not limited to inadvertent or malicious changes to the configuration of the cloud platform audit logging service 150 that may impair the ability of the cloud entity decoy security system 160 to effectively monitor the decoy cloud entities 130. Figure 2 is an example flowchart for implementing a cloud entity decoy security system 160, according to an embodiment. At P210 the cloud entity decoy security system collects data about the cloud entities within a cloud environment. In one embodiment this may be achieved by making requests to the cloud platform control planes 140 of Figure 1. In an embodiment this may also be achieved by processing static or dynamically generated inventory data pertaining to the environment. In one embodiment, monitoring of activity within the cloud platform via the cloud platform audit logging service 150 of Figure 1 may also be used to passively detect the existence of resources referred to therein. The data collected about the cloud entities may be stored. At P220 the cloud entity decoy security system determines decoy cloud entities to deploy. As a first example, this determination could be based on the data collected about the existing cloud entities discovered in P210. For instance, the types of cloud entities discovered to exist (whether S3 Buckets, SecretsManager Secrets and the like) could inform the decision to deploy decoy cloud entities of the same type. The properties of the cloud entities could also be inspected so as to determine the properties of the decoy cloud entities - for example with respect to types of encryption used, the regions into which they are deployed, and other service-specific properties which can be configured for a cloud entity. Among many advantages, this could allow the decoy cloud entities to blend into the cloud environment more effectively, and maintain conformity with an organization’s policies with respect to how cloud entities should be configured within an environment. In an embodiment, the names of existing cloud entities may be used to determine the names of decoy cloud entities. For instance, conformity with respect to naming conventions (pascal-case, snake-case, camel-case and the like), common prefixes and suffixes and the like may be desirable. Words and names pertaining to products, projects, services, organizations, environments and the like may be discovered in the names of the cloud entities and used within the decoy cloud entity names to make them appear more plausible within the cloud environment. These and other elements may be combined, in determining the names of decoy cloud entities, with elements designed to make the decoy cloud entities look of particular interest to attackers - for instance names which imply sensitivity or confidentiality. In an embodiment, the choice of decoys may be subject to manual approval, revision or refinement by a person or team operating the cloud entity decoy security system. Data about the decoy cloud entities intended for deployment into the cloud environment may be stored. At P230 the decoy cloud entities are deployed into the cloud environment. In an embodiment, this may be achieved by making requests to the cloud platform control plane 140 of Figure 1. In one embodiment, the decoy cloud entity security system may facilitate the deployment of the decoy cloud entities by generating an intermediary infrastructure-as-code representation of the intended decoy cloud entities. This representation can subsequently be used by other services, tools or software, or any combination thereof to deploy the decoy cloud entities. At P240 the decoy cloud entity security system monitors activities performed in the cloud environment to detect activities performed against decoy cloud entities. In an embodiment, the cloud platform audit log service 150 of Figure 1 may be used to achieve this. This may, for example and without limitation, require the polling for and reading log files or objects, querying, stream-based processing, event-based processing, callbacks and the like depending on the capabilities and limitations of the underlying cloud platform audit log service. It may be necessary to inspect various properties of the underlying activity data obtained to correlate the activity as pertaining to a decoy cloud entity, whether by unique identifiers, names and the like. Activity may be further processed, for example and without limitation to group, aggregate or sessionise discovered activity, or in accordance with aforementioned techniques with respect to classification of the severity, or any combination thereof. It will be readily understood that this process description, including subsets of the stages described, may also, in an embodiment, run continuously or periodically and without necessarily requiring the ordering with respect to the stages to be maintained. Among many advantages, this may allow the decoy cloud entity security system to dynamically evolve the decoy cloud entities in use, as the underlying cloud environment changes and as the threat landscape changes. It will also be understood that the other techniques disclosed herein may be combined with this process description and that these may occur inline, asynchronously or otherwise with respect to the stages outlined. Figure 3 indicates a hardware block diagram of the architecture of the cloud entity decoy security system 160, as per an embodiment. The system comprises a bus 350 which connects a processor 310, memory 320, storage 330 and a network interface 340. The processor 310 is a circuit capable of performing instructions and may be a Central Processing Unit (CPU), a microcontroller, a microprocessor or the like. Memory 320 may be volatile or non-volatile, including random access memory, flash memory, read-only memory and the like. Storage 330 may be components and recording media such as a hard disk drive, solid state drive, optical disks and the like. The network interface 340 connects the cloud entity decoy security system to a computer network whether by cables or wirelessly or other means, for instance using ethernet or wi-fi. The system and the various elements thereof may be virtualized. The processor performs instructions which implement the methods of the various embodiments in this disclosure. These instructions may be stored in memory 320, storage 330 or both and in various formats such as binaries, source code, intermediate languages and the like. The system may make use of the network interface 340 as required to achieve connectivity to the cloud environment to realize the various methods as well as for other purposes. The system may make use of the storage 330 for storing instruction code, as well as data pertaining to the cloud environments and their various cloud entities and decoy cloud entities as required, as well as for other purposes. There are many possible computer architectures and it is important to note that the description provided in Figure 3 is an example. Alternative computer architectures that are configured to implement the methods of the present disclosure are also considered to be cloud entity decoy security systems 160 as per this disclosure.

Claims

24Claims1. A computer-implemented method for detecting intrusion in a cloud environment, wherein the cloud environment hosts cloud entities in a cloud platform, the method comprising: deploying one or more decoy cloud entities into the cloud platform, wherein the one or more decoy cloud entities are of the same type as the entities hosted in the cloud platform; andmonitoring activity pertaining to any decoy cloud entities using a cloud environment audit logging system.

2. The computer-implemented method of claim 1, further comprising collecting data about existing cloud entities deployed in the cloud environment to inform the choice of decoy cloud entities for deployment.

3. The computer-implemented method of any preceding claim, further comprising using infrastructure-as-code to facilitate the deployment of the decoy cloud entities.

4. The computer-implemented method of any preceding claim, further comprisingdeploying the decoy cloud entities in an automated manner.

5. The computer-implemented method of any preceding claim, further comprisingclassifying the monitored activity pertaining to the decoy cloud entities with reference to at least one of: the nature of the monitored activity pertaining to the decoy cloud entities; and a cloud principal which performed the monitored activity.

6. The computer-implemented method of any preceding claim, further comprising modifying a configuration of the cloud environment audit logging system to enable the logging of more information pertaining to the decoy cloud entities.

7. The computer-implemented method of any preceding claim, further comprising modifying an identity and access management system within the cloud environment to permit access by cloud principals to the decoy cloud entities.

8. The computer-implemented method of any preceding claim, further comprising monitoring the cloud decoy entities to ensure they remain deployed within the cloud environment.08 08 249. The computer-implemented method of any preceding claim, further comprising performing a test activity against the cloud decoy entities to verify that activity monitoring of decoy cloud entities is working correctly.

10. The computer-implemented method of any preceding claim, wherein the cloud environment includes a plurality of cloud platforms.

11. A system for detecting intrusion in a cloud environment, wherein the cloud environment hosts cloud entities in a cloud platform, the system comprising one or more processors configured to:deploy one or more decoy cloud entities into the cloud platform, wherein the one or more decoy cloud entities are of the same type as the entities hosted in the cloud platform; andmonitor activity against any decoy cloud entities using a cloud environment audit logging system.

12. The system of claim 11, wherein the system is further configured to collect data about existing cloud entities deployed in the cloud environment to inform the choice of decoy cloud entities for deployment.

13. The system of any of claims 11 to 12, wherein the system is further configured to use infrastructure-as-code to facilitate the deployment of the decoy cloud entities.

14. The system of any of claims 11 to 13, wherein the system is further configured to automate the deployment of the decoy cloud entities.

15. The system of any of claims 11 to 14, wherein the system is further configured to classify the monitored activity against the decoy cloud entities with reference to at least one of: the nature of the monitored activity performed against the decoy; and a cloud principal which performed the monitored activity.

16. The system of any of claims 11 to 15, wherein the system is further configured to modify a configuration of the cloud environment audit logging system to enable the logging of more information pertaining to the decoy cloud entities.

17. The system of any of claims 11 to 16, wherein the system is further configured to modify an identity and access management system within the cloud environment to permit access by cloud principals to the decoy cloud entities.

18. The system of any of claims 11 to 17, wherein the system is further configured to monitor the cloud decoy entities to ensure they remain deployed within the cloud environment.

19. The system any of claims 11 to 18, wherein the system is further configured to perform test activity against the cloud decoy entities to verify that activity monitoring of decoy cloud entities is working correctly.

20. The system of any of claims 11 to 19, wherein the cloud environment includes a pluralityof cloud computing platforms.08 08 24

Images