• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ibm informix security functionality overview
 

Ibm informix security functionality overview

on

  • 491 views

This presentation is an introduction to security handled by IBM Informix

This presentation is an introduction to security handled by IBM Informix

Statistics

Views

Total Views
491
Views on SlideShare
491
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Ibm informix security functionality overview Ibm informix security functionality overview Presentation Transcript

    • IBM InformixSecurity functional overview Luxembourg, October 2012 Eric Vercelletto, Begooden-IT Consulting www.
    • Agenda Informix security: OS perspective (overview) Informix security: database perspective (overview) Roles: configuration et separation (detail) Administration/Roles (detail) Auditing (detail) Performance considerations (overview) www. 2
    • 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
    • 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
    • Sql security/1Informix can secure data thru SQL commands in 2ways 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
    • Sql security/2Informix 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
    • Roles separationInformix 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
    • 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
    • IDS Audit www. 9
    • Configure IDS audit The general configuration of audit is done in the $INFORMIXDIR/aaodir/adtcfg fileADTMODE 0 # Auditing modeADTPATH /usr/informix/aaodir # Directory where audit trails will be written by IDSADTSIZE 50000 # Maximum size of any single audit trail fileADTERR 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
    • 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
    • audit events CRLB Security Label, CreateACTB Access Table CRLC Security Label Component, CreateADCK Chunk, Add CROC Operator Class, CreateADLG Transaction Log, AddALFR Alter Fragment CROP Optical Cluster, CreateALIX Index, Alter CRPL Security Policy, CreateALLC Security Label Component, Alter CRPT Encryption/DecryptionALME Access Method, Alter CRRL Create RoleALOC Operator Class, Alter CRRT Named Row Type, CreateALOP Optical Cluster, AlterALSQ Sequence, Alter CRSN Synonym, CreateALTB Table, Alter CRSP SPL Routine, CreateBGTX Transaction, Begin CRSQ Sequence, CreateCLDB Database, Close CRTB Table, CreateCMTX Transaction, Commit CRTR Trigger, CreateCRAG Aggregate, CreateCRAM Audit Mask, Create CRVW View, CreateCRBS Storage Space, Create DLRW Row, DeleteCRBT Opaque Type, Create DNCK Chunk, Bring Off-lineCRCT Cast, Create DNDM Disk Mirroring, DisableCRDB Database, Create DRAM Audit Mask, DeleteCRDM Domain, CreateCRDS Dbspace, Create DRBS Storage Space, DropCRDT Distinct Type, Create DRCK Chunk, DropCRIX Index, Create DRDB Database, Drop www. 1 2
    • audit events CRLB Security Label, CreateACTB Access Table CRLC Security Label Component, CreateADCK Chunk, Add CROC Operator Class, CreateADLG Trnsaction Log, AddALFR Alter Fragment CROP Optical Cluster, CreateALIX Index, Alter CRPL Security Policy, CreateALLC Security Label Component, Alter CRPT Encryption/DecryptionALME Access Method, Alter CRRL Create RoleALOC Operator Class, Alter CRRT Named Row Type, CreateALOP Optical Cluster, AlterALSQ Sequence, Alter CRSN Synonym, CreateALTB Table, Alter CRSP SPL Routine, CreateBGTX Transaction, Begin CRSQ Sequence, CreateCLDB Database, Close CRTB Table, CreateCMTX Transaction, Commit CRTR Trigger, CreateCRAG Aggregate, CreateCRAM Audit Mask, Create CRVW View, CreateCRBS Storage Space, Create DLRW Row, DeleteCRBT Opaque Type, Create DNCK Chunk, Bring Off-lineCRCT Cast, Create DNDM Disk Mirroring, DisableCRDB Database, Create DRAM Audit Mask, DeleteCRDM Domain, CreateCRDS Dbspace, Create DRBS Storage Space, DropCRDT Distinct Type, Create DRCK Chunk, DropCRIX Index, Create DRDB Database, Drop www. 1 3
    • audit events RNIX Rename indexGRTB Grant Table Access RNLB Security Label, RenameGRXM Grant Exemption RNLC Security Label Component, RenameINRW Row, InsertLGDB Database Log Mode, Change RNPL Security Policy, RenameLKTB Table, Lock RNTC Table/ Column, RenameLSAM Audit Masks, List RSOP Optical Cluster, ReserveLSDB Databases, List RVDB Revoke Database AccessMDLG Modify Transaction Logging RVDR Revoke Default RoleONAU onauditONBR onbar RVFR Revoke Fragment AccessONCH oncheck RVLB Revoke Security LabelONIN oninit RVRL Revoke RoleONLG onlog RVSA Revoke DBSECADMONLO onload RVSS Revoke SETSESSIONAUTHONMN onmonitorONMO onmode RVTB Revoke Table AccessONPA onparams RVXM Revoke ExemptionONPL onpload SCSP SPL Routine, System CommandONSP onspaces STCO Collation®, Set STCN Constraint, Set STDF Set Debug File STDP Set Database Password STDS Set Dataskip www. 1 4
    • 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
    • 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
    • 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
    • The audit log file format The audit log file looks like this www. 1 8
    • 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
    • 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
    • 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
    • AppendixWe 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