Monitor Developer s Guide

Transcription

1 IBM Tioli Priacy Manager for e-business Monitor Deeloper s Guide Version 1.1 SC

2

3 IBM Tioli Priacy Manager for e-business Monitor Deeloper s Guide Version 1.1 SC

4 Note: Before using this information and the product it supports, read the information in Notices on page 39. First Edition (July 2002) This edition applies to ersion 1.1 of IBM Tioli Priacy Manager for e-business (5724 C07) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright International Business Machines Corporation All rights resered. US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Preface Who should read this guide Publications Tioli Priacy Manager publications..... Related publications i IBM Tioli Access Manager for e-business.. i IBM Uniersal DB2 Enterprise Edition... i IBM WebSphere Application Serer.... i IBM HTTP Serer i Accessing publications online i Ordering publications i Proiding feedback about publications.... i Accessibility ii Contacting customer support ii Typeface conentions ii Operating system-dependent ariables and paths ii Chapter 1. Getting Started What is a toolkit? Monitor SDK Jaa APIs Tioli Priacy Manager oeriew Key concepts Defining and deploying policies Introduction to monitors Monitor handling of user keys Monitor handling of PII usage conditions Enironment requirements Installation requirements Chapter 2. Designing a monitor Monitor architecture Monitor responsibilities Learn the storage system Identify storage system relationships Assign monitor-specific storage location attributes Register monitors Register storage locations Retriee monitor and storage location information Poll the serer for updates Report submission and access actiity Enforce priacy policy statements Monitor placement Multiple part monitors Chapter 3. Introduction to the Monitor SDK Jaa APIs Objects MonitorInfo SLocInfo EalRuleInfo EalResultInfo SKey Methods for communicating with the serer Helper methods Exceptions Chapter 4. Monitor Deelopment and Testing Programming considerations Setting up the monitor deelopment enironment 23 Blueprint for monitor implementations Monitor startup and initialization Monitor polling Monitoring PII submission Monitoring PII access Real-time enforcement of PII access Monitor shutdown and termination Strategies for exception handling Support for debugging monitors Performance considerations Background execution Gathering additional information from the storage system Tuning controls Multiple part monitors Setting up the run-time enironment WebSphere J2EE Application Client setup WebSphere Application Thin Client setup WebSphere Application Serer setup Internationalization considerations Appendix. Notices Trademarks Glossary Index Copyright IBM Corp iii

6 i IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

7 Preface Who should read this guide Publications The IBM Tioli Priacy Manager for e-business Monitor Deeloper s Guide proides information about deeloping monitors for IBM Tioli Priacy Manager for e-business (Tioli Priacy Manager, upon subsequent mention). This document is written for the following: Systems administrators who want to learn about the purpose and design of Tioli Priacy Manager monitors. Systems programmers, systems integrators and independent software endors who want to design and implement a Tioli Priacy Manager monitor for a specific storage system or application. Users need a working knowledge of the following products: IBM Tioli Priacy Manager for e-business IBM WebSphere Application Serer The following publications are related to the Tioli Priacy Manager product. Tioli Priacy Manager publications Most of the product information for using Tioli Priacy Manager, with the exception of the integrated online help is found on the following location: The publications for this product include the following: IBM Tioli Priacy Manager for e-business Release Notes. Proides information on obtaining required fixes and APARs, and describes updates, corrections, amendments, and workarounds for tasks and topics described in the Tioli Priacy Manager library. IBM Tioli Priacy Manager for e-business Planning Guide, SC Proides information on planning for the installation, operation, and administration of Tioli Priacy Manager. IBM Tioli Priacy Manager for e-business Installation Guide, SC Proides information on installing and configuring Tioli Priacy Manager. IBM Tioli Priacy Manager for e-business Monitor Deeloper s Guide, SC Proides information about the application programming interface (API) system programmers can use to create a storage system monitor. IBM Tioli Priacy Manager for e-business Problem Determination Guide, SC Proides information on diagnosing and soling problems with Tioli Priacy Manager. Product messages are also included. Online user assistance for Tioli Priacy Manager (Tioli Assistant) Proides integrated online help topics for all Tioli Priacy Manager administratie tasks. Copyright IBM Corp. 2002

