Tighten Security for an Instance

To provide increased security for an InterSystems IRIS® database, you can and should configure it to more tightly constrain user access. This can prevent unauthorized users from using system tools or from gaining access to sensitive resources. This section describes various actions that reduce the attack surface of a database instance or otherwise increase its security. The section assumes you have already installed an InterSystems IRIS instance with an initial security of Minimal. If you have chosen an initial security of Normal or Locked Down, some of these actions have already been performed for you.

There actions for tightening an instance’s security are presented here roughly in the sequence in which they should be performed:

The InterSystems Security Advisor also provides an automated analysis of the instance and recommendations for actions to increase the security of an instance.

Important:

An InterSystems IRIS database instance has many interdependent elements. Because of this, it is recommended that you only do what is specified for a change, and not more or less. For example, simply removing UnknownUser from the %All role — without doing anything else — will cause problems for a minimal-security installation.

Enable Auditing

The primary elements of security are often described as the “Three A’s”: authentication, authorization, and auditing. Auditing provides two functions:

It provides data about what has occurred if there is a security event.
The knowledge of its existence can be a deterrent for an attacker, given that the attack will be tracked and there will be evidence of any malicious actions.

To enable auditing for key events, the procedure is:

From the Management Portal home page, select System Administration > Security > Auditing > Enable Auditing. If the choice is not available, auditing is already enabled.
From the Management Portal home page, go to Configure System Events page (System Administration > Security > Auditing > Configure System Events).
On the Configure System Events page, enable the following events if they are not already enabled by clicking Change Status in the event’s row:
- %System/%DirectMode/DirectMode — Provides information on console/terminal use. For sites that extensively use command-line utilities, can create large amounts of data. Recommended if increased data is not an issue.
- %System/%Login/Login — Provides information on logins. For large sites, can create large amounts of data. Recommended if increased data is not an issue.
- %System/%Login/LoginFailure — Provides feedback on possible attempted unauthorized logins. Recommended.
- %System/%Security/Protect — Provides data on attempts to read, write, or use protected data. Recommended.

Change the Authentication Mechanism for an Application

A key element of restricting access to the database is configuring the instance to use a stricter authentication mechanism for its applications. This section describes how to perform this procedure, using the Management Portal as an example application and with the change from unauthenticated access (as in a minimal-security installation) to requiring a password as an example of moving to a stricter authentication mechanism.

Important:

Performing the following procedure may affect aspects of the instance being modified beyond access to the Portal. The specifics depend on (1) the instance’s configuration and (2) whether you are performing just this procedure or all the procedures in this section. Specifically:

Making %Service_WebGateway:Use not public means that all users of web applications will need to be granted %Service_WebGateway:Use by some other means.
Removing UnknownUser from the %All role can have many effects.

To provide properly functioning authentication for an application, there must be consistent authentication mechanisms for both the application and any service that it uses. For a web application, the Web Gateway must also be configured to match the Web Gateway service. Hence, to provide authentication for the Management Portal, there are three layers that all need to work together:

The %Service_WebGateway service
The Web Gateway
The Management Portal application

If these layers do not have matching authentication mechanisms, this usually results in a denial of access — for example, there may be a “This page cannot be displayed” error instead of a login page or access to the Management Portal.

Important:

If (1) a web application uses a more powerful authentication mechanism than the Web Gateway and %Service_WebGateway and (2) authentication succeeds, then the system’s security is only that of the less powerful mechanism.

For an instance with a minimal-security installation, the Web Gateway, %Service_WebGateway, and the Management Portal application are all set up for unauthenticated access. To provide password-level authentication for the Portal, various InterSystems IRIS elements must be configured as follows:

The Web Gateway service must require password authentication.
The Web Gateway must provide a username and password for that authentication.
The user representing the Gateway must have sufficient privilege to use the Web Gateway service.
The Management Portal must require password authentication.
All the Portal’s users must have sufficient privilege to use the Portal.

Important:

Complete the following set of procedures during a single session in the Portal. Otherwise, you may lock yourself out of the Portal and have to perform the remaining procedures through the ^SECURITY routine.

