Start of change

Discovering and controlling secure TCP/IP connectivity with profile tables

You can discover applications that are using TCP/IP connections without compliant authentication methods or encrypted connections to take corrective action or enforce compliance.

Start of change

Before you begin

If the Db2 profile tables and related objects does not exist on the Db2 subsystem, you must create them. For a list of the objects and how to create them, see Profile tables.

The distributed data facility (DDF) must be loaded, with the DDF subsystem parameter set to AUTO or COMMAND. See DDF STARTUP OPTION field (DDF subsystem parameter).

If you plan to use TCP/IP domain names for profile filtering, you must enable the database services address space (ssnmDBM1) to access TCP/IP services. See Enabling Db2 to access TCP/IP services in z/OS UNIX System Services.

This task describes one of several uses for profile tables. For an overview of how to use profile tables and a summary of the different uses, see Monitoring and controlling Db2 by using profile tables.

Start of changeWhen multiple matching security profiles are defined, the most specific profile filter applicable for the connection’s product type is used.End of change

End of change

About this task

This type of profile monitors connections for a specified product type for use of desired authentication and encryption methods.

Profiles of this type apply to all connections regardless of whether a connection can be matched to a more specific profile. This differs from the precedence rules for applying profiles that are described in How Db2 applies multiple matching profiles for threads and connections.

Procedure

