7.2 Netezza Advanced Security Admin Guide

IBM Netezza
Release 7.2
IBM Netezza Advanced Security

Administrator's Guide

IBM Netezza
Release 7.2
IBM Netezza Advanced Security

Administrator's Guide

Note
Before using this information and the product it supports, read the information in “Notices” on page D-1
Revised: September 8, 2014

This edition applies to IBM Netezza Release 7.2 and to all subsequent releases until otherwise indicated in new
editions.
© Copyright IBM Corporation 2009, 2014.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Electronic emission notices . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Regulatory and compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
About this publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
If you need help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
How to send your comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Chapter 1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Basic security model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Advanced security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
System security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
View the security setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Chapter 2. User login control . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Session context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Concurrent sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Access time control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Password restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Chapter 3. Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Nesting and stored procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Chapter 4. Key management . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Encrypt passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Change keys for password encryption and decryption . . . . . . . . . . . . . . . . . . . . . 4-1
Digital signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Create and manage keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Chapter 5. Advanced query history . . . . . . . . . . . . . . . . . . . . . . . 5-1

Collect history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Control history collection for users . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Control history collection for databases . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Audit database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Audit data flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Audit configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Audit data capture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Service commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
System state changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Authentication events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Upgrade and downgrade best practices . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Chapter 6. Multi-Level Security and row-secure tables . . . . . . . . . . . . . . . 6-1

Security labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Security label syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
SQL commands for security labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Row-secure tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
RST caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
RST backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
RSTs and concurrent loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
© Copyright IBM Corp. 2009, 2014 iii

RSTs and external tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Appendix A. Netezza SQL and CLI commands . . . . . . . . . . . . . . . . . . A-1

Changes to Netezza SQL commands . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
ALTER CATEGORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
ALTER COHORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
ALTER DATABASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
ALTER GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
ALTER HISTORY CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . A-9
ALTER SECURITY LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
ALTER USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13
CREATE CATEGORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16
CREATE COHORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17
CREATE DATABASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18
CREATE GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20
CREATE SECURITY LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21
CREATE TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23
CREATE USER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23
DROP CATEGORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-26
DROP COHORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-27
DROP HISTORY CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . A-28
DROP SECURITY LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-29
EXECUTE AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-30
REVERT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-31
SET HISTORY CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . A-32
SHOW CATEGORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-33
SHOW COHORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-34
SHOW HISTORY CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . A-36
SHOW SECURITY LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-37
CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-38
The nzhistcleanupdb command . . . . . . . . . . . . . . . . . . . . . . . . . . . A-38
The nzverifyauditsig command . . . . . . . . . . . . . . . . . . . . . . . . . . . A-39
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Create a database security officer and database administrator . . . . . . . . . . . . . . . . . . B-1
Create a security model as database security officer . . . . . . . . . . . . . . . . . . . . . B-1
Create sample users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
Create a database and grant access . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
Create a row-secure table with permissions . . . . . . . . . . . . . . . . . . . . . . . . B-2
The engmgr role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3
The sw2 role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3
The sw1 role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-4
Show restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5
Appendix C. Enable and disable security commands . . . . . . . . . . . . . . . C-1

The enable_execute_as setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
The enable_login_constraints setting. . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
The enable_collect_history setting . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
The enable_row_security setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
The enable_audit setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1
iv IBM Netezza Advanced Security Administrator's Guide

Tables
2-1. Session SQL commands . . . . . . . 2-1 A-21. CREATE DATABASE output . . . . . A-19
2-2. Restriction setting examples . . . . . . 2-2 A-22. CREATE GROUP inputs . . . . . . . A-20
4-1. SQL language extensions . . . . . . . 4-4 A-23. CREATE GROUP output . . . . . . A-21
5-1. Audit history database options . . . . . 5-3 A-24. CREATE SECURITY LEVEL inputs A-22
5-2. Audited commands . . . . . . . . . 5-5 A-25. CREATE SECURITY LEVEL outputs A-22
5-3. State change events . . . . . . . . . 5-6 A-26. CREATE TABLE input . . . . . . . A-23
5-4. Authentication events . . . . . . . . 5-6 A-27. CREATE USER inputs . . . . . . . A-24
6-1. Pre-defined security label system values 6-2 A-28. CREATE USER output . . . . . . . A-25
6-2. All-of comparison (categories) . . . . . 6-5 A-29. DROP CATEGORY input . . . . . . A-26
6-3. Any-of comparison (cohorts) . . . . . . 6-6 A-30. DROP CATEGORY outputs . . . . . . A-26
6-4. Labels and access . . . . . . . . . 6-6 A-31. DROP COHORT input . . . . . . . A-27
A-1. Netezza SQL commands . . . . . . . A-1 A-32. DROP COHORT outputs . . . . . . A-27
A-2. ALTER CATEGORY inputs . . . . . . A-3 A-33. DROP HISTORY CONFIGURATION
A-3. ALTER CATEGORY output . . . . . . A-3 inputs . . . . . . . . . . . . . A-28
A-4. ALTER COHORT inputs . . . . . . . A-4 A-34. DROP HISTORY CONFIGURATION
A-5. ALTER COHORT output . . . . . . . A-5 outputs . . . . . . . . . . . . A-28
A-6. ALTER DATABASE input. . . . . . . A-6 A-35. DROP SECURITY LEVEL input A-29
A-7. ALTER DATABASE output . . . . . . A-6 A-36. DROP SECURITY LEVEL outputs A-29
A-8. ALTER GROUP inputs. . . . . . . . A-7 A-37. EXECUTE AS input . . . . . . . . A-30
A-9. ALTER GROUP output . . . . . . . A-8 A-38. EXECUTE AS outputs . . . . . . . A-30
A-10. ALTER HISTORY CONFIGURATION A-39. REVERT outputs . . . . . . . . . A-31
inputs . . . . . . . . . . . . . A-9 A-40. SET HISTORY CONFIGURATION inputs A-32
A-11. ALTER HISTORY CONFIGURATION A-41. SET HISTORY CONFIGURATION outputs A-32
outputs . . . . . . . . . . . . A-11 A-42. SHOW CATEGORY inputs . . . . . . A-33
A-12. ALTER SECURITY LEVEL inputs A-12 A-43. SHOW COHORT inputs . . . . . . . A-34
A-13. ALTER SECURITY LEVEL output A-13 A-44. SHOW HISTORY CONFIGURATION
A-14. ALTER USER inputs . . . . . . . . A-14 inputs . . . . . . . . . . . . . A-36
A-15. ALTER USER output . . . . . . . . A-15 A-45. SHOW HISTORY CONFIGURATION
A-16. CREATE CATEGORY input. . . . . . A-16 outputs . . . . . . . . . . . . A-36
A-17. CREATE CATEGORY outputs A-16 A-46. SHOW SECURITY LEVEL inputs A-37
A-18. CREATE COHORT inputs . . . . . . A-17 A-47. The nzhistcleanupdb inputs . . . . . A-38
A-19. CREATE COHORT outputs . . . . . . A-17 A-48. The nzverifyauditsig inputs. . . . . . A-39
A-20. CREATE DATABASE inputs . . . . . A-19 A-49. The nzverifyauditsig output . . . . . A-40
© Copyright IBM Corp. 2009, 2014 v

vi IBM Netezza Advanced Security Administrator's Guide
Electronic emission notices
When you attach a monitor to the equipment, you must use the designated
monitor cable and any interference suppression devices that are supplied with the
monitor.
Federal Communications Commission (FCC) Statement
This equipment was tested and found to comply with the limits for a Class A
digital device, according to Part 15 of the FCC Rules. These limits are designed to
provide reasonable protection against harmful interference when the equipment is
operated in a commercial environment. This equipment generates, uses, and can
radiate radio frequency energy and, if not installed and used in accordance with
the instruction manual, might cause harmful interference to radio communications.
Operation of this equipment in a residential area is likely to cause harmful
interference, in which case the user is required to correct the interference at their
own expense.
Properly shielded and grounded cables and connectors must be used to meet FCC
emission limits. IBM® is not responsible for any radio or television interference
caused by using other than recommended cables and connectors or by
unauthorized changes or modifications to this equipment. Unauthorized changes
or modifications might void the authority of the user to operate the equipment.
This device complies with Part 15 of the FCC Rules. Operation is subject to the
following two conditions: (1) this device might not cause harmful interference, and
(2) this device must accept any interference received, including interference that
might cause undesired operation.
Industry Canada Class A Emission Compliance Statement
This Class A digital apparatus complies with Canadian ICES-003.
Avis de conformité à la réglementation d'Industrie Canada
Cet appareil numérique de la classe A est conforme à la norme NMB-003 du

Canada.
Australia and New Zealand Class A Statement
This product is a Class A product. In a domestic environment, this product might

cause radio interference in which case the user might be required to take adequate
measures.
European Union EMC Directive Conformance Statement
This product is in conformity with the protection requirements of EU Council

Directive 2004/108/EC on the approximation of the laws of the Member States
relating to electromagnetic compatibility. IBM cannot accept responsibility for any
failure to satisfy the protection requirements resulting from a nonrecommended
modification of the product, including the fitting of non-IBM option cards.
© Copyright IBM Corp. 2009, 2014 vii

This product is an EN 55022 Class A product. In a domestic environment, this
product might cause radio interference in which case the user might be required to
take adequate measures.
Responsible manufacturer:
International Business Machines Corp.

New Orchard Road
Armonk, New York 10504
914-499-1900
European Community contact:
IBM Technical Regulations, Department M456

IBM-Allee 1, 71137 Ehningen, Germany
Telephone: +49 7032 15-2937
Email: tjahn@de.ibm.com
Germany Class A Statement
Deutschsprachiger EU Hinweis: Hinweis für Geräte der Klasse A EU-Richtlinie

zur Elektromagnetischen Verträglichkeit
Dieses Produkt entspricht den Schutzanforderungen der EU-Richtlinie

2004/108/EG zur Angleichung der Rechtsvorschriften über die elektromagnetische
Verträglichkeit in den EUMitgliedsstaaten und hält die Grenzwerte der EN 55022
Klasse A ein.
Um dieses sicherzustellen, sind die Geräte wie in den Handbüchern beschrieben zu

installieren und zu betreiben. Des Weiteren dürfen auch nur von der IBM
empfohlene Kabel angeschlossen werden. IBM übernimmt keine Verantwortung für
die Einhaltung der Schutzanforderungen, wenn das Produkt ohne Zustimmung der
IBM verändert bzw. wenn Erweiterungskomponenten von Fremdherstellern ohne
Empfehlung der IBM gesteckt/eingebaut werden.
EN 55022 Klasse A Geräte müssen mit folgendem Warnhinweis versehen werden:

“Warnung: Dieses ist eine Einrichtung der Klasse A. Diese Einrichtung kann im
Wohnbereich Funk-Störungen verursachen; in diesem Fall kann vom Betreiber
verlangt werden, angemessene Maßnahmen zu ergreifen und dafür
aufzukommen.”
Deutschland: Einhaltung des Gesetzes über die

elektromagnetische Verträglichkeit von Geräten
Dieses Produkt entspricht dem “Gesetz über die elektromagnetische Verträglichkeit

von Geräten (EMVG)”. Dies ist die Umsetzung der EU-Richtlinie 2004/108/EG in
der Bundesrepublik Deutschland.
Zulassungsbescheinigung laut dem Deutschen Gesetz über die

elektromagnetische Verträglichkeit von Geräten (EMVG) (bzw. der
EMC EG Richtlinie 2004/108/EG) für Geräte der Klasse A
Dieses Gerät ist berechtigt, in Übereinstimmung mit dem Deutschen EMVG das
EG-Konformitätszeichen - CE - zu führen.
Verantwortlich für die Einhaltung der EMV Vorschriften ist der Hersteller:
viii IBM Netezza Advanced Security Administrator's Guide

International Business Machines Corp.
New Orchard Road
Armonk, New York 10504
914-499-1900
Der verantwortliche Ansprechpartner des Herstellers in der EU ist:
IBM Deutschland
Technical Regulations, Department M456
IBM-Allee 1, 71137 Ehningen, Germany
Telephone: +49 7032 15-2937
Email: tjahn@de.ibm.com
Generelle Informationen: Das Gerät erfüllt die Schutzanforderungen nach EN 55024

und EN 55022 Klasse A.
Japan VCCI Class A Statement
This product is a Class A product based on the standard of the Voluntary Control
Council for Interference (VCCI). If this equipment is used in a domestic
environment, radio interference might occur, in which case the user might be
required to take corrective actions.
Japan Electronics and Information Technology Industries

Association (JEITA) Statement
Japan Electronics and Information Technology Industries Association (JEITA)

Confirmed Harmonics Guidelines (products less than or equal to 20 A per phase)
Japan Electronics and Information Technology Industries

Association (JEITA) Statement
Japan Electronics and Information Technology Industries Association (JEITA)

Confirmed Harmonics Guidelines (products greater than 20 A per phase)
Electronic emission notices ix

Korea Communications Commission (KCC) Statement
This is electromagnetic wave compatibility equipment for business (Type A). Sellers
and users need to pay attention to it. This is for any areas other than home.
Russia Electromagnetic Interference (EMI) Class A Statement
People's Republic of China Class A Electronic Emission

Statement
Taiwan Class A Compliance Statement
x IBM Netezza Advanced Security Administrator's Guide

Regulatory and compliance
Regulatory Notices
Install the NPS® system in a restricted-access location. Ensure that only those
people trained to operate or service the equipment have physical access to it.
Install each AC power outlet near the NPS rack that plugs into it, and keep it
freely accessible.
Provide approved circuit breakers on all power sources.
Product might be powered by redundant power sources. Disconnect ALL power

sources before servicing.
High leakage current. Earth connection essential before connecting supply. Courant
de fuite élevé. Raccordement à la terre indispensable avant le raccordement au
réseau.
Homologation Statement
This product may not be certified in your country for connection by any means
whatsoever to interfaces of public telecommunications networks. Further
certification may be required by law prior to making any such connection. Contact
an IBM representative or reseller for any questions.
© Copyright IBM Corp. 2009, 2014 xi

xii IBM Netezza Advanced Security Administrator's Guide
About this publication
This guide describes the advanced security features available for the IBM Netezza®
data warehouse appliances. These features include Multi-Level Security, user login
controls, audit history, and user masquerading.
Audience
This guide is written for administrators who are using the IBM Netezza
Multi-Level Security and other advanced security features.
If you need help

