docs.intersystems.com
Home  /  Security Features of InterSystems IRIS  /  Security Administration Guide  /  About InterSystems Security


Security Administration Guide
About InterSystems Security
[Back]  [Next] 
InterSystems: The power behind what matters   
Search:  


The InterSystems IRIS Data Platform™ provides a simple, unified security architecture with the following features:
InterSystems Security and Different Levels of the Computing Environment
InterSystems security is based on authentication, authorization, auditing, and database encryption:
InterSystems IRIS also supports the use of SSL/TLS and provides tools for a public key infrastructure (PKI).
Note:
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:
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.
About Kerberos
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:
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
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 for 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 for Authentication with 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:
Authorization Basics
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:
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
or
%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:
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:
  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 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 Mechanisms and Role-Assignment Mechanisms
Authentication Mechanism Role-Assignment Mechanisms
Kerberos InterSystems authorization
Delegated authorization (ZAUTHORIZE)
Operating System InterSystems authorization
Delegated authorization (ZAUTHORIZE)
LDAP
Instance Authentication InterSystems 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 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
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 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:
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 InterSystems IRIS databases.
Note:
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:
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
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:
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 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.
InterSystems IRIS 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 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.