Custom Domains

Custom domains allow for user defined domains and can define any tables of data uploaded to your Guardium system.

The usage for these custom entitlement (privileges) domains are for entitlement reports which are found if logged in as a user. To see these reports, go to the user tab DB Entitlements.

A number of custom domains have been predefined. You can use them to import data.

If you create a custom domain, and do not see it immediately after in the Custom Query-Report Builder, log out of the UI and log in again.

For details on using custom tables and custom domains, see External data correlation.

[Custom] Access

This domain contains all of the same entities as the standard Data Access domain. It is provided as a custom domain to allow additional user-defined domains to be built including information from this domain and any custom tables that have been uploaded by the user. [Custom]Access domain is meant to be cloned. This domain is updated on each version therefore is not advisable to create reports on this domain. For a description of the entities included in the Access domain, see the Access domain description in the Domains topic.

S-TAP Info (Central Manager)

Report: See S-TAP® Reports. On a Central Manager, an additional report, S-TAP Info, is available. This report monitors S-TAPs of the entire environment. Upload this data using the Custom Table Builder.

S-TAP info is a predefined custom domain which contains the S-TAP Info entity and is not modifiable.

When defining a custom query, go to upload page and click Check/Repair to create the custom table in CUSTOM database, otherwise save query will not validate it. This table loads automatically from all remote sources. A user cannot select which remote sources are used - it pulls from all of them.

Based on this custom table and custom domain, there are two reports:

Enterprise S-TAP view shows, from the Central Manager, information on an active S-TAP on a collector and/or managed unit (If there are duplicates for the same S-TAP engine, one being active and one being inactive, then the report will only use the active).

Detailed Enterprise S-TAP view shows, from the Central Manager, information on all active and passive S-TAPs on all collectors and/or managed units.

If the Enterprise S-TAP view and Detailed Enterprise S-TAP view look the same, it is because there only one S-TAP on one managed unit being displayed. The Detailed Enterprise S-TAP view would look different if there is more S-TAPs and more managed units involved.

These two reports can be chosen from the TAP Monitor tab of a standalone system, but they will display no information.

DB Entitlement Domains

Along with authenticating users and restricting role-based access privileges to data, even for the most privileged database users, there is a need to periodically perform entitlement reviews, the process of validating and ensuring that users only have the privileges required to perform their duties. This is also known as database user rights attestation reporting.

Use Guardium’s predefined database entitlement (privilege) reports (for example) to see who has system privileges and who has granted these privileges to other users and roles. Database entitlement reports are important for auditors tracking changes to database access and to ensure that security holes do not exist from lingering accounts or ill-granted privileges.

DB Entitlement Reports use the Custom Domain feature to create links between the external data on the selected database with the internal data of the predefined entitlement reports. See Database Entitlements Reports for further information on how to use predefined database entitlement reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

Note: DB Entitlements Reports are optional components enabled by product key. If these components have not been enabled, the choices do not appear in the Custom Domain Builder/Custom Query-Report Builder/Custom Table Builder selections.

The predefined entitlement reports are listed as follows. They appear as domain names in the Custom Domain Builder/Custom Query-Report Builder/ Custom Table Builder selections.

  • Oracle DB Entitlements
  • MYSQL DB Entitlements
  • DB2® DB Entitlements
  • SYBASE DB Entitlements
  • Informix® DB Entitlements
  • Microsoft SQL Server DB Entitlements
  • Netezza® DB Entitlements
  • Teradata DB Entitlements
  • PostgreSQL DB Entitlements

Oracle DB Entitlements

The following domains are provided to facilitate uploading and reporting on Oracle DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Query-Report Builder/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

