DB2 Best Practicespublic.dhe.ibm.com/software/dw/data/bestpractices/DB2BP_Cloud_S… · This paper...

��® 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

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


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.


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.


• “Additional cloud-specific security challenges” examines the additional challenges posed to data security in a cloud environment, in particular, the need for privileged-user monitoring and data segregation.


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:.

Figure 1. The IBM Data Server Security Blueprint

Application Security

Data Server Security

Physical Security

Network Security

Identity Managem

ent

Data Threats

Business Controls

Configuration Threats

Audit Threats Executable Threats

Host Security


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.


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 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.


• 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


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.


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


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 operating-system 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


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.


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.


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

http://www.ibm.com/developerworks/db2/bestpractices/

http://www.ibm.com/developerworks/data/bestpractices/security/


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 NON-INFRINGEMENT, 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.


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.

DB2 Best Practicespublic.dhe.ibm.com/software/dw/data/bestpractices/DB2BP_Cloud_S… · This paper...

Documents

Transcript of DB2 Best Practicespublic.dhe.ibm.com/software/dw/data/bestpractices/DB2BP_Cloud_S… · This paper...