IDS 11.7 – IDS Security Enhancements

1. Scott Pickett – WW Informix Technical Sales For questions about this presentation contact: spickett@us.ibm.com IDS 11.7 – IDS Security Enhancements

2. Agenda • Mapped Users • Mapped Users - OAT • Selective Row Level Auditing • Trusted Context • Vormetric Encryption Expert

3. Mapped Users

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

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

6. Granting IDS Access to Mapped Users • GRANT ACCESS TOstatement: • 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

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

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

9. Questions?

10. Mapped Users – Open Admin Tool (OAT)

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

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

13. Mapped Users • To create a mapped user, click Add. • Enter the information for the new mapped user:

14. Mapped Users • Click Show SQL to review the SQL statement. Then click Add. • You can also edit and delete mapped users.

15. Questions?

16. Selective Row Auditing

17. Agenda • Recap – Auditing subsystem in IDS • Row-level mnemonics • Audit enabled tables

18. 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.servernumberfile # located at $ADTPATH

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

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

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

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

23. Questions?

24. Trusted Context

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

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

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

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

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

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

31. Creating Trusted Context Objects

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

33. Creating Trusted Connections • APISupport inESQL/C, JDBC and ODBC • ESQL/CExample: • 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.

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

35. Vormetric Encryption Expert • Now supports Raw devices.

36. Questions?

37. Scott Pickett – WW IDS Technical Sales For questions about this presentation contact: spickett@us.ibm.com

38. Logo

39. Logo