1. Cisco Data Virtualization
Preserving Data Source Security
April 2017

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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