• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cache Security- Configuring a Secure Environment
 

Cache Security- Configuring a Secure Environment

on

  • 992 views

 

Statistics

Views

Total Views
992
Views on SlideShare
992
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cache Security- Configuring a Secure Environment Cache Security- Configuring a Secure Environment Presentation Transcript

    • Caché Security II:A More Advanced Look At Caché SecurityDave Lutz & Daryl FlamingMarch 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 Components1. Authentication: verifies the identity of all users2. Authorization: ensures that users can access the resources that they need, and no others3. Auditing: keeps a log of pre-defined system and application-specific events4. Secure Communications: protects network data traffic from eavesdropping, tampering, and message forgery5. 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 users 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-DefinedAuthentication 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 users password – Properties("Username") — The users 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 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 withExisting 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 DatabaseBetween 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
    • AuditingDave 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 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