Download Best Practices ® Data Protection in the Cloud

®
®
®
®
®
IBM DB2 for Linux , UNIX , and Windows
Best Practices
Data Protection in the Cloud
Walid Rjaibi
Senior Technical Staff Member
DB2 Security Architect
Mark Wilding
Senior Technical Staff Member
DB2 Cloud Computing Architect
Last updated: February 2011
®
Data Protection in the Cloud
Page 2
Executive summary ............................................................................................. 3
Introduction .......................................................................................................... 4
The IBM Data Server Security Blueprint .......................................................... 6
Security outside the database....................................................................... 6
Developing and rolling out a security plan ............................................... 7
Threats and countermeasures ............................................................................ 8
Threats ............................................................................................................. 8
Countermeasures ........................................................................................... 9
Additional cloud-specific security challenges ............................................... 10
Initial provisioning ...................................................................................... 10
State of the virtual machine ........................................................................ 10
Virtual machine parameters ....................................................................... 10
Security of other components of the cloud environment....................... 10
Monitoring privileged uses ........................................................................ 11
Auditing DBA activities................................................................................................11
Controlling when DBADM authority can be acquired.............................................12
Restricting DBA access to table data ...........................................................................13
Data segregation........................................................................................... 13
Conclusion .......................................................................................................... 15
Further reading................................................................................................... 16
Contributors.................................................................................................. 16
Notices ................................................................................................................. 17
Trademarks ................................................................................................... 18
Data Protection in the Cloud
Page 3
Executive summary
Public cloud computing is an emerging computing technology that uses the Internet and
central remote servers to host data and applications. It allows consumers and businesses
to use applications without installing them locally and access information from any
computer with Internet access. Cloud computing allows for much more efficient
computing by using centralized storage, memory, and processing. The benefits of cloud
computing are clear, and so is the need to develop appropriate security for cloud
implementations.
This paper is important for all database administrators (DBAs) who are setting up or
managing databases in a public cloud environment. The details and best practices in this
paper will help DBAs protect themselves and their companies from security leaks and
exposures by applying a standard, high-grade security policy to all databases that are
hosted in a public cloud.
Data Protection in the Cloud
Page 4
Introduction
Cloud computing shifts much of the control over data and operations from client
organizations to their cloud providers, much in the same way that organizations entrust
much of their IT operations to outsourcing companies. Even basic database
administration tasks, such as configuring authentication and authorization, can become
the responsibility of the cloud service provider. This makes the issue of monitoring
privileged users vitally important in a cloud computing environment.
Cloud computing also has new and cloud-specific security risks. For example,
standardization is one of the many benefits of cloud computing. Through the use of the
same virtualized hardware and the same software, the level of complexity is greatly
reduced. Fewer problems are encountered and automation becomes much more feasible
because of the reduced complexity. Standardization with a good security policy increases
the level of security because the same high-standard security policy is applied to all
software. Standardization with no security policy or a poor security policy greatly
reduces security because the same exposures apply to all of the standardized systems or
software.
Moreover, the massive sharing of infrastructure in cloud computing creates a significant
difference between cloud security and security in more traditional IT environments.
Users spanning different corporations and trust levels often interact with the same set of
computing resources. This requires implementing data segregation models that ensure
that data from different organizations remains logically segregated even if it is stored on
the same computing resources.
Securing data in a public cloud requires a holistic and layered approach that considers
the broad range of threats that could affect that data. This approach is commonly referred
to as defense in depth and requires a security by design approach. That approach espouses
security as part of the core design of database environments and the supporting
infrastructures and business practices around these environments. Multiple layers of
security work together to meet the three ultimate objectives of security, commonly
known as the CIA triad: confidentiality, integrity, and availability.
The information in this paper is organized into three main sections:
•
“The IBM Data Server Security Blueprint” reviews the IBM Data Server Security
Blueprint. The blueprint first positions data server security within the bigger
enterprise security picture. This section also describes steps to develop and roll out a
security plan.
•
“Threats and countermeasures” describes the most common threats that affect a data
server, whether it is deployed in a traditional environment or a cloud computing
environment. The section then recommends a set of countermeasures.
Data Protection in the Cloud
•
Page 5
“Additional cloud-specific security challenges” examines the additional challenges
posed to data security in a cloud environment, in particular, the need for privilegeduser monitoring and data segregation.
Data Protection in the Cloud
Page 6
The IBM Data Server Security Blueprint
Security outside the database
Securing data requires a holistic and layered approach that considers the broad range of
threats that could affect that data. Although the primary focus of this paper is on
database security, it is vitally important to position database security within the overall
enterprise security picture. That is, to fully protect data, an organization must pay
attention to not only data server security but also to security outside the database. Figure
1 shows the primary layers of security and types of threats that you must take into
account when building a data security plan:.
Application Security
Data Server Security
Business Controls
Identity Management
Data Threats
Configuration Threats
Audit Threats
Executable Threats
Host Security
Network Security
Physical Security
Figure 1. The IBM Data Server Security Blueprint
Data Protection in the Cloud
Page 7
The security layers that need to be considered in addition to data server security, and
their associated implementation tasks, are as follows:
•
Physical security. Implement effective badge access to control who can
physically gain access to the computer or computers hosting the data server.
•
Network security. Use firewalls, virtual private networks (VPNs), secure routers,
intrusion detection systems, network sniffers, and other network security
techniques.
•
Host security. Secure the operating system, use virus and malware protection,
implement web browser security, monitor and log activities of system users, and
use other host security techniques.
•
Application security: Secure applications that are running on your system. For
example, one well-known threat is SQL injection, whereby a poorly developed
application can be forced to run unintended SQL statements. This vulnerability
exists only in dynamic SQL applications that do not validate any user input that
is used to construct dynamic SQL statements. There are at least two options that
you can use to handle the SQL injection problem. First, by using IBM pureQuery,
you can restrict access to only captured SQL statements. If the target database is a
DB2 database, you can bind the captured SQL statements into packages for static
execution to improve security. Second, by using an application scanning tool
such as the IBM Rational AppScan® tool, you can detect and then eliminate
potential vulnerabilities that can be exploited through SQL injection attacks.
•
Identity management. Use reliable systems and methods for identifying and
authenticating enterprise users.
•
Business controls. Implement rules, processes. and practices to govern access to
assets and the use and management of data.
Developing and rolling out a security plan
At a minimum, rolling out an effective data security plan always includes the following
seven steps:
1.
Data classification. Understand and classify your data. Which parts of the data
are most important, and which are less so? What is the value of the data to your
organization? What is the cost if the data is compromised?
2.
User classification. Determine who is allowed to access the data. What are the
minimum privileges that employees need to do their jobs? How long must each
employee have the privilege? At this stage, the two security principles of least
privilege and separation of duties are vital.
3.
Threat identification. Understand the threats that you are facing, the risk of each
threat being manifested, and the cost of controls to protect against such threats.
Data Protection in the Cloud
Page 8
Enumerate and categorize threats in a logical fashion. Decide which threats
apply to your environment and which ones, if any, do not. Try to anticipate and
be generally prepared for unforeseen threats.
4.
Implementation of countermeasures and preventative measures. Implement
effective measures to address every threat that you deem important in your
environment. It makes little sense to buy a titanium front door to secure your
house when the side door is made of wood. In most cases, addressing threats
involves multiple layers—remember defense in depth. Lastly, these solutions
must also be easy to deploy and manage. Otherwise, no one will use them, or
worse, people will think that the solutions are applied correctly when they are
not.
5.
Testing. Validate that your security mechanisms are in place and working
correctly. In many ways, this can be the hardest step: not only must your system
be secure but there must also be a way to continuously monitor and validate that
it is so. You must perform testing in a variety of ways, including both
vulnerability and penetration testing, to determine the effectiveness of applied
countermeasures and the effect of a breach.
6.
Auditing. Audit and monitor your system to provide a historical trail of data
access and to detect any attempts to improperly access the data. Otherwise, as
happens all too frequently, no one can detect that a breach occurred or
something else went wrong. For example, you must audit access to any data that
you classified as sensitive in the data classification step. You might also want to
audit the actions of certain users, groups, or roles, as identified in the user
classification step. Your audit policy is driven by business controls and any
corporate audit policy that might exist. Effective data security is an ongoing
process, and auditing is the key feedback method in this process.
7.
Maintenance. Keep the system maintained and secure, including the installation
of all required patches and updates. Effective security is not a point-in-time
exercise. You must keep everything up to date as you identify new threats or add
new users or as your data environment changes, as inevitably it will. Integrate
security maintenance in your standard operational practices, and task people
with keeping it up to date as an important part of their core everyday
responsibilities.
Threats and countermeasures
Threats
You need to know what type of threats you are up against. Data server security threats
can be divided into four broad categories: data threats, configuration threats, audit
threats, and executable threats.
Data Protection in the Cloud
Page 9
Data threats. These are mechanisms whereby data can be accessed by users or processes
that are not authorized to access such data. This is by far the largest category of threats
and is usually the first that comes to mind. These threats can be aimed directly at the
tables in the database or can be made more indirectly, such as by looking at the log files
or at the table space files on the operating system.
Configuration threats. These are mechanisms whereby the database or database
manager configuration files can be tampered with. Because configuration files control
critical aspects of your data server—such as how and where authentication is
performed—it is critical that you protect the database manager configuration files as
securely as the data itself.
Audit threats. These are mechanisms whereby the audit configuration, audit logs, or
archive logs can be tampered with. In many cases, audit records are the only way to
determine what happened and the only evidence for detecting misuse. Therefore, it is
critical that audit records be able to withstand tampering.
Executable threats. These are mechanisms whereby database manager executable files
can be tampered with. These threats include executable spoofing, denial-of-service
attacks, privilege escalation, and Trojan horse attacks.
Countermeasures
If you are managing your own database in the public cloud, the countermeasures in this
section will help you to set a high-grade security policy to protect your data. These
countermeasures are meant to address the threat categories in the previous section and
are the standard practice for all of your databases in the public cloud. The
countermeasures represent security features built into the database itself or external tools
that complement database security, such as the IBM Database Encryption Expert (DEE),
IBM Optim™ Data Masking, and IBM Guardium® tools. If your database is hosted for
you on the public cloud, be sure to quiz your cloud provider about its security policies.
The countermeasures are as follows:
•
Using authentication and authorization methods that adhere to the principles of
least privilege and separation of duties. That is, permit users to do only what
they must do, and vest database administration and security administration into
two non-overlapping roles.
•
Setting appropriate privileges and using other access control methods, such as
label-based access control (LBAC) on sensitive data.
•
Auditing user access, particularly to sensitive data, and actions by the DBA.
•
Revoking the data access authority from the DBA if the DBA has no business
need to access data.
•
Limiting access that is given to PUBLIC.
Data Protection in the Cloud
Page 10
•
Remembering to protect staging tables and materialized query tables.
•
Using DB2 trusted contexts technology in multitier environments to address the
loss of end user identity problem.
•
Encrypting data at rest—both online data and data in backup files.
•
Encrypting data in transit by using SSL.
•
Using operating-system controls to prevent operating-system administrators
from gaining too much access.
•
Ensuring that the database server environment is correctly configured, that is, by
using registry variables, database manager configuration parameters, and
database configuration parameters. An automated tool such as the IBM
Guardium vulnerability and configuration assessment tool is of great value for
this task.
Additional cloud-specific security challenges
Initial provisioning
Due to the standardization of public clouds, you will likely base your DB2 database on
top of a standard virtual machine image. Be sure to check whether during initial
provisioning, a default (standardized) password is used and users can use ssh or telnet to
access the system without a public key.
State of the virtual machine
After provisioning, there might be a number of daemons or services running on the
virtual machine. These daemons might give unwanted access to the Internet. Make sure
that the standard virtual machine image does not run any unwanted daemons or services
when it starts, or better yet, remove anything that you do not need.
Virtual machine parameters
This is a first line of defense for any system on the public Internet. Make sure that the
TCP/IP traffic (and UDP, ICMP, and so on) is restricted to what is necessary for the
functioning of the virtual machine. For example, block all traffic to the database port
except for what the applications need. Also, ideally, collocate the applications, and block
access to the database by all Internet traffic.
Security of other components of the cloud environment
As explained in “Security outside the database”, you must pay attention to not only
database security but also to security outside the database (see Figure 1. The IBM Data
Server Security Blueprint). This is also true in a cloud computing environment. Although
Data Protection in the Cloud
Page 11
security outside the database is not the subject of this paper, the key challenges that are
posed by cloud computing for each of the security layers in Figure 1 are as follows:
•
Physical security. The cloud’s infrastructure, including servers, routers, storage
devices, power supplies, and other components that support operations must be
physically secure. Safeguards include the adequate control and monitoring of
physical access using biometric access control measures and closed circuit
television (CCTV) monitoring. Providers must clearly explain how they manage
physical access to the servers that host client workloads and data.
•
Network and host security. As data moves farther from their control, clients
expect capabilities such as intrusion detection and prevention systems to be built
into the environment.
•
Application security. All of the typical application security requirements apply
to applications in the cloud, but the security requirements also apply to the
images that host those applications. The cloud provider must follow and support
a secure development process. In addition, cloud users demand support for
image provenance, licensing, and usage control. Suspension and destruction of
images must be performed carefully, ensuring that sensitive data in those images
is not exposed.
•
Identity management. Cloud environments introduce a new tier of privileged
users: administrators working for the cloud provider. Monitoring privileged
users, including logging their activities, becomes an important requirement. This
monitoring must include both physical monitoring and background checking.
Monitoring privileged uses
Cloud computing shifts much of the control over data and operations from client
organizations to their cloud providers, much in the same way that organizations entrust
much of their IT operations to outsourcing companies. Even basic database
administration tasks, such as configuring authentication and authorization, can become
the responsibility of the cloud service provider. This makes the monitoring privileged
users vitally important in a cloud computing environment.
DB2 software provides a rich set of security capabilities that cloud computing providers
can rely upon to audit and control the activities that DBAs can perform.
Auditing DBA activities
To audit the activities performed by the DBA, the security administrator must create an
audit policy that captures events of interest, such as object maintenance. The security
administrator must also associate that audit policy with database administrator
(DBADM) authority.
Data Protection in the Cloud
Page 12
Example
The following SQL statement creates an audit policy that captures information about
object maintenance events, such as creating a table and creating an index:
CREATE AUDIT POLICY dbadminPolicy
CATEGORIES OBJMAINT
STATUS BOTH ERROR TYPE AUDIT
The following SQL statement audits the activities of any user who holds DBADM
authority, according to the previously created policy:
AUDIT DBADM USING POLICY dbadminPolicy
Controlling when DBADM authority can be acquired
The security administrator can control when DBADM authority can be acquired by not
directly granting that authority to the user. Instead, the security administrator can grant
DBADM authority to a trusted context. The user has access to that authority only when
working within the confines of that trusted context.
Example
The following SQL statement creates a database role called DBA:
CREATE ROLE DBA
The following SQL statement grants DBADM authority to the DBA role:
GRANT DBADM ON DATABASE TO ROLE DBA
The following SQL statement creates a trusted context object for user Miller that confers
the DBA role:
CREATE TRUSTED CONTEXT CTX1
BASED UPON CONNECTION
Data Protection in the Cloud
Page 13
USING SYSTEM AUTHID MILLER
ATTRIBUTES (ADDRESS 9.26.52.193)
DEFAULT ROLE DBA
If user Miller connects to the database from an IP address other than 9.26.52.193, Miller
does not acquire the DBA role. Miller can acquire this role only by connecting from IP
address 9.26.52.193.
Restricting DBA access to table data
To prevent DBAs from accessing table data, the security administrator can choose
between two options:
•
To prevent access to data in all tables, the security administrator can revoke
DATAACCESS authority from the DBA. Alternatively, the security administrator
could grant DBADM authority to the DBA and specify the WITHOUT
DATAACCESS option. DATAACCESS authority is granted by default with the
DBADM authority, unless specified otherwise.
•
To prevent access to data in one particular table, the security administrator can
follow these steps:
1.
Assign a security label to every column in the table.
2.
Grant that security label to a role.
3.
Grant that role to all users who have a legitimate need to access the table.
No user, regardless of authority, can access data in that table unless the
user is a member of that role.
The security administrator must also consider how to prevent access to table data from
outside the scope of the database system. For example, a DBA with sufficient operatingsystem privileges could access the operating-system files where table data is stored. The
DB2 software offers two options:
•
Use the IBM DEE solution to add a layer of file access control that the DBA
cannot bypass..
•
Use the IBM DEE solution to encrypt the database files on disk so that data
confidentiality is assured.
Data segregation
The massive sharing of infrastructure in cloud computing creates a significant difference
between cloud security and security in more traditional IT environments. Users spanning
Data Protection in the Cloud
Page 14
different corporations and trust levels often interact with the same set of computing
resources. This requires implementing data segregation models that ensure that data
from different organizations remains logically segregated even if it is stored on the same
computing resources.
DB2 software provides four models that a cloud computing provider can rely upon to
segregate data from different clients (tenants):
•
Instance per tenant. A full DB2 instance is allocated to hold tenant data. This
model provides full isolation of tenant data and allows the cloud computing
provider to tailor authentication settings to the specific needs of the tenant. For
example, a particular tenant might want user authentication to be done using a
particular authentication mechanism. Although the instance per tenant model is
by far the most flexible data segregation model, it is also the most costly.
•
Database per tenant. A full database is allocated to hold tenant data within one
DB2 instance. This model provides good isolation of tenant data, but all tenants
must use the same authentication settings because authentication is configured at
the DB2 instance level. Authorization, however, is configured at the database
level, and authorization can be different for each tenant. A tenant can be given
CONNECT privilege only to the database that contains its own data, which still
provides good isolation of tenant data.
•
Schema per tenant. A full schema is allocated to hold tenant data within one
database within one DB2 instance. In this model, different tenant data is
collocated within the same database, and different tenants can connect to the
same database. The security administrator must follow the least privilege
security principle to make sure that a tenant has privileges that give it access
only to its own schema.
•
Row per tenant. In this model, different tenants share the same database table.
The security administrator must implement LBAC on that table to provide
logical tenant data separation.
Another element of great importance that a cloud provider must take into account when
choosing a data segregation option is auditing. Almost all government regulations and
industry standards require an organization to set up an audit policy so that database
users can be held accountable for their actions. In the event of an incident that relates to a
particular tenant, forensic investigators will want to look at the DB2 audit logs to try to
figure what caused that incident. The instance per tenant model provides full segregation
of audit logs from different tenants. The database per tenant model provides full
segregation of database-specific audit logs, but the instance-level audit log is shared by
all tenants. The schema per tenant and row per tenant models provide no isolation
because both the instance and database audit logs are shared by all tenants. The cloud
computing provider must discuss these auditing aspects with you when selecting a data
segregation model.
Data Protection in the Cloud
Page 15
Conclusion
DB2 software has a rich set of security features that you can use to protect databases on
the public cloud. You can use these features as part of your high-grade cloud security
policy.
The low-cost and convenience of a public cloud, coupled with the DB2 software security
features, provide the best of two worlds. You can reduce costs by moving data to a
publicly hosted environment and yet maintain a high level of security.
Data Protection in the Cloud
Page 16
Further reading
•
DB2 Best Practices: http://www.ibm.com/developerworks/db2/bestpractices/
•
DB2 Trusted Contexts: Making Security and Compliance Easier. IDUG Solutions
Journal, Volume 14, Number 2, 2007
•
DB2 Best Practices: Data Server Security:
http://www.ibm.com/developerworks/data/bestpractices/security/
Contributors
Steven Bade
Senior Technical Staff Member
IBM Security Strategy
Serge Boivin
Senior writer
DB2 Information Development
Data Protection in the Cloud
Page 17
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other
countries. Consult your local IBM representative for information on the products and services
currently available in your area. Any reference to an IBM product, program, or service is not
intended to state or imply that only that IBM product, program, or service may be used. Any
functionally equivalent product, program, or service that does not infringe any IBM
intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in
this document. The furnishing of this document does not grant you any license to these
patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where
such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES
CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do
not allow disclaimer of express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
Without limiting the above disclaimers, IBM provides no representations or warranties
regarding the accuracy, reliability or serviceability of any information or recommendations
provided in this publication, or with respect to any results that may be obtained by the use of
the information or observance of any recommendations provided herein. The information
contained in this document has not been submitted to any formal IBM test and is distributed
AS IS. The use of this information or the implementation of any recommendations or
techniques herein is a customer responsibility and depends on the customer’s ability to
evaluate and integrate them into the customer’s operational environment. While each item
may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee
that the same or similar results will be obtained elsewhere. Anyone attempting to adapt
these techniques to their own environment do so at their own risk.
This document and the information contained herein may be used solely in connection with
the IBM products discussed in this document.
This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new
editions of the publication. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only
and do not in any manner serve as an endorsement of those Web sites. The materials at
those Web sites are not part of the materials for this IBM product and use of those Web sites is
at your own risk.
IBM may use or distribute any of the information you supply in any way it believes
appropriate without incurring any obligation to you.
Any performance data contained herein was determined in a controlled environment.
Therefore, the results obtained in other operating environments may vary significantly. Some
measurements may have been made on development-level systems and there is no
guarantee that these measurements will be the same on generally available systems.
Furthermore, some measurements may have been estimated through extrapolation. Actual
results may vary. Users of this document should verify the applicable data for their specific
environment.
Data Protection in the Cloud
Page 18
Information concerning non-IBM products was obtained from the suppliers of those products,
their published announcements or other publicly available sources. IBM has not tested those
products and cannot confirm the accuracy of performance, compatibility or any other
claims related to non-IBM products. Questions on the capabilities of non-IBM products should
be addressed to the suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal
without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To
illustrate them as completely as possible, the examples include the names of individuals,
companies, brands, and products. All of these names are fictitious and any similarity to the
names and addresses used by an actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE: © Copyright IBM Corporation 2011. All Rights Reserved.
This information contains sample application programs in source language, which illustrate
programming techniques on various operating platforms. You may copy, modify, and
distribute these sample programs in any form without payment to IBM, for the purposes of
developing, using, marketing or distributing application programs conforming to the
application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions.
IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corporation in the United States, other countries, or both. If these and
other IBM trademarked terms are marked on their first occurrence in this information with a
trademark symbol (® or ™), these symbols indicate U.S. registered or common law
trademarks owned by IBM at the time this information was published. Such trademarks may
also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at “Copyright and trademark information” at
www.ibm.com/legal/copytrade.shtml
Windows is a trademark of Microsoft Corporation in the United States, other countries, or
both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.