EXPERT RESPONSE
You've asked a great question as I've run across many sites that have this
same issue. I'm no Windows expert, but I think that Windows provides
mechanisms to prevent the type of scenario you present. However, it seems
that many sites still treat Windows as a desktop OS and figure that if you can
login to the host at all, then you should have administrative rights.
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.
|
