Cache Security- Configuring a Secure Environment

Caché Security II:
A More Advanced Look At Caché Security
Dave Lutz & Daryl Flaming
March 2011

Caché Security II
• Caché Security II
Technical level: Intermediate
In 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: 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 establish
the 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.

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 security
roles 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 view
each 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 UPDATE
the 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 unique
database-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 cvencrypt
utility (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

• 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 thought
provoking…
• 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

Cache Security- Configuring a Secure Environment

More Related Content

What's hot

Similar to Cache Security- Configuring a Secure Environment

Recently uploaded

Cache Security- Configuring a Secure Environment