Manage object security（管理对象安全）

Ontology data can be secured using object and property policies or data source policies. Both approaches support cell-level security, which is a combination of row and column level security.

As an example, consider a Passenger object type in an airline management platform with the properties User ID, Flight Number, Seat Assignment, Name, Address, and Phone Number.

• Row-level security: Certain users are VIPs and their object instances, corresponding to rows in the backing dataset, can only be seen if a user has the VIP marking.
• Column-level security: The properties Name, Address and Phone number contain user data, and can only be accessed by users that have the PII marking.

:::callout{theme="neutral"} The Check access panel in the sidebar can be used to check someone's access to a Workshop or Slate application, including access to dependent object types, their data sources, and granular access controls. For more information, see the check access panel documentation. :::

:::callout{theme="warning"} Some property values refer to data stored in additional resources outside of the Ontology. The access control mechanisms described in this section only control the visibility of the property values, but not the visibility of those additional resources. For example, a media reference property can refer to a media item stored in a media set. If the media set has different permissions from the object type, then it is possible for a user to not have access to a media reference property, but still be able to fetch the media item directly from the media set. Therefore, it is important to ensure that the additional resources are configured with the appropriate permissions when using them in the Ontology. :::

Object and property security policies

Object and property security policies allow you to set view permissions on object instances and their properties to achieve cell-level permissions. These can be directly managed in the object type’s Ontology Manager view and are independent of the permissions on the backing data sources.

The visibility of an object instance is governed by its object security policy, whereas the visibility of a property value is governed by its property security policy. Mandatory and classification based access controls, as well as granular access controls, can be applied to object and property security policies. Together, they allow for cell-level security in the Ontology.

Learn more about setting up object and property security policies.

Data source policies

Data permissions for object types are implicitly controlled by the permissions applied to the input data sources of the object type.

Object and property policies vs. data source policies

Object and property security policies are recommended for managing object security in most cases. They provide a unified approach to cell-level security (row, column, and cell-level permissions) directly on the object type. This makes them simpler to configure and maintain compared to data source policies.

Benefits of object and property security policies

Object and property security policies address several challenges that arise when using data source policies:

• Unified cell-level security: A single feature provides row-level (object security policies), column-level (property security policies), and cell-level permissions, rather than requiring a combination of restricted views (RVs) and multi-data source object types (MDOs).
• Simplified configuration: Security is managed directly on the object type in Ontology Manager, independent of the backing data sources. This reduces complexity and maintenance burden.
• Near-instantaneous policy updates: Changes to object and property security policies take effect almost immediately. With RVs, policy changes require a pipeline rebuild before reads respect the new policies. Note that changes in Multipass such as group membershisp or other user attributes are still cached for a short period of time.
• Streaming support: Object security policies can be applied to object types backed by streams, enabling row-level and column-level permissions for streaming data.
• Branching compatibility: Object security policies integrate with Global Branching, supporting development workflows where you need to test security configurations on branches before merging.

When to use data source policies

Data source policies, which rely on RVs and MDOs, are appropriate in the following cases:

1. Granular access control outside of the Ontology: If the backing dataset is used outside of the Ontology and requires granular access control in those contexts, RVs remain the appropriate solution. For example, RVs can secure reads on the backing dataset for users with different access levels in Code Workspaces. Object and property security policies are scoped to the Ontology and do not control access to raw datasets in non-Ontology contexts.
2. MDOs with specific requirements: If your object types require MDOs for reasons such as different resolution strategies or different build schedules per data source, data source policies may be required. Learn more about this configuration.

Object input data sources

Datasets and streams are the most widely used resources as input data sources for object types. Data permissions for these data sources are determined as follows:

• Datasets: Each row in the dataset corresponds to an object instance in the Ontology, and any user that has at least Viewer permissions on the dataset and its transactions will have access to all object instances created from that dataset.
• Streams: Streams are input data sources used for low-latency streaming data in the Ontology. Any user that has at least Viewer permissions on the stream data source has access to all object instances created from that stream data source.

If you need row-level or column-level permissioning using data source policies, you can use restricted views (RVs) and multi-data source object types (MDOs).

Configure data source policies with RVs and MDOs

Restricted views

:::callout{theme="neutral"} Restricted views can only be built on top of datasets. No other data source types are supported. :::

Restricted views enable row-level access control to certain rows in a dataset and the corresponding object instances created from those rows. Access to an object instance with a specific primary key is governed by who can access that specific row in the restricted view's input data source.

