Data security is a concern for everyone. The need to ensure the safety of personal information and to protect vital corporate assets stored electronically is of paramount importance.

Vector has a built-in hierarchical security system that any privileged user can use to fully control access to the database.

Security in Vector is provided through the following features:

Vector installations can be administered in compliance with the C2 security standard, as defined by the United States Government National Computer Security Council (NCSC). Level C2 security requires individual logon with password and an audit mechanism.

Vector provides a variety of security methods. The default method is DBMS Authentication.

Except for DBMS Authentication, all these methods are performed before the connection is made to the DBMS Server.

The NULL, INGRES, KERBEROS, and AES mechanisms are listed under the Security component in Configuration-By-Forms (or Configuration Manager, if available). The default configuration setting for security mechanisms rarely needs to be changed. Multiple mechanisms are supported concurrently.

The DBMS Authentication method is controlled in Configuration-By-Forms, DBMS Server component, dbms_authentication.

Databases are protected from user access by the permissions on the directories containing the database files and the permissions on the database files themselves. Users cannot look at the files in a database except through Vector. Even in Vector, files are protected from access except from the privileged accounts. The binary files are in a special format, making decoding of any information difficult.

For each Vector user, a user object must be defined in the master database.

Vector authenticates users:

Ingres Net allows access to databases on local or remote nodes. Users can only access data for which they are authorized.

Ingres Net can be configured to allow users access to remote nodes directly (through an installation password) or by providing a user name and password. The user name and password can be authenticated by the DBMS (if the server has DBMS authentication enabled), or against a local OS user account. The password is encrypted as it is sent across the network.

Ingres Net allows you to set up an Installation Password to authorize access to a server installation from a remote client installation without setting up an operating system account on the server; the user retains his identity as defined on the client instance.

The main advantage of using installation passwords is that users on the client do not require a login account on the server.

A valid Vector user object must be created in the master database using the same operating system user ID as on the remote client. OS authentication is done on the remote client, where the user must have a login and password.

For details of Ingres Net setup, see the Connectivity Guide.

In some environments, Vector uses the ingvalidpw program to validate user passwords. Ingvalidpw is used depending on the requirements of the platform where the password is validated. For example, the DBMS Server uses the ingvalidpw program to validate shadow passwords on Linux or to enforce C2 security in some Linux environments.

Ingvalidpw is used for authentication against OS users; it is not used when DBMS authentication is enabled.

Vector allows DBMS level authentication in addition to the other supported methods (which include operating system authentication, installation passwords, and Kerberos authentication). The DBMS authentication feature removes the need to add an operating system user every time a new user needs to access a database.

A user who is appropriately defined in the database can access the database using a valid Vector user name and password. The user does not have to be defined at the operating system level or in a global directory.

DBMS authentication must be enabled for the DBMS Server on which the database resides. It is on by default (dbms_authentication=on in config.dat). Such authentication can be enabled at the server level only, not at the database level.

Database administrators can configure DBMS authentication for each user by using new WITH options on the CREATE USER and ALTER USER statements or by using Actian Director or accessdb.

A user can be defined on the CREATE USER statement as either WITH DBMS_AUTHENTICATION='REQUIRED' or WITH DBMS_AUTHENTICATION='OPTIONAL' (the default).

A user who is defined WITH DBMS_AUTHENTICATION='REQUIRED' must connect to the database using his DBMS user name and password. All other connection attempts will fail. Such a user cannot connect to a server configured as dbms_authentication=no.

System administration users must be defined as DBMS_AUTHENTICATION='OPTIONAL.' All users with the "security" privilege, including the installation owner, are forced to be DBMS_AUTHENTICATION='OPTIONAL'.

If a user is created or altered with DBMS_AUTHENTICATION='REQUIRED', the user must also have a DBMS password or an error is issued. A user defined with no DBMS password can connect to dbms_authentication enabled servers only through a local connection, installation password, or Kerberos authentication.

Users can set and modify their own DBMS passwords if they have the CHANGE_PASSWORD privilege (the default). DBMS passwords are encrypted on disk and when passed over the network.

DBMS authentication is backward compatible. An older remote client will work with new remote dbms_authentication enabled servers assuming that the DBMS password (defined by the CREATE USER statement and stored in iiuser catalog) is compatible with the vnode password.

When an existing installation is upgraded, existing user definitions are modified to DBMS_AUTHENTICATION='OPTIONAL'.

For more information, see the CREATE USER, ALTER USER, and CONNECT statements in the SQL Reference Guide.

Access can be granted to four authorization identifiers.

Identifiers are listed here from highest to lowest precedence, which determines the privilege enforced for a session if a particular privilege is defined for more than one authorization identifier associated with a session.

Subject privileges define the operations a user can perform, and are assigned to a user or a role. Subject privileges include: Auditor, Create Database, Maintain Audit, Maintain Locations, Maintain Users, Operator, Security, and Trace.

Data access can be restricted through the granting of permissions on objects. Permissions can be granted on the following objects: database, table, view, procedure, database event, role, and current installation.

Security alarms can be set up to monitor events against a database or individual tables. Such triggers on important databases and tables are useful in detecting unauthorized access.

Security alarms can monitor success or failure of connecting or disconnecting from a database, and selecting, deleting, inserting, or updating data in a table.

Security alarms can raise a database event (dbevent), which can be monitored by background programs that respond accordingly. Security alarms can be assigned to specific authorization identifiers to limit the monitoring to selected users, groups, or roles.

Security events can be recorded for the entire Vector installation. All objects or certain classes of objects can be targeted. Information in the audit logs can grow quickly, so you should carefully plan what events to audit.

Database procedures provide an extra level of control over data access and modification. Database procedures can be used with security alarms to enhance security auditing.

Specific database table columns can be encrypted to enhance data security, ensure privacy, and protect media that contains database records holding sensitive information. Data in the protected columns is stored on disk or other media in encrypted form and can only be accessed if the encryption passphrase is known.

Data at rest encryption protects table information, transaction information, and full database backups.