个人信息保护

如果您必须遵守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）相关联的用户创建了两个案例日志条目，则案例日志的内容将存储在数据库中，如下所示：

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

只要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导入。
• 可以使用每个用户账号的详细信息上的“授予矩阵型”选项卡查看这些功能。
  

个人数据的清理

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

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

但是，这些操作活动受到限制：

• 关于目标人员对象与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查询列出和导出通知电子邮件：

个人信息保护

如果您必须遵守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）相关联的用户创建了两个案例日志条目，则案例日志的内容将存储在数据库中，如下所示：

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

只要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导入。
• 可以使用每个用户账号的详细信息上的“授予矩阵型”选项卡查看这些功能。
  

个人数据的清理

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

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

但是，这些操作活动受到限制：

• 关于目标人员对象与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查询列出和导出通知电子邮件：