Cisco Data Virtualization Preserving Data Source Security April 2017

Introduction The Cisco Information Server can apply row-level security, granular privileges on resources, and much more We all know how to apply the basics of security configuration within the Cisco Information Server Apply privileges on objects Apply row-level security Etc… Two common questions: How do we leverage data-source-specific security setup? How do we properly manage CIS-level privileges in multiple environments?

Problem: Leverage Source Security We have security configured in our various data sources RLS, object security, VPD, query banding, etc. We must ensure that security is applied on each connection to the data sources Cannot use stored credentials for data source access We don't want to, or cannot, rebuild all the security setup again within the CIS Information Security requirement, insurmountable cost, etc.

Solution 1: Connection Check-out Procedure What is a Connection Check-out Procedure A simple procedure to build / return SQL statements to set any context within a physical data source The CIS runs this procedure to gather the SQL, then executes data- source-specific SQL code to initialize the connection Executed each time a connection is activated from the connection pool Can be used to: Set a query band for Teradata Set session level context for Oracle VPD -Etc.

Solution 1: Connection Check-out Procedure Create the procedure Must consist of only two parameters: IN ds_name VARCHAR, OUT sqlText VARCHAR) sqlText must contain commands in data-source-specific syntax to be executed immediately upon activation of the connection

Solution 1: Connection Check-out Procedure SIDE NOTE: This approach can be used to perform many functions, not just set security context Set Teradata Query Band: PROCEDURE teradataInit(IN ds_name VARCHAR, OUT sqlText VARCHAR) BEGIN DECLARE username VARCHAR; DECLARE sessionId VARCHAR; CALL /lib/util/GetProperty('CURRENT_USER_NAME', username); CALL /lib/util/GetProperty('SESSION_ID', sessionId); SET sqlText = 'SET QUERY_BAND = ''ClientUser=' || username || '; Importance=Standard; JobID=' || sessionId || ';'' FOR SESSION;'; END

Solution 1: Connection Check-out Procedure SIDE NOTE: This approach can be used to perform many functions, not just set security context Disable Oracle Optimizer Feedback: PROCEDURE teradataInit(IN ds_name VARCHAR, OUT sqlText VARCHAR) BEGIN SET sqltxt = 'alter session set "_optimizer_use_feedback" = false'; END

Solution 1: Connection Check-out Procedure Configure "Connection Check- out Procedure" as the path to the procedure in the namespace Consider disabling connection pooling if the code cannot be re-executed for a connection sitting in a connection pool Set Connection Pool Minimum Size to 0 Set Connection Pool Idle Timeout to 1

Solution 1: Connection Check-out Procedure All executions against the data source now execute the connection check-out procedure BEFORE issuing any queries

Solution 2: Pass-Through Authentication Configure data source access using Pass-Through Authentication Configure the data source stored credentials Also set "Pass-through Login" property to ENABLED

Solution 2: Pass-Through Authentication Any queries executed against this data source by members of the composite\admin group use stored credentials Similar to Oracle VPD: admin users can see everything Use CIS row-level security to restrict data access, if required Any queries executed against this data source by members of other groups will use their username and password for authentication Allows the data source to enforce security for the given user Only schemas, tables, rows, columns, etc. this user may access will be available, regardless of introspection or CIS rights / privileges All users must also have applicable privileges on the CIS resources to execute queries

Solution 2: Pass-Through Authentication Query executed by the admin user use the stored credentials of the 'system' user

Solution 2: Pass-Through Authentication Query executed by the admin user use the stored credentials of the 'system' user

Solution 2: Pass-Through Authentication Query executed by the victoria user passes Victoria's credentials when logging into the physical database

Solution 2: Pass-Through Authentication Query executed by the victoria user passes Victoria's credentials when logging into the physical database

Solution 2: Pass-Through Authentication Query executed by the victoria user passes Victoria's credentials when logging into the physical database

Solution 2: Pass-Through Authentication Query executed by the michael user passes Michael's credentials when logging into the physical database

Solution 2: Pass-Through Authentication Query executed by the michael user passes Michael's credentials when logging into the physical database

Solution 2: Pass-Through Authentication NOTE: Functions with accounts in the Composite or LDAP domains Composite domain: username and password must be identical in CIS and the source LDAP domain: additional setup required in the physical data source

Problem: Managing Privileges How can we properly manage privileges in our CIS environments? NOTE: We assume that privileges are managed at the group level per security best practices, but also include references to user privileges

Solution 1: Script and Set Maintain a spreadsheet of: Resource path, resource type, domain name, group name, matrix of privilege settings, etc. One spreadsheet needed per CIS environment Create a script to read the spreadsheet and apply privileges in the CIS using the Admin API

Solution 1: Script and Set Pros: Guaranteed only the privileges in the spreadsheet are set in the environment where the spreadsheet lives Privileges can be applied regularly to overwrite any settings that were tampered with Cons: Spreadsheets require maintenance, security to ensure they are complete and accurate Spreadsheets can become unweildly to maintain with large numbers of users, groups, resources, etc. Requires custom scripts that interact with the Admin API

Solution 2: Set and Migrate Create groups for all environments (i.e. DEV, UAT, PROD) in your CIS DEV environment Exclude user accounts for UAT and PROD to avoid disallowed logins Set appropriate privileges for all groups in the DEV environment

Solution 2: Set and Migrate When migrating resources, privileges will also be migrated if: CAR Files: ensure "Privileges" is checked pkg_export: ensure flag is set -includeaccess

Solution 2: Set and Migrate When migrating resources, privileges will also be migrated if: DM: Ensure a Principal Bundle is created that contains the UAT / PROD groups as appropriate for the target site Set the Principal Bundle Filter on the Deployment Plan

Solution 2: Set and Migrate Pros: Privileges can be managed in one CIS environment Privileges can be migrated without requiring maintenance of mappings or other scripts / external components Cons: All groups for all environments must be configured in the CIS DEV environment, which could allow user access Privilege modifications manually set in other environments will be lost during next migration

Solution 2: Set and Migrate But wait! I have different domain names configured in DEV / UAT / PROD I have the same domain name but different group names configured in DEV / UAT / PROD Solution 2 won't work for me, will it?

Solution 3: Set, Map, and Migrate Solution 2 with a twist Create Composite domain groups for each of your UAT / PROD groups in different domains Eg: DEV UAT PROD composite/ corp_dev/ corp/ developers users admins corp_dev-developers developers corp_dev-users users corp_dev-admins admins corp-cis_developers cis_developers corp-cis_users cis_users corp-cis_admins cis_admins

Solution 3: Set, Map, and Migrate Solution 2 with a twist In DM, create principal mappings from the created DEV groups to the UAT / PROD groups

Solution 3: Set, Map, and Migrate When migrating resources, privileges will also be migrated, and mapped to the proper environment groups, if: DM: Ensure a Principal Bundle is created that contains the UAT / PROD groups as appropriate for the target site Set the Principal Bundle Filter on the Deployment Plan

Conclusion If you have invested time and money into your data source security setup, don't stress! The Cisco Information Server can leverage this investment Can leverage existing data source privileges Can leverage query banding, VPD, other auditing / security requirements Managing privilege assignments can be challenging Can be set with scripts Can be migrated forward Cisco is your partner Reach out for more information or assistance with implementation