diff --git a/database/baseline/vpd/vpd-livelab/vpd.md b/database/baseline/vpd/vpd-livelab/vpd.md index e83a7068..413c9f4e 100644 --- a/database/baseline/vpd/vpd-livelab/vpd.md +++ b/database/baseline/vpd/vpd-livelab/vpd.md @@ -3,11 +3,11 @@ ## Introduction Oracle Virtual Private Database enforces security, to a fine level of granularity, directly on database tables, views, or synonyms. Because you attach security policies directly to these database objects, and the policies are automatically applied whenever a user accesses data, there is no way to bypass security. -Description: This lab introduces the functionality of Oracle Virtual Private Database (VPD). It gives the user an opportunity to learn how to configure this feature to implement row and column level security. Oracle VPD creates security policies to control database access at the row and column level. +This lab introduces the functionality of Oracle Virtual Private Database (VPD). It gives the user an opportunity to learn how to configure this feature to implement row and column level security. Oracle VPD creates security policies to control database access at the row and column level. *Estimated Time:* 30 minutes -*Version tested in this lab:* Oracle DB 19.17 +*Version tested in this lab:* Oracle DB 19c ### Objectives - Understand how to create a PL/SQL function for use in a VPD policy @@ -23,9 +23,9 @@ This lab assumes you have: - Lab: Environment Setup - Lab: Initialize Environment -## Task 1: Download vpd.tar file to local directory. +## Task 1: Download vpd.tar file to local directory -1. Open a Terminal session on your **DBSec-Lab** VM as OS user *oracle* and use `cd` command to move to livelabs directory. +1. Open a Terminal session on your **DBSec-Lab** VM as OS user *oracle* and use `cd` command to move to livelabs directory. ```` cd livelabs @@ -33,34 +33,34 @@ This lab assumes you have: **Note**: If you are using a remote desktop session, double-click on the *Terminal* icon on the desktop to launch a session -2. Use the Linux command 'wget' to download a bundled (zipped) file of the commands for the lab. +2. Use the Linux command 'wget' to download a bundled (zipped) file of the commands for the lab. ```` - wget https://objectstorage.us-ashburn-1.oraclecloud.com/p/cSHhQf7m7ms3YRkyhSIfYtQw9qRcoOeBevb81RGUKsU19RhLMsLTjtUNRPoO4UaN/n/oradbclouducm/b/dbsec_rich/o/dbsec-livelabs-vpd.tar + wget https://objectstorage.us-ashburn-1.oraclecloud.com/p/Ca1HsovSmxaXDPvFRjf7CS9E-jGCl6U3rfaNlwePwWoD5Hi8vPcfeg1xs-_KAJp-/n/oradbclouducm/b/dbsec_rich/o/dbsec-livelabs-vpd.tar ```` -3. Unarchive the downloaded tar to expand the directory and scripts. +3. Unarchive the downloaded tar to expand the directory and scripts. ```` tar xvf dbsec-livelabs-vpd.tar ```` -4. Use `cd` command to move to vpd directory. - +4. Use `cd` command to move to vpd directory. + ```` cd vpd ```` -5. Use `ls` command to list files. - +5. Use `ls` command to list files. + ```` ls ```` ## Task 2: Create row function and policies -1. Initial query to show that there have not been VPD policies created yet. - +1. Initial query to show that there have not been VPD policies created yet. + ```` ./vpd_query_policies.sh ```` @@ -71,8 +71,8 @@ This lab assumes you have: no rows selected ```` -2. Initial query to demonstrate that `EMPLOYEESEARCH_PROD` and `DBA_DEBRA` can see employee-related data. Note the number of rows and the sensitive data returned in the columns. - +2. Initial query to demonstrate that `EMPLOYEESEARCH_PROD` and `DBA_DEBRA` can see employee-related data. Note the number of rows and the sensitive data returned in the columns. + ```` ./vpd_query_employee_data.sh ```` @@ -84,14 +84,14 @@ This lab assumes you have: ![Initial Query DBA_DEBRA](./images/vpd_initialquerydebra.png " ") -3. VPD relies on PL/SQL functions for business logic. Create a function that applies a `1=0` predicate (where clause) to the query if the session user is not the application owner, `EMPLOYEESEARCH_PROD` - +3. VPD relies on PL/SQL functions for business logic. Create a function that applies a `1=0` predicate (where clause) to the query if the session user is not the application owner, `EMPLOYEESEARCH_PROD` + ```` ./vpd_create_row_function.sh ```` -4. Apply a VPD policy to the `EMPLOYEESEARCH_PROD.DEMO_HR_EMPLOYEES` table that will call the PL/SQL function and restrict rows for `SELECT` queries. - +4. Apply a VPD policy to the `EMPLOYEESEARCH_PROD.DEMO_HR_EMPLOYEES` table that will call the PL/SQL function and restrict rows for `SELECT` queries. + ```` ./vpd_create_row_policy.sh ```` @@ -99,41 +99,43 @@ This lab assumes you have: ![Create Row Policy](./images/vpd_createrowpolicy.png " ") -5. Re-run the query to view employee data. With the VPD row policy applies, `EMPLOYEESEARCH_PROD` will still see all rows but `DBA_DEBRA` will no longer be able to see employee data. - +5. Re-run the query to view employee data. With the VPD row policy applies, `EMPLOYEESEARCH_PROD` will still see all rows but `DBA_DEBRA` will no longer be able to see employee data. + ```` ./vpd_query_employee_data.sh ```` **Output for `EMPLOYEESEARCH_PROD`:** ![Row Policy Query](./images/vpd_rerunquery.png " ") - + **Output for `DBA_DEBRA`:** ![Row Policy Query DBA_DEBRA](./images/vpd_rerunquerydebra.png " ") -6. Now that you understand how to use VPD to limit the number of rows returned, we will drop the row policy and move on to protecting column values. - +6. Now that you understand how to use VPD to limit the number of rows returned, we will drop the row policy and move on to protecting column values. + ```` ./vpd_drop_row_policy.sh ```` -## Task 3: Create column function and policies. -1. Similar to the row function, the PL/SQL function will limit the number of rows returned for users who are not the application schema owner, `EMPLOYEESEARCH_PROD`. In addition, the the application user, the function will also verify the `CLIENT_IDENTIFIER` value is set in the user's session context. - + +## Task 3: Create column function and policies + +1. Similar to the row function, the PL/SQL function will limit the number of rows returned for users who are not the application schema owner, `EMPLOYEESEARCH_PROD`. In addition, the application user, the function will also verify the `CLIENT_IDENTIFIER` value is set in the user's session context. + ```` ./vpd_create_col_function.sh ```` -2. Create the VPD policy using the PL/SQL column function. This policy will apply to the `SSN`, `SIN`, and `NINO` columns. - +2. Create the VPD policy using the PL/SQL column function. This policy will apply to the `SSN`, `SIN`, and `NINO` columns. + ```` ./vpd_create_col_policy.sh ```` **Output:** - + ![Column Policy](./images/vpd_createvpdpolicy.png " ") -3. When `EMPLOYEESEARCH_PROD` queries data, 9 rows will be returned but the values for the sensitive columns will not. This is because the VPD policy function will not return the values of these columns until the session user and `CLIENT_IDENTIFIER` session context are both met. - +3. When `EMPLOYEESEARCH_PROD` queries data, 9 rows will be returned but the values for the sensitive columns will not. This is because the VPD policy function will not return the values of these columns until the session user and `CLIENT_IDENTIFIER` session context are both met. + ```` ./vpd_query_employee_data.sh ```` @@ -144,84 +146,84 @@ This lab assumes you have: ![Column Policy Query DBA_DEBRA](./images/vpd_columnpolicyquerydebra.png " ") -4. To demonstrate the results when both session user and `CLIENT_IDENTIFIER` are met, append `hradmin` to the previous query. Sensitive column values will be displayed. However, `DBA_DEBRA` will never see this data because she is not authorized by the PL/SQL function. - +4. To demonstrate the results when both session user and `CLIENT_IDENTIFIER` are met, append `hradmin` to the previous query. Sensitive column values will be displayed. However, `DBA_DEBRA` will never see this data because she is not authorized by the PL/SQL function. + ```` ./vpd_query_employee_data.sh hradmin ```` **Output for `EMPLOYEESEARCH_PROD`:** ![Client Identifier Query](./images/vpd_clientidentifierquery.png " ") - + **Output for `DBA_DEBRA`:** - + ![Client Identifier Query DBA_DEBRA](./images/vpd_clientidentifierquerydebra.png " ") -5. Altering the query from `hradmin` to `can_candy` will not display any of the sensitive columns because our PL/SQL function does not recognize `can_candy` as a `CLIENT_IDENTIFIER` yet. - +5. Altering the query from `hradmin` to `can_candy` will not display any of the sensitive columns because our PL/SQL function does not recognize `can_candy` as a `CLIENT_IDENTIFIER` yet. + ```` ./vpd_query_employee_data.sh can_candy ```` **Output for `EMPLOYEESEARCH_PROD`:** - + ![Can_Candy Identifier Query](./images/vpd_can_candyidentifierquery.png " ") - + **Output for `DBA_DEBRA`:** - + ![Can_Candy Identifier Query DBA_DEBRA](./images/vpd_can_candyidentifierquerydebra.png " ") -6. Update the PL/SQL function to include an `elsif` to allow `can_candy` to see the sensitive columns for Toronto-based employees. - +6. Update the PL/SQL function to include an `elsif` to allow `can_candy` to see the sensitive columns for Toronto-based employees. + ```` ./vpd_update_col_function.sh ```` -7. Demonstrate that `hradmin` sees 9 rows and sensitive columns but `DBA_DEBRA` does not. - +7. Demonstrate that `hradmin` sees 9 rows and sensitive columns but `DBA_DEBRA` does not. + ```` ./vpd_query_employee_data.sh hradmin ```` **Output for `EMPLOYEESEARCH_PROD`:** - + ![Hradmin Identifier Query](./images/vpd_hradminidentifierquery.png " ") - + **Output for `DBA_DEBRA`:** - + ![Hradmin Identifier Query DBA_DEBRA](./images/vpd_hradminidentifierquerydebra.png " ") -8. Demonstrate that `can_candy` will see 9 rows and only the sensitive columns for Toronto-based employees. `DBA_DEBRA` will still not see any sensitive columns. - +8. Demonstrate that `can_candy` will see 9 rows and only the sensitive columns for Toronto-based employees. `DBA_DEBRA` will still not see any sensitive columns. + ```` ./vpd_query_employee_data.sh can_candy ```` **Output for `EMPLOYEESEARCH_PROD`:** - + ![Updated Can_Candy Query](./images/vpd_updatedcan_candyquery.png " ") - + **Output for `DBA_DEBRA`:** - + ![Updated Can_Candy Query DBA_DEBRA](./images/vpd_updatedcan_candyquerydebra.png " ") -## Task 4: Clean up. +## Task 4: Clean up + +1. Remove the PL/SQL functions and drop the VPD-related policies. -1. Remove the PL/SQL functions and drop the VPD-related policies. - ```` ./vpd_cleanup.sh ```` -2. Verify both `EMPLOYESEARCH_PROD` and `DBA_DEBRA` have full access to rows and columns without the VPD policies in place. - +2. Verify both `EMPLOYEESEARCH_PROD` and `DBA_DEBRA` have full access to rows and columns without the VPD policies in place. + ```` ./vpd_query_employee_data.sh ```` **Output for `EMPLOYEESEARCH_PROD`:** - + ![Cleanup Query](./images/vpd_cleanupquery.png " ") - + **Output for `DBA_DEBRA`:** - - ![Cleanup Query DBA_DEBRA](./images/vpd_cleanupquerydebra.png " ") + + ![Cleanup Query DBA_DEBRA](./images/vpd_cleanupquerydebra.png " ") ## Learn More Technical Documentation: @@ -229,5 +231,5 @@ Technical Documentation: ## Acknowledgements - **Author** - Stephen Stuart & Noah Galloso, Solution Engineers, North America Specialist Hub -- **Contributors** - Richard C. Evans, Database Security Product Manager -- **Last Updated By/Date** - Stephen Stuart & Noah Galloso, August 2023 +- **Contributors** - Richard C. Evans, Database Security Product Manager +- **Last Updated By/Date** - Richard C. Evans, March 2026