Writer instructions

Purpose

Use this page to display a banner announcement on each page of the space. Create the Space announcements page in the master space, outside of the Home branch.

You can version the Space announcements page to enable different banners to be published into different target spaces, however, the banner that is displayed in the versioned (master) space itself only displays the most recently-published banner.  If you find errors in the banner area of your versioned space and you are sure the Space announcements page is set up correctly, try publishing the page to the same space.

For more information, see Space-announcements-banners.

Removing

When an announcement is no longer needed, remove the BMC Space Banner macro.

Translation

Localized spaces using the L10n Viewport theme must change the name of this page to Space announcements l10n.  See Configuring-the-Scroll-ViewPort-theme-for-translated-spaces.

Usage

Choose one or none of the following BMC Space Banner macros.

If your space requires another kind of announcement, you can use this page in coordination with your team lead and editors.

When should I use a space announcement banner?

Use the space organization announcement after you change the content from a book-like organization (such as User Manual, Configuration Manual, and Administration Guide) to the product model.

Use the latest version announcement to push traffic to later versions. You do not need to add this to every previous version, but if you have a specific reason that you want users to be aware—for example, Google searches show content for an obsolete version—use the banner to help users find a relevant version.

When an announcement is no longer needed, remove the BMC Space Banner macro.

Space announcement This documentation space provides the same content as before, but the organization of the content has changed. The content is now organized based on logical branches instead of legacy book titles. We hope that the new structure will help you quickly find the content that you need.

Data Disguise function


Option 7, Data Disguise, enables you to disguise extracted data from a Db2 table and works in conjunction with File-AID/Data Solutions and File-AID Data Privacy. we recommend installation and/or configuration of the current GA versions of the three products to take advantage of recent enhancements. File-AID/Data Solutions must be installed at your site to access Option 7, Data Disguise.

Using File-AID for Db2 with File-AID Data Privacy (Using DPR) 

File-AID Data Privacy is a component of the Topaz Workbench and provides the ability to easily create Data Privacy rules for your Enterprise files or databases.

Note

Topaz Workbench: The Compuware Workbench has been replaced by the Topaz Workbench. The Topaz Workbench provides all of the functionality of the previous Compuware Workbench as well as any additional chargeable functionality.

File-AID Data Privacy protects your data by concealing sensitive information while maintaining data integrity, table relationships, and data format during processing. For example, a female employee name field can be replaced by a recognizable fictitious female name or a nonsensical set of characters. File-AID Data Privacy:

  • Builds rules used to disguise data for a defined collection of fields.
  • Provides a graphical means for applying data encryption to fields for supported data connections.
  • Allows you to replace field values with consistent valid data via key encryption (using an encoding key value) or via substitution with meaningful readable data.
  • Allows you to age dates by adding or subtracting from the date or replacing the date with a specific date.

File-AID Data Privacy is Compuware's solution for addressing all of your data privacy needs whether you have files or databases on distributed machines or on a mainframe computer. File-AID Data Privacy allows you to protect your data by concealing sensitive information while maintaining data integrity, table relationships, and data format during processing. You can:

  • Build rules to disguise data for a defined collection of fields.
  • Replace field values with consistent valid data via key encryption or via substitution with meaningful readable data.

Refer to the File-AID Data Privacy documentation on how to define Dynamic Privacy Rules (DPR) that can be applied to File-AID for Db2 extracts. Once the Dynamic Privacy Rules have been defined, you can disguise data during an extract using File-AID Option 2 Extract (see also Disguise Extract File) or disguise an existing extract file with File-AID for Db2 Option 7 Disguise Existing Extract File (see also Disguise-Existing-Extract-File).

Important

In order to execute batch jobs using File-AID Data Privacy, the job submitter must have a RACF record with an OMVS segment for z/OS UNIX (or equivalent if using a different security package). This can be done with BPX.DEFAULT.USER, but note that z/OS v1.13 is the last release to support BPX.DEFAULT.USER. The CPUTIMEMAX value in the OMVS segment must be large enough to accommodate the File-AID Data Privacy jobs being run.

