About Caché Security

Caché provides a simple, unified security architecture with the following features:

It offers a strong, consistent, and high-performance security infrastructure for applications.
It meets certification standards.
It makes it easy for developers to build security features into applications.
It places a minimal burden on performance and operations.
It ensures that Caché can operate effectively as part of a secure environment and that other applications and Caché can work together well.
It provides infrastructure for policy management and enforcement.

Caché Security and Different Levels of the Computing Environment

Caché security is based on authentication, authorization, auditing, and database encryption:

Authentication verifies the identity of all users. It is described in the section “Authentication: Establishing Identity.”
Authorization ensures that users can access the resources that they need, and no others. It is described in the section “Authorization: Controlling User Access.”
Auditing keeps a log of predefined system and application-specific events. It is described in the section “Auditing: Knowing What Happened.”
Managed key encryption protects information against unauthorized viewing. It is described in the section “Managed Key Encryption: Protecting Data on Disk.”

Caché also supports the use of SSL/TLS and provides tools for a public key infrastructure (PKI).

Note:

Caché SQL security uses the Caché authentication infrastructure. The tools for Caché security authorization are described in this book, while the Caché SQL security authorization system is described in the “Users, Roles, and Privileges” chapter of the Using Caché SQL book.

Authentication: Establishing Identity

Authentication is how you prove to Caché that you are who you say you are. Without trustworthy authentication, authorization is moot — one user can impersonate another and then take advantage of the fraudulently-obtained privileges.

The authentication mechanisms available depend on how you are accessing Caché. Caché has a number of available authentication mechanisms:

Kerberos — The most secure means of authentication. The Kerberos Authentication System provides mathematically proven strong authentication over a network.
Operating-system–based — OS-based authentication uses the operating system’s identity for each user to identify that user for Caché purposes.
LDAP — With the Lightweight Directory Access Protocol (LDAP), Caché authenticates the user based on information in a central repository, known as the LDAP server.
Caché login — With Caché login, Caché prompts the user for a password and compares a hash of the provided password against a value it has stored.
Delegated authentication — Delegated authentication provides a means for creating customized authentication mechanisms. The application developer entirely controls the content of delegated authentication code.

You can also allow all users to connect to Caché without performing any authentication. This option is appropriate for organizations with strongly protected perimeters or in which neither the application nor its data are an attractive target for attackers.

About Kerberos

For maximally secure connections, Caché supports the Kerberos authentication system, which provides a highly secure and effective means of verifying user identities. Kerberos was developed at the Massachusetts Institute of Technology (MIT) to provide authentication over an unsecured network, and protects communications using it against sophisticated attacks. The most evident aspect of this protection is that a user’s password is never transmitted over the network — even encrypted.

Kerberos is what is called a trusted-third-party system: the Kerberos server holds all sensitive authentication information (such as passwords) and is itself kept in a physically secure location.

Kerberos is also:

Time-tested — Kerberos was originally developed in the late nineteen-eighties. Its principal architecture and design have been used for many years at many sites; subsequent revisions have addressed issues that have been discovered over the years.
Available on all supported Caché platforms — Originally developed for UNIX®, Kerberos is available on all Caché-supported variants of UNIX®; Microsoft has integrated Kerberos into Windows 2000 and subsequent versions of Windows. (Note that because the Microsoft .NET framework does not include direct Kerberos support, Caché does not support Kerberos for the Caché Managed Provider for .NET.)
Flexibly configurable — It accommodates heterogeneous networks.
Scalable — The Kerberos protocol minimizes the number of interactions with its Key Distribution Center (KDC); this prevents such interactions from becoming a bottleneck on larger systems.
Fast — As an open-source product, the Kerberos code has been scrutinized and optimized extensively over the years.

Underlying Kerberos authentication is the AES encryption algorithm. AES — the Advanced Encryption Standard — is a royalty-free, publicly-defined symmetric block cipher that supports key sizes of 128, 192, and 256 bits. It is part of the US Federal Information Processing Standard (FIPS), as chosen by United States National Institute of Standards and Technology (NIST).

