As businesses look to clouds for faster, more flexible growth, they confront significant challenges from a legacy application base that has varying levels of cloud suitability. It is therefore worth examining how security and compliance requirements can impact choice of cloud or architecture strategies within a cloud.
Maintaining privacy for data that must be protected for business or regulatory reasons is a substantial concern in cloud migration, public or private. Security and compliance organisations vary in their acceptance of shared environments, even within a single organisation.
Public clouds particularly can highlight weaknesses in data security practices. As firms consider moving applications into a public cloud it is important to be sure basic policies and procedures are in place. Data classification is a core practice that enables risk-aware protection of data as it moves to the cloud. Having a formal classification system defining what data is public, company confidential, or eyes only is the first step to being able to track compliance in an explicit way. Data life cycle management, decommissioning and disposal in particular, gain increased importance in public cloud. Encryption and key management have new wrinkles when infrastructure is owned by outside parties.
In addition to basic security concerns, legal regulatory issues for data management must also be considered. Distributing data in any cloud environment, public or private, can trip over legal restrictions in global enterprises. It is important to establish what’s permissible in the jurisdictions an application is operating in, and preventing cross-border flows of data is sometimes required. Similarly, for international applications, it’s important to be aware of any requirements for electronic discovery, integrity, and data custody in the countries where data exists. Firms considering moving applications into the public cloud should require their providers to detail the legal requests the provider will respond to and the manner in which they will respond.
In the US, domestic regulatory concerns can also come into play with shared service environments. They can vary depending on the particular standards being enforced. Two common U.S. examples are information protected by the Health Insurance Portability and Accountability Act (HIPAA) and data segregation required to maintain credit card privacy: the Payment Card Industry Data Security Standards (PCI-DSS).
HIPAA’s primary focus is preserving administrative security and integrity controls around protected data. Core areas of concern are access control, audit points, encryption of data at rest and in flight. The implementation of each of these varies based on type of cloud model implemented. Virtualisation introduces additional control points and risks. Audit logs should be continuously reviewed for unwarranted access in any shared service environment.
There are vendor solutions that can help: role-based access control ensuring administrators have the least privilege possible for accomplishing their tasks, cloud volume encryption methods that render keys unreadable to public cloud service providers. But planning and awareness are imperative to implementing protection that meets compliance obligations without being operationally burdensome.
While HIPAA emphasises only administrative data access, PCI-DSS adds the burden of technical segregation of protected data. In virtualised, shared environments, this can lead to difficult tradeoffs and increased diligence around audit readiness.
A virtual machine that contains data that is in scope for PCI-DSS compliance renders the hosting hypervisor in scope as well as any virtual machines hosted by the same hypervisor. That means all the shared VMs must be treated with the same strict security management as those with PCI-DSS protected data, even if no PCI-DSS protected data exists on the shared VMs. “Compensating controls” and additional proofs may make logical separation compliant, but there is no one-size-fits-all method to meet PCI-DSS requirements. Specific controls and procedures will depend on how virtualisation is used and implemented.
If, in addition to sharing hardware inside an organisation, you are also sharing that hardware with other organisations in a public cloud, there is additional complexity. Multi-tenancy, nested service-provider relationships, converged administrative responsibilities, can all expand compliance requirements in undesirable ways. Many public clouds, including Google Compute, Amazon Web Services, and Microsoft Azure, market themselves as PCI-DSS compliant, but it is important to note that the final burden of compliance for an application falls to the client organisation. Specific responsibilities and proofs for compliance should be carefully spelled out when contracting for cloud services requiring PCI-DSS compliance.
Security and compliance requirements may be met in cloud environments, but special attention and close cooperation with a firm’s risk management organisation is called for.
In summary, while moving applications into a private or public cloud environment may present an opportunity to save costs or improve operations, applications vary in their requirements for data security, privacy and management. The common concerns presented here can add complexity but are manageable with proper care around planning, design, and execution. Performing detailed application analysis for cloud security requirements can create evidence-based guidance on migration costs and requirements rather than letting panic-stricken hand-waving dictate decisions around whether and what to migrate.
[Source:- Cloudcomputing]
