Storage Provisioning and Networking - Deploying and Managing a Cloud Infrastructure - page 281

Here are some solutions to these cloud security problems:
■ Public key infrastructure (PKI), cryptography, and expiring hashcodes
■ Policy-driven data storage architecture and API support for ID-based data object/item
access mechanisms
■ Anonymization as a tool for enabling and ensuring privacy
■ Ensuring the latest security patches and active investigation of any possible threats
■ Active surveillance of control staff and use of client-specific PKI-based encryption keys
to restrict and control staff access to data.
These issues and their solutions have been mentioned in detailed research works.
With greater ease of control for multiple cloud service providers and a plethora of data
already in their systems, the risk of data being disclosed either accidentally or deliberately
becomes immense. Companies like Amazon deploy country-wide local infrastructures
and provide customers with the ability to select Availability Zones. Moreover, articulat-
ing clear policy and legislation could help describe how the data of individual cloud users
would be accessed and used.
However, there are other architectural and maintenance issues that need to be taken care
of. Outsourcing data storage to a cloud storage provider increases the attack surface area.
In a cloud storage platform, data is (automatically) replicated and moved frequently (auto-
matic load balancing) across the entire cloud infrastructure. Though it supports multiple
benefits, it does however bring about the risk of unauthorized data recovery (drive reuse,
reallocation of storage space, disposal of old hardware, etc.).
Risk of unauthorized access to data can be mitigated by the use of cryptographic techniques
and encryption standards such as FIPS 140-2. FIPS Publication 140-2 is a U.S. government
computer security standard that provides guidelines for cryptographic modules. It describes
four levels of security, from Level 1 to Level 4, without describing what level of security is
required by a particular application:
Level 1 The lowest level of security. Basic requirements for a cryptographic module are speci-
fied without any physical security mechanisms. An example would be PC encryption board.
Level 2 Improves upon Level 1 and requires features that show evidence of tampering
with a cryptographic module. This includes tamper-evident coatings and pick-resident
locks and doors that prevent unauthorized access to a facility.
Level 3 In addition to tamper-evident security mechanisms, Level 3 is proactive and puts in
places mechanisms to prevent an intruder from gaining access to the cryptographic module.
Level 3 is intended to have detection and response to intrusion attempts at physical access
and use/modification of cryptographic module. Examples include strong enclosures and tam-
per detection/response circuitry.
Level 4 This is the highest level of security, with physical security providing a complete
envelope of protection around the cryptographic module with the intent to detect and
respond to all unauthorized attempts at physical access.