© 2011 ibm corporation september 9, 2010 ids 11.7 – ids security enhancements scott pickett –...
TRANSCRIPT
© 2011 IBM CorporationSeptember 9, 2010
IDS 11.7 – IDS Security Enhancements
Scott Pickett – WW Informix Technical SalesFor questions about this presentation contact: [email protected]
© 2010 IBM Corporation2
Agenda
Mapped Users Mapped Users - OAT Selective Row Level Auditing Trusted Context Vormetric Encryption Expert
© 2011 IBM CorporationSeptember 9, 2010
Mapped Users
© 2010 IBM Corporation4
As a user without Host Operating System Accounts, I should be able to connect to IDS.
As a DBSA, I should be able to grant Dynamic Server
access to externally authenticated users by mapping them to the appropriate user and group privileges, regardless of whether these users have operating system accounts on the Dynamic Server host computer.
Overview
© 2010 IBM Corporation5
Enabling Mapped Users
When a DBSA turns on the USERMAPPING parameter of the onconfig file.
New onconfig parameter: – USERMAPPING OFF|ADMIN|BASIC
• OFF is the default.• ADMIN can grant administrative privileges to mapped users.• BASIC is what it says, basic access.
DBSA should verify that users mapped to surrogate user properties for Informix access can externally authenticate with:
– Single sign-on (SSO) or– Pluggable authentication module (PAM).
© 2010 IBM Corporation6
Granting IDS Access to Mapped Users
GRANT ACCESS TO statement:– Use the GRANT statement with the ACCESS TO clause to
map users to user properties required for access to IDS resources.
User mapping tables:– The following system catalog tables in the SYSUSER
database map users to OS-level properties that enable IDS access and control level of privileges:
– sysusermap– syssurrogates – syssurrogategroups
Open Admin Tool:– Server Administration User Privileges -> Mapped Users
© 2010 IBM Corporation7
Examples
GRANT ACCESS TO bob PROPERTIES USER fred;– This means that when 'bob' connects to IDS, as far as the
operating system access is concerned, IDS will use the UID, GID(s) and home directory for user 'fred' (which must be a user name known to the O/S).
GRANT ACCESS TO bob PROPERTIES UID 101, GROUP 10011;
– This means that 'bob' will use the anonymous UID 101 and the anonymous group 10011 when an O/S identity is required.
© 2010 IBM Corporation8
Examples
GRANT ACCESS TO PUBLIC PROPERTIES USER dbuser;
– Anyone who can authenticate but does not have an explicit entry designating the mapped (surrogate) user will use the identity of dbuser.
REVOKE ACCESS FROM bob;
– This means that 'bob' no longer has access to the machine via user mapping unless user PUBLIC is given mapped access, in which case 'bob' now uses the same privileges that PUBLIC uses.
– Alternatively, 'bob' may have been created as an O/S user, in which case those privileges override anything set in sysusermap and syssurrogates.
© 2010 IBM Corporation9
Questions?
© 2011 IBM CorporationSeptember 9, 2010
Mapped Users – Open Admin Tool (OAT)
© 2010 IBM Corporation11
Mapped UsersGrant database server privileges to externally authenticated users by mapping them to operating system user accounts.
On the OAT menu, expand:
Server Administration > User Privileges.
© 2010 IBM Corporation12
Mapped Users On the Mapped Users page, specify the privileges for all the mapped users on the database server.
© 2010 IBM Corporation13
To create a mapped user, click Add.
Mapped Users
Enter the information for the new mapped user:
© 2010 IBM Corporation14
Click Show SQL to review the SQL statement. Then click Add.
Mapped Users
You can also edit and delete mapped users.
© 2010 IBM Corporation15
Questions?
© 2011 IBM CorporationSeptember 9, 2010
Selective Row Auditing
© 2010 IBM Corporation17
Recap – Auditing subsystem in IDS Row-level mnemonics Audit enabled tables
Agenda
© 2010 IBM Corporation18
Recap – Auditing Subsystem in IDS Onaudit
– Manages audit masks and configuration.– Need to be DBSSO or AAO.– DBSSO can perform functions related to audit setup.– AAO can perform functions related to audit analysis.
• Examples:– onaudit –l 1 # audit all sessions, sets
# $ADTERR = 1– onaudit –c # show all values of $ADTCFG– onaudit –a –u sqlqa –e +RDRW # adds a new audit mask
# for user sqlqa and
# excludes read row events.
Onshowaudit – Lets AAO extract audit trail information:– onshowaudit –n <servernumber # Extracts audit records from
# the audit file specified in the # adtcfg.servernumber file
# located at $ADTPATH
© 2010 IBM Corporation19
New Row-Level Mnemonics (1)
UPRW – Update Row DLRW – Delete Row RDRW – Select Row INRW – Insert Row
These are masks created by the onaudit utility, as part of the Secure Auditing Facility.
Row level auditing is started in any of the following ways:
– ADTROWS is on by default ( 0 ) in the audit configuration file as defined by the environment variable $ADTCFG. Row level auditing is on by default, if auditing is set up.
– onaudit –R 0 This will set row level auditing on for all tables and ADTROWS to 0
– onaudit –R 1 This will set the audit configuration file parameter ADTROWS to 1, and turn
on row level auditing for tables set with the AUDIT flag.– onaudit –R 2
This turns on selective row level auditing and includes the primary key in the audit output if the primary key is an integer and ADTROWS to 2.
© 2010 IBM Corporation20
New Row-Level Mnemonics (2)
To audit row level updates:– onaudit –a –u sippl –e UPRW
To audit row level selects:– onaudit –a –u sippl –e RDRW
To audit row level inserts:– onaudit –a –u sippl –e INRW
To audit row level deletes:– onaudit –a –u sippl –e DLRW
It is anticipated that row level auditing will require lots of operating system file space for the audit file data.– The file system that ADTPATH in $ADTCFG is on should have lots of
space and is secure. – Revisit ADTSIZE in $ADTCFG to adjust the audit output file size, if need
be.
Auditing is expensive in terms of performance:– The degree of this depends on how much you are auditing.
© 2010 IBM Corporation21
Problem
Most of the time, you do not need row-level audit information for ALL tables as some tables are just used for reference. Enabling these mnemonics produces huge amounts of useless data.
The information in the current row-level audit records contains table_id and row_id and these can change over time. So looking back at audit records can be meaningless.
© 2010 IBM Corporation22
Solution Added a new table level property, “AUDIT”:
– CREATE TABLE {existing syntax} | with AUDIT;– ALTER TABLE {existing syntax} | add AUDIT;
| drop AUDIT;
– You will need resource or DBA privileges to run either of these with/add/drop AUDIT.
Added a new parameter, ADTROWS to adtcfg file:
– 0: NO changes in existing row level auditing behavior (default)– 1: SRLA is enabled and only "audit" enabled tables will
generate row-level audit records.
© 2010 IBM Corporation23
Questions?
© 2011 IBM CorporationSeptember 9, 2010
Trusted Context
© 2010 IBM Corporation25
Trusted Context – Why have it?
Trusted Context is a feature developed by DB2.
Connection reuse is allowed with a different userid with authentication:
– Avoid the overhead of establishing a new connection.
– Accommodate application servers needing to connect on behalf of an end-user but lack access to that end-user’s password to establish a new connection on their behalf.
Allow users to gain additional privileges when their connection satisfies certain database server defined conditions.
© 2010 IBM Corporation26
Current State without Trusted Context (1) Loss of user identity:
– Some enterprises need to know the identity of the actual user accessing the database for access control purposes.
Diminished user accountability:
– Accountability through auditing is a basic principle in database security.
– Not knowing the user’s identity makes it difficult to distinguish the transactions performed by the middle tier for its own purpose from those performed by the middle tier on behalf of some user.
© 2010 IBM Corporation27
Current State without Trusted Context (2)
Over granting of privileges to the middle tier’s userid:
– The middle tier’s userid must have all the privileges needed to execute all the requests from all the users.
– This has the security issue of enabling users who do not need access to certain information to obtain access to them.
Weakened security:
– The current approach requires that the userid used by the middle tier to connect must be granted privileges on all resources that might be accessed by user requests.
– If that middle-tier userid is ever compromised, then all those resources will be exposed.
© 2010 IBM Corporation28
Trusted Context Features
Typically an application server has to connect to the database server as the “application user”.
This gives the application all the privileges associated with that user – usually everything.
Control the machine(s) a trusted connection can be established from.
With trusted context, application users can access the database with their own level of privilege.
Discretionary Access Control (DAC) applies to the current userid.
Audit records apply to the current user. Different levels of privilege (roles) can be given to
different users.
© 2010 IBM Corporation29
What is a Trusted Context?
A Trusted Context is a database object created by the database security administrator (DBSECADM) that defines a set of properties for a connection that when met, allow that connection to be a “trusted connection” with special properties.
The connection must be established by a specific user. The connection must come from a trusted client machine. The connection connecting port must have required
encryption. If these criteria are met, the connection will allow changes in
userid and privileges as defined in the trusted context.
© 2010 IBM Corporation30
Typical Usage Scenario
Step 1: Create Trusted Context Objects:
– Created at database level.
– Must be created by DBSECADM before Trusted Connections can be established.
– Can use O/S users or Mapped Users.
Step 2: Establish Trusted Connections:
– Must satisfy criteria defined in Trusted Context.
– Provision to Switch User.
– Use transactions within switched user session.
© 2010 IBM Corporation31
Creating Trusted Context Objects
© 2010 IBM Corporation32
Create Trusted Context
CREATE TRUSTED CONTEXT CTX1
BASED UPON CONNECTION USING SYSTEM AUTHID BOB
DEFAULT ROLE MANAGER
ENABLE
ATTRIBUTES (ADDRESS '9.26.113.204')
WITH USE FOR JOE, MARY WITHOUT AUTHENTICATION
Creates an Trusted Context object named CTX1
Will allow connections from 9.26.113.204
Can switch to user Joe or Mary once Trusted Connection established.
© 2010 IBM Corporation33
Creating Trusted Connections
API Support in ESQL/C, JDBC and ODBC
ESQL/C Example:
– EXEC SQL CONNECT TO "dbname@online1" TRUSTED A trusted connection is possible only when the application
specifically invokes an API designed to make such a connection (known as an explicit connection).
The connection request attributes must match those of a trusted context defined on the DBMS as follows:
– System authorization ID: Represents the user that establishes a database connection.
– IP address (or domain name): Represents the host from which a database connection is established.
– Data stream encryption: Represents the encryption setting (if any) for the data communication between the database server and the database client.
© 2010 IBM Corporation34
Switching Users
Switch to any user defined in the Trusted Context Object scope.
Perform database operations.
Audit records will show the switched user as the originator of the operations.
If using transactions, commit or rollback before switching to a new user.
© 2010 IBM Corporation35
Vormetric Encryption Expert
Now supports Raw devices.
© 2010 IBM Corporation36
Questions?
© 2011 IBM CorporationSeptember 9, 2010
Scott Pickett – WW IDS Technical SalesFor questions about this presentation contact: [email protected]
© 2010 IBM Corporation38
Logo
© 2010 IBM Corporation39
Logo