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 ...
Welcome/FAQ • What is the purpose of this academy?    • A ―Hands-On‖, more detailed look at some specific      security fe...
Academy Agenda • Review of Caché’s Security Model • Authentication Using LDAP • Delegated Authentication • Two Factor Auth...
Review of Caché’s Security Model:            Dave Lutz
Caché Security Components1.   Authentication: verifies the identity of all users2.   Authorization: ensures that users can...
LDAP Authentication      Dave Lutz
LDAP Authentication • Caché provides support for authentication using LDAP • LDAP: Lightweight Directory Access Protocol •...
LDAP Authentication - Configuration  The procedure for configuring a Caché service or  application to use an existing LDAP...
LDAP Configuration in Caché
LDAP: Attempting to Authenticate  When a user attempts to authenticate to an instance of Caché that  uses LDAP authenticat...
LDAP: Attempting to Authenticate 4. If Caché locates the target user in the LDAP database, it retrieves    all the attribu...
LDAP: intersystems.schema In 2011.1 the intersystems.schema is available for LDAP. This defines Caché attributes such as d...
Exercise #1: LDAP Authentication  We will test the use of LDAP Authentication using  OpenLDAP as the LDAP server running L...
Delegated Authentication       Daryl Flaming
Delegated Authentication • User-defined authentication mechanism • Can be used for both Applications and specific Caché   ...
Setting up Delegated Authentication Setting up Delegated Authentication involves the following  steps:    1. Create user-d...
Creating User-DefinedAuthentication Code • A system-supplied copy of ZAUTHENTICATE is available in the   %SYS namespace in...
Authentication Code… • The content of the authentication code inside ZAUTHENTICATE is   application specific. • The authen...
Setting User Account Characteristics • If initial authentication succeeds, ZAUTHENTICATE can establish   the roles and oth...
Once Authenticated –―The State of the System‖ 1. Any user who is initially authenticated using Delegated    Authentication...
From Authenticated to ―Logged In‖ • ―Logging in‖ stipulates that:    – Authentication was successful using any of the supp...
Exercise #2: Delegated Authentication      In this exercise we will set the %Service_Console to use      Delegated Authent...
Two Factor Authentication         Dave Lutz
Two-factor Authentication  In addition to the authentication mechanism in use, Caché supports  the use of two-factor authe...
Two-factor Authentication Configuration 1. Enable two-factor authentication for an instance via the System    Management P...
Two-factor Authentication - Demo    We will show how to configure two-factor authentication using the    following factors...
Authorization   Dave Lutz
Roles   Role: a named collection of privileges      • Multiple users typically need the same set of privileges      • Sets...
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...
Why do I need RLS? • Typically, SQL security is controlled by granting the   SELECT privilege on a table or view to a user...
For Example… • A hospital may desire to make patient-specific data   available to each patient over the Web • Creating a s...
Setting Up RLS • To enable row-level security for a table, edit the definition   of the class from which the table is proj...
Setting Up RLS (cont)   – Changing this parameter to ROWLEVELSECURITY = 1; means     that row-level security is now active...
Setting Up RLS (cont) 2. Define a %SecurityPolicy class method, which    determines and specifies the role and user names ...
Adding Row-level Security to a Table withExisting Data • To add Row-level Security to a table with existing data: 1.Follow...
How do I UPDATE ―rlsprop‖? • The %SecurityPolicy method is exposed as an SQL   Stored Procedure • It can be called from an...
Exercise #3: Row Level Security      In this exercise we will use row level security to control      user access via SQL t...
Database Encryption      Dave Lutz
Caché Database Encryption:Protecting Data at Rest • Designed to prevent unauthorized users from viewing or using the   dat...
Database Encryption Keys • Each Caché ―site‖ (or instance) can create a unique   database-encryption key. • This key allow...
The Database Encryption Key File • Contains multiple encrypted copies of the site’s Encryption Key. • Each copy is associa...
Encrypted Database Creation • A database can be encrypted at the time it is created. • You can encrypt an already-existing...
Moving an Encrypted DatabaseBetween Sites  •   If your organization has multiple Caché sites, you may need to use      an ...
New Encryption Functionality in 2011.1    In Caché 2011.1 new $SYSTEM commands have been    added for encryption key manag...
Exercise #4: Encryption  In this exercise we will perform the following tasks:  1.   Create and activate an encryption key...
AuditingDave Lutz
Auditing • Logging certain key events in a secure audit log is a major   aspect of Caché Security. • Caché provides built-...
What Caché does NOT Audit • Caché does not automatically generate audit log entries for:    – Normal database activity (i....
Accessing Audit Data • Audit log is stored in a special, protected, tamper-resistant   Caché database, CACHEAUDIT • Protec...
Managing the Audit Log • System Management Portal enables:     – Copy: Entries for one or more days can be copied to a spe...
Questions? • We hope this has been both informative and thought   provoking… • Thank-you for your time, patience and atten...
We’d love your feedback   If you have a minute, we’d love your feedback on the                 academy you just attended. ...
Upcoming SlideShare
Loading in …5
×

Cache Security- Configuring a Secure Environment

1,846 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,846
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
64
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cache Security- Configuring a Secure Environment

  1. 1. Caché Security II:A More Advanced Look At Caché SecurityDave Lutz & Daryl FlamingMarch 2011
  2. 2. 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
  3. 3. 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.
  4. 4. 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
  5. 5. Review of Caché’s Security Model: Dave Lutz
  6. 6. 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
  7. 7. LDAP Authentication Dave Lutz
  8. 8. 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)
  9. 9. 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.
  10. 10. LDAP Configuration in Caché
  11. 11. 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.
  12. 12. 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é).
  13. 13. 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 )
  14. 14. 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.
  15. 15. Delegated Authentication Daryl Flaming
  16. 16. 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!
  17. 17. 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.
  18. 18. 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
  19. 19. 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!
  20. 20. 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
  21. 21. 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!
  22. 22. 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
  23. 23. 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.
  24. 24. Two Factor Authentication Dave Lutz
  25. 25. 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.
  26. 26. 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)
  27. 27. 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.
  28. 28. Authorization Dave Lutz
  29. 29. 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
  30. 30. Role Based Authorization - Visual
  31. 31. Row-level Security Daryl Flaming
  32. 32. 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
  33. 33. 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!
  34. 34. 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!
  35. 35. 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;
  36. 36. 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.
  37. 37. 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 "" }
  38. 38. 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!
  39. 39. 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…
  40. 40. 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.
  41. 41. Database Encryption Dave Lutz
  42. 42. 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.
  43. 43. 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.
  44. 44. 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.
  45. 45. 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.
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. AuditingDave Lutz
  50. 50. 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()
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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

×