To discover and control secure connectivity to Db2 by using profile tables, complete the following steps:

  1. In the SYSIBM.DSN_PROFILE_TABLE table, insert a row to create the profile and specify its filtering criteria:
    1. In the PROFILEID column, specify a unique value or accept the generated default value. This value identifies the profile and the relationship between DSN_PROFILE_TABLE and DSN_PROFILE_ATTRIBUTES rows.
    2. In the LOCATION column, specify one of the following values:
      • '*', '::0', or '0.0.0.0' (for all connections).
      • A domain name that resolves to an IP address. An example fully qualified domain name is 'stlmvs1.svl.example.com'.
      • IPV4 or IPV6 IP address.
      • IPV4 or IPV6 subnet address.

      Other filtering columns must contain the null value.

      Tip: If you create multiple profiles with overlapping filtering criteria, Db2 applies only one profile from each filtering category, based on a specific order of precedence. Start of changeIf multiple DSN_PROFILE_TABLE rows specify the same filtering criteria, only the newest is row is accepted when you start the profiles, and the other duplicates are rejected.End of change Also, exact values take precedence over values that use an asterisk (*) wildcard. However, profiles from different filtering categories can all apply. For more information about these rules, see How Db2 applies multiple matching profiles for threads and connections.
    3. In the PROFILE_ENABLED column, specify 'Y' so that the profile is enabled when profiles are started.
      If the PROFILE_AUTOSTART subsystem parameter setting is YES, the profile starts when you issue a START PROFILE command or when Db2 starts.
  2. Insert one or more SYSIBM.DSN_PROFILE_ATTRIBUTES table rows to specify the monitoring functions of the profile and its thresholds:
    1. Specify the PROFILEID value from the DSN_PROFILE_TABLE row that specifies the filtering criteria for this profile.
      Tip: Start of changeUse the same PROFILEID value for any DSN_PROFILE_ATTRIBUTES rows that require the same filtering criteria. If multiple DSN_PROFILE_TABLE rows contain exactly matching filtering criteria, only the newest duplicate row is accepted when you start the profiles, and the others are rejected and disabled.End of change
    2. In the KEYWORDS column, specify 'MONITOR product-type CONNECTIONS FOR SECURITY'.
    3. In the ATTRIBUTEn columns, specify the attributes of the profile:
      MONITOR product-type CONNECTIONS FOR SECURITY

      Specifies that Db2 monitors all connections for the specified product type for the desired authentication mechanisms and encryption requirements.

      MONITOR product-type CONNECTIONS FOR SECURITY validation occurs when new connections are made; they do not occur when existing connections are reused.

      Profiles defined for this keyword apply regardless of whether a connection can be matched to a more specific profile.

      When multiple matching security profiles are defined, the most specific profile filter applicable for the connection’s product type is used.

      The DSN_PROFILE_TABLE row must specify filtering only in the LOCATION column. The other filtering columns must contain the null value.

      product-type is one of the following values:
      • REST
      • JDBC
      • CLI
      • DB2CONNECT
      • DSN
      • * (the asterisk is a wildcard that applies for application requesters that do not match any of the more specific product types above)
      ATTRIBUTE1
      Specifies the action and console message to issue when the desired authentication mechanisms and encryption requirements are not met for connections with the product type specified in the profile, as shown in the following table.
      ATTRIBUTE1 value Result for exceeded thresholds Messages issued
      EXCEPTION Fail the connection request and issue the console message. DSNT771I for all active profiles, every 5 minutes at most
      EXCEPTION_ DIAGLEVEL1 Fail the connection request and issue the console message. DSNT771I for all active profiles, every 5 minutes at most
      EXCEPTION_DIAGLEVEL2 Fail the connection request and issue the console message. DSNT772I for a specific active profile, every 5 minutes at most
      EXCEPTION_DIAGLEVEL3 Fail the connection request and issue the console message. DSNT776I for every exception
      WARNING Allow the connection to remain open and issue the console message. DSNT771I for all active profiles, every 5 minutes at most
      WARNING_DIAGLEVEL1 Allow the connection to remain open and issue the console message. DSNT771I for all active profiles, every 5 minutes at most
      WARNING_ DIAGLEVEL2 Allow the connection to remain open and issue the console message. DSNT772I for a specific active profile, every 5 minutes at most
      WARNING_ DIAGLEVEL3 Allow the connection to remain open and issue the console message. DSNT775I for every warning
      ATTRIBUTE2
      FL 505 In the ATTRIBUTE2 column, specify the desired authentication mechanism.
      NULL
      Honor the value of the TCP/IP ALREADY VERIFIED field. This option is mutually exclusive with all other values. When this value is specified:
      1
      Use basic authentication: A user ID and password or passphrase for authentication.
      2
      Use a basic authentication with multifactor authentication (MFA).
      4
      Use a client certificate for authorization. When this value is specified:
      • The connection must be secured with an AT-TLS policy.
      • The ATTRIBUTE3 value is ignored.
      5
      Use basic authentication or client certificate: Use the behavior of value 1 or 4.
      6
      Use basic authentication with MFA or client certificate: Use the behavior of value 2 or 4.
      8
      Authentication token: Use RACF®-generated token (IDT) for authentication.
      10
      Basic authentication with MFA or authentication token: Use the behavior of value 2 or 8.
      12
      Client certificate or authentication token: Use the behavior of value 4 or 8.
      14
      Basic authentication with MFA, client certificate, or authentication token: Use the behavior of value 2, 4, or 8.
      ATTRIBUTE3
      FL 505 In the ATTRIBUTE3 column, specify whether the connection must be secured with an AT-TLS policy.
      NULL
      Use the following default AT-TLS policy behavior for the authentication mechanism specified in ATTRIBUTE2:
      • Basic authentication: The connection does not require an AT-TLS policy.
      • Basic authentication with MFA: The connection does not require an AT-TLS policy.
      • Client certificate: The connection must be secured with an AT-TLS policy.
      • Authentication token: The connection does not require an AT-TLS policy.
      1
      The connection must be secured with an AT-TLS policy.
  3. Load or reload the profile tables into memory by issuing a START PROFILE command. (For best results, do not issue a STOP PROFILE command when you add or modify existing profiles. Use the STOP PROFILE command only if you intend to disable all existing profiles.) For more information, see Starting and stopping profiles.
  4. Check the status of all newly added profiles in the STATUS columns of the DSN_PROFILE_HISTORY and DSN_PROFILE ATTRIBUTES_HISTORY tables.
    Successful completion of the START PROFILE command does not imply that all profiles started successfully. If the STATUS column of either history table contains a value that does not start with 'ACCEPTED', further action is required to enable the profile or the keyword action.

Examples

Example 1

Assume that you want to enforce that connections from native REST requesters use basic authentication or client certificates, and you want to discover any JDBC connections that do not use basic authentication with a defined AT-TLS policy.