8 The Tioli Glossary includes definitions for many of the technical terms related to Tioli software. The Tioli Glossary is aailable, in English only, at the following Web site: Related publications The following documents also proide useful information: IBM Tioli Access Manager for e-business The documents required to support IBM Tioli Access Manager for e-business are aailable at: IBM Uniersal DB2 Enterprise Edition The documents required to support DB2 are aailable at: IBM WebSphere Application Serer Access publications for this product at: IBM HTTP Serer Access publications for this product at: Accessing publications online You can access updated publications in the Tioli Information Center from the following Customer Support Web site: These publications are aailable in PDF or HTML format, or both. Translated documents are also aailable for some products. Note: If you print PDF documents on other than letter-sized paper, select the Fit to page check box in the Adobe Acrobat Print dialog (which is aailable when you click File --> Print ) to ensure that the full dimensions of a letter-sized page are printed on the paper that you are using. Ordering publications You can order publications at: pbi.cgi Proiding feedback about publications We are ery interested in hearing about your experience with Tioli products and documentation, and we welcome your suggestions for improements. If you hae comments or suggestions about Tioli products and documentation, send an to pubs@tioli.com or complete the customer feedback surey at the following Web site: i IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

9 Accessibility Contacting customer support Typeface conentions The product documentation has been modified to include features to aid accessibility: Documentation is aailable in both HTML and conertible PDF formats to gie the maximum opportunity for users to apply screen-reader software. All images in the documentation are proided with alternatie text so that users with ision impairments can understand the contents of the images. If you hae a problem with any Tioli product, you can contact IBM Customer Support for Tioli products. See the Tioli Customer Support Handbook at the following Web site: The handbook proides information about how to contact Customer Support, depending on the seerity of your problem, as well as the following information: Registration and eligibility Telephone numbers and addresses, depending on the country in which you are located The information you should gather before contacting support The following typeface conentions are used in this book: Bold Italic Monospace Lowercase and mixed-case commands, command options, and flags that appear within text appear like this, in bold type. Graphical user interface elements (except for titles of windows and dialogs) and names of keys also appear like this, in bold type. Variables, alues you must proide, new terms, and words and phrases that are emphasized appear like this, in italic type. Commands, command options, and flags that appear on a separate line, code examples, output, and message text appear like this, in monospace type. Names of files and directories, text strings you must type, when they appear within text, names of Jaa methods and classes, and HTML and XML tags also appear like this, inmonospace type. Operating system-dependent ariables and paths This book uses the UNIX conention for specifying enironment ariables and for directory notation. When using the Windows command line, replace $ariable with %ariable% for enironment ariables and replace each forward slash (/) with a backslash (\) in directory paths. Preface ii

10 Note: If you are using the bash shell on a Windows system, you can use the UNIX conentions. iii IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

11 Chapter 1. Getting Started What is a toolkit? Tioli Priacy Manager is used to define priacy policies and to monitor access to information goerned by those policies. The IBM Tioli Priacy Manager for e-business Monitor Deeloper s Guide describes the fundamental design principles of Tioli Priacy Manager monitors, defines the Jaa application programming interfaces (APIs) used by those monitors to communicate with the Tioli Priacy Manager serer, and introduces the tools and resources that are aailable to assist software deelopers in the deelopment of monitors. This chapter contains the following sections: What is a toolkit? Tioli Priacy Manager oeriew Introduction to monitors on page 5 Enironment requirements on page 8 Installation requirements on page 8 A deelopers toolkit is a set of software routines and utilities used to help programmers write an application. The Tioli Priacy Manager Monitor Software Deeloper s Toolkit (Monitor SDK, upon subsequent mention) contains: The IBM Tioli Priacy Manager for e-business Monitor Deeloper s Guide The Monitor SDK Jaa APIs needed to deelop and compile a new monitor implementation, packaged in a Jaa Archie (JAR) file The Jaadoc, which contains detailed information about the Monitor SDK Jaa APIs A WebSphere Enterprise Archie (EAR) file, which contains the Monitor SDK runtime support Monitor SDK Jaa APIs The Monitor SDK Jaa APIs consist of a set of classes used by monitors to interact with the Tioli Priacy Manager serer. A software deeloper can use these classes to implement new monitors without haing to understand the protocols to communicate with the Tioli Priacy Manager serer. The Jaa APIs proide methods that are used to register a monitor with the Tioli Priacy Manager serer, to retriee storage location classification information from the Tioli Priacy Manager serer, and to send notifications to the Tioli Priacy Manager serer when personally identifiable information (PII) is accessed or changed within a monitored storage system. For additional information about the Monitor SDK Jaa APIs, see Chapter 3, Introduction to the Monitor SDK Jaa APIs on page 17. Tioli Priacy Manager oeriew The Tioli Priacy Manager enironment consists of the Tioli Priacy Manager serer and one or more monitors. Copyright IBM Corp

