IBM Support

Protecting the private data network against unauthorized access

Product Documentation


Abstract

This document describes how to configure the private data network (PDN) that is used by DB2 Analytics Accelerator for z/OS so that only authorized users or applications can access the PDN.
This configuration prevents other z/OS users or applications from viewing or even manipulating data on the accelerator, either accidentally or on purpose.

Content

The z/OS Communications Server allows you to control the access to TCP/IP networks. The control features are sufficient to fulfill the security requirements.

The z/OS Communications Server uses System Authorization Facility (SAF)-controlled access to IP networks. In the IP Configuration Guide of z/OS Communications Server, this is called Network Access Control. See the following website for more information:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz002/security_tcpip_resrcs_network.htm

Note: It is assumed that your PDN is attached to dedicated OSA adapters. In addition, it is assumed that the PDN configuration suppresses the announcement of the network by dynamic routing protocols like OSPF or RIP.
Although it is not likely that your logical z/OS partition (LPAR) becomes an involuntary IP router if the PDN is excluded from dynamic routing, you might want to further shield the PDN against unwanted routing by using z/OS IP filtering capabilities. IP filtering is not discussed in this document.

In the remainder of this document, it is assumed that you use IBM RACF as your System Authorization Facility.

To activate Network Access Control, your RACF administrator must activate the SERVAUTH class.

Note: Activating the SERVAUTH class for the first time bears the risk of unintentionally disabling TCP/IP service. To avoid such a situation,
use generic profiles in WARN mode until you are satisfied with the results.

For more information, see the chapter Local user access control to TCP/IP resources using SAF in the
IP Configuration Guide:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz002/security_tcpip_resrcs_saf.htm

This chapter lists all kinds of supported SERVAUTH profiles in a table.

The profiles of interest in this context are the following:
  • EZB.NETACCESS.sysname.tcpname.zonename
    The SERVAUTH class activation enables checking for and enforcing the following two profiles by default. Creating these profiles and permitting user access to these profiles allows your SAF to make a predictive decision.
  • EZB.STACKACCESS.sysname.tcpname
    Since the introduction of z/OS 1.13, the default action in RACF is to allow all users even if there is no STACKACCESS profile at all. The default might be different for systems that do not run RACF as the SAF.
  • EZB.INITSTACK.sysname.tcpname
    The default RACF action is to deny all users if there is no INITSTACK profile at all. This does not disturb your operations unless you activate the support for the application transparent transport layer security (AT-TLS) in your TCPIP stack. Activation of AT-TLS by adding TCPCONFIG TTLS in your TCPIP profile makes the existence of INITSTACK profiles mandatory. If this is omitted, Initial Program Load (IPL) sequences cannot be completed successfully.

Step 1: Activate the SERVAUTH class in RACF by submitting the following stack of commands:

   SETROPTS CLASSACT(SERVAUTH)
   SETROPTS RACLIST(SERVAUTH)
   SETROPTS GENERIC(SERVAUTH)
   SETROPTS RACLIST(SERVAUTH) REFRESH

Do not omit the RACLIST(SERVAUTH) command, as it is mandatory.

Step 2a: Create a generic "catch all" profile in warn mode:

   RDEF SERVAUTH EZB.** UACC(NONE) warn
   SETROPTS RACLIST(SERVAUTH) REFRESH

You will receive RACF warning messages on your MVS console as soon as you refresh your RACF profiles. Example of such a warning:

