It’s a new year, and therefore time to start a new series of posts. This year I will be looking at how to secure Oracle on a limited budget (or more commonly a non-existant one), with an emphasis on what can be done for little or no additional cost beyond the basic hardware and software licensing and maintenance fees required to install the original infrastructure.
Based on my experience of over 20 years working in both the Department of Defense and the corporate world I will attempt to convey what I believe is the most inexpensive way possible to deploy Oracle while maintaining compliance with the various applicable network rules and requirements that we all face, such as the DISA Security Technical Implementation Guides (STIGs).
In each post I will address a particular problem or set of problems faced by a database administrator when configuring and deploying an Oracle database server. I will present my proposed solution, reference any applicable STIG items and any ballpark cost estimates, savings or concerns. Most solutions can be applied to any architecture, regardless of complexity, but I will raise a flag if anything I’m suggesting is only appropriate for a particular configuration.
I will be spending time on each of the following categories. Some can be summed up in a single post, while others will be more complex or incorporate several sub-topics that will take more time to adequately discuss.
- Rules and Regulations
- System Documentation
- Infrastructure Planning
- OS Configuration
- Oracle Installation
- Oracle Configuration
- Application Design
When I talk about deploying a “secure” database, what exactly do I mean? It is easy to assume that I might mean “well protected”, but security is much more than keeping out the bad guys. According to Wikipedia, database security “concerns the use of a broad range of information security controls to protect databases (potentially including the data, the database applications or stored functions, the database systems, the database servers and the associated network links) against compromises of their confidentiality, integrity and availability. It involves various types or categories of controls, such as technical, procedural/administrative and physical.” (Wikipedia, August 20, 2014)
So a secure database system is one that is reliable, available, protected, efficient and scalable. A secure system is also well documented, with established policies and procedures for dealing with every conceivable situation that might arise in the course of development, deployment, and production operations. For instance, a secure system can be confidently restored from backup when – not “if” – something goes wrong because the DBA has prepared not only backup scripts, but a proven and tested recovery strategy. A secure system can alert you when something isn’t as it should be because monitoring has been considered and planned, and can even react proactively to certain situations to ensure its continued availability. In other words, a secure system is one that works predictably and isn’t threatened by the more obvious gotchas of system administration, like those I will be discussing.
In my next post I will look at some of the rules of the road in deploying an Oracle database and how they should be considered in designing your system.