Transcript dbv - Marco Alamanni

Database Vault
Marco Alamanni
Why Database Vault?
• Compliance to regulations such as Sarbanes-Oxley
(SOX), European Data Protection Directive
(95/46/EC) and Health Insurance Portability and
Accountability Act (HIPAA) require Strong Internal
Controls and Separation of Duty
• Internal threats are a much bigger concern today
require enforcement of operational security policies Who, When, Where can data be accessed?
• Database consolidation strategy requires preventive
measures against access to application data by
Powerful (DBA) users
Common Security Problems
• I have requirements around SOX and PCI, how can I
prevent my DBA from looking at the application data,
including Credit Cards and Personal Information?
• No protection from users with DBA privileges
DBA role with full access to user and business data
• Only few apps built with least-privilege model:
various utilities require powerful administrator
privileges
• Cannot meet new compliance requirements:
separation of duty not enforced
• Cannot control user creation, role assignment, etc.
Oracle Database Vault Goals
• Integrated security framework to provide full control:
Network, users, DBA, data, roles, SQL
Multi-factor Authorization and Policies across
various checks
• Compliance requirements:
Built-in Separation of Duty
Prevent misuse of powerful privileges
Support Database consolidation
Database Vault Versus
VPD and OLS
• Virtual Private Database (VPD):
Restricts access to certain rows for a user by modifying the
WHERE clause
• Oracle Label Security (OLS):
Mediates access to a given row, based on the label on the
row and the security level of the user
• VPD and OLS restrict access at the row level, whereas
Database Vault restricts access at the object and command
levels.
• DBV is integrable with both VPD and OLS
DBV Administration Model
• DV Administrative roles:
DV_SECANALYST: Reporting only
DV_ACCTMGR: Maintain db accounts/profiles
(but no
roles)
DV_OWNER: Big boss but cannot grant any
direct access rights
• DV Realm Roles:
DV_REALM_OWNER: Manages realm and
associated roles
• Security:
Provide separation of duties with different admin
roles
sys, system, sysdba and sysoper cannot grant
DV_OWNER, DV_ADMIN roles
Separation of Duty
Key Components
•
•
•
•
•
Realms
Command Rules
Rule sets
Factors
Secure application roles
Realms
• Collections of schemas, objects and roles to be
secured
• Controls SELECT, DML, DDL, EXECUTE on
protected objects
• Prevents super user (ANY) access to security
sensitive data
• Does not impact direct object privileges
• Realm owner determines:
Who can access the realm using system
privileges
Grants/revokes applicable roles
• Authorization enforced at every data object access
during SQL execution
Default Realms
• Database Vault Account Management:
Protects user accounts/profiles and account
management role
• Data Dictionary:
Protects all DBMS meta-data
• Enterprise Manager:
Protects all objects required by Enterprise
Manager
• Database Vault:
Protects all Database Vault meta-data
All object owned by Database Vault schemas
All objects owned by LBACSYS
All Security Administration Roles
Benefits of Data Protection
with Realms
• Ability to restrict access to privileged users based
upon a collection of objects
• Separation of Duty regarding user administration, and
role management
• Ability to define additional realm authorization rules
based upon requirements
• Limit damage even if privileges escalate to DBA
• Minimize risks associated with an army of DBAs for 7
* 24 operation whether in-house, outsourced
• No changes required to applications
Command rules
Command Rules Mechanics
• Works very similar to DDL event triggers
• Built into the SQL engine for optimization and security
• Cover all basic DDL and DML commands
Command Rule Flexibility
Alter Database
Alter Function
Alter Package Body
Alter Session
Alter Table
Password
Change Password
Create Function
Create Database Link
Create Package Body
Create Table
Noaudit
Create Tablespace
Update
Execute
Alter Database
Audit
Alter Procedure
Alter System
Alter Trigger
Alter Tablespace
Connect
Create Index
Create Procedure
Create User
Grant
Rename
Create Trigger
Insert
Select
Alter Table
Alter Tablespace
Alter Profile
Alter Synonym
Alter User
Alter View
Comment
Create Package
Create Role
Create View
Insert
Lock Table
Truncate Table
Delete
Rules and Rule Set
Factors
• A factor:
Is an attribute of a database session
Can have a value, which can be labeled
as an identity
• Can easily be referenced in other Database
Vault components to discern access
• Can be combined with other factors to provide
for multifactored authentication
Factor’s Identity
• An identity:
Is a value
Is associated to a factor
Has a trust level
Can have a label
• Can be resolved from other factors
• Can be retrieved with PL/SQL functions
associated with the factor
Built-In Factors
• User Factors:
Name
Authentication type
Session User
• Database Factors:
Database IP
Database Instance
DatabaseHostname
• Network Factors:
Machine name
Client IP
Network Protocols
• Runtime Factors:
Language
Date
Time
Examples of Security Policies
• IP address based policy:
Allow access from intranet IP addresses
Allow access only from application servers
• DBA policies:
Allow updates to the database structure only on the
weekend
Allow DBA access only with PKI/Kerberos authentication
Allow DDL but only with strong authentication
Permit DDL (CREATE INDEX) but not SELECT
Implement a different set of policies for different types of
DBAs
• Time/date based policies
• Disallow access from ad-hoc tools (SQL*plus)
Oracle Database Vault
Rules & Multi-factor
Authorization
• Database DBA attempts
remote “alter system”
Rule based on IP
Address blocks action
• HR DBA performs
unauthorized actions
during production
alter system…….
DBA
create …
HR
HR
HR DBA
3pm Monday
Rule based on Date and
Time blocks action
Factors and Command Rules provide
flexible and adaptable security controls
HR Realm
Deployment Flow
Database Vault Access Algorithm
Integration with OLS and VPD
• Oracle Label Security:
Association of factors identities with OLS
labels to enforce row-level security
policies
• Virtual Private Database:
Factors can be used in PL/SQL functions
that implement VPD policies
PL/SQL API to Database Vault
• PL/SQL interface for scriptable administration
and tools
• API includes:
Create, modify, and delete Database Vault
components
Allow a session to define their security
environment
Query the state and values of components
Administer and configure system-wide
Database Vault parameters
Oracle Database Vault Summary
• Integrated security framework to provide full control:
Control access based upon Network, users, DBA,
data, roles, SQL access
Multi-factor Authorization and Policies across various
checks
Baked-in Security controls
• Compliance requirements:
Built-in Separation of Duty (Users mgmt, data mgmt, apps
mgmt)
Prevent misuse of powerful privileges
• Operational requirements:
No application changes required
Minimal Performance impact
Easy-to-use PLUS customization flexibility
Support Database consolidation
Credits and references
• Oracle Database Vault – Under the covers,
Vipin Samar, Oracle
• Dividing the Keys to the Kingdom Separation of Duties with Oracle 10g
Database Vault,
Eric Siglin, Oracle
• Patricia Huey, Oracle Database Vault
Administrator’s Guide 11g Release 2 (11.2),
Oracle, 2010