jean_oper_dba@aos>-- no we can grant the DBV realm owner role to the jean_oper_dba@aos>-- application-centric database administrator role jean_oper_dba@aos>GRANT dv_realm_owner TO sh_dba
Trang 1jean_oper_dba@aos>GRANT CREATE SESSION TO sh;
Grant succeeded
jean_oper_dba@aos> connect as our object-owner
jean_oper_dba@aos> account and create or application's objects jean_oper_dba@aos>CONNECT sh
Enter password:
Connected
sh@aos> install our application objects
sh@aos> @install_sales_history_objects.sql
Table created
Table created
Sequence created
View created
…
sh@aos> now protect the application's objects in a DBV realm sh@aos>CONNECT dbvowner
Enter password:
dbvowner@aos>BEGIN
dbms_macadm.create_realm(
realm_name => 'Sales History'
, description =>
'Annual, quarterly, monthly, and weekly sales figures by product' , enabled => DBMS_MACUTL.G_YES
, audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL
);
END;
/
PL/SQL procedure successfully completed
BEGIN
dbms_macadm.add_object_to_realm<A> (
realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => '%'
,object_type => '%'
);
END;
/
PL/SQL procedure successfully completed
we typically authorize the object-owner account in the realm if application code performs DDL activity on the realm
BEGIN
dbms_macadm.add_auth_to_realm(
realm_name =>'Sales History'
, grantee => 'SH'
, rule_set_name => NULL
, auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER );
END;
/
PL/SQL procedure successfully completed
Trang 2Create (Realm-based) Application Database Administrators
We mentioned earlier that DBV comes with a predefined role named DV_REALM_OWNER that works nicely with the application database administrator concept We do not want to grant the DV_REALM_OWNER role directly to the accounts and then authorize the accounts in the realm,
as this yields higher maintenance costs on the DBV policy side for account provisioning We also
do not want to authorize the DV_REALM_OWNER role in each realm as this would provide access to all realms for anyone that has been granted this role The solution is to define an application-centric role name for this administrator for each realm and simply grant this DV_ REALM_OWNER role to the application-centric role We demonstrate with an example for the Sales History realm:
jean_oper_dba@aos> login as our new
jean_oper_dba@aos> Operational DBA for audit attribution
jean_oper_dba@aos>CREATE ROLE sh_dba_role_0101;
Role created
jean_oper_dba@aos> revoke the role from the account
jean_oper_dba@aos> that created it or our privilege
jean_oper_dba@aos> escalation realm authorization
jean_oper_dba@aos> will fail The Oracle Database
jean_oper_dba@aos> performs an implicit and hidden
jean_oper_dba@aos> GRANT of the role to the account
jean_oper_dba@aos> that creates a role
jean_oper_dba@aos>REVOKE sh_dba_role_0101 FROM jean_oper_dba;
Revoke succeeded
jean_oper_dba@aos> no we can grant the DBV realm owner role to the
jean_oper_dba@aos> application-centric database administrator role
jean_oper_dba@aos>GRANT dv_realm_owner TO sh_dba_role_0101 ;
Grant succeeded
Once this named role is defined, we would authorize the role in the application realm as a realm owner for grantees of the role to manage the roles and object privilege grants that are protected by the realm as follows:
dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm(
realm_name =>'Sales History'
, grantee => 'SH_DBA_ROLE_0101'
, rule_set_name => NULL
, auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER );
END;
/
PL/SQL procedure successfully completed
Depending on the organization’s IT policy or compliance-related security requirements, we may not necessarily want to use the DV_REALM_OWNER role as the base role for any number of reasons, discussed previously We decided that we could have up to four profiles of application administrators, and we want a design that takes into account the need to maintain privilege sets for these profiles across any number of applications and their respective DBV realms The system privilege model should be constructed so that it can be used by several applications in a
hierarchical fashion The approach is to start by defining a set of base roles that will be granted
Trang 3the ANY privileges appropriate to profile We will then create a named application realm role that corresponds to appropriate base role, just as we did earlier Easy enough; let’s implement our four application administrator roles.
Application Security Administrator This administrator can create roles and grant
realm-protected roles or realm-realm-protected objects to other accounts or roles The administrator can also control the audit configuration for the objects protected by the realm The implementation is as follows:
jean_oper_dba@aos> create the base role
jean_oper_dba@aos>CREATE ROLE base_sec_admin_0101;
Role created
jean_oper_dba@aos>REVOKE base_sec_admin_0101 FROM jean_oper_dba;
Revoke succeeded
jean_oper_dba@aos> grant the security-relevant system privileges to this base role jean_oper_dba@aos> this privilege allows the administrator to
jean_oper_dba@aos> grant roles to other accounts or roles
jean_oper_dba@aos>GRANT GRANT ANY ROLE TO base_sec_admin_0101;
Grant succeeded
jean_oper_dba@aos> this privilege allows the administrator
jean_oper_dba@aos> to create roles for use in the realm
jean_oper_dba@aos>GRANT CREATE ROLE TO base_sec_admin_0101;
Grant succeeded
jean_oper_dba@aos> this privilege allows the administrator
jean_oper_dba@aos> to change the authentication mode of the role
jean_oper_dba@aos>GRANT ALTER ANY ROLE TO base_sec_admin_0101;
Grant succeeded
jean_oper_dba@aos> this privilege allows the administrator
jean_oper_dba@aos> to remove roles in the event they are
jean_oper_dba@aos> no longer required
jean_oper_dba@aos>GRANT DROP ANY ROLE TO base_sec_admin_0101;
Grant succeeded
jean_oper_dba@aos> this privilege allows the administrator to
jean_oper_dba@aos> grant object privileges on realm protected
jean_oper_dba@aos> objects to roles or other accounts
jean_oper_dba@aos>GRANT GRANT ANY OBJECT PRIVILEGE TO
base_sec_admin_0101;
Grant succeeded
jean_oper_dba@aos> this privilege allows the administer to configure
jean_oper_dba@aos> audit policy on realm protected objects
jean_oper_dba@aos>GRANT AUDIT ANY TO base_sec_admin_0101;
Grant succeeded
jean_oper_dba@aos> create the role for the Sales History realm
jean_oper_dba@aos> and grant the base role
jean_oper_dba@aos>CREATE ROLE sh_sec_admin_0101;
Role created
jean_oper_dba@aos>REVOKE sh_sec_admin_0101 FROM jean_oper_dba;
Revoke succeeded
jean_oper_dba@aos>GRANT base_sec_admin_0101 TO sh_sec_admin_0101;
Grant succeeded
The DROP ANY ROLE privilege is granted to the application security administrator in the event that a role is no longer required As a matter of safeguarding against human error, DBV command
rules around DROP commands may be worthy of consideration (for many commands) in your
Trang 4production environments This forces the DROP command to be approved by a second party,
namely the DBV administrator, whose approval is the temporary disablement of the command rule or some factor-based modification to the rule that governs it.
We want to create an initial named security administrator account before we protect the role within the DBV realm or we won’t be able to grant the first named account the role without disabling the realm From this point on, we can use the initial named security administrator account to manage grants for all realm-protected roles.
dbvacctmgr@aos>CREATE USER sam_sec_mgr IDENTIFIED BY <password>;
User created
dbvacctmgr@aos> expire the password for the account so they are
dbvacctmgr@aos> forced to change it to a password
dbvacctmgr@aos> they can control at next login
dbvacctmgr@aos>ALTER USER sam_sec_mgr PASSWORD EXPIRE;
User altered
dbvacctmgr@aos>CONNECT jean_oper_dba
Enter password:
Connected
jean_oper_dba@aos>GRANT CREATE SESSION TO sam_sec_mgr;
Grant succeeded
jean_oper_dba@aos>GRANT sh_sec_admin_0101 TO sam_sec_mgr
Grant succeeded
We now protect the base role and application role as realm-secured objects within the appropriate realm and authorize the application administration role in the realm as a realm owner With the application role, we will also add a realm authorization, keeping an eye on the privilege escalation concerns we demonstrated previously.
dbvowner@aos> create a new rule set for privilege escalation
dbvowner@aos> that is specific to realm application security
dbvowner@aos>BEGIN
dbms_macadm.create_rule_set(
rule_set_name =>'Authorized Realm Security Command',
description => 'Checks to verify the command is authorized for a realm application security administrator',
enabled =>dbms_macutl.g_yes,
eval_options =>dbms_macutl.g_ruleset_eval_all,
audit_options =>dbms_macutl.g_ruleset_audit_fail,
fail_options =>dbms_macutl.g_ruleset_fail_show,
fail_message =>NULL,
fail_code =>NULL,
handler_options =>dbms_macutl.g_ruleset_handler_off,
handler =>NULL);
END;
/
PL/SQL procedure successfully completed
dbvowner@aos>BEGIN
dbms_macadm.add_rule_to_rule_set(
rule_set_name => 'Authorized Realm Security Command'
, rule_name => 'Authorized Grant or Revoke'
);
END;
Trang 5PL/SQL procedure successfully completed.
dbvowner@aos> authorize the Sales History realm's
dbvowner@aos> application security administrator with this new rule set dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm (
realm_name =>'Sales History'
, grantee => 'SH_SEC_ADMIN_0101'
, rule_set_name => 'Authorized Realm Security Command'
, auth_options => dbms_macutl.g_realm_auth_owner );
END;
/
PL/SQL procedure successfully completed
dbvowner@aos> protect the Sales History application
dbvowner@aos> security role in the realm
dbvowner@aos>BEGIN
dbms_macadm.add_object_to_realm (
realm_name => 'Sales History'
,object_owner => 'SH'
,object_name => 'SH_SEC_ADMIN_0101'
,object_type => 'ROLE'
);
END;
/
PL/SQL procedure successfully completed
dbvowner@aos> protect the base application security
dbvowner@aos> role in the Oracle Data Dictionary realm
dbvowner@aos>BEGIN
dbms_macadm.add_object_to_realm (
realm_name => 'Oracle Data Dictionary'
,object_owner => 'SYS'
,object_name => 'BASE_SEC_ADMIN_0101'
,object_type => 'ROLE'
);
END;
/
PL/SQL procedure successfully completed
Finally, we’ll examine how this role behaves when our named security administrator account executes commands against realm-protected objects:
dbvowner@aos>CONNECT sam_sec_mgr
Password:
ERROR:
ORA-28001: the password has expired
Changing password for sam_sec_mgr
New password:
Retype new password:
Password changed
Connected
sam_sec_mgr@aos> review and confirm the session privileges
sam_sec_mgr@aos>SELECT * FROM session_privs ORDER BY 1;
Trang 6
-ALTER ANY ROLE
AUDIT ANY
CREATE ROLE
CREATE SESSION
DROP ANY ROLE
GRANT ANY OBJECT PRIVILEGE
GRANT ANY ROLE
7 rows selected
sam_sec_mgr@aos> review and confirm the session roles
sam_sec_mgr@aos>SELECT * FROM session_roles ORDER BY 1;
ROLE
-BASE_SEC_ADMIN_0101
DV_PUBLIC
SH_SEC_ADMIN_0101
sam_sec_mgr@aos> the account can see what the Sales History
sam_sec_mgr@aos> COSTS table looks like
sam_sec_mgr@aos>DESCRIBE sh.costs
Name Null? Type
- -
PROD_ID NOT NULL NUMBER
TIME_ID NOT NULL DATE
PROMO_ID NOT NULL NUMBER
CHANNEL_ID NOT NULL NUMBER
UNIT_COST NOT NULL NUMBER(10,2)
UNIT_PRICE NOT NULL NUMBER(10,2)
sam_sec_mgr@aos> the account cannot see the data in the table
sam_sec_mgr@aos> which is what we want, note this is due
sam_sec_mgr@aos> to the privileges versus DBV
sam_sec_mgr@aos> SELECT * FROM sh.costs WHERE ROWNUM < 6;
SELECT * FROM sh.costs WHERE ROWNUM < 6;
*
ERROR at line 1:
ORA-01031: insufficient privileges
sam_sec_mgr@aos> the account can create a role
sam_sec_mgr@aos>CREATE ROLE sh_query;
Role created
sam_sec_mgr@aos> the account cannot perform object privileges
sam_sec_mgr@aos> just yet as we've added privilege escalation
sam_sec_mgr@aos> logic to the realm authorization rule
sam_sec_mgr@aos> and the account has the implicit grant on the role
sam_sec_mgr@aos>GRANT SELECT ON sh.costs TO sh_query ;
GRANT SELECT ON sh.costs TO sh_query
Trang 7*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-47401: Realm violation for grant object privilege on SH.COSTS
ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55
ORA-06512: at line 31
sam_sec_mgr@aos> revoke the role and we are in business
sam_sec_mgr@aos>REVOKE sh_query FROM sam_sec_mgr;
Revoke succeeded
sam_sec_mgr@aos>GRANT SELECT ON sh.costs TO sh_query ;
Grant succeeded
drop the role as it was just a test
sam_sec_mgr@aos>DROP ROLE sh_query;
Role dropped
sam_sec_mgr@aos> the account can control the audit policy
sam_sec_mgr@aos> on the table, which is also what we want to provide
sam_sec_mgr@aos>AUDIT DELETE ON sh.costs;
Audit succeeded
We can also grant these security administrator accounts the privileges required to maintain OLS policies on the tables protected by the realm If we use the CUSTOMER_POLICY OLS policy from the examples in Chapter 5, we simply grant the OLS component APIs to our security administrator role and the CUSTOMER_POLICY_DBA role to the named account as follows:
lbacsys@aos> these OLS label APIs can be granted to the
lbacsys@aos> security administrator role
lbacsys@aos>GRANT EXECUTE ON sa_components TO sh_sec_admin_0101;
Grant succeeded
lbacsys@aos>GRANT EXECUTE ON sa_label_admin TO sh_sec_admin_0101;
Grant succeeded
lbacsys@aos> this OLS user-label assignment API can be granted to the
lbacsys@aos> security administrator role
lbacsys@aos>GRANT EXECUTE ON sa_user_admin TO sh_sec_admin_0101;
Grant succeeded
lbacsys@aos> in order to use this policy DBA role it
lbacsys@aos> must granted directly to a named account
lbacsys@aos>GRANT customer_policy_dba TO sam_sec_mgr ;
Grant succeeded
We then authorize LBACSYS in the Sales History realm in the same way we did in Chapter 5
to allow the OLS CREATE TRIGGER commands to complete:
dbvowner@aos>BEGIN
dbms_macadm.add_auth_to_realm (
realm_name =>'Sales History'
, grantee => 'LBACSYS'
, rule_set_name => NULL
, auth_options => dbms_macutl.g_realm_auth_participant );
END;
/
PL/SQL procedure successfully completed
Trang 8The result is that we have a named account, sam_sec_mgr, who can maintain an OLS policy’s label components, labels, and user-label assignments for an OLS policy that is specific to data protected in a realm This account can also maintain enforcement for data tables protected by OLS for row-level security policy.
sam_sec_mgr@aos> create a new OLS level for this policy
sam_sec_mgr@aos>BEGIN
sa_components.create_level(
policy_name=> 'CUSTOMER_POLICY'
, level_num => 40
, short_name => 'VERY_HIGH'
, long_name => 'VERY HIGH CREDIT LIMIT'
);
END;
/
PL/SQL procedure successfully completed
sam_sec_mgr@aos> create a new OLS label for this policy
sam_sec_mgr@aos>BEGIN
sa_label_admin.create_label(
policy_name => 'CUSTOMER_POLICY'
, label_tag => 40
, label_value => 'VERY_HIGH'
);
END;
/
PL/SQL procedure successfully completed
sam_sec_mgr@aos> assign the labels ranges of data
sam_sec_mgr@aos> records that ANTHONY can read and write
sam_sec_mgr@aos>BEGIN
sa_user_admin.set_user_labels(
policy_name => 'CUSTOMER_POLICY'
, user_name => 'ANTHONY'
, min_write_label => 'LOW'
, max_read_label => 'HIGH'
, max_write_label => 'HIGH'
, def_label => 'HIGH'
, row_label => 'HIGH'
);
END;
/
PL/SQL procedure successfully completed
sam_sec_mgr@aos> simple test to remove the table policy
sam_sec_mgr@aos>BEGIN
sa_policy_admin.remove_table_policy(
policy_name => 'CUSTOMER_POLICY'
, schema_name => 'SH'
, table_name => 'CUSTOMERS'
, drop_column => FALSE
);
Trang 9PL/SQL procedure successfully completed
sam_sec_mgr@aos> simple test to add the table policy back
sam_sec_mgr@aos>BEGIN
sa_policy_admin.remove_table_policy(
policy_name => 'CUSTOMER_POLICY'
, schema_name => 'SH'
, table_name => 'CUSTOMERS'
, drop_column => FALSE
);
END;
/
PL/SQL procedure successfully completed
This OLS policy control, in addition to the object privilege management, role management, and auditing of the objects protected by the realm, make for a complete application security administrator pattern that can be implemented in your environment.
Application Maintenance Administrator This administrator’s privileges would be limited
to performing in the DDL category of commands on the application realm’s objects The implementation is as follows:
jean_oper_dba@aos> create the base role
jean_oper_dba@aos>CREATE ROLE base_maint_admin_0101;
Role created
jean_oper_dba@aos>REVOKE base_maint_admin_0101 FROM jean_oper_dba;
Revoke succeeded
jean_oper_dba@aos> grant the DDL system privileges to this base role
jean_oper_dba@aos>GRANT ALTER ANY CLUSTER TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY DIMENSION TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY INDEX TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY INDEXTYPE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY MATERIALIZED VIEW TO base_maint_admin_0101; Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY OPERATOR TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY OUTLINE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY PROCEDURE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY SEQUENCE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY TABLE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY TRIGGER TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT ALTER ANY TYPE TO base_maint_admin_0101;
Trang 10jean_oper_dba@aos>GRANT COMMENT ANY TABLE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY CLUSTER TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY CONTEXT TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY DIMENSION TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY INDEX TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY INDEXTYPE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY MATERIALIZED VIEW TO base_maint_admin_0101; Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY OPERATOR TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY OUTLINE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY PROCEDURE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY SEQUENCE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY SYNONYM TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY TABLE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY TRIGGER TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY TYPE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT CREATE ANY VIEW TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY CLUSTER TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY DIMENSION TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY INDEX TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY INDEXTYPE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY MATERIALIZED VIEW TO
base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY OPERATOR TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY OUTLINE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY PROCEDURE TO base_maint_admin_0101;
Grant succeeded
jean_oper_dba@aos>GRANT DROP ANY SEQUENCE TO base_maint_admin_0101;
Grant succeeded