3. OS security/1
Informix can authenticate users through
◦ os authentication: user must have a login on the system
◦ Trusted user: use OS trust capability if dbserver and app server
are different systems
◦ PAM (pluggable authentication module:
Informix supports the PAM framework, that can be used to
develop company standards for authentication
◦ Lightweight Directory Access Protocol (LDAP):
Informix also supports LDAP as an authentication method, only
on Windows clients
Informix and users permissions
◦ Informix uses OS permissions to protect Informix utilities
◦ By default, user informix is the super user BUT
◦ DBSA, DBSSO, AAO and informix roles can be separated using
OS built-in capabilities
www.
3
4. OS security/2
Informix uses standard network security capabilities
◦ ssh can be used to run Informix utilities in a secure way
◦ The Informix database server instance can(must) be placed
behind a firewall to protect it from malicious external attacks
www.
4
5. Sql security/1
Informix can secure data thru SQL commands in 2
ways
DAC: discretionary access control
use of GRANT and REVOKE statements applied to
users, roles, having effect on databases, tables,
views, fragments, routines, UDT…
The permission granted can be connect, resource,
dba, create, alter, select,insert, update, delete,
usage, execute etc…, according to the type of object
impacted
www.
5
6. Sql security/2
Informix can also secure data thru SQL commands using
LBAC: label-based access control
◦ Security can b defined at a row level or at a column level
Tables are protected by security POLICIES
Rows and columns are protected by LABELS
Policies and Labels are granted to users by the database
security administrator
Labels can look like
◦ CREATE SECURITY LABEL COMPONENT classification ARRAY ['Top-Secret','Secret', 'Confidential', Unclassified'];
◦ CREATE SECURITY LABEL COMPONENT org_position ARRAY ['CEO', 'VP','Director', 'Manager','Staff'];
◦ CREATE SECURITY LABEL COMPONENT region TREE ( 'HeadQuarters' ROOT,’East' UNDER
'HeadQuarters','West' UNDER HeadQuarters','North' UNDER 'HeadQuarters','South' UNDER
'HeadQuarters','Georgia' UNDER 'East','Florida' UNDER 'East','Atlanta' UNDER 'Georgia','Texas'
UNDER 'South','Dallas' UNDER Texas','Houston' UNDER 'Texas');
◦ Customer labels can be created
Policies can look like
◦ CREATE SECURITY POLICY sales_plcy COMPONENTS org_position, region;
Policies and labels are granted to users like this:
◦ GRANT SECURITY LABEL sales_plcy.sales_rep TO "usr3" FOR WRITE ACCESS;
◦ GRANT SECURITY LABEL sales_plcy.sales_rep_mgr TO "usr3" FOR READ
www.
6
7. Roles separation
Informix IDS considers 7 distinct roles
The DBSA (database system administrator)
is in charge of configuring, tuning and maintaining the IDS
instances. Tasks include startup and shutdown instances, disk
space management, performance tuning etc…
The DBSSO (database system security officer)
is in charge of defining audit masks on a large possible range of
audit targets
The AAO (audit analysis officer) configures, runs and analyzes
the audit trail
The DBA (database administrator) manages databases (not
necessarily instances)
the OSA (operating system administrator) handles user
accounts, groups, sets permissions, handles system resource
The user runs database applications
The privileged users « root » and « informix » are the default
privileged users defined by IDS
www.
7
8. Roles separation:
When and how?
The company can decide to use role separation or not
If not applied, the informix user has all the roles
At IDS install time, you must decide to use it or not
◦ You will be asked to enter the unix group names of DBSSO, AAO and
« regular » users.
To apply separation after installation, you must change
group ownsership of $INFORMIXDIR/dbssodir and
$INFORMIXDIR/aaodir
◦ You will rebounce the IDS instance to enable role separation
◦ You can switch back to no role separation by changing group ownership of
those directories back to informix, and rebounce again
Security rules can then be set in a more detailed manner by
editing the $INFORMIXDIR/dbssodir/seccfg file
www.
8
10. Configure IDS audit
The general configuration of audit is done in the
$INFORMIXDIR/aaodir/adtcfg file
ADTMODE 0 # Auditing mode
ADTPATH /usr/informix/aaodir # Directory where audit trails will be written by IDS
ADTSIZE 50000 # Maximum size of any single audit trail file
ADTERR 0 # Error handling modes.
audit dbsso and dbsa operations
Possible modes are
◦ 0 audit off
◦ 1 audit on
◦ 3 audit dbsso operations
◦ 5 audit dbsso and dbsa operations
◦ 7 audit dbsso, dbsa operations and normal user operations
Rebounce the instance to validate config, or use onaudit
command to set the configuration dynamically
www.
1
0
11. audit events
After general configuration is set, audit policy is configured by
specifying audit events
Audit events are instance and database operations identified by
an audit mnemonic like CRTB,CRIX,DLRW,RDRW ….
You can request specific status for each even: ‘S’ for sucessful, ‘F’
for failed
If ‘S’ or ‘F’ is not specified, all the events will be audited
Ex: SCRTB will audit only successful table creations
FDLRW will audit only failed rows deletes
CRVW will audit all the view creations
www.
1
1
12. audit events
CRLB Security Label, Create
ACTB Access Table CRLC Security Label Component, Create
ADCK Chunk, Add CROC Operator Class, Create
ADLG Transaction Log, Add
ALFR Alter Fragment CROP Optical Cluster, Create
ALIX Index, Alter CRPL Security Policy, Create
ALLC Security Label Component, Alter CRPT Encryption/Decryption
ALME Access Method, Alter CRRL Create Role
ALOC Operator Class, Alter
CRRT Named Row Type, Create
ALOP Optical Cluster, Alter
ALSQ Sequence, Alter CRSN Synonym, Create
ALTB Table, Alter CRSP SPL Routine, Create
BGTX Transaction, Begin CRSQ Sequence, Create
CLDB Database, Close CRTB Table, Create
CMTX Transaction, Commit
CRTR Trigger, Create
CRAG Aggregate, Create
CRAM Audit Mask, Create CRVW View, Create
CRBS Storage Space, Create DLRW Row, Delete
CRBT Opaque Type, Create DNCK Chunk, Bring Off-line
CRCT Cast, Create DNDM Disk Mirroring, Disable
CRDB Database, Create
DRAM Audit Mask, Delete
CRDM Domain, Create
CRDS Dbspace, Create DRBS Storage Space, Drop
CRDT Distinct Type, Create DRCK Chunk, Drop
CRIX Index, Create DRDB Database, Drop
www.
1
2
13. audit events
CRLB Security Label, Create
ACTB Access Table CRLC Security Label Component, Create
ADCK Chunk, Add CROC Operator Class, Create
ADLG Trnsaction Log, Add
ALFR Alter Fragment CROP Optical Cluster, Create
ALIX Index, Alter CRPL Security Policy, Create
ALLC Security Label Component, Alter CRPT Encryption/Decryption
ALME Access Method, Alter CRRL Create Role
ALOC Operator Class, Alter
CRRT Named Row Type, Create
ALOP Optical Cluster, Alter
ALSQ Sequence, Alter CRSN Synonym, Create
ALTB Table, Alter CRSP SPL Routine, Create
BGTX Transaction, Begin CRSQ Sequence, Create
CLDB Database, Close CRTB Table, Create
CMTX Transaction, Commit
CRTR Trigger, Create
CRAG Aggregate, Create
CRAM Audit Mask, Create CRVW View, Create
CRBS Storage Space, Create DLRW Row, Delete
CRBT Opaque Type, Create DNCK Chunk, Bring Off-line
CRCT Cast, Create DNDM Disk Mirroring, Disable
CRDB Database, Create
DRAM Audit Mask, Delete
CRDM Domain, Create
CRDS Dbspace, Create DRBS Storage Space, Drop
CRDT Distinct Type, Create DRCK Chunk, Drop
CRIX Index, Create DRDB Database, Drop
www.
1
3
14. audit events
RNIX Rename index
GRTB Grant Table Access RNLB Security Label, Rename
GRXM Grant Exemption RNLC Security Label Component, Rename
INRW Row, Insert
LGDB Database Log Mode, Change RNPL Security Policy, Rename
LKTB Table, Lock RNTC Table/ Column, Rename
LSAM Audit Masks, List RSOP Optical Cluster, Reserve
LSDB Databases, List RVDB Revoke Database Access
MDLG Modify Transaction Logging
RVDR Revoke Default Role
ONAU onaudit
ONBR onbar RVFR Revoke Fragment Access
ONCH oncheck RVLB Revoke Security Label
ONIN oninit RVRL Revoke Role
ONLG onlog RVSA Revoke DBSECADM
ONLO onload
RVSS Revoke SETSESSIONAUTH
ONMN onmonitor
ONMO onmode RVTB Revoke Table Access
ONPA onparams RVXM Revoke Exemption
ONPL onpload SCSP SPL Routine, System Command
ONSP onspaces STCO Collation®, Set
STCN Constraint, Set
STDF Set Debug File
STDP Set Database Password
STDS Set Dataskip
www.
1
4
15. audit masks
The audit masks contain a list of events mnemonics to
be audited
Events can be easily added or removed without
affecting the ongoing configuration
Events can be included or excluded from auditing
There are 5 types of masks
◦ Template masks are self explanatory. Their names must begin with
a ‘_’ character
◦ User masks will define an events list for a specific user. Their name
are made of the audited user ID. They are generally derivated from
template masks.
◦ The _ default mask contains the default list of events to be audited,
generally for all the users
◦ The _require mask contains the list of events that must be audited.
◦ The _exclude mask contains the list that must not be audited
◦ The order rule is: user masks, _default mask, _require mask and
finally _exclude mask.
The masks are created using the onaudit command
www.
1
5
16. The onaudit command
The onaudit command is multipurpose:
◦ To set up and configure auditing
Ex: onaudit -l 3
onaudit -s 10000000
◦ To manipulate/change audit masks
Ex: onaudit -a -u _user1 -e +CRTB,INRW
onaudit -a -u _user1 -e –CRTB
onaudit –f audit file
It is used only by the dbsso and the aao if roles are
separated, else it can also be user by the informix user
To stop auditing
onaudit -l 0
www.
1
6
17. The audit log file
The audit log files are generated in the directory
specified by the ADTPATH config parameter in the
$INFORMIXDIR/aaodir/adtcfg file
The log file names are built this way: <value of
onconfig DBSERVERNAME parameter>.sequence
number. Ex bcv_boc9 .1
The log file have a size limited by the adtcfg ADTSIZE
parameter. Once this size is reached, a new file is
created, with an incremented sequence number.
The audit trail can grow consequently according to
what events are audited. It is recommanded to put a
regular archiving procedure in place.
Compression can also be applied
www.
1
7
18. The audit log file format
The audit log file looks like this
www.
1
8
19. The audit log file output
First columns are self explanatory
The event specific colum is made of, and sepated by ‘:’
◦ Error code
◦ Event mnemonic
◦ Database name
◦ Event specific fields, can be user name,table name,rowid etc… ie all
relevant information used for auditing
This file is an ascii separated file, readable as is by any
tool that can read this type of file
Results can also be loaded into a database
Formatted / Structured output is provided by the
onshowaudit command
www.
1
9
20. The onshowaudit command
The onshowaudit command reads and formats the
audit trail files in a structured readable way, read-only
A number of options allow the aao to filter the records
by different criteria
Onshowaudit can also be used to generate a file to be
loaded to database for further SQL analysis
Some scripts are provided to do so
www.
2
0
21. Performance considerations
Activating the audit will never enhance the Informix
performance
It consists in Informix server threads that write system
files, not directly IFMX buffers and tables
Important questions are:
◦ What events are audited
◦ How many events are audited
◦ How is Informix performance before auditing
◦ How many transactions are effectively audited
To be considered:
◦ Some events will generate huge amount of data (row read etc..)
◦ Define an archiving procedure, that may also filter out unrelevant
data
www.
2
1
22. Appendix
We recommand the reading of these documentations
The IBM Informix Security guide, chapters
7,8,9,10,11,12 & 13, accessible on the Web
http://publib.boulder.ibm.com/infocenter/idshelp/v117/
index.jsp?topic=%2Fcom.ibm.sec.doc%2Fids_sec_019.
htm
The Security and Compliance Solutions for IBM
Informix Dynamic Server Redbook
http://www.redbooks.ibm.com/abstracts/sg247556.ht
ml
www.
2
2