An explicit trusted connection is a connection that is successfully established by a specific, explicit request for a trusted connection. When you request an explicit trusted connection and you do not qualify for one, you get a regular connection and a warning (+20360).
To determine why a user could not establish a trusted connection, the security administrator needs to look at the trusted context definition in the system catalogs and at the connection attributes. In particular, the IP address from which the connection is established, the encryption level of the data stream or network, and the system authorization ID making the connection. The -application option of the db2pd utility returns this information, as well as the following additional information:
v Connection Trust Type: Indicates whether the connection is trusted or not. When the connection is trusted, this also indicates whether this is an explicit trusted connection or an implicit trusted connection.
v Trusted Context name: The name of the trusted context associated with the trusted connection.
v Role Inherited: The role inherited through the trusted connection.
The following are the most common causes of failing to obtain an explicit trusted connection:
v The client application is not using TCP/IP to communicate with the DB2 server.
TCP/IP is the only supported protocol for a client application to communicate with the DB2 server that can be used to establish a trusted connection (explicit or implicit).
v The database server authentication type is set to CLIENT.
v The database server does not have an enabled trusted context object. The
definition of the trusted context object must explicitly state ENABLE in order for that trusted context to be considered for matching the attributes of an incoming connection.
v The trusted context objects on the database server do not match the trust attributes that are presented. For example, one of the following situations may apply:
– The system authorization ID of the connection does not match any trusted context object system authorization ID.
– The IP address from which the connection originated does not match any IP address in the trusted context object considered for the connection.
– The data stream encryption used by the connection does not match the value of the ENCRYPTION attribute in the trusted context object considered for the connection.
You can use the db2pd tool to find out the IP address from which the connection is established, the encryption level of the data stream or network used by the connection, and the system authorization ID making the connection. You can consult the SYSCAT.CONTEXTS and SYSCAT.CONTEXTATTRIBUTES catalog views to find out the definition of a particular trusted context object, such as its system authorization ID, its set of allowed IP addresses and the value of its ENCRYPTION attribute.
The following are the most common causes of a switch user failure:
v The user ID to switch to does not have CONNECT privileges on the database. In this case, SQL1060N is returned.
v The user ID to switch to, or PUBLIC, is not defined in the WITH USE FOR clause of the trusted context object associated with the explicit trusted connection.
v Switching the user is allowed with authentication, but the user presents no credentials or the wrong credentials.
v A switch-user request is not made on a transaction boundary.
v The trusted context that is associated with a trusted connection has been disabled, dropped, or altered. In this case, only switching to the user ID that established the trusted connection is allowed.
Chapter 4. Row and column access control (RCAC) overview
DB2 Version 10.1 introduces row and column access control (RCAC), as an additional layer of data security. Row and column access control is sometimes referred to as fine-grained access control or FGAC. RCAC controls access to a table at the row level, column level, or both. RCAC can be used to complement the table privileges model.
To comply with various government regulations, you might implement procedures and methods to ensure that information is adequately protected. Individuals in your organization are permitted access to only the subset of data that is required to perform their job tasks. For example, government regulations in your area might state that a doctor is authorized to view the medical records of their own patients, but not of other patients. The same regulations might also state that, unless a patient gives their consent, a healthcare provider is not permitted access to patient personal information, such as the patients home phone number.
You can use row and column access control to ensure that your users have access to only the data that is required for their work. For example, a hospital system running DB2 for Linux, UNIX, and Windows and RCAC can filter patient
information and data to include only that data which a particular doctor requires.
Other patients do not exist as far as the doctor is concerned. Similarly, when a patient service representative queries the patient table at the same hospital, they are able to view the patient name and telephone number columns, but the medical history column is masked for them. If data is masked, a NULL, or an alternate value is displayed, instead of the actual medical history.
Row and column access control, or RCAC, has the following advantages:
v No database user is inherently exempted from the row and column access control rules.
Even higher level authorities such as users with DATAACCESS authority are not exempt from these rules. Only users with security administrator (SECADM) authority can manage row and column access controls within a database.
Therefore, you can use RCAC to prevent users with DATAACCESS authority from freely accessing all data in a database.
v Table data is protected regardless of how a table is accessed via SQL.
Applications, improvised query tools, and report generation tools are all subject to RCAC rules. The enforcement is data-centric.
v No application changes are required to take advantage of this additional layer of data security.
That is, row and column level access controls are established and defined in a way that is not apparent to existing applications. However, RCAC represents an important shift in paradigm in the sense that it is no longer what is being asked but rather who is asking what. Result sets for the same query change based on the context in which the query was asked and there is no warning or error returned. This behavior is the exact intent of the solution. It means that application designers and DBAs must be conscious that queries do not see the whole picture in terms of the data in the table, unless granted specific
permissions to do so.