The Official (ISC)2 CCSP CBK Reference. Leslie Fife

Чтение книги онлайн.

СКАЧАТЬ safer for a customer's information and processes. However, there remains some challenges with cloud computing, including portability, interoperability, and vendor lock-in.

      These challenges can be lessened through the use of a vendor management process to ensure standard capabilities, clearly identifying the responsibilities or each party and the development of SLAs as appropriate. For complex or expensive systems, the RFP process can be utilized to clearly state customer requirements. The security requirements should be part of the requirements specified in the RFP and can be part of the process of choosing a vendor. A vendor that cannot meet the customer's security needs can be eliminated early on.

      Portability

      One-time movement is when a customer moves to a cloud platform, with no intention of moving it again. This is not common. In a modern environment, movement to and from the cloud as well as between cloud services and CSPs is much more common. These movements are not simply a forklift operation where you pick up some on-premises solution and data and drop it into a cloud account. Each CSP uses different tools and templates. So, a move from one CSP to another requires mapping to the other with the associated data cleanup. Moving from your own infrastructure to a CSP has the same challenge.

      Frequent movement between CSPs and between a CSP and your own infrastructure is significantly more difficult, and data can be lost or modified in the process, violating availability and integrity rules. Portability means that the movement between environments is possible. Portable movement will move services and data seamlessly and may be automated.

      The movement of data between software products is not a new issue. It can be complicated in the cloud by the need to continue paying for the old service while porting to the new one. This puts time pressure on the porting.

      Interoperability

      With customers using a variety of cloud services, often from different vendors, interoperability is an important consideration. In addition, some situations may require a private cloud sharing data with an on-premises solution. The ability to share data between tools and cloud environments and between clouds and corporate infrastructure is important. One issue is that the security tools and control sets differ between CSPs. A gap in security may result. Careful planning is essential, and the services of a cloud broker may also be warranted.

      One way to improve the situation is through application programming interfaces (APIs). If properly designed, the API can bridge the security gap between services and allow the sharing of data and processes across multiple platforms. For example, if a SaaS tool is used to build a data inventory and supports the corporate data/system classification scheme, an API could be built to securely share that information with the governance, risk management, and compliance (GRC) or system inventory tool. This creates a single source for data, sharing it with relevant systems, and removes the potential of multiple data classification in different systems.

      Vendor Lock-in

      Solving the interoperability and portability challenges will go a long way toward ending vendor lock-in. This occurs when a customer is tied to a specific CSP and moving would incur significant costs including financial, technical, and legal. Vendor lock-in remains a significant concern with cloud computing. Continued advances in virtualization, improvements in portability and interoperability, and a careful design within a reference architecture have decreased this issue.

      An additional concern is the use of CSP-specific services. If these are used to build capabilities, moving to a new CSP also impacts this additional capability. This is similar to using nonstandard features of a compiler in the development process. It locks you into that development environment.

      One example is the use of AWS CloudTrail. CloudTrail allows auditing of your AWS account in support of governance, risk management, and compliance. If the decision is made to move away from AWS, the GRC functionality will have to be rebuilt with new services, either with the new CSP or with another vendor.

      With additional improvements and careful architecture, vendor lock-in should become an issue in the past. Until then, the security challenges of cloud computing in general, and portability and interoperability in particular, remain.

      Security Considerations for Different Cloud Categories

In a cloud environment, security responsibilities are shared between the service provider and the customer. In the SaaS model, the customer has the least responsibility, and in the IaaS model, the customer has the most responsibility. In a PaaS, the responsibility is shared more equally.

      The Shared Responsibility Model for cloud services is commonly presented by the major vendors, which are all similar. There is an architecture stack. Some items in the stack are the responsibility of the CSP, and some are the responsibility of the customer. In between, there is an area of varied responsibility. At times, this middle area is the responsibility of the CSP and sometimes of the customer and sometimes both. It is important for the customer to know their responsibilities, especially in this middle region.

      A typical architecture stack looks like this:

       Data

       APIs

       Applications/solutions

       Middleware

       Operating systems

       Virtualization (VMs, virtual local area networks)

       Hypervisors

       Compute and memory

       Data storage

       Networks

       Physical facilities/data centers

      It is generally understood that the CSP is responsible for the last five items on the list in all delivery models. However, where the line between customer and CSP exists varies beyond that.

      The exact split and layer names vary by vendor, but the general principle remains the same. Both the CSP and the customer have some individual security responsibilities, and along the line where these meet, each may have some security responsibilities. The line for each delivery model is explained in the following sections.

      Software as a Service

      From a security standpoint, you have limited security options with a SaaS solution. Most of the security options are provided by the SaaS provider. The SaaS provider is responsible for the security of the infrastructure, operating system, application, networking, and storage of the information on their service.

      In the Shared Responsibility Model, the customer is responsible for their data and may have some responsibility for the APIs. All other layers are the responsibility of the CSP.

The user of a SaaS solution has responsibilities as well. When a service is subscribed to by an organization or an individual, it is important to understand the security policies and procedures of the SaaS provider to the extent possible. In addition, the user determines how information is transferred to the SaaS provider and can do so securely through end-to-end encryption. The SaaS user is responsible for determining how the data is shared. Finally, the user can provide access security through proper use of login credentials, secure passwords, and СКАЧАТЬ