12 The Tioli Priacy Manager serer is an enterprise application built from Enterprise Jaa Beans (EJBs), Jaa Serer Pages (JSPs), and serlets. The Tioli Priacy Manager serer runs inside an IBM WebSphere Application Serer (WAS) Jaa 2 Enterprise Edition (J2EE) container. The serer maintains a DB2 database that contains information related to priacy policies, monitors and their storage locations, and audit logs that record the submission and access of PII in the monitored storage systems. Tioli Priacy Manager monitors run inside WebSphere Application Client J2EE containers. They monitor the submission and access of PII and report this actiity to the Tioli Priacy Manager serer for auditing and conformance checking purposes. The monitors use the Monitor SDK Jaa APIs to interact with the Tioli Priacy Manager serer. Figure 1 illustrates the relationship between the Tioli Priacy Manager serer, a Tioli Priacy Manager monitor, and a monitored storage system. Figure 1. Interaction between the Tioli Priacy Manager serer and the monitor. Key concepts One key goal of Tioli Priacy Manager is to assist organizations with the monitoring and auditing of priacy sensitie information. This information can be collected from a number of persons, including customers and employees. The following key concepts should be considered before designing a monitor. Personally identifiable information Personally identifiable information (PII) refers to personal data that an indiidual proides to an organization for some business purpose. Data is considered PII if it is specifically associated with an indiidual, if it was disclosed by the indiidual to the organization and persistently stored for future use, and if the indiidual who submitted the data has an interest, either directly expressed or by legal right, in limiting the propagation of the data within the organization or to other organizations or indiiduals. 2 IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

13 Storage system A storage system is a data repository that collects and stores PII for future use. Storage systems can either be physical repositories, such as a database or directory, or they can be abstract, such as an application that controls access to collected data. A storage system typically maintains different types of data in a logical arrangement. For example, directories keep information in attributes of directory object classes and databases arrange information in tables of rows and columns. Storage location A storage location is a named place within a storage system that can hold a piece of information. For example, a storage location for a directory might represent one attribute of an object class, and a storage location for a database might represent one column of a table. Sometimes a storage location can represent information that is not stored the same way as other information in the storage system. For example, a storage location might represent the distinguished name (DN) of a directory object, een though no attribute of an object class exists that holds the DN of the directory entry. Storage key Information is considered priacy sensitie only if it can be associated with an indiidual, so when PII is accessed, it is necessary to know who owns the PII. If PII is accessed and the owner of the PII cannot be determined, the access is considered de-identified and is not priacy sensitie. Storage keys are storage locations used by Tioli Priacy Manager to make associations between other storage locations in the storage system. For example, the primary key of a database table identifies a row in the table and acts as the association between all of the storage locations in that row of the table. A user key is a storage key that identifies the owner of PII in the storage system; that is, it associates specific instances of PII in the storage system with the owner of the PII. Some user keys are known to the organization collecting the information (such as a customer or patient number), while other user keys are known to the specific person who owns the information. User keys that are known to the PII owner are called user identifiers (user IDs). All user IDs are user keys and all user keys are storage keys. Priacy Manager defines one other type of storage key called a master key. The master key is a user key that can be mapped to any other user key or to the alue of any storage location associated with an indiidual. For additional information about the purpose and use of the master key, see Monitor handling of user keys on page 6. PII Submission and access Monitors notify the Tioli Priacy Manager serer when they detect actiity in the monitored storage system that might be priacy sensitie. A PII submission notification is sent when PII is submitted or changed in the storage system to enable the Tioli Priacy Manager serer to determine the priacy policies that are currently in effect. If a person submits PII, this implies that the person consents to the priacy policy that currently goerns the usage of the PII. A PII access notification is sent to the Tioli Priacy Manager serer when PII is accessed so the serer can keep an audit trail of PII usage. In addition, monitors that support real-time enforcement of priacy policies can request a PII conformance check from the Tioli Priacy Manager serer to determine if a particular PII access attempt is compliant with the goerning priacy policies. Chapter 1. Getting Started 3

