Zen Security
Zen provides security both at the relational database level for SQL-based applications and at the file level for Btrieve applications that call the MicroKernel engine. Data access can be secured by authenticating users through the operating system, through an Active Directory account, or as a Zen database user. Once user identity is verified, user rights are authorized by operating system or Active Directory rights groups or by Zen database rights defined at the user or group level.
The following topics explain these security models and how to work with them, followed by a topic covering Zen data file encryption capabilities.
Security Models for the Relational Engine
Zen offers SQL applications the authentication and authorization configurations shown in the following table.
Database Security
Authentication
Authorization
Level of Security
Disabled
Operating system
User name and password for server connection
Unrestricted
Owner names (optional)
None. All tables are accessible through SQL connections.
Local database
Zen users
User name and password, unrelated to operating system or domain
Zen user rights (if no group)
Zen group rights (if no user rights)
PUBLIC rights
Owner names (optional)
Databases
Tables
Table columns
Stored procedures (if V2 format)
Views (if V2 format)
Windows domain
Active Directory users
User name and password
Users assigned to domain groups named after Zen database groups
Zen group rights (required)
PUBLIC rights
Owner names (optional)
No individual user rights
Same as local database
By default, database security is disabled when you create a new database. You enable it by entering a password for its Master user, which is created when security is turned on. For information about allowed passwords, see Identifier Restrictions.
After enabling security for a database, you must create any users or groups needed to configure the permissions for various database activities. For local database security, you can assign permissions directly to users, or you can assign permissions at the group level and then assign users to a group. For Windows domain security, you create only groups, using the same names as rights groups in which network users are members. You can manage users and groups for each database using ZenCC or SQL scripting.
You can also configure permissions in the built-in PUBLIC group, which applies to all users connected to the database. Permissions for any user are a combination of either user or group permissions and those in the PUBLIC group. The PUBLIC group in a new database has no permissions set and does not need any settings if all permissions are managed at the group or individual user level.
The following topics explain these concepts in more detail:
Master User
Enabling Zen database security creates a user named Master, who has full access to the database. The Master user requires a password, which you set when you enable security. Master passwords can differ among databases and are not connected. To make changes to the security configuration for a database, you must provide the Master password, so be sure to remember it.
After you authenticate yourself as Master for a database, you can use ZenCC to create users for that database, create groups to assign them to, and manage data access permissions at both the group and user level. You can also execute SQL statements to create groups and then users within those groups. A user can be a member of only one of the groups you create. All users automatically become members of the PUBLIC special group in each database.
The PUBLIC Special Group
If you want to grant the same permissions to all users, you can grant them to a special group named PUBLIC. The database engine automatically creates the special group PUBLIC when you turn on security. Initially, no permissions are assigned to PUBLIC. Until you assign PUBLIC permissions or create users and groups with their own permissions, access to Zen data is blocked.
PUBLIC is a special group that provides default permissions for all users. Even if you assign a user to another Zen group, that user remains a member of PUBLIC. A couple of examples help to clarify how PUBLIC permissions apply. Suppose in ZenCC that you assign the CREATE TABLE permission to PUBLIC. You then create a user named myuser whose permissions in ZenCC do not include individual rights to create a table. Myuser can create a table because the database engine first checks default permissions in PUBLIC, and PUBLIC, in this case, grants rights to create a table.
Conversely, if a permission is not granted to PUBLIC, then the permission granted to the individual user or group applies. For example, suppose in ZenCC that you do not assign the CREATE TABLE permission to PUBLIC. No user can create a table unless the permissions for the user, or the group to which the user belongs, allow creating a table.
Users and Groups
After you enable local database authentication, you can manage permissions for users and groups for the database. For Windows domain authentication, you can manage only group permissions, since user membership is assigned in Active Directory. Zen Explorer in ZenCC displays the users and groups you can work with in either case. The following table lists the general rules that apply to users and groups.
Rules for Users and Groups
Local Database
Windows Domain
A user is not required to be a member of a group and can have individual permission settings.
X
N/A
All users in a group have the permissions defined for that group.
X
X
When a user is a member of a group, that user has no individual permissions.
X
X
The permissions of a user unite with permissions of the PUBLIC group.
X
N/A
The permissions of a group unite with permissions of the PUBLIC group.
X
X
A user can be a member of only one group at a time, not counting the PUBLIC group.
X
X
A group cannot be a member of another group.
X
X
For more information, see User and Group Tasks in Zen User’s Guide.
SQL and Zen Security
If you manage Relational Engine security through SQL scripting, the following topics in SQL Engine Reference provide useful information:
GRANT
REVOKE
Accessing Data in More Than One Database
A SQL application may access data from more than one database in a single connection if the databases are on the same machine. However, since you can be logged in to only one database at a time, your access to another database where you are not logged in depends on the security settings of both databases.
Security for Logged-in Database
Security for Second Database
Access to Second Database
Security enabled
None
Access granted with all rights.
Security enabled
Security enabled
Database uses same user name and password as logged-in database.
Access granted for rights defined in second database.
Security enabled
Security enabled
Database uses different user name and password as logged-in database.
Access denied.
None
Security enabled
Access denied.
Security Models for the MicroKernel Engine
Zen offers Btrieve applications the authentication and authorization configurations shown in the following table.
Btrieve Security
Authentication
Authorization
Classic
Operating system
User name and password
File system rights
Owner names (optional)
Database, secured by local database
Zen users
User name and password, unrelated to operating system or domain
Zen user rights
Zen group rights (optional)
PUBLIC rights (optional)
Owner names (optional)
Database, secured by Windows domain
Active Directory users
User name and password
Users assigned to domain rights groups with same names as Zen database groups
Zen group rights (required)
PUBLIC rights (optional)
Owner names (optional)
No individual user rights
Mixed
Operating system or domain
User name and password
Individual user rights, if using local database security
Group rights (required if using Windows domain security)
PUBLIC rights (optional)
Owner names (optional)
The following topics explain these configurations in more detail:
These topics apply only to applications that directly call the MicroKernel Engine. The terms credentials, login credentials, or user credentials refer to a valid user name and password.
Zen database authentication and authorization for the MicroKernel Engine can be configured to be dependent on or independent of the operating system. You can allow Btrieve users access to the database without allowing them operating system access to the data files.
Classic Btrieve Security
Classic security is the Btrieve security model provided in all releases of the database. For Btrieve users, authentication is performed by the operating system, and data access privileges are determined by file system rights for the given user. Users have the same kinds of rights to access a file through Btrieve that they have for other types of files controlled by the operating system.
Btrieve owner names can add another layer of security by restricting access to individual files. For more information, see Owner Names.
Setting Up Classic Btrieve Security
Under Classic security, you set up application users and access permissions simply by creating operating system users and assigning permissions to files and directories. You do not need to take other actions.
Mixed Btrieve Security
Mixed Btrieve Security provides access to Btrieve data files without giving the user operating system file permissions. You can use this option in environments where you are strengthening security and are unable to modify your Btrieve application to use API login or a URI to specify a file.
In the Mixed security model, when a Btrieve open request occurs, the database engine authenticates the operating system user against the users in a special database called DefaultDB. If the operating system finds the user, then the database engine uses the rights table for the database to determine the user's access to the file to be opened. Thus, permissions for users must be defined within the database they need to use. The database engine enforces its permissions regardless of operating system permissions.
Database authorization for Btrieve applications is provided by extending the Relational Engine security model so that it also can be used for Btrieve applications. The ability to create and define users and groups and set their permissions is provided in ZenCC and through SQL statements such as GRANT, REVOKE, ALTER GROUP, CREATE USER, ALTER USER, and DROP USER.
Under the Mixed security model, local database authentication and Windows domain authentication differ slightly. For local database authentication, any user names defined in the DefaultDB database must be the same as those defined in the operating system. During a Btrieve file create or open operation, the database engine passes the entered user name and password to the operating system for authentication. If the operating system authenticates the credentials, then the database uses the user's individual permissions or the permissions of his or her assigned group. Instead of defining permissions for each user or group, you can define them once using the PUBLIC group.
Under Mixed security with Windows domain authentication, group names in Active Directory must be the same as groups defined in the database, but user membership is handled only in Active Directory. During a Btrieve file create or open operation, the database engine passes the user name and password entered by the user to the network for authentication. If the network authenticates the credentials, then the database uses the user's group assignment to determine permissions. You do not need to add users to the database, and in fact, the Users node in ZenCC is no longer displayed. As an alternative to defining permissions for various groups, you can define them once using the PUBLIC group.
For Mixed security setup procedures, see Setting Up Mixed or Database Btrieve Security.
Notes on Classic and Mixed Btrieve Security
Since the Workgroup engine performs no operating system authentication, the behavior of the Classic and Mixed security policies using the Workgroup engine are the same. If you wish to secure a Btrieve database using the Workgroup engine, you must choose the Database security policy and set up any needed users and groups.
Database Security for Btrieve Files
Database security for Btrieve files requires applications to issue a Btrieve login operation or use a Btrieve URI to specify the file in an Open operation. In either case, a database is referenced in the login or URI. This database provides the permissions for the specified user. Under Btrieve database security, the Zen database authenticates and authorizes users of Btrieve data files either based on users defined locally in the Zen database or based on network logins defined in Windows Active Directory where users are members of rights groups with the same names as groups in the Zen database. With the one exception noted below, the ability of users to connect to and access data is unrelated to file system permissions as long as they can successfully log in to the system where the needed application runs. The ability to define database users and groups and set permissions is provided in ZenCC and through SQL statements such as GRANT and REVOKE.
Note:  To create new databases, a user must have administrator privileges in the operating system.
Notes on Mixed and Database Btrieve Security
You can use the Mixed or Database security models only with Btrieve data files that reside in the directories defined to belong to a given database, including the default database DefaultDB described in The Default Database and the Current Database. Data files residing in directories that have not been associated with a database cannot be accessed.
One of the primary advantages of these security models is the ability to restrict direct user access to the data files while still allowing full access to the data through the database engine. In contrast, under the Classic model, any user permitted to add records to the data file must necessarily also have the ability to copy or delete the data file from the operating system.
Setting Up Mixed or Database Btrieve Security
Migrating to mixed or database security requires that you make a number of choices and plan carefully. In a well-established environment, you may have to plan how your Btrieve files will be grouped together into databases, and schedule the migration so that you do not disrupt your production environment.
For the procedures for moving from the default Classic to Mixed or Database security, see Security Tasks in Zen User’s Guide.
Owner Names
An owner name is a string of bytes used to restrict access to a Btrieve data file. You can think of an owner name as a password that gives access to an individual file. In addition, if Zen encrypts a file, the owner name serves as the private encryption key. Owner names reside in the file header and are always encrypted, whether or not the file is encrypted. As with most passwords, owner names are case-sensitive.
All supported releases of Zen database engines offer the ability to set a "short" owner name of 1–8 ASCII characters for a file. In addition to restricting access, the short owner name is used to apply proprietary encryption when you select the Encrypt File setting in Function Executor or the Encrypt Data in File setting in the Maintenance tool.
Zen 10.10 introduced a "long" owner name of 1–24 ASCII characters, which increased file security and also enabled the use of stronger, 128-bit encryption.
Zen 13.30 added AES-192 encryption and support for long owner names as hexadecimal strings.
Zen 14.00 lengthened long owner names to a maximum of 32 ASCII characters, extended the hexadecimal limit accordingly, and added AES-256 encryption.
The possibilities for long owner names and file encryption are summarized in the following table.
Zen Version
Long Owner Name
File Encryption
14.00
13.0 format
1–32 ASCII characters
32–64 hexadecimal digits, plus 0x or 0X prefix
9.5 format
1–24 ASCII characters
32–48 hexadecimal digits, plus 0x or 0X prefix
Files in 13.0 format with long owner names of 25–32 ASCII characters or 50–64 hexadecimal digits use AES-256 encryption.
Files in 13.0 format with long owner names of 1–24 ASCII characters or 32–48 hexadecimal digits use AES-192 encryption.
Files in 9.5 format with long owner names use 128-bit encryption.
13.30
13.0 format
1–24 ASCII characters
32–48 hexadecimal digits, plus 0x or 0X prefix
9.5 format
1–24 ASCII characters
32–48 hexadecimal digits, plus 0x or 0X prefix
Files in 13.0 format with long owner names use AES-192 encryption.
Files in 9.5 format with long owner names use 128-bit encryption.
10.10 to 13.20
9.5 format
1–24 ASCII characters
Files in 9.5 format with long owner names use 128-bit encryption.
Long owner names in hexadecimal must meet the following requirements:
The owner name string is prefixed with the characters 0x or 0X.
The owner name string uses only hexadecimal digits 0123456789abcdefABCDEF, with no spaces.
No null characters, encoded as 00, are used.
The number of digits for a 13.0 format file must be an even total between 32 and 64, plus the 0x or 0X prefix. The number of digits for a 9.5 format file must be an even total between 32 and 48, plus the 0x or 0X prefix. Note that the prefix serves only to indicate hexadecimal values and is not used by the encryption algorithm.
The following restrictions apply to files with long owner names:
Due to stronger encrypting of owner name strings in Zen v14 or later, a 13.0 format file assigned a long owner name in Zen v14 can be read only in Zen v14 or later. This applies whether or not the file itself is encrypted. Files in 9.5 format do not have the stronger encrypting and are not affected.
Zen before version 10.10 does not support long owner names and cannot read files that have them.
A file can be rebuilt to a file format before 9.5 only after the owner name is removed.
Note:  Owner names have no connection with user names authenticated at the network, system, or database level. For example, the file owner name Master is not the same as the default Master user.
The following topics provide more information:
Choosing and Setting an Owner Name
You can set or clear an owner name on a file in the Maintenance and Function Executor tools. You cannot use SQL scripts to set or manage an owner name for a table, but SET OWNER and GRANT statements can be used to provide an owner name when it is required.
Depending on the options selected when an owner name is assigned, a user can access the file in the ways shown in the following table.
Option
Description
Read-only
Without specifying the owner name, users can perform data access operations that do not modify the data file.
Read-only encrypted
Without specifying the owner name, users can perform data access operations that do not modify the data file. When you set this option, the database engine encrypts every record in the file using the owner name as a key. Records added later are also encrypted.
Normal
Without specifying the owner name, users cannot perform any file access operations.
Normal encrypted
Without specifying the owner name, users cannot perform any file access operations. When you set this option, the database engine encrypts every record in the file using the owner name as a key. Records added later are also encrypted.
Owner Names and SQL Access
If you have a Btrieve owner name set on a file serving as a table in a SQL database, then you can access the table in two ways, depending on whether security is enabled for the database. With no security, the SET OWNER statement provides the owner name before any other attempt to access the table. With security, the Master user of the database must provide the owner name in a GRANT statement to issue permissions for the table to any user, including the Master user itself.
If a file with an owner name is read-only in the operating system, the Master user automatically has SELECT rights on this table without specifically granting itself SELECT rights with the owner name. In this case, other users do not have this automatic access, but the Master user can grant SELECT permission without providing the owner name.
Owner Names and Encryption
When you first set an owner name with encryption on a file, the database engine immediately begins to encrypt the entire file. The larger the file, the longer encryption takes.
Data access operations on an encrypted file are slower than for an unencrypted file. The database engine must decrypt each page as it reads it from disk, and then encrypt it again before writing it back to disk.
Caution!  Do not forget or lose a file owner name. If the file itself is not encrypted, it is still readable through the Btrieve API, but you cannot write to it without the owner name. It is not possible to discover the owner name of a file by examining its contents because the owner name string is always encrypted in the header of the file to which it is assigned, whether or not the file data is encrypted.
Owner Name Examples
For examples of granting access to files with Btrieve owner names, see GRANT in SQL Engine Reference.
Planning Security for the MicroKernel Engine
In every new database, by default the Btrieve security setting is Classic, where the database engine authenticates through the operating system and authorization is based on directory and file permissions. Any user who can access a data file through the operating system has the same level of permission to data records in the file, unless Btrieve owner names restrict access.
The following topics describe the steps to set up the default database, authorized users, and other aspects of the Btrieve security policies:
Available Options
There are three security options available to you. The following table describes the features of these options to help you choose the best one. Encryption is optional in every configuration.
Feature
Classic
Mixed
Database
Administrator must set up separate operating system and database user accounts for each user when local database security is used.
 
