Caché Security Administration Guide
About Caché Security
[Home] [Back] [Next]
InterSystems: The power behind what matters   

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

Caché Security and Different Levels of the Computing Environment
Caché security is based on authentication, authorization, auditing, and database encryption:
Caché also supports the use of SSL/TLS and provides tools for a public key infrastructure (PKI).
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:
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:
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:
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:
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:
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:
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:
  1. Resources are associated with permissions to establish privileges.
  2. Privileges are assigned to roles.
  3. 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
Delegated authorization (ZAUTHORIZE)
Operating System Caché authorization
Delegated authorization (ZAUTHORIZE)
Caché login Caché authorization
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.
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
There are several predefined administrative resources:
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:
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.
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:
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:
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:
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.

Send us comments on this page
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA