Caché Security II:

A More Advanced Look At Caché Security

Dave Lutz & Daryl FlamingMarch 2011

Caché Security II

• Caché Security IITechnical level: IntermediateIn this hands-on session, you will learn advanced techniques for configuring secure environments and deployments. Topics include: how to build your own authentication and authorization methods that interface with external components or existing applications, how to incorporate LDAP in your environment, and how to implement 2-factor authentication.Prerequisite: Caché Security I or equivalent knowledge

Welcome/FAQ

• What is the purpose of this academy?

• A ―Hands-On‖, more detailed look at some specific security features.

• For whom is it intended?

• Developers who are familiar with Caché Security.

• Please feel free to ask questions at any time.

• We’ll gladly handle ―in-depth‖ security questions at the end of the Academy.

Academy Agenda

• Review of Caché’s Security Model

• Authentication Using LDAP

• Delegated Authentication

• Two Factor Authentication

• Authorization Using Row-level Security

• Encrypting an Existing Database

• Managing the Audit Log

Review of Caché’s Security Model:

Dave Lutz

Caché Security Components

1. Authentication: verifies the identity of all users

2. Authorization: ensures that users can access the resources that they need, and no others

3. Auditing: keeps a log of pre-defined system and application-specific events

4. Secure Communications: protects network data traffic from eavesdropping, tampering, and message forgery

5. Database Encryption: protects information against unauthorized viewing

LDAP Authentication

Dave Lutz

LDAP Authentication

• Caché provides support for authentication using LDAP

• LDAP: Lightweight Directory Access Protocol

• LDAP systems have a central repository of user information, from which Caché retrieves specific attributes. (Ex. Windows Active Directory is Microsoft’s version of LDAP)

LDAP Authentication - Configuration

The procedure for configuring a Caché service or application to use an existing LDAP server for authentication is as follows:

1. On the LDAP Options page, configure Caché to use the LDAP server. This includes specifying the names of LDAP user properties to be used for setting the values of properties of Caché users.

2. Set up Caché to use LDAP. This involves enabling LDAP for the entire instance of Caché and then enabling it for the relevant services or applications.

LDAP Configuration in Caché

LDAP: Attempting to Authenticate

When a user attempts to authenticate to an instance of Caché that uses LDAP authentication, the process is:

1. The user is prompted for a username and password. This user, who is trying to authenticate, is known as the ―target user.‖

2. Caché establishes a connection to the LDAP server using the values specified for the LDAP username to use and searches for LDAP username password. This user, who has privileges to search the LDAP database so that Caché can retrieve information, is known as the ―search user.‖

3. Once the connection is established, the next step is to look up the user in the LDAP database using the LDAP Unique search attribute.

LDAP: Attempting to Authenticate

4. If Caché locates the target user in the LDAP database, it retrieves all the attributes associated with the user, including the roles to which the user belongs.

5. Caché then attempts to authenticate the user to the LDAP database, using the username and password provided in step 1.

6. If authentication succeeds, the user can then interact with Cachébased on the privileges associated with the user’s roles and any publicly available resources. The user’s properties are displayed read-only in the System Management Portal and are not editable from within Caché (since all the information is coming from outside Caché).

LDAP: intersystems.schema

In 2011.1 the intersystems.schema is available for LDAP.

This defines Caché attributes such as default namespace,

routine and roles programmatically.

# intersystems-Namespace

# The name of the user's default namespace

attributetype ( 1.2.840.113556.1.8000.2448.2.1

NAME 'intersystems-Namespace'

DESC 'Default namespace a user connects to'

EQUALITY caseIgnoreMatch

SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

SINGLE-VALUE )

Exercise #1: LDAP Authentication

We will test the use of LDAP Authentication using OpenLDAP as the LDAP server running Linux as the Operating System.

We will validate a username and password against the LDAP server and return user attributes stored in LDAP.

Delegated Authentication

Daryl Flaming

Delegated Authentication

• User-defined authentication mechanism

• Can be used for both Applications and specific CachéServices as required.

• Re-use existing custom/legacy authentication code for new, modern applications!

Setting up Delegated Authentication

