Choose passwords carefully   Do not deploy databases that use the default user ID and password. See Increasing password security.

Restrict DBA authority   You should restrict DBA authority only to users who absolutely require it since it is very powerful. Users with DBA authority can see and do anything in the database.

You may consider giving users with DBA authority two user IDs: one with DBA authority and one without, so they can connect as a DBA user only when necessary.

Use secured database features   The database server -sf option lets you enable and disable features for all databases running on a database server. The features you can disable include the use of external stored procedures, Java, remote data access, and the ability to change the request log settings. See -sf server option and Specifying secured features.

Drop external system functions   The following external functions present possible security risks: xp_cmdshell, xp_startmail, xp_startsmtp, xp_sendmail, xp_stopmail, and xp_stopsmtp.

The xp_cmdshell procedure allows users to execute operating system commands or programs.

The email commands allow users to have the server send email composed by the user. Malicious users could use either the email or command shell procedures to perform operating-system tasks with authorities other than those they have been given by the operating system. In a security-conscious environment, you should drop these functions.

For information about dropping procedures, see DROP statement.

Protect your database files   You should protect the database file, log files, and dbspace files from unauthorized access. Do not store them within a shared directory or volume.

Protect your database software   You should similarly protect SQL Anywhere software. Only give users access to the applications, DLLs, and other resources they require.

Run the database server as a service or a daemon   To prevent unauthorized users from shutting down or gaining access to the database or log files, run the database server as a Windows service. On Unix, running the server as a daemon serves a similar purpose. See Running the server outside the current session.

Set SATMP to a unique directory   To make the database server secure on Unix platforms, set SATMP to a unique directory, and make the directory read, write, and execute protected against all other users. Doing so forces all other connections to use TCP/IP, which is more secure than the shared memory connection.

The shared memory buffers that are used between the client and server are removed from the directory tree before any actual data is sent between the two sides. This means that another process cannot see any of the communication data because the shared memory buffer/file is hidden, and so a process cannot get a handle to it.

Strongly encrypt your database   Strongly encrypting your database makes it completely inaccessible without the key. You cannot open the database, or view the database or transaction log files using any other means.

For more information, see -ep server option and -ek database option.