14 When a monitor sends PII submission and access notifications or performs a real-time policy conformance check, it sends the Tioli Priacy Manager serer a list of the PII storage locations that were inoled along with one or more user keys that identify the owner of the PII. Tioli Priacy Manager assumes that the person submitting PII is the PII owner, but the person accessing PII might not be the PII owner. The accessor is an entity, either a person or an application, that requests access to PII. For example, an accessor might be a physician requesting access to a patient s medical history or an application designed to send mass messages to users that hae subscribed to an internet news serice. Monitors proide the Tioli Priacy Manager with a list of accessor attributes to identify who is accessing PII and for what purpose. Each accessor attribute is a key/alue pair, and the list of supported attribute keys is defined by the monitor implementation. The list of supported attribute keys is based on the type of accessor information that is aailable to the monitor when the PII is accessed. For example, a database monitor can define the attribute key DataBaseUser, because it knows the database user who is requesting information from the database. Conditions Sometimes an organization must restrict PII usage by certain accessors and for certain purposes, either because a priacy policy does not allow access to the information or because the law prohibits access to the information. For example, an organization can decide that an indiidual s address only be used for marketing purposes if the indiidual requests (opts in) marketing materials. Conditions are defined at the Tioli Priacy Manager serer during priacy policy creation, and monitors obtain instructions for ealuating the conditions during priacy policy deployment. Monitor implementations are required to ealuate the conditions defined for PII storage locations and to proide the results of these ealuations on PII submission notifications, PII access notifications and real-time conformance check requests. For additional information about ealuating conditions, see Monitor handling of PII usage conditions on page 7. Defining and deploying policies After an administrator installs Tioli Priacy Manager, the administrator uses a Web-based graphical user interface (GUI) to define priacy policies that reflect an organization s PII usage practices. Each policy must contain at least one statement, and each statement contains PII types, groups, and purposes. A statement can optionally contain conditional information that limits the use of PII. Refer to Monitor handling of PII usage conditions on page 7 for additional information. When a policy is being defined, it is considered to be in draft state. After the administrator defines the policy, the policy must be changed to published state. Publishing a policy implies that the information contained in the policy is finalized and the policy is ready to be deployed. Before you can deploy the policy, Tioli Priacy Manager must know which storage locations exist for the storage system. When a monitor first starts up, the monitor should query the monitored storage system and build a list of storage locations from the information contained in the system. After the monitor builds a list of storage locations, the monitor must register itself and the list of storage locations with the Tioli Priacy Manager serer. When a 4 IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

15 Introduction to monitors monitor and its storage locations are registered with the Tioli Priacy Manager serer, the administrator can begin deploying the policy. To deploy a policy, the administrator must identify which storage locations in the storage system contain PII and which storage locations are user keys and user IDs. This process is called storage location classification. Storage location classification information enables a monitor to determine which storage locations contain PII and therefore are subject to monitoring. If a storage location is classified as a PII storage location, the administrator can assign PII types from a priacy policy to the storage location. When the administrator assigns a PII type to the storage location, the information contained in the storage location is goerned by the priacy policy statement that contains the PII type. For priacy policy statements that hae conditional information, ealuation rules must be defined. The ealuation rules are used to ealuate conditions to ensure adherence to a policy. The the length of time needed to deploy a policy to a monitored storage system can ary depending on the complexity of the system and the priacy policy. While a policy is being deployed, the monitor remains in Not deployed state and polls the serer for updates to its status. After the administrator completes the policy deployment process, which includes changing the state of the policy from published to deployed, the monitor state can be changed from Not deployed to In test or Deployed (depending on whether the monitor is being tested or deployed). On the next polling operation, the monitor detects that its status has been changed and retriees the complete set of storage location classification information from the Tioli Priacy Manager serer. The monitor is ready to begin monitoring the storage system for submissions and accesses of PII. When PII submission or PII access actiity is detected, the monitor must send submission and access notifications to the Tioli Priacy Manager serer. The process for defining priacy policies, deploying the policies, and monitoring access to data goerned by the policies is a cooperatie effort that requires information from both the monitor (list of storage locations) and the Tioli Priacy Manager administrator (storage location classification and conditional information). Although storage systems (such as databases, directories, or applications with proprietary data repositories) are designed with different operating characteristics, they all perform the same function: they store data that must be retrieed and updated. When the stored data being retrieed or updated is priacy sensitie, monitors can be used to obsere submission and access actiity and to report this actiity. Tioli Priacy Manager monitors obsere data going into and out of a monitored storage system. They act as a bridge between the monitored storage system and the Tioli Priacy Manager serer. The Tioli Priacy Manager serer defines a common model for the monitors and proides a set of Jaa APIs that are used by the monitors to interact with the Tioli Priacy Manager serer. Thus, the Tioli Priacy Manager serer can support different monitor implementations for a wide ariety of storage systems. Chapter 1. Getting Started 5

