XYGATE Access Control Reference Manual

XYGATE
®
Access Control Reference Manual
Introduction
XYPRO Technology Corporation xvii Proprietary and Confidential
Vocabulary
XAC is the name of the XYGATE Access Control software package.
XYGATEAC is the name of the object file that runs as a process to manage an XAC
session.
XAC by itself is the name of the macro that is run to perform two functions: (1) attach
the XAC_SEG compiled TACLSEG library of macros, and (2) invoke XYGATEAC to
start an XAC session.
DBSO is the name of the object file that runs as the database server.
XSC is the name of the XYGATE Secure Communication software package that is a
PC-resident module and provides communication security.
XAC Installation Design Philosophy
XYGATEAC is designed to control actions on a system-wide basis. The
implementation effort can be broken down into two components: (1) the time spent
developing XAC Command Entries, and (2) the time spent reviewing XAC audit
reports.
XAC Command Entries described in Appendix C3: (starting on page 138) are denoted
by a Command Name; that is, a program to run the userid to use as the PAID when
the program is run and a list of the users that can run the program finish the set of
required elements. There are many other keywords that can control how the program
executes, including controls on which commands can be used in the program, limits on
which other programs can be spawned from inside this program, and how
communications errors are handled.
There are two extremes in philosophy when designing the XAC installation. In the first,
XAC’s primary usage is to provide complete keystroke auditing for all sessions on the
system by replacing unsecured TACLs with XAC-secured TACLs and unsecured OSS
access with secured OSS access. There are no changes to the users’ environment;
everything behaves as it always has. No new limitations are placed on what a user can
or cannot do. The only security implemented is the complete audibility of every action.
The second philosophy designs an XAC Command Entry for every command where
security is necessary. Basic TACLs are left unsecured because the majority of actions
performed by users are permitted by basic NSK rules. Only sensitive commands are
secured, so that the audit does not reflect normal, low-risk usage but instead shows
only actions that run under a userid different from the person executing the command
or that contain an element of risk.