Setting up Delegated Authentication involves the following steps:

1. Create user-defined authentication code in the ZAUTHENTICATE routine.

2. Enable delegated authentication for the Cachéinstance and then the relevant services or applications.

Note: The ZAUTHENTICATE routine can also perform basic setup for a user account, such as specifying roles and other user properties.

Creating User-Defined

Authentication Code

• A system-supplied copy of ZAUTHENTICATE is available in the %SYS namespace in the routine ZAUTHENTICATE.int.

• To use this routine as a template:

1. Open the routine in Studio.

2. From within Studio, save it as a .MAC file in the %SYS namespace.

Note: Saving the routine to a .MAC file preserves it across Caché upgrades, while saving it as an .INT file does not.

3. Edit the routine by adding custom authentication code and any desired code to set user account characteristics

Authentication Code…

• The content of the authentication code inside ZAUTHENTICATE is application specific.

• The authentication code can be any user-defined:

• Caché ObjectScript

• Embedded SQL

• Class Method(s)

• $ZF callout code.

• Caution: Caché places no constraints on the authentication code in ZAUTHENTICATE, the application programmer is responsible for ensuring that this code is sufficiently secure!

Setting User Account Characteristics

• If initial authentication succeeds, ZAUTHENTICATE can establishthe roles and other characteristics for the authenticated user.

• For subsequent logins, ZAUTHENTICATE can update these elements of the user record.

• The following User Account properties must be set/modified in code:

– Properties("Comment") — Any text

– Properties("FullName") — The first and last name of the user

– Properties("NameSpace") — The default namespace for the Terminal login

– Properties("Roles") — A comma-separated list of roles that the user holds in Caché

– Properties("Routine") — A routine that is invoked when the user gains access to the Terminal

– Properties("Password") — The user's password

– Properties("Username") — The user's username

Once Authenticated –

―The State of the System‖

1. Any user who is initially authenticated using Delegated Authentication is listed in the table of users on the Users page ( [System Administration] > [Security] > [Users ] ) as having a type of ―Delegated user‖.

2. If a system administrator has already explicitly created a user through the System Management Portal (or using any other Cachéfacility), that user is a ―Caché password user‖.

3. If a ―Caché password user‖ attempts to login using Delegated Authentication and is successfully authenticated by the ZAUTHENTICATE code, Caché determines that this user already exists as a Caché user — not a Delegated user — and so login fails!

From Authenticated to ―Logged In‖

• ―Logging in‖ stipulates that:

– Authentication was successful using any of the supported authentication methods (Kerberos, Caché Login, …)

– Privileges associated with the target namespace have been satisfied

• Once a user is ―logged in‖, further interaction with Cachécan take place

• 2 System variables are automatically setup:

– $USERNAME contains the user name that was authenticated,

– $ROLES contains a delimited list of roles held by the user

Exercise #2: Delegated Authentication

In this exercise we will set the %Service_Console to use Delegated Authentication.

We will add delegated users and test the use of CachéTerminal.

Two Factor Authentication

Dave Lutz

Two-factor Authentication

In addition to the authentication mechanism in use, Caché supports the use of two-factor authentication.

This means that Caché authentication can require that the user possess two separate elements or ―factors.‖

1. An authentication token (Ex. Password).

2. The user’s mobile phone. Caché sends a randomly generated eight-digit one-time security token to the phone and challenges the user to enter that code via the computer within a specified amount of time.

Two-factor authentication is enabled on a per-service basis and, if enabled, is required for all of a service’s users.

Two-factor Authentication Configuration

1. Enable two-factor authentication for an instance via the System Management Portal’s Authentication Options page.

2. Configure the mobile phone service provider(s) (if necessary) by adding any mobile phone service providers if required and changing configuration information as necessary for any existing providers (default or added).

3. Configure each user to include a mobile phone number and mobile phone service provider.

4. Enable two-factor authentication for each service that is going to use it. (Ex. Language bindings, CSP or Zen connections)

Two-factor Authentication - Demo

We will show how to configure two-factor authentication using the following factors:

1) password

2) user’s mobile phone

We will add a user and enable the %Service_Console service to require two-factor authentication.

