"It would be easier to implement a patch policy if it came from management and we could get downtime", "I don't know what data to encrypt so the application owners need to tell me", "Isn't it the security team's responsibility to make sure that access changes when the jobs change". These are probably things we have heard DBAs says and maybe have even said them ourselves. Security is something that a DBA is responsible for implementing but where does the responsibility end?
I was reminded the other day about this topic and started to think about this. If there was an outage because something happened for an upgrade, and the DBA was not able to restore the database, is that the fault of the upgrade or not being able to restore? Again we can probably argue both, and at the same time I am thinking if I wasn't doing everything possible to assure that had good backups and could restore from them, I would fault myself.
Yes, it is definitely easier if it isn't just coming from the DBA team that security patches need to be applied, and if there were top down mandates to govern security practices, but what can be done by the DBA?
One, patches should be applied to the system and the DBA can have a solid implementation plan in place to make this easier. Probably if patching was successful on a regular basis the outage or maintenance window would be easier to get. A good test plan with reviewing of pre-checks and post-scripts to make sure everything gets covered in a step by step way. This process is something the DBA can own and promote. A well documented plan with details about testing and success rate.
Two, encryption at the tablespace level. This is transparent to the application, and if the DBA knows that the database can have sensitive information, then it is definitely worth raising the risk of what happens if this data at rest is accessed. Encrypting the tablespace means that you don't have to know exactly what fields are sensitive either. It would be great to have these conversations to control access and mask this data in test environments, but at least reducing the risk of data at rest and outside of the application is worth it. This also is a feature that is fun to implement as a DBA, because it is on the back end and is how you create the tablespace.
Three, protect yourself from seeing data you don't really want to see in the first place. Being able to prove out that even with sysdba permissions you can't see the data in a database vault realm protects you knowing what you really don't want to know. Using database vault does protect the data from the administrators, but still allows for the job to get done. Database vault is an option that can be configured after creating the database using dbca (database configuration assistant). The realms would be managed by someone outside of the DBAs or SYSDBA to make sure that these permissions cannot be granted back to the SYSDBA.
Four, check out the database firewall. We should be evaluating and looking at new security features. The firewall can help in the fight against SQL injection, and examining new features and doing the research would be useful to understanding if it is something that would be of value and reduce some risk in your environment.
Five, educate business and users of the environment. This would also tie in the research about features. After the initial understanding of what can be secured, monitored and implemented, then it is time to talk. Discuss what it takes to implement and the risk, which is a great way to look at some of the value you can get out of securing the environment.
These are good steps to be taking as a DBA to provide a secured database environment.
It is not necessarily going to be the easier road to take, but there are some things we can do. And there is persistence on our side because I would definitely like to error on the side of trying to implement the needed security and communicating the risks, then being caught when it isn't implemented and not having even tried.
