kwlol
asked on
Oracle Database Data Protection
I would like to know how the Oracle database files are protected under the operating system, say AIX. In particular,
- is the database files encrypted, so that they could not be seen by other users under the same OS?
- how about its stored procedures, would they be stored as plained text under the OS?
- any log files that may leak out the data stored inside?
Thanks.
- is the database files encrypted, so that they could not be seen by other users under the same OS?
- how about its stored procedures, would they be stored as plained text under the OS?
- any log files that may leak out the data stored inside?
Thanks.
While the data files are not encrypted, they are not easily human readable. You could probably figure out things stored in VARCHAR or CHAR fields, but anything in a NUMBER field is definitely not human readable.
For stored procedures, they are stored in a data file and not easily accessible from the OS. From within the database, they are stored in plain text unless wrapped as already suggested.
Archive log files go with data files. The information in them is not human readable, but VARCHAR or CHAR fields could possibly be pulled from them in some way.
The only human readable file that I could think of that might have data in it would be a trace file. However that depends on how your application is written. If it is all done with bind variables, that would drastically minimize the amount of data that is in the files. Also, this would assume that you have tracing turned on. If it is off, then this would minimize it even more.
For stored procedures, they are stored in a data file and not easily accessible from the OS. From within the database, they are stored in plain text unless wrapped as already suggested.
Archive log files go with data files. The information in them is not human readable, but VARCHAR or CHAR fields could possibly be pulled from them in some way.
The only human readable file that I could think of that might have data in it would be a trace file. However that depends on how your application is written. If it is all done with bind variables, that would drastically minimize the amount of data that is in the files. Also, this would assume that you have tracing turned on. If it is off, then this would minimize it even more.
>>they are not easily human readable
There are a lot of tools out there to browse (recover) data by reading the DBF files directly.
Oracle even supplies one: BBED
http://www.dba-oracle.com/forensics/t_forensics_bbed.htm
>>The information in them is not human readable, but VARCHAR or CHAR fields could possibly be pulled from them in some way.
Logminer.
There are a lot of tools out there to browse (recover) data by reading the DBF files directly.
Oracle even supplies one: BBED
http://www.dba-oracle.com/forensics/t_forensics_bbed.htm
>>The information in them is not human readable, but VARCHAR or CHAR fields could possibly be pulled from them in some way.
Logminer.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Last time I used LogMiner, it was a package DBMS_LOGMNR. There is no command line that I am aware of. Without a dictionary file it is pretty difficult to read them on another system. The datatypes and things are skewed. You may be able to get some information out of them from the statements, but it is all in a raw binary format (even character fields). The dictionary file is what makes them readable.
You need extra products to achieve PCI-DSS conformance as AIX or plain oracle has no provisions to encrypt database.
Linux on the cheaper hand can encrypt LVM partitions....
Linux on the cheaper hand can encrypt LVM partitions....
Not by default. You need additional products to achieve this:
http://www.oracle.com/us/products/database/sans-tde-wp-178238.pdf
- how about its stored procedures, would they be stored as plained text under the OS?
By default stored procedure code is in clear text. Check out the WRAP program (They can still be unwrapped):
http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/wrap.htm
- any log files that may leak out the data stored inside?
Main ones: Archived redo logs.
Also, any trace files have the potential to leak data. Depending on what you consider a leak, log files like sqlnet.log and even the listener.log can provide some sensitieve information.