The IT company I work for is in the midst of an SAS70 security audit. We are a
small company - I share sys admin/db admin/security admin roles with the CIO.
We host client data on our servers, so we had to resolve this very issue.
The bottom line is that one person must ultimately be made responsible if
something happens (me in our case). You cannot protect data from the people who
set permissions on it, period. You can try but you'll end up chasing your tail
(who controls the logs for the admin who controls the logs for the admin who
controls the database...). That means the fewer people who can set permissions,
the easier it is to track what's going on.
If you have one person (say a sys admin) who sets permissions (databases need
to be able to access their own files), that person must be made responsible for
the log files and database. It is their responsibility to make sure the db
admin account doesn't have permissions to write to log files. However, if they
are the ones who set up the account passwords (i.e., the account that your
database runs as), they can still get into the database and do as they please.
This is the case where I work - I know all the passwords, I set all the
permissions, I have all the responsibility if something goes wrong.
In order to get close to what you ask, you'll need at least three roles:
1. Permissions admin - Permissions admin is allowed to set permissions
everywhere (including denying local login to the DB account), but knows only
his own password, and cannot edit account information (like passwords or group
membership). Ultimately responsible for database as he can edit whatever he
wants, but if something happens we know who did it. Single person role.
2. Database admin - Database admin is allowed full access over data *inside*
the database but no write permissions to log files. Database software should
run as a separate account. Hopefully the DBMS prohibits editing or deletion of
log files, otherwise you're back to square one.
3. Accounts admin - Sets up the database user account and knows the password,
but is prohibited from setting permissions or logging into the database.
Hopefully the DBMS forces authentication based on existing credentials (like
Active Directory, for example) and doesn't allow "run-as"-type features,
otherwise the accounts admin can simply log in as dbadmin and go to town. Also,
like I said above, you want your permissions admin to make sure that only real
user accounts can gain local login credentials.
I imagine you could add more roles (log admin perhaps) but again, whoever can
set permissions gets the responsibility.
Derick Anderson
-----Original Message-----
From: Nabil MALIK / KTEFH - OTAS [mailto:NabilM@kuveytturk.com.tr]
Sent: Friday, July 15, 2005 3:18 AM
To: security-management@securityfocus.com
Subject: Segregation of Duities and least priviliges for DB
In order to avoid fraudulent or malicious acts on sensitive data in a database
(DB) , how do we segregate the duties of high privileged employees like DBA
and/or DB Security Administrator. What controls need to be established to
prevent an undesirable change or transaction from a highly privileged employee,
with out being noticed.
Should the DBA and DB security admin be separate personal? For e.g.: The DBA
has rights to modify tables or data, but only security admin can change DB
access control and system/transaction logs. In case if the DBA conducts some
malicious activates, it will be there in the logs which the DBA cannot delete.
On the other side, the DB security admin does not have permission to create
tables and access core data. But then again, the security admin can change his
permissions, do fraudulent acts, and then deleted the logs.. and hence go
un-noticed.
How to deal with the above? Making sure that no one person with high access
rights and can go un-noticed after committing a fraud. Particularly looking for
suggestion for the Database Environment.
Thanks...
Regards,
-Nabil.
DISCLAIMER:
Bu elektronik posta ve ekleri, sadece yukarida ismi yazili alicinin dikkatine
gonderilmistir. Mesajin muhatabi degilseniz, icerigini ve varsa ekindeki
dosyalari kimseye aktarmayiniz ya da kopyalamayiniz. Boyle bir durumda
gondereni uyarip, mesaji imha ediniz. KUVEYT TURK E.F.K. A.S bu e-postanin ve
eklerinin icerdigi bilgilerin size degisiklige ugrayarak ulasmasindan veya gec
ulasmasindan, butunlugunun ve gizliliginin korunamamasindan veya icerigine
güvenilerek yapilacak islemlerden dolayi sorumlu tutulamaz.
This e-mail & its content have been sent to the attention of the receiver named
above. If you are not the intended recipient (or have received this e-mail in
error), Please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this e-mail
is strictly forbidden. Kuwait Turkish Evkaf Finance House shall not be held
liable for the arrival of this e-mail & its content as modified or late, the
protection of integrity and secrecy and shall not be liable to any person who
acts or omits to do anything in reliance upon it.