For detailed content, see “Configuring for Kerberos Authentication” in the “Authentication” chapter.

About Operating-System–Based Authentication

Caché supports what is called operating-system–based (or OS-based) authentication. With operating system authentication, Caché uses the operating system’s user identity to identify the user for Caché. When operating system authentication is enabled, the user authenticates to the operating system using according to the operating system’s protocols. For example, on UNIX®, this is traditionally a login prompt where the operating system compares a hash of the password to the value stored in the /etc/passwd file. When the user first attempts to connect to Caché, Caché obtains the process’ operating system level user identity. If this identity matches a Caché username, then that user is authenticated.

This capability only applies to server-side processes, such as terminal-based applications (for example, connecting through the Terminal) or batch processes started from the operating system. It is not available for an application that is connecting to Caché from another machine, such as when a copy of Studio on one machine is connecting to a Caché server on another.

This mechanism is typically used for UNIX® systems, in addition to the Windows console.

For detailed content, see “Configuring for Operating-System–Based Authentication” in the “Authentication” chapter.

About LDAP Authentication

Caché supports authentication through the Lightweight Directory Access Protocol (LDAP). In this case, Caché contacts an LDAP server to authenticate users, relying on its database of users and their associated information to perform authentication. The LDAP server also controls all aspects of password management, password policies, and so on.

For detailed content, see the “Using LDAP” chapter.

About Caché Login

Caché itself can provide a login mechanism. Specifically, Caché maintains a password value for each user account and compares that value to the one provided by the user at each login. (As with traditional OS-based authentication, Caché stores a hashed version of the password. When the user logs in, the password value entered is hashed and the two hashed versions are compared.) The system manager can configure certain password criteria, such as minimum length, to ensure a desired degree of robustness in the passwords selected by users.

For detailed content, see “Configuring for Authentication with Caché Login” in the “Authentication” chapter.

About Delegated Authentication

Caché supports delegated authentication, which allows you to create your own authentication mechanism. As the application developer, you fully control the content of delegated authentication code. Caché includes a routine, ZAUTHENTICATE.mac, that serves as a template for creating custom authentication code.

For detailed content, see the “Using Delegated Authentication” chapter.

Authorization: Controlling User Access

Once a user is authenticated, the next security-related question to answer is what that person is allowed to use, view, or alter. This determination and control of access is known as authorization. Authorization manages the relationships of users and resources — entities being protected. Resources are as diverse as databases, Caché services (such as for controlling web access), and user-created applications. Each user has one or more roles, each of which authorizes the user to perform particular activities with particular resources Caché provides tools so you can manage each resource, as well as each role’s privileges in relation to each resource.

Caché also supports various role-assignment mechanisms. A role-assignment mechanism allows you to associate particular roles with particular authenticated users. Caché uses these associations to determine the authorized activities for the user. Each role-assignment mechanism is associated with one or more authentication mechanisms; configuring Caché includes specifying the supported combination(s) of authentication and role-assignment mechanisms.

The available role-assignment mechanisms are:

Native authorization — Role assignment occurs within Caché. Available with the Kerberos, OS-based, and Caché login authentication mechanisms.
Delegated authorization (ZAUTHORIZE) — Role assignment occurs as part of the ZAUTHORIZE routine. Available with the Kerberos and OS-based authentication mechanisms.
LDAP — An LDAP (Lightweight Directory Access Protocol) server performs role assignment. Available with the OS-based and LDAP authentication mechanisms.
ZAUTHENTICATE — Role assignment occurs as part of the ZAUTHENTICATE routine. Available with the delegated authentication mechanism, which calls ZAUTHENTICATE.

For a list of authentication mechanisms and role-assignment mechanisms, see the “Authentication Mechanisms and Role-Assignment Mechanisms” table in the “About Role Assignment” section.

Authorization Basics

The fundamental purpose of Caché security is to establish the relationships between users and the resources that they attempt to use.

Resources, Permissions, and Privileges

