PROTECTING ORACLE PL/SQL SOURCE CODE FROM A DBA USER

P L / SQL SOURCE CODE B LOCKS AND WRAPPING PROCESS
1. PL/SQL stands for Procedural Language/SQL. PL/SQL e xtends SQL by adding constructs found in procedural languages, resulting in a structural language that is more powerful than SQL. The basic unit in PL/SQL is a block.
  1. Overhead: Because stored statements are stored directly in t he database, they may remove all or part of the compilation overhead that is typically required in situations where software applications send inline SQL stateme nts to a database. In addition, while they avoid some overhead, pre-compiled SQL statemen ts add to the complexity of creating an optimal execution plan because not all arguments of the SQL statement are supplied at compile time
  2. Avoidance of network traffic: A major advantage with stored pl/sql object is tha t they can run directly within the database engine. In a p roduction system, this typically means that the procedures run entirely on a specialized d atabase server, which has direct access to the data being accessed. The benefit here is tha t network communication costs can be International Journal of Database Management System s ( IJDMS ) Vol.4, No.4, August 2012 47 avoided completely. This becomes particularly impor tant for complex series of SQL statements
  3. Encapsulation of business logic: Database stored PL/SQL objects allows software developers to embed business logic in the database. This method can reduce the need to encode the logic elsewhere in any client applicatio ns. The database system with the help of stored procedures can ensure data integrity and consistency.
  4. Delegation of access-rights: In many systems, stored PL/SQL objects can be gran ted access rights to the database that users who execut e those procedures do not directly have.
  5. Protection from SQL injection attacks: Database stored PL/SQL objects can be used to protect against injection attacks. Parameters used during function or a procedure execution will be treated as data even if they are inserts SQL commands from an attacker.
ORACLE DATABASE SECURITY
1. The intent of this section is to give a basic under standing of the security capabilities of Oracle relational database management system. It is not th e scope of this paper to explain all of the security features and options available in Oracle r elational database management system. The Oracle RDMBS has too many security features which m ake it an excellent database system for any database application. Data integrity, confident iality, and availability are well - protected with a properly designed Oracle database
  1. Oracle allows for various types of authentication. Oracle-based authentication allows for Oracle database accounts with user-ids and strong password s which are encrypted with a modified DES algorithm for each database connection. Oracle pass words are stored in an encrypted format in the data dictionary [8]. Each session key is unique, wh ich means the key is not re-used in any other session. Oracle also supports authentications based on the operating system’s user accounts which are then passed on to Oracle RDBMS
    1. Oracle makes use of profiles to allow the database administrator to place specific restrictions, rules and controls on a number of system resources, password usage lifetime and various Oracle products. These profiles can be named, defined, and then assigned to groups of users or to specific users. There are two types of profiles as bellow.
The electronic information is simpler to reuse and modify and query, so the future is going towards to only digital data. Sometimes , we do not need to have a trace of changes that we made, and sometimes it is required to know the history of changes. This information can be stored in any database, but not all the database engines meet these requirements. The most important requirements vary to performance, hardware resource s, security, user-friendliness, price or others
PROTECTING PL/SQL OBJECTS BY DISABLING DML/DDL STATEMENTS TO ANY USER
1. To protect PL/SQL objects is necessary to disable D DL statements like create, replace and some DML statements oriented to the static data dictiona ry views *_SOURCE. To prevent execution of any DML/DDL statements on some object we must monit or every user session and analyze every SQL statements before their execution.
2. We developed some scripts which can prevent any una uthorized user to execute DML/DDL statements over any database object. Those scripts monitor every user sessions and if they detect any DML/DDL statements over objects, which are prot ected by scripts, then scripts immediately, kill this user session and do not allow execution o f those DML statements.
3. The scripts also analyze DDL statements, because if a user with permission to disable triggers, to drop package, to modify procedure, functions, and e tc, can disable our scripts too. By analyzing DDL statements, scripts can protect their self from any unauthorized DDL statements. So if a user is trying to execute DDL statements over our script s, this session will be killed immediately
4. All the DML and DDL statements are checked, and if statement is not allowed to be executed, immediately their session will be killed
CONCLUSIONS & FUTURE WORK
1. Our scripts can disable DML/DDL statements of an un authorized user even he has DBA role, but we must monitor all sessions, so the database perfo rmance decrease but it does not influence too much. Our tests were based on a database schema whi ch includes about 300 tables and some table contains more 50,000,000 million records. After the test we did not find a difference on a query time before the implementation of scripts and after it.
  1. As described above we can stop execution of DDL sta tements oriented to the static data dictionary views *_SOURCE, but this prevent DBA to access its PL/SQL objects, to solve this problem session monitoring part will allow query wh en their results do not contain any part from of protected PL/SQL objects. This part must be modi fied in future to allow execution of DML statements oriented to the static data dictionary v iews *_SOURCE but have to modify the result where protected objects will be invisible to user r equest.
    1. Even if DBA cannot execute DML/DDL statements on pr otected objects or DDL statements over our package he still can manipulate the data by gen erating some triggers to an authorized user. To eliminate this problem we insert every DDL statemen ts into ddl_log table which is part of our package.
      1. Package must be installed to a user with sysdba role because it uses some necessary packages.
        During protection of objects, the scripts kill untr usted sessions but sometime not all the SQL statements on those sessions must be killed.

Next up

PROTECTING ORACLE PL/SQL SOURCE CODE FROM A DBA USER

Description

Resource summary

Similar

	Created by espinoza__123 almost 10 years ago