Database Security Best Practices

1. Grant privileges only to a user or application which requires the privilege to accomplish necessary work. Excessive granting of unnecessary privileges can compromise security.
2. No administrative functions are to be performed by an application.  For example create user, delete user, grant role, grant object privileges, etc.
3. Privileges for schema or database owner objects should be granted via a role and not explicitly.  Do not use the “ALL” option when granting object privileges, instead specify the exact privilege needed, such as select, update, insert, delete.
4. Password protected roles may be implemented to allow an application to control access to its data.  Thereby, end users may not access the application’s data from outside the application.
5. Access to Administrative or System user accounts should be restricted to authorized DBAs.
6. Do not grant system supplied database roles. These roles may have administrative privileges and the role privileges may change with new releases of the database.
7. Database catalog access should be restricted.  Example: Use “USER_VIEWS” instead of “DBA_VIEWS” for an Oracle database. 
8. Privileges granted to PUBLIC are accessible to every user and should be granted only when necessary.
9. Any password stored by applications in the database should be encrypted.
10. Applications should not “DROP”, “CREATE” or “ALTER” objects within the application.
11. Utilize the shared database infrastructure to share cost whenever possible.
12. Applications should not access the database with the same security as the owner of the database objects. For example on SQL Server do not grant the “dbowner” role and on Oracle do not use the Schema userid to connect to the database. Setup another userid with the necessary privileges to run the application.

Drafted By

Data Architecture