If you are having trouble using the IBM Netezza appliance, follow these steps:
1. Try the action again, carefully following the instructions for that task in the
documentation.
2. Go to the IBM Support Portal at: http://www.ibm.com/support. Log in using
your IBM ID and password. You can search the Support Portal for solutions. To
submit a support request, click the Service Requests & PMRs tab.
3. If you have an active service contract maintenance agreement with IBM, you
can contact customer support teams by telephone. For individual countries,
visit the Technical Support section of the IBM Directory of worldwide contacts
(http://www.ibm.com/support/customercare/sas/f/handbook/contacts.html).
How to send your comments

You are encouraged to send any questions, comments, or suggestions about the
IBM Netezza documentation. Send an email to netezza-doc@wwpdl.vnet.ibm.com
and include the following information:
v The name and version of the manual that you are using
v Any comments that you have about the manual
v Your name, address, and phone number
We appreciate your suggestions.
© Copyright IBM Corp. 2009, 2014 xiii

xiv IBM Netezza Advanced Security Administrator's Guide
Chapter 1. Overview
The Advanced Security features of theIBM Netezza data warehouse appliances
provide more options for securing access to your appliance and to the user data it
contains.
For more information about system security, see the IBM Netezza System
Administrator’s Guide.
Basic security model

The IBM Netezza security model is a combination of administrator privileges that
are given to users and groups, object privileges for specific objects, and object
privileges for classes of objects.
As part of the model, any privilege that is granted to a group is automatically

granted to (that is, inherited by) any user in that group. Privileges are additive,
which means that you cannot remove a privilege from a user who is granted that
privilege as a group member.
Each object has an owner. Individual owners automatically have full access to their
objects and do not require individual object privileges to manage them.
In the Netezza system, the admin user owns all predefined objects. The admin
user has full access to all functions and objects, which is similar to the super user
(root) in UNIX. There are no privilege records associated with the admin user. You
cannot delete the admin user or change its name. Unlike all other objects, admin
user has no owner.
The PUBLIC group is also predefined. All users automatically are members of the
group. You cannot delete the PUBLIC group or change its name. Its owner is the
admin user.
Advanced security
The advanced security feature on the IBM Netezza system has the following areas:
v User login control provides session context and access restrictions.
v Masquerading provides a way for a user to operate as another user, with all the
privileges of that user.
v Advanced query history captures details about the user activity on the Netezza
system, such as the queries that are run, query plans, table access, column
access, session creation, and failed authentication requests.
v Multi-Level Security (MLS) is an abstract security model, which Netezza uses to
define rules to control access to table rows.
The advanced security features are enabled by default on IBM Netezza systems.
You can enable or disable the features with registry variables as described in
Appendix C, “Enable and disable security commands,” on page C-1.
© Copyright IBM Corp. 2009, 2014 1-1

System security
The most important aspect of system security is control of physical access to the
IBM Netezza appliance. Netezza systems are typically installed in secure data
centers to ensure that physical access is restricted to permitted users.
Database security, including Multi-Level Security, depends on access through the

database interfaces. Access to the Linux host other than through Netezza-supplied
client software is discouraged. Carefully control and manage access. Any process
which is not installed and qualified by Netezza and running as root or as nz can
cause denial of service and gain access to data without database access controls.
User-defined functions (UDFs) and user-defined aggregates (UDAs) run from

within the Netezza security domain and might gain access to data without
database access controls. Carefully control the UDFs and UDAs that are installed
on the system.
Using the Netezza host for purposes other than running the Netezza database
software is a security issue, and can create denial-of-service situations. For
example, filling the host disks with non-Netezza data can stop audit logging and
therefore stop activity on the system. Creating demand on the processors, memory,
or disk subsystem can all interfere with provision of database services.
The admin user is the super user in the Netezza system database. It is necessary to
have such a user for initial configuration and to manage configuration and security
problems. However, the admin user can control all users and see all data – if not
directly, then by the ability to create objects that allow such access. Do not use the
admin user login in normal operations. Give explicit privileges to other user
identities for the management of the system and conduct DBA and operations
tasks on the system.
For example, to control the Multi-Level Security model and create users, create a
Netezza database user account for a Database Security Officer (DSO) with only
certain privileges, as in the following example. (For more information, see
Appendix B, “Examples,” on page B-1.)
SYSTEM.ADMIN(ADMIN)=> CREATE USER dso;
CREATE USER
SYSTEM.ADMIN(ADMIN)=> GRANT MANAGE SECURITY TO dso;
GRANT
SYSTEM.ADMIN(ADMIN)=> GRANT USER TO dso;
GRANT
View the security setup

While various SHOW commands can display security information, such as categories,
cohorts, and levels, the system also has the following views available:
v _v_security_category
v _v_security_cohort
v _v_security_cohort_hierarchy
v _v_security_level
v _v_user_security
1-2 IBM Netezza Advanced Security Administrator's Guide

Chapter 2. User login control
This section describes ways to control user logins to create sessions. A session
represents a connection and successful login to the IBM Netezza appliance.
For more information about sessions and creating users and groups, see the IBM
Netezza System Administrator’s Guide.
Session context
When a user logs in through an application and uses the IBM Netezza system, all
work is done in the context of a session. A session is owned by its session user,
who is constant after the session is created. You can control when sessions can be
created and how many concurrent (simultaneous) sessions can occur.
The session user is not affected by running EXECUTE AS statements or running

stored procedures. The EXECUTE AS statement affects the current user and does
not enforce access time or concurrent sessions restrictions.
You can access session operations through any SQL interface. The following table
shows examples of SQL statements used for sessions, where each session has an
ID.
Table 2-1. Session SQL commands
SQL statement Meaning
SHOW SESSION [ID | ALL] [VERBOSE] Display the active session in verbose mode
ALTER SESSION [ID] PRIORITY Change the session priority
ALTER SESSION [ID] ROLLBACK Roll back any transactions in the session
TRANSACTION
DROP SESSION [ID] Remove the session
The security system controls what users and sessions you can access. Although
session lists are accessible to all users, you can read only the names of objects for
which you have List privileges.
Related concepts:
Chapter 3, “Masquerading,” on page 3-1
Concurrent sessions
You can limit the number of concurrent sessions that are owned by a single user,
and you can set different concurrent session values for each user.
A user can be limited by inherited restrictions from a group.

v If the number of concurrent sessions is not set for a user, the system uses the
minimum value specified for the groups to which the user belongs.
v If the user or any of the groups do not have a concurrent session limit, then the
number of concurrent sessions is unlimited.
For example, to set the number of concurrent sessions to 3 for user John Doe:

SYSTEM.ADMIN(ADMIN)=> CREATE USER jdoe CONCURRENT SESSIONS 3;
Access time control

You can restrict session creation to certain times of the day or days of the week.
Session restrictions are defined by the ACCESS TIME clause.

v If the USER has a specific setting, that setting is used.
v If the USER has no setting, but the GROUP statement of the user has a specific
setting, the group setting is used.
v If any GROUP of the user explicitly disallows access, then the session creation is
rejected.
v If a USER belongs to different GROUPS with different access times, the most
restrictive GROUP setting is used. So a USER is allowed access if none of the
GROUPS restricts the time.
The following table shows command examples for different restrictions on a user.
The days are numbered 1 - 7, beginning with Sunday as 1.
Table 2-2. Restriction setting examples
Restriction Definition
ACCESS TIME ALL; No restriction on access.
ACCESS TIME DEFAULT; Restrictions are defined by GROUP settings.
ACCESS TIME (DAY ALL START Access is allowed every day from 8:00 a.m. to 6:00
'8:00' END '18:00'); p.m.
ACCESS TIME (DAY 3,4,5 START Access is allowed Tuesday, Wednesday, and Thursday
'7:00' END '18:00', DAY 2, 6 START from 7:00 a.m. to 6:00 p.m., and on Monday and
'6:00' END '15:00'); Friday from 6:00 a.m. to 3:00 p.m.
The times define when users can log in, but users can remain on the system past
the restriction time, if they logged in during the allowed timeframe and do not log
out.
The following example creates a user with a concurrent session limit of 2 and an
access time that ranges from 7:00 a.m. to 7:00 p.m.:
SYSTEM(ADMIN)=> CREATE USER jdoe CONCURRENT SESSIONS 2 ACCESS TIME
(DAY ALL START ’7:00’ END ’19:00’);
CREATE USER
The following example creates a group with a concurrent session limit of 8 and an
access time that ranges from Tuesday to Thursday, from 9:00 a.m. to 6:00 p.m.:
SYSTEM(ADMIN)=> CREATE GROUP finance CONCURRENT SESSIONS 8 ACCESS TIME
(DAY 3,4,5 START ’9:00’ END ’18:00’);
CREATE GROUP
Password restrictions
This section describes some techniques to control password policies for IBM
Netezza database users.
The following features allow for greater control in password setup for users:
v Password expiration

You can specify the number of days that an IBM Netezza database user account
password is valid as a system-wide setting. You can also specify the password
expiration rate on a per-user and per-group basis. You can also expire an
account password immediately. For more information, see the IBM Netezza
System Administrator’s Guide.
v Password authentication
To set the password authentication for a user to LOCAL, use the AUTH LOCAL
option for CREATE USER or ALTER USER. This option sets the overriding
authentication for the user to LOCAL (checks the password against the local
database/catalog), regardless of the connection setting. To revert this setting to
the default setting, use the AUTH DEFAULT option.
v Password string restrictions
You can set a password strength check, based on restrictions. For more
information, see the IBM Netezza System Administrator’s Guide.
For more information about the specific usage of SQL command-line options, see
the IBM Netezza Database User’s Guide.
Chapter 2. User login control 2-3

Chapter 3. Masquerading
Masquerading is a way for a client to operate as another user, with all the
privileges of that user. Masquerading is a powerful feature. Use masquerading
with caution, as you would when using the root command in UNIX or the su
command in Linux.
The masquerading feature allows application servers to do authentication

separately from the IBM Netezza appliance. It also allows a server to use one
connection to the Netezza system for a number of users while still recording those
users with the Netezza system.
In this use case, system security is set up so that users do not access an Netezza
database directly, but do it through an application. The application allows certain
users access to the database. Each database user has an associated security profile,
determining what information can be accessed.
The Netezza system does not do the user authentication, but leaves that to the
application. In masquerading, a client uses the application to access the database as
another user (called a target user), thus accessing the database with the security
profile of the target user.
Masquerading is done with the EXECUTE AS command. To use this command,

you need EXECUTE AS privileges on the target user. If you issue the command
without the required privilege, an error message is displayed.
To run EXECUTE AS, use the following syntax, where target-user-name is the name
of an existing user for whom you have EXECUTE AS privilege:
EXECUTE AS target-user-name
As explained in Chapter 2, “User login control,” on page 2-1, opening a connection

to the database establishes a session, and the session user is recorded.
Masquerading changes the current user in the session context. Subsequent
permission checks use that value, while the session user function still shows the
original user.
The following command example begins a session for user John, with the
password ABCD, and accessing the database BIZ:
nzsql -u JOHN -pw ABCD -db BIZ
BIZ.SCM(JOHN)=>
John uses the EXECUTE AS command to masquerade as the user Hank:

BIZ.SCM(JOHN)=> EXECUTE AS HANK;
EXECUTE AS
To see which is the session user and which is the current user, run the following
commands:
BIZ(JOHN)=> SELECT session_user, current_user;
SESSION_USER | CURRENT_USER
--------------+--------------
JOHN | HANK
(1 row)

To reverse the EXECUTE AS command, use the REVERT command, which changes
the current user back:
BIZ(JOHN)=> REVERT;
REVERT
BIZ(JOHN)=> SELECT session_user, current_user;
--------------+--------------
JOHN | JOHN
(1 row)
Related reference:
“Session context” on page 2-1
Nesting and stored procedures

You can nest EXECUTE AS and REVERT commands to switch the current user. In
the following example, John masquerades as Hank, then masquerades as Tom, and
reverts:
BIZ.SCM(JOHN) = > EXECUTE AS HANK;
EXECUTE AS
BIZ.SCM(JOHN) = > SELECT session_user, current_user;
--------------+--------------
JOHN | HANK
(1 row)
BIZ.SCM(JOHN) = > EXECUTE AS TOM;
EXECUTE AS
BIZ.SCM(JOHN) = > SELECT session_user, current_user;
--------------+--------------
JOHN | TOM
(1 row)
BIZ.SCM(JOHN)=> REVERT
REVERT
BIZ.SCM(JOHN) => SELECT session_user, current_user;
--------------+--------------
JOHN | HANK
(1 row)
BIZ.SCM(JOHN)=> REVERT
REVERT
BIZ.SCM(JOHN) => SELECT session_user, current_user;
--------------+--------------
JOHN | JOHN
(1 row)
You can create stored procedures to use nested masquerading commands. For the
next example, first login as Admin and set up a group of users and privileges.
BIZ.SCM(ADMIN)=> CREATE USER john PASSWORD ’john’;
CREATE USER
BIZ.SCM(ADMIN)=> CREATE USER hank PASSWORD ’hank’;
CREATE USER
BIZ.SCM(ADMIN)=> CREATE USER tom PASSWORD ’tom123’;
CREATE USER
BIZ.SCM(ADMIN)=> GRANT EXECUTE AS ON tom to hank;
GRANT
BIZ.SCM(ADMIN)=> GRANT LIST ON john,hank,tom to john, hank, tom;
GRANT
BIZ.SCM(ADMIN)=> GRANT CONNECT ON dev to john, hank, tom;
GRANT
BIZ.SCM(ADMIN)=> GRANT CREATE PROCEDURE to hank;
GRANT

Log in as Hank and create a stored procedure. Depending on the inputs, the
procedure runs as HANK (proc_as 1) or as TOM (proc_as 6).
DEV.SCM(ADMIN)=> \c dev hank hank
You are now connected to database dev as user hank.
DEV.SCM(HANK)=> CREATE OR REPLACE PROCEDURE proc_as(INTEGER) RETURNS
INTEGER LANGUAGE NZPLSQL AS BEGIN_PROC DECLARE inval ALIAS FOR $1;
cuser VARCHAR(128); suser VARCHAR(128); BEGIN IF (inval > 5) THEN
EXECUTE IMMEDIATE ’EXECUTE AS TOM’; END IF; SELECT CURRENT_USER INTO
cuser; SELECT SESSION_USER INTO suser; RAISE NOTICE ’Current User <% >
Session User <% > ’, cuser, suser; RETURN inval; END; END_PROC;
CREATE PROCEDURE
DEV.SCM(HANK)=> CALL proc_as(1);
NOTICE: Current User <HANK> Session User <HANK>
PROC_AS
---------
1
(1 row)
DEV.SCM(HANK)=> CALL proc_as(6);
NOTICE: Current User <TOM> Session User <HANK>
PROC_AS
---------
6
(1 row)
HANK grants JOHN the EXECUTE permission on the procedure, and runs the
procedure as JOHN. The procedure does not include the REVERT command,
because this is done automatically on a return from a stored procedure. This means
that you exit a stored procedure with the same current user and session user you
had when calling the procedure.
DEV.SCM(HANK)=> GRANT EXECUTE on proc_as(integer) to john;
GRANT
DEV.SCM(HANK)=> \c dev john john
You are now connected to database dev as user john.
DEV.SCM(JOHN)=> CALL proc_as(1);
NOTICE: Current User <HANK> Session User <JOHN>
PROC_AS
---------
1
(1 row)
DEV.SCM(JOHN)=> CALL proc_as(6);
NOTICE: Current User <TOM> Session User <JOHN>
PROC_AS
---------
6
(1 row)
Chapter 3. Masquerading 3-3

Chapter 4. Key management
In the IBM Netezza system, keys are used to encrypt passwords and for digital
signing of audit data. This section describes the key management features used
with the security capabilities.
For more information about creating encrypted passwords, see the IBM Netezza
System Administrator’s Guide.
Encrypt passwords
In the IBM Netezza system, passwords now can be encrypted for both the host and
the client by using the AES_256 algorithm (AES with a 256-bit key).
On the host side, passwords can be encrypted (and decrypted for verification
during authentication) by using a host key, a symmetric key stored on the host in
encrypted form. You can choose an encryption key in a keystore to be the host key.
On the client side, the nzpassword command is used to store the user passwords.
Individual clients have unique client keys to encrypt the user passwords. For more
information about nzpassword usage, see the IBM Netezza Database User’s Guide.
When nzpassword is used for the first time, it generates a native client key, which is
stored on the client machine and serves to encrypt the user passwords on the
client. The administrator does not choose this key, it is generated by the system.
Note: The keystore encryption process and utilities are not related to the IBM
Netezza SQL Extensions toolkit encryption functions.
Change keys for password encryption and decryption

On the host, you can change the key used for encrypting and decrypting
passwords by using the syntax as in the following example:
SET SYSTEM DEFAULT HOSTKEY TO <keystore name>.<key name>;
<keystore name>
Name of the keystore.
<key name>
Name of the key, which must be of type AES_256.
Or you can set the default to NONE, which reencrypts the format on the host side,
as in the following example:
SET SYSTEM DEFAULT HOSTKEY TO NONE;
Since some users can have a mix of host and client versions, the .nzpassword file
on the client might need to be accessed by different clients, some that understand
the old Blowfish format, and some that understand both the Blowfish format and
the AES_256 format. In such cases, the .nzpassword file needs to be maintained in
the old format. If you are using the Blowfish format, you can continue to add
passwords in that format.

To enforce the improved security available with the AES_256 format, you can
convert old format passwords to new by running nzpassword resetkey. You can
also run nzpassword resetkey to change the client key if the passwords are already
in AES_256 format. This command creates a client key and re-encrypts all the user
passwords stored on the client with a newly auto-generated client key. For
information about this command, see the IBM Netezza Database User’s Guide.
To convert all AES_256-encrypted passwords to Blowfish-encrypted passwords,

such as for a major downgrade, run nzpassword resetkey -none. This command
re-encrypts the user passwords in the old format and stores them. For more
information, see the IBM Netezza System Administrator’s Guide.
Digital signing
Digital signing of audit data is used to show attempts at log tampering and
provide for non-repudiation of the audit log.
Each file within each load gets a digital signature. The signature and the sequence
information are stored in the audit database.
Digital signing on the system is done by setting up a public/private cryptographic

pair of keys and setting the history configuration to use that key pair.
To set the audit digital signature key, use the syntax as in the following example:
ALTER HISTORY CONFIG
KEY <keystore name>.<key name>;
To turn off signing, use the following command:

ALTER HISTORY CONFIG
KEY NONE
To verify the signature, in addition to displaying the keys,IBM Netezza provides

the following sample script that checks the key against the signature:
nzverifyauditsig.sh
The output returns a verification or a failure message, as in the following:

v signature verified
v signature could not be verified
Create and manage keys

Keys and key-related data are associated with a keystore. You can create multiple
keystores and keys, which are managed through any SQL interface, such as ODBC.
Before you create or import a key, you must first create the keystore to hold the
key.
Important: Because a key is stored like an external table, it is not captured by a

regular backup/restore function. Be sure to back up the key after you create it. You
must save all keys, either in the keystore or by exporting them by using SHOW, to
verify the signatures in the audit database.
To create a keystore, use the syntax as in the following example:

CREATE KEYSTORE <name> TYPE <type> PASSWORD <password>;

<name>
The name for the keystore.
<type>
The value is LOCAL, the only type currently supported.
<password>
Password that is used as the key encryption key (KEK) for any crypto keys
that you create and associate with that keystore.
To create a key in a keystore, use the following command:

CREATE CRYPTO KEY <keystore name>.<key name> TYPE <type>
<keystore name>
<key name>
Name of the key.
<type>
The encryption type. The supported types are asymmetric keys of type
DSA_KEYPAIR or DSA_KEYPAIR_2048, and symmetric keys of type
AES_256.
Netezza uses an encryption key based on the keystore to encrypt and decrypt all
the keys in that keystore.
To import a key into a keystore, you use the CREATE CRYPTO KEY command
with two additional fields VALUE and PASSWORD, as in the following command:
CREATE CRYPTO KEY <keystore name>.<key name> TYPE <type> VALUE <value>
PASSWORD <password>
<keystore name>
<key name>
Name of the key.
<type>
The encryption type. The supported types are asymmetric keys of type
DSA_KEYPAIR or DSA_KEYPAIR_2048, and symmetric keys of type
AES_256.
<value>
The key pair (encrypted form) that you want to import to the keystore. The
imported key has a required format that includes three parts separated by
the dollar sign ($) character:
v The first part of the key is the salt value used to create the key based on
the password. It is 16 bytes base64 encoded, resulting in a string of 23
padded bytes. Netezza uses PBKDF2-SHA256 to derive the
password-key from the password string and the salt.
v The second and third parts are the encrypted key (32 bytes) and
initialization vector (16 bytes), for a total of 48 bytes base64 encoded
resulting in a string of 64 bytes. The key is encrypted in CBC mode.
Netezza uses the Botan library for the base64 encoding and
encrypt/decrypt functions.
<password>
Used to decrypt the key <value> when you import a key.
Chapter 4. Key management 4-3

The following is a sample command to import a crypto key:
create crypto key mykeyst.mykey1 type aes_256 value
’c2vaXGjnR4b2Sj8hdRqaMQ==$q6fdHB4wfXNm3ySRpugjhzSUuTloPWa7MwhdBUKWUISK
fPJBcfSul/krWk3hG1+7’ password ’mysecureword’;
SQL language extensions were added for the key and keystore operations, as
shown in the following table. You must have MANAGE SECURITY privileges to
use these commands.
Table 4-1. SQL language extensions
Command Meaning
CREATE keystore Creates a keystore
SHOW keystore Displays the keystore configuration in summary or detail
(VERBOSE) format
ALTER keystore Changes the keystore parameters
DROP keystore Deletes a keystore
CREATE CRYPTO Sets a key entry
KEY
SHOW CRYPTO KEY Displays key-entry details
DROP CRYPTO KEY Deletes a key entry

Chapter 5. Advanced query history
Query history captures details about the user activity on the IBM Netezza system,
such as the queries that are run, query plans, table access, column access, session
creation, and failed authentication requests. This section describes the advanced
query features used with the new security capabilities.
History information is saved in a history database. Users with the correct

privileges can review the query history information for details about the users and
activity on the Netezza system. These features enhance the query history with
auditing and the following benefits:
v Guaranteed audit capture of all operations
v Digital signing of audit data
v Audit data stored in row-secure tables
v Secure data offload to a different Netezza system, lowering the impact on a
production system and improving the security of the audit
For more information about query history, see the IBM Netezza System
Collect history
In some high-security environments, the activities of all users must be logged at all
times. In other environments, it is not necessary to capture all activity all of the
time. The COLLECT HISTORY command enables the security administrator to
control which users, groups, and databases are subject to having history collected.
The user session is the unit of history collection control. The setting is calculated
on session creation and is not altered after that time. The session user and the
connected database both must be set to collect history or no history is collected for
the session.
History in a session is collected if both the user setting and the database setting are
COLLECT HISTORY ON, which is the default. If the group specifications conflict,
history is collected. If the security administrator does not want to collect history,
the administrator can ALTER the database and set COLLECT HISTORY OFF.
Control history collection for users

A user is set to collect history based on the following:
v Session user
v Groups the session user belongs to
v The connected database
The user setting is based on the following:

v If the COLLECT HISTORY command of a user is explicitly set, that is the user
setting.
v If the COLLECT HISTORY command of a user is not set, then the groups to
which the user belongs are examined.
v If the groups of a user are not set, then the setting defaults to COLLECT
HISTORY ON.

v If any of the groups of a user is set to COLLECT HISTORY ON, then the setting
is COLLECT HISTORY ON.
v Otherwise, the setting is COLLECT HISTORY OFF.
With these rules, you can avoid collecting history on operations against a
development or test database, while allowing identified users (or users in an
identified group) to have their work audited.
Thus groups can be used as roles. For example, a GROUP might be granted update
access on a table and also be set to collect history. A different group might be
created for table readers that does not collect history.
Control history collection for databases

While the database administrator controls whether history is collected for a
database, the session is the unit of collection. The default is to collect history for
the user and the database.
Use the COLLECT HISTORY clause on the CREATE DATABASE or ALTER

DATABASE statements to disable or enable history collection for a database.
To create the database and turn on the COLLECT HISTORY feature, use the
following syntax:
CREATE DATABASE database-name [create-db-clause]...
create-db-clause ::=
... existing clauses ...
| COLLECT HISTORY ON
With cross-database access, settings might be different. The history collection

setting of the session creation determines access.
For example, if the session setting is set to ON, history is collected, even if the
cross-database setting is OFF. If the session setting is OFF, history is not collected,
even if the cross-database settings are set to ON.
Audit database
The audit database is stored in tables that use row-level security. Each row is given
a label derived from combining the label of the user who is doing the action and
the audit categories associated with that user. The label of the user is used so that
someone who views the audit data is able to see the original data as well, since
what is captured for the operations might contain some of the original data.
Access to the data is restricted by adding in audit categories, which can prevent
the user that is doing the action from viewing the audit data. It also allows the
audit data to be partitioned among auditors.
There can be two IBM Netezza systems, the source system where the audit data is
captured, and the target system, where the audit data is stored. These systems can
be the same system.
To create the audit database, run the following command aimed at the target
system, configuring desired options. If an option is not specified, the associated
environment variable is used.
/nz/kit/bin/adm/nzhistcreatedb [options]

The following table explains the options available.
Table 5-1. Audit history database options
Option Description
-d | --db= The name of the history database to create.
[DBNAME]
-n | --host=[HOST] The host name of the target Netezza system. The host name is also
specified in the NZ_HOST variable.
-t | The type of database to create. You can specify q (or Q or query) to
--db-type=[DBTYPE] create a query history database, or a (or A or audit) for an audit
history database. For more information on query history databases,
see the IBM Netezza System Administrator’s Guide.
-o | An existing database user account which will be made the owner
--OWNER=[USER] of the history database. The specified user account must have
Create Database privilege. The default is NZ_USER. You cannot
specify the admin user account. If you specify a different account
for the -o and -u arguments (owner and user), the specified owner
account must be granted List privileges on the User class.
-p | User flag that is the password of the user on the target Netezza
--pwd=[PASSWORD] system. The password is also set in the NZ_PASSWORD variable.
-v | --schema=[VER] The schema version of the history database to be created. Starting
in Netezza Release 4.6, the number is 1. In Release 7.0.3, the
version number changed to 2 to support multiple schemas and
other changes. In Release 7.1, the version number changed to 3 to
support scheduler rules and client information fields. You could
create a version 1 or 2 database for backward compatibility, but it is
highly recommended that 7.1 or later systems use version 3 to
capture the most accurate history information.
The version must match the version number specified for the active
history configuration; otherwise, the loader process will fail.
-h | --help Display the help text.
-u | --USER=[USER] The user name on the target system used to load audit data to the
database. The command configures privileges to allow the user to
write to the audit database, but not to read from it.
Related reference:
“The nzhistcleanupdb command” on page A-38
Audit data flow

Components which generate audit log information are on the host. The data flow
is as follows:
1. Host processes send log information to the audit capture process.
2. The audit capture process stores the log information in buffers, and periodically
sends the data to disk.
3. The disk files are read by a separate audit loader process.
4. The data is loaded into an IBM Netezza database. This database can be on the
same or a different Netezza system, but if different, both systems must have an
identical security configuration of security levels, cohorts, and categories.
Since loading requires that the Netezza database to be online and available,
loading is separate from the capture function.
Chapter 5. Advanced query history 5-3

Important: If the size of staged audit data exceeds the set limit, the audit capture
server cannot write more log data, and returns errors. All new activity that
requires audit logging fails until the audit data can be loaded and disk space freed.
If audit logging fails, the Netezza system goes offline. Excessive loading of
auditing information can affect performance.
Audit configuration
You can configure a system for audit logging or query history, but not both. Audit
logging provides a superset of the information collected by query history.
Audit configuration is done in the following steps:

1. Determine the user name of the user on the target IBM Netezza system to write
the audit. Use a user with no privileges. The nzhistcreatedb command gives
the audit-writing user privileges to write to the tables in the audit database, but
not to read from them.
2. If using a remote system as the target system, verify that the security model of
the source system matches the target system for level, cohort, and category. A
Netezza target system can support audit databases that load from several
source Netezza systems.
3. Run nzhistcreatedb on the target Netezza system.
4. Define the configuration on the source Netezza system.
5. Set the configuration to be active.
6. Stop and start the source system by using the nzstop and nzstart commands.
The following information must be specified to configure audit logging:

v Target database to use for logging.
v Target database credentials.
v Maximum disk space to use for buffering audit data.
v Maximum time between when data is written to the buffer file and when it is
loaded into the audit database.
After data is captured, it is signed, even if the data does not get loaded. Signing is
done with the history configuration that is current during the capture phase of the
operation, not the load phase. For more information, see the CREATE HISTORY
CONFIGURATION command in the IBM Netezza Database User’s Guide.
Audit data capture

You can capture additional data in the following areas with the query history
extensions:
v Service commands
v System state changes
v Authentication events
Service commands
A subset of the CLI can be audited by setting the SERVICE collect flag in the
History Configuration. The CLI commands in the following table are captured, and
the SERVICETYPE values are used in the history database.

Table 5-2. Audited commands
Command SERVICETYPE
nzbackup 1
nzrestore 2
nzreclaim 3
nzsfi 4
nzspu 5
nzstate 6
nzstats 7
nzsystem 8
nzevent (-dump 9
option)
All the commands in previous table are associated with the IBM Netezza “system
user” login and password. Audited data relates each command invocation to the
invoker session.
Even if a service command fails due to lack of privileges, it is still captured. The
data does not indicate whether the service finished successfully or not. Service
attempts that fail at login based on username/password are captured as failed
authentications.
The following list shows certain CLI commands that are not captured, because they
are already audited through SQL or they do not connect to the database.
v nzcontents
v nzconvert
v nzhostbackup
v nzhostrestore
v nzstart
v nzstop
v nzwebstart
v nzwebstop
v nzload
v nzpassword
v nzsession
v nzsql
v nztopology
v nzrev
v nzinventory
v nzevent (options other than dump)
System state changes

State changes are captured with the default 'PUBLIC::' security label and are not
related to a user account. State change capture is determined by the STATE collect

flag in the History Configuration. Whenever any state change event is captured,
the current version of the system is included as part of the captured data, to allow
for tracking upgrades and downgrades.
The following table lists the state change events that are captured.
Table 5-3. State change events
Event CHANGETYPE
System changed to Online 1
System changed to a Paused state 2
System changed to an Offline state 3
System changed to a Stopped state 4
Related concepts:
Chapter 6, “Multi-Level Security and row-secure tables,” on page 6-1
Authentication events
The advanced security feature captures additional events related to failed
authentications. Failed authentication data is unrelated to any current sessions.
These events are captured in the $hist_failed_authentication table.
The following table shows the authentication events captured.

Table 5-4. Authentication events
Event FAILURETYPE
Failed authentication due to bad username/password 1
Failed authentication due to concurrency 2
Failed authentication due to user access time limits 3
User account disabled after too many failed password attempts 4
The user name captured might or might not be the name of a valid user. The data
captured is also security-sensitive, so the failed authentication data is always
captured with the OMNI:OMNI:OMNI security label, requiring the highest level of
access to view this data.
Related concepts:
Chapter 6, “Multi-Level Security and row-secure tables,” on page 6-1
Upgrade and downgrade best practices

When you upgrade or downgrade your IBM Netezza system, you may have to
create a history database to use the correct history version settings.
The history database version specifies the kind of information that the history
database collects for the queries and sessions that occur on your system. Starting in
Release 4.6, the history database version was 1. In Release 7.0.3, the version of the
history database changed to 2 to collect information related to multiple schema
support and also captures history when users change to a new database or a new
schema in a session using the SET CATALOG and SET SCHEMA commands. In

Release 7.1, the history version changed to 3 to collect information related to the
scheduler rules that apply to queries and the client information fields that users
can specify for sessions.
When you upgrade to 7.1 or later, your existing version 1 and 2 history
configurations continue to work and collect data, but the information may not
accurately capture changes relating to the 7.1 features. As a best practice, you
should create a new version 3 history database and collect the latest information
going forward. The older history databases will become dormant (that is, no new
data will be loaded into them after you start using the version 3 database), but you
can still query against the older history database as needed.

Chapter 6. Multi-Level Security and row-secure tables
Multi-Level Security is an abstract security model, which IBM Netezza uses to
define rules to control user access to row-secure tables (RSTs). A row-secure table is
a database table with security labels on rows to filter out users without the
appropriate privileges. The results that are returned on queries differ based upon
the privileges of the user who makes the query. This section describes ways of
using Multi-Level Security.
The set of user access privileges is called a security profile. Every user (also called
a principal) created on the system gets at least the default security profile, at the
lowest possible level. When a user attempts to access a table row, the system
checks the user’s profile against the row security label; if the profile allows, the
user can access the row.
The following sections explain the components of the access rules and how they
interact with each other.
For more information about SQL, see the IBM Netezza Database User’s Guide.
Related concepts:
“System state changes” on page 5-5
“Authentication events” on page 5-6
Security labels
The security label has three dimensions: level, category, and cohort.
You can apply one, two, or all three dimensions to a row.

Level Levels are ordered, from a less secure lower level (such as “PUBLIC”), to a
more secure higher level (such as “Top Secret”). Every table row and user
has only one level.
Category
Categories are a set of all-of tag values associated with a table row. To
access the object, the user security profile must match against the entire set
of category tags. A table row can have a number of categories (the system
limit is 64 K, and the size limit on the label string is 4000). A category is
typically used to group a set of data.
Cohort
Cohorts are a set of any-of tag values associated with a table row. To access
the object, the user security profile must match at least one of the cohort
tags. A table row can have any number of cohorts. A cohort is typically
used to group a set of users (like a SQL group).
All table rows require a security label, and if not defined, the system applies a
default level of PUBLIC. The system provides the pre-defined values shown in the
following table.

Table 6-1. Pre-defined security label system values
Security label
dimension Value Meaning
Level PUBLIC Default level, the lowest possible. A user with this defined
level (or no defined level, which defaults to this level) cannot
see any other levels.
A table row with this defined level (or no defined level,

which defaults to this level) can be accessed by every user.
OMNI Highest possible level. A user with this privilege can see all
levels.
A table row with this privilege defined requires the highest

privilege for access.
Category OMNI Set of all categories. A user with this privilege can see all
categories.
A table row with this privilege defined requires the OMNI

for access.
NONE A user with this privilege defined cannot see any defined
categories.
A table row with this privilege defined allows all users.

Cohort OMNI Set of all cohorts. A user with this privilege can see all
cohorts.
A table row with this privilege defined is visible to anyone.

NONE A user with this privilege defined cannot see any defined
cohorts.
A table row with this privilege defined makes the row

inaccessible.
A missing category or cohort is different from NONE because a missing category

or cohort on a row does not filter, while NONE on a row means that no bits are
set.
Security label syntax

Security labels are represented as a text string, with the following syntax:
<label> ::= <level> : <categories> : <cohorts>
<level> ::= [ <level-string> ]
<categories> ::= [ <category-string> [ , <categories> ]
<cohorts> ::= [ <cohort-string> [ , <cohorts> ]
For example, if the security label is defined with a level of Top Secret, a category
of Alpha, and a cohort of UK, it would look like the following example:
TOP_SECRET: Alpha: UK
Each component of the label is treated like a SQL identifier. Security labels are
handled as character strings, and in SQL must be presented as string literals. If you
have any character separation within the string, connect characters with
underscores or enclose the string in quotation marks.
"For Your Eyes Only" : AUDIT : Finance_Management, HR

The label is set to the system case unless encased with quotation marks, so the
previous example would appear as follows:
"For Your Eyes Only" : AUDIT : FINANCE_MANAGEMENT, HR
Spaces before and after the colon are ignored by the system. The label example can
be described in any of the following ways:
TOP_SECRET: Alpha: UK
TOP_SECRET : Alpha : UK
TOP_SECRET:Alpha:UK
The NONE identifier can be used for category and cohort, and explicitly indicates
the empty set:
CONFIDENTIAL : Alpha, Beta, Gamma: NONE
The following label is assigned to the Admin user, with access to all rows.
OMNI:OMNI:OMNI
The following is the PUBLIC level, with missing categories and cohorts:
::
Strings are restricted to 7-bit ASCII characters, with a maximum length of 4000
characters. While any user can create a label, you must have Manage Security
privileges to define the parts.
Important: Never change the letter case of a database that contains row-secure
tables. Using nzconvertsyscase on row-secure tables can cause serious problems
and possible data loss.
SQL commands for security labels

You can use the following SQL commands with all security label components:
v CREATE
v ALTER
v SHOW
v DROP
The following is an example of how to create and display levels:

DEV.SCHEMA(ADMIN)=> CREATE SECURITY LEVEL conf VALUE 500;
CREATE SECURITY LEVEL
DEV.SCHEMA(ADMIN)=> CREATE SECURITY LEVEL greater VALUE 600;
DEV.SCHEMA(ADMIN)=> CREATE SECURITY LEVEL secret VALUE 800;
DEV.SCHEMA(ADMIN)=> SHOW SECURITY LEVEL ALL;
NAME | LEVEL
----------+--------
PUBLIC | 0
CONF | 500
GREATER | 600
SECRET | 800
OMNI | 32767
(5 rows)
Chapter 6. Multi-Level Security and row-secure tables 6-3

Since SECRET has a higher value than CONF and GREATER, a user with SECRET
can access CONF and GREATER levels, but a user with CONF or GREATER
cannot access SECRET levels. A GREATER level can access a CONF level, and any
other levels with lesser values.
Restriction: You cannot change level values or drop any security levels, cohorts, or
categories if you have any row-secure tables defined in the system.
To alter a security level, you rename it and give it the new value, as in the
following example by using the name and value of CONF from the previous
example:
DEV.SCHEMA(ADMIN)=> ALTER SECURITY LEVEL conf RENAME TO TOP_SECRET VALUE
1000;
ALTER SECURITY LEVEL
So now a user with the altered TOP_SECRET level can access SECRET levels, but a
user with SECRET levels cannot access TOP_SECRET levels.
The following is an example of how to create and display categories. The system
automatically generates IDs.
DEV.SCHEMA(ADMIN)=> CREATE CATEGORY super;
CREATE CATEGORY
DEV.SCHEMA(ADMIN)=> CREATE CATEGORY insider;
CREATE CATEGORY
DEV.SCHEMA(ADMIN)=> CREATE CATEGORY audit;
CREATE CATEGORY
DEV.SCHEMA(ADMIN)=> SHOW CATEGORY ALL;
NAME | ID
----------+--------
AUDIT | 3
INSIDER | 2
SUPER | 1
OMNI | 0
(4 rows)
To alter a category, rename it and give it the new value, as in the following
example:
DEV.SCHEMA(ADMIN)=> ALTER CATEGORY SUPER RENAME TO TOP_SECRET;
ALTER CATEGORY
Cohorts are a strict set of hierarchies, and you can put cohorts into other cohorts
for a finer control of access, as in the following example:
DEV.SCHEMA(ADMIN)=> CREATE COHORT TOP;
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT SALES IN COHORT TOP;
CREATE COHORT
The following is an example of how to create and display different cohorts. The
system automatically generates the IDs:
DEV.SCHEMA(ADMIN)=> CREATE COHORT "NA" in COHORT sales;
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT "EUROPE" in COHORT sales;
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT "Asia" in COHORT sales;
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT DIST in COHORT top;
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT ENG in COHORT "Europe";
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT FRA in COHORT "Europe";

CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT GER in COHORT "Europe";
CREATE COHORT
DEV.SCHEMA(ADMIN)=> CREATE COHORT NE in COHORT dist;
CREATE COHORT
DEV.SCHEMA(ADMIN)=> SHOW COHORT ALL;
NAME | ID | CLOSURE
--------+----+----------------------------------------------------
Asia | 5 | "Asia"
DIST | 6 | DIST,NE
ENG | 8 | ENG
Europe | 4 | "Europe",ENG,FRA,GER
FRA | 9 | FRA
GER | 10 | GER
NA | 3 | "NA"
NE | 7 | NE
OMNI | 0 |
SALES | 2 | SALES,"NA","Europe","Asia",ENG,FRA,GER
TOP | 1 | TOP,SALES,"NA","Europe","Asia",DIST,NE,ENG,FRA,GER
(11 rows)
The hierarchy shows that the cohort at the top can access all the cohorts beneath it.
DIST cannot access SALES cohorts (both are “siblings” of TOP), and vice versa.
NA, EUROPE, and ASIA cannot access NE and vice versa.
When a user accesses a table row, the security profile of the user is compared to
the security label on the object to determine whether to allow access. The access
check is as follows:
v The label level must be less than or equal to the profile level.
v All members of the label category must be members of the profile. The user
must have all data categories.
v At least one member of the table row cohort must also be a member of the
profile.
You do not have to use all three dimensions (level, category, cohort) of the security
label. For example, if you wanted to use security level and category, but not
cohorts, you can specify as in the following:
DEV.SCHEMA(ADMIN)=> CREATE USER MARY PASSWORD ’abcd’ SECURITY LABEL ’secret:
blue’;
CREATE USER
The absence of a specified dimension does not have an identifier, and is treated as
missing. The missing state is used to decide whether to evaluate the access check.
If the label on a row is missing, the system ignores the user state and allows
access. If the user label is missing, it is treated as NONE.
The following table shows the all-of comparison used for comparing categories.
Table 6-2. All-of comparison (categories)
User Security
profile label Result
Missing Missing Allow access
Missing Specified Access not allowed
Specified Missing Allow access
Specified Specified The user must have all categories that the table row has. The user
can have more categories.

The following table shows how the any-of comparison is used for comparing
cohorts.
Table 6-3. Any-of comparison (cohorts)
User Security
profile label Result
Missing Missing Allow access
Missing Specified Access not allowed
Specified Missing Allow access
Specified Specified The user must have at least one cohort in common with the table
row. Both the user and the table row can have other cohorts.
From the previous examples, create a user:

DEV.SCHEMA(ADMIN)=> CREATE USER GRETA SECURITY LABEL ’SECRET : INSIDER, AUDIT
: DIST, Europe, Asia’;
CREATE USER
From the examples given, the following table shows how a match against the
created user GRETA determines which access is allowed.
Table 6-4. Labels and access
Category Cohort
Level (all-of) (any-of) Can access
CONF INSIDER Asia Yes.
CONF INSIDER SALES No. User is restricted because none of the cohorts of
user is SALES.
AUDIT OMNI Asia No. User is restricted because OMNI equals all
categories, and INSIDER and AUDIT are a subset of
the all-of categories.
GREATER AUDIT FRA Yes. FRA belongs to cohort Europe.
TOP_SECRET SUPER GER No. Level is too low and user ID does not have
SUPER as a category.
When security labels are combined, the rules of Multi-Level Security determine
that the result is the most restrictive combination, defined as the following:
v The maximum of the levels.
v The union of the all-of tag sets (categories).
v The intersection of the any-of tag sets (cohorts).
The IBM Netezza system does not automatically calculate combinations of labels.
You can define functions and aggregates to enforce rules.
The following built-in functions can be used to calculate the combination of two or
more security labels:
v combine_label(label1, label2)
This is a scalar function that combines two or more labels and returns the most
restrictive combination.
v max_label(label)
This is an aggregate function that combines a set of labels and returns a single,
most restrictive label.

In the following example, SECRET is more restrictive than PUBLIC, so the result is
SECRET. Two categories are more restrictive than one, and since you have to have
both categories to see the data, the result is BLUE and GREEN. Cohorts are more
restrictive because of the intersection. In this case, the intersection of PSG and QA
is empty, so the result is explicitly NONE. Note that an explicit NONE means the
data is not visible to anyone except OMNI.
DEV.SCHEMA(ADMIN)=> SELECT combine_label(’secret: blue:psg’, ’public: green:
qa’);
COMBINE_LABEL
------------------------
SECRET:GREEN,BLUE:NONE
(1 row)
To label query results or use for CTAS, you may combine labels with max_label
and combine_label, which calculates the most restrictive label. Joins have no label,
just the result.
Row-secure tables
A row-secure table (RST) looks like a normal database table, but returns different
answers to queries, based upon the security label of the user. Only user tables can
have row security, which can be specified when a table is created.
To create a row-secure table, you must have Create Table privilege. Even a table
owner might not have the rights to see all the table rows. To create a row-secure
table, use the following syntax:
create table rst ... row security;
The following are row-secure table permissions:

LABEL ACCESS
Allows visibility of the label column.
LABEL RESTRICT
Allows the user to update the label to a more restrictive value.
LABEL EXPAND
Allows the user to update the label to a less restrictive value.
The resulting created table has an extra column named “_sec_label” of type
varchar, with a 4000 character limit and Latin9 support. To access the _sec_label
column you must have LABEL ACCESS permission.
The following list provides additional RST information:

v Users can INSERT information they are not allowed to view if they have the
LABEL RESTRICT permissions.
v UPDATE and DELETE can only be done on rows the user can select.
Important: If there are RSTs in the system, you can rename objects and create
new levels, categories, and cohorts, but you cannot drop levels, categories, or
cohorts, and you cannot alter any level value.
RST caveats
When using the advanced security features, note the following operational
considerations:

v Never change the letter case of a database that contains row-secure tables. Using
nzconvert -syscase on row-secure tables can cause serious problems and
possible data loss.
v You cannot change the name of a database that has row-secure tables defined
within it. You must drop all row secure tables from the database before you can
rename it. You can then re-create the tables in the newly renamed database.
v You cannot restore a Release 4.6.5 database backup that includes a row-secure
table to a previous release.
RST backup and restore

Existing backup and restore commands work with RSTs. The target database of a
restore must have a compatible model of levels, categories, and cohorts. All of the
security descriptors referenced by tables in a database backup must be present on a
machine that is a restore target or the restore fails. Backup captures the security
descriptor information with each backup. Restore compares the security descriptors
in the backup against those descriptors in the restore target system.
The nzrestore command checks for compatibility before beginning to insert data.
The comparison shows any security discrepancies early in the restore operation,
rather than during the data load phase. The compatibility check can be disabled if
you want.
RSTs and concurrent loads

There is a known issue that occurs when users run concurrent loads into an RST
and the loads contain rows with new (previously undefined) security masks. The
concurrent loads could fail with the error Could not serialize - transaction
aborted.
To avoid the load error, create a test table in the same database that contains the
target table for the concurrent loads that failed. Insert a sample row into the test
table for each security mask that is used in the failed load commands. This defines
each security mask in the database, and you can reissue the load commands to
load the data into the target RST.
RSTs and external tables

There are no row-secure external tables, as the IBM Netezza system does not apply
row security filtering on external tables. The file contents are not secure, and
anyone with file access can view the data. External tables can have string columns
that contain label strings in the label column, and can be used to load and unload
RSTs.
To capture the label with a SELECT statement, you must be explicit, as in the
following example:
DEV(ADMIN)=> CREATE TABLE rst (id int, name varchar(80), metric int)
ROW SECURITY;
CREATE TABLE
DEV(ADMIN)=> CREATE EXTERNAL TABLE ’TMP/XT' AS SELECT *, _SEC_LABEL
FROM rst;
INSERT 0 0

Appendix A. Netezza SQL and CLI commands
This section includes reference information for IBM Netezza SQL and CLI
commands and functions implemented in the new security features.
Changes to Netezza SQL commands

This section describes the changes in IBM Netezza SQL commands.
The following table describes the commands supported.

Table A-1. Netezza SQL commands
Command Description See
ALTER CATEGORY Changes the name of “ALTER CATEGORY” on page A-3
the category.
ALTER COHORT Changes the name or “ALTER COHORT” on page A-4
the hierarchy position
of the cohort.
ALTER DATABASE ... Assigns the collect “ALTER DATABASE” on page A-5
COLLECT HISTORY history to the
database object.
ALTER GROUP Changes the security “ALTER GROUP” on page A-7
label and audit
categories, the collect
history, concurrent
session, and access
time attributes of the
group.
ALTER HISTORY Modifies the “ALTER HISTORY CONFIGURATION” on
CONFIGURATION configuration of page A-9
query or audit history
logging.
ALTER SECURITY Changes the name or “ALTER SECURITY LEVEL” on page A-12
LEVEL value of a security
level.
ALTER USER Changes the security “ALTER USER” on page A-13
label and audit
history, concurrent
session, and access
time attributes of the
user object.
CREATE CATEGORY Creates a security “CREATE CATEGORY” on page A-16
category.
CREATE COHORT Creates a security “CREATE COHORT” on page A-17.
cohort.
CREATE DATABASE Assigns the collect “CREATE DATABASE” on page A-18
... COLLECT history to the
HISTORY database object.
© Copyright IBM Corp. 2009, 2014 A-1

Table A-1. Netezza SQL commands (continued)
CREATE GROUP Assigns the security “CREATE GROUP” on page A-20
label and audit
history, concurrent
session, and access
time attributes to the
group.
CREATE HISTORY Creates a history See the CREATE HISTORY
CONFIGURATION configuration. CONFIGURATION command in the IBM
Netezza Database User’s Guide.
CREATE SECURITY Creates a security “CREATE SECURITY LEVEL” on page A-21
LEVEL level.
CREATE TABLE ... Specifies the table is “CREATE TABLE” on page A-23
ROW SECURITY created with row
security support.
CREATE USER Assigns the security “CREATE USER” on page A-23
label and audit
history, concurrent
session, and access
time attributes to the
user object.
DROP CATEGORY Removes the category “DROP CATEGORY” on page A-26
from the label
security
configuration.
DROP COHORT Removes the cohort “DROP COHORT” on page A-27
from the label
security
configuration.
DROP HISTORY Drops the “DROP HISTORY CONFIGURATION” on
CONFIGURATION configuration for page A-28
query or audit history
logging.
DROP SECURITY Removes a security “DROP SECURITY LEVEL” on page A-29
LEVEL level from the label
security
configuration.
EXECUTE AS... Allows a suitably “EXECUTE AS” on page A-30
privileged user to set
the CURRENT USER
of their session to a
different user.
REVERT Reverses the action of “REVERT” on page A-31
the last EXECUTE AS
statement.
SET HISTORY Sets the current “SET HISTORY CONFIGURATION” on
CONFIGURATION history configuration page A-32
to the named
configuration.
SHOW CATEGORY Displays one or more “SHOW CATEGORY” on page A-33
categories.
A-2 IBM Netezza Advanced Security Administrator's Guide

Table A-1. Netezza SQL commands (continued)
SHOW COHORT Displays one or more “SHOW COHORT” on page A-34
cohorts or the cohort
hierarchy.
SHOW HISTORY Displays the query or “SHOW HISTORY CONFIGURATION” on
CONFIGURATION audit history page A-36
configuration settings.
SHOW SECURITY Displays one or all “SHOW SECURITY LEVEL” on page A-37
LEVEL security levels.
ALTER CATEGORY
Use the ALTER CATEGORY command to change the name of the category.
Synopsis
Syntax for altering a category:

ALTER CATEGORY <category-name> RENAME TO <new-name>
Inputs
The ALTER CATEGORY command has the following inputs:

Table A-2. ALTER CATEGORY inputs
Input Description
<category- The identifier of an existing category.
name>
<new- An identifier to be the new name of the category. The name must be unique
name> among category names. Due to the total size limitation of the system security
label field, use short names. For compatibility with other vendors, do not use
delimited identifiers, only ASCII characters, and limit name length to 30
characters.
Outputs
The ALTER CATEGORY command has the following output:

Table A-3. ALTER CATEGORY output
Output Description
ALTER CATEGORY The message that the system returns if the command is
successful.
ERROR: permission You must have Manage Security privilege to create a security
denied. category.
ERROR: object The specified category was not found.
<category-name> not
found.
ERROR: object The new category name must be different from all other
<new-name> already category names.
exists.
Appendix A. Netezza SQL and CLI commands A-3

Description
The ALTER CATEGORY command changes the name of the category.

Privileges required
You must have Manage Security privilege to create security categories.
Common tasks
Use the ALTER CATEGORY command to change the name of the category.
Usage
The following provides sample usage:

ALTER CATEGORY ARGON RENAME TO BORON;
Related reference:
“CREATE CATEGORY” on page A-16
“DROP CATEGORY” on page A-26
“SHOW CATEGORY” on page A-33
ALTER COHORT
Use the ALTER COHORT command to change the name or the hierarchy position
of the cohort.
Synopsis
Syntax for altering a cohort:

ALTER COHORT <cohort-name>
{ RENAME TO <new-name> | IN COHORT <parent-cohort> | IN NONE }...
Inputs
The ALTER COHORT command has the following inputs:

Table A-4. ALTER COHORT inputs
Input Description
<cohort- The identifier of an existing cohort.
name>
<new- An identifier to be the new name of the cohort. The name must be unique
name> among cohort names. Due to the total size limitation of the system security
label field, use short names. For compatibility with other vendors, do not use
delimited identifiers, only ASCII characters, and limit name length to 30
characters.
IN NONE Removes this cohort from its parent. The cohort no longer has a parent
cohort.
IN Places the cohort in the cohort hierarchy as a child of <parent-cohort>
<parent- replacing any previous parent.
cohort>

Outputs
The ALTER COHORT command has the following output:

Table A-5. ALTER COHORT output
Output Description
ALTER COHORT The message that the system returns if the command
is successful.
ERROR: permission denied. You must have Manage Security privilege to create a
security cohort.
ERROR: object <cohort-name> not The specified cohort or parent cohort was not found.
found.
ERROR: object <new-name> already The new cohort name must be different from all other
exists. cohort names.
Description
The ALTER COHORT command has the following characteristics:

Privileges required
You must have Manage Security privilege to create security levels.
Common tasks
Use the ALTER COHORT command to change the name or the hierarchy
position of the cohort.
Usage

ALTER COHORT SECRET RENAME TO CONIFDENTIAL IN COHORT HR;
Related reference:
“CREATE COHORT” on page A-17
“DROP COHORT” on page A-27
“SHOW COHORT” on page A-34
ALTER DATABASE
Use the ALTER DATABASE command with the added COLLECT HISTORY clause
to specify history collection for the databases and the users who are connected to
it.
Synopsis
Syntax for altering a DATABASE:

ALTER DATABASE <database-name> [<ALTER-db-clause>]...
<ALTER-db-clause> ::=
| COLLECT HISTORY { ON | OFF | DEFAULT }

Inputs
The ALTER DATABASE command has the following input:

Table A-6. ALTER DATABASE input
Input Description
COLLECT HISTORY [ ON Specifies whether history data is to be collected for sessions
| OFF | DEFAULT ] attached to this database.
ON History is collected only if the user is a member of at
least one group for which COLLECT HISTORY is set
to ON.
OFF History is not collected for the database.
DEFAULT
History is collected for the database only if the user
is a member of at least one group for which
COLLECT HISTORY is set to ON and if one of the
following criteria apply:
v The user is not a member of any user group.
v All the user groups of which the user is a member
have COLLECT HISTORY set to DEFAULT.
v The user is a member of at least one user group
that has COLLECT HISTORY set to ON.
Outputs
The ALTER DATABASE command has the following output:

Table A-7. ALTER DATABASE output
Output Description
ERROR: permission You must have Manage Security privilege to set a database
denied. history collection attribute.
Description
For details about all the options of the ALTER DATABASE command, see theIBM
Netezza Database User’s Guide. The ALTER DATABASE command has the following
characteristics:
Privileges required
You must be the admin user, the database owner, or your account must
have the Alter privilege for the database or for the Database object class.
You must have Manage Security privilege to alter the history collection
attribute of a database.
Common tasks
In addition to its previous functions, the command assigns the collect
history to the database object.
Usage

ALTER DATABASE SECRET COLLECT HISTORY ON;

ALTER GROUP
Use the ALTER GROUP command to alter a group with additional security-related
clauses.
Synopsis
Syntax for altering a security group:

ALTER GROUP <group-name> [WITH] [<alter_group_clause>]...
<alter_group_clause> ::=
ROWSETLIMIT <limit>
| SESSIONTIMEOUT <limit>
| QUERYTIMEOUT <limit>
| DEFPRIORITY <priority_type>
| MAXPRIORITY <priority_type>
| RESOURCELIMIT <percent>
| [ADD] USER { <user-name> },...
| DROP USER { <user-name> },...
| SYSID <id-number>
| OWNER TO <group-name>
| RENAME TO <group-name>
| CONCURRENT SESSIONS <limit>
| ALLOW CROSS JOIN [TRUE|FALSE|NULL]
| ACCESS TIME { ALL | DEFAULT | ( <access-time>,... )
<access-time> ::= DAY { ALL | <day>, ... } [ <time-bound> ]
<time-bound> ::= START <time-literal> END <time-literal> ]
Inputs
The ALTER GROUP command has the following additional inputs:

Table A-8. ALTER GROUP inputs
Input Description
COLLECT HISTORY [ ON | OFF | Determines whether this session collects history for a
DEFAULT ] group. ON indicates that history is collected for this
group when connected to a database that also has
COLLECT HISTORY ON. OFF indicates that history
is not collected for this group. DEFAULT means to
examine groups this group is a member of to
determine whether to collect history. If any group has
COLLECT HISTORY ON, then history is collected
when connected to a database that also has
COLLECT HISTORY ON. If no group has COLLECT
HISTORY ON, but a group has COLLECT HISTORY
OFF, then no history is collected. If all groups have
DEFAULT history collection, the history is collected.
DEFAULT is the default for a group, if the COLLECT
HISTORY clause is not specified.
CONCURRENT SESSIONS <limit> Sets the maximum number of concurrent sessions this
group can have. A value of 0 means no limit to the
number of concurrent sessions, unless a limit is
imposed by a group. In that case, the minimum limit
of concurrent sessions across all such groups is used.

Table A-8. ALTER GROUP inputs (continued)
Input Description
ALLOW CROSS JOIN [TRUE | Sets user or group permission to allow explicit cross
FALSE | NULL] joins. If NULL is defined for a user, the system
checks against the group permission, and takes the
lowest non-null value, where FALSE is lower than
TRUE.
This setting involves a system-wide change, so notify

all affected users before making this change.
ACCESS TIME ALL Indicates that this group can start sessions on the
IBM Netezza system at any time on any day.
ACCESS TIME DEFAULT Indicates that access time restrictions are taken from
the groups. If no groups have access time restrictions,
then the user can start sessions at any time on any
day. The access time restriction is evaluated for every
group that has one. If any group restricts access, the
user cannot create a session. That is, the most
restrictive access policy is applied.
access-time Specifies one access time subclause; several can be
specified. An access time subclause defines one or
more days by the standard SQL day number (1 =
Sunday, 7 = Saturday). The keyword ALL can be use
to specify all days of the week; it is equivalent to
1,2,3,4,5,6,7. An access time subclause optionally
contains one time bound. If no time bound is
specified, then the group can create a session at any
time on the specified day.
time-bound Specifies a time range from a start time to an end
time. The times can be specified as any valid SQL
time literal. It is possible to repeat the same day
specification multiple times with different time
bounds.
Outputs
The ALTER GROUP command has the following output:

Table A-9. ALTER GROUP output
Output Description
ERROR: permission denied. You must have Manage Security privilege to alter a
group.
Description
For details about all the options of the ALTER GROUP command, see theIBM
Netezza Database User’s Guide. The ALTER GROUP command has the following
characteristics:
Privileges required
You must have Manage Security privilege to alter a group.
Common tasks
Use the ALTER GROUP command to alter a group with additional clauses.

Usage

ALTER GROUP FLIGHT WITH COLLECTHISTORY OFF;
ALTER HISTORY CONFIGURATION

Use the ALTER HISTORY CONFIGURATION command to modify the
configuration of query or audit history logging. This command runs on the source
IBM Netezza system. You cannot alter the current history configuration.
Synopsis
Syntax for altering a history configuration:

ALTER HISTORY CONFIGURATION <config-name> <hist-clause>...
<hist-clause> ::=
| HISTTYPE {QUERY | AUDIT | NONE}
| NPS { LOCALHOST | <hostname> }
| DATABASE <dbname>
| SCHEMA <schemaname>
| USER <username>
| PASSWORD <writer-password>
| COLLECT <history-item> ,...
| LOADINTERVAL {number }
| LOADMINTHRESHOLD {number}
| LOADMAXTHRESHOLD {number}
| DISKFULLTHRESHOLD {number}
| STORAGELIMIT {number}
| LOADRETRY {number}
| ENABLEHIST {boolean}
| ENABLESYSTEM {boolean}
| VERSION <version>
| KEY { NONE | <cryto-key-name>
| INCLUDING [ONLY] { SUCCESS | FAILURE | ALL }
Inputs
The ALTER HISTORY CONFIGURATION command has the following inputs:

Table A-10. ALTER HISTORY CONFIGURATION inputs
Input Description
config_name The name of the configuration to alter. The configuration
must exist on the IBM Netezza system. You cannot alter the
current configuration or can you change the name of the
configuration. (To change a configuration name, you must
drop the configuration and create a new one.) This input
option is a delimited identifier. If not delimited, the system
converts the name to the host case.
HISTTYPE The type of the database to create, which can be QUERY,
AUDIT, or NONE. Specify NONE to disable history collection.
If you do not specify this input option, the current
configuration value is retained.
LOCALHOST Use this Netezza system as the target system for query or
audit history logging. If not specified, the current value is
retained.

Table A-10. ALTER HISTORY CONFIGURATION inputs (continued)
Input Description
DATABASE <dbname> Specifies the database to use for query or audit history
logging. The database must be created with the CREATE
HISTORY DATABASE command on the target Netezza
system. If not specified, the current value is retained. This
input is a delimited identifier. If not delimited, the name is
converted to host case.
SCHEMA <schemaname> Specifies the schema in the history database where you want
to load the history data, If you omit this value, the history
data is loaded to the default schema of the history database.
You should specify a schema value that matches the owner of
the database. This is very important for systems where the
enable_user_schema setting is TRUE.
USER<username> The user name to use when logging in to the Netezza system
to write the query or audit history log. If not specified, the
current value is retained. This input is a delimited identifier. If
not delimited, the name is converted to host case.
PASSWORD <password> The password to use when logging in to the Netezza system
to write the query or audit history log. If not specified, the
current value is retained. This input is a single quoted string.
COLLECT Specifies the history data to be collected. The system always
collects login failure, session creation, session deletion, and
the startup of the log capture (alcapp) process. You can
specify more information to collect by using this clause:
v QUERY to collect the query data
v PLAN to collect plan data from queries. If you specify
PLAN, you automatically collect QUERY as well.
v TABLE to collect table detail data from queries. If you
specify TABLE, you automatically collect QUERY as well.
v COLUMN to collect column detail data from queries. If you
specify COLUMN, you automatically collect QUERY and
TABLE as well.
v SERVICE to collect CLI commands
v STATE to collect system state changes
You can specify multiple values by using comma-separated

values. If you do not specify this input option, the current
configuration value is retained. For more information, see the
section about query history in the IBM Netezza System
LOADINTERVAL Specified in seconds. It must be at least 0. Maximum value is
3600 seconds. The “alcapture” process attempts to message
the “alcloader” at this interval to load data provided the min
threshold is reached. If not specified, the current value is
retained.
LOADMINTHRESHOLD Specified in MB. At the expiry of every LOADINTERVAL if
this minimum threshold of data is accumulated, the
“alcapture” process can message the “alcloader” process to
load this data. If not specified, the current value is retained.
This value can be zero.
LOADMAXTHRESHOLD Specified in MB. When this amount of data is reached, the
“alcapture” sends a message to “alcloader” to load the data. If
not specified, the current value is retained. This value can be
zero.

Table A-10. ALTER HISTORY CONFIGURATION inputs (continued)
Input Description
DISKFULLTHRESHOLD Specified in MB. If the amount of total free disk space in
/nz/data falls below this threshold, the query or audit history
data collection is stopped until manual intervention occurs.
For audit history, the system is stopped.
STORAGELIMIT Specified in MB. If this limit is reached in the staging area
then the query or audit history data collection is stopped until
manual intervention occurs. For audit history, the system is
stopped. If not specified, the current value is retained. This
value can be zero. If zero, the storage limit checking is
disabled.
LOADRETRY The number of times the load operation is retried by the
“alcloader” process. Minimum is 0 and maximum is 2. If not
specified, the current value is retained.
ENABLEHIST This TRUE / FALSE flag enables or disables the inclusion of
queries on query or audit history database in query or audit
history. If not specified, the current value is retained. Even if
this value is specified as FALSE, if queries against history
database have syntax errors they are captured.
ENABLESYSTEM This TRUE / FALSE flag enables or disables the inclusion of
queries on system tables in query or audit history. If not
specified, the current value is retained. Even if this value is
set to FALSE, a query with syntax error against system tables
is captured.
VERSION <version> The schema version of the history database. If not specified,
the current value is retained.
KEY NONE Only applies to HISTTYPE AUDIT. If NONE is specified, then
no crypto key is associated with the configuration and no
digital signing is done.
KEY <crypto-key-name> The specified crypto key must be an existing public-private
key pair. That crypto key is used to digitally sign the audit
history data.
Outputs
The ALTER HISTORY CONFIGURATION command has the following outputs:

Table A-11. ALTER HISTORY CONFIGURATION outputs
Output Description
ALTER HISTORY CONFIGURATION The message that the system returns if the command
is successful.
ERROR: permission denied. You must have Manage Security privilege.
ERROR: login failed. The credentials provided for the writer did not work.
This check can be made only if the target database is
on the same system as the source.
ERROR: <config-name> not found. The specified configuration name cannot be found.
ERROR: database <dbname> not The query or audit history database was not found
found. on the target system. This validation is done only if
the target database is on the same system as the
source.

Description
For details about all the options of the ALTER HISTORY CONFIGURATION
command, see theIBM Netezza Database User’s Guide. Current query or audit is not
interrupted by ALTER as this action can be done only on a configuration that is
not current. The ALTER is logged to the current query or audit history log.
The target query or audit database does not need to be empty.
If you frequently change configurations, it is possible to have some staged data not
loaded yet. If the configuration corresponding to part of the staged data is
changed, it is possible the loader can error out and the files moved to the error
directory.
Privileges required
You must have Manage Security privilege to alter query or audit logging.
Common tasks
The ALTER HISTORY CONFIGURATION command updates the query or
audit history configuration in the catalog, and can be done only on a
configuration that is not current.
Usage

ALTER HISTORY CONFIGURATION all_hist VERSION 3;
ALTER SECURITY LEVEL

Use the ALTER SECURITY LEVEL command to change the name or value of a
security level.
Synopsis
Syntax for altering a security level:

ALTER SECURITY LEVEL <level-name>
{ RENAME TO <new-level-name> | VALUE <level-number> }
Inputs
The ALTER SECURITY LEVEL command has the following inputs:

Table A-12. ALTER SECURITY LEVEL inputs
Input Description
<level_name> The identifier of an existing level name.
<new-level- An identifier to be the new name of the level. The name must be
name> unique among security level names. Due to the total size limitation of
the system security label field, use short level names. For compatibility
with other vendors, do not use delimited identifiers, use only ASCII
characters, and limit name length to 30 characters.
<level_number> A positive integer level value 1 - 32766. Higher levels are more secure;
lower values are less secure.

Outputs
The ALTER SECURITY LEVEL command has the following output:

Table A-13. ALTER SECURITY LEVEL output
Output Description
ALTER SECURITY LEVEL The message that the system returns if the command
is successful.
ERROR: permission denied. You must have Manage Security privilege to alter a
security level.
ERROR: level number <number> The specified level number exists. A level number can
already exists. only have one name.
ERROR: level number <number> is The level number must be 1 - 32766. Level number 0
out of range. is predefined by the system as level PUBLIC. Level
number 32767 is predefined by the system as level
OMNI. Negative level numbers are not allowed.
ERROR: object <new-level-name> The new level name must be different from all other
already exists. security level names.
ERROR: object <level-name> not The level name must exist.
found.
ERROR: label security in use. You cannot change the value of a security level after
there is user data that might reference that level.
Description
The ALTER SECURITY LEVEL command either renames a security level or

changes the value of the security level. You can rename a security level at any
time. However, you can only change the value of the level if there are no ROW
SECURITY tables defined in any database in the system.
Develop and review your label security configuration before you create any ROW
SECURITY tables. After tables are defined, you can add levels to the system or
rename levels, but you cannot change the value of or remove levels.
Privileges required
You must have Manage Security privilege to alter security levels.
Common tasks
Use the ALTER SECURITY LEVEL command to update the system catalog
to add the new object, and update the security level name to value
mapping.
Usage

ALTER SECURITY LEVEL SECRET { RENAME TO CONFIDENTIAL VALUE 22 };
Related reference:
“CREATE SECURITY LEVEL” on page A-21
“DROP SECURITY LEVEL” on page A-29
“SHOW SECURITY LEVEL” on page A-37
ALTER USER
Use the ALTER USER command to change user settings.

Synopsis
Syntax for altering a user:

ALTER USER <user-name> [WITH] [<alter_user_clause>]...
<alter_user_clause> ::=
PASSWORD { <password> | NULL }
| IN GROUP { <group-name> },...
| VALID UNTIL <valid-date>
| ROWSETLIMIT <limit>
| SYSID <id-number>
| IN RESOURCEGROUP <group-name>
| SECURITY LABEL <label-string>
| AUDIT CATEGORY { NONE | { <category> },... }
| RESET ACCOUNT
| OWNER TO <user-name>
| RENAME TO <group-name>
| AUTH [LOCAL|DEFAULT]
| EXPIRE PASSWORD
Inputs
The ALTER USER command has the following additional inputs:

Table A-14. ALTER USER inputs
Input Description
SECURITY LABEL <label> Specifies the security label of the user. If a SECURITY LABEL
is not specified, the default label ‘PUBLIC::’ is assigned. The
label is surrounded by parentheses so that identifiers in the
label do not conflict with keywords of the other user clauses.
AUDIT CATEGORY Specifies the audit categories of the user. One or more audit
<category> categories can be specified. The categories are added to the
security label during audit logging.
COLLECT HISTORY [ ON Determines whether this session of the user collects history.
| OFF | DEFAULT ] ON indicates that history is collected for this user when
connected to a database that also has COLLECT HISTORY
ON. OFF indicates that history is not collected for this user.
DEFAULT means to examine groups this user is a member of
to determine whether to collect history. If any group has
COLLECT HISTORY ON, then history is collected when
ON. If no group has COLLECT HISTORY ON, but a group
has COLLECT HISTORY OFF, then no history is collected. If
all groups have DEFAULT history collection, the history is
collected. DEFAULT is the default for a user, if the COLLECT
CONCURRENT SESSIONS Sets the maximum number of concurrent sessions this user
<limit> can have. A value of 0 means no limit to the number of
concurrent sessions, unless a limit is imposed by a group of
which this user is a member. In that case, the minimum limit

Table A-14. ALTER USER inputs (continued)
Input Description
ALLOW CROSS JOIN Sets user or group permission to allow explicit cross joins. If
[TRUE | FALSE | NULL] NULL is defined for a user, the system checks against the
group permission, and takes the lowest non-null value,
where FALSE is lower than TRUE.
This setting involves a system-wide change, so notify all

affected users before making this change.
ACCESS TIME ALL Indicates that this user can start sessions on the IBM Netezza
system at any time on any day.
ACCESS TIME DEFAULT Indicates that access time restrictions are taken from the
groups this user is a member of. If no groups have access
time restrictions, then the user can start sessions at any time
on any day. The access time restriction is evaluated for every
group that has one. If any group restricts access, the user
cannot create a session. That is, the most restrictive access
policy is applied.
access-time Specifies one access time subclause; several can be specified.
An access time subclause defines one or more days by the
standard SQL day number (1 = Sunday, 7 = Saturday). The
keyword ALL can be use to specify all days of the week; it is
equivalent to 1,2,3,4,5,6,7. An access time subclause optionally
contains one time bound. If no time bound is specified, then
the user can create a session at any time on the specified day.
time-bound Specifies a time range from a start time to an end time. The
times can be specified as any valid SQL time literal. It is
possible to repeat the same day specification multiple times
with different time bounds.
AUTH [LOCAL | Sets the overriding authentication for the user to LOCAL
DEFAULT] (checks the password against the local database/catalog),
regardless of the connection setting. To revert this setting to
the default setting, use AUTH DEFAULT.
EXPIRE PASSWORD If this value is set while the user is logged in, it does not
affect the current session, but requires the user to change
their password the next time they log in.
Outputs
The ALTER USER command has the following output:

Table A-15. ALTER USER output
Output Description
ERROR: permission denied. You must have Manage Security privilege to set the
security group of a user.
ERROR: invalid security label. The security label is either incorrectly formatted or
refers to a security level, cohort, or category that does
not exist.
ERROR: object <category-name> The specified audit category must exist to associate it
not found. with the user.

Description
The ALTER USER command has the following characteristics:

Privileges required
You must have Manage Security privilege to alter the security group of a
user.
Common tasks
Use the ALTER USER command to change user settings.
Usage

ALTER USER BOB CONCURRENT SESIONS 3;
CREATE CATEGORY
Use the CREATE CATEGORY command to create a security category.
Synopsis
Syntax for creating a category:

CREATE CATEGORY <category-name>
Inputs
The CREATE CATEGORY command has the following input:

Table A-16. CREATE CATEGORY input
Input Description
<category- An identifier for a category. The name must be unique among security
name> category names. Due to the total size limitation of the system security label
field, use short category names. For compatibility with other vendors, do
not use delimited identifiers, only ASCII characters, and limit name length
to 30 characters.
Outputs
The CREATE CATEGORY command has the following outputs:

Table A-17. CREATE CATEGORY outputs
Output Description
CREATE CATEGORY The message that the system returns if the command is
successful.
denied. category.
ERROR: object The specified category exists. The category name must be
<category-name> already different from all other category names.
exists.
Description
Privileges required
You must have Manage Security privilege to create security categories.

Common tasks
Use the CREATE CATEGORY command to create a security category.
Usage

CREATE CATEGORY ARGON;
Related reference:
“ALTER CATEGORY” on page A-3
CREATE COHORT
Use the CREATE COHORT command to create a security cohort.
Synopsis
Syntax for creating a security cohort:

CREATE COHORT <cohort-name> [ IN COHORT <parent-cohort> | IN NONE ]
Inputs
The CREATE COHORT command has the following inputs:

Table A-18. CREATE COHORT inputs
Input Description
<cohort-name> An identifier for a cohort. The name must be unique among security
cohort names. Due to the total size limitation of the system security label
field, use short cohort names. For compatibility with other vendors, do
not use delimited identifiers, only ASCII characters, and limit name length
to 30 characters.
IN NONE Specifies that the cohort does not have a parent cohort. IN NONE is the
default if no IN clause is specified.
IN Places the new cohort in the cohort hierarchy as a child of
<parent- <parent-cohort>.
cohort>
Outputs
The CREATE COHORT command has the following outputs:

Table A-19. CREATE COHORT outputs
Output Description
CREATE COHORT The message that the system returns if the command is
successful.
denied. cohort.
ERROR: object The specified cohort exists. The cohort name must be different
<cohort-name> already from all other security cohorts.
exists.

Table A-19. CREATE COHORT outputs (continued)
Output Description
ERROR: object The parent cohort must exist before defining children.
<parent-cohort> not
found.
Description
Privileges required
You must have Manage Security privilege to create security cohorts.
Common tasks
Use CREATE COHORT to create a security cohort.
Usage

CREATE COHORT FINANCE IN COHORT HR;
Related reference:
“ALTER COHORT” on page A-4
CREATE DATABASE
Use the CREATE DATABASE command with the added COLLECT HISTORY
clause.
Synopsis
Syntax for creating a DATABASE:

CREATE DATABASE <database-name> [<create-db-clause>]...
<create-db-clause> ::=

Inputs
The CREATE DATABASE command has the following inputs:

Table A-20. CREATE DATABASE inputs
Input Description
COLLECT HISTORY [ ON Specifies whether history data is to be collected for sessions
| OFF | DEFAULT ] attached to this database.
ON History is collected only if the user is a member of
at least one group for which COLLECT HISTORY is
set to ON. This is the default.
OFF History is not collected for the database.
DEFAULT
History is collected for the database only if the user
is a member of at least one group for which
COLLECT HISTORY is set to ON and if one of the
following criteria apply:
v The user is not a member of any user group.
v All the user groups of which the user is a member
have COLLECT HISTORY set to DEFAULT.
v The user is a member of at least one user group
that has COLLECT HISTORY set to ON.
Outputs
The CREATE DATABASE command has the following output:

Table A-21. CREATE DATABASE output
Output Description
ERROR: permission denied. You must have Manage Security privilege to set a
database history collection attribute.
Description
For details about all the options of the CREATE DATABASE command, see theIBM
Netezza Database User’s Guide. The CREATE DATABASE command has the
following characteristics:
Privileges required
None.
Common tasks
In addition to its previous functions, the command assigns the collect
history to the database object.
Usage

CREATE DATABASE SECRET COLLECT HISTORY ON;

CREATE GROUP
Use the CREATE GROUP command to create a group with additional clauses for
history and security characteristics.
Synopsis
Syntax for creating a security group:

CREATE GROUP <group-name> [WITH] [<create_group_clause>]...
<create_group_clause> ::=
ROWSETLIMIT <limit>
| SYSID <id-number>
| RESOURCELIMIT <percent>
| [ADD] USER { <user-name> },...
Inputs
The CREATE GROUP command has the following additional inputs:

Table A-22. CREATE GROUP inputs
Input Description
COLLECT HISTORY [ Determines whether this session of a group collects history. ON
ON | OFF | DEFAULT ] indicates that history is collected for this group when
connected to a database that also has COLLECT HISTORY ON.
OFF indicates that history is not collected for this group.
DEFAULT means to examine groups this group is a member of
to determine whether to collect history. If any group has
connected to a database that also has COLLECT HISTORY ON.
If no group has COLLECT HISTORY ON, but a group has
COLLECT HISTORY OFF, then no history is collected. If all
groups have DEFAULT history collection, the history is
collected. DEFAULT is the default for a group, if the COLLECT
CONCURRENT Sets the maximum number of concurrent sessions this group
SESSIONS <limit> can have. A value of 0 means no limit to the number of
which this group is a member. In that case, the minimum limit
group permission, and takes the lowest non-null value, where
FALSE is lower than TRUE.

ACCESS TIME ALL Indicates that this group can start sessions on the IBM Netezza
system at any time on any day.

Table A-22. CREATE GROUP inputs (continued)
Input Description
ACCESS TIME DEFAULT If the group has no access time restrictions, then a user can
start sessions at any time on any day. The access time
restriction is evaluated for every group that has one. If any
group restricts access, the user cannot create a session. That is,
the most restrictive access policy is applied.
keyword ALL can be use to specify all days of the week; it is
equivalent to 1,2,3,4,5,6,7. An access time subclause optionally
contains one time bound. If no time bound is specified, then
the group can create a session at any time on the specified day.
Outputs
The CREATE GROUP command has the following output:

Table A-23. CREATE GROUP output
Output Description
ERROR: You must have Manage Security privilege to set the security label audit
permission category or history collection for a group.
denied.
Description
For details about all the options of the CREATE GROUP command, see theIBM
Netezza Database User’s Guide. The CREATE GROUP command has the following
characteristics:
Privileges required
You must have Manage Security privilege to create a group with additional
clauses.
Common tasks
Use the CREATE GROUP command to create a group with additional
clauses.
Usage

CREATE GROUP FLIGHT;

Use the CREATE SECURITY LEVEL command to create a security level, giving it a
name and a value.

Synopsis
Syntax for creating a security level:

CREATE SECURITY LEVEL <level-name> VALUE <level-number>
Inputs
The CREATE SECURITY LEVEL command has the following inputs:

Table A-24. CREATE SECURITY LEVEL inputs
Input Description
<level_name> An identifier for the level name. The name must be unique among
security level names. Due to the total size limitation of the system
security label field, use short level names. For compatibility with other
vendors, do not use delimited identifiers, but use only ASCII characters,
and limit name length to 30 characters.
<level_number> A positive integer level value 1 - 32766. Higher levels are more secure;
lower values are less secure.
Outputs
The CREATE SECURITY LEVEL command has the following outputs:

Table A-25. CREATE SECURITY LEVEL outputs
Output Description
CREATE SECURITY LEVEL The message that the system returns if the command is
successful.
denied. level.
ERROR: level number The specified level number exists. A level number can only
<number> already exists. have one name.
ERROR: level number The level number must be 1 - 32766. Level number 0 is
<number> is out of pre-defined by the system as level PUBLIC. Level number
range. 32767 is pre-defined by the system as level OMNI. Negative
level numbers are not allowed.
ERROR: object The level name must be different from all other security level
<level-name> already names.
exists.
Description
This command creates a security level of the given name. The security manager
must carefully allocate level numbers. IBM Netezza suggests leaving gaps between
levels so that a level can be added if needed later.
Privileges required
Common tasks
Use the CREATE SECURITY LEVEL command to update the system
catalog to add the new object, and update the security level name to value
mapping.

Usage

CREATE SECURITY LEVEL SECRET VALUE 99;
Related reference:
“ALTER SECURITY LEVEL” on page A-12
CREATE TABLE
Use the CREATE TABLE command to create a table with the option of row
security support.
Synopsis
Syntax for creating a table:

CREATE TABLE <table-name> ( <element-list> )
[ DISTRIBUTE ON { RANDOM | [HASH] ( <distribution-list> ) } ]
[ ROW SECURITY ]
Inputs
The CREATE TABLE command has the following input:

Table A-26. CREATE TABLE input
Input Description
ROW Create a table with row-level security.
SECURITY
Outputs
There is no changed output.
Description
For details about all the options of the CREATE TABLE command, see theIBM
Netezza Database User’s Guide. The CREATE TABLE command has the following
characteristics:
Privileges required
You must have CREATE TABLE privilege to create a table. No additional
privilege is required to create a table with row-level security.
Common tasks
Use the CREATE TABLE command to create a table with the option of row
security support.
Usage

CREATE TABLE NEWTABLE DISTRIBUTE ON RANDOM ROW SECURITY;
CREATE USER
Use the CREATE USER command to create a user with additional clauses.

Synopsis
Syntax for creating a user:

CREATE USER <user-name> [WITH] [<create_user_clause>]...
<create_user_clause> ::=
PASSWORD { ’string’ | NULL }
| IN GROUP { <group-name> },...
| VALID UNTIL <valid-date>
| ROWSETLIMIT <limit>
| DEFPRIORITY [critical|high|normal|low|none]
| MAXPRIORITY [critical|high|normal|low|none]
| SYSID <id-number>
| IN RESOURCEGROUP <group-name>
| SECURITY LABEL <label-string>
| SECURITY LABEL ’ [<level>] : [<category>,]... :
[<cohort>,]...’
| AUDIT CATEGORY { NONE | ’ <category> ,...' }
| AUTH [LOCAL|DEFAULT]
| EXPIRE PASSWORD
Inputs
The CREATE USER command has the following additional inputs:

Table A-27. CREATE USER inputs
Input Description
SECURITY LABEL Specifies the security label of a user. If a SECURITY LABEL
is not specified, the default label ‘PUBLIC::’ is assigned. The
label is surrounded by parentheses so that identifiers in the
label do not conflict with keywords of the other user
clauses.
AUDIT CATEGORY Specifies the audit categories of the users. One or more audit
<category> categories can be specified. The categories are added to the
security label during audit logging.
COLLECT HISTORY [ ON | Determines whether this session collects history of a user.
OFF | DEFAULT ] ON indicates that history is collected for this user when
ON. OFF indicates that history is not collected for this user.
DEFAULT means to examine groups this user is a member
of to determine whether to collect history. If any group has
ON. If no group has COLLECT HISTORY ON, but a group
has COLLECT HISTORY OFF, then no history is collected. If
all groups have DEFAULT history collection, the history is
collected. DEFAULT is the default for a user, if the
COLLECT HISTORY clause is not specified.
CONCURRENT SESSIONS Sets the maximum number of concurrent sessions this user
<limit> can have. A value of 0 means no limit to the number of
which this user is a member. In that case, the minimum
limit of concurrent sessions across all such groups is used.

Table A-27. CREATE USER inputs (continued)
Input Description
group permission, and takes the lowest non-null value,
where FALSE is lower than TRUE.

ACCESS TIME ALL Indicates that this user can start sessions on the IBM
Netezza system at any time on any day.
ACCESS TIME DEFAULT Indicates that access time restrictions are taken from the
groups this user is a member of. If no groups have access
time restrictions, then the user can start sessions at any time
on any day. The access time restriction is evaluated for every
group that has one. If any group restricts access, the user
cannot create a session. That is, the most restrictive access
policy is applied.
keyword ALL can be use to specify all days of the week; it
is equivalent to 1,2,3,4,5,6,7. An access time subclause
optionally contains one time bound. If no time bound is
specified, then the user can create a session at any time on
the specified day.
AUTH [LOCAL | Sets the overriding authentication for the user to LOCAL
DEFAULT] (checks the password against the local database/catalog),
regardless of the connection setting. To revert this setting to
the default setting, use AUTH DEFAULT.
EXPIRE PASSWORD If this value is set while the user is logged in, it does not
affect the current session, but requires the user to change
their password the next time they log in.
Outputs
The CREATE USER command has the following output:

Table A-28. CREATE USER output
Output Description
security label, audit category, or history collection of
a user.
Description
The CREATE USER command has the following characteristics:

Privileges required
You must have Manage Security privilege to set the security label, audit
category, or history collection of a user.
Common tasks
Use the CREATE USER command to create a user with additional clauses.
Usage

CREATE USER BOB WITH AUDIT CATEGORY TOP;
DROP CATEGORY
Use the DROP CATEGORY command to remove the category from the label
security configuration.
Synopsis
Syntax for removing a category:

DROP CATEGORY <name>
Inputs
The DROP CATEGORY command has the following input:

Table A-29. DROP CATEGORY input
Input Description
<name> The identifier of an existing category.
Outputs
The DROP CATEGORY command has the following outputs:

Table A-30. DROP CATEGORY outputs
Output Description
DROP CATEGORY The message that the system returns if the command is successful.
ERROR: You cannot drop a category after there is user data that might reference
permission it.
denied.
ERROR: label The specified category was not found.
security in
use.
Description
Privileges required
You must have Manage Security privilege to drop security categories.
Common tasks
Use the DROP CATEGORY command to remove the category from the
label security configuration.

Usage

DROP CATEGORY ARGON;
Related reference:
DROP COHORT
Use the DROP COHORT command to remove a cohort.
Synopsis
Syntax for dropping a cohort:

DROP COHORT <name>
Inputs
The DROP COHORT command has the following input:

Table A-31. DROP COHORT input
Input Description
<name> The identifier of an existing cohort.
Outputs
The DROP COHORT command has the following outputs:

Table A-32. DROP COHORT outputs
Output Description
DROP COHORT The message that the system returns if the command is successful.
ERROR: permission You must have Manage Security privilege to create a security level.
denied.
ERROR: label You cannot drop a cohort when there is user data that references it.
security in use.
Description
The DROP COHORT command removes the cohort from the label security
configuration. Any children of this cohort are modified so they have no parent
cohort.
Privileges required
Common tasks
Use the DROP COHORT command to remove a cohort.

Usage

DROP COHORT SECRET;
Related reference:
DROP HISTORY CONFIGURATION

Use the DROP HISTORY CONFIGURATION command to drop the configuration
for query or audit history logging.
Synopsis
Syntax for dropping a history configuration:

DROP HISTORY CONFIGURATION <config-name> [ PASSPHRASE <phrase> ]
Inputs
The DROP HISTORY CONFIGURATION command has the following inputs:

Table A-33. DROP HISTORY CONFIGURATION inputs
Input Description
config_name This configuration name must exist.
PASSPHRASE <phrase> The character string phrase of the configuration. If
the configuration is TYPE AUDIT, then you must
specify the matching phrase of the configuration for
the DROP to succeed.
Outputs
The DROP HISTORY CONFIGURATION command has the following outputs:

Table A-34. DROP HISTORY CONFIGURATION outputs
Output Description
DROP HISTORY CONFIGURATION The message that the system returns if the command
is successful.
ERROR: permission denied. You must have Manage Security privilege.
ERROR: invalid passphrase. The passphrase provided is not correct.
Description
For details about all the options of the DROP HISTORY CONFIGURATION
command, see theIBM Netezza Database User’s Guide. This command does not allow
the current query or audit history configuration to be dropped. If you want to
drop the current configuration you have from SET HISTORY CONFIGURATION to
another configuration, restart the IBM Netezza system and then DROP HISTORY
CONFIGURATION.

After you drop a history configuration, any existing but unloaded history files in
the staging or loading area for that configuration will not be loaded. When the
loading process attempts to load those files, it will not be able to find the
associated history-logging configuration, and will move the files to the error
directory ($NZ_DATA/hist/error).
Privileges required
You must have Manage Security privilege to drop a history configuration.
Common tasks
The DROP HISTORY CONFIGURATION command does the following:
v Checks if the configuration is current configuration and if so, it returns
an error.
v If the configuration is not current, it drops the configuration.
Usage

DROP HISTORY CONFIGURATION all_hist VERSION 2;
DROP SECURITY LEVEL

Use the DROP SECURITY LEVEL command to remove a security level.
Synopsis
Syntax for removing a security level:

DROP SECURITY LEVEL <level-name>
Inputs
The DROP SECURITY LEVEL command has the following input:

Table A-35. DROP SECURITY LEVEL input
Input Description
<level_name> The identifier of an existing level name.
Outputs
The DROP SECURITY LEVEL command has the following outputs:

Table A-36. DROP SECURITY LEVEL outputs
Output Description
DROP SECURITY LEVEL The message that the system returns if the command is
successful.
denied. level.
ERROR: object The level name must exist.
<level-name> not
found.
ERROR: label security You cannot remove a security level after there is user data that
in use. might reference that level.

Description
The DROP SECURITY LEVEL command removes a security level if there are no
ROW SECURITY tables defined in any database in the system.
Privileges required
You must have Manage Security privilege to drop security levels.
Common tasks
Use the DROP SECURITY LEVEL command to remove a security level.
Usage

DROP SECURITY LEVEL SECRET;
Related reference:
EXECUTE AS
Use the EXECUTE AS command to set the CURRENT USER of the session.
Synopsis
Syntax for setting the current user:

EXECUTE AS <target-user-name>
Inputs
The EXECUTE AS command has the following input:

Table A-37. EXECUTE AS input
Input Description
<target-user-name> The name of an existing user.
Outputs
The EXECUTE AS command has the following outputs:

Table A-38. EXECUTE AS outputs
Output Description
EXECUTE AS The message that the system returns if the command
is successful.
ERROR: permission denied. You must have EXECUTE AS privilege on the target
user.
Description
This statement allows a suitably privileged user to set the CURRENT USER of
their session to a different user. On successful completion of this statement, the
CURRENT USER is the target user specified in the syntax. Security checks are
based on the security profile the CURRENT USER.

The current_user function returns the target user. The session_user function returns
the original session user.
EXECUTE AS operates outside of the transaction scope, just like SET statements.
Running EXECUTE AS while in an explicit transaction is allowed. Rolling back the
transaction does not affect the EXECUTE AS setting. For example, suppose that
you are running as jdoe and running the following:
BEGIN;
EXECUTE AS dd;
ROLLBACK;
SELECT current_user;
CURRENT_USER
--------------
DD
(1 row)
Privileges required
You must have EXECUTE AS privilege on the target user.
Common tasks
Use the EXECUTE AS command to set the CURRENT USER of the session.
Usage

EXECUTE AS BOB;
Related reference:
“REVERT”
REVERT
Use the REVERT command to reset the CURRENT USER of the session back to the
previous EXECUTE AS user; if none, then revert to the SESSION USER.
Synopsis
Syntax for using the command:

REVERT
Inputs
None.
Outputs
The REVERT command has the following outputs:

Table A-39. REVERT outputs
Output Description
REVERT The message that the system returns if the command is
successful.
ERROR: REVERT without You must run a successful EXECUTE AS command to run a
preceding EXECUTE AS. REVERT.

Description
The REVERT command has the following characteristics:

Privileges required
No specific privilege is needed to issue this statement. However, you must
have EXECUTE AS privilege on the current user to need a REVERT
statement.
Common tasks
Reset the CURRENT USER of the session back to the previous EXECUTE
AS user.
Usage
REVERT;
Related reference:
“EXECUTE AS” on page A-30
SET HISTORY CONFIGURATION

Use the SET HISTORY CONFIGURATION command to specify which history
configuration settings are to take effect after the next Netezza system restart. This
command is run on the source IBM Netezza system.
Syntax
Syntax for this command:

SET HISTORY CONFIGURATION <config-name> [ PASSPHRASE <phrase> ]
Inputs
The SET HISTORY CONFIGURATION command has the following inputs:

Table A-40. SET HISTORY CONFIGURATION inputs
Input Description
config_name Sets the current history configuration to this
configuration on the next Netezza start.
PASSPHRASE <phrase> The character string phrase of the configuration. If
the configuration is TYPE AUDIT, then you must
specify the matching phrase of the configuration for
the SET to succeed.
Outputs
The SET HISTORY CONFIGURATION command has the following outputs:

Table A-41. SET HISTORY CONFIGURATION outputs
Output Description
SET HISTORY CONFIGURATION The message that the system returns if the command
is successful.
query or audit history setting.

Table A-41. SET HISTORY CONFIGURATION outputs (continued)
Output Description
ERROR: invalid passphrase. The passphrase provided is not correct.
Description
Until the next Netezza software restart, the current configuration and settings
remain in effect. After the restart, the history loader process attempts to load any
existing history data in the staging or loading area for the previous configuration.
Privileges required
You must be the admin user, or your account must have Manage Security
permissions to set a history configuration.
Usage
SET HISTORY CONFIGURATION all_hist;
SHOW CATEGORY
Use the SHOW CATEGORY command to display one or more categories.
Synopsis
Syntax for displaying one or more categories:

SHOW CATEGORY [ [NAME] <category-name> | ALL ]
Inputs
The SHOW CATEGORY command has the following inputs:

Table A-42. SHOW CATEGORY inputs
Input Description
ALL When ALL is specified, all security categories are displayed. ALL is the
default.
<category- The name of a security category to display.
name>
Outputs
The SHOW CATEGORY command has the following output:
Display all categories:

SYSTEM.ADMIN(ADMIN)=> SHOW CATEGORY ALL;
NAME | ID
------+----
ABC | 1
DEF | 2
GHI | 3
OMNI | 0
(4 rows)

Display one category:
SYSTEM.ADMIN(ADMIN)=> SHOW CATEGORY abc;
NAME | ID
------+----
ABC | 1
(1 row)
Display non-existent category:

SYSTEM.ADMIN(ADMIN)=> SHOW CATEGORY xyz;
NAME | ID
------+----
(0 rows)
Attempt to display categories by a user without Manage Security permissions:

DEV.SCH(DD)=> SHOW CATEGORY All;
NAME | ID
------+----
(0 rows)
Description
Privileges required
You must have Manage Security privilege to show security categories.
Common tasks
Use the SHOW CATEGORY command to display one or more categories.
Usage

SHOW CATEGORY ALL;
Related reference:
SHOW COHORT
Use the SHOW COHORT command to display one or more cohorts or to display
the cohort hierarchy.
Synopsis
Syntax for displaying cohorts:

SHOW COHORT [ [NAME] <cohort-name> | ALL ] [ HIERARCHY ]
Inputs
The SHOW COHORT command has the following inputs:

Table A-43. SHOW COHORT inputs
Input Description
ALL When ALL is specified, all security cohorts are displayed. ALL is the
default.
<cohort_name> The name of a security cohort to display.

Table A-43. SHOW COHORT inputs (continued)
Input Description
HIERARCHY When HIERARCHY is specified, the parent-child hierarchy of cohorts is
displayed.
Outputs
The SHOW COHORT command has the following outputs:
Display all cohorts:

SYSTEM.ADMIN(ADMIN)=> SHOW COHORT ALL;
NAME | ID | CLOSURE
---------+----+---------
HR | 2 | HR
SW | 1 | SW
HW | 3 | HW
OMNI | 0 |
(4 rows)
Display one cohort:

SYSTEM.ADMIN(ADMIN)=> SHOW COHORT HR;
NAME | ID | CLOSURE
------+----+---------
HR | 2 | HR
(1 row)
Display non-existent cohort:

SYSTEM.ADMIN(ADMIN)=> SHOW COHORT notthere;
NAME | ID | CLOSURE
------+----+---------
(0 rows)
Attempt to display cohorts by a user without Manage Security permissions:

DEV.SCH(DD)=> SHOW COHORT HR;
NAME | ID | CLOSURE
------+----+---------
(0 rows)
Description
The SHOW COHORT command has the following characteristics:

Privileges required
You must have Manage Security privilege to show security cohorts.
Common tasks
Use the SHOW COHORT command to display the security cohorts.
Usage

SHOW COHORT HR;
Related reference:

SHOW HISTORY CONFIGURATION
Use the SHOW HISTORY CONFIGURATION command to display the query or
audit history configuration settings. This command is run on the source IBM
Netezza system. By default with no arguments, it gives the current query or audit
history configuration.
Syntax
Syntax for the command:

SHOW HISTORY CONFIGURATION [ <config-name> | ALL ]
Inputs
The SHOW HISTORY CONFIGURATION command has the following inputs:

Table A-44. SHOW HISTORY CONFIGURATION inputs
Input Description
ALL Displays the details of all the query or audit history configurations.
config_name Displays the details of the specific query or audit history configuration.
Outputs
The SHOW HISTORY CONFIGURATION command has the following outputs:

Table A-45. SHOW HISTORY CONFIGURATION outputs
Output Description
SHOW HISTORY The message that the system returns if the command is successful.
CONFIGURATION
ERROR: permission You must have Manage Security privilege to configure query or
denied. audit history logging.
ERROR: <config-name> The specified configuration name cannot be found.
not found.
Description
For details about all the options of the SHOW HISTORY CONFIGURATION
command, see theIBM Netezza Database User’s Guide. This command displays the
current or ALL or a specific query or audit configuration settings.
Privileges required
You must be an administrator or must have the Manage Security
permission
Common tasks
Use the SHOW HISTORY CONFIGURATION command to display the
query or audit history configuration settings.
Usage

SHOW HISTORY CONFIGURATION ALL;

SHOW SECURITY LEVEL
Use the SHOW SECURITY LEVEL command to display one or all security levels.
Synopsis
Syntax for showing a security level:

SHOW SECURITY LEVEL [ [NAME] <level-name> | ALL ]
Inputs
The SHOW SECURITY LEVEL command has the following inputs:

Table A-46. SHOW SECURITY LEVEL inputs
Input Description
ALL When ALL is specified, all security levels are displayed. ALL is the
default.
<level_name> The name of a security level to display.
Outputs
The SHOW SECURITY LEVEL command has the following outputs:
Display all security levels:

DEV(ADMIN)=> SHOW SECURITY LEVEL ALL;
NAME | LEVEL
--------+-------
PUBLIC | 0
LOW | 10
MED | 20
HIGH | 30
OMNI | 32767
(5 rows)
Display one security level:

DEV(ADMIN)=> SHOW SECURITY LEVEL med;
NAME | LEVEL
------+-------
MED | 20
(1 row)
Display non-existent security level:

DEV(ADMIN)=> SHOW SECURITY LEVEL xyzzy;
NAME | LEVEL
------+-------
(0 rows)
Attempt to display security levels by a user without Manage Security permissions:

DEV.SCH(DD)=> SHOW SECURITY LEVEL ;
NAME | LEVEL
------+-------
(0 rows)
Description
The SHOW SECURITY LEVEL command has the following characteristics:

Privileges required
You must have Manage Security privilege to show security levels.
Common tasks
Use the SHOW SECURITY LEVEL command to display the security levels.
Usage

SHOW SECURITY LEVEL ALL;
Related reference:
CLI commands
This section describes the CLI commands for the security feature.
The nzhistcleanupdb command

Use the nzhistcleanupdb command to periodically delete old history information
from a history database.
Synopsis
Syntax for deleting old history information from a history database:

nzhistcleanupdb [options]
Inputs
The nzhistcleanupdb command takes the following input options. The input
options have two forms for the option names.
Table A-47. The nzhistcleanupdb inputs
Input Description
-d | --db Specifies the name of the history database from which you want to remove
<dbname> old data. The name must be a valid, unquoted, identifier.
-n | --host Specifies the host name of the IBM Netezza system where the database is.
<hostname> The default and only value for this option is NZ_HOST.
Outputs
None.
Description
After running the command, you can run nzreclaim to completely remove the
deleted rows in the table. However, use caution when planning the time to reclaim.
Reclaims lock the tables that they process, which can cause the loader to error
when attempting to load new history data.
Privileges required
You must be the nz user to run this command.

Common tasks
This command deletes old history information from a history database.
Usage
The following deletes history data which is older than January 1, 2009,10:45 p.m.,
from the histdb history database:
nzhistcleanupdb -d histdb -u myuser -p password -t "1/1/2009,22:45"
Related concepts:
“Audit database” on page 5-2
The nzverifyauditsig command

Use the nzverifyauditsig command to verify the signature of a signed block in a
specified audit database table.
Synopsis
Syntax for this command:

nzverifyauditsig [options]
Inputs
The nzverifyauditsig command takes the following inputs.

Table A-48. The nzverifyauditsig inputs
Input Description
-d | --db The name of the history database.
<dbname>
-f|--le-start The starting log entry ID of the signed block.
<logEntryStart>
-l|--le-end The ending log entry ID of the signed block.
<logEntryEnd>
-m|--npsid The ID of the source IBM Netezza system.
<npsid>
-i|--instance The instance ID of the source Netezza system.
<npsinstanceid>
-n|--host The host name of the target Netezza system. The default is NZ_HOST.
<host>
-p|--pwd The password for USER that is used for getting audit data. The default is
<password> NZ_PASSWORD.
-s|--seq-start The starting sequence ID of the signed block. The default is 0.
<seqIdStart>
-e|--seq-end The ending sequence ID of the signed block. The default is 0.
<seqIdEnd>

Table A-48. The nzverifyauditsig inputs (continued)
Input Description
-t|--type The type of audit table database to verify. You can specify additional
<audittype> information:
v Failed_authentication (0)
v Session_prolog (1)
v Session_epilog (2)
v Query_prolog (3)
v Query_epilog (4)
v Query_overflow (5)
v Log_entry (6)
v Plan_prolog (7)
v Plan_epilog (8)
v Table_access (9)
v Table_access (9)
v Service (11)
v State_change (12)
-u|--user The USER account used to extract audit data. The default is NZ_USER.
<user>
-v|--schema The version of the history database. For Netezza Release 4.6, the number
<num> is 1. Starting in Release 7.0.3, the version number is 2 to support multiple
schemas and other changes. Starting in Release 7.1, the version number is
3 to support scheduler rules and client information fields.
-h|--help Display the help for this topic.
Outputs
The nzverifyauditsig command has the following outputs:

Table A-49. The nzverifyauditsig output
Output Description
Signature verified. The digital signature and key used were checked and verified.
Signature could not The digital signature and key used were checked and cannot be
be verified. verified.
Description
Verifies the signature of a signed block in a specified audit database table.

Privileges required
None.
Common tasks
Verify a signed block.
Usage

nzverifyauditsig -d auditdb -t query_epilog -v 2 -u histusr -p admpw
-i 2 -m 1

Appendix B. Examples
This section contains examples to aid you in understanding advanced security
tasks.
Create a database security officer and database administrator

Log in as administrator (ADMIN) and create a Database Administrator (DBA) with
the minimum security label:
SYSTEM.ADMIN(ADMIN)=> CREATE USER dba ’PASSWORD ’dddd’ SECURITY LABEL ’::’;
CREATE USER
SYSTEM.ADMIN(ADMIN)=> GRANT CREATE DATABASE to dba;
GRANT
The DBA is not able to see any data above 'PUBLIC::' even in tables that they
create.
As administrator, create a Database Security Officer (DSO) with the minimum

security label. Giving Manage Security permission allows the DSO to change their
setting.
SYSTEM.ADMIN(ADMIN)=> CREATE USER dso PASSWORD ’dddd’ SECURITY LABEL ’::’;
CREATE USER
SYSTEM.ADMIN(ADMIN)=> GRANT MANAGE SECURITY to dso;
GRANT
SYSTEM.ADMIN(ADMIN)=> GRANT CREATE USER to dso;
GRANT
SYSTEM.ADMIN(ADMIN)=> GRANT LIST ON dba to dso;
GRANT
Create a security model as database security officer

For this example, log in as the newly created DSO and create a security model by
using levels, categories, and cohorts.
SYSTEM.ADMIN(ADMIN)=> \c system dso dddd
You are now connected to database system as user dso.
SYSTEM.ADMIN(DSO)=> CREATE SECURITY LEVEL confidential VALUE 100;
SYSTEM.ADMIN(DSO)=> CREATE SECURITY LEVEL secret VALUE 200;
SYSTEM.ADMIN(DSO)=> CREATE SECURITY LEVEL "Top Secret" VALUE 300;
SYSTEM.ADMIN(DSO)=> CREATE CATEGORY red;
CREATE CATEGORY
SYSTEM.ADMIN(DSO)=> CREATE CATEGORY green;
CREATE CATEGORY
SYSTEM.ADMIN(DSO)=> CREATE CATEGORY blue;
CREATE CATEGORY
SYSTEM.ADMIN(DSO)=> CREATE COHORT corp;
CREATE COHORT
SYSTEM.ADMIN(DSO)=> CREATE COHORT hr in COHORT corp;
CREATE COHORT
SYSTEM.ADMIN(DSO)=> CREATE COHORT fin in COHORT corp;
CREATE COHORT
SYSTEM.ADMIN(DSO)=> CREATE COHORT eng in COHORT corp;
CREATE COHORT
SYSTEM.ADMIN(DSO)=> CREATE COHORT qa in COHORT eng;
CREATE COHORT
© Copyright IBM Corp. 2009, 2014 B-1

SYSTEM.ADMIN(DSO)=> CREATE COHORT sw in COHORT eng;
CREATE COHORT
SYSTEM.ADMIN(DSO)=> CREATE COHORT hw in COHORT eng;
CREATE COHORT
Create sample users

For this example, log in as the DSO and create sample users. Then grant the DBA
List privileges on the users created.
SYSTEM.ADMIN(DSO)=> CREATE USER sw1 PASSWORD ’swsw’ SECURITY LABEL
’confidential:green:sw’;
CREATE USER
SYSTEM.ADMIN(DSO)=> CREATE USER sw2 PASSWORD ’swsw’ SECURITY LABEL
’confidential:red:sw’;
CREATE USER
SYSTEM.ADMIN(DSO)=> CREATE USER engmgr PASSWORD ’emem’ SECURITY LABEL
’secret:red, green:eng’;
CREATE USER
SYSTEM.ADMIN(DSO)=> GRANT LIST ON sw1,sw2,engmgr to dba;
GRANT
Create a database and grant access

As the DBA, create a database (mlssample), connect to it, and grant access to the
users. The DSO does not need access to the created database.
SYSTEM.ADMIN(DSO)=> \c system dba dddd
You are now connected to database system as user dba.
SYSTEM.ADMIN(DBA)=> CREATE DATABASE mlssample;
CREATE DATABASE
SYSTEM.ADMIN(DSO)=> GRANT CONNECT ON mlssample to sw1,sw2,engmgr;
GRANT
SYSTEM.ADMIN(DBA)=> \c mlssample dba dddd
You are now connected to database mlssample as user dba.
Create a row-secure table with permissions

For this example, create a row-secure table (projstatus) and grant privileges for the
users.
MLSSAMPLE.SCH(DBA)=> CREATE TABLE projstatus(id int, name varchar(80),
metric int) ROW SECURITY;
CREATE TABLE
MLSSAMPLE.SCH(DBA)=> GRANT SELECT, INSERT, UPDATE, DELETE ON projstatus to
sw1;
GRANT
MLSSAMPLE.SCH(DBA)=> GRANT SELECT, INSERT, UPDATE, DELETE, LABEL ACCESS on
projstatus to sw2;
GRANT
MLSSAMPLE.SCH(DBA)=> GRANT SELECT, INSERT, UPDATE, DELETE, LABEL ACCESS,
LABEL EXPAND on projstatus to engmgr;
GRANT
The following are the privileges of each user:

v User sw1 can operate on projstatus, but cannot see the labels.
v User sw2 can operate on projstatus, can see the labels, but cannot change them.
v User engmgr can operate on projstatus, can see the labels, and can declassify
data.
B-2 IBM Netezza Advanced Security Administrator's Guide

The engmgr role
For this example, insert values into the projstatus database by using the engmgr
role. By default, the insert command uses the security label of the inserter. Also
_sec_label does not automatically expand from the asterisk, you must specifically
request it.
MLSSAMPLE.SCH(DBA)=> \c mlssample engmgr emem
You are now connected to database mlssample as user engmgr.
MLSSAMPLE.SCH(ENGMGR)=> INSERT INTO projstatus VALUES (1, ’Secret
Project’, 105);
INSERT 0 1
MLSSAMPLE.SCH(ENGMGR)=> SELECT *, _SEC_LABEL FROM projstatus;
ID | NAME | METRIC | _SEC_LABEL
----+----------------+--------+----------------------
1 | Secret Project | 105 | SECRET:RED,GREEN:ENG
(1 row)
The next example explicitly enters a label, which is allowed because the engmgr
has Label Expand permission, which allows insertion of a label less restrictive than
their own
MLSSAMPLE.SCH(ENGMGR)=> INSERT INTO projstatus(id,name,metric,_SEC_LABEL)
VALUES (2, ’Project Red’, 113) ’confidential:red:eng’);
INSERT 0 1
The next example explicitly enters a label that sw1 can see.
VALUES (3, ’Project Green’, 113) ’confidential:green:eng’);
INSERT 0 1
The next example fails because sw is a subset of eng, making it a more restrictive
label. This would be allowed if engmgr had Label Restrict permission.
VALUES (4, ’Manhattan’, 102) ’secret:red:sw’);
ERROR: Security Label : Permission denied.
The next example fails because the category name does not exist.
VALUES (4, ’General’, 164) ’confidential:eng’);
ERROR: Security Label : Category name does not exist.
Use select to see the results.

MLSSAMPLE.SCH(ENGMGR)=> SELECT *, _SEC_LABEL FROM projstatus;
----+----------------+--------+------------------------
3 | Project Green | 113 | CONFIDENTIAL:GREEN:ENG
1 | Secret Project | 105 | SECRET:RED,GREEN:ENG
2 | Project Red | 113 | CONFIDENTIAL:RED:ENG
(3 rows)
The sw2 role

This example shows the use of the sw2 role.
MLSSAMPLE.SCH(ENGMGR)=> \c mlssample sw2 swsw
You are now connected to database mlssample as user sw2.
MLSSAMPLE.SCH(SW2)=> INSERT INTO projstatus VALUES (5, ’SW2 RED’, 196);
INSERT 0 1
MLSSAMPLE.SCH(SW2)=> SELECT *, _SEC_LABEL FROM projstatus;
Appendix B. Examples B-3

----+---------+--------+---------------------
5 | SW2 Red | 196 | CONFIDENTIAL:RED:SW
(1 row)
The user has Label Access permission, and can see the label. In the following
example, the user does not have Label Expand permission to change from
confidential to public.
MLSSAMPLE.SCH(SW2)=> UPDATE projstatus SET _SEC_LABEL = ’public:red:sw’
WHERE NAME = ’SW2 Red’;
Now change to engmgr to try the example again. With Label Expand permission, it
now works. The rule to expand is relative to the existing row label, not the security
label of the user, and is independent of the ability to create the label.
MLSSAMPLE.SCH(SW2)=> \c mlssample engmgr emem
You are now connected to database mlssample as user engmgr.
MLSSAMPLE.SCH(ENGMGR)=> UPDATE projstatus SET _SEC_LABEL = ’public:red:sw’
WHERE NAME = ’SW2 Red’;
Update 1
The following example fails due to an improper security label.

MLSSAMPLE.SCH(ENGMGR)=> INSERT INTO projstatus (id, name, metric,
_SEC_LABEL) VALUES (10, ’Ten’, 10, ’public:red:sw’);
The sw1 role

This example shows the use of the sw1 role, where the row-secure table looks like
an ordinary table.
MLSSAMPLE.SCH(ENGMGR)=> \c mlssample sw1 swsw
You are now connected to database mlssample as user sw1.
MLSSAMPLE.SCH(SW1)=> INSERT INTO projstatus VALUES (1, ’SW1 Project’,
143);
INSERT 0 1
The following example fails because the user does not have Label Access.
MLSSAMPLE.SCH(SW1)=> SELECT *, _SEC_LABEL FROM projstatus;
ERROR: query: permission denied.
MLSSAMPLE.SCH(SW1)=> SELECT * FROM projstatus;
ID | NAME | METRIC
----+-------------+--------
1 | SW1 Project | 143
(1 row)
The following examples work normally.

MLSSAMPLE.SCH(SW1)=> UPDATE projstatus SET METRIC = 145 WHERE NAME = ’SW1
Project’;
UPDATE 1
MLSSAMPLE.SCH(SW1)=> DELETE projstatus WHERE NAME = ’SW1 Project’;
DELETE 1
In the following example, the project cannot be deleted, because it cannot be seen
with the available permissions.
MLSSAMPLE.SCH(SW1)=> DELETE projstatus WHERE NAME = ’Project Red’;
DELETE 0

Show restrictions
This example shows that the DBA, who owns the table, cannot see any of the
row-secure rows. The security label of the DBA is PUBLIC::, and the data in the
row-secure table has more restrictive labels.
MLSSAMPLE.SCH(SW1)=> \c mlssample dba dddd
You are now connected to database mlssample as user dba.
MLSSAMPLE.SCH(DBA)=> SELECT * FROM projstatus;
ID | NAME | METRIC
----+-------------+--------
(0 rows)
Appendix B. Examples B-5

Appendix C. Enable and disable security commands
This section explains how to enable or disable the advanced security commands
and features.
The advanced security features are disabled by default on Netezza systems. If you
run a command that is described in this document and the command fails with the
message ERROR: <command> is not currently supported, you must enable the
features.
To enable or disable the features, you must log in to the IBM Netezza system host,
set the history configuration to QUERY or NONE and edit the postgresql.conf
file. After you specify the configuration setting, save the file and restart the system
(nzstop and nzstart) for the settings to take effect.
The enable_execute_as setting

When the setting is true, you can use the EXECUTE AS and REVERT statements;
and GRANT and REVOKE the EXECUTE AS permission.
When the flag is false, the system returns an error if you use EXECUTE AS and
REVERT.
The enable_login_constraints setting

When the setting is true, you can specify the CONCURRENT SESSIONS and
ACCESS TIME clauses on users and groups. The system enforces those settings
when users connect to the system.
When the flag is false, the system no longer enforces those settings. For example, a
user with CONCURRENT SESSIONS set to 1 before the setting changed to false
can have any number of concurrent sessions.
The enable_collect_history setting

When the setting is true, you can specify the COLLECT HISTORY clause on users,
groups, and databases. The system enforces those settings when users connect to
the system.
Suppose that you created a history configuration with some users and some
databases to have COLLECT HISTORY OFF.
v When the setting is true, the collect history setting is enforced and history is not
collected for those users and databases.
v When the setting is false, the system no longer enforces those settings, so history
is collected for all users on all databases.
© Copyright IBM Corp. 2009, 2014 C-1

The enable_row_security setting
When the ENABLE_ROW_SECURITY setting is true:
v ROW SECURITY tables can be created, accessed, and dropped.
v The security model (level, category, cohort) can be created and managed.
v The security label and audit attributes of users are calculated and enforced.
When the setting is false, the following happens:

v All users get the security label ‘PUBLIC::’ and no audit category. The
administrator gets ‘OMNI:OMNI:OMNI’.
v ROW SECURITY tables cannot be created, accessed, or dropped with the
following exceptions:
– The nzbackup command continues to function to allow the row secure tables
to be backed up.
– Creation of compressed external tables from row secure tables is permitted to
allow nzbackup to function properly.
– SELECT of row secure tables continues to operate and enforces security.
However, since all users have the lowest access label, any sensitive labeled
data is not visible.
The enable_audit setting

If the ENABLE_ROW_SECURITY setting is false, this setting is treated as though it
is false. So if row security is disabled, audit is implicitly disabled.
If row security is enabled, audit can be enabled or disabled.
When ENABLE_ROW_SECURITY is true and ENABLE_AUDIT is true, then you

can create audit configurations with digital signing keys. In addition, you can
create keystores that contain keys for digital signing.
C-2 IBM Netezza Advanced Security Administrator's Guide

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to: This
information was developed for products and services offered in the U.S.A.
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation

Licensing 2-31 Roppongi 3-chome, Minato-ku
Tokyo 106-0032, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.
This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
© Copyright IBM Corp. 2009, 2014 D-1

Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
Software Interoperability Coordinator, Department 49XA
3605 Highway 52 N
Rochester, MN 55901
U.S.A.
Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled

environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs.
D-2 IBM Netezza Advanced Security Administrator's Guide

Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:
© your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs.
© Copyright IBM Corp. _enter the year or years_.
If you are viewing this information softcopy, the photographs and color
illustrations may not appear.
Trademarks
IBM, the IBM logo, ibm.com® and Netezza are trademarks or registered trademarks
of International Business Machines Corporation in the United States, other
countries, or both. If these and other IBM trademarked terms are marked on their
first occurrence in this information with a trademark symbol (® or ™), these
symbols indicate U.S. registered or common law trademarks owned by IBM at the
time this information was published. Such trademarks may also be registered or
common law trademarks in other countries. A current list of IBM trademarks is
available on the web at "Copyright and trademark information" at
http://www.ibm.com/legal/copytrade.shtml.
Adobe is a registered trademark of Adobe Systems Incorporated in the United

States, and/ or other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other

countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other
names may be trademarks of their respective owners.
Red Hat is a trademark or registered trademark of Red Hat, Inc. in the United
States and/or other countries.
D-CC, D-C++, Diab+, FastJ, pSOS+, SingleStep, Tornado, VxWorks, Wind River,
and the Wind River logo are trademarks, registered trademarks, or service marks
of Wind River Systems, Inc. Tornado patent pending.
APC and the APC logo are trademarks or registered trademarks of American
Power Conversion Corporation.
Other company, product or service names may be trademarks or service marks of

others.
Notices D-3
D-4 IBM Netezza Advanced Security Administrator's Guide
Index
A crypto key
create 4-2
L
access control, time 2-2 drop 4-2 label
access time control 2-2 show 4-2 access 6-7
advanced query history 5-1 expand 6-7
advanced security 1-1 restrict 6-7
AES_256 algorithm 4-1 level 6-1
ALTER D login control, user 2-1
CATEGORY A-3 data capture, audit 5-4
COHORT A-4 data flow, audit 5-3
DATABASE A-5
GROUP A-7
DATABASE
ALTER A-5
M
CREATE A-18 masquerading 3-1
HISTORY CONFIGURATION A-9
Digital signing 4-2 multi-level security 6-1
SECURITY LEVEL A-12
USER A-14 DROP
audit CATEGORY A-26
configuration 5-4 COHORT A-27 N
data capture 5-4 HISTORY CONFIGURATION A-28 nesting 3-2
data flow 5-3 SECURITY LEVEL A-29 NONE 6-1
database 5-2 DSA_KEYPAIR 4-2 nzhistcreatedb 5-2
authentication events 5-6 nzpassword 4-1
E
B enabling security features C-1 P
basic security model 1-1 events, authentication 5-6 password
Blowfish format 4-1 EXECUTE AS 3-1 authentication 2-2
external tables 6-8 encrypting 4-1
expiration 2-2
C G
restrictions 2-2
string restrictions 2-2
category 6-1
GROUP public 1-1
CATEGORY
ALTER A-7 PUBLIC 6-1
ALTER A-3
CREATE A-16 CREATE A-20
DROP A-26
SHOW A-33 Q
changing keys 4-1 H query history 5-1
cohort 6-1 history 5-1
COHORT collect 5-1
ALTER A-4
CREATE A-17
HISTORY CONFIGURATION R
ALTER A-9 resetkey 4-1
DROP A-27 CREATE 5-4 REVERT 3-1, A-31
SHOW A-34 DROP A-28 row-secure tables 6-1
collect history 5-1 SET A-32 RST, See row-secure tables 6-7
commands, service 5-4 SHOW A-36
concurrent loads
RSTs 6-8
concurrent sessions 2-1
K S
context, session 2-1 security
control keys advanced 1-1
access time 2-2 changing 4-1 basic model 1-1
user login 2-1 creating 4-2 model 1-1
CREATE managing 4-1, 4-2 multi-level 6-1
CATEGORY A-16 keystore system 1-2
COHORT A-17 alter 4-2 security label syntax 6-2
DATABASE A-18 create 4-2 security labels 6-1
GROUP A-20 drop 4-2 SECURITY LEVEL
SECURITY LEVEL A-22 show 4-2 ALTER A-12
USER A-24 CREATE A-22
CREATE HISTORY DROP A-29
CONFIGURATION 5-4 SHOW A-37
CREATE TABLE A-23 SERVICE collect flag 5-4
© Copyright IBM Corp. 2009, 2014 X-1

service commands 5-4
session context 2-1
sessions, concurrent 2-1
SET HISTORY CONFIGURATION A-32
SHOW
CATEGORY A-33
COHORT A-34
HISTORY CONFIGURATION A-36
SECURITY LEVEL A-37
stored procedures 3-2
system security 1-2
system state changes 5-5
T
tables
external 6-8
row secure 6-1
U
upgrade best practices 5-6
USER
ALTER A-14
CREATE A-24
user login control 2-1
X-2 IBM Netezza Advanced Security Administrator's Guide

Part Number: 20494 Rev. 1
Printed in USA

7.2 Netezza Advanced Security Admin Guide

Uploaded by

Copyright:

Available Formats

7.2 Netezza Advanced Security Admin Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7.2 Netezza Advanced Security Admin Guide

Uploaded by

Copyright:

Available Formats

IBM Netezza

IBM Netezza Advanced Security

IBM Netezza Advanced Security

Revised: September 8, 2014

Electronic emission notices . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Regulatory and compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

About this publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Chapter 2. User login control . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Chapter 3. Masquerading . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Chapter 4. Key management . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Chapter 5. Advanced query history . . . . . . . . . . . . . . . . . . . . . . . 5-1

Chapter 6. Multi-Level Security and row-secure tables . . . . . . . . . . . . . . . 6-1

© Copyright IBM Corp. 2009, 2014 iii

Appendix A. Netezza SQL and CLI commands . . . . . . . . . . . . . . . . . . A-1

Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Appendix C. Enable and disable security commands . . . . . . . . . . . . . . . C-1

iv IBM Netezza Advanced Security Administrator's Guide

© Copyright IBM Corp. 2009, 2014 v

Federal Communications Commission (FCC) Statement

Industry Canada Class A Emission Compliance Statement

This Class A digital apparatus complies with Canadian ICES-003.

Avis de conformité à la réglementation d'Industrie Canada

Cet appareil numérique de la classe A est conforme à la norme NMB-003 du

Australia and New Zealand Class A Statement

This product is a Class A product. In a domestic environment, this product might

European Union EMC Directive Conformance Statement

This product is in conformity with the protection requirements of EU Council

© Copyright IBM Corp. 2009, 2014 vii

International Business Machines Corp.

European Community contact:

IBM Technical Regulations, Department M456

Germany Class A Statement

Deutschsprachiger EU Hinweis: Hinweis für Geräte der Klasse A EU-Richtlinie

Dieses Produkt entspricht den Schutzanforderungen der EU-Richtlinie

Um dieses sicherzustellen, sind die Geräte wie in den Handbüchern beschrieben zu

EN 55022 Klasse A Geräte müssen mit folgendem Warnhinweis versehen werden:

Deutschland: Einhaltung des Gesetzes über die

Dieses Produkt entspricht dem “Gesetz über die elektromagnetische Verträglichkeit

Zulassungsbescheinigung laut dem Deutschen Gesetz über die

viii IBM Netezza Advanced Security Administrator's Guide

Der verantwortliche Ansprechpartner des Herstellers in der EU ist:

Generelle Informationen: Das Gerät erfüllt die Schutzanforderungen nach EN 55024

Japan VCCI Class A Statement

Japan Electronics and Information Technology Industries

Japan Electronics and Information Technology Industries Association (JEITA)

Japan Electronics and Information Technology Industries

Japan Electronics and Information Technology Industries Association (JEITA)

Electronic emission notices ix

Russia Electromagnetic Interference (EMI) Class A Statement

People's Republic of China Class A Electronic Emission

Taiwan Class A Compliance Statement

x IBM Netezza Advanced Security Administrator's Guide

Provide approved circuit breakers on all power sources.

Product might be powered by redundant power sources. Disconnect ALL power

© Copyright IBM Corp. 2009, 2014 xi

If you need help

How to send your comments