For example, a healthcare employee may be allowed to view dataset rows and object instances for patients that visit their care center, but they may be restricted from viewing data for patients that only visit other care centers, even if both types of data exist in the same dataset and object type.

If a given dataset, care_event_info, has patient_id, doctor_id, and care_center columns, a restricted view can be built on top of it with the policy user.userAttribute('care_center') == care_center. The restricted view will only allow access to rows in care_event_info that have the same care center as the user.

Using Ontology Manager, restricted views can be selected as the input data source of an object type in the same way as a dataset.

Learn more about setting up restricted views and governing row-level permission for objects.

Multi-data source object types

:::callout{theme="neutral"} Multi-data source object types are only available in object storage v2. :::

The Ontology offers support for mapping multiple input data sources to a single object type. Such object types are referred to as multi-data source object types (MDOs).

MDOs enable you to map columns from different data sources to the various properties of an object type. This enables you to apply multiple access controls corresponding to separate input data sources, to a single object type. These input data sources can be any combination of datasets or restricted views.

For example, for a given care event object type, some healthcare employees may require access to object properties containing personal health information (PHI), while other employees should not have access. This access control can be supported by backing the Care Event object type with two separate input data sources and applying different access controls and permissions on each input data source. The Care Event object type has Patient ID as its primary key and is backed by data sources patient_info and care_event_info.

• patient_info has the columns patient_id, name, address, contact_number, and age. This dataset has the PHI marking. Only users with access to the PHI marking will have access to the property values from patient_info.
• care_event_info has columns patient_id, doctor_id, and care_center. This dataset is unmarked. Users do not need access to any markings to access the property values from this dataset.

These different permissions will be respected and applied to the object instance. A user will not have access to the properties mapped from patient_info, such as name, address, contact_number, and age, unless they have the PHI marking.

Learn more about setting up MDOs and governing column-level permissions for objects.

---

中文翻译

---

管理对象安全

本体（Ontology）数据可通过对象与属性策略或数据源策略进行保护。这两种方法均支持单元格级安全（cell-level security），即行级与列级安全的组合。

以航空管理平台中的Passenger对象类型为例，该类型包含用户ID、航班号、座位分配、姓名、地址和电话号码等属性。

• 行级安全（Row-level security）： 部分用户为VIP，其对应的对象实例（即底层数据集中的行）仅当用户拥有VIP标记（marking）时方可查看。
• 列级安全（Column-level security）： 姓名、地址和电话号码属性包含用户数据，仅当用户拥有PII标记时方可访问。

:::callout{theme="neutral"} 侧边栏中的检查访问权限（Check access）面板可用于检查用户对Workshop或Slate应用程序的访问权限，包括对依赖对象类型、其数据源及细粒度访问控制的访问情况。更多信息请参阅检查访问权限面板文档。 :::

:::callout{theme="warning"} 部分属性值引用本体外部其他资源中存储的数据。本节所述的访问控制机制仅控制属性值的可见性，而不控制这些外部资源的可见性。例如，媒体引用（media reference）属性可引用媒体集中存储的媒体项。若媒体集与对象类型的权限不同，则用户可能无法访问媒体引用属性，但仍可直接从媒体集中获取媒体项。因此，在本体中使用外部资源时，务必为其配置适当的权限。 :::

对象与属性安全策略

对象与属性安全策略允许您对对象实例及其属性设置查看权限，从而实现单元格级权限。这些策略可直接在对象类型的本体管理器（Ontology Manager）视图中管理，且独立于底层数据源的权限。

对象实例的可见性由其对象安全策略（object security policy）控制，而属性值的可见性则由其属性安全策略（property security policy）控制。强制访问控制（Mandatory access controls）、基于分类的访问控制（classification based access controls）以及细粒度访问控制（granular access controls）均可应用于对象与属性安全策略。这些策略共同实现本体中的单元格级安全。

了解有关设置对象与属性安全策略的更多信息。

数据源策略

对象类型的数据权限由应用于对象类型输入数据源的权限隐式控制。

对象与属性策略 vs. 数据源策略

在大多数情况下，建议使用对象与属性安全策略来管理对象安全。它们提供了一种统一的方法，可直接在对象类型上实现单元格级安全（行级、列级及单元格级权限）。与数据源策略相比，这使得配置和维护更加简单。

对象与属性安全策略的优势

对象与属性安全策略解决了使用数据源策略时出现的若干挑战：