16 While monitor implementations can ary, there are certain responsibilities that must be carried out by all monitors regardless of the implementation. In general, monitors are responsible for registering with the Tioli Priacy Manager serer, for registering all storage locations with the Tioli Priacy Manager serer, and for notifying the Tioli Priacy Manager serer when storage locations that contain PII are accessed or changed in the storage system. For detailed information about the responsibilities of a monitor, see Monitor responsibilities on page 10. Monitor handling of user keys When PII is accessed or changed, the monitor sends a list of the storage locations accessed to the Tioli Priacy Manager serer along with one or more user keys. User keys are used to identify the person whose PII is inoled in the actiity being monitored. Monitors are required to supply one or more user keys for eery PII submission notification, PII access notification, or PII conformance check request. A storage system is likely to contain many user keys for an indiidual, and any of the user keys can be used to identify the indiidual. Howeer, not all PII submissions or accesses use the same user key. For example, one database query might return an indiidual s salary and full name, while another query might return the indiidual s home address and telephone number. In this case, different types of PII (salary and home address) are accessed with different user keys (full name and telephone number, respectiely). If only the user keys associated with the actiity are recorded in the Tioli Priacy Manager audit logs, it is difficult to get a complete report of all PII access. The person requesting the report would need to know the alues of all user keys associated with the indiidual to find all of the audit records for that indiidual. Ideally, a monitor s interaction with its storage system should allow the monitor to map user keys for an indiidual to other user keys for that same indiidual. For example, a monitor should be able to query its storage system to obtain an indiidual s telephone number gien the indiidual s full name. But mapping any user key to any other user key might be difficult to implement in some storage systems. To simplify user key mapping, Tioli Priacy Manager uses the concept of a master key. A master key is a user key that can be used to obtain any other user key (or the alue of any other storage location) for an indiidual. It should be possible to obtain an indiidual s master key gien any other user key for that indiidual. With a master key, a monitor does not need to map all user keys for an indiidual to each other. Instead, the monitor can map a user key to the master key and then map the master key to any other user key. Tioli Priacy Manager does not require monitors to support a master key, because all monitors or storage systems might not be able to implement a master key. If a monitor does not support master keys, the monitor should send all user keys that were inoled in the submission or access operation to the Tioli Priacy Manager serer when it reports submission and access actiity. If a monitor supports master keys, the monitor must send the master key and all other user keys inoled in the submission or access, which might require the monitor to request the master key from the storage system using one of the other user keys inoled in the operation. The adantage of supporting a master key is eident when indiidual access reports are generated. If an administrator wants to generate a report that shows all the times an indiidual s PII was accessed, the administrator must first know one 6 IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

17 or more user keys for the indiidual. For monitors that do not support a master key, the administrator must know eery user key for the indiidual to include all PII accesses in the report. Howeer, if the monitor supports a master key, the administrator needs to know a single user key for the indiidual. The administrator can map the user key to the indiidual s master key and run the report using the master key to find all accesses for the indiidual. The drawback to supporting a master key is that the monitor might need to perform additional queries against the storage system for eery data submission or access to obtain the master key. This might hae an impact on performance. Some monitor implementations might require that a specific storage location be classified as the master key, whereas other monitor implementations might allow the Tioli Priacy Manager administrator to select the storage location that acts as the master key. A monitor cannot programmatically define which storage location is the master key. If a monitor implementation requires that a specific storage location be identified as the master key, the documentation for the monitor must identify which storage location must be the master key. Monitor handling of PII usage conditions PII usage can be limited based on conditions that are either defined by law or by the organization collecting the PII. For example, if a law states that an indiidual s employer information cannot be used to determine loan eligibility if the indiidual lies in a certain state or country, a policy that goerns the employer information might contain a condition that prohibits use of the information for that purpose. Use of PII can also be limited based on a person s choice to opt in or opt out with regard to use of the PII. For example, an organization can allow its customers to opt out with regard to use of their PII for telemarketing purposes. If the customer does not choose to opt out, PII can be used for telemarketing, but if the customer chooses to opt out, the PII cannot be used for telemarketing. The conditions for data usage are part of the contract between the indiidual and the organization regarding use of the indiidual s PII. As a result, the conditions must be considered during priacy policy conformance checks. Using the information maintained in the storage system, administrators can use the Tioli Priacy Manager GUI to define the conditions for arious types of PII and to define how these conditions are ealuated by monitors. A storage location assigned to a certain PII type can be subject to one or more conditions, and to ealuate those conditions, it might be necessary to access information in other storage locations, such as the indiidual s opt in or opt out choice or the indiidual s state or country of residence. (Retrieing the alues of other storage locations is similar to retrieing the master key for an indiidual, as described in Monitor handling of user keys on page 6.) Monitors must ealuate conditions each time information is submitted or accessed for a PII storage location so the conditions defined for the storage location are known and recorded with the PII submission or access. The results of the ealuations must be sent to the Tioli Priacy Manager serer with each PII submission and access notification. Because the storage locations themseles can be priacy sensitie, the results of the ealuations are sent to the Tioli Priacy Manager serer instead of the actual alues of the storage locations used in the ealuation process. Chapter 1. Getting Started 7

