企业知识库权限模型：空间 / 页级 / 属性权限、SSO/SCIM 与外部共享对照清单
企业知识库的权限模型，是决定「谁能以何种身份打开、编辑、分享某一页，以及员工离职或调岗后这些权利如何被收回」的规则组合，通常覆盖空间或站点级授权、页级限制、属性级规则，以及 SSO、SCIM 与审计。它要回答的不是数据存放在哪个区域，也不是检索或 AI 问答会不会越权引用，而是访问控制本身能否被目录同步、外部共享策略和日志所验证。本文对照 Confluence Cloud、Notion 与 GitBook 在 2026 年公开文档中的权限层次、身份开通方式和对外分享边界，给出一份可写进立项书的核对表。
浏览 4
巴克励步
导语：先问谁能打开这一页，再问登录方式叫什么
企业知识库的权限模型，是决定「谁能以何种身份打开、编辑、分享某一页，以及员工离职或调岗后这些权利如何被收回」的规则组合。它通常不是单一开关，而是几层规则叠在一起：空间或站点级授权、页级限制、有时还有按人员属性生效的规则，再加上单点登录、用户开通和审计。
这和数据存放在哪个区域不是同一件事，也和 Wiki-first vs Search-first 里讨论的「检索或 AI 问答会不会引用无权查看的内容」不是同一件事。后者要验证的是检索边界是否可证伪；本文要验证的是访问控制本身：角色怎么分层、组怎么从目录同步过来、对外分享会不会绕开内部限制，以及日志里到底记下了什么。更早的知识库单点登录说明回答的是「能不能用企业账号登录」；私有知识库讨论的是「要不要登录才能阅读」。本文把登录、授权、外部共享和审计放在同一张对照表里。产品定位见支柱文 Baklib Wiki 是什么。
立项里最常见的误会有三个：一是把 SSO 当成权限模型本身；二是以为给某一页加了限制，公开链接或「分享到网页」也会自动遵守同样的边界；三是把页面版本历史当成审计日志。2026 年，主流 Wiki 与文档产品把角色、属性级授权和对外分享写得更细，这些误会也更容易在验收时被翻出来。
为什么现在要谈：2026 年叠在一起的三条公开信号
第一，协作 Wiki 正在把「权限表」产品化成可复用的角色。Confluence Cloud 已将基于角色的访问作为正式可用能力（GA）：默认提供 Admin、Manager、Collaborator、Viewer 四种角色，并允许定义自定义角色；管理入口在 Confluence 设置中的 Space roles，或空间设置里的 Users。官方还把旧权限表映射到新名称，并把原先集中在 Admin 上的能力拆成「管理空间访问」「管理空间内全部内容」「允许并管理公开链接」「管理访客进入空间」等更细的权限。见 What are Confluence’s roles?。这意味着采购不能再只问「有没有页级权限」，而要问：角色能否按组批量授予，管理员权限会不会过宽，以及公开链接、匿名访问和访客是不是被单独控制。
第二，知识库里的「属性级」授权已经出现在公开产品文档里，而不只是抽象的 ABAC 概念。Notion 在 Business 与 Enterprise 方案中，允许在源数据库上按「人员」或「创建者」属性设置页级访问规则，例如只让工单创建者编辑自己的工单，或只让招聘负责人看到与自己相关的候选人。规则会作用于该数据库的所有视图和链接视图；若同一人还通过工作区级分享拿到了更宽的权限，Notion 会取更宽的那一档。见 Sharing & permissions settings。对要把「负责人可见自己的记录」写进制度的团队来说，这是页级限制之外必须单独验证的一层。
第三，对外分享和「已发布的文档站」被厂商自己拆开写。Confluence 的公开链接用于把单个页面、live docs 或白板分享给组织外的人，且不把 Confluence 使用权一并交出；但它同时写明：公开链接会忽略父级、空间和站点上的查看限制。见 Share content externally with public links。GitBook 则把已发布站点的「需登录才能阅读」写成独立能力：可以用 Okta、Azure、Auth0 集成，或自建认证后端，典型场景包括只给付费客户或伙伴看的产品文档，以及只给员工看的内部知识库。见 Authenticated access。一边是协作页面上的外部分享开关，一边是发布面上的访问控制——选型时不该把它们当成同一个功能。
把这三条放在一起，立项问题就从「支不支持权限」变成：你的权限是在哪一层生效的、身份如何进入这些层、对外分享会不会绕开内部限制，以及这些动作能不能被审计。
四个容易混在一起的词
在短名单上把下面四个词拆开写。混用它们，最后往往买到「能用公司账号登录」，却买不到「这一页只对该看到的人可见」。
| 概念 | 它真正回答的问题 | 典型落地方式 |
|---|---|---|
| 身份认证（Authentication） | 访问者是不是他所声称的那个人 | 密码、SSO（SAML / OIDC）、MFA，由企业身份提供方（IdP）集中管理 |
| 授权（Authorization） | 通过认证之后，能对哪一块内容做什么 | 空间 / 站点角色、页级限制、属性级规则、组映射 |
| 用户开通（Provisioning） | 账号和组如何被创建、更新、停用 | SCIM 2.0 同步，或仅在首次 SSO 登录时即时开通（JIT） |
| 审计（Audit） | 权限变更、外发和导出能不能被事后核对 | 审计日志、保留期限、CSV 导出或向 SIEM 推送 |
单点登录（SSO）是认证方式。SAML 被 Atlassian 写成身份提供方与服务提供方之间交换认证与授权数据的开放标准；配置 Atlassian Cloud 的 SAML SSO 需要订阅 Atlassian Guard Standard，且 SSO 只适用于已验证域名下的用户账号。见 Configure SAML single sign-on with an identity provider。SCIM（System for Cross-domain Identity Management）是另一件事：IETF 在 RFC 7643 与 RFC 7644 中分别定义了核心模式与协议。Atlassian 写明其用户开通使用 SCIM 2.0，可从身份提供方自动创建、关联和停用受管理的 Atlassian 账号。见 Understand user provisioning、RFC 7643。
一个可操作的判断句是：先画清「认证 / 授权 / 开通 / 审计」四行，再看某家产品的角色名称有多好看。 没有开通和审计，登录本身解决不了权限腐烂。
权限在哪一层生效：空间、页面、属性
不同产品用不同的词，但层次可以对齐来看。
| 层次 | Confluence Cloud | Notion | GitBook（以已发布站点为例） |
|---|---|---|---|
| 组织 / 站点 | 全局权限；角色还可以赋给「所有 Confluence 用户 / 管理员」这类用户类 | 工作区与组织级安全策略，例如关闭公开链接、限制访客 | 组织管理员在每个站点上始终拥有站点 Admin，不能被降级 |
| 空间 / 团队空间 / 站点 | 空间角色（Admin、Manager、Collaborator、Viewer 或自定义角色）决定该空间内能做什么 | Teamspace 有独立成员与权限；默认 Teamspace 中的页面对工作区全员可见（受限成员除外） | 站点角色：Admin、Creator、Reviewer、Editor、Commenter、Reader；Reviewer 才能把变更请求合并到线上 |
| 页面 / 内容项 | 内容级查看与编辑限制；默认开放；免费版不能限制内容访问 | 页面 Share 中的邀请、一般访问与权限级别（Full access 到 Can view）；子页面默认继承父页面权限 | 站点角色主要管结构、发布和编辑流，而不是给每一页单独画一张权限表 |
| 属性 / 条件 | 主要仍按用户与组授权，而不是按页面上的「负责人」字段自动授权 | Business / Enterprise 可按人员或创建者属性设置数据库页级规则 | 已发布站点可另配访客认证，把「谁能打开这个站点」交给认证提供方 |
三件事特别容易在验收时翻车。
第一，开放默认与限制的叠加方向。Confluence 把开放默认写成产品原则：内容希望对有空间查看权限的人可见，除非另行限制；页级限制不能补上空间权限的缺口。查看限制会向下继承，编辑限制不会：即使不能编辑父页面，也不自动失去对子页面的编辑权；但若在空间级被禁止编辑，则该空间内任何内容都不能编辑。空间管理员仍能看到空间里存在哪些受限页面，并更改限制；Premium 与 Enterprise 的组织管理员还可以用 admin key 查看并改写访问。见 Change who can find content and what they can do with it、What are Confluence’s roles?。
第二，「更宽的权限优先」。Notion 明确写：系统尊重授予某用户的最宽访问级别。如果先通过人员属性把某人设为「仅可查看」，后来又把「工作区所有人」设为 Full access，则该成员会得到完全访问。把共享页面拖到侧边栏 Private，只会收回父页面上其他人的访问，子页面上已授予的权限保持不变。页面若设为「任何拥有链接的人可访问」，还可能因为被更宽分享的页面提及、双向关联或嵌套而被意外交出。见 Sharing & permissions settings。
第三，编辑权限和发布权限不是同一把钥匙。GitBook 把这一点写进站点角色：Editor 可以在变更请求里改内容并提交评审，但不能合并；Reviewer 才能把变更发布到线上站点；Creator 才能改站点结构并把草稿区段正式发布。组织管理员在所有站点上自动是 Admin。见 Site permissions。如果团队要的是「写作者能改草稿、但不能直接改对外手册」，应把这层发布权单独列入验收，而不是只看「有没有编辑角色」。
SSO 只能登录，SCIM 才负责收回权限
把身份路径写成三档，比只在询价单上勾「支持 SSO」有用。
| 路径 | 它做了什么 | 它通常做不到什么 | 公开文档中的关键约束 |
|---|---|---|---|
| 仅手动邀请 | 管理员逐个发邮件邀人 | 入职、调岗、离职都靠工单 | 规模稍大就会出现残留席位和「人已走、组还在」 |
| 仅 SSO（SAML 等）+ 可选 JIT | 用企业身份登录；首次登录时可自动建号 | 不自动把组推到空间角色；访客往往不能走 SSO；停用后本地会话或 API 访问可能仍在 | Atlassian：SSO 只作用于已验证域名；JIT 需把域名链到身份目录，并在默认认证策略上强制 SAML。Notion：SAML 适用于 Business / Enterprise，访客不能用 SAML 登录；若使用 SCIM，不建议再开 JIT |
| SSO + SCIM 2.0 | 在身份提供方创建、更新、停用用户和组，并同步到知识库 | 不一定覆盖访客；组同步范围因产品而异 | Atlassian 用户开通需 Atlassian Guard Standard，组同步目前可用于 Confluence 等，停用受管账号可在身份提供方完成。Notion SCIM 仅企业版，可创建和移除工作区成员、管理组，目前不能用 SCIM 管理访客；移除用户会使其退出所有活动会话，但不能通过 SCIM 删除 Notion 账号本身 |
Atlassian 还把 SAML 与 SCIM 的分工写得很清楚：配好 SAML 后，仍要单独授予应用和站点访问权；若希望自动开通和回收，应配置 SCIM，或使用 Google Workspace 开通。若只用 SAML、没有用户开通，为防止离职者继续通过 REST API 取数，需要在组织和身份提供方两侧都停用该用户。SSO 生效后，Atlassian 自己的密码策略和两步验证不会再作用于这些登录，官方建议改用身份提供方提供的等价能力。见 Configure SAML single sign-on with an identity provider、Understand user provisioning。
Notion 的企业版把 SAML 做成组织级可多套配置：一个组织最多 25 套 SAML 配置，便于业务单元、区域 IT 或被收购公司使用各自的身份提供方；同一验证域名可以出现在多套配置里，但同一时间只能有一套被设为强制。访客被邀请到已启用 SAML 的工作区时，不能用 SAML 登录，而要使用密码或 Google / Apple 等其他方式。企业版还可以为工作区要求「不论邮箱域名，访问前都须经过指定 SAML」，以便更安全地做外部协作。见 SAML SSO configuration。SCIM 方面，官方写明目前支持 Okta、OneLogin、Rippling 和自定义 SCIM 应用；每个要被 SCIM 管理的工作区都要单独生成令牌；工作区所有者离职或角色变更时，其令牌会被撤销，相关开通会中断，直到被替换。见 Provision users & groups with SCIM。
对知识库立项，这意味着：把「能登录」写成验收项远远不够。至少还要问：组能否同步并映射到空间 / 团队空间角色；JIT 与 SCIM 是否互斥；访客是否在 SCIM 范围之外；停用账号后会话、令牌和席位何时失效。
外部共享：访客、公开链接和需认证的发布面
内部权限再严谨，一旦分享出口没有单独治理，就等于在门上装了锁、却把钥匙挂在门外。
Confluence 的公开链接只出现在付费方案（Standard、Premium、Enterprise），且只适用于页面、live docs 和白板，不适用于博客或数据库；因 FedRAMP Moderate 要求，该功能在 Atlassian Government Cloud 中不可用。关键安全边界写在同一页官方文档里：只要管理员允许使用公开链接，它就会生效，无视内部查看限制；能查看内部内容的人也可以复制该公开链接再转发出去；每个公开链接只对应一个内容项，子页面不会被自动公开，必须各自打开并单独分享；关闭后再打开，用的仍是同一条链接。见 Share content externally with public links。因此，「这一页已经对内部设限」并不能推理出「公开链接也是安全的」。公开链接是一种外发通道，应该按内容项审批，并在空间或站点级决定是否允许使用。
Notion 把对外口子分成几类：邀请工作区以外的人作为访客（Guest）；把一般访问设为「任何拥有链接的人」；以及把页面发布为 Notion Site。组织域名下的邮箱会被加成成员而不是访客，因而可能占用付费席位；工作区或 Teamspace 可以禁止添加访客，也可以限制允许的邮箱域名。企业版工作区所有者可在 Settings → Security 关闭站点发布与公开链接。访客需要拥有自己的 Notion 账号才能打开被邀请的页面。见 Sharing & permissions settings。结合上一节：这些访客目前还不能被 SCIM 管理，也不能走 SAML SSO。外部协作的生命周期，往往是权限模型里最容易被忘掉的一段。
GitBook 处理的是另一类需求：不是把协作页临时丢到公网，而是给已经发布的文档站加上认证。官方列出的常见用途包括：只给付费客户、销售对象或伙伴看的敏感产品文档，以及只给本公司员工看的内部知识库。站点提供内置的登录与登出 URL（
/~gitbook/auth/login 与 /~gitbook/auth/logout），登录时会带上原来的页面位置，便于认证后回到同一页。见 Authenticated access。这更接近「对外可发布文档站的访问控制」，而不是协作 Wiki 里的「把这一页 Share 出去」。对同时做内部制度与对外知识库的团队，更稳妥的做法是：把需要公开或按客户登录可见的内容，作为正式知识资产发布到独立站点，并为每个站点规定公开、登录可见或指定权限可见；而不是长期依赖协作页面上的公开链接。Baklib 把这类能力写成知识库绑定应用站点之后，才形成对外 URL，并在站点上交付权限。见 知识库发布、Baklib Wiki。一源多站的意义，是同一份已治理的内容可以出现在内部门户和对外手册上，却使用不同的访问规则，而不是维护两份逐渐分叉的文稿。这与可发布企业 Wiki 的选型对照讨论的是同一条产品分界，本文只把它用在权限交付上。
审计：日志必须能回答的五句话
权限模型若不能被审计，就只在演示环境里成立。把厂商文档里已经写明的范围当成验收底线，而不是事后补日志。
Confluence Cloud 的审计日志需要管理员权限，免费版不可用。它用于回溯关键变更，例如全局权限变化；可按关键词和时间过滤，可导出为 CSV，默认保留一年，也可改为最短一个标准月（31 天），系统每周清理超期记录。官方列出的事件类型包括：空间的创建、归档、删除、导入导出和配置更新；用户与组的创建、停用和成员变更；全局和空间权限的添加或移除（含匿名访问）；内容限制的添加或移除；公开链接的启用或禁用；以及使用 admin key 查看内容等。它不记录内容编辑（编辑见版本历史），也不记录内容位置变更。见 View the audit log。
Notion 的审计日志面向企业版组织所有者。升级到企业版之后才开始记录，升级前的事件不会补进日志；界面查询与导出默认最多回溯 365 天，导出包含当前过滤器匹配的事件，并写明可查看至导出前约 2 小时。事件在可用时包含 IP 地址。类别覆盖页面、工作区、账号、Teamspace、表单、数据源和组织级事件。与权限和外发直接相关的例子包括：页面权限更新、页面分享到网页、页面导出、工作区内容导出、访客移除、访客邀请请求、公开页面分享开关、禁用访客开关、SCIM 令牌生成与撤销，以及 SAML 相关变更。页面事件还可以标出受众：私有、内部共享、外部共享（含访客或集成机器人）、分享到网页。自 2026 年 8 月 9 日起，Teamspace 过滤对之后捕获的事件生效。自定义 SIEM 集成可通过 webhook 实时推送工作区事件，但不包含页面正文，也不推送组织级事件；每个工作区同时只能配置一个 webhook。见 Audit log。
写进询价单时，至少要对方书面回答这五句：
- 哪些动作会进日志？ 权限变更、公开链接或「分享到网页」、导出、访客邀请、SSO / SCIM 配置变更是否都在列。
- 哪些动作故意不记？ 例如 Confluence 不记正文编辑和位置变更。
- 从哪一天开始记、保留多久、超期怎么处理？ Notion 从升级企业版之时起记；两边公开文档里的常见上限都在一年左右，更长保留通常要靠定期导出。
- 能不能导出，或推到现有 SIEM？ 导出格式、过滤器是否生效、webhook 是否包含组织级事件，都要单独问。
- AI、集成和机器人算不算独立主体？ Notion 已把集成或外部 AI 工具对页面的阅读与编辑写入页面事件，并把 admin bot 与人工操作区分开。知识库一旦接上问答或 MCP，这会直接决定事故排查能不能做完。
审计回答的是「发生过什么」，不能替代检索与 AI 引用是否越权的专项验证，也不能替代版本回滚。三者要一起设计，但不要互相冒充。
可执行核对清单：把权限模型写进立项书
下面十问可以直接贴进询价或概念验证脚本。对每一问，要求看当前产品界面或导出一条证据，而不是只听演示。
- 默认是开放还是收紧？ 新建空间 / 团队空间 / 站点时，谁能立刻看见内容。Confluence 是开放默认；Notion 的默认 Teamspace 对工作区全员可见。
- 空间（或站点）角色能否按组授予，组是否来自身份目录？ 没有组映射，SCIM 同步进来的部门无法落到「谁能进这个空间」。
- 页级限制与空间权限如何叠加？ 验证「空间无权的人不会因为出现在页级名单里就获得访问」，以及查看限制与编辑限制的继承是否符合你的制度。
- 有没有属性级规则，冲突时取最宽还是最严？ 用 Notion 的人员属性规则做概念验证时，故意再给一次更宽的工作区权限，确认实际生效的是哪一档。
- SSO 覆盖哪些人？ 已验证域名的成员、外部访客、客户读者是否走同一套登录；强制 SSO 之后，管理员是否仍有紧急入口。Notion 规定组织所有者或工作区所有者在 IdP 故障时可使用邮箱密码绕过；Atlassian 建议另备不受 SAML 强制约束的管理员测试策略。
- SCIM 与 JIT 如何分工？ 是否互斥；停用账号后会话、令牌、组资格和席位何时失效；访客是否在范围外。
- 对外分享有几类出口，谁能打开？ 公开链接、任意链接可访问、访客邀请、需认证的发布站点，要分别列出，并验证它们会不会忽略内部查看限制。
- 发布权与编辑权是否分离？ 对外手册尤其需要「能写草稿、不能直接上线」。GitBook 用 Reviewer / Editor 把这层写进了角色。
- 审计能否回答上一节的五句话？ 导出一条包含权限变更和外发事件的日志，确认保留期和主体（人 / 集成 / AI）。
- 内部知识与对外手册是否共用同一份资产、使用不同的站点权限？ 若做不到，权限再细也会在复制粘贴中失效。Baklib 将知识资产发布、权限交付与一源多站写成同一条产品逻辑：一份内容可以输出到不同应用站点，并分别设置公开、登录可见或指定权限可见。见 知识库发布、Baklib Wiki。
怎么选：先画访问边界，再挑产品名词
没有放之四海都正确的权限模型，只有和内容分级、协作者类型相匹配的模型。
若知识库主要是公司内部制度、项目空间和需要精细收紧的协作文档，应优先验证空间角色、页级限制、组同步和审计，而不是先看能不能把某一页公开到网上。Confluence 这类开放默认的协作 Wiki，适合已经接受「默认可见、例外再限制」的组织；前提是空间管理员知道如何盘点受限页面，并且公开链接被站点策略管住。
若知识库里有大量「按负责人可见自己的记录」——支持工单、招聘、客户项目——要单独验证属性级或等价规则，并搞清楚「更宽权限优先」会不会把规则冲掉。Notion 的数据库页级访问是公开可核对的一种实现，但它依赖源数据库上的人员属性，也依赖工作区分享不要给得过宽。
若主要交付物是对外产品手册、客户文档或合作伙伴资料，应把「发布面的访问控制」当成第一验收项：公开、登录可见还是指定客户可见；编辑与发布是否分离；认证是走企业 SSO，还是走面向读者的访客认证。GitBook 的站点角色与 Authenticated access，对应的是这一类问题。协作页面上的公开链接可以应急，但不应当长期充当正式文档站。
混合是常见结果：内部 Wiki 用空间和页级权限管协作，对外手册用独立站点做权限交付。风险不在「用了两种阅读入口」，而在「同一句话有两个互不相干的版本」。避免分裂的方法，是让正式知识作为一份资产被引用到不同站点，并分别设置访问规则——这也是 Baklib Wiki 强调的知识资产发布与权限交付，而不是把内部草稿的分享链接临时转成对外地址。
账单和部署形态会改变 SSO、SCIM 和审计出现在哪一档订阅里——例如 Atlassian 的 SAML 与 SCIM 写在 Guard Standard 之下，Notion 的 SCIM 与审计日志写在企业版，Confluence 审计日志在免费版不可用——但那是定价模型要单独展开的问题。本文只提醒：把「权限模型」写进功能清单时，同步写上它依赖的订阅层级。
收束：权限模型要能被目录同步，也要能被日志证明
企业知识库的权限决策，不该从「支不支持 SSO」或「能不能给某一页加密」开始。更稳妥的顺序是：先给内容分级并画出内部成员、访客和匿名读者三类边界，再把授权落在空间、页面还是属性上写清楚，然后才选择 SSO、SCIM、对外分享方式和审计。
2026 年的公开文档已经足够用来做概念验证。Confluence 把角色和公开链接的例外写进了正式说明；Notion 把属性级页访问、「更宽权限优先」以及访客不在 SCIM / SAML 范围内写进了帮助中心；GitBook 把站点上的编辑 / 发布分离和已发布站点的认证访问写成了产品能力。对要同时服务员工和外部读者的团队来说，真正有区分度的，仍然是把已治理的知识作为资产来发布，并按站点交付权限，而不是假设登录方式一旦统一，谁能看见哪一页就会自动正确。
想要了解更多?
数字内容新基建白皮书
常见问题
SSO 开通了，是不是权限就自动跟着组织架构走？
不一定。SSO（通常是 SAML）解决的是「用企业目录里的身份登录」，不等于「这个人属于哪个空间、能看哪一页」。要把入职、调岗和离职同步成知识库里的账号与组，还需要 SCIM 或等价的用户开通，再把组映射到空间、站点或团队空间角色。Notion 还提醒：如果已经使用 SCIM，不建议再打开 SAML 的即时开通（JIT），以免身份源和实际成员不一致。
页级限制能不能覆盖空间权限不足的人？
在 Confluence 里不能。官方写明，限制对话框里即使写了某人「可以查看」，若其没有该空间的查看权限，仍然看不到这一页；页级限制是在已有空间权限之上再收紧，而不是另外发一张通行证。查看限制会向下继承给子页面，编辑限制则不会自动传到子页面。
打开「公开链接」或「分享到网页」，内部页级限制还有效吗？
对 Confluence 的公开链接（public links）来说，内部查看限制不再约束外部访问：只要管理员允许使用公开链接，它会忽略父页面、空间乃至站点上的查看限制；链接对应的是单个内容项，不会自动带上子页面。Notion 则把「Anyone on the web with link」和把页面发布为 Notion Site 区分开，企业版工作区所有者可以关闭站点发布与公开链接。这两种「对外分享」都应该单独出现在审计与审批流程里，而不是默认等于已经发布的文档站。
只开 SSO、不开 SCIM，员工离职后会怎样？
常见结果是：对方无法再通过 SSO 登录，但本地会话、导出权限或已发出的访客邀请不一定会立即失效；若没有把停用账号同步到知识库，席位和组权限也可能残留。Atlassian 写明，若同时配置了用户开通，只需在身份提供方停用用户即可同步；若只用 SAML，为防止其继续通过 REST API 取数，需要在组织侧和身份提供方两侧都停用。Notion 的 SCIM 可以移除工作区成员并使其退出所有活动会话，但官方同时写明：目前不能用 SCIM 管理访客（guests）。
审计日志能代替页面版本历史吗？
不能。Confluence Cloud 的审计日志明确不记录内容编辑（编辑要看版本历史），也不记录内容位置变更；它记录的是空间创建与删除、全局和空间权限、内容限制、公开链接启停等关键事件，默认保留一年，且免费版不可用。Notion 企业版审计日志会记录页面编辑、导出、分享到网页和权限更新等，但事件从升级到企业版之时起才开始记录，历史默认最多保留 365 天。采购时应把「记什么、保留多久、能否导出或接入 SIEM、AI / 集成操作是否算作主体」写成验收项。
