| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Looking for Security book
Pete Finnigan <pete_at_peterfinnigan.demon.co.uk> wrote in message news:<Q2zsu3AULER+Ewod_at_peterfinnigan.demon.co.uk>...
> Hi
>
> There are some links on my site also at http://www.petefinnigan.com
>
> HTH
>
> cheers
>
> Pete Finnigan
Pete,
This is a very rough draft of something that I was working on last
Sunday.
As your text is largely an outline and does not necessarily provide
step-by-step instructions as to implementing recommendations (THAT
would be a rather large text) - I figured that I would share this
piece of info with you.
I am in no way complaining that your book does not include instructions as to how to implement all of the recommendations.
These are just my notes from securing a box, and will likely appear as a section in a paper in the near future. The goal was to have the filesystems permissions as restrictive as possible, but still allowing user access to the database, backup jobs to disk to execute (hot, exp, cold, not yet using RMAN).
Its highly likely that the formatting of this will be mangled via the posting mechanism.
HOWTO set directory and file permissions in MS Windows 2000 for use as an oracle database server.
disclaimer:
Please test this on a test server prior to applying to production.
I have not yet attempted to altered the properties of the operating
system volume.
I have not yet altered properties of the registry permissions.
This strategy outlined here will not allow members of the group
administrators to connect to the oracle database(s) using os
authentication, nor will it allow access to the filesystems used by
oracle by users and groups that do not belong to the local group
ORA_DBA.
Of course, a member of the local administrator's group can take
ownership of filesystems, grant groups to an account and take over a
database. These events should be logged, but as the administrator
group member can clear such log events. External logging using a third
party tool may be required.
A future project is the use of the syslog client to an external syslogd server for cross-database reporting.
assumptions:
1. server is not a member of a domain, or active directory forest.
(the workgroup can have an arbitrary name, just not use a domain controller).
2. DBA/SysAdmin has full administrative control of this server. 3. a clean operating system was installed on newly formatted volumes. 4. Any/all service packs and security patches were applied prior toconnecting the server to a network
and filesystems used by all databases on the server. A higher level of granularity could be used whereby each database's files and services would be owned by a different account.
notes:
it is helpful to have a switch/hub available with no other connections
so that network interface cards (NICs) are active during the operating
system install.
If you are preparing multiple servers, it may be helpful to have a
fileserver which has the network operating system, service packs,
patchets, hotfixes, management and application software available for
installation *that is on
a clean network, unconnected to any other network*.
set filesystem attributes
after creating the newly formatted filesystem, right-click on the volume in windows explorer.
select the option "sharing" or "properties". click on the tab "Security". remove the group "Everyone" from the list of users/groups that havepermissions on the object.
click through the messages acknowledging this change.
click the "Add ..." button.
Add the group "ORA_DBA" and the user "ora-owner".
Check the boxes for full control for each listee.
Click on the "Advanced" button.
you will now see the panel "Acces Control Settings for <volume_name>
<drive>".
Click on the check box "Reset permissions on all child objects and
reset propagation of inheritable permissions.
click "Ok".
You will be presented with the message "Security: This will remove
explicitly defined permissions on all child objects and enable
propagation of inheritable permissions to those child objects. Only
inheritable permissions
propagated from RedoB (F:) will take effect.
Do you wish to continue?"
click "Yes".
Click "Ok".
repeat for each volume.
other folders of note:
The folder \Database must be writtten to when a service is created. It also must be read from when a service starts an instance (password file)
grant the following:
ORACLE_BASE\Admin\db_name\
bdump
cdump
pfile
udump
ORA_DBA ORA_OPER ora-owner service system full control X X Modify X X X X Read & Execute X X X X List Folder Contents X X X X Read X X X X Write X X X X
ORACLE_HOME\bin
ORA_DBA ORA_OPER ora-owner service system full control X X Modify X X Read & Execute X X X X X List Folder Contents X X X X X Read X X X X X Write X X
ORACLE_HOME\Database
ORA_DBA ORA_OPER ora-owner service system full control X X Modify X X X X Read & Execute X X X X X List Folder Contents X X X X X Read X X X X X Write X X X X
ORACLE_HOME\Network\Admin
ORA_DBA ORA_OPER ora-owner service system full control X X Modify X X X Read & Execute X X X X X List Folder Contents X X X X X Read X X X X X Write X X X X
ORACLE_HOME\Network\Log
ORA_DBA ORA_OPER ora-owner service system full control X X Modify X X X Read & Execute X X X X X List Folder Contents X X X X X Read X X X X X Write X X X X
NOTE: once a service has been created, it should immediately be stopped, and have its properties modified to run under the authorty of a named account, such as "ora-owner", that belongs to a group that has suitable permissions and privileges.
NOTE: When you edit a service to run under the authority of a named local account, it will automatically grant the account the "logon as a service" right, and will inform you as such.
thoughts, comments appreciated.
Paul Received on Tue Feb 11 2003 - 11:32:07 CST
 |
 |