• 统一的单元格级安全： 单一功能即可提供行级（对象安全策略）、列级（属性安全策略）及单元格级权限，无需结合使用受限视图（restricted views, RVs）和多数据源对象类型（multi-data source object types, MDOs）。
• 简化配置： 安全策略直接在本体管理器中针对对象类型进行管理，独立于底层数据源。这降低了复杂性和维护负担。
• 近乎实时的策略更新： 对对象与属性安全策略的更改几乎立即生效。使用RVs时，策略更改需要重建管道后，读取操作才会遵循新策略。请注意，Multipass中的更改（如组成员身份或其他用户属性）仍会缓存一小段时间。
• 流式支持： 对象安全策略可应用于由流（streams）支持的对象类型，从而为流式数据启用行级和列级权限。
• 分支兼容性： 对象安全策略与全局分支（Global Branching）集成，支持在合并前需要在分支上测试安全配置的开发工作流。

何时使用数据源策略

依赖RVs和MDOs的数据源策略适用于以下情况：

1. 本体外部的细粒度访问控制： 如果底层数据集在本体外部使用，并且在这些上下文中需要细粒度访问控制，则RVs仍然是合适的解决方案。例如，RVs可以在代码工作台（Code Workspaces）中为不同访问级别的用户保护对底层数据集的读取。对象与属性安全策略的作用域仅限于本体，不控制非本体上下文中原始数据集的访问。
2. 具有特定需求的MDOs： 如果您的对象类型因不同数据源需要不同的解析策略或不同的构建计划而需要MDOs，则可能需要数据源策略。了解有关此配置的更多信息。

对象输入数据源

数据集（Datasets）和流（Streams）是作为对象类型输入数据源最广泛使用的资源。这些数据源的数据权限确定方式如下：

• 数据集： 数据集中的每一行对应本体中的一个对象实例。任何对数据集及其事务（transactions）至少拥有查看者（Viewer）权限的用户，都将有权访问从该数据集创建的所有对象实例。
• 流： 流是用于本体中低延迟流式数据的输入数据源。任何对流数据源至少拥有查看者权限的用户，都将有权访问从该流数据源创建的所有对象实例。

如果您需要使用数据源策略实现行级或列级权限，可以使用受限视图和多数据源对象类型。

使用RVs和MDOs配置数据源策略

受限视图

:::callout{theme="neutral"} 受限视图只能基于数据集构建。不支持其他数据源类型。 :::

受限视图支持对数据集中的特定行以及从这些行创建的对应对象实例进行行级访问控制。对具有特定主键的对象实例的访问，取决于谁可以访问受限视图输入数据源中的该特定行。

例如，医疗保健员工可能被允许查看其所在护理中心的患者数据集行和对象实例，但可能被限制查看仅访问其他护理中心的患者数据，即使这两种类型的数据存在于同一数据集和对象类型中。

假设给定数据集care_event_info包含patient_id、doctor_id和care_center列，则可以基于该数据集构建一个受限视图，其策略为user.userAttribute('care_center') == care_center。该受限视图仅允许访问care_event_info中与用户所在护理中心相同的行。

使用本体管理器，受限视图可以像数据集一样被选为对象类型的输入数据源。

了解有关设置受限视图和管理对象行级权限的更多信息。

多数据源对象类型

:::callout{theme="neutral"} 多数据源对象类型仅在对象存储v2（object storage v2）中可用。 :::

本体支持将多个输入数据源映射到单个对象类型。此类对象类型称为多数据源对象类型（MDOs）。

MDOs允许您将不同数据源中的列映射到对象类型的各个属性。这使得您能够将对应于不同输入数据源的多个访问控制应用于单个对象类型。这些输入数据源可以是数据集或受限视图的任意组合。

例如，对于给定的护理事件对象类型，某些医疗保健员工可能需要访问包含个人健康信息（PHI）的对象属性，而其他员工则不应拥有访问权限。这种访问控制可以通过使用两个独立的输入数据源来支持Care Event对象类型，并对每个输入数据源应用不同的访问控制和权限来实现。Care Event对象类型以Patient ID作为主键，并由数据源patient_info和care_event_info支持。

• patient_info包含列patient_id、name、address、contact_number和age。该数据集带有PHI标记。只有拥有PHI标记访问权限的用户才能访问来自patient_info的属性值。
• care_event_info包含列patient_id、doctor_id和care_center。该数据集无标记。用户无需任何标记即可访问来自该数据集的属性值。

这些不同的权限将被遵守并应用于对象实例。除非用户拥有PHI标记，否则他们将无法访问从patient_info映射的属性，例如name、address、contact_number和age。

了解有关设置MDOs和管理对象列级权限的更多信息。