The primary goal of security is the protection of resources — information or capabilities in one form or another. With Caché, resources can be databases, services, applications, tools, and even administrative actions. The system administrator grants access to these by assigning permissions. Together, a resource and an associated, assigned permission are known as a privilege. This is often described using the following shorthand:

Resource-Name:Permission

where Resource-Name is the specific resource for which permissions are being granted and Permission is one or more permissions being associated with the resource. For example, the granting of read and write permissions on the EmployeeInfo database is represented as:

%DB_EmployeeInfo:Read,Write

%DB_EmployeeInfo:RW

For most resource types, the relevant permission is Use; for databases, the permissions are Read and Write. Granting or revoking this permission enables or disables access to the resource’s action(s).

For most resources, the name of a resource is <resource-type>_<specific-resource>, such as %Admin_Operate, %Service_SQL, or the %DB_SAMPLES database.

Differences between Resources and Assets

Resources differ from assets as follows:

Assets are the items being protected while resources are their logical representation within the Caché security system.
A single resource can protect multiple assets.

Users and Roles

Caché uses Role-Based Access Control (RBAC) for its authorization model. With this type of model, a user gains the ability to manipulate resources as follows:

Resources are associated with permissions to establish privileges.
Privileges are assigned to roles.
Roles have members, such as users.

A user connects to Caché to perform some set of tasks. A role describes a set of privileges that a user holds.

Roles provide an intermediary between users and privileges. Instead of creating as many sets of privileges as there are users, roles allow you to create sets of task-specific privileges. You can grant, alter, or remove the privileges held by a role; this automatically propagates to all the users associated with that role. Instead of managing a separate set of privileges for each and every user, you instead manage a far smaller number of roles.

For example, an application for a hospital might have roles for both a doctor making rounds (RoundsDoctor) and a doctor in the emergency room (ERDoctor), where each role would have the appropriate privileges. An individual user could be a member of just one of the two roles, or of both of them.

Caché comes with a set of pre-defined roles: %Manager, %Operator, %Developer, %SQL, and a role for each of the initially-installed databases; the database-related roles have names of the form %DB_<database-name>.

Caché also comes with a role called %All, which holds all privileges — that is, all permissions on all resources. There is no way to reduce this role’s privileges, and at least one user must always belong to this role.

Each user has an associated $Roles variable, which contains the list of roles held. Once Caché authenticates a user (using one of the mechanisms described in the section “Authentication: Establishing Identity”), it grants that user all associated roles. This set of initially granted roles is known as login roles. A user’s login roles establishes a default value for the $Roles variable. Once logged in, a user may temporarily be a member of additional roles — either from a Caché application or from some part of the Caché system itself; these are reflected in the value of the $Roles variable. The set of roles that a user has at any particular moment is called that user’s active roles. If, at any point, a call sets the value of $Roles to NULL (""), then the value of $Roles reverts to the login roles.

When Caché adds new items to the list of roles in the $Roles variable, this is known as escalating roles. The removal of roles from the list is known as role de-escalation.

About Role Assignment

Role assignment depends on the role-assignment mechanism in use, which, in turn, varies by the authentication mechanism in use:

Authentication Mechanisms and Role-Assignment Mechanisms

Authentication Mechanism	Role-Assignment Mechanisms
Kerberos	Caché authorization
Kerberos	Delegated authorization (ZAUTHORIZE)
Operating System	Caché authorization
	Delegated authorization (ZAUTHORIZE)
	LDAP
Caché login	Caché authorization
LDAP	LDAP
Delegated Authentication (ZAUTHENTICATE)	ZAUTHENTICATE

For an instance that supports unauthenticated access, all users hold the privileges associated with the UnknownUser and _PUBLIC accounts; these accounts are described in the sections “The UnknownUser Account” and “The _PUBLIC Account,” both of which are in the “Users” chapter.

Note:

Regardless of how role assignment occurs, role management — that is, associating particular privileges with particular roles — occurs within Caché.

Resources and What They Protect

At the foundation of any security system is that which it protects. With Caché, resources are being protected. There are a number of kinds of resources and each governs a different key aspect of Caché:

