About InterSystems Security
InterSystems IRIS® data platform 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 InterSystems IRIS can operate effectively as part of a secure environment and that other applications and InterSystems IRIS can work together well.
It provides infrastructure for policy management and enforcement.
InterSystems 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.”
InterSystems SQL security uses the InterSystems IRIS authentication infrastructure. The tools for InterSystems security authorization are described in this book, while the InterSystems SQL security authorization system is described in the “Users, Roles, and Privileges” chapter of the Using InterSystems SQL book.
Authentication: Establishing Identity
Authentication is how you prove to InterSystems IRIS 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 InterSystems IRIS. InterSystems IRIS 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 InterSystems IRIS purposes.
LDAP — With the Lightweight Directory Access Protocol (LDAP), InterSystems IRIS authenticates the user based on information in a central repository, known as the LDAP server.
Instance Authentication — With Instance Authentication, InterSystems IRIS 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 InterSystems IRIS 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.
For maximally secure connections, InterSystems IRIS 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 InterSystems IRIS platforms — Originally developed for UNIX®, Kerberos is available on all InterSystems IRIS-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, InterSystems IRIS does not support Kerberos for the InterSystems IRIS 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 Kerberos Authentication” in the “Authentication” chapter.
About Operating-System–Based Authentication
InterSystems IRIS supports what is called operating-system–based (or OS-based) authentication. With operating system authentication, InterSystems IRIS uses the operating system’s user identity to identify the user for InterSystems IRIS. 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 InterSystems IRIS, InterSystems IRIS acquires the process’ operating system level user identity. If this identity matches an InterSystems IRIS 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 InterSystems IRIS from another machine, such as when a copy of Studio on one machine is connecting to an InterSystems IRIS server on another.
This mechanism is typically used for UNIX® systems, in addition to the Windows console.
For detailed content, see “Configuring Operating-System–Based Authentication” in the “Authentication” chapter.
About LDAP Authentication
InterSystems IRIS supports authentication through the Lightweight Directory Access Protocol (LDAP). In this case, InterSystems IRIS 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 Instance Authentication
InterSystems IRIS itself can provide a login mechanism. Specifically, InterSystems IRIS 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, InterSystems IRIS 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 Instance Authentication” in the “Authentication” chapter.
About Delegated Authentication
InterSystems IRIS 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. InterSystems IRIS 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, InterSystems 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 InterSystems IRIS provides tools so you can manage each resource, as well as each role’s privileges in relation to each resource.
InterSystems IRIS also supports various role-assignment mechanisms. A role-assignment mechanism allows you to associate particular roles with particular authenticated users. InterSystems IRIS uses these associations to determine the authorized activities for the user. Each role-assignment mechanism is associated with one or more authentication mechanisms; configuring InterSystems IRIS includes specifying the supported combination(s) of authentication and role-assignment mechanisms.
The available role-assignment mechanisms are:
InterSystems authorization — Role assignment occurs within InterSystems IRIS. Available with the Kerberos, OS-based, and Instance 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.
The fundamental purpose of InterSystems 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 InterSystems IRIS, 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:
Assets are the items being protected while resources are their logical representation within the InterSystems security system.
A single resource can protect multiple assets.
Users and Roles
InterSystems IRIS 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 InterSystems IRIS 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.
InterSystems IRIS 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>.
InterSystems IRIS 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 InterSystems IRIS 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 an InterSystems IRIS application or from some part of the InterSystems IRIS 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 InterSystems IRIS 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 Mechanism||Role-Assignment Mechanisms|
|Delegated authorization (ZAUTHORIZE)|
|Operating System||InterSystems authorization|
|Delegated authorization (ZAUTHORIZE)|
|Instance Authentication||InterSystems authorization|
|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.
Regardless of how role assignment occurs, role management — that is, associating particular privileges with particular roles — occurs within InterSystems IRIS.
Resources and What They Protect
At the foundation of any security system is that which it protects. With InterSystems IRIS, resources are being protected. There are a number of kinds of resources and each governs a different key aspect of InterSystems IRIS:
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 — InterSystems IRIS 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 InterSystems IRIS servers. See the section “Service Resources” for more information.
Application resources — User-defined applications, applications that come with InterSystems IRIS, an action in code, or a page in the Management Portal. See the section “Application Resources” for more information.
There are several predefined administrative resources:
%Admin_Operate — Controls a set of tasks for system operators. These include:
Starting and stopping (but not configuring) InterSystems IRIS
%Admin_Secure — Controls a set of tasks for security administrators. These include:
User account management
Starting and stopping services
Database encryption tasks
%Admin_Manage — Controls a set of tasks related to managing an InterSystems IRIS instance. In addition to those listed for %Admin_Operate and %Admin_Secure, these include
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 Terminal)
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
InterSystems IRIS debugging facilities
For each system resource, the Use permission enables access.
A service controls a user’s ability to connect to InterSystems IRIS. 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 InterSystems IRIS. These include:
Client/server services, such as for SQL
Console, Telnet, and Terminal (for various kinds of terminal connections)
A web connection service (for web applications)
Networking services, such as ECP
To use a service, you must hold the Use permission on the service’s resource.
A database refers to a physical file that resides in a particular location. A database resource governs one or more InterSystems IRIS databases.
InterSystems 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 InterSystems IRIS instance (that is, each separately installed copy of InterSystems IRIS), there is a database called IRISSYS, 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 InterSystems IRIS itself; therefore, to protect the instance as a whole, access to it should be carefully restricted.
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 InterSystems IRIS, and can include entire applications, individual actions in code, or pages in the Management Portal.
For the purposes of InterSystems security, an application is a software program or group of InterSystems IRIS routines. To protect applications, InterSystems IRIS 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 InterSystems IRIS routines.
A web application definition is associated with a specific web pages.
A client application definition is associated with one or more specific executable programs, which have been created as clients for an InterSystems IRIS server.
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 InterSystems IRIS 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 InterSystems IRIS. Because the audit log can contain sensitive information, running an audit report itself generates an entry for the audit log. The included InterSystems IRIS tools support archiving the audit log and other tasks.
For more information on auditing, see the “Auditing” chapter.
Managed Key Encryption: Protecting Data on Disk
The purpose of authentication is to ensure that InterSystems IRIS users are who they say they are. The purpose of authorization is to control access to data through InterSystems IRIS. The purpose of auditing is to keep a record of what has happened during interactions with InterSystems IRIS and its data. In addition to this, there is the need to prevent unauthorized access to data on disk. To protect against such access, InterSystems IRIS 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. InterSystems IRIS implements encryption using the AES (Advanced Encryption Standard) algorithm. Database encryption and decryption occur when InterSystems IRIS 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 InterSystems IRIS, these concerns are unfounded. Encryption and decryption have been optimized, and their effects are both deterministic and small for any InterSystems IRIS 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 an InterSystems IRIS 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 InterSystems IRIS instance as a whole, including users, roles, services, resources, auditing, and the security properties of any applications defined for the InterSystems IRIS 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
InterSystems IRIS can play a significant role in providing security. However, it constitutes only part of a computing environment. To properly and fully secure that environment, InterSystems IRIS 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 InterSystems IRIS are designed to successfully interoperate with those of other products.
Also, although InterSystems IRIS 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 InterSystems IRIS and other products will do no good; with such an action, InterSystems IRIS can be part of a secure and productive environment.