无需 KYC 的加密货币GPU 租赁 · 3、7 或 30 天
Capordia
语言: 简体中文
菜单
运维 / 团队访问

让每个人获得必要的访问权限,并设定明确的终止时间。

将跟随租赁的账户与机器上获授权的技术身份区分开。为每个人定义允许的工作、范围、审批人和访问终止时间,然后核实实际权限。此流程以目标上可用的机制为前提;它并不表示 Capordia 空间提供团队角色。账户密码和私钥始终由个人保管。

01

在分配访问权限之前指定负责人

请区分租用档案的负责人、授权访问项目的人员,以及可在目标上实施技术变更的人员。结果负责人不一定需要启动进程或管理机器。在选定权限之前,先写明所需操作:读取导出文件、上传输入、执行任务或修改环境。

随后核实实际交付的访问范围。如果您没有创建身份或设置权限的权限,请在邀请其他参与方之前,让人确认可行的流程。不要通过分发 Capordia 账户密码来绕过这一限制。工作分配与商业档案管理是两个不同的问题。

02

使用个人身份并了解其范围

个人身份允许在不更换整个团队访问权限的情况下撤销某个人的访问权限。在基于密钥的 SSH 组织中,OpenSSH 区分服务器已知的公钥和用户持有的私钥。协调文档可以包含公钥的引用或指纹;它绝不能包含私钥或其口令。

两把不同的密钥即使都能访问同一个系统账户,也不会自动形成两个不同的文件权限范围。权限取决于账户以及机器上配置的机制。因此,请先确定该要求仅涉及个人身份验证,还是也涉及操作隔离。对于自动化任务,应指定明确的身份和所有者,不要暗中复用同事的个人身份。

03

在向目标出示身份之前先核实目标

首次访问时,请根据在权限交付流程中获得的可信参考,核对机器名称、预期账户及其主机密钥指纹。该主机密钥用于标识服务器,与您的用户密钥不同。如果出现意外的服务器身份变更提示,应进行检查,而不是自动删除已知参考。

OpenSSH 会保存主机密钥并报告其变更。请结合具体情境使用这一信息:是否已宣布机器重建、地址变更或存在无法解释的事件。如果变更并非预期,请先确认再继续。目的不是为每次连接增加一套仪式,而是避免把身份警报当作单纯的显示干扰来处理。

04

虚构示例:三名参与者,三种需求

虚构团队「著作档案」正在筹备一周的工作。Idriss 执行项目 A 的处理任务,Noémie 复核导出的结果,Sacha 临时介入配置环境。团队希望获得表格中的权限,但必须核实这些权限能否在实交付的系统上生效。这既不涉及已有的客户账户,也不涉及 Capordia 宣传的团队管理功能。

决定性原则是:Noémie 不需要获得管理权限就能打开结果,而 Sacha 的介入有明确的结束时间。仅有人工审批并不能配置任何权限:技术负责人应用可用的机制,然后每个人执行既定的核查。如果所需的隔离无法实现,项目应先调整其组织方式,再引入需要这种隔离的数据。

虚构示例的期望矩阵——需在真实目标上应用并核查
参与者需求期望范围复核
Idriss,运行提交输入并启动项目 A工作区 A,无一般管理权限活动结束或角色变更
Noémie,验证读取交付的导出结果已采纳的结果,不修改输入验证结束
Sacha,介入准备获授权的环境已定义并批准的变更介入完成后立即
05

准备访问登记表并测试边界

登记表将人员或自动化、技术身份、审批人、范围、理由和期限关联起来。请保留公钥的引用和撤销流程,但不要存储机密。OpenSSH ssh-keygen 可以显示公钥的指纹:该引用有助于在添加或删除时指定正确的密钥,而无需复制其私钥部分。

先在一个合成文件上测试一项被允许的操作,然后测试一项故意超出范围、预计会被拒绝的操作。对于只读角色,打开必须正常,而受控的修改尝试必须被拒绝。不要使用真实数据来测试删除禁令。还要检查公共路径和输出目标,因为对某个目录拥有正确权限并不能保证程序的所有路径都正确。

06

规划撤回并验证新连接

在操作结束、人员离岗或怀疑凭证泄露后触发撤回。负责人需识别所有相关授权,包括同一身份的其他已授权访问路径,并根据实际配置执行撤回。OpenSSH 的 RevokedKeys 指令是文档中记载的一种可选机制;未经核验,不应假定某台机器上已启用该机制。

然后确认使用已被移除的身份再次认证会被拒绝,同时不删除负责人的恢复访问权限。请分别检查已打开的会话、进行中的任务和自动化身份:撤销授权与停止活动是不同的决定。如果某项工作必须继续,应按照既定流程转移其责任,而不是留下一个孤立的身份。

07

避免妨碍管控的捷径

共用私钥会导致无法确定应由谁更换,且往往被迫进行集体轮换。临时性的宽泛访问若无人设定复查日期,往往会长期存在。将验证账户同时用于管理机器,会使职责分离的检查难以解读。请在访问登记表中纠正这些问题,以免它们成为运维依赖。

同时,避免仅为绕过一项尚未诊断清楚的难题而添加代理转发、隧道或访问例外。应由被授权的负责人说明连接需求及其约束条件。本指南不提供通用的服务器配置:具体机制取决于所授予的权限、环境以及项目要求。一般性文档并不等同于对目标环境的验证。

08

移交一套仍可验证的访问组织方案

在接收时,汇集已批准的权限矩阵、活跃身份、已允许和已拒绝的测试结果、到期时间以及能够撤回访问的人员。确认在某人缺席时可被替代,且无需扩散其密钥。连续性依赖于流程和获授权的备用负责人,而不是项目文件夹中共享的密码。

在交接时,复查已无用的访问权限以及依赖个人身份的自动化。若意外拒绝阻碍了工作,请建立一个有针对性的故障档案,包含技术身份、涉及的路径和已脱敏的错误信息。不要仅为消除症状而添加通用权限。正确的收尾是必要、经过测试且具有已知终止时间的访问。

决策要点

是否应与所有相关人员共享 Capordia 账户?

不应该。租赁的跟踪与工作的技术访问应分开组织。根据实际授予的权限定义可能的机器身份。此方法不假定 Capordia 空间中有任何邀请或团队角色系统。

公钥会自动授予正确的权限吗?

不会。它仅在获得授权时用于身份认证;可执行的操作随后取决于账户和系统权限。请使用合成文件验证一项应被允许的操作和一项应被拒绝的操作。

某位人员离岗后应检查什么?

撤回其授权,验证新认证会被拒绝,并检查仍与其身份关联的会话、任务和自动化。保留一位获授权的负责人负责恢复和跟踪。不要仅凭一个勾选框就认定已完成撤回。

继续处理查看配置查看常见问题