We will then test this via Terminal.

Authorization

Dave Lutz

Roles

Role: a named collection of privileges

• Multiple users typically need the same set of privileges

• Sets of privileges can be defined once and shared

• A user can have more than one role.

• Privileges are only assigned to roles

• Privileges are not assigned directly to users

• Basic unit of authorization

Role Based Authorization - Visual

Row-level Security

Daryl Flaming

What is Row-level Security?

• In addition to its general security features, Caché offers SQL security with a granularity of a single row

• This is called Row-level Security or RLS

• Each row holds a list of authorized viewers, which can be either users or roles

Why do I need RLS?

• Typically, SQL security is controlled by granting the SELECT privilege on a table or view to a user or role

• Roles simplify access control when the number of securityroles is substantially fewer than the number of users

• While View-level security provides adequate control over which rows each user can SELECT…

• When the sheer number of views required to achieve the desired control becomes very large, an alternative for fine-grained access control is needed!

For Example…

• A hospital may desire to make patient-specific data available to each patient over the Web

• Creating a separate view for each patient is not a practical alternative

• Instead, fine-grained access control, in conjunction with the Caché role-based authentication model, enables this type of application to be created efficiently and securely through row-level security!

Setting Up RLS

• To enable row-level security for a table, edit the definition of the class from which the table is projected:

1.In Studio, on the Class menu, select Override. On the dialog that appears, go to the Parameters tab and select the ROWLEVELSECURITY parameter.

– This adds the following parameter to the class definition code: Parameter ROWLEVELSECURITY;

Setting Up RLS (cont)

– Changing this parameter to ROWLEVELSECURITY = 1; means that row-level security is now active and that the class uses the generated property %ReaderList to store information about users and roles with authorized access to the row

– Changing the parameter to ROWLEVELSECURITY = ―rlsprop‖; means that row-level security is now active and that the class uses the generated property ―rlsprop‖ to store information about users and roles with authorized access to the row.

– Note: If rlsprop refers to a valid property name, then that property is used.

Setting Up RLS (cont)

2. Define a %SecurityPolicy class method, which determines and specifies the role and user names that are permitted to select the row (subject to view and table SELECT privileges)

– The structure of the %SecurityPolicy method is:

ClassMethod %SecurityPolicy() As %String [ SqlProc, SqlName = SecurityPolicy ]

{

QUIT ""

}

Adding Row-level Security to a Table with

Existing Data

• To add Row-level Security to a table with existing data:

1.Follow the procedure described in the previous section, ―Setting Up Row-level Security.‖

2.Once this is complete:

– Update the value of the property (i.e. %ReaderList or ―rlsprop‖) that lists the users and roles who can vieweach row.

– Rebuild the indices for the table

• We’ll actually do this in the next Exercise!

How do I UPDATE ―rlsprop‖?

• The %SecurityPolicy method is exposed as an SQL Stored Procedure

• It can be called from any SQL Client or in code to UPDATEthe entire Table’s RLS information

• For example:UPDATE MySchema.MyClass

SET rlsprop =MySchema.MyClass_sys_SecurityPolicy(MyColumn,…)

• %SecurityPolicy is exposed to SQL as ―sys_SecurityPolicy‖

• We’ll examine this concept during the exercise…

Exercise #3: Row Level Security

In this exercise we will use row level security to control user access via SQL to a finer granularity.

Row level access will be based on which roles allow access to the specified rows.

Database Encryption

Dave Lutz

Caché Database Encryption:

Protecting Data at Rest

• Designed to prevent unauthorized users from viewing or using the data in a Caché database.

• Encryption is set on a per-database basis at the time of database creation.

• Caché implements encryption and decryption using the AES (Advanced Encryption Standard) algorithm.

• Encryption and decryption occurs at the time of database reads and writes… ―On-the-Fly‖.

• Associated entries in the Write Image Journal file are also encrypted.

• The CACHETEMP database and Journal files can also be encrypted.

Database Encryption Keys

• Each Caché ―site‖ (or instance) can create a uniquedatabase-encryption key.

• This key allows you to use (decrypt and encrypt) the data on all the encrypted databases for the site.