Using File-AID for Db2 with File-AID/Data Solutions (Using DCF)

File-AID/Data Solutions provides the functionality to disguise data fields through aging, encryption, translation, data generation, and field exits. The process of defining what data is sensitive and how each field is to be disguised requires careful planning and should be handled by someone in a privacy administration role.

For each data field being disguised, disguise criteria must be defined with the specific details of the disguise action. Disguise criteria can be defined for Db2 and MVS objects. The disguise criteria definition process is consistent with File-AID/RDX, however, File-AID for Db2 will only extract and disguise Db2 data.

Once the disguise criteria have been defined they can be stored in the Disguise Criteria File. The Disguise Control File identifies what disguise criteria is to be used and where it is stored. The Disguise Control File can be made available to all users of File-AID for Db2, and can be shared by other File-AID products. As part of defining an extract, you have an option to disguise the extract. When the disguise option is selected and a Disguise Control File specified, all disguise criteria defined for the object being extracted will be applied.

What Is Disguise?

There are many different ways to disguise data. The File-AID/Data Solutions product provides disguise functionality and groups three functions together as disguise functions: encryption, aging and translation. Encryption is really character substitution where a numeric position is replaced with a numeric position and an alphabetic position is replaced by an alphabetic position. Aging is used to disguise date fields by incrementing or decrementing the original date. Translation is replacing the original data with other data stored in a translate table. There are several different ways to determine which data from the translate table is used as the replacement value. Translate always uses some data as input to determine which entry is selected from the translate table and then replaces the data in the requested fields with data stored in the translate table.

In addition to the three functions identified within File-AID/Data Solutions as disguise techniques, data generation and field exits are also valid ways to disguise data. Data Generation can generate sequential or random values appropriate for the data type; it can also generate new values based on a table of valid values. Field Exits are user written exit routines that can take whatever action is required to disguise the data.

Which disguise function to use is determined by the three R's of disguise: repeatable, reversible, and readable. Repeatable means that the same input value must always return the same value or set of values; the same data from multiple objects or files must be disguised the same. Reversible means that there must be a way to get back to the original data value. Readable means that the data must look valid to the human eye; name fields should contain name information not just a random string of characters.

Planning Disguise Strategy

Disguise is much more than a new product feature. Being successful will require careful planning and understanding your related data and disguise requirements.

The first part of this process is deciding what data is considered sensitive data and determining how it should be disguised. Once the sensitive data fields have been identified, the next step is to locate all the tables and files in which the sensitive data exists. The File-AID for Db2 relationship file can assist you to identify the related objects and fields.

Most likely, you will define disguise criteria for a specific purpose. For example, you establish disguise rules that are to apply whenever data is moved from the production to any test region. Once a strategy has been defined and disguise criteria created, many users would likely share the criteria; every user extracting data from the production environment would be directed to use the defined disguise rules. Any File-AID for Db2 user can create disguise criteria as long as they have authority to write to the Disguise Control File.

File-AID for Db2 and File-AID/Data Solutions are tools for implementing a data protection strategy; before any disguise criteria can be defined, the customer has to design a data protection strategy. File-AID for Db2 assumes that work has been done and supports the implementation of the strategy.

When related fields are considered sensitive data there are additional planning considerations. It is your responsibility to choose a disguise method that will produce appropriate results for the related field. If the related field is a key field, it is likely that the replacement value will need to be unique. You must choose a technique that produces unique values; encryption and some translate methods will fulfill this requirement.

Enforcing Disguise

File-AID for Db2 does not place restrictions on who is authorized to extract and disguise data. However, the user running the extract must be able to read the data in order to run the extract. If they can read the data to extract, they can likely read the data in other ways as well.

It will be a user's responsibility to request the extract file be disguised and to provide the appropriate Disguise Control File. If the Disguise Control File does not include criteria for an object being extracted, no disguise will be applied to that object.