18 Enironment requirements Installation requirements Because the ealuation of conditions might inole any storage location in the monitored storage system, the monitor must be able to retriee the alue of any storage location for a particular indiidual, gien one or more user keys for that indiidual. While this is a simple task for some monitors, it is more complex for other monitors, such as database monitors that hae storage locations spread across seeral interrelated tables. For monitors that support a master key, this task can be simplified by assuming that the master key is always used to retriee conditional information, as opposed to an arbitrary user key. Tioli Priacy Manager monitors use the Monitor SDK Jaa APIs to communicate with the Tioli Priacy Manager serer. Therefore, monitor source code must be compiled against the Monitor SDK Jaa API classes during the deelopment of a new monitor implementation. The classes needed at compile time are packaged in a JAR file. The JAR file can be installed on the deelopment machine using the Tioli Priacy Manager installation procedure. Monitor deelopment requires Jaa 1.3 or a later ersion. Testing a new monitor implementation requires a fully functional Tioli Priacy Manager serer enironment and the setup of the monitor runtime enironment. The monitor run-time enironment requires the installation of either the WebSphere Application Serer or a WebSphere client enironment, depending on the design and implementation of the monitor. Seeral different runtime configurations are supported, and the setup requirements for each configuration are different. For detailed information about the monitor runtime enironment, see Setting up the run-time enironment on page 33. The Monitor SDK can be installed on the same machine as the Tioli Priacy Manager serer or on a different machine. For information about the Tioli Priacy Manager installation procedure for the Monitor SDK, see the IBM Tioli Priacy Manager for e-business Installation Guide. 8 IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

19 Chapter 2. Designing a monitor Monitor architecture Each monitor is designed specifically for the storage system being monitored. The storage system might be a database, a directory, or an application that controls access to its own proprietary data repository. A monitor acts as the bridge between the storage system and the Tioli Priacy Manager serer. This chapter describes how to design a new monitor implementation and focuses on the architecture and responsibilities of monitors. The chapter contains the following sections: Monitor architecture Monitor responsibilities on page 10 Monitor placement on page 15 Multiple part monitors on page 16 A monitor can be conceptually diided into three components: storage system adapter, monitor implementation, and priacy serer adapter. Monitored storage system Storage system adapter Monitor implementation Monitor status Storage location classification Storage key definitions Priacy serer adapter Tioli Priacy Manager serer Storage system interface Priacy serer interface Figure 2. Monitor component architecture The first component of the monitor is the storage system adapter. The storage system adapter is specific to the storage system being monitored, and it detects when data is submitted or accessed in the storage system. The storage system adapter acts as a bridge between the storage system and the monitor implementation. The second component of the monitor is the monitor implementation. The monitor implementation uses information maintained on the Tioli Priacy Manager serer and information from the storage system to perform priacy monitoring functions. The interface between the storage system adapter and the monitor implementation is called the storage system interface. The storage system interface is bi-directional; that is, it defines the ways the storage system adapter coneys information to the monitor implementation and also defines the way the monitor implementation requests information from the storage system adapter. This interface might only be a logical interface because some monitor designs can blur the line between the storage system adapter and the monitor implementation. Copyright IBM Corp

20 Monitor responsibilities The storage system adapter uses the storage system interface to notify the monitor implementation when data in the storage system is accessed or updated. For each notification, the storage system adapter proides information about the affected data to the monitor implementation. The monitor maps this information to its list of storage locations to determine if any of the data is PII and therefore subject to monitoring. The storage system adapter must proide the monitor implementation with the alues of the affected data items in order for the monitor to use the alues of storage key locations to identify the indiidual whose PII was accessed or updated. The storage system adapter does not contain logic that requires information about storage location classification; it is simply a thin layer that communicates storage system actiity to the monitor implementation. The monitor implementation receies notifications from the storage system adapter, determines whether or not PII was accessed or updated, and then notifies the Tioli Priacy Manager serer. The monitor implementation might require additional information from the storage system when it builds the notification messages. For example, the monitor might need the alue of the master key storage location for the indiidual, or the monitor might need to obtain the alues of other storage locations to ealuate conditions for one or more of the affected PII storage locations. In either case, the monitor implementation uses the storage system interface to request additional information, and must proide the alue of one or more user keys to identify the indiidual whose information is being accessed or updated. The monitor implementation also uses the storage system interface during monitor startup to retriee the list of data fields in the storage system that are used to build the list of storage locations. The third component of the monitor is the priacy serer adapter. The priacy serer adapter implements the protocols and flows used by the monitor to communicate with the Tioli Priacy Manager serer. The interface between the priacy serer adapter and the monitor implementation is the priacy serer interface. The monitor implementation uses the priacy serer interface in all communications with the Tioli Priacy Manager serer, including monitor and storage location registration, polling, submission and access notifications, and real-time conformance checking. (The priacy serer interface is abstracted from the underlying EJB protocols, so that monitors do not hae to handle the complexities of using EJBs.) The Tioli Priacy Manager Monitor SDK Jaa APIs proide the implementation of the priacy serer adapter and define the priacy serer interface. Each monitor implementation is specific to a particular storage system. A monitor is written based on the design and operational characteristics of the storage system and presents a iew of the storage system to the Tioli Priacy Manager serer. The monitor performs the following functions: Learn the storage system on page 11 Register monitors on page 12 Register storage locations on page 13 Retriee monitor and storage location information on page 13 Poll the serer for updates on page 13 Report submission and access actiity on page 14 Enforce priacy policy statements on page IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