An overview of the procedure to make these changes is:

Once this process is complete, then a user’s next attempt to connect to the Portal will result in a login prompt.

Caution:

An InterSystems IRIS database instance has many interdependent elements. Because of this, it is recommended that you only do what is specified for a change, and not more or less. Otherwise, you may lock yourself out of the instance or could even render the instance temporarily inoperative.

Give the %Service_WebGateway:Use Privilege to the CSPSystem User

The InterSystems IRIS installation process creates a CSPSystem user, which represents the Web Gateway in its interactions with the %Service_WebGateway service. Since the service is going to have restricted access, this user needs to hold the %Service_WebGateway:Use privilege for the authentication process.

Note:

There is a service called %Service_WebGateway and a resource called %Service_WebGateway. The resource regulates access to the service. Therefore, to gain access to the service, a user must have Use permission for the resource — that is, the %Service_WebGateway:Use privilege.

To associate the %Service_WebGateway:Use privilege with the CSPSystem user, the procedure is:

From the Management Portal home page, go to the Roles page (System Administration > Security > Roles).
On the Roles page, click Create New Role. This displays the Edit Role page, where the Name field is editable.
Enter a name for the role to include the %Service_WebGateway:Use privilege (such as “GatewayRole”).
Click Save. InterSystems IRIS has now created the role.
In the Privileges section on the General tab of the Edit Role page, click Add, which displays a list of available resources for the role.
From this list, click %Service_WebGateway and then click Save. The newly created role now includes the %Service_WebGateway:Use privilege.
Select the Members tab of the Edit Role page.
On this tab, you can assign the CSPSystem user to the newly created role. Click CSPSystem from the users in the Available list and move it to the Selected by clicking the right arrow.
Click Assign to assign CSPSystem to the role. (In other words, CSPSystem is now a member of the role.) This means that CSPSystem holds the %Service_WebGateway:Use privilege.

Note:

The system creates the CSPSystem user to represent the Web Gateway. If you prefer, a different user can perform this function. This procedure refers only to the CSPSystem user; if you use a different user, replace CSPSystem with that username where relevant.

Change the Password of the CSPSystem User

Because a minimal-security installation gives the CSPSystem user a password of “SYS”, it is important to change this to a new password — one that an attacker would not know or be able to guess. The procedure is:

In the Management Portal, go to the Users page (System Administration > Security > Users).
On the Users page, click CSPSystem. This displays the Edit User page.
Enter the new password for CSPSystem in the Password field. Since no user has to remember this password, you can make it as long and complex as you wish. You will need to remember it long enough to complete the next item, Configure the Web Gateway to Provide a Username and Password.
Reenter the new password in the Password (Confirm) field and click Save. If the Portal does not display an error message or dialog, then the password change has succeeded.

If you wish, you can also confirm that CSPSystem is assigned to the role created for authentication in the previous procedure. To do this, click on the Roles tab. The table with the column heading CSPSystem is Assigned to the Following Roles should list the newly-created role.

Configure the Web Gateway to Provide a Username and Password

Because you are going to configure %Service_WebGateway to require password authentication, the Web Gateway needs to provide a username-password pair. Having set up a user with the appropriate level of privilege, you have established a username-password pair that the Gateway can provide. The next step is to configure the Gateway to provide this username-password pair when the InterSystems IRIS server challenges it for them. The procedure is:

In the Management Portal, go to the Web Gateway Management page (System Administration > Configuration > Web Gateway Management).
On the Web Gateway Management page, select Server Access from the list on the left side. This displays the Server Access frame.
In the Server Access frame, the LOCAL server should be highlighted. Click Submit to edit it, which displays a page with Server Access and Error Pages parameters.
On this page, there is a Connection Security section.
Ensure that the Connection Security Level drop-down has “Password” displayed.
In the User Name field, enter CSPSystem.
In the Password and Password (Confirm) field, enter the password that you selected in the previous section.
Click Save Configuration near the bottom of the page.
To return to the Management Portal, click Back to Management Portal from the bottom of the list in the left pane.