X
X
Database user accounts are derived directly from OS user accounts. Always the case when Windows domain database security is used.
X
X
 
Data access rights are unrelated to file system. Administrator must assign data access privileges to each user or group in the database.
 
X
X
User data access rights derive from OS user file system rights.
X
 
 
Supports automatic login dialog for entering database user name and password from any Windows application based on Zen.
X
X1
X
Database accepts successful OS login as valid database user.
X
X
X2
User must log in to database separately from logging in to computer.
 
 
X3
1 The login dialog may appear if the requester cannot establish an identity through the operating system.
2 For database secured using Windows domain authentication.
3 For database secured using local database authentication.
Under Btrieve Database security plus Relational local database security, database user accounts are completely unrelated to operating system user accounts.
In contrast, under Btrieve Classic security, a user who successfully logs into the computer has access to the database contents, at whatever level of file system rights that the user has been assigned to the file that contains the data.
Lastly, the Btrieve Mixed security policy has aspects of both of the other policies. Under this scheme, users log in using their operating system user names and passwords, but then the users access rights to the data are governed by user or group permissions set up in the secured database.
Choosing Your Policy
The following topics capture some of the major reasons you might choose one security policy over another.
Reasons to Choose Classic
You are comfortable with users having file system access to data files. For example, any user with rights to delete records from the data file can also delete the entire file from your operating system.
You want the minimum administrative hassle; you don't want to set up both OS user accounts for each user and at least one database account.
You do not need to have a variety of data access rights that vary from each user's file system rights.
You don't want your users to have a separate login for the database.
Reasons to Choose Mixed
You have existing Btrieve applications that cannot be changed to use a Btrieve login or a Btrieve URI path for opening files.
You don't want your users to have a separate login for the database.
You want to prevent valid database users from having any rights to the data files on the operating system. For example, you can prevent users who have all rights in the database from having rights to delete data files from the operating system.
You are using local database security and are willing to set up database user accounts that have the same user names as OS user accounts, and you are willing to assign permissions to each database user or to his or her group. If you choose, all of your users can have the same level of permissions by inheriting them from the special group PUBLIC.
You are using Windows domain security and are willing to set up rights groups in Active Directory with the same names as Zen groups defined in the database, with permissions assigned to each Zen group. No permissions are assigned in Active Directory, only group membership for users.
Reasons to Choose Database
You have Btrieve applications that use the Btrieve login operation or Btrieve URI path formats.
You want to have a separate login for the database. That is, after logging into the operating system, users must log in again to the database. This behavior is useful when some authorized computer users are permitted access to the database and some are not.
You want to prevent valid database users from having rights to the data files on the operating system. For example, you can prevent users who have all rights in the database from having rights to delete data files from the operating system. You can also achieve this goal using the Mixed security policy.
You want database user accounts that use different names than the operating system accounts. For example, operating system user jsmith might be required to log in to the database as john.
The users and their permissions stay with the database, not with the server or machine. This allows you to move a database from one machine to another without having to recreate the users and their permissions for the database.
Preparing to Set Up Security
Setting up security for the MicroKernel Engine is a simple process, but it affords enough flexibility that some preparation is necessary. This section describes the information you should know before you begin to set up Btrieve security.
How Do Your Btrieve Applications Access Data?
If your applications have been or can be changed to use Btrieve login operations or open files with URIs, then you can choose either Database or Mixed Btrieve security and in both cases the database to be secured is registered in ZenCC. If your applications do not use Btrieve logins or URIs, then you can manage access by choosing Mixed and configuring the DefaultDB database.
How Many Databases?
For Mixed or Database security, you must either assign all users the same level of permissions, or create a set of defined users for each database.
In some cases where your Btrieve data files encompass two or more completely unrelated bodies of data, you may want to set up two or more separate databases, each with its own set of authorized users. Generally speaking, however, you want to minimize the number of separate databases so that you do not have to create and maintain multiple sets of defined users. Often, a single database is sufficient. User permissions within the database will allow you to regulate each user's access to the database, so you do not need to create separate databases just to limit certain users' access.
If you determine that you need only one database, you may use the preexisting database, DefaultDB, as the database associated with your Btrieve files. You may also set up your own named database instead.
Where Are the Data Files?
You associate a Btrieve data file with a database by specifying the directory containing the data file as a Data Directory for the given named database. Thus, you need to know the directories containing all the data files that you want to associate with the database. If all the data files reside in a subdirectory of a specific directory, all you need to know is the top-level directory path name. You can even use "C:\" if you wish to include all data files on the hard drive.
What Are the User Names?
If you plan to use Mixed security with local database authentication, you must either assign all users the same permissions, or set up user accounts for the users whose rights differ. If you are going to set up individual users, you must have a list of the operating system user names that you want to make into database user names. The database user names must match their operating system counterparts exactly.
If you plan to use Mixed security with Windows domain authentication, you must either assign all users the same permissions in the PUBLIC group or set up different Zen groups for users whose rights differ. In both cases, you must have a list of the network group names that you want to duplicate as database group names. The database group names must match their network counterparts.
What Security Policy?
Before you set up security, you must know what policy you plan to use. The setup process varies somewhat for each policy. Considerations in choosing a policy are presented in Choosing Your Policy.
Process Overview
The following high-level steps outline how to set up security for a database. More detailed instructions are provided in MicroKernel Engine Security Quick Start.
1. Preparation. As described in Preparing to Set Up Security, gather the information you need and make the decisions necessary to get started. How many databases? Where are the Btrieve files located? What are the user names? What security policy will you use?
2. Select a database to use with your Btrieve files, and populate the database with the data directory specifying the location of your data files. This step is only necessary for Mixed or Database security.
3. Turn on security.
For details on this step, see To turn on security using Zen Explorer in Zen User’s Guide.
4. Create users or groups as needed and set their permissions using SQL statements or ZenCC. This step is necessary only for Mixed or Database security.
For the fastest, easiest way to grant users access, see To assign permissions to all users using Zen Explorer in Zen User’s Guide.
5. Set the Btrieve Security for your database to Mixed or Database.
For details on this step, see To set or change the security policy for a database in Zen User’s Guide.
6. Secure the data files in the operating system. For Mixed or Database security, users now can access the data without having any rights to access the data files in the operating system. Refer to your operating system documentation for information on securing access to files.
Summary of Tasks for MicroKernel Engine Security
The following table illustrates the basic level of effort required using the different security models. The tasks required to implement the security models, see Security Tasks in Zen User’s Guide.
Security Model
Authentication/Authorization
Summary of Behavior and High-Level Setup Tasks
Classic
Operating system/Operating system
Give users file permission access to all database files.
Add an owner name to Btrieve files to further limit access (optional)
Mixed
Operating system/Database
Set up users in the operating system. Users will be authenticated against these user names and passwords.
Set up like-named users in the database using the ZenCC. Although the OS authenticates, the database stores permissions, so OS users or domain groups must match users or groups in the database.
Define user or group permissions using ZenCC or SQL statements. Alternatively, define a set of rights for the group PUBLIC. Each authenticated user will have the same rights as PUBLIC. No user can have rights defined that are lower than that of PUBLIC.
For the Workgroup engine, this security model behaves like Classic.
Database
Database/Database
Operating system user names and passwords are unrelated to Zen database security.
Define users or groups using ZenCC or SQL statements.
Define database permissions using ZenCC or SQL statements.
MicroKernel Engine Security Quick Start
This section provides step-by-step instructions on the fastest, easiest way to secure your Btrieve data files in the operating system while still allowing database users to access the data.
When this procedure is complete, you can revoke operating system user rights to the data files without affecting database user rights to access the data through an application.
Note:  You must be logged into the computer where the database engine is installed, as an operating system user with administrative rights or as a user who is a member of the Zen_Admin security group.
1. Start Zen Control Center (ZenCC). For how to start ZenCC, see Starting ZenCC on Windows in Zen User’s Guide.
2. If you are using Mixed security, then the database to use in the following steps is DefaultDB. If you are using Database security, then make sure your database is registered in ZenCC. For how to register a database engine, see To register a remote server engine in Zen User’s Guide.
3. Click the expand icon to the left of the node for the database you are using, whether DefaultDB or the database for your application.
4. In ZenCC, right-click the database DefaultDB, then click Properties.
5. Click Directories then click New.
6. Type a path for the Btrieve files then click Apply.
If your files are spread over many directories, specify a high-level directory that they all have in common. You can specify a root level if necessary, but doing so includes in DefaultDB all Btrieve files at the root level and its subordinate directories. For example, a root level could be C:\ for Windows. See To use an existing database, including the predefined DefaultDB, with your Zen files in Zen User’s Guide.
You do not need to enter every directory, just the lowest level directory that is common to all Btrieve files you want to include in the database.
7. Enable security on the database by clicking the Security node in the Properties tree.
8. Select the Btrieve Security tab and choose Mixed or Database security.
9. Select the Database Security tab and choose local database or Windows domain authentication.
10. Enter a password to use for the Master user, twice as prompted.
Security is now turned on, but access is based on OS user rights by default, so your users currently have the same access that they had before. The next step addresses this situation.
Note that passwords are limited to a maximum of 8 bytes. You may use any displayable character in a password except for the semicolon (;) and the question mark (?).
11. Click OK to close the Properties dialog.
12. Expand the Groups for your database (click the expand icon to the left of the node), then right-click the group PUBLIC.
13. Click Properties then Permissions in the tree.
14. Click the Database tab.
15. Click the desired permissions.
For example, if you want to grant read-only rights to all authenticated users, click Select. This option will give all users read-only rights to the data. To give all users update permission, click Update, and so forth.
If you need to grant individual users varying rights, then you must create group accounts (if using domain authentication) or individual user accounts (if using local database authentication) using the GRANT statement in SQL or using ZenCC. For more information, see Security Tasks in Zen User’s Guide.
16. Click OK.
17. Secure the data files in the operating system according to your operating system instructions. You can now deny operating system users from having any rights to the data files, without affecting their ability to access the data through the database engine.
Caution!  Be sure to secure the data files in the operating system. If you do not perform this step, the users still can access the files through the operating system with the same level of permissions that they had prior to this procedure. You must revoke the users' operating system privileges to the data files if you want to prevent users from being able to delete or modify the files directly.
Data Encryption Over Networks
Zen supports the encrypting of network traffic between Zen and the applications that call it. This type of encryption is often called wire encryption because it protects the data when it is traveling on the network wire, or on any network infrastructure, including wireless. While the use of wire encryption is not required, it provides additional deterrence against unauthorized access to the data transmitted by your application.
Zen wire encryption is not tied to any particular security model. All Zen security configurations can be used with or without turning on wire encryption. The rest of this topic covers the following:
Configuration Properties for Wire Encryption
Two configuration settings are associated with wire encryption. The settings must be configured for each client machine as well as for the server. For more information on these settings, see the following:
To access wire encryption settings
1. In ZenCC, do one of the following:
For a server, right-click the server name under the Engines node. You can click the plus signs to expand the nodes.
For a client, right-click MicroKernel Router under the Local Client node.
2. Click Properties.
3. Click Access in the tree.
Wire Encryption Notes
To perform data encryption before data passes over the network, Zen uses Blowfish, a well-known and time-tested public domain algorithm, implementing its 40-, 56-, and 128-bit keys. Encryption using a 40-bit key provides the least amount of protection for the data. Encryption using a 56- or a 128-bit key is progressively more difficult to compromise.
As with all security using encryption, the greater the deterrence, the slower the performance, since some amount of processor time is needed to perform encryption and decryption.
Backward Compatibility
Earlier versions of Zen that did not support wire encryption are unable to communicate with a client or server from a later release that provides encryption. Any client or server that does not support encryption will return an error if it attempts to connect to a client or server that is using encryption.
Setting Up Encryption
Before turning on the encryption settings in your environment, first think about your encryption needs. You can select from four possible schemes for your encryption environment, depending on your situation:
No encryption
All communications encrypted
Encryption to/from specific clients
Encryption to/from specific servers
No Encryption
First of all, consider whether your data has characteristics that would favor encryption. Is your data confidential or proprietary? Is it valuable in the hands of unauthorized users? Can it be used to harm your organization? If you answer no to these question and others like them, then your data may not need to be encrypted at all. Under these circumstances, there may be no reason to incur the performance trade-off that encryption requires. If you aren't sure, talk to a data security expert.
Assuming your data does need to be protected, you still may not need encryption. If your applications run solely on a LAN, and you are comfortable with the existing security of your network, encryption may not provide any additional benefit.
Encryption to/from Specific Clients
Now suppose that you have one major customer at a remote site that has a connection to your database. You may wish to use encryption only for the communications that go to/from that remote client. You can achieve this affect by setting Wire Encryption at the remote client to Always and setting the server values accessed by that remote client to If Needed. All your internal clients would be set to Never. Thus, the servers will only use encryption when communicating with the remote client that requires encryption.
Encryption to/from Specific Servers
Now, suppose the situation is reversed and your environment includes one or more remote servers that are accessed by network infrastructure that you do not trust 100%. In this case, you can set those server values to Always, and set the local client values to If Needed. The result is encrypted communications only to those remote servers that require it.
All Communications Encrypted
Finally, if your Zen applications often run over WAN, VPN, or other external networks that you do not trust 100%, then you may wish to encrypt 100% of your database communications. In this scenario, you would set Wire Encryption to Always at all clients and servers.
Choosing an Encryption Level
Once you have decided which clients and servers require encrypted communications, you must decide what level of deterrence is appropriate for your needs.
While Actian Corporation cannot offer advice regarding the encryption level that meets your specific needs, we can provide some guidelines to help inform your discussions with an appropriate data security expert. These guidelines do not represent a guarantee or warranty from Actian Corporation that no third party will be able to intercept and/or decode your encrypted data. As with any encryption scheme, there is no such thing as an "unbreakable" code, only varying levels of difficulty to compromise different types of encryption. The 128-bit encryption used by Zen would be considered very difficult to decode using techniques and equipment available to a highly sophisticated individual hacker.
Low (40-bit) Encryption
Consider using this level of encryption in cases where your data has limited ability to harm your organization or your customers if it falls into the wrong hands. Another reason to consider a Low level of encryption is if you wish simply to prevent a casual observer on your network from being able to read your data as it travels over the wires.
Medium (56-bit) Encryption
Consider using this level of encryption in situations where you believe you need somewhat more protection than against just a casual observer, but you do not believe you require the strongest level of security.
High (128-bit) Encryption
Consider using this level of encryption in situations where your data contains very sensitive information such as credit card numbers, social security numbers, financial account numbers, or other information protected by law. Especially consider this level of encryption if your database is associated with an entity on the network that is well-known to contain sensitive data, such as an Internet shopping website or an online securities brokerage website. Consider this level of encryption if your organization has previously suffered attempts to compromise its data security.
Effects of Encryption
Using encryption reduces client-server performance. With encryption turned on, each piece of data must be encoded at the source and decoded at the destination. This process requires additional CPU cycles when compared to the same operations performed without encryption. The level of encryption should not affect the performance. The performance drop in using encryption is roughly the same no matter which of the three encryption levels you choose.
Encryption of Files on Disk
Zen also offers encryption of a data file when it is written to disk. To use this feature, you must set an owner name for the file and choose the encryption option. For more information, see Owner Names.
 
Last modified date: 10/31/2023