21 Learn the storage system Each monitor must identify the list of storage locations within the storage system. A storage location is a location within the storage system where data can be stored, such as a column in a database table or an attribute of a directory object, or a storage location can be abstract. For example, an abstract storage location might be defined to represent the parent-child relationship between two directory objects when no explicit object attribute is defined for this purpose. A monitor deries a list of storage locations in arious ways depending on the storage system. The monitor should be able to create a list of storage locations from the storage system definition information (database schema or directory schema). If not, the monitor implementation might require that a list of storage locations be built manually and that this list be made aailable to the monitor at run time. A monitor must proide a unique name for each storage location. The naming conention should reflect the logical arrangement of the storage locations within the storage system. Below are two examples of naming conentions for storage locations. A database monitor can use the form Database.Schema.Table.Column to name storage locations based on the organization of the data in the database. A directory monitor can use the form ObjectClass.Attribute to name storage locations based on the arrangement of attributes in directory objects. The monitor must be able to detect changes in the storage system that result in a change in the list of storage locations, such as when storage locations are added or remoed. The monitor is responsible for notifying the Tioli Priacy Manager serer when changes occur. The following sections contain information to consider when creating a list of storage locations. Identify storage system relationships A monitor must be able to determine the relationship between storage locations to find related information in a storage system. For example, a database monitor should be able to determine which storage locations are primary keys, indexed fields that maintain the primary sequence of the table, and which storage locations are foreign keys, fields in one table that are indexed in another table. A directory monitor should be implemented to detect the parent-child relationship between directory objects and might need to determine which attributes of directory objects are DN pointers to other directory objects. If the implementation of a monitor requires knowledge of these relationships, the monitor must be able to derie them from the storage system definition information (schema), or the information must be proided to the monitor using an alternate method. Assign monitor-specific storage location attributes Attributes are assigned to storage locations to assist the monitor with managing them. Each attribute consists of a key/alue pair. The set of attributes assigned to storage locations by monitors is based on each indiidual monitor implementation. Attributes are assigned to storage locations when they are registered with the Tioli Priacy Manager serer. The registered attributes are then proided to the monitor when it subsequently retriees the storage locations from the Tioli Priacy Manager serer. The following examples indicate how attributes can play a significant role in the design of a monitor: Chapter 2. Designing a monitor 11

22 Storage location description Monitors that hae access to text descriptions of storage locations (for example, from the storage system schema) should set the DESCRIPTION attribute of the storage location to the text description. The Tioli Priacy Manager serer uses the alue of this attribute, if it exists, as a hint for the storage location, and can display this hint in the GUIs. Storage location aliases In some storage systems, the same information can be accessed in different ways. For example, database information can be accessed by table/column. If specialized iews are constructed, the same information can be accessed by iew/column, as well as by stored procedures, which hide the actual database schema implementation. LDAP directories permit access to attributes based on the attribute name such as organizationunit or an abbreiation, such as OU. Storage location attributes can be used to list all of the aliases that refer to a particular storage location. Primary key indicator A monitor can use an attribute to indicate which storage locations are primary keys. Foreign key information A monitor can use an attribute to indicate which storage locations are foreign keys and to indicate the storage location of the foreign key references. Storage location record names Monitors might need to understand the arrangement of storage locations within the storage system, such as storage locations in the same database table or storage locations that are attributes of the same directory object. While the monitor s storage location naming scheme might reflect this arrangement of storage locations, using a storage location attribute, such as RECORD_NAME, could preent the monitor from haing to perform repeated parsing of storage location names. Sharing information among monitor parts If a monitor is designed with multiple parts, as described in Multiple part monitors on page 16, storage location attributes can be used to share information among the monitor parts. That is, the monitor part that registers the storage locations with the Tioli Priacy Manager serer can record the storage location attributes for the storage locations to make the attributes aailable to the other monitor parts when those monitor parts retriee updated storage location information from the serer. In this way, the multiple part monitor can use the Tioli Priacy Manager serer as a data store for storage location information so that all monitor parts are using consistent storage location information. Register monitors All monitors must register with the Tioli Priacy Manager serer. When a monitor registers with the serer, it must: Proide a unique name for the monitor. Define the type of information the monitor can proide to identify the PII accessor in the monitored storage system. This accessor information is proided as a list of one or more attribute names. For example, a database monitor might define DataBaseUser, because an indiidual accessing information in the database is required to proide a database user ID. Accessor attribute names are 12 IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide

