立即与支持人员聊天
与支持团队交流

Classification Module 6.1.1 - User Guide

Introduction Deploying Classification in Identity Manager Configuring Classification: Taxonomies, Categories, and Rules
An Overview of Classification Configuration Steps Required to Implement Classification Creating Taxonomies Setting Up Manual Categorization Implementing Rules for Automated Categorization Classifying Resources When Do Categorization and Classification Occur? Importing and Exporting Taxonomies Working with a Taxonomy XML File Managing the Life Cycle of Taxonomies and Categories Advanced Rule Applications
Working with Categorized Resources Appendix A: PowerShell cmdlets Appendix B: Oracle Configuration Appendix C: Classifying Data with Data Governance Templates Glossary

Modifying a Production Taxonomy

Categorization using Quest One Identity Manager is intended to help you identify risks posed by the contents of your unstructured data. Using categorization, you gain information about the content of your data and the risks it poses, and then using policies, you can control access to resources based on content or risk. Attestations add more security by validating that the categorizations are correct.

Because of the interplay of categorizations, risk and policies, it is important to only deploy changes you want business owners to see. Any change to a category can change a business owner’s categorizations, which could lead to confusion or unnecessary manual overrides during the time you are testing your changes. For this reason, you should avoid making changes to categories that are visible to business owners. Instead, set up a test environment with its own Data Governance server.

By maintaining a separate test environment, you can predict the results of your changes across your environment, and test right through to the policy level. You can scan a set of carefully built test resources, and/or scan documents in the live environment and see the full categorization results. Business owners and other users will not have access to your environment, so you can comfortably make and test changes.

For additional protection, you may wish to store backup copies of exported production taxonomy XML files, or even keep them in source control. This allows you to restore your system in the event of a hard drive failure or other catastrophic event.

When you use a test environment, you will need some way of ensuring that all elements of the production system are present in the test environment. The simplest way to do this is using a taxonomy export and import system. At any given time, your test environment may have more under development than you want to deploy, so you may need to modify the exported XML manually before importing it to your production environment.

Here is a sample workflow you could use in this scenario:

Step Description
If necessary, ensure your test environment is up to date by exporting your production taxonomy to your test environment. See Importing and Exporting Taxonomies for details.
This step is only necessary if changes have been made in the production environment, which is not recommended.
You should export all taxonomies to ensure that all shared elements can be properly tested. If your test taxonomy contains new categories that have not yet been deployed, they will not be overwritten.
Make changes in the test environment as required. See Working with Taxonomies, Working with Categories, Managing Rules in the Classification System and Advanced Rule Applications.
Test your changes, taking into account all affected categories. See Testing and Reviewing Automated Classification for details on the tools available to you for testing.
For extra protection, unpublish all new categories in the test environment. This allows you to turn them on in the production environment when you are ready, not immediately on importing the changes. See Setting Up Manual Categorization and Making a Category Available to the Automated System for more details.
Trim your template XML file. You may have elements under development, such as a new category or modified rule, that you would prefer not to import into the production environment. You can manually trim this from the template XML file before importing it. For more information, see Working with a Taxonomy XML File.
Import affected taxonomies into the production environment. Importing includes rules and entities. This will fully update your production environment.
If you chose to unpublish categories before exporting, you can publish categories as you are ready to bring them online.
All changes will now be live in the system, and categorization will begin with the next scanned document.
To ensure that your changes have the expected behavior, you should monitor the new categorizations carefully. For more information, see: Determining Why Categorizations Were Applied to a Resource, Viewing Categorized Resources and When Do Categorization and Classification Occur?.

Advanced Rule Applications

For more complex taxonomies, a deeper understanding of how rule and category settings affect categorization may be required. For a simpler overview, see How Rules Affect Categorization. Categorization occurs if:

Categorization calculation

By leveraging the power of these variables, and refining your extractors, you can manipulate categorization.

Threshold Considerations

In the simple example provided in Rule Example Manipulating Threshold and Rule Weight, thresholds and rule weights started with simple values of 1, and then were increased or decreased depending on the number of rules for which you required a match. However, if you find this restrictive, you can use any range of numbers for your thresholds. Remember that you need to design your threshold so that your rule weights and the match strength of the rule will combine to trigger categorization. If you use a large number such as 100 for your threshold, for example to remove the need to use decimals in the match strength, ensure your match strengths and rule weights scale appropriately.

Mutual Exclusivity Considerations

When categories are set to mutually exclusive, if more than one potential category exists, the one with the highest combined rule score will be applied. This means that every subcategory should have a similar potential rule weight score, otherwise categories may be applied inaccurately. Consider two mutually exclusive subcategories. Based on their threshold settings, they are both a potential match. Examine the settings outlined:

SubCategory A Match Strength Rule Weight Rule Score
(Match Strength x Rule Weight)
Rule 1 1 1 1
Rule 2 1 1 1
Rule 3 1 1 1
Rule 4 1 1 1
Total 4
SubCategory B Match Strength Rule Weight Rule Score
(Match Strength x Rule Weight)
Rule 1 1 50 50
Rule 2 1 50 50
Rule 6 1 50 50
Rule 7 1 50 50
Total 200

SubCategory B would always be applied in this case. This may not be your intention; for example you may want the category with the most rules that match to be applied. In this case, you could use the exact same variables for both subcategories. Generally, it is advisable to keep all your variables to the same scale across a taxonomy, particularly one in which you are implementing mutual exclusivity.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级