Kicking a row over database insecurity
In the ancient times, men would seek out a sage for aid and counsel in time of need. Such mystics also claimed to be able to see things that were otherwise unseen, and some claimed to mysteriously have answers to questions not even raised.
Perhaps Oracle sees itself doing the same, because they seem to have taken a step forward in database security that other database vendors have not yet ventured into - adding row-level security.
This additional layer of security management does not require an added layer of application coding to grant access, however it is being packaged as an option in Oracle9i.
Oracle9i, which was positioned for ASPs and MSPs, now allows for greater control between what each user (or groups of users) has access to, meaning there's no more need to maintain a separate database instance for each customer.
The Oracle Label Security (OLS) option, which was actually developed from the Oracle8i Virtual Private Database feature, allows providers to label data at the row level (as opposed to the traditional table level) to ensure proper access to data, thus positioning it as a more cost-effective solution for providers with scalable customer-bases. This is especially so for current providers who are already using Oracle solutions, since there's no need to re-code entire databases and applications to ensure for proper secure access.
Organizations that wanted to use a trusted version of the database would not have to revamp their entire security system, according to Peter Thomas, director of marketing for Oracle9i in Asia. OLS also allows customers in a hosted environment to secure their present database without having to modify the application.
Policies can be managed through a graphical user interface to help define permissions in terms of levels, sensitivity, categories as well as allocate access in order of groups.
Traditionally, security for databases is assigned at the table level, and requires some application coding to grant access to the row level. This security layer can be bypassed easily when a user gains access to the database from an outside application.
On the other hand, Label Security is implemented in the DB kernel, as that's where the security policies are evaluated and then labels applied to the data in the table, says Thomas.
The OLS allocates a row identifier to the rows within the table, allowing for the allocation of permissions at the row level. Data rows can be tagged not only to give the right person access but to allow access during certain parts of the day and from specific locations. When data is accessed, the database then compares its labels with the labels in the directory.
The concept for Label Security was originally initiated to meet the needs of the US government, leveraging off research that it had done with selected government agencies, including standards laid down by the US Defense Department.
"We've taken technology that was originally defense-related… and moved it into the commercial," said Thomas.
Oracle Label Security has been available since March 2001 and costs US$120 for a named user single server, US$150 for a multi-user server, or US$15 per universal power unit.