• It is a permanent key, so you do not ever need to change it after creating and activating it.

• Caché provides for the use of 128, 192, or 256-bit keys.

• It is stored along with Encryption Key Administrator Account(s) in an Encryption Key File.

The Database Encryption Key File

• Contains multiple encrypted copies of the site’s Encryption Key.

• Each copy is associated with an Encryption Key File Administrator account (username and password).

• This account is required to activate an Encryption Key and manage encrypted databases.

• Once you save the key file, you can move it anywhere you choose.

• The loss of or damage to a database-encryption key file can render all encrypted databases permanently unreadable*.

• It is imperative that you store a copy of the Key File in a secure location where it cannot be damaged in any way… removable USB Flash drives are recommended.

Encrypted Database Creation

• A database can be encrypted at the time it is created.

• You can encrypt an already-existing database with the cvencryptutility (We’ll do this in the next exercise).

• Caché must have an activated database-encryption key before you can create or mount an encrypted database.

• Caché now includes the ability to provide for interactive and unattended start-up using Encrypted Databases.

• This includes options for encrypting CACHETEMP and the Journal Files.

Moving an Encrypted Database

Between Sites

• If your organization has multiple Caché sites, you may need to use an encrypted database on one site that was created on another site (using a different encryption key).

• To move the data from one site to another, the procedure is:

1. Back up you data

2. Re-key the database using the cvencrypt utility

• cvencrypt allows you to:

1. Convert an unencrypted database to be encrypted

2. Convert an encrypted database to be unencrypted

3. Convert an encrypted database to use a new key

New Encryption Functionality in 2011.1

In Caché 2011.1 new $SYSTEM commands have been added for encryption key management:

$SYSTEM.Encryption.CreateEncryptionKey

$SYSTEM.Encryption.ActivateEncryptionKey

$SYSTEM.Encryption.ListEncryptionKeys

$SYSTEM.Encryption.DeactivateEncryptionKey

Exercise #4: Encryption

In this exercise we will perform the following tasks:

1. Create and activate an encryption key

2. Use the cvencrypt utility to encrypt an existing database

3. Confirm that the data is encrypted

4. Decrypt the database using cvencrypt

Auditing

Dave Lutz

Auditing

• Logging certain key events in a secure audit log is a major aspect of Caché Security.

• Caché provides built-in audit support for:

– Mandatory System Events: Caché system events that are always logged (e.g. start-up and shutdown)

– Optional System Events: Caché system events that are only logged if they are explicitly enabled (e.g. security-related events)

– User-defined: Application events, which are only logged if they are explicitly enabled. Applications can generate their own audit log entries via $system.Security.Audit()

What Caché does NOT Audit

• Caché does not automatically generate audit log entries for:

– Normal database activity (i.e. all inserts, updates, or deletes for a table )

– Applications can easily do so through object methods or SQL triggers

• Auditing database activity might generate excessive entries and become counterproductive

• Recommended to have an application create a single audit entry, rather than have the database manager generate thousands

Accessing Audit Data

• Audit log is stored in a special, protected, tamper-resistant Caché database, CACHEAUDIT

• Protected by the %DB_CACHEAUDIT resource

• Caché provides several standard Audit Reports

• Audit log contents accessible via SQL or Audit API

• Such access is subject to standard security restrictions

Managing the Audit Log

• System Management Portal enables:

– Copy: Entries for one or more days can be copied to a specified namespace

– Export: Entries for one or more days can be exported from the log to a file

– Purge: Entries for one or more days can be removed from the log

• Database is journaled and backed-up

• To facilitate security monitoring, Caché keeps a counter for each audit event type and makes these counters available via the standard Caché monitoring interface.

– Example: Monitoring the LoginFailure event counter to detect possible break-in attempts

Questions?

• We hope this has been both informative and thoughtprovoking…

• Thank-you for your time, patience and attention over the past 2 hours

• We hope you enjoy Global Summit 2011

We’d love your feedback

If you have a minute, we’d love your feedback on the academy you just attended.

Go to…

intersystems.com/survey

Select the day and time of the academy you attended

and complete our short evaluation form.

Thank you