This chapter provides an overview of Caché security, with emphasis on the topics most relevant to programmers who write or maintain Caché applications. It discusses the following topics:
This section provides an introduction to security within Caché and for communications between Caché and external systems.
Caché security provides a simple, unified security architecture that is based on the following elements:
. Authentication is how you prove to Caché that you are who you say you are. Without trustworthy authentication, authorization mechanisms are 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. Some require programming effort.
. 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
As a programmer, you are responsible for including the appropriate security checks within your code to make sure that a given user has permission to perform a given task. The authorization model is discussed in more detail later in this chapter.
. Auditing provides a verifiable and trustworthy trail of actions related to the system, including actions of the authentication and authorization systems. This information provides the basis for reconstructing the sequence of events after any security-related incident. Knowledge of the fact that the system is audited can serve as a deterrent for attackers (because they know they will reveal information about themselves during their attack).
Caché provides a set of events that can be audited, and you can add others. As a programmer, you are responsible for include the audit logging in your code for your custom events.
. Caché database encryption protects data at rest it secures information stored on disk by preventing unauthorized users from viewing this information. Caché implements encryption using the AES (Advanced Encryption Standard) algorithm. Encryption and decryption occur when Caché writes to or reads from disk. In Caché, 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 an encrypted database.
The task of database encryption does not generally require you to write code.
When communicating between Caché and external systems, you can use the following additional Caché tools:
. Caché supports the ability to store a SSL/TLS configuration and specify an associated name. When you need an SSL/TLS connection (for HTTP communications, for example), you programmatically provide the applicable configuration name, and Caché automatically handles the SSL/TLS connection.
X.509 certificate storage
. Caché supports the ability to load an X.509 certificate and private key and specify an associated configuration name. When you need an X.509 certificate (to digitally sign a SOAP message, for example), you programmatically provide the applicable configuration name, and Caché automatically extracts and uses the certificate information.
You can optionally enter the password for the associated private key file, or you can specify this at runtime.
Caché uses the CA certificate automatically; no programming effort is required.
Almost all users interact with Caché using applications
. For example, the Management Portal itself is a set of applications. Each application has its own security. There are three kinds of applications in Caché:
these are applications built with the InterSystems tools for front-end development: CSP and Zen. To create these, you create the web pages and you use the Management Portal to register the pages (starting with a particular root path) formally as an application.
Privileged routine applications
these are routines in any supported server-side language. In addition to writing the routine, you use the Management Portal to register it formally as an application.
You can define, modify, and applications within the Management Portal (provided that you are logged in as a user with sufficient privileges). When you deploy your applications, however, you are more likely to define applications programmatically as part of installation; Caché provides ways to do so.
As a programmer, you are responsible for including the appropriate security checks within your code to make sure that a given user has permission to perform a given task. Therefore, it is necessary to become familiar with the Caché authorization model, which uses role-based access. Briefly, the terms are as follows:
. Assets are the items being protected. Assets vary widely in nature. The following items are all assets:
The ability to connect to Caché using SQL
The ability to perform backups
Each application defined in Caché
. A resource is a Caché security element that you can associate with one or more assets.
For some assets, the association between an asset and a resource is a configuration option. When you create a database, you specify the associated resource. Similarly, when you create a Caché application, you specify the associated resource.
For other assets, the association is hardcoded. For a DeepSee KPI class, you specify the associated resource as a parameter of that class.
For assets and resources that you define, you are free to make the association in either manner either by hardcoding it or by defining a suitable configuration system.
. A role is a Caché security element that specifies a name and an associated set of privileges (possibly quite large). A privilege
is a permission
of a specific type (Read, Write, or Use) on a specific resource. For example, the following are privileges:
Permission to read a database
Permission to write to a table
Permission to use an application
Another important concept is role escalation
. Sometimes it is necessary to temporarily add one or more new roles to a user (programmatically) so that the user can perform a normally disallowed task within a specific context. This is known as role escalation
. After the user exits that context, you would remove the temporary roles; this is role de-escalation
You define, modify, and delete resources, roles, and users within the Management Portal (provided that you are logged in as a user with sufficient privileges). When you deploy your applications, however, you are more likely to define resources, roles, and starter usernames programmatically, as part of installation; Caché provides ways to do so.