Configure %Service_WebGateway to Require Password Authentication

Now that the Gateway is configured to provide a username and password and you have given the CSPSystem user the necessary level of privilege, the next step is to configure the service that manages web applications (%Service_WebGateway) so that it requires password authentication. The procedure is:

From the Management Portal home page, go to the Services page (System Administration > Security > Services).
On the Services page, click %Service_WebGateway. This displays the Edit Service page for %Service_WebGateway.
On the Edit Service page, under Allowed Authentication Methods, make sure that Unauthenticated access is disabled and that Password access is enabled (also known as “Instance Authentication”). Click Save.

Remove the Public Status of the %Service_WebGateway:Use Privilege

With %Service_WebGateway requiring password authentication and the Gateway able to authenticate with an appropriately authorized user, the next step is to exclude %Service_WebGateway:Use from public availability. The procedure is:

From the Management Portal home page, go to the Resources page (System Administration > Security > Resources).
On the Resources page, in the row for %Service_WebGateway, click Edit. This displays the Edit Resource page for %Service_WebGateway.
In the Public Permission section, clear the Use box. Click Save.

Important:

Once %Service_WebGateway:Use is not a public privilege, only those users who have been explicitly granted it will be able to use web applications. You may need to assemble a list of these users and grant them this privilege through other means.

Configure the Management Portal to Accept Password Authentication Only

Once the connection between the Gateway and the InterSystems IRIS server has a new authentication mechanism, the next task is to configure the Management Portal application to use a matching mechanism. In this example, this mechanism is Instance Authentication. The procedure for changing the Portal’s authentication mechanism is:

From the Management Portal home page, go to the Web Applications page (System Administration > Security > Applications > Web Applications).
On the Web Applications page, the /csp/sys application represents the Management Portal home page. Click the name /csp/sys in this row to edit the application. This displays the Edit Web Application page for the /csp/sys application.
In the Security Settings section, under Allowed Authentication Methods, disable Unauthenticated access and enable Password access. Click Save.
Also disable Unauthenticated access and enable Password access for all the applications that compose the other pages and choices of the Portal. These applications are:
- /csp/sys/exp
- /csp/sys/mgr
- /csp/sys/op
- /csp/sys/sec
Note:

After editing the application /csp/sys/op, you will need to authenticate to make further changes.

This configures the Portal to require password authentication (also known as “Instance Authentication”) and not to allow unauthenticated access, and so that all its parts behave consistently. The next step is to ensure that all relevant users have appropriate access to the Portal.

Specify the Appropriate Privilege Level for the Instance’s Users

When the Portal is configured to accept unauthenticated connections, any user can connect as the UnknownUser. Because a minimal-security installation makes UnknownUser a member of the %All role, there is no danger of being locked out of the Portal. Now that the Portal requires password authentication, its legitimate users need to be members of the %Operator role, the %Manager role, or the %All role.

In a minimal-security installation, SuperUser, Admin, _SYSTEM, and UnknownUser all have this level of privilege; further, these all have passwords of “SYS”.

Note:

In a normal or locked-down installation, the UnknownUser is enabled, but is not assigned any roles.

In a normal or locked-down installation, passwords are set in the installation process, but you can choose to change them again here.

To properly secure users, the procedure is:

Either disable UnknownUser or remove UnknownUser from the %All role.
- To disable UnknownUser, the procedure is:
  1. On the Users page (System Administration > Security > Users), click UnknownUser under the Name column. This displays the Edit User page for UnknownUser.
  2. Clear the User Enabled field and click Save.
- To remove UnknownUser from the %All role:
  1. On the Users page (System Administration > Security > Users), click UnknownUser under the Name column. This displays the Edit User page for UnknownUser.
  2. Go to the Roles tab on the Edit User page.
  3. In the User UnknownUser is Assigned to the Following Roles table, on the %All row, and click Remove.
Important:

