Security

The database service provides different options to allow you perform database operation securely. The security features includes:

 Standard login authentication: The server does UNIX style login and allow multi-level access control settings. Each operation is validated against the user assigned rights.

 SSL Support: The server support standard SSL 3.0. All data sent to user is encrypted using public/private keys when enabled. The server also uses SSL to communicate among Dynamic Server Group (DSG).

 Data Encryption using secret keys: The server can also use secret key when communicate within a DSG.

User Authentication

Setting the Authentication to 1 in the server configuration file enables user authentication. The server response with a standard HTTP challenges which instruct user browser to ask for user name and password. The user must have an account in the server in order to get database services.

User Groups

A user group represents a group of users who has special privileges. User group is granted access rights in the server configuration file. Access right is represented by a single character. For instance, r means read, w mean write, etc. You can define any number of groups in the server configuration file. A user is assigned to a user group when an account is created.

Similarly, each database access operation has access rights attached to it. The rights in a user group must cover all rights required by an operation. For example, Administrator group (s) has the read, write and execute privilege, and the regular user group (u) has only read privilege, e.g.,

@s=rwe

@u=r

If an update operation requires read (to display the original record) and write (to write the changed record),

@update=rw

Then the regular users update request will failed because insufficient access rights. But the administrator's request will be processed.

Which letter to use for representing an access right is insignificant as long as the same letter is also attached to the required operation. This scheme is very flexible because it allows you to designate special access rights or change privilege requirements very easily.

Password File

There is a password file created in the config directory. The file contains all user information including encoded passwords. You should not manually modify the file at any time because the server calculates a digital digest of the file dynamically. The digest wouldn't match if the file is modified.

The password file can be manipulated through admin services using a WEB browser. The following operations are available:

 Add New User

 Revoke User

 Change Password

 Create New User File

An Administrator's password is required for all the operations (See password for further information about these operations). For initial installation, the administrator's password can be found in the readme.txt file. You should change the password after successful installation.

Window NT authentication

In Windows NT environment, the server uses user accounts on the local machine if the authentication above failed. The server then impersonates the security context in the thread that is handling the request. In other words, you could use Windows NT security system for the service authentication. However, you should be very carefully planning access control because the server will no longer verify user privileges for individual resources. For example, an authenticated Windows NT user may be able to access administration functions offered by the server.

Database Server Authentication

In the client/server environment where database server performs its own authentication. The server sends the same user name and password to connect to the specified database. In other words, the user needs not only have an account on this server, but also on the database server (Such as ORACLE and SQL Server). The ODBC database connection will fail if such an account is not established.

Using SSL

In order to use SSL, you needed to obtain a signed certificate from a Certificate Authority. The server will use SSL if

 The ServerCertificate is set to a valid certificate in the server configuration file.

 The certificate file is passed as one of the command line parameter, -cert CertFileName.

The certificate file name should not contain any directory. The server looks for all certificate files under the certs subdirectory.

If you need to verify client certificate, you can set the verification mode using the command line parameter, -VerifyMode nMode

Where nMode is an integer value (See command line option for details, or using command line option -? for help.)

 

Server Secret

Server secret is used in between-server communications. The server supports Dynamic Server Group, which is a cluster of servers that offers distributed database services. The physical location of the database is transparent to users. In order to prevent data from being intercepted, the servers use a secret key to encrypt data before sending it through the wire. The receiver can then decrypt the data using the same secret key.

For sensitive data, the following should be enforced:

 Secret Key should be long enough and contain a mix of alphanumerical characters.

 Secret Key should be changed periodically.

 Distributing secret key through a channel other than computer network.

 All servers involved in the DSG should have exactly the same secret.

 The secret key must start with '@' character.

 

When ServerSecret setting is present in the server configuration file, The secret key encryption will be enabled among the DSG. There is a performance penalty for using encryption. You can disable it by comment out the secret key in the server configuration file.

 

 Using Centralized Authentication Server

In the Dynamic Server Group (DSG) configuration, multiple servers may be able to serve the same database request. It may be desirable to use one of the servers as the authentication server for security reasons. All other servers send authentication requests to the authentication server to verify user credentials before serving a request.

An authentication server can be specified in the server configuration file as follows:

AuthServer=AuthenticationHost:port

Where AuthenticationHost is the host name and port is an integer number. Please make sure that Authentication is set to 1 in the configuration file of the authentication server, all users will be granted access otherwise. Users are validated locally if AuthServer is not specified.

The remote authentication server doesn't support Windows NT accounts because it can't impersonate threads on different machines.

 

Related Page 1 | Related Page 2 | Related Page 3