Creating Disguise Criteria

All criteria used by the File-AID for Db2 disguise function must be created through the bridge to File-AID/Data Solutions from File-AID for Db2. Criteria created directly within File-AID/Data Solutions is not usable from File-AID for Db2 or File-AID/RDX disguise.

The Data Disguise function within File-AID for Db2 provides a central point of control for defining disguise criteria and will provide the necessary layout information to File-AID/Data Solutions. The actual panel on which the criteria are entered will be a File-AID/Data Solutions panel. The criteria will be saved in a Disguise Criteria File.

Criteria creation is always done by object. Each object must be uniquely identified, which for Db2 objects includes the location, creator and object name. There can be three different types of criteria: related, associated and unrelated. File-AID for Db2 determines what type of disguise criteria will be created based on the fields selected for disguising.

Unrelated Criteria

Unrelated criteria is straightforward; it applies to a single object and must be defined for any field in the object that is to be disguised. Unrelated criteria always applies to a single object and cannot be shared.

Related Criteria

Related criteria can be more involved because it is defined once and the definition propagated to related fields in other objects. File-AID for Db2 does not propagate disguise at execution time, so any criteria defined on related fields must be simple criteria. Refer to Simple and Complex Disguise Criteria for more information.

Associated Criteria

Associated criteria are always defined on a single unrelated field and can be applied to fields in different objects; identification of the additional data locations is a manual process.

Simple and Complex Disguise Criteria

Simple disguise criteria are entirely determined by the contents of a single field, and are repeatable. If the value of "ABC" is replaced with "123" once, and the same disguise rule is applied again, it will yield the same value, "123", every time.

Any disguise criteria that are not repeatable, or that are not entirely determined by the contents of a single field, are called complex criteria. This includes any disguise rule for a field based on the contents of another field. It also includes the use of a partial column in a relationship when the disguise of one part is based on the contents of another part. It also includes the use of the File-AID/Data Solutions Data Generator because the value generated for the current column is affected by the value generated for the previous column. Also any rule that involves randomization is complex, because it is not repeatable across multiple objects.

All File-AID for Db2 extracts are single object extracts, so the disguise criteria defined for related fields must be able to be applied to each object independently. Simple criteria can always be applied to each object and produce the same value for each object. When complex criteria is defined an attempt is made to apply the criteria. If the object being disguised contains the required fields, then the criteria is applied.

When disguise criteria are created, the disguise rules are propagated to all related objects defined in the Relationship File. When complex criteria is applied to an object other than the object where the criteria was created, the disguised values may be different than the value returned for the original object. When relational integrity is to be maintained between tables you must define simple criteria or use File-AID/RDX to extract and disguise the related set of data.

Disguise Control File and Disguise Criteria Storage

The Disguise Control File determines which disguise criteria is applied to which object. The actual criteria created by File-AID/Data Solutions will be stored in the Disguise Criteria File. Refer to Disguise Criteria File for more information.

The Disguise Control File has the following characteristics:

File organization

VSAM-KSDS

Record format

Variable-blocked (RECFM=VB)

Logical record length

Maximum record size is 6168

Key length

255

The Disguise Control File can be created with Option 4 Control - Allocate Disguise Control File. Refer to Allocate Disguise Control File for more information.

A Disguise Control File contains a set of disguise rules for specific objects. Maintaining multiple Disguise Control Files provides flexibility in how you choose to manage the disguise process. You may choose to define different sets of disguise criteria for the same objects by storing them in different Disguise Control Files. For example, one set of disguise criteria could be defined for production data being moved to the training subsystem and a different set of disguise criteria could be defined for production data being moved to the offshore test subsystem. The disguise rules for data being loaded for training purposes may be much less extensive than the disguise rules required if the data is to be sent offshore for testing. Multiple Disguise Control Files allow customers to define protection that is appropriate for the environment where the data will be loaded.

