Download Mapped Users

IDS 11.7 – IDS Security
Enhancements
Scott Pickett – WW Informix Technical Sales
For questions about this presentation contact: [email protected]
September 9, 2010
© 2011 IBM Corporation
Agenda





2
Mapped Users
Mapped Users - OAT
Selective Row Level Auditing
Trusted Context
Vormetric Encryption Expert
© 2010 IBM Corporation
Mapped Users
September 9, 2010
© 2011 IBM Corporation
Overview
 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.
4
© 2010 IBM Corporation
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:
–
–
5
Single sign-on (SSO) or
Pluggable authentication module (PAM).
© 2010 IBM Corporation
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
6
© 2010 IBM Corporation
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.
7
© 2010 IBM Corporation
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.
8
© 2010 IBM Corporation
Questions?
9
© 2010 IBM Corporation
Mapped Users – Open Admin Tool (OAT)
September 9, 2010
© 2011 IBM Corporation
Mapped Users
Grant database server privileges to externally
authenticated users by mapping them to operating
system user accounts.
On the OAT menu,
expand:
Server Administration >
User Privileges.
11
© 2010 IBM Corporation
Mapped Users
 On the Mapped Users page, specify the privileges for all the
mapped users on the database server.
12
© 2010 IBM Corporation
Mapped Users
To create a mapped user, click
Add.
 Enter
13
the information for the new mapped user:
© 2010 IBM Corporation
Mapped Users
 Click
Show SQL to review the SQL statement. Then click
Add.
 You can also edit and delete mapped users.
14
© 2010 IBM Corporation
Questions?
15
© 2010 IBM Corporation
Selective Row Auditing
September 9, 2010
© 2011 IBM Corporation
Agenda



17
Recap – Auditing subsystem in IDS
Row-level mnemonics
Audit enabled tables
© 2010 IBM Corporation
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
18
# Extracts audit records from
# the audit file specified in the
# adtcfg.servernumber file
# located at $ADTPATH
© 2010 IBM Corporation
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.
19
© 2010 IBM Corporation
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.
20
© 2010 IBM Corporation
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.
21
© 2010 IBM Corporation
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:
–
–
22
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 Corporation
Questions?
23
© 2010 IBM Corporation
Trusted Context
September 9, 2010
© 2011 IBM Corporation
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.
25
© 2010 IBM Corporation
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.
26
© 2010 IBM Corporation
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.
27
© 2010 IBM Corporation
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.
28
© 2010 IBM Corporation
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.
29
© 2010 IBM Corporation
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.
30
© 2010 IBM Corporation
Creating Trusted Context Objects
31
© 2010 IBM Corporation
Create Trusted Context

32
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 Corporation
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:
–
–
–
33
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 Corporation
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.
34
© 2010 IBM Corporation
Vormetric Encryption Expert
 Now supports Raw devices.
35
© 2010 IBM Corporation
Questions?
36
© 2010 IBM Corporation
Scott Pickett – WW IDS Technical Sales
For questions about this presentation contact: [email protected]
September 9, 2010
© 2011 IBM Corporation
Logo
38
© 2010 IBM Corporation
Logo
39
© 2010 IBM Corporation