| Oracle Enterprise Database11g has the Virtual Private | | | | sensitive columns. However, with column masking the |
| Database feature to provide security features to your | | | | data of all such rows is displayed where the sensitive |
| database. Virtual Private Database or VPD is very | | | | columns have null value. This way more information is |
| useful in situations when associated database roles | | | | available for the authorized users and only the |
| and standard object privileges cannot provide | | | | sensitive information is hidden. |
| application security requirements. You can set the | | | | Virtual Private Database can be made more secure |
| Virtual Private Database policies to be simple or | | | | by providing security at the column or row level by |
| complex depending upon the amount of security you | | | | combining VPD with application context feature. |
| need to provide to the database. | | | | Providing security at such deep levels was termed as |
| You can create a secure virtual private database to | | | | fine-grained access control or FGAC where you can |
| keep it safe from unauthorized access. Virtual private | | | | secure a row or column separately also. Whenever a |
| database is used in environment where multiple users | | | | DML or DDL query is initiated by the user Oracle |
| access the same database and only specific | | | | Database dynamically modifies the query before data |
| information should be available to each group. The | | | | retrieval or data manipulation. However, the user is |
| best way to secure your virtual private database is to | | | | unaware of the security procedures followed at back |
| implement security features during its creation or | | | | end, as it is transparent for users and whenever he or |
| designing. The level of security is very high as you | | | | she access the data only the authorized information is |
| secure your database instead of controlling it with | | | | shown. Moreover, you need not to modify your |
| some other application. | | | | application code whenever you want to change any |
| Best way is to associate security policies with the | | | | of the security policies. Just change the Virtual Private |
| views and tables of the database. It is designed in | | | | Database policies to grant or deny access to any part |
| such a way that security policy is implemented | | | | of database. Irrelevant of the fact that you use any |
| whether you access the data directly or indirectly. | | | | source to connect to the database, that is, whether |
| What is more? You can also define security policies | | | | you use an application, SQL or web interface, there is |
| for a set of statements that eliminates the need to | | | | no way by which your application security can be |
| develop security policies individually for all statements. It | | | | infected. |
| is also possible to apply multiple policies for a group of | | | | Various other types of VPD policy types such as |
| views, synonym or tables. | | | | Static, Shared and Context-Sensitive are also used to |
| A new feature known as Column Masking is also used | | | | provide a better level of security. You may use |
| with Virtual Private Database which overcomes the | | | | context-sensitive and static policies to secure multiple |
| drawbacks of Column relevance. Main problem with | | | | database objects. Shared policies would save your |
| column level Virtual Private Database security was | | | | overheads on re-executing policy functions repetitively |
| that it restricted the rows that contains data for | | | | for every query. |