Oracle

  • ORA Accnts of ALTER SYSTEM - Accounts with ALTER SYSTEM and ALTER SESSION privileges
  • ORA Accnts with BECOME USER - Accounts with BECOME USER privileges
  • ORA All Sys Priv and admin opt - Report showing all system privilege and admin option for users and roles
  • ORA Obj And Columns Priv - Object and columns privileges granted  (with or without grant option)
  • ORA Object Access By PUBLIC - Object access by PUBLIC
  • ORA Object privileges - Object privileges by database account not in the SYS and not a DBA role
  • ORA PUBLIC Exec Priv On SYS Proc - Execute privilege on SYS PL/SQL procedures assigned to PUBL
  • ORA Roles Granted - Roles granted to users and roles
  • ORA Sys Priv Granted - Hierarchical report showing system privilege granted to users including recursive definitions (i.e. privileges assigned to roles and then these roles assigned to users
  • ORA SYSDBA and SYSOPER Accnts - Accounts with SYSDBA and SYSOPER privileges

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

/* Select privilege to these tables/views is required */

grant select on sys.dba_tab_privs to sqlguard;

grant select on sys.dba_roles to sqlguard;

grant select on sys.dba_users to sqlguard;

grant select on sys.dba_role_privs to sqlguard;

grant select on sys.dba_sys_privs to sqlguard;

grant select on sys.obj$ to sqlguard;

grant select on sys.user$ to sqlguard;

grant select on sys.objauth$ to sqlguard;

grant select on sys.table_privilege_map to sqlguard;

grant select on sys.dba_objects to sqlguard;

grant select on sys.v_$pwfile_users to sqlguard;

grant select on sys.dba_col_privs to sqlguard;

MYSQL DB Entitlements

The following domains are provided to facilitate uploading and reporting on MYSQL DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Query-Report Builder/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

MYSQL: The queries ending in _40 use the most basic version of the mysql schema (for MySQL 4.0 and beyond). The information_schema has not changed since it was introduced in MySQL 5.0, so there is a set of _50 queries, but no _51 queries. The _50 queries work for MySQL 5.0 and 5.1 and for 6.0 when it comes out, since the information_schema is not expected to change in 6.0. The queries ending in _502 (MYSQL502) use the new information_schema, which contains much more information and is much more like a true data dictionary.

  • MYSQL Database Privileges 40
  • MYSQL User Privileges 40
  • MYSQL Host Privileges 40
  • MYSQL Table Privileges 40
  • MYSQL Database Privileges 500
  • MYSQL User Privileges 500
  • MYSQL Host Privileges 500
  • MYSQL Table Privileges 500
  • MYSQL Database Privileges 502
  • MYSQL User Privileges 502
  • MYSQL Host Privileges 502
  • MYSQL Table Privileges 502

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

Note: In addition to the privileges required, the user should connect to the MYSQL database to upload the data.

The entitlement queries for all MySQL versions through MySQL 5.0.1 use this set of tables: mysql.db mysql.host mysql.tables_priv mysql.user

Beginning with MySQL 5.0.2, and for all later versions, the entitlement queries use this set of tables: information_schema.SCHEMA_PRIVILEGES mysql.host information_schema.TABLE_PRIVILEGES information_schema.USER_PRIVILEGES

If a datasource has a MYSQL database type, but does not have a DB name (see Datasource Definitions, the database name under Location is blank), then the uploading data will loop through all MYSQL databases the user has access to.

DB2 DB Entitlements

The following domains are provided to facilitate uploading and reporting on DB2 DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Query-Report Builder/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

  • DB2 Column-level Privileges (SELECT, UPDATE, ETC.)
  • DB2 Database -level Privileges (CONNECT, CREATE, ETC.)
  • DB2 Index-level Privilege (CONTROL)
  • DB2 Package-level Privileges (on code packages – BIND, EXECUTE, ETC.)
  • DB2 Table-level Privileges (SELECT, UPDATE, ETC.) DB2 Privilege Summary

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

/* Select privilege to these tables/views is required */

GRANT SELECT ON SYSCAT.COLAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.DBAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.INDEXAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.PACKAGEAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.DBAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.TABAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.SCHEMAAUTH TO SQLGUARD;

GRANT SELECT ON SYSCAT.PASSTHRUAUTH TO SQLGUARD;

SYBASE DB Entitlements

The following domains are provided to facilitate uploading and reporting on SYBASE DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Query-Report Builder/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

  • SYBASE System Privilege and Roles Granted to User including Grant option
  • SYBASE Role Granted to User and System Privileges Granted to user and role including Grant option
  • SYBASE Object Access by Public
  • SYBASE Execute Privilege on Procedure, function assigned To Public
  • SYBASE Accounts with System or Security Admin Roles
  • SYBASE Object and Columns Privilege Granted with Grant option
  • SYBASE Role Granted To User

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

/* Select privilege to these tables/views is required */

/* These are required on MASTER database */

grant select on master.dbo.sysloginroles to sqlguard

grant select on master.dbo.syslogins to sqlguard

grant select on master.dbo.syssrvroles to sqlguard

 

/*These are required on every database, including MASTER */

grant select on sysprotects to sqlguard

grant select on sysusers to sqlguard

grant select on sysobjects to sqlguard

grant select on sysroles to sqlguard

If a datasource has a SYBASE database type, but does not have a DB name (see Datasource Definitions, the database name under Location is blank), then the uploading data will loop through all SYBASE databases the user has access to.

Informix DB Entitlements

The following domains are provided to facilitate uploading and reporting on Informix DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Query-Report Builder/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

  • Informix Object Privileges by database account not including system account and roles
  • Informix database level privileges, roles and language granted to user including grant option
  • Informix database level privileges, roles and language granted to user and role including grant option
  • Informix Object Grant to Public
  • Informix Execute Privilege on Informix procedure and function granted to Public
  • Informix Account with DBA Privilege Informix Object and columns privileges granted with Grant option
  • Informix Role Granted To User and Role

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements). The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

