外包人员的仓库访问：公网入口还是 VPN 路径？

外包人员需要一个私有仓库来完成有限的项目，而请求往往以两种形式出现：把仓库改成公开，或者给这个人 VPN 访问。这两个答案都跳过了真正的问题。仓库授权与网络入口是两个不同的层面，真正重要的权限，是让那个人读取或 push 那一个仓库的权限。两种方案里其余的一切都是额外的风险。先设计授权层，再决定它需要多小的网络路径。

一个具体的例子能把问题说清楚：一名外部开发者、一个仓库、没有生产主机、没有管理界面。在比较两种入口时，请把这个范围固定住。

两种入口，两种不同的边界

可公网访问的仓库服务仍然会强制执行 HTTPS 或 SSH 身份验证和应用层授权。公网可达并不意味着匿名可读。代价是你必须维护、监控和修补的一个监听器。

VPN 入口可以让那个监听器不暴露在公网上，但范围过宽的 VPN 账号可能顺带暴露无关服务。遗留的公网主机名、一个 SSH 监听器，或者你忘记的一个地址族，都可能击穿你以为存在的仅 VPN 边界。这就是为什么仅 VPN 的设计需要一份监听器清单，而不只是一条防火墙规则。

比较允许的路径，而不是标签。无论哪种方式，都要保留应用层身份验证和常规的服务器身份校验。

仓库角色才是权限的单位

给外包人员一个独立身份，并只授予完成任务所需的最小角色。查看、push、维护和管理是不同的角色，而一个授予所有内部项目的组，并不等于对一个仓库的访问权。请检查平台里真实的角色名称，而不是假设某个组名对应某一个角色。

列出这项工作真正需要的每一个操作。浏览器访问和 Git 传输可能使用不同的凭据或监听器。自动化构建、软件包下载和 webhook 可以作为各自投递路径的独立身份运行，而笔记本上的 VPN 并不会把它们连起来。

保护仓库内容是另一件事。改变入口路径不会移除历史中已经存在的密钥，不会限制已被授权的克隆，也不会保护贡献者的工作站。

比人活得更久的凭据

离职处理正是仓库访问与网络访问再次分道扬镳的地方。请通过各自的负责人移除仓库授权和 VPN 权利，然后检查个人令牌、SSH 密钥、自动化凭据和活动会话。部署密钥是典型的幸存者：在人员离开组织之后，它仍可能保留原先配置的读或写权限。把人从成员列表里删掉，并不等于完成了离职处理。

要在工作结束之前清点机器凭据的负责人和用途，而不是之后。为为期一周的构建创建的令牌，如果没有人写下它为什么存在，可能比项目多活一年。

验证操作、拒绝和离职处理

在交接之前，测试三件事：被允许的仓库操作成功，无关仓库被拒绝，已退场的身份失败。如果设计是仅 VPN，请确认旧的直连公网路径不再能执行该操作。

保留代码和评审记录，但不要让被遗忘的访问变成恢复方案。一份写下来的身份、角色和到期日期清单，才能让下一个外包请求成为可重复的流程。