How-tos

Secure Your Db2 Data Base with Trusted Contexts

Share this post:

I recently introduced you to Cloud App Security. Now, you have that new cloud-based app. The data is going to be stored in DB2 (on or off the cloud). You want to protect the data, but that cloud app user needs read and write access to the database. You don’t want to open the floodgates to the database for that user? Ok, here is a way to secure your Db2 data and still provide the required access. Even if that sounds impossible, trust me. And, I am going to put that “trust me” in context. Read on.

Overview

Db2 has a security feature named Trusted Context. To utilize it, specify connection attributes like the userid, the originating address and its security or encryption level (SSL in use?). Those properties define a scenario, the so-called trusted context. When those properties match the current connection attributes, when that trusted relationship has been established, then the userid can either switch to another userid or inherit privileges from a specified role. This allows to secure the database by three simple steps:

  1. Grant the needed privileges to a new, application-specific role.
  2. Revoke all privileges from the userid utilized by the application.
  3. Create a trusted context for that userid and the application’s connection and grant the role from step 2 and its privileges to the userid.

Db2 Privileges

How would those steps look like in actual SQL? For the example we assume that the userid “webuser” is utilized by the application. The app address may be “mytrustedapp.example.com”. We want to allow on SSL-secured connections. In the first step, we need to create a new role and grant all the needed privileges:

create role webapprole;
grant connect on database to role webapprole;
grant grant insert,update,delete,select on webtable to role webapprole;

The above would grant the connect privilege on the database as well as privileges to access and modify data in a table “webtable” to the newly created role “webapprole”.

If the “webuser” already had privileges and you want to improve database security, how could you find out the existing privileges? This is something needed for the second step, too. Db2 offers several security-related routines and views. The view PRIVILEGES and the table function AUTH_LIST_AUTHORITIES_FOR_AUTHID provide and easy way to retrieve the existing privileges. Revoke them and later check back that no privilege is left. If you started with a “fresh” userid, there is probably only the CONNECT privilege and maybe few others to take care of.

Trusted Context

In the final step, we create the trusted context “webapptrust”:

create trusted context webapptrust
based upon connection using system authid webuser
enable
attributes (address ‘mytrustedapp.example.com’, encryption ‘high’)
default role webapprole; 

The trusted context is enabled. It can be created as disabled or switched on and off using ALTER TRUSTED CONTEXT. Note that the address ‘mytrustedapp.example.com‘ is checked during the creation process and it needs to exist. Thus, the above statement will give an error message. A property of high encryption indicates that a SSL-protected connection is necessary. When the attributes are matched successfully, the userid “webuser”. for the duration of the trusted connection, is granted the role webapprole and its associated privileges. Therefore, “webuser” is able to connect to the database and to access the table “webtable” again. If the user would try to access the database via other means, e.g., by a local IPC- or TPC-based connection, the attempt would fail.

Learn more about that topic and meet me at the upcoming IDUG EMEA and Db2 Aktuell conferences. If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Security Stories

Build and deploy a MEAN stack application on IBM Cloud

MEAN is a collection of JavaScript-based technologies — MongoDB, Express.js, AngularJS, and Node.js — used to develop web applications. From the client and server sides to databases, MEAN is a full-stack development toolkit. This tutorial walks you through the creation of a web application using the popular MEAN stack. It is composed of a Mongo DB, Express web framework, Angular front-end framework and a Node.js runtime.

Continue reading

A hybrid Cordova mobile app with Push and Analytics in minutes

As promised while introducing "Tutorials to get your mobile development up and running", we are continuing our efforts to add more mobile solution tutorials. After quickly scaffolding a native iOS-Swift and Android mobile app with Push and Analytics, it's time to bring in the hybrid mobile app development flavor to the game with Cordova - Apache Cordova is an open-source mobile development framework. It allows you to use standard web technologies - HTML5, CSS3, and JavaScript for cross-platform development.

Continue reading

Use your own branded UI for user sign-in with App ID

With IBM Cloud App ID’s Cloud Directory feature, you can create a user registry, and add sign-up and email/password sign-in to your mobile or web app. Cloud Directory comes with a pre-built sign-in widget that you can use, or if you prefer to use your own branding, you can replace it with your own custom UI. This blog will show you how to use Cloud Directory APIs and add your own custom sign-in screen to an Android application. You can find the Android Cloud Land App on GitHub.

Continue reading