System resources — The ability to perform various tasks for system management, security administration, or application development. See the section “System Resources” for more information.
Database resources — Caché databases, which can be altered or read, and which have executable code that can also be altered or run. See “Database Resources” for more information.
Service resources — Tools for connecting to or among Caché servers. See the section “Service Resources” for more information.
Application resources — User-defined applications, applications that come with Caché, an action in code, or a page in the Management Portal. See the section “Application Resources” for more information.

System Resources

There are several predefined administrative resources:

%Admin_Operate — Controls a set of tasks for system operators. These include:
- Starting and stopping (but not configuring) Caché
- Performing backups
%Admin_Secure — Controls a set of tasks for security administrators. These include:
- User account management
- Role management
- Resource management
- Starting and stopping services
- Database encryption tasks
%Admin_Manage — Controls a set of tasks related to managing a Caché instance. In addition to those listed for %Admin_Operate and %Admin_Secure, these include
- Configuration management
- Adding, modifying, and deleting databases
- Modifying namespace mappings
- Managing backup definition
- Performing database restores
- Performing journal restores
%Development — Controls development tasks and tools, including:
- Using direct mode (the programmer prompt)
- Establishing Studio connections to a server
- Using the global, routine, class, table, or SQL capabilities of the Management Portal.
- Access to global, routine, class, table, or SQL capabilities programmatically
- Caché debugging facilities

For each system resource, the Use permission enables access.

Service Resources

A service controls a user’s ability to connect to Caché. For example, Telnet and ECP each have associated services. Each service can be enabled or disabled. If disabled, no one, regardless of privilege level, can use the service. If enabled, the service’s specified authentication mechanism is used to authenticate the user; once authenticated, the service grants access according to the privilege level specified by the user’s roles. (For services that support multiple authentication mechanisms, these are used in a pre-determined order.)

There are a large number of services available as part of Caché. These include:

Client/server services, such as for SQL
Console, Telnet, and the Terminal (for various kinds of terminal connections)
A CSP connection service (for CSP and Zen web applications)
Networking services, such as ECP

To use a service, you must hold the Use permission on the service’s resource.

Database Resources

A database refers to a physical file that resides in a particular location. A database resource governs one or more Caché databases.

Note:

Caché security does not directly control access to namespaces. Since a namespace can be mapped to multiple databases, there can be different security settings for its different underlying parts.

For database resources, there are two permissions available:

Read — Allows viewing but not modification of content, and also running of routines
Write — Allows viewing and modification of content

The Manager’s Database

For each Caché instance (that is, each separately installed copy of Caché), there is a database called CACHESYS, which contains routines and globals required to administer the instance. This database is also known as the manager’s database.

Because of the powerful tools available in the manager’s database, it is necessary to carefully control access to it. Data and routines in it can affect the operation of Caché itself; therefore, to protect the instance as a whole, access to it should be carefully restricted.

Application Resources

Application resources can protect a number of different kinds of assets, all of which are associated with either user-defined applications or applications that come with Caché, and can include entire applications, individual actions in code, or pages in the Management Portal.

For the purposes of Caché security, an application is a software program or group of Caché routines. To protect applications, Caché supports what is called an “application definition.” You can associate an application definition with an Application resource (that is, a resource of type Application); this allows you to establish a privilege that regulates its use. Any role that holds the privilege is entitled to run the application.

There are three types of application definitions:

A privileged routine application definition is associated with one or more Caché routines.
A web application definition is associated with a specific Caché Server Pages (CSP) or Zen application.
A client application definition is associated with one or more specific executable programs, which have been created as clients for a Caché server.

For example, Caché comes with the DocBook web application for displaying documentation; if you are reading this in a browser, then you are using the DocBook application right now. For more information on applications, see the “Applications” chapter.

In addition to using Application resources to protect the application as a whole, you can also use these resources to perform authorization for a particular piece of code or with a particular Portal page. For more information on adding authorization code into an application, see the section “Checking Privileges” in the “Privileges and Permissions” chapter; for more information on authorization checks for a particular Portal page, see the section “Using Custom Resources with the Management Portal” in the “Resources” chapter.

