IDS 11.7 – IDS Security Enhancements

© 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


Mapped Users


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


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).


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


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.


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.


Questions?


Mapped Users – Open Admin Tool (OAT)


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.


Mapped Users On the Mapped Users page, specify the privileges for all the mapped users on the database server.


To create a mapped user, click Add.

Mapped Users

Enter the information for the new mapped user:


Click Show SQL to review the SQL statement. Then click Add.

Mapped Users

You can also edit and delete mapped users.


Questions?


Selective Row Auditing


Recap – Auditing subsystem in IDS Row-level mnemonics Audit enabled tables

Agenda


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


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.


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.


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.


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.


Questions?


Trusted Context


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.


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.


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.


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.


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.


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.


Creating Trusted Context Objects


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.


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.


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.


Vormetric Encryption Expert

Now supports Raw devices.


Questions?


Scott Pickett – WW IDS Technical SalesFor questions about this presentation contact: [email protected]


Logo

IDS 11.7 – IDS Security Enhancements

Documents

Transcript of IDS 11.7 – IDS Security Enhancements