个人信息保护

如果您必须遵守RGPD,这里有一些提示可以帮助您...

iTop中的个人数据的库存

人对象中的人数据

iTop中的大多数个人信息都存储在个人对象中。在标准iTop数据模型中,这些数据包括:

场代码标签领域描述
email发送邮件发送邮件的人的地址
employee_number员工编号员工编号或公司内部使用的任何标识符
first_name名字人的名字
function职能职能该人员的职称
location_id位置人员的位置(链接到位置对象)
manager_id经理人的经理(链接到人对象)
mobile_phone移动电话手机号码
phone电话固定电话号码
picture图片人的照片

由于iTop的关系性质,因此不应将个人对象中存储的信息复制到其他地方。下面列出了此原则的一些例外:

历史上的个人数据

对Person对象的所有修改都记录在此Person对象的历史中,从而存储了一些个人信息。您可以使用以下OQL对象列出对给定的个人对象所做的所有更改:

SELECT CMDBChangeOp WHERE objclass='Person' AND objkey=:person_id

其中:person_id是个人对象的标识符。与联系人关联的用户账号执行的所有修改也都跟踪进行更改的联系人的名称((i.e. friendlyname)。

SELECT CMDBChange WHERE userinfo =:person_name

其中:person_name是完整名称(i.e. friendlyname),例如“ Claude Monet”。

案例日志中的个人数据

iTop中的每个“案例日志”字段存储有关在案例日志中创建每个条目的人员的信息(在iTop的当前版本中,无法修改案例日志条目)。案例日志中记录的信息(针对每个条目)包括:

  • 修改的日期和时间
  • 进行修改的人的全名(修改时)
  • 进行修改的人员对象的标识符

例如,如果与人员“ Claude Monet”(id = 3)相关联的用户创建了两个案例日志条目,则案例日志的内容将存储在数据库中,如下所示:

========== 2018-05-09 11:38:45 : Claude Monet (3) ============
<p>This is the second entry of the case log</p>
========== 2018-05-09 11:38:27 : Claude Monet (3) ============
<p>This is the first entry of the case log</p>

发送邮件中的个人数据通知

只要iTop将通知作为发送邮件发送,该信息就会记录在事件通知电子邮件对象中。此对象记录发送到邮件对象的发送邮件。该对象包含它被寻址的人的发送邮件地址(在TO,CC或BCC中)以及所发送消息的内容。 邮件通知对象还存储发出它的日期。

数据流量

处理个人数据时,重要的主题之一是在组织中记录个人数据的流动。本文档(以及iTop本身)无法为您提供此流动的文档,因为每个流动都是特定的,并且依赖于流程和操作iTop时已实现的集成。但是,iTop提供了一些功能,可以帮助您将流动的信息记录在数据中。

RESTTJSON Web服务日志

您可以通过在iTop配置文件中将配置参数'log_rest_service'设置为true来通过REST/JSON服务执行操作。设置此参数后,每个REST/JSON配置将在iTop服务中创建EventRestService对象。该对象记录:

  • 运维的日期时间
  • 用户账号用于执行运维
  • JSON输入参数
  • 运维的输出(代码,消息和-JSON输出的修剪后的版本)

使用所有信息,您可以通过REST/JSON Web服务(如果有)确定流动个人信息。

启用‘log_rest_service’可以在Web服务的性能上拥有大量的影响度,并增加iTop数据库的空间使用。因此,建议仅在有限的时间内打开此特性以进行审核。

从iTop 2.5开始,只有带有简档“ REST Services用户”的用户帐户可以执行REST/JSON操作。

同步数据来源列表

您可以通过搜索搜索“目标类”为“人”的同步数据源,轻松列出所有更新人的导入的同步数据源。可以通过“管理工具同步数据源”或运行以下OQL数据来执行此搜索:

 SELECT SynchroDataSource WHERE scope_class='Person' 

每个数据源均跟踪其操作的完整日志,包括其运行的日期时间和每次运行所执行的操作的总结(作品/更新/删除)。
请注意,如果为同步数据源指定了“用户”,则只有指定的用户账号才能执行此同步。

限制大宗出口(和大宗进口)

  • 只有在人员上具有能力“批量读取”的用户帐户才能执行人员列表的导出。
  • 同样,只有在Persons上具有能力“批量修改”的用户帐户才能对Persons执行CSV导入。
  • 可以使用每个用户账号的详细信息上的“授予矩阵型”选项卡查看这些功能。

个人数据的清理

要完全清除与某人有关的数据,必须执行以下操作:

  1. 删除与此人对应的人对象,这还将删除有关此人的历史信息。
  2. 删除此人创建的案例日志条目
  3. 删除与发送给此人的电子邮件相对应的邮件通知对象

但是,这些操作活动受到限制:

  • 关于目标人员对象与iTop数据库中其他对象之间的关系的依赖,如果不遵守某些其他对象上的指定替换人员以遵守数据库集成约束的条件,则无法删除人员对象。
  • 删除案例日志条目目前尚未在iTop中实现,并且对于SQL查询而言并非易事,因为案例日志文本必须与另一个称为案例日志索引的字段保持一致。
  • 可以在一个SQL查询中完成更新CMDBChange对象以替换对联系人名称的引用,因为表中只有一个字段“ userinfo”要匿名化。由于此字段仅显示给终端用户,而不显示给iTop中的任何引用的用户,因此没有完整性约束,并且任何价值都可以放在该字段中。
  • 由于一个发送邮件通知可能会发送给多个人(在TO,CC和BCC中),因此删除一个这样的通知不仅会影响目标用户,还会影响其他用户。

由于上述限制,“假名化”方法似乎比完全擦除个人数据更现实。

个人数据的别名

  • 通过用匿名值(恒定值或随机值)替换其所有必填字段中的值来使Person对象匿名
  • 清空所有非必填字段(例如位置,经理,电话号码,n:n关系)
  • 在不更改文本长度的情况下,通过删除对人员的所有引用来对案件日志条目进行假名化,以保留带有案件日志“索引”字段的一致性。
  • 删除人员的历史记录(CMDBChange CMDBChangeOp),以删除字段的“先前值”,这将有助于恢复这些值。
  • 包含人名的CMDBChange“ userinfo”字段的匿名化。
  • 超过(较短)保留期(3个月??)的所有邮件通知对象的删除

个人数据的导出

  • 可以使用iTop的标准导出特性导出人员详细信息。
  • 可以通过搜索每个包含案例日志的对象类别(即,每个工单类别并搜索包含“联系人的名称”的“外部留言”)来导出案例日志条目。

可以使用“运行查询”菜单和类似以下的OQL来实现:

SELECT UserRequest WHERE (public_log LIKE :name OR private_log LIKE :name) 

将:name参数的价值指定为%联系人_friendlyname%。

例如,对于导出,所有用户请求以及Claude Monet在案件日志中的条目,OQL查询将为:

 SELECT UserRequest WHERE (public_log LIKE '%Claude Monet%' OR private_log LIKE '%Claude Monet%') 

可以使用OQL查询列出和导出通知电子邮件:

SELECT EventNotificationEmail WHERE 
      TO = 'email_address' 
   OR cc LIKE '%email_address%' 
   OR bcc LIKE '%email_address%'

原贴链接:https://www.itophub.io/wiki/page?id=2_7_0%3Aadmin%3Argpd


Managing Personal data in iTop

If you have to comply with RGPD, here are some tips to help you…

Inventory of personal data in iTop

Personal data in the Person object

Most of the personal information in iTop is stored in the Person object. In the standard iTop datamodel, these data consist of:

Field codeLabelDescription of the field
emailEmailEmail address of the person
employee_numberEmployee numberEmployee number or any identifier used within the company
first_nameFirst NameFirst name of the person
functionFunctionFunction / job title of the person
location_idLocationLocation of the person (link to a Location object)
manager_idManagerManager of the person (link to a Person object)
mobile_phoneMobile PhoneMobile phone number
phonePhoneFixed phone number
picturePicturePicture of the person

Due to the relational nature of iTop, the information stored in the Person object is not supposed to be duplicated elsewhere. The few exceptions to this principle are listed below:

Personal data in the History

All modification to the Person object are recorded in the history of this Person object, thus storing some personal information. You can list all the changes made to a given Person object using the following OQL query:

SELECT CMDBChangeOp WHERE objclass='Person' AND objkey=:person_id

Where :person_id is the identifier of the Person object. All the modifications performed by the user account associated with the contact also keep track of the name (i.e. friendlyname) of the contact who made the changes.

SELECT CMDBChange WHERE userinfo=:person_name

Where :person_name is the complete name (i.e. friendlyname) of the Person, for example “Claude Monet”.

Personal data in the case logs

Each Case Log field in iTop stores information about the person who created each entry in the case log (in the current version of iTop it is not possible to modify a case log entry). The information recorded in the case log (for each entry) contains:

  • The date and time of the modification

  • The full name (at the time of the modification) of the Person who made the modification

  • The identifier of the Person object who made the modification

For example, if the user associated with the Person “Claude Monet” (id=3) created two case log entries, the content of the case log will be stored in the database as follows:

========== 2018-05-09 11:38:45 : Claude Monet (3) ============
<p>This is the second entry of the case log</p>
========== 2018-05-09 11:38:27 : Claude Monet (3) ============
<p>This is the first entry of the case log</p>

Personal data in Email notifications

Whenever a notification is sent by iTop as an eMail, the information is recorded in the EventNotificationEmail object. This object records the email sent to the mail server. This object contains the email addresses of the person it was addressed (in TO, CC or BCC) and the content of the message sent. The EmailNotification object also stores the date at which it was emitted.

Data flows

One of the important topics when dealing with personal data is to document the flow of personal data within your organization. This document (and iTop itself) cannot document this flow for you since each use case is specific and depends on the processes and integrations put in place when operating iTop. However, iTop provides several features which can help you document and control this flow of information.

log of REST/JSON web services

You can audit the operations performed via the REST/JSON services by setting the configuration parameter ‘log_rest_service’ to true in the iTop configuration file. Once this parameter is set, every REST/JSON operation will create an EventRestService object in the iTop database. This object records:

  • The date/time of the operation

  • The user account used to perform the operation

  • The JSON input parameters

  • The output of the operation (code, message and – a trimmed version of the - JSON output)

Using all the information you can determine the flow of personal information via REST/JSON webservices (if any).

Enabling ‘log_rest_service’ can have a significant impact on the performance of Web services and increase the iTop database space use. Therefore it is recommended to turn on this feature for auditing purposes only during a limited period of time.

Starting with iTop 2.5 only the user accounts with the profile “REST Services User” can execute REST/JSON operations.

List of Synchronization Data Sources

You can easily list all Synchro Data Sources which import of update Persons by search searching for Synchronization Data Sources which “Target Class” is “Person”. This search can be performed through the “Admin tools / Synchronization Data Sources” or by running the following OQL query:

 SELECT SynchroDataSource WHERE scope_class='Person' 

Each data source keeps track of a complete log of its operations, including the date/time it was run and the summary of the operations executed for each run (creations/updates/deletions).
Note that if a “User” is specified for a Synchronization Data Source, then only the specified user account can execute this synchronization.

Restriction of Bulk Exports (and Bulk Imports)

  • Only the user accounts having the capability “Bulk Read” on Persons can perform exports of a list of persons.

  • Similarly, only the user accounts with the capability “Bulk Modify” on Persons can perform a CSV import of Persons.

  • These capabilities can be viewed using the “Grant matrix” tab on the details of each user account.

Cleanup of personal data

To completely cleanup the data related to a person, one has to:

  1. Delete the Person object corresponding to this person, this will also remove the history information about this Person.

  2. Delete the case log entries created by this person

  3. Delete the EmailNotification objects corresponding to emails sent to this person

But there are limitations to those actions:

  • Depending on the relations between the targeted Person object and other objects in the iTop Database, the deletion of the Person object may not be possible without specifying a replacement Person on some other objects in order to respect the database integrity constraints.

  • Deleting the case log entries is currently not implemented in iTop, and is non-trivial to achieve with SQL queries since the case log text must be kept consistent with another field called the case log index.

  • Updating the CMDBChange objects to replace the references to the contact name can be done in one single SQL query, since there is only one field ‘userinfo’ to anonymize in the table. Since this field is only displayed to the end-user and not user for any reference in iTop, there is no integrity constraint and any value can be put in the field.

  • Since one email notifications may be addressed to several persons (in TO, CC and BCC), deleting one such notification will affect other users than just the targeted person.

Due to the limitations mentioned above the “pseudonymization” approach seem more realistic to implement than a complete wipe of the personal data.

Pseudonymisation of personal data

  • Anonymize the Person object by replacing the values in all its mandatory fields by anonymous values (constant or random)

  • Empty all non-mandatory fields (like Location, Manager, Phone number, n:n relations)

  • Pseudonymisation of the case log entries, by removing all references to the person, without altering the length of the text, to preserve the consistency with the case log “index” field.

  • Deletion of the Person’s history (CMDBChange / CMDBChangeOp) to delete the “previous values” of the fields, which would help recover the values.

  • Anonymization of the CMDBChange “userinfo” fields containing the name of the Person.

  • Deletion of all EmailNotification objects past a (short) retention period (3 months ??)

Export of personal data

  • Person details can be exported using the standard export feature of iTop.

  • Case log entries can be exported by searching each class of object containing a Case Log (i.e. each class of tickets and searching for “Public Log” contains “Name of the contact”.

This can be achieved using the “Run Query” menu and an OQL like:

 SELECT UserRequest WHERE (public_log LIKE :name OR private_log LIKE :name) 

specifiying the value of the :name parameters as %contact_friendlyname%.

For example to export all the User requests with an entry by Claude Monet in a case log, the OQL query would be:

 SELECT UserRequest WHERE (public_log LIKE '%Claude Monet%' OR private_log LIKE '%Claude Monet%') 

Notification emails can be listed and exported using the OQL query:

SELECT EventNotificationEmail WHERE 
      TO = 'email_address' 
   OR cc LIKE '%email_address%' 
   OR bcc LIKE '%email_address%'
标签:
由 superadmin 在 2020/08/25, 16:38 创建
    

需要帮助?

如果您需要有关XWiki的帮助,可以联系:

深圳市艾拓先锋企业管理咨询有限公司