/* Select privilege to these tables/views is required */

Since all users have sufficient privileges for system catalog SELECT privileges, there is no need to grant privilege to any user. Informix doesn't seem to like granting system catalog to users. The grant would normally be used.  But in this case they are not required.

grant select on systables to sqlguard;

grant select on systabauth to sqlguard;

grant select on sysusers to sqlguard;

grant select on sysroleauth to sqlguard;

grant select on syslangauth to sqlguard;

grant select on sysroutinelangs to sqlguard;

grant select on sysprocauth to sqlguard;

grant select on sysprocedures to sqlguard;

grant select on syscolauth to sqlguard;

If a datasource has a Informix database type, but does not have a DB name (see Datasource Definitions, the database name under Location is blank), then the uploading data will loop through all Informix databases the user has access to.

Microsoft SQL Server 2005 and later DB Entitlements

The following domains are provided to facilitate uploading and reporting on Microsoft SQL Server 2005 and later DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder, Custom Query-Report Builder, and Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

Note: Objects in Dynamic query Strings will NOT be shown in xxx_DEPENDENCIES. An object in an EXECUTE IMMEDIATE SQL string called by a stored program unit does not show dependency. This query exclude schema owner defined in group ID 202 "Dependencies_exclude_schema-MSSQL". User has the ability to add or subtract schema name from this group for the dependencies query.
  • Microsoft SQL Server Object privileges by database account not including default system user.
  • Microsoft SQL Server Role/System privileges granted To User
  • Microsoft SQL Server Role/System Privilege granted to user and role including grant option
  • Microsoft SQL Server Object access by PUBLIC
  • Microsoft SQL Server Execute Privilege on System Procedures and functions to PUBLIC
  • Microsoft SQL Server Database accounts of db_owner and db_securityadmin Role
  • Microsoft SQL Server Server account of sysadmin, serveradmin and security admin /* only run against MASTER database */
  • Microsoft SQL Server Object and columns privileges granted with grant option
  • Microsoft SQL Server Role granted to user and role.

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

 

/* Select privilege to these tables/views is required */

/*These are required on MASTER database */

