In part 1 I talked about introduction to the security world and important terms. In this post I will introduce database security, what it means and what we can do about it.
Link to the previous post: part 1 – general introduction to security
The database is the heart of the organization’s data. People want to lay a hand on it to get sensitive information (such as credit card information or salaries of employees) or change data (such as money transfers or billing). Another option is simply take the database down, so all the applications that use this database will be down.
Some people might say that this is the reason that their database is not exposed to the internet and by that they protect it from attacks. This is important, as the database server should not indeed be connected to the internet (too many do, though), however, a hacker can access in other ways. One of the famous hacks lately was to RSA Security in 2011. In this breach, the hacker used an email that contained malware and managed to get one of RSA’s employees to open it. The malware installed itself, allowing the hacker to access the network from inside. The hacker then could access servers that were not connected to the internet.
So even if the database server is not connected to the internet, we need to secure it, because an attacker can use an internal machine to connect to it, and because we also need to secure it from internal “attackers” (malicious or not).
Infrastructure
One aspect of protecting our database is the infrastructure layer. In this section I include the OS (users, passwords, etc.), the network (access control, listener configuration) and the database itself (the installation, database features and more).
There are also issues outside of the database server itself. For example, we can secure our database server perfectly, but give everyone access to our database backups.
I will discuss this in the next post.
Application
Another aspect of protecting our database is the application layer. We can secure our database as much as possible, but if the application that connects to it has DBA privileges and allow any user to execute anything, we lost the war before it even began.
Under this “application” section I include application permissions, application SQL and PL/SQL code, passwords, etc. I also include here the developers and their access to the different databases. Note that I won’t include actual code security (like C and Java known issues, etc.).
I will talk more about this topic in the forth post (after the infrastructure one).
Others
Besides the application and the infrastructure, there are some other things that should be taken into account, regulations for example. Many organizations today should be compliant to regulations such as PCI if they store credit card numbers, HIPAA for health care information, etc. These regulations require certain actions to be taken on the database and environment. I think that any organization that needs to comply with any regulation, should take another step forward and harden and secure its environment and database as well as it can, and not only to comply.
Another topic here will be security products that provide access control, auditing and alerting mechanisms. They usually provide a very good protection, eliminate some hardening steps, and provide an active guard against attacks.
The last topic is duplication of the database. Many organizations protect their production database, but then copy it for development or QA purposes. The copied database contains the exact same information as the production one, but is far less secure. The best practice here is to scramble the sensitive data so the database is usable but contains incorrect or unusable information. There are several tools for that, including our very own JumbleDB.
Summary
In this post I talked a little bit about database security. It was still a theoretical discussion, but we need to understand this world and concepts before really talking about the details, which will be in the next post.
Many of the companies, donot allow us to change the security permissions.
They create a user and grant DBA privilege and then build the application on it.
So in the middle if we remove the privs, application gets affected and throws “invalid permission” error.
Apart from user level security, do we need to do the below things to secure our database/
1) Encrypt the Listner.ora file?
2) Encrypt the datapump dump file (.dmp file)?
3) Encrypt the RMAN backup?
You are right. Companies that need to comply to regulations and need database hardening might have difficulties with such 3rd party software, as this is far from being a best practice.
I actually was involved in a project with a software company that needed to remove its DBA privilege from their application user.
Regarding the encryption, you cannot encrypt the listener.ora file, but definitely should secure your dump files and backups. I’ll mention it in one of the posts in this series.
Thanks for the comment