In this case, you might complete the following steps:

  1. Insert the following DSN_PROFILE_TABLE rows.
    PROFILEID LOCATION ROLE AUTHID PRDID COLLID PKGNAME
    1 ::0 null null null null null
  2. Insert the following DSN_PROFILE_ATTRIBUTES rows.
    PROFILEID KEYWORDS ATTRIBUTE1 ATTRIBUTE2 ATTRIBUTE3
    1 MONITOR REST CONNECTIONS FOR SECURITY EXCEPTION_DIAGLEVEL3 5 null
    1 MONITOR JDBC CONNECTIONS FOR SECURITY WARNING 1 1
  3. Issue a -START PROFILE command.

Creating this example profile has the following results:

  • Native REST applications that connect to Db2 by using client certificates with an AT-TLS policy defined are allowed. REST connections using user ID and password are also allowed regardless of AT-TLS policy. Other forms of authentication are rejected with a DSNT776I exception message.
  • JDBC applications connecting to Db2 by using basic user ID and password with an AT-TLS policy defined are allowed. Other forms of authentication are also allowed with a DSNT771I warning message.
  • Connections from product types other than REST or JDBC use the TCPALVER subsystem parameter to determine what form of security is required.
Start of changeExample 2End of change
Start of changeThis example demonstrates the precedence rules when multiple security and thread monitoring profiles are defined. Consider the following profile definitions:
  1. Insert the following DSN_PROFILE_TABLE rows.
    PROFILEID LOCATION ROLE AUTHID PRDID COLLID PKGNAME
    1 ::0 null null null null null
    2 9.61.0.0/16 null null null null null
    3 9.61.15.0/24 null null null null null
  2. Insert the following DSN_PROFILE_ATTRIBUTES rows.
    PROFILEID KEYWORDS ATTRIBUTE1 ATTRIBUTE2 ATTRIBUTE3
    1 MONITOR * CONNECTIONS FOR SECURITY WARNING 5 1
    1 MONITOR JDBC CONNECTIONS FOR SECURITY EXCEPTION_DIAGLEVEL3 5 null
    1 MONITOR THREADS EXCEPTION 10 null
    2 MONITOR * CONNECTIONS FOR SECURITY EXCEPTION 1 1
    2 MONITOR DSN CONNECTIONS FOR SECURITY EXCEPTION 2 null
    2 MONITOR THREADS EXCEPTION 15 0
    3 MONITOR REST CONNECTIONS FOR SECURITY EXCEPTION 4 null
  3. Issue a START PROFILE command.
Creating this example profile has the following results:
  • From IP address 9.7.49.252, a Db2 for z/OS®application establishes a non-secure connection to the Db2 server with a user ID and password.
    • Profile ID 1 is the only security profile match for the IP address and product type.
    • The connection is allowed based on profile ID 1 MONITOR * CONNECTIONS FOR SECURITY rule.
    • Because the rule specifies TLS (ATTRIBUTE3=1) and a warning action, the DSNT771I console warning message is issued for the non-secure connection.
    • For monitoring threads, profile ID 1 is also the only match and the threshold of 10 threads is enforced.
  • From IP address 9.61.15.1 a REST client establishes a secure connection using a client certificate to the Db2 server.
    • Profile ID 3 is the most specific security profile match for the IP address and product type.
    • The connection is allowed based on profile ID 3 MONITOR REST CONNECTIONS FOR SECURITY rule.
    • For monitoring threads, profile ID 2 is the best match and the threshold of 15 threads is enforced.
    • This example demonstrates how two different profiles are applied because security profiles and thread monitoring profiles do not interact with one another.
  • From IP address 9.61.15.6 a CLI application establishes a secure connection to the Db2 server with a user ID and password.
    • Profile ID 3 is the most specific security profile match for IP address.
    • However, there is no security profile rule which governs the CLI application’s product type.
    • Profile ID 2 is evaluated because its subnet filter is the next best match for the IP address. The MONITOR * CONNECTIONS FOR SECURITY rule governs the CLI application’s product type and the connection is allowed.
    • For monitoring threads, profile ID 2 is the best match and the threshold of 15 threads is enforced.
    • This example demonstrates how multiple profiles, ID=3 and subsequently ID=2, in the same LOCATION filtering category are evaluated for security profiles, and how both the location filter and product type are used to determine which profile is applied.
End of change
End of change