ICH408I USER(TEST) GROUP(DE#03557) NAME(GRAY BILL)
EZB.STACKACCESS.PRODA.TCPIP CL(SERVAUTH)
WARNING: INSUFFICIENT AUTHORITY - TEMPORARY ACCESS ALLOWED
FROM EZB.** (G)
ACCESS INTENT(READ) ACCESS ALLOWED(NONE)

Step 2b: Create tighter "catch all" profiles and allow access:

   RDEF SERVAUTH EZB.INITSTACK.** UACC(NONE) warn
   PE EZB.INITSTACK.** CL(SERVAUTH) ID(*) ACC(READ)
   RDEF SERVAUTH EZB.STACKACCESS.** UACC(NONE) warn
   PE EZB.STACKACCESS.** CL(SERVAUTH) ID(*) ACC(READ)
   RDEF SERVAUTH EZB.BINDDVIPARANGE.** UACC(NONE) warn
   PE EZB.BINDDVIPARANGE.** CL(SERVAUTH) ID(*) ACC(READ)
   SETROPTS RACLIST(SERVAUTH) REFRESH

This step makes the RACF warnings for STACKACCESS disappear.
INITSTACK warnings issued during an IPL disappear as well.

Step 3: Create your IBM DB2 Analytics Accelerator for z/OS or Netezza NETACCESS RACF profile and grant profile access to those users and applications that require it.

The following users need access:
  • Started task user IDs of the DB2 head running the DB2 subsystems
  • Started task user ID of the z/OS Capturing Agent for IBM Change Data Capture for z/OS
  • RACF users (or group of users) that need access to the Netezza service or configuration console from
    ssh or TSO telnet clients
  • RACF users (or group of users) with the right to execute IBM DB2 Analytics Accelerator for z/OS stored procedures and SYSACCEL.* packages

To grant access to these users or groups, your RACF administrator must run the following TSO commands:

   RDEF SERVAUTH EZB.NETACCESS.PRODA.TCPIP.NETEZZA1 UACC(NONE) warn
   PE EZB.NETACCESS.PRODA.TCPIP.NETEZZA1 CL(SERVAUTH)
     ID(DB2MSTR CDCSTART IDAAADMIN IDAAGRP) ACC(READ)

Step 4: Your network administrator is now ready to configure NETACCESS checking by adding the following code to your TCP/IP profile:

NETACCESS INBOUND OUTBOUND   ; CHECK BOTH WAYS
       10.101.8.0/24 NETEZZA1; NETEZZA private net
ENDNETACCESS

Activation of NETACCESS checking can be done without restarting TCPIP.
You might want to create a new data set that contains just the new NETACCESS configuration settings.
Run the OBEY command on an MVS console session to activate the new NETACCESS configuration:

  ==> V TCPIP,tcpip,OBEYFILE,DSN=my.ipprofile(obeynet)

The string  my.ipprofile(obeynet) is the name of the NETACCESS configuration data set that you just created or modified.

Expect the following informational message to be issued on the MVS console when you activate your NETACCESS configuration:

EZZ0730I NETACCESS STATEMENT DEFINED WITHOUT DEFAULT ENTRY

A default NETACCESS entry is optional and not needed to fulfill the security requirements.
Details about the NETACCESS configuration statement can be found here:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz001/netaccessstatement.htm#netaccst

The TCP/IP stack checks whether the RACF profiles do exist. If the profiles cannot be found, you receive messages on the MVS console that are similar to this one:

EZD1313I REQUIRED SAF SERVAUTH PROFILE NOT FOUND
    EZB.NETACCESS.PRODA.TCPIP.NETEZZA1

Step 5: Once you are satisfied with your NETACCESS configuration, incorporate it into your existing TCP/IP profile to make the changes permanent.

Step 6: Remove the WARN mode if you are satisfied with your profiles:

RALT SERVAUTH EZB.NETACCESS.PRODA.TCPIP.NETEZZA1 UACC(NONE) nowarn
RALT SERVAUTH EZB.** UACC(NONE) nowarn
RALT SERVAUTH EZB.STACKACCESS.** UACC(NONE) nowarn
RALT SERVAUTH EZB.INITSTACK.** UACC(NONE) nowarn
RDEF SERVAUTH EZB.BINDDVIPARANGE.** UACC(NONE) nowarn

[{"Product":{"code":"SS4LQ8","label":"Db2 Analytics Accelerator for z\/OS"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"--","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"4.1.0;5.1.0;7.1.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
09 July 2021

UID

swg27038935