For More Information on Authorization

For more information on authorization, see the following chapters in this book: “Assets and Resources,” “Privileges and Permissions,” “Roles,” and “Users.”

Auditing: Knowing What Happened

Auditing provides a verifiable and trustworthy trail of actions related to the system. Auditing serves multiple security functions:

It provides proof — the proverbial “paper trail” — recording the actions of the authentication and authorization systems in Caché and its applications.
It provides the basis for reconstructing the sequence of events after any security-related incident.
Knowledge of its existence can serve as a deterrent for attackers (since they know they will reveal information about themselves during their attack).

The auditing facility allows you to enable logging for various system events, as well as user-defined events. Authorized users can then create reports based on this audit log, using tools that are part of Caché. Because the audit log can contain sensitive information, running an audit report itself generates an entry for the audit log. The included Caché tools support archiving the audit log and other tasks.

Caché Auditing System

For more information on auditing, see the “Auditing” chapter.

Managed Key Encryption: Protecting Data on Disk

The purpose of authentication is to ensure that Caché users are who they say they are. The purpose of authorization is to control access to data through Caché. The purpose of auditing is to keep a record of what has happened during interactions with Caché and its data. In addition to this, there is the need to prevent unauthorized access to data on disk. To protect against such access, Caché provides managed key encryption, a suite of technologies that protects data at rest. This suite includes block-level database encryption, data element encryption for applications, and encryption key management.

The tools protect data at rest — that is, they secure information stored on disk — by preventing unauthorized users from viewing this information. Caché implements encryption using the AES (Advanced Encryption Standard) algorithm. Database encryption and decryption occur when Caché writes to or reads from disk, and the information handled includes the data itself, indices, bitmaps, pointers, allocation maps, and incremental backup maps. Data element encryption is supported by a set of methods that allow an application to encrypt and decrypt content as desired. And, underlying the encryption tools are key management tools that allow for simple creation and management of data encryption keys and the key files that contain them.

Those experienced with encryption systems for databases may have concerns about encryption having dire effects on performance, but, with Caché, these concerns are unfounded. Encryption and decryption have been optimized, and their effects are both deterministic and small for any Caché platform; in fact, there is no added time at all for writing to the database.

For more information on these tools, see the chapter “Managed Key Encryption.”

Managing Security with the Management Portal

To manage security for a Caché instance, use the Management Portal. From the Management Portal home page, the System Administration menu includes submenus for Security and Encryption. The Security submenu contains choices for managing the Caché instance as a whole, including users, roles, services, resources, auditing, and the security properties of any applications defined for the Caché instance. The Encryption submenu contains choices related to the technologies of managed key encryption: database encryption, data element encryption, and encryption key management.

Notes on Technology, Policy, and Action

Caché can play a significant role in providing security. However, it constitutes only part of a computing environment. To properly and fully secure that environment, Caché must be part of a solution that employs other security products and tools (such as firewalls and the security features of operating systems). This is why the security features in Caché are designed to successfully interoperate with those of other products.

Also, although Caché can do much to prevent attacks and misuse of data, it cannot do the entire job. If a user goes to lunch with a Terminal window open, your organization’s data is vulnerable to attack.

And while technology can solve many security problems, it cannot teach users to behave responsibly. An organization must define clear policies that specify what can, cannot, and must be done. Further, it must educate its members in how to follow these policies and why. Without such an action, all the security in Caché and other products will do no good; with such an action, Caché can be part of a secure and productive environment.

A Note on Certification

Security certifications are a frequent requirement for government purchases, and are increasingly requested for private sector purchases. Effective February 15, 2007, Caché received certification according to the Common Criteria standard (EAL 3).

Common Criteria standard provides a set of common security standards for a wide and growing number of nations around the globe. It provides an evaluation assurance scale with levels from 1 to 4 (EAL), where a product’s rating indicates the rigor of evaluation to which it has been subjected; commercially available products are rated from one (least rigorous) to four (most rigorous). Caché is certified at EAL 3. Such a level indicates that Caché can effectively serve as part of a highly secure operational environment.