By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The first thing to ensure is that you limit access to the Administrators or Domain Administrators group carefully. I think that's how most people get the escalated privileges that allow them to stop/start services and the like. That is, pay careful attention to *how* you are accessing the server--with what credentials or account. A non-privileged user (not a member of an administrative group) should not be able to stop services.
As for the password file, I think you're right that Oracle doesn't take good care of NTFS file permissions to ensure that files remain secure. I believe that this got a lot better in 9.2, but I still don't think it's perfect. With most of the Windows systems I've worked on, any new files created allow Everyone Full Control. Maybe there's a way to change this default behavior, but I haven't seen it done yet. That said, I don't think that you're required to leave the default permissions as they are. You should restrict permissions to the %OH%database directory and to the password file as well and see how restrictive you can make them without breaking the database server. I don't have any Windows systems to test with, so you'll have to check this one yourself.
You might consider setting remote_login_passwordfile = NONE if you don't require it. I know that on other (non-Windows) platforms, there is no requirement to have a password file in order for the server to function. I don't see why that would be different on Windows.
Finally, your last comment is especially bothersome. I think that no matter what steps you take as the DBA to secure the database and its various files, you should always ensure that the system administrator secures the server as much as possible. Security in the database doesn't help at all if someone can steal the whole server. I think that most of the concerns you describe are things that Oracle maybe could do better, but could easily be addressed by restricting access to the server. Beware that your concerns are valid and it's great that you're thinking about them (not everyone does), but there are also many other potentially easier targets that will be more damaging. For example, if your application has a database super-user that owns all the data and has a password equal to the username. If that's true, you can build the most secure box on the planet and as long as you run a listener, it's still game over.
Dig Deeper on Oracle database security
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.