File-AID for Db2 generates the member name for related and unrelated criteria; the user can provide a name for associated criteria.

The related, associated and unrelated disguise criteria are stored separately. This allows the correct disguise criteria to be applied for each object and also allows the same disguise criteria to be applied to multiple objects for related and associated criteria. At extract time, you specify the Disguise Control File and all disguise criteria defined for the objects being extracted will be applied as defined in the Disguise Control File.

Disguise Criteria File

The Disguise Criteria File (data set) contains disguise criteria information using File-AID/Data Solutions. The Disguise Criteria File must be a PDS. Optionally, you can add selection criteria information to your disguise criteria member. Disguise criteria and XREF members can be stored in the same file.

The Disguise Criteria File can be created with Option 5, Criteria - Allocate Disguise Criteria File. Refer to Allocate Disguise Criteria File for more information.

Warning

Disguise criteria files for related extracts should be maintained only through the bridge to File-AID/Data Solutions using Option 7 . Editing a disguise criteria file with ISPF causes the file to be unusable by File-AID/Data Solutions.

The Disguise Criteria File has the following characteristics:

File organization

Partitioned (DSORG=PO)

Record format

Variable-blocked (RECFM=VB)

Logical record length

300 (LRECL=300)

Minimum block size

304 (BLKSIZE=304)

Db2 XML and LOB Data Type Considerations

DCF Disguise Criteria cannot be created on XML and/or LOB columns.

XML and CLOB column data in extracts can only be disguised with Dynamic Privacy Rules (Disguise Option 2, DPR). Dynamic Privacy Rules must be defined with the File-AID Data Privacy component of the Topaz Workbench (see also Using File-AID for DB2 with File-AID Data Privacy (Using DPR)). Disguising DBCLOB columns is not supported.

Unicode Considerations

DCF Disguise Criteria cannot be created on Unicode columns or fields.

Unicode data in extracts can only be disguised with Dynamic Privacy Rules (Disguise Option 2, DPR). Dynamic Privacy Rules must be defined with the File-AID Data Privacy component of the Topaz Workbench (see also Using File-AID for DB2 with File-AID Data Privacy (Using DPR)).

MVS Considerations

You can define disguise criteria on MVS files but that criteria will not be used by File-AID for Db2; File-AID/RDX is required to extract and disguise MVS data.

Suggested Disguise Approach

To ensure consistent disguise result, it is recommended to have a Privacy or Security Administrator identify:

  • The objects that contain sensitive data that needs to be disguised
  • The data fields in those objects that need to be disguised
  • The relationship file that is the most comprehensive for the objects to be disguised
  • One Disguise Control File that will contain the disguise information for all objects to be disguised (Only use multiple Disguise Control Files when the same objects needs to have different disguise criteria.)
  • Disguise Criteria and Business Rules files

Then the Privacy or Security Administrator can:

  • Build the object list of objects to be disguised
    • Specify the object to be disguised
    • Use ObjectIn and related commands to add other objects to the list
  • Use the most suitable disguise method and criteria for each field to be disguised
  • Create secondary data (translate tables, encryption exits etc.)
  • Create Related, Associated, or Unrelated Disguise rules for each object and field to be disguised
  • Test the disguise criteria with test extracts
  • Refine the disguise criteria where necessary
  • Verify disguised extract results using the File-AID for DB2 Data Privacy Summary Report and Audit Trail Report files
  • Set RACF security for the Disguise Control File so only authorized users can make changes, and regular File-AID for Db2 users can then use it to execute extract requests with disguise or disguise already existing extract files.

Note

RACF security: The Privacy or Security Administrator, or anyone using Option 7.1 (Create and Modify Disguise Criteria), requires UPDATE or greater RACF authority to the Disguise Control File. A “Regular” File-AID for Db2 user requires READ or greater RACF authority to execute the disguise function in batch.

Regular File-AID for Db2 users should request the Disguise Control File name from the Privacy or Security Administrator.

This section provides information about the following topics:

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*