Confidentiality and Security Levels

You are now familiar with the way in which security is implemented in ENOVIA V6. Security can be taken one step further by defining and implementing a corporate level of confidentiality referential in order to ensure that access to data is granted in compliance with confidentiality regulations.

A company typically sets up a hierarchy of confidentiality levels like this:

In the above example:

• level 0: access is granted to all data on this level, it is public
• level 1: data on this level is considered sensitive
• level 2: data on this level is considered critical
• level 3: data on this level is considered strategic and is the maximum security level.

Security mechanisms (policies and rules) in ENOVIA V6 enable accreditation based on P&O information (project, person) to ensure that project members and/or persons are granted access to the appropriate V6 data.

To support security levels, all VPLM entities are assigned a confidentiality attribute (V_sec_level). This attribute will be an integer, and the default value zero "0" or null is interpreted during read access evaluation as public data, therefore visible and queryable: you will be able to search for level 0 data in your search query. Level 0 data is public data, so from a security level standpoint, all project members can search it.

A table is provided in the Resource section of the web administration console to store all confidentiality values for a given project. Each value is an integer, associated with an alias (for example, sensitive, top secret...) and a description (used as a confidentiality message during a V6 session). You can add rows to and remove rows from the table.

Confidentiality level valuation is based on the integer order, associated with specific filter expressions within the policy and/or rule based on standard MQL syntax.

The project and person P&O objects are assigned an accreditation property, visible when creating and updating projects and persons. The property is visible when browsing profiles. P&O import syntax also supports user/project accreditation.

Finally, you have to perform a number of additional administration steps in a specific order in order to fully deploy security levels:

• mask customization is required to create, modify, query and read confidentiality levels on any targeted PLM objects (products, documents, etc.)
• customization of the New command dialog box for the targeted types is required to retrieve confidentiality levels created in the P&O web administration console
• policy and rule customization is required to filter data based on data confidentiality level.

For more information, refer to Managing Confidentiality and Security Levels.