grant select on sys.server_principals to sqlguard

 

/*These are required on every databases including MASTER */

grant select on sys.database_permissions to sqlguard

grant select on sys.database_principals to sqlguard

grant select on sys.all_objects to sqlguard

grant select on sys.database_role_members to sqlguard

grant select on sys.columns to sqlguard

If a datasource has a MSSQL database type, but does not have a DB name (see Datasource Definitions, the database name under Location is blank), then the uploading data will loop through all MSSQL databases the user has access to.

Netezza DB Entitlements

The following domains are provided to facilitate uploading and reporting on Netezza DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Domain Query/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

Note: There is no DB error text translation for Netezza. The error appears in the exception description. Users can clone/add a report with the exception description for Netezza as needed.

  • Netezza Obj Privs by DB Username - Object privileges with or without grant option by database username excluding ADMIN account.

  • Netezza Admin Privs by DB Username - Admin privileges with or without grant option by database username excluding ADMIN account.

  • Netezza Group /Role Granted To User - Group (Role) granted to user

  • Netezza Obj Privs By Group - Object privileges with or without grant option by GROUP excluding PUBLIC.

  • Netezza Admin Privs By Group - Admin privileges with or without grant option by GROUP excluding PUBLIC.

  • Netezza Admin Privs By DB Username, Group - Admin privileges with or without grant option by database username, group excluding ADMIN account and PUBLIC group.

  • Netezza Obj Privs Granted - Object privileges granted with or without grant option to PUBLIC.

  • Netezza Admin Privis Granted - Admin privileges granted with or without grant option to PUBLIC.

  • Netezza Global Admin Priv To Users and Groups - Global admin privilege granted to users and groups excluding ADMIN account.

  • Netezza Global Obj Priv To Users and Groups - Global object privilege granted to users and groups excluding ADMIN account.

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

 

/* Select privilege to these tables/views is required */

/* This script must be run from the system database */

GRANT SELECT ON SYSTEM VIEW TO sqlguard;

GRANT LIST ON DATABASE TO sqlguard;

GRANT LIST ON USER TO sqlguard;

GRANT LIST ON GROUP TO sqlguard;

GRANT SELECT ON _V_CONNECTION TO sqlguard;

For Netezza entitlement queries, it is recommended to connect to SYSTEM database, especially when granting the privilege to the user who is going to run these reports. The granting privilege MUST take place from SYSTEM database or else the granted privilege will only take place on one particular database. When the granted privilege takes place from SYSTEM database, a special feature will allow the granted privilege to carry through to all the databases.

Teradata DB Entitlements

The following domains are provided to facilitate uploading and reporting on Teradata DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Domain Query/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

  • Teradata Object privileges by database account not including default system users.

  • Teradata System privileges and roles granted to users including grant option.

  • Teradata Roles granted to users and roles including grant option.

  • Teradata Role granted to users and roles.  System privileges granted to users and roles including grant option.

  • Teradata Objects and System privileges granted to public. Note role cannot be granted to public in Teradata.

  • Teradata Execute privileges on system database objects to public.

  • Teradata System admin, Security admin privileges granted to user and role.
    Note: There are no such role as System or Security admin in Teradata. User must create their own roles. These are some important system privileges that would normally not be granted to normal user: ABORT SESSION, CREATE DATABASE, CREATE PROFILE, CREATE ROLE,CREATE USER, DROP DATABASE, DROP PROFILE, DROP ROLE, DROP USER, MONITOR RESOURCE, MONITOR SESSION, REPLICATION OVERRIDE, SET SESSION RATE, SET RESOURCE RATE.

  • Teradata Object privileges granted with granted option to users. Not including DBC and grantee = 'All'.

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

 

/* Select privilege to these tables/views is required */

GRANT SELECT ON DBC.AllRights TO sqlguard;

GRANT SELECT ON DBC.Tables TO sqlguard;