Limiting access through UnknownUser can have widespread effects, particularly if an instance’s users are not sufficiently privileged.
Ensure that any other potentially unauthorized users are not members of %All, %Developer, %Manager, %Operator, %SQL, or any user-defined role that grants privileges. This involves a process analogous to removing UnknownUser from the %All role.
(A user-defined role that grants privileges might have Use permission on any of the %Admin... resources, %Development, or any of the %Service or %System resources, or Write permission on %DB_IRISLIB or %DB_IRISSYS.)
Ensure that any user who should have access to the Portal is assigned to %All, %Developer, %Manager, %Operator, %SQL, or any user-defined role that grants Portal access. The procedure, for each of these users, is:
1. On the Users page (System Administration > Security > Users), click the name of the user under the Name column. This displays the Edit User page for that user.
2. Go to the Roles tab on the Edit User page.
3. Move the desired role(s) from the Available to the Selected list by selecting the role, clicking the right arrow button, and then clicking Assign to assign the user to the role(s).
Change the passwords for SuperUser and Admin users from the default and disable the accounts. To do this:
1. On the Users page (System Administration > Security > Users), click the name of the user under the Name column. This displays the Edit User page for that user.
2. Click Enter new password.
3. Enter the new password in the Password field.
4. Confirm it in the Password (confirm) field.
5. Clear the selection for User enabled and click Save.
Note:

InterSystems IRIS requires at least one enabled account with the %All role. InterSystems recommends creating a unique user with the %All role and disabling the SuperUser, Admin, and _SYSTEM users.

Important:

Make sure that you know the password for at least one user who administers the Portal. Otherwise, you may lock yourself out of the Portal and have to log in using emergency access so that you can reset one or more passwords using the ^SECURITY routine.

Make the Class Documentation Available

Once you finish configuring the service, the Web Gateway, and the Portal application, you may wish to ensure that the class documentation program is available. The procedure is:

From the Management Portal home page, go to the Web Applications page (System Administration > Security > Applications > Web Applications).
To make the documentation available:
1. On the Web Applications page, the /csp/documatic application represents the class reference application. Click /csp/documatic in this row to edit the application. This displays the Edit Web Application page for the /csp/documatic application.
2. In the Security Settings section, under Allowed Authentication Methods, disable Unauthenticated access and enable Password access. Click Save.
  
  Note:
  
  In a normal installation, password access is already enabled.

If you do not perform this procedure, the service requires a password prompt but the application attempts to use unauthenticated access. This prevents all users — including those assigned to %All — from reaching the documentation.

Begin Enforcement of New Policies

At this point, the InterSystems IRIS instance is fully configured to operate properly. However, all existing connections are still using unauthenticated access. To begin enforcement of the new policies, the following events must occur:

Establish an Authenticated Web Gateway Connection

To force the Web Gateway to establish an authenticated connection, the procedure is:

From the Management Portal home page, select System Administration > Configuration > Web Gateway Management. This displays the Web Gateway Management page.
On the Web Gateway Management page, select Close Connections from the list on the left side. This displays the Close Connections frame.
Click Close Connection(s). This displays a message indicating that all connections between the Gateway and InterSystems IRIS server have been closed.

The next time that a user requests a page, the Gateway will reestablish a connection to the InterSystems IRIS server. This connection will use the selected authentication mechanism.

Establish Authenticated User Connections

At this point, all connections to the Management Portal are still using unauthenticated access. If there is no pressing need to require authenticated access, then there is nothing else to do. Users will gradually end their connections to the Portal and will have to authenticate when they reconnect. (Connections may be ended due to machine reboots, stopping and restarting browsers, clearing browser caches, Portal logouts, etc.)

If there is a need to force connections to use authenticated access, you can stop and restart InterSystems IRIS. For example, on Windows, if you have InterSystems IRIS available through the default Start menu page:

From the Windows Start menu, select Programs > InterSystems IRIS, then the InterSystems IRIS instance to restart.
On the submenu for the instance of InterSystems IRIS, choose Stop InterSystems.
On the dialog that appears, select Restart and click OK.

Note:

If you are using a production instance of InterSystems IRIS, you may want to choose a low-traffic time for the restart, since users will temporarily not have access to either InterSystems IRIS as a whole or the Portal.

Limit the Number of Public Resources

