Management Database Integrity Protection - The Management Software and Database Configuration must ensure that SecureDoc Database Access is secured
While SecureDoc performs an invaluable service ensuring that data is protected by encryption, and that user access to SecureDoc-protected devices is locked down and governed by permitting only specific users to authenticate at Pre-Boot, there are other risks that any security-conscious organization should be aware of and include in its overall security design.

The Management Software and Database Configuration must ensure that SecureDoc Database Access is secured

This means that the recommended database rights and roles are defined for the SecureDoc applications (Server console, ADSync and SDConnex), and that the database itself does not allow login or other access from any other process, service or user.

Generally, applications will either inherit the rights to the database of the user executing the application, or where there are services involved that connect to the database, then the most secure scenario is to create a service account and provide that account only the rights and roles it needs, and only within the context of the database(s) it needs to access.

The primary point of control for such securitization is inside the SQL server itself, so the Database Analyst (DBA) is expected to ensure that:

• There are no extraneous user accounts or service accounts that cannot be accounted for.
• Each account has only the database rights and roles that it needs to perform its own tasks, and only within the context of its own databse(s)
• Each account must be checked to ensure that it has no rights outside the context of its own database needs
• Use of the database engine's SA (System Administrator) account must be avoided in the context of a service or in non-Administrator access to the database engine. This is necessary in part because the SA account usually has far too elevated rights for normal use (and therefore can create damage in the wrong hands), and because its password is passed in cleartext across the network, presenting a risk of being found out using a network sniffer or other monitoring tool.

Where the Database engine is installed within the same server as SecureDoc Enterprise Server, then additional security can be implemented by severely limiting which user accounts are permitted access to that server (for example, which domain accounts are permitted to log in to that server at Windows log on).