The Db2 profile tables - SYSIBM.DSN_PROFILE_TABLE and SYSIBM.DSN_PROFILE_ATTRIBUTES - have long been very useful in managing a Db2 for z/OS client-server application workload (i.e., a Db2 system's DDF workload). In particular, organizations have appreciated the ability, provided via the profile tables, to set thread limits and/or connection limits and/or an idle thread timeout value for particular DDF-using applications, versus having to rely solely on the subsystem-wide thread limit, connection limit and idle thread timeout values specified by way of the ZPARM parameters MAXDBAT, CONDBAT and IDTHTOIN, respectively. Db2 13 for z/OS recently delivered a new "more granular than ZPARM" DDF workload management option that can be exercised through the profile tables. This time, the more fine-grained control pertains to security requirements for Db2 for z/OS client-server applications. You can read on to learn more about this enhancement.
The challenge for which a solution was needed
Historically, a system-wide security requirement (i.e., one that would apply to all requesters) for a Db2 for z/OS system was specified via the TCPALVER parameter in ZPARM. The need for a more-granular client-server security requirement specification can be readily seen if you think about a new requirement that you'd like to eventually apply to the entire DDF workload for a Db2 for z/OS system. Suppose, for example, that your Db2 client-server applications now authenticate to the Db2 server with a password, and you'd like to eventually have all requesters authenticate to Db2 instead with a digital certificate; or, maybe you'd like for all requester applications accessing the Db2 system to eventually be required to utilize SSL encryption (aka AT/TLS encryption, referring to encryption of data "on the wire" that flows between Db2 for z/OS and requester applications); or, maybe you'd like to eventually have all requester applications use multi-factor authentication when requesting a connection to the Db2 system, or use RACF-generated authentication tokens. With all these situations, the tricky thing has been the "eventually" part of the objective. That's been problematic because Db2 for z/OS client-server security requirements have often required implementation in a "big switch" way (as in, throwing a big switch that suddenly routes all traffic to track A versus track B).
Consider, for example, a desire to have all Db2 for z/OS client-server applications use SSL encryption. One way to do that - available since April of 2019, via Db2 12 APAR PH08188 - is to make it so that the only SQL listener port available for the Db2 subsystem in question is a secure port (when a client application requests a connection to a Db2 for z/OS system via the Db2 server's secure port, Db2 will reject the connection if it determines that the requester cannot support SSL encryption). Let's say you go this route. OK, objective achieved - but, at what cost? Setting up SSL encryption for a Db2 client-server application can be a little tricky if you haven't done that before. There are multiple steps that have to be taken - correctly - on the Db2 and z/OS side, and on the client application side. It's pretty easy to get something wrong, and it could take a few tries before you get it right. If the Db2 for z/OS system's only SQL listener port is of the secure variety (i.e., you've thrown that particular "big switch"), any of your applications that aren't properly set up for SSL encryption will not be able to connect to the Db2 system (and if part of the server-side set-up for SSL encryption was not done properly, NO applications will be able to connect to the Db2 system). This could end up causing substantial disruption for one or more of your Db2 for z/OS client-server applications - something you'd certainly want to avoid.
It's a similar story for things such as certificate-based (versus password-based) client authentication, multi-factor authentication, etc. There are "big switch" ways in which you can lay down the law, but those approaches carry with them an elevated risk of application disruption because of their "big switch" nature. Wouldn't it be nice if you could roll out a Db2 for z/OS client-server security requirement in an incremental way - start small, and then expand once you've gotten it right for a little piece of the client-server workload? In fact, you can take just that approach in a Db2 13 for z/OS environment, thanks to APARs PH48764 (March 2023) and PH57811 (January 2024).
A new way to use the Db2 profile tables
APAR PH48764 added a new profile table attribute: MONITOR _______ CONNECTIONS FOR SECURITY. You'd fill in that blank after MONITOR with a category of the Db2 client-server application workload, with the category choices being:
- REST (for applications connecting to the Db2 for z/OS system's REST interface)
- JDBC
- CLI (short for the call-level interface - this will most commonly apply to applications using an ODBC driver to access the Db2 system)
- DB2CONNECT (this applies to applications that connect to the Db2 system through a Db2 Connect "gateway" server, as opposed to getting a direct application server-to-Db2 connection)
- DSN (this refers to requesters that are other Db2 for z/OS systems)
Importantly, APAR PH57811 made it possible to get very specific within a given client-server application category: you can have a profile that applies to a subnet of TCP/IP addresses, or even to a specific IP address (referring to the IP address of an application server).
With a profile defined (a category of the Db2 client-server workload, possibly as granular as a single application server), you can provide the associated attribute row in the DSN_PROFILE_ATTRIBUTES table. In that row, you can indicate the appropriate security requirement - choices include password-based cleint authentication, certificate-based client authentication, multi-factor authentication, and whether or not SSL encryption is required (the full range of choices can be found in the Db2 for z/OS documentation, and note that a requirement for certificate-based client authentication carries with it a requirement for SSL encryption).
OK, so let's look again at that scenario involving making SSL encryption a requirement for - eventually - all of your Db2 for z/OS client-server applications. This time, the "eventually" bit will NOT be a problem, because we'll leverage this new profile table-based granular client-server security requirement specification capability. Suppose we decide to start with applications that access the Db2 system using a JDBC driver. We can specify a profile for that DDF workload category, and we can make the profile applicable solely to a single server on which a JDBC-using application runs. If the application running on that server is running as well on one or more other servers, we can flow most all transaction work through those other servers and have just a few transactions (perhaps submitted by people on the IT team, as opposed to being user-submitted transactions) going through the server acting as our "canary in the coal mine." We issue the -START PROFILE command to load the profile table information into Db2 memory, and now the JDBC-using application running on the one app server will have to successfully complete an "SSL handshake" with the Db2 for z/OS server in order to establish a connection. What if the first connection request from the app server fails with a security error related to our MONITOR JDBC CONNECTIONS FOR SECURITY row in DSN_PROFILE_ATTRIBUTES? Not a huge deal - the application is interacting with Db2 just fine from servers other than the one on which we're working. We examine the connection error data, and determine where we need to make an adjustment or adjustments - maybe Db2 for z/OS-side, maybe app server-side, maybe a little of both. After making appropriate changes on whatever side, we try again and, WOO-HOO - successful SSL connection, followed by successful execution of some transactions flowing from the one app server. Now, we have a template for success - we know how things need to be set up in order for SSL encryption to work for our JDBC-using applications. We can subsequently expand the location-scope of our profile to include other servers hosting JDBC-using applications that access the Db2 system (maybe specifying, for example, a TCP/IP address that covers a subnet that includes several of these app servers), and eventually go with a generic location value (which could be specified in various ways, including * or 0.0.0.0) to indicate that the profile applies to all JDBC-using applications that access the Db2 for z/OS system.
Having gotten to where we want to be with the JDBC-using applications, we can take the same approach with (for example) applications that access the Db2 system using an ODBC driver - start with (if we want) a single app server, and stay with that very limited location scope until we get it right and have, as a result, the template for success with ODBC-using applications. Then we expand the location scope and eventually have the SSL requirement in force for all ODBC-uisng applications; then, on to the next category of interest to us (maybe REST clients). This "start small, get it right, then expand the location scope using what we've learned" approach can greatly reduce the risk and reach of application disruption when we want to implement a new Db2 for z/OS client-server security requirement. A game-changing Db2 enhancement, in my view.
Don't forget about profile table "warning" behavior - great for discovery purposes
Before closing out this blog entry, I want to highlight a Db2 profile table characteristic that I feel is sometimes overlooked by DBA teams: attributes (those that specify a requirement such as a security rule, or that specify a limit on application consumption of resources such as Db2 connections or threads) can be implemented with warning behavior ("let me know if the requirement was not met or the limit was exceeded, but otherwise take no action") as well as with exception behavior ("take application-impacting action when the requirement is not met or the limit is exceeded"). Warning behavior can be great for "getting the lay of the land" when you want to specify a new security requirement or set a new limit for some part of a Db2 subsystem's DDF workload. Let's again consider the SSL encryption requirement. Before establishing a "comply or suffer the consequences" SSL encryption requirement, even for a single app server, you might do well to activate one or more profiles and associated attributes in warning mode, just to see how big of a lift your team's going to be facing in establishing the new security requirement. How about JDBC-using applications? Is it the case that most of them are already using SSL encryption when accessing the Db2 system (not so big a lift, in that case), or is the reality more on the other end of the range of possibilities, with few or no JDBC-using applications using SSL when accessing the Db2 system (in which case, get ready to roll up your sleeves)? You can get the answer to that question by specifying an "SSL required" attribute for JDBC-using applications that will function in warning mode. No application work is impacted, and the messaging provided by Db2 when the SSL requirement is not met will provide you with valuable clarity regarding the current situation.
In conclusion...
In this blog entry, I have highlighted two of the beneficial applications of MONITOR _______ CONNECTIONS FOR SECURITY functionality that most appeal to me:
- It gives you the ability to "start small, succeed and then expand" when rolling out a security requirement that you'd like to eventually be in effect for your entire Db2 for z/OS client-server application workload, such as use of SSL encryption or certificate-based client authentication or multi-factor authentication. This approach can substantially reduce the risk of application disruption that could occur if you were to implement the new security requirement by "throwing a big switch."
- The non-application-impacting information provided by Db2 when profile table requirements or resource limits are implemented in warning mode can provide a very useful "lay of the land" view of one or more aspects of a Db2 client-server application workload. That intelligence, in turn, can help you to assess the scope of effort that would be required to implement the proposed requirement or resource limit in exception mode.
No comments:
Post a Comment