Data Security in dashDB

By Walid Rjaibi,

dashDB is a managed data warehousing and analytics service on the cloud, available on both the Bluemix  and Cloudant platforms. For IT professionals, it takes data warehouse infrastructure out of the equation when you must rapidly add analytics services for your organizations. For business professionals, it provides a self-service analytics powerhouse in a cloud-easy, load and go format. But when you place your data in the cloud you need to know that it is secure. In this blog you will learn how dashDB keeps your data secure through encryption, database activity monitoring, deployment hardening, and secure design principles

Encryption for data at rest

With dashDB, encryption for data at rest is automatic. The encryption uses Advanced Encryption Standard (AES) in Cipher-Block Chaining (CBC) mode with a 256 bits key. Encryption and key management are totally transparent to applications and schemas. Additionally, the client has the option to indicate, upon provisioning, the master key rotation period. The default is 90 days but the client may choose a different value. The master key rotation is automatic and transparent. Database and tables-pace backup images are automatically compressed and encrypted. Like for online data, backup images are also encrypted using AES in CBC mode with 256 bit keys.

Encryption for data in transit

Secure Socket Layer (SSL) is automatically configured when your dashDB database is provisioned. That is, your database applications have the option to immediately leverage SSL to protect the confidentiality and integrity of the database traffic. The SSL certificate you need to enable your applications for SSL is easily downloadable from the dashDB console. The dashDB console itself is automatically deployed with HTTPS so all your exchanges with the console are also protected with SSL.

Database activity monitoring

Your dashDB database is continuously monitored through IBM InfoSphere Guardium. The monitoring reports are made available to you easily through the dashDB console. Three different reports are available. The first is a sensitive data report. This allows you to understand what sensitive data might be present in your database (e.g., credit card numbers). The second report is a database connections report. This allows you to understand who is making connections to your database. The third report is an activity report. This allows you to understand who is accessing which objects in your database. There are two versions of this report: A summary version and a detailed version.

Database access control

Database access control starts with the dashDB console where you define your database users. Your dashDB database also provides a rich set of traditional security capabilities to allow you to manage who in your team should have access to what objects in your database.  These capabilities include table level privileges and role based access control. For example, suppose that a Guardium sensitive data report shows that you have a table that includes sensitive data. In this case, you would want to create a role representing the users authorized to access that table, grant access on the table to that role,  and then revoke access from anyone else.

Deployment hardening

Both the dashDB database server and the database are hardened. The database server employs a host firewall to protect listening services against port scans and other network security threats. As such, only the required TCP ports are open. CONNECT authority to the database is revoked from PUBLIC, and SELECT privilege on the catalog tables and views is also revoked from PUBLIC. Additionally, the AUTHENTICATION database manager configuration parameter is set to SERVER_ENCRYPT which means that user authentication credentials are never exchanged in clear text between a user application and the database server. These credentials are automatically encrypted with AES 256 when sent over the network regardless of whether SSL is used or not.

Secure design principles

The development of dashDB follows secure development best practices as outlined in the IBM Secure Engineering Framework (http://www-01.ibm.com/software/test/wenses/security/). For example, this includes the completion of a risk assessment and a threat modeling document. Additionally, the IBM Security AppScan tools are regularly used to conduct static and dynamic code analysis during the development process.

About Walid Rjaibi, 

Walid Rjaibi is the Chief Security Architect for IBM Information Management (IM). He drives the strategy and provides technical oversight for security over a broad set of IM products and cloud services. Prior to his current role, Walid was a Research Staff Member at the IBM Zurich Research Lab in Switzerland where he established and led a new research program focused on database security and privacy. His research results were the foundation for key security enhancements in IBM’s database products and for which he led the actual development efforts upon his return to the IBM Toronto Lab. Walid’s work so far resulted in over 20 patents and several publications in the proceedings of leading scientific conferences, such as the international conference on Very Large Databases (VLDB), the International Conference on Data Engineering (ICDE), and the international conference on Security and Cryptography (SECRYPT). Walid also speaks frequently at industrial conferences such as the International DB2 User Group (IDUG) and the IBM Information of Demand (IOD). You can follow him on @WalidRjaibi

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s