Any resource can be specified as a public resource. This means that any user has the ability to read, write, or use the resource, depending on its public settings. The following should always be public:

Required Public Resources and Their Permissions

Resource	Permission
%DB_IRISLOCALDATA	R
%DB_IRISLIB	R
%DB_IRISTEMP	RW

To tighten the security of an instance, limit the number of public resources. To do this, the procedure is:

Ensure that all users who genuinely require access to these resources have been given privileges for them.

Important:

If you do not provide privileges for %Service_WebGateway:Use to the appropriate users, then this procedure can result in a widespread lockout from the Management Portal and other web applications.
From the Management Portal home page, go to the Resources page (System Administration > Security > Resources).
On the Resources page, each resource for which there is one or more public permissions has those permissions listed in the Public Permissions column of the table of resources. Select the resource by clicking Edit. This displays the resource’s Edit Resource page.
On the Edit Resource page, clear any checked Public Permission fields and click Save. The resource is no longer public.

Perform this procedure for all public resources.

Restrict Access to Services

There are various pathways by which users can interact with InterSystems IRIS. Services regulate access to these pathways. To limit access to InterSystems services, the available choices are:

Limit the number of enabled services to only those required for the applications in use
Limit the number of public services to only those required for the applications in use
Restrict access to services by IP address or machine name

Limit the Number of Enabled Services

To limit the number of enabled services, the procedure is:

Determine the required services for the InterSystems IRIS instance. Typically, these are:
- Whatever service is required for each form of user access
- Whatever services are required for any automated access
- Either %Service_Console (on Windows) or %Service_Terminal (on UNIX®), for local programmer-mode access
From the Management Portal home page, go to the Services page (System Administration > Security > Services).
On the Services page, for each service that is not required, select the service by clicking on its name. This displays the service’s Edit Service page.
On the Edit Service page, clear the Service Enabled field and click Save. The service is now disabled.

Once you have disabled all unnecessary services, the only pathways to InterSystems IRIS are the required services.

Limit the Number of Public Services

Each service is associated with a resource. In most cases, the resource has the same name as the service, such as %Service_WebGateway; the exception to this is the %Service_Bindings service, which is associated with the %Service_Object and %Service_SQL resources. Services are public because of the settings for the resources associated with them. Because of this, the procedure for making a service non-public is the same as for making any other resource non-public. This is described in Limiting the Number of Public Resources.

Restrict Access to Services by IP Address or Machine Name

For certain services, you have the option of restricting access to the service according to IP address or machine name. This is known as the ability to limit “allowed incoming connections.” The services that support this feature are:

%Service_Bindings
%Service_CacheDirect
%Service_ECP
%Service_Monitor
%Service_Shadow
%Service_WebGateway

By default, a service accepts connections from all machines. If a service has no associated addresses or machine names, then it accepts connections from any machine. If one or more addresses or machine names are specified from which a service accepts connections, then the service only accepts connections from these machines.

This feature is not available for %Service_CallIn, %Service_ComPort, %Service_Console, %Service_DataCheck, %Service_Login, %Service_Mirror, %Service_Telnet, and %Service_Terminal.

To restrict access to a service by IP address, the procedure is:

Determine the IP addresses of those machines with legitimate access to the service.
From the Management Portal home page, go to the Services page (System Administration > Security > Services).
On the Services page, for each service for which you are restricting access by IP address, select the service by clicking on its name. This displays the service’s Edit Service page.
On the Edit Service page, in the Allowed Incoming Connections section, click Add New.
In the displayed dialog, enter an IP address for an allowed incoming connection. Click OK.
Click Add New and enter other addresses as needed.

Perform this procedure for each service that is restricting the IP addresses from which it accepts connections.

Limit Remote Privileged Access

InterSystems IRIS supports ECP remote job requests. However, a remote job runs as root on the server, which could allow a user to operate on the server with more privileges than intended. To disable handling of remote jobs and limit remote privileged access on the server, follow the procedure in Changing This ParameterOpens in a new tab to set netjob to false. This setting is true by default.

Limit the Number of Privileged Users

