As we hear in the news applications are under constant attack. The reason for that is for the most part applications represent the weakest IT link. Many apps, especially custom applications, have little to no built-in security. Instead of running with least privilege, most apps actually run with DBA privileges “just in case”. Even worse many applications store database connection credentials in the clear.
This is what makes applications such attractive targets. If a bad guy can find a way to get control of the application or the system the application is running on, they can get access to the database, typically as a privileged user.
It is also easy for insiders to by-pass application security controls all together and use their credentials to connect directly to the database and access unauthorized data.
And with enterprise identity theft on the rise, bad guys who have stolen credentials are now posing as trusted insiders to gain access to sensitive application databases.
Also since many organizations have consolidated application databases, if a bad guy compromises one application to gain access to the database, they can now access all the sensitive application information stored on that server. Sometimes all it takes is one application being compromised for all of your application data to be compromised.
More and more companies are also under regulatory scrutiny and must prove they have put in place controls to protect data privacy at all levels of their business. The IT Policy Compliance Group concluded 6 months ago that about 90% of companies fail compliance, facing penalties and remediation expenses. Additionally breach disclosure laws have made any unauthorized data access very costly. Remediation costs $239/record and does not include loss of reputation, business, or litigation associated with data breaches.
We’re all familiar with concept of Defense in Depth. On the regulatory side we’re seeing an equivalent concept, “Controls In Depth”. It’s not enough for organizations to build controls into their business processes. Auditors are looking for IT controls to ensure that business controls can’t be circumvented at the IT level. And one of the first place auditors will look is the database given that’s where all the regulated data resides.
Not only is it key for organizations to prove that they have put in preventive controls for auditors, it is also key to mounting a credible legal defense in case there is a data breach and litigation ensues. Organizations that are subject to regulations like PCI, SOX, GLBA, and HIPAA must be able to prove preventive IT controls such as separation of duties and least privilege.
“Legal says our DBA should not be able to read financial records, but the DBA needs to access the database to do her job. What do we do?”
“Our SOX auditors require that we separate account creation from granting privileges to accounts.”
“No user should be able to by-pass our application to access information in the database directly.”
“How do we keep the Finance department from running reports during production hours?”
“New DBAs should not be able to make database changes without a senior DBA being present.”
Oracle Database Vault is powerful rules engine inside the Oracle database that can enforce security policies such as least privilege and separation of duties by restricting access to any users, including privileged users. Since policies are enforced inside the database no changes to applications are needed.
Here we see how Database Vault Realms placed around application databases enforce administrative boundaries and restrict access to those application to privileged users. So for example a database administrator that can manage all the application databases cannot actually read (do a select) the data stored in those databases.
Similarly a privileged HR application user has free reign over the HR Application database but cannot access data stored in the Financial Application database since these are different Realms. Being able to prevent privileged users from accessing data outside their authorization is critical as many enterprises are consolidating application databases on the same database server and more data into databases for ease of management and lower TCO.
The performance overhead of Realms is between 3 and 5 percent.
In addition to Realms, Database Vault can also restrict ad-hoc access to the database, protecting application data from being accessed through other tools or via other unauthorized means.
With Database Vault organizations can define authorization rules based on internal and external factors, such as ip address, time of day, application being used, authentication type, etc. So for example if a request to access HR data comes from an IP address that is assigned to a desktop v. an IP address assigned to an HR Application server, Database Vault can block that access. Similarly if let’s say an organization has a policy of no changes to databases during production hours, and a new DBA tries to do an upgrade at an unauthorized time, Database Vault can block him. Or alternatively the rule could have been setup so that it required a second DBA to be present (logged in) if a change had to be made during production hours.
Database Vault rules can be associated with over two dozen individual database commands, such as create table, create view, drop table and comes with many built-in factors, all of which can be extended via APIs. Database Vault also comes with Out of the box policies for Oracle E-Business Suite, PeopleSoft, and Siebel applications.
© 2009 – 2011, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
最新评论