SQL/MX object security: Background
SQL/MX executes within the OSS environment, but database files reside within the Guardian environment. For SQL/MX tables, data access uses the ANSI GRANT/REVOKE authorization model.
SQL/MX is not tightly integrated with Safeguard; however, with SQL/MX version 3.3 and later, Safeguard volume protection can be used to control where SQL/MX objects are created. SQL/MX uses Guardian security for SQL/MP objects, Installation and fallback: cautions The initial installation of SQL/MX, done with the InstallSqlmx script, must be run by SUPER.SUPER (not an alias to it).
Do not change the security setting on the anchor file created by SQL/MX. If the file is modified, SQL/MX ceases to operate.
If you do not use DSM/SCM to do a SQL/MX installation, you must explicitly license the ZCLIPDLL public DLL.
If this step is not performed, program load errors might occur.
Make sure that the following files are licensed in $SYSTEM.SYSTEM:
• IMPORT
• MXUTP
• MXIMPDDL
• MXAUDSRV
• MXCMP
• MXESP
• MXRTDSRV
• MXTOOL
Make sure that the mxci file in /usr/tandem/sqlmx/bin has both read and execute permissions.
Best Practices
Create a separate SQL/MX security administrator group if running 3.1 or a subsequent version.
Security administrators manage access to SQL/MX data but they do not have access to the underlying data itself unless explicitly GRANTED access by an object owner or designee or through PUBLIC access.
Use this group to administer security.
Consider having only one user create database objects (such as a user designated as the database administrator).
In that way, no users other than the security administrators and database administrator may grant object access. Periodically audit the set of security administrators. To obtain detailed security administrator information:
OSS> mxci >> SET SCHEMA nonstop_sqlmx_<system name>.system_security_schema; >> SELECT * FROM privileged_users FOR read uncommitted access;
Use GRANT/REVOKE CREATE CATALOG to restrict the set of users who can create catalogs.
Use ANSI VIEWs to limit access to specific fields of a table to those users entitled to see their contents best practices
SQL/MX executes within the OSS environment, but database files reside within the Guardian environment. For SQL/MX tables, data access uses the ANSI GRANT/REVOKE authorization model.
SQL/MX is not tightly integrated with Safeguard; however, with SQL/MX version 3.3 and later, Safeguard volume protection can be used to control where SQL/MX objects are created. SQL/MX uses Guardian security for SQL/MP objects, Installation and fallback: cautions The initial installation of SQL/MX, done with the InstallSqlmx script, must be run by SUPER.SUPER (not an alias to it).
Do not change the security setting on the anchor file created by SQL/MX. If the file is modified, SQL/MX ceases to operate.
If you do not use DSM/SCM to do a SQL/MX installation, you must explicitly license the ZCLIPDLL public DLL.
If this step is not performed, program load errors might occur.
Make sure that the following files are licensed in $SYSTEM.SYSTEM:
• IMPORT
• MXUTP
• MXIMPDDL
• MXAUDSRV
• MXCMP
• MXESP
• MXRTDSRV
• MXTOOL
Make sure that the mxci file in /usr/tandem/sqlmx/bin has both read and execute permissions.
Best Practices
Create a separate SQL/MX security administrator group if running 3.1 or a subsequent version.
Security administrators manage access to SQL/MX data but they do not have access to the underlying data itself unless explicitly GRANTED access by an object owner or designee or through PUBLIC access.
Use this group to administer security.
Consider having only one user create database objects (such as a user designated as the database administrator).
In that way, no users other than the security administrators and database administrator may grant object access. Periodically audit the set of security administrators. To obtain detailed security administrator information:
OSS> mxci >> SET SCHEMA nonstop_sqlmx_<system name>.system_security_schema; >> SELECT * FROM privileged_users FOR read uncommitted access;
Use GRANT/REVOKE CREATE CATALOG to restrict the set of users who can create catalogs.
Use ANSI VIEWs to limit access to specific fields of a table to those users entitled to see their contents best practices
No comments:
Post a Comment