Every instance of InterSystems IRIS must have at least one user who is assigned to the %All role. In fact, if there is only one user assigned to this role, then InterSystems IRIS prevents the user from being removed from the role. However, over time, an instance can end up having more users assigned to %All than are necessary. This can arise from assigned users leaving an organization but their accounts not being disabled, from temporary assignments not being revoked, and so on.

Along with the %All role, the system-defined roles of %Manager, %Developer, %Operator, and %SQL can give users undue privilege. There also may be user-defined roles that do this. Users assigned to such roles are sometimes known as “privileged users.”

To limit the number of privileged users, determine which users are assigned to each privileged role and remove those who are not needed. The procedure is:

From the Management Portal home page, go to the Roles page (System Administration > Security > Roles).
On the Roles page, click the name of the role. This displays the Edit Role page for that role.
On the Edit Role page, click the Members tab, which displays a list of the users and roles assigned to the role.
To remove any user from the specified role, click Remove on the row for the user or role to be removed.

Perform this procedure for each privileged role, including %All and the others listed previously. It is also important to disable the _SYSTEM user; the procedure for this is described in Disabling the _SYSTEM User.

Important:

Certain seemingly non-privileged roles may have what could be called “privileges by proxy.” This occurs when a seemingly non-privileged role is assigned to a privileged role. In this case, any user who is assigned to role with privileges by proxy holds all the privileges associated with the privileged role.

Avoid creating privileges by proxy whenever possible. When not possible, have as few users as possible assigned to the roles with privileges by proxy.

Disable the _SYSTEM User

The InterSystems IRIS installation program creates the _SYSTEM user. This user is created in accordance with the SQL standard as the SQL root user. In a minimal-security installation, the default password for this user is “SYS”; in normal and locked-down installations, the default password is whatever was selected during the installation process. Because this user and the password of “SYS” are both publicly specified by the SQL standard, and because of this user’s SQL privileges, disabling _SYSTEM is important for tightening access to an InterSystems IRIS instance.

To do this, the procedure is:

From the Management Portal home page, go to the Users page (System Administration > Security > Users)).
On the Users page, click the name _SYSTEM to open the Edit User page for _SYSTEM.
On the Edit User page for _SYSTEM, clear the User Enabled field. Click Save.

Note:

If you need to check root-level SQL privileges after disabling _SYSTEM, you will have to temporarily enable the user to perform the required action.

Restrict Access for UnknownUser

In instances that support unauthenticated access, connections that do not use authentication are established with the UnknownUser account. In minimal-security installations, the default behavior is that:

All connections use UnknownUser.
UnknownUser is assigned to the %All role.
UnknownUser holds all SQL privileges.

To restrict access for UnknownUser, disable unauthenticated access for all enabled services. (Other actions may not be effective or may result in a lockout from the Management Portal.)

Note:

If you have performed all of the previous actions listed in this section, you may have already disabled UnknownUser and limited the number of public resources.

Potential Lockout Issue with the UnknownUser Account

If an instance has been installed with Minimal security, UnknownUser has the %All role; the instance also has unauthenticated access available for all services and applications. If you simply change the user’s role (from %All to something else) and still allow unauthenticated access, you may be unable to use basic features.

This is because, under these conditions, InterSystems IRIS establishes a connection to the selected tool without performing authentication. When there is no authentication, the system automatically sets the user account to UnknownUser. The next step is to check user privileges. If UnknownUser has insufficient privileges, access to the tool is limited or not available. For example, under these circumstances, the Terminal displays an “Access Denied” message and then shuts down; the Portal displays its main page, but no options can be selected.

To correct this condition:

Start InterSystems IRIS in emergency access mode.
Restore sufficient privileges to the UnknownUser account.

If you wish to prevent use of UnknownUser, you must upgrade the authentication mechanism for the Management Portal.

Configure Third-Party Software

InterSystems products often run alongside and interact with non-InterSystems tools, including virus scanners. For important information about the effects these interactions can have, see Configuring Third-Party Software to Work in Conjunction with InterSystems Products.

Security Advisor

System Management and Security