Choose passwords carefully   Never deploy databases that use the default user ID and password. See Security considerations: Passwords.

Restrict use of super-users   Avoid creating and granting roles that possess all privileges, roles, and administration rights (that is, avoid super-users). Instead, create roles with logical groupings of privileges and rights, and then grant those roles judiciously. If you do create super-users, consider using them only when absolutely necessary, and store their passwords in a secure location, such as a safe, so that you can retrieve them when needed. See Super-users.

Consider giving your database administrators two user IDs: one with all privileges and one with limited privileges, so they can connect to the one with all privileges 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 database server option and Creating secure feature keys.

Drop external system functions   The following external functions present possible security risks:

The email system procedures allow users to have the database server send email composed by the user. Malicious users could use either the email or command shell procedures to perform operating-system tasks with permissions 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 PROCEDURE statement.

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

Protect your database software   Protect your SQL Anywhere software from unauthorized access. Only give users access to the applications, DLLs, and other resources they require.

Run the database server as a service or a daemon   Prevent unauthorized users from shutting down or gaining access to the database or log files, by running the database server as a Windows service. On Unix, running the server as a daemon serves a similar purpose. See How to run the database server as a service or daemon.

Set SATMP environment variable to a unique directory (Unix)   Make the database server secure on Unix platforms, by setting 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. 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. See SATMP environment variable.

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. See -ep database server option and -ek database option.

Adjust the -xs server option HTTP and MaxRequestSize protocol option   Adjust the -xs server option HTTP{ TO, KTO, and MaxRequestSize protocol option }. See -xs database server option.

Set the request_timeout to ensure that no one request can consume server resources indefinitely   Set the request_timeout database option to ensure that no single request can consume server resources indefinitely. See request_timeout option.

Secure the disk sandbox feature   If disk sandboxing is turned on, then database file operations are restricted to the directory where the main database file is located and any subdirectories of this directory. See:

• Disk sandboxing
• -sbx database server option
• -sbx database option
• sa_server_option system procedure

Starting and stopping databases   When using a personal database server (dbeng16), by default any user can start an extra database on a running server.

By default, network database servers (dbsrv16) require the SERVER OPERATOR system privilege to start a database on a running database server. The -gd database option allows you to limit access to this option to users with a certain level of privileges in the database to which they are already connected.

Creating and deleting databases   When running a personal database server (dbeng16), by default any user can use the CREATE DATABASE statement to create a database file.

By default, network database servers (dbsrv16) require the SERVER OPERATOR system privilege to create databases. The -gu option allows you to limit access to this option to users with a certain level of privilege in the database to which they are connected.

Stopping the server   The dbstop utility stops a database server. It is useful in batch files, or in other cases where stopping the server interactively (by clicking Shut Down on the database server messages window) is impractical.

By default on personal database servers (dbeng16), any user can run dbstop to shut down a server.

On network database servers (dbsrv16), the default setting requires the SERVER OPERATOR system privilege to stop a database server. The -gk option allows you to limit access to this option to users with a certain level of privilege in the database.

Loading and unloading data   The LOAD TABLE, UNLOAD TABLE, and UNLOAD statements all access the file system on the database server computer. The -gl database server option allows you to control the database privileges required to perform loading and unloading of data. The default setting is all for personal database servers ( dbeng16) on non-Unix operating systems. The default setting is DBA for the network database server and the Unix personal server. If you are running the personal database server, you already have access to the file system and this is not a security issue. If you are running the network database server, unwarranted file system access may be a security issue.

Using transport-layer security (TLS) to encrypt client/server communications   For greater security of network packets, you can use transport-layer security to authenticate communications between client applications and the database server. Transport-layer security uses RSA encryption technology.

Disabling database features   The -sf database server option specifies a list of features that are disabled for databases running on the database server so they are not available to client applications or stored procedures, triggers, or events defined within the databases. This can be useful when you are starting a database that is not your own that may contain unwanted actions, such as a virus or trojan.