Security Considerations - Teradata Director Program

Teradata Director Program Reference

Product
Teradata Director Program
Release Number
16.10
Published
May 2017
Language
English (United States)
Last Update
2018-05-09
dita:mapPath
hwt1488824663348.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2416
lifecycle
previous
Product Category
Teradata Tools and Utilities
TDP communicates with the Teradata Database from its address space, so its execution environment is independent of any applications using the Database. Specifically note the following:
  • TDP executes on MVS as an APF authorized program but limits its use of system authorities to those required by specific operating system services.
  • TDP accesses only datasets specified in the Job Control Language used to start TDP. Standard dataset access controls are not circumvented. Only standard dataset access methods are used. If no TDPSNAP Data Definition (DD) JCL statement is defined, TDP may dynamically allocate one that specifies a JES spool file. Since TDPSNAP is used to record error information, notably xP error information, if access to this information must be controlled, a TDPSNAP DD statement may be included that specifies a dataset name which may be controlled.
  • For communication with the Teradata Database using channel devices, either STARTIO, EXCPVR, or EXCP is used, as controlled by TDP commands when TDP begins execution.
  • Neither application SQL data nor Teradata Database logon passwords are retained beyond their need, nor are they passed to other address spaces. Such information is not included in any internal trace. The exception is incidental storage capture by system storage dump processing, system traces of CP device traffic, or NP system component traces of NP traffic.
  • TDP does not inspect or alter the application's SQL request or response data.
  • When using a CP, security of the requests and responses is based on the physical security of the channel cables. If device pairs—such as channel extenders—are placed on the channel that include the network into the data path, this physical security is lost. Access to system traces of CP device traffic may be controlled by securing the dataset in the GTF JCL used to record the data. TDP does not need access to this dataset.
  • When using an NP, requests and responses are transmitted over the network, which is not as inherently secure as the channel when using a CP.
TDP communicates with applications using the Teradata Database in their own address spaces using routines in commonly addressable storage such as the MVS Link Pack Area. Applications call CLIv2 routines, which in turn communicate to TDP using a state switch.
  • After a TDP routine in the application address space receive control in TDP's state, access to application storage for the request is serialized, validated, and performed only with the same access capabilities as the application itself possesses.
  • The TDP copy of the application's request is protected from any access or modification by the application.
  • No application resources except storage explicitly designated by the application is inspected or altered. No datasets are accessed in the application address space. No I/O is performed to any device. No communication facility, such as TCP/IP, is invoked.
  • No changes are made to the application's environment. No authorization is extended beyond TDP's routines.
  • Information is passed only to the TDP address space. No other address space is inspected or passed any information.
  • Communication with the TDP address space is serialized, validated, and performed only with the same access capabilities as the application itself possesses.

TDP exits should be carefully inspected and controlled because they have access to userids, passwords, and request and response data and could pass that information to other address spaces, save it in datasets, or establish network connections and send it elsewhere.