Speaking of the minimum set of security measures, I would highlight the following items
Separating data access at the user or group level Monitoring user activity and notifying security officers in case of suspicious transactions Preserving audit trail for future analyze
As a fan of the Oracle database, I believe that it is the best database in terms of the convenience of development and the abundance of built-in possibilities for data security implementation. Nevertheless, some things are not easy to implement even in Oracle.
In the Oracle database, you can give access to database objects to the user or role. Oracle even allows you to give permission to change only the defined columns, but let’s imagine you need to give access to select only a given set of columns. The simplest example is a table containing information about credit cards. The call center user should not see the credit card number but must see the status of the card. The solution could be to create a view based on table data, in which the credit card number is missing or masked. After that the access to be configured to allow user deals with a view instead of a table. But this is not such a simple solution as it assumes an additional development of the system, especially if it is a purchased product. Let’s take a look at another example. Assume that we have a table contains information about a company’s customers. Each employee should see customers relate only to him. The solution is to create a view for each employee with the condition of selecting data belongs only to him but like in the previous case it leads to the additional development. A more elegant solution may be the use of Oracle Level Security, but this also not eases since it supposes the development of PL/SQL code implements restricted rules as well as an additional configuration to add policies to the table. Another problem is that using OLS is not always transparent for the database administrator and supposes revising database code to understand the logic the rule is implementing. Talking about monitoring and auditing, the first thing that comes to mind is Fine-Grained Auditing. This is a powerful mechanism allows you to track SQL operations at the table or view level. But we are faced with the same problem as described above, namely, this leads to the additional configuration of the rules and it hard to quickly understand what actions are logged and which ones are not. Moreover, FGA can’t notify about suspicious activity thus, notification implementation requires additional development. Storing audit is the database could also be a problem, as if an attacker gets administrative rights, he can simply clean the audit logs out. Given all of the above problems, we used a completely different approach to data protection. The idea is to use the DataSunrise database firewall, which is put between the database and the application. It allows implementing database protection rules based on the database traffic. The firewall allows to simply configuring the rules that separate accesses to given objects in the database. The rules can be applied to any SQL statement for any database objects. So for example, we can simply configure a rule that prohibits the user from modifying data in a specific column of the table. Moreover, we can describe the action that will be performed if the user has tried to change the data. For example, when the user tries to change account balance or to get information about a credit card number, the mail will be sent to the company’s security service. Also, the firewall provides a fairly convenient mechanism for sensitive data obfuscation. It allows the setup of the rule masking data with a given pattern. For example, the rule can be configured to provide only the last 4 digits of the credit card number when the user is selecting data from the credit card table. This is quite convenient, given that the configuration of the rules occurs through the web interface with a few clicks and does not require a deep knowledge of the Oracle database security. Another benefit is that DataSunrise uses a separate database to store audit logs. So, even if the Oracle database is unavailable, you can always see what actions were performed in the database. At the end of the day, we found the DataSunrise firewall very useful in greatly simplifying the configuration of database security and it allows to implement security rules fast enough without deep-diving into the database settings. I still believe that DataSunrise should not be a full-fledged replacement for Oracle DB security, but I’m absolutely sure this can be an excellent extension of the database security. Coexisting with internal data protection mechanisms, this can help to build a reliable database security system in a relatively short term.