GRANT SELECT ON DBC.AllRoleRights TO sqlguard;

GRANT SELECT ON DBC.RoleMembers TO sqlguard;

PostgreSQL DB Entitlements

The following domains are provided to facilitate uploading and reporting on PostgreSQL DB Entitlements. Each of the following domains has a single entity (with the same name), and there is a predefined report for each domain. All of these domains are available from the Custom Domain Builder/Custom Domain Query/ Custom Table Builder selections. As with other predefined entities and reports, these cannot be modified, but you can clone and then customize your own versions of any of these domains or reports. To see entitlement reports, log on the user portal, and go to the DB Entitlements tab.

There are seven entitlement custom domains/queries/reports for PostgreSQL. They are as follows (each is listed with Report name, description, note):

 

  • PostgreSQL Priv On. Databases Granted To Public User Role With Or Without Granted Option. Privilege on databases granted to public, user and role with or without granted option. Run this on any database, ideally PostgreSQL.

  • PostgreSQL Priv On Language Granted To Public User Role With Or Without Granted Option. Privilege on Language granted to public, user and role with or without granted option. Run this per database.

  • PostgreSQL Priv On Schema Granted To Public User Role With Or Without Granted Option. Privilege on Schema granted to public, user and role with or without granted option. Run this per database.

  • PostgreSQL Priv On Tablespace Granted To Public User Role With Or Without Granted Option. Privilege on Tablespace granted to public, user and role with or without granted option. Run this on any database, ideally PostgreSQL.

  • PostgreSQL Role Or User Granted To User Or Role. Role or User granted to user or role including grant option. Run this once in any database. Ideally PostgreSQL.     

  • PostgreSQL Super User Granted To User Or Role. Super user granted to user or role. Run this once in any database. Ideally PostgreSQL.     

  • PostgreSQL Sys Privs Granted To User And Role. System privileges granted to user and role. Run this once in any database. Ideally PostgreSQL.     

  • PostgreSQL Table View Sequence and Function privs Granted To Public. Tables, Views, Sequence and Functions privileges granted to public. Run this per database. Run this per database.

  • PostgreSQL Table View Sequence and Function Privs Granted With Grant Option. Tables, Views, Sequence and Functions privileges granted to user and role with grant option only. Exclude PostgreSQL account.

  • PostgreSQL Table View Sequence Function Privs Granted To Roles. Tables, Views, Sequence and Functions privileges granted to roles.  Not including public. Run this per database.

  • PostgreSQL Table Views Sequence and Functions Privs Granted To Login. Tables, Views, Sequence and Functions privileges granted to logins. Not including postgres system user. Run this per database.

Note: As of version 8.3.6, PostgreSQL does not support grant admin option to public. There is only function, no store procedure. There is no support for column grant, only table grant. Public is a group, not user. Public does not show up in pg_roles. The only privileges need to run all these queries is: GRANT CONNECT ON DATABASE PostgreSQL TO username;

 

For entitlements to be able to upload data from various datasources, the general requirement is that the login, used to access the database, be able to read the tables used in the query (which is hidden for all entitlements).

The following list (with comment line heading) details the minimal privileges required, in the database table (or view of the database table), in order for the entitlement to work.

 

/* Select privilege to these tables/views is required */

/*This is required on POSTGRES database*/

grant connect on database postgres to sqlguard;

 

/*These are required on every database, including POSTGRES (By default these are already granted to PUBLIC) */

grant select on pg_class to sqlguard;

grant select on pg_namespace to sqlguard;

grant select on pg_roles to sqlguard;

grant select on pg_proc to sqlguard;

grant select on pg_auth_members to sqlguard;

grant select on pg_language to sqlguard;

grant select on pg_tablespace to sqlguard;

grant select on pg_database  to sqlguard;

 

If a datasource has a PostgreSQL database type, but does not have a DB name (see Datasource Definitions, the database name under Location is blank), then the uploading data will loop through all PostgreSQL databases the user has access to.