# Space and Time 创建和管理表

**Published by:** [xunannan](https://paragraph.com/@xunannan/)
**Published on:** 2024-01-13
**URL:** https://paragraph.com/@xunannan/space-and-time

## Content

概述（表安全模型） 背景 Space and Time 为用户提供了几种保护平台数据安全的方法。最基本的形式是通过加密（数据加扰）来保护数据。除了简单的加密之外，我们的解决方案还包括通过饼干进行细粒度访问控制的去中心化授权解决方案。关于饼干授权的更多详细信息，请参见相关文档。 安全模型 安全模型决定如何在平台内保护数据库资源（表、视图等）。作为配置新资源的一部分，用户必须选择一种可用的安全模型来定义平台和更广泛的社区如何与其交互。通过将安全模型的范围限制为单个资源，用户可以自由地共享和/或保护他们认为合适的数据。下面概述了每个可用的安全模型： 公共 - 数据未加密，仅限于无访问控制 许可 - 数据未加密，完全访问控制 加密——数据加密，完全访问控制 无论安全模型如何，在通过参数创建表时，您始终需要提供饼干公钥：public_key SQL CREATE TABLE MY_SCHEMA.MY_TABLE( id int, name varchar, PRIMARY KEY (id) ) WITH "public_key=<biscuit_pub_key_here>"; 这是因为DDL操作总是需要饼干授权，因此需要为每个表配置公私钥对。 公共餐桌 此模型在平台级别最容易支持，并且需要最终用户最少的努力来启用授权和共享。它非常适合旨在共享的数据集（例如我们的区块链数据）。它还可以最轻松地使所有者将其数据货币化。公共表数据未加密，任何经过身份验证的用户都可以访问。 公共表可以配置为以下三个访问级别之一： public_read- 允许经过身份验证的用户进行表查询 ( )；所有其他操作都需要授权SELECT public_append- 允许经过身份验证的用户进行表查询和追加（, ）；所有其他操作都需要授权SELECTINSERT public_write- 允许经过身份验证的用户进行表查询和 DML（、、、、、） ；所有其他操作都需要授权SELECTINSERTUPDATEMERGEDELETE 要创建公共表，请在 DDL CREATE 命令中通过参数指定访问级别：access_type SQL CREATE TABLE MY_NAMESPACE.MY_TABLE( id int, name varchar, PRIMARY KEY (id) ) WITH "access_type=public_read"; 关于公共模型的最后一点是：资源所有者始终保持对 DDL 的控制（即，未经明确授权，任何用户都不能对任何资源执行 DDL 语句）。 权限表 该模型在平台级别也很容易支持，但需要最终用户付出额外的努力才能实现授权和共享。权限表数据也未加密，但只有显式授权才能访问。在这种模型中，存储在集群中的数据仍然可以被运营商窥探，但其访问仅限于平台用户。为了启用授权和共享，用户必须明确地创建和共享饼干。 要创建权限表，请在 DDL命令中通过 access_type 参数指定访问级别：CREATE SQL CREATE TABLE MY_NAMESPACE.MY_TABLE( id int, name varchar, PRIMARY KEY (id) ) WITH "access_type=permissioned"; 加密表 该模型需要平台和最终用户付出额外的努力来支持。尽管它确实需要额外的延迟和计算，但它确实提供了最强的安全保证。存储在集群中的数据是加密的，加解密密钥保留在集群外部，防止操作员检索解密的数据。平台如何处理加密数据取决于用户是否实施自己的加密。 用户管理的加密 用户始终能够实现自己的加密方案。在这种情况下，不需要额外的平台交互或配置，并且可以在公共或许可安全模型之上实现加密（因为加密完全存在于平台之外）。一个重要的注意事项是，用户将需要处理与加密数据集上的 SQL 一致性相关的各种复杂问题（例如，过滤子句不一定会以相同的方式工作）。此外，用户有责任保证所有数据在进入平台之前都经过加密。未加密的敏感数据可能会被删除，但不能保证在此之前不会被捕获。 平台管理的加密 如果用户想要加密数据但不想自己实现，他们可以依赖SxT平台安全作为可选服务。对于平台管理的加密，用户必须首先通过许可模型创建表，然后可以在其表上启用加密。 📘 我们正在致力于加密配置的前端支持。请尽快回来查看屏幕截图和更新的演练。 设置 作为前提，用户应该已经创建了他们的表并生成了适当的饼干。使用 dapp 前端，用户可以查看其表的现有加密配置并打开页面以开始配置新表。打开页面后，用户选择要添加加密的表、每个表中的哪些列应加密以及他们希望对每个列使用哪种类型的加密。有关列加密方案的详细信息将很快添加。 🚧 必须在尚未加密的表上设置加密。加密一旦配置，就无法更改或删除。 🚧 在设置加密之前添加到表中的数据不会自动加密。 📘 只能在同一命名空间/架构中的表上配置加密。如果您希望支持连接两个表之间的加密列，请确保两个表位于同一命名空间中。 运行 在目标表上配置加密后，用户现在可以透明地在传入数据时对其数据进行加密，并在传出时对其进行解密。标准交互所需的唯一更改是更改所使用的 SQL API 端点。 对于查询结果解密，使用API/decrypt/dql 对于数据操作加密，请使用API/encrypt/dml 📘 我们的数据加密/解密即将推出！稍后回来查看 API 规范

## Publication Information

- [xunannan](https://paragraph.com/@xunannan/): Publication homepage
- [All Posts](https://paragraph.com/@xunannan/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@xunannan): Subscribe to updates