23 specific to the monitor that registers them. Each monitor must register the set of attribute names to be used by that monitor. Specify whether or not the monitor supports real-time policy enforcement. Proide monitor attributes in the form of key/alue pairs. These attributes are for the sole use of the monitor. Register storage locations After a monitor registers with the Tioli Priacy Manager serer, it must also register the list of storage locations in the storage system with the serer. The monitor must proide the following information for each storage location it registers: A unique name for the storage location A set of zero or more monitor-specific storage location attributes Retriee monitor and storage location information After a monitor registers itself and its storage locations with the Tioli Priacy Manager serer, an administrator uses the Tioli Priacy Manager serer GUIs to add information to the monitor and storage location definitions. For example, the administrator performs the following tasks: Defines the polling interal for the monitor Identifies which storage locations contain PII and the type of PII contained in the storage location Identifies which storage locations contain user keys and user IDs. Defines the conditional information associated with storage locations and how to ealuate it (for example, opt in or opt out choices) Changes the monitor s deployment status (for example, to actiate a monitor) Enables or disables real-time enforcement checking In other words, the information proided by the monitor during the registration process is only a subset of the total information maintained for the monitor and its storage locations. The monitor does not supply any policy-related information. This information is proided by the administrator after the initial registration process, and some of this information is required by the monitor. Therefore, a monitor must be able to retriee monitor and storage location information from the Tioli Priacy Manager serer. This information should be retrieed during monitor startup and might need to be updated while the monitor is running based on the result of the monitor polling function. Poll the serer for updates The monitor and storage location information retrieed from the Tioli Priacy Manager serer should be refreshed continuously. Monitors are responsible for polling the Tioli Priacy Manager serer for changes to this information. The polling interal used by the monitor is configured by the Tioli Priacy Manager serer administrator. The Tioli Priacy Manager graphical user interface allows an administrator to define monitor properties, such as the polling interal, for each monitor. The interal is stored along with other monitor properties, such as name, description, and deployment status. Chapter 2. Designing a monitor 13

24 Report submission and access actiity The main purpose of monitors is to detect the submission of new or updated PII to the storage system and the access to PII in the storage system and to report these actiities to the Tioli Priacy Manager serer for recording. For submission actiity, the monitor detects the storage locations that are submitted and determines which ones contain PII. If any of the submitted storage locations contain PII, the monitor notifies the Tioli Priacy Manager serer of the submission (typically on a different thread of execution, so as to not cause a significant delay in the submission request), passing it: A list of all the PII storage locations submitted A list of user keys. The list must include all of the user keys aailable with the submitted storage locations, and might also include additional user keys obtained by the monitor. A list of the ealuation results for the conditional information associated with each storage location to assist the Tioli Priacy Manager serer in determining the context states at the time the PII was submitted. A timestamp representing the date and time of the submission. The timestamp must be expressed in coordinated uniersal time (UTC). For access actiity, the monitor detects the storage locations that were accessed and determines which of the storage locations contain PII. If any of the accessed storage locations contain PII, the monitor notifies the Tioli Priacy Manager serer of the access (typically on a different thread of execution, so as to not cause a significant delay in the access request), passing it the same information that is proided for submission actiity. The monitor also proides information to help identify the PII accessor. This PII accessor information is in the form of a list of attribute name/alue pairs, where the attribute names are the accessor attributes defined by the monitor during monitor registration. Enforce priacy policy statements The Tioli Priacy Manager serer is designed to support two modes of monitoring storage systems: audit and enforcement. For the audit mode, monitors notify the serer each time PII is accessed or changed in the storage system, which allows the serer to maintain an audit trail of PII actiity and to track whether or not each PII access is in conformance with the goerning priacy policies. For the enforcement mode, monitors use the serer to enforce priacy policies by requesting real-time conformance checks each time PII is accessed and by denying access to PII that is not in conformance with goerning priacy policies. All monitor implementations are required to support the audit mode of monitoring, but Tioli Priacy Manager does not require monitor implementations to support the enforcement mode. The enforcement mode requires a more complex monitor implementation and might hae a significant impact on the performance of applications using the storage system because each access to PII causes the monitor to request a policy conformance check from the Tioli Priacy Manager serer before information is returned to the application. Because of the potential performance impact associated with the enforcement mode of monitoring, Tioli Priacy Manager allows an administrator to turn off real-time enforcement for any monitor. Therefore, if a monitor implementation supports real-time enforcement mode, the monitor must be able to run in audit mode if it is configured to do so by the administrator of the Tioli Priacy Manager serer. 14 IBM Tioli Priacy Manager for e-business: Monitor Deeloper s Guide