您需要什么样的访问控制策略？| Xygeni

为什么开发人员需要真正的访问控制策略（而不仅仅是理论）

如果你正在推送代码，维护 pipelines，或者管理构件注册表，你需要的不仅仅是理论。薄弱或不明确的访问控制策略会导致仓库被篡改， CI/CD 虐待，以及 凭证泄露。DevSecOps 需要真正的执行，而不仅仅是隐藏的权限设置。

为了有效地管理跨代码存储库的访问控制策略， CI/CD pipelines以及工件注册表，许多团队依赖于像 Xygeni 这样的自动化执行工具。通过持续监控角色、权限和策略遵守情况，Xygeni 有助于防止权限漂移、未经授权的访问和手动覆盖，将强制访问控制理论付诸实践。

访问控制直接锁定您的源代码，保护您的构建，并保护您的生产 pipeline如果开发人员绕过控制措施或服务帐户拥有过多权限，就会为安全漏洞打开大门。因此，了解强制访问控制、MAC 访问控制和其他模型至关重要。

开发人员应该了解的访问控制策略类型

访问控制策略主要分为三类，每类适用于不同的情况 CI/CD 工作流程。以下是快速并排细分，以便澄清：

型号	谁控制访问？	典型用途 CI/CD	风险等级
DAC（自主访问控制）	资源所有者（开发人员、管理员）	手动共享 repo 或注册表访问权限	高（人为错误）
RBAC（基于角色的访问控制）	系统按角色分配权限	GitHub 分支保护，基于用户角色的 CI 作业访问	中（角色配置错误）
MAC（强制访问控制）	由系统策略强制执行	强制规定谁可以发布工件或部署代码	低（政策覆盖用户意图）

澄清 MAC 与 RBAC CI/CD 语境

基于角色的访问控制很容易混淆（RBAC) 具有强制访问控制 (mac 访问控制)，尤其是在 CI/CD 环境。尽管 CI/CD GitHub 和 GitLab 等平台使用 RBAC 来管理角色和权限（例如，谁可以合并或部署），这仍然从根本上是基于角色的，而不是真正的 MAC 访问控制。

RBAC 允许您根据角色（开发人员、维护人员等）分配权限，但这些权限仍然由用户控制和修改。配置错误或权限蔓延是常见的风险。

相比之下，强制访问控制（MAC 访问控制）是在系统或基础设施层面强制执行的。用户（包括管理员）无法覆盖它。可以将 Mac 访问控制视为嵌入到平台中的策略：云提供商（例如 AWS IAM、GCP IAM）中的 IAM 策略，或 SELinux 或 AppArmor 等操作系统级强制执行工具。在这些情况下，只有满足预定义的、不可绕过的规则时才会授予访问权限。

In CI/CD许多工具通过严格限定的 IAM 角色或特定于资源的权限来模拟 MAC 访问控制行为，但这并不是完全的强制访问控制。真正的强制访问控制实施需要在应用层以下（操作系统、网络或云基础设施层）实施控制，在这些层级，访问由不可变的访问控制策略而非人工配置进行管理。

基于角色的访问控制（RBAC）

RBAC 将权限映射到定义的角色，例如“开发人员”、“维护人员”或“发布经理”。它简化了 GitHub 等工具中的管理， GitLab。无需逐个用户进行配置，而是将他们分配给角色并让系统强制执行规则。

计费示例： GitHub CODEOWNERS 文件

				
					# CODEOWNERS
/docs/ @doc-team
/scripts/ @devops-team
/main.py @maintainers

这确保只有指定的角色才能批准关键目录中的更改。

GitLab 角色设置：在“设置”>“成员”中配置项目访问权限：

开发商： 可以推送至功能分支。
维护者： 可以合并到受保护的分支。
客人： 只读访问。

GitHub Actions 工作流 RBAC 示例：

				
					yaml
# .github/workflows/deploy.yml
name: Deploy to Production
on:
  push:
    branches:
      - main
jobs:
  deploy:
    if: github.actor == 'release-manager'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Deploy
        run: ./scripts/deploy.sh

强制访问控制（MAC）

强制访问控制（MAC 访问控制）强制执行严格的系统级规则，用户和管理员无法覆盖。使用 Mac 访问控制严格控制谁可以读取、写入或执行关键资源。

计费示例： Google Artifact 注册策略（简化 YAML）

				
					yaml
bindings:
  - role: roles/artifactregistry.writer
    members:
      - serviceAccount:ci-deployer@project.iam.gserviceaccount.com

此策略仅向 ci-deployer 服务帐户授予写入权限，确保只有具有此身份的 CI 作业才能推送工件。

计费示例： Amazon ECR 策略（简化 YAML）

				
					yaml
Version: "2008-10-17"
Statement:
  - Effect: Deny
    Principal: "*"
    Action: ecr:PutImage
    Resource: arn:aws:ecr:region:account-id:repository/my-app
    Condition:
      StringNotEquals:
        aws:userid: ci-service-account

此策略拒绝任何对 ECR 存储库执行的 PutImage 操作，除非由 ci-service-account 执行。它将镜像上传严格限制到此服务账户。

手动覆盖的风险以及 MAC 如何预防这些风险

RBAC 和 DAC 模型 存在故意或意外手动覆盖的可能性。例如，管理员或开发人员可能会直接将工件上传到受保护的注册表，或授予超出既定访问控制策略的过多权限。这些操作可能会引入漏洞或造成合规性漏洞。

强制访问控制（MAC 访问控制）通过强制执行任何用户（甚至管理员）都无法绕过的系统级策略来防止此类覆盖。访问cis离子由嵌入在基础设施中的不可变规则（例如云 IAM 策略或操作系统级安全模块）管理。这意味着：

如果 Mac 访问控制策略拒绝，管理员将无法手动将工件上传到注册表。
用户不能提升权限或改变定义的访问控制策略之外的权限。
自动化 CI/CD pipeline严格在其分配的权限内运行，防止范围蔓延。

通过消除手动覆盖，强制访问控制可确保比单独的 RBAC 或 DAC 更强大、更可靠的安全态势。

2.4 自主访问控制（DAC）

DAC 允许资源所有者手动分配权限。它灵活但风险较大。一次错误的共享就可能危及整个代码库。DAC 的工作原理是：“你拥有它，你决定谁可以加入。”

例如：：以 dev 邀请外部协作者并授予他们代码库的写入权限。协作者将不安全的代码直接推送到开发科。

In CI/CD，DAC 可能看起来像一个开发人员通过控制台手动授予临时团队成员生产部署访问权限，超出任何定义的访问控制策略。

如何选择实际有效的访问控制策略 Pipelines

Git 中的访问控制

利用 RBAC 管理贡献者、维护者和发布者角色。锁定受保护分支的合并权限。需要签名 commit并限制谁可以绕过保护。

示例：GitHub 分支保护规则

要求 pull request 合并前的评论。
消除陈旧 pull request 新批准 commits 被推了。
要求签名 commits.
对于生产关键型代码库，请跳过 DAC。不要随意授予写入权限。

Pipeline 政策执行

实施强制访问控制 pipelines. 可靠的 Mac 访问控制模型将 CI 作业限制为其所需的权限。

根据环境分离秘密。
每个环境使用唯一的令牌。
防止手动运行影响生产。

计费示例： CI 作业在暂存和生产过程中重复使用部署令牌，意外地将测试代码推送到实时状态。

添加 Mac 访问控制规则来控制令牌范围：

				
					yaml
env:
  DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN_PROD }}
if: github.ref == 'refs/heads/main' && github.actor == 'release-manager'

秘密范围示例：特定于环境的令牌使用

根据环境正确界定机密范围对于 防止意外或恶意的跨环境访问。 例如，开发环境的部署令牌永远不应该用于部署到生产环境。

以下是基于访问控制策略的控制如何在 GitHub Actions 中隔离秘密的使用：

				
					yaml
env:
  DEPLOY_TOKEN_DEV: ${{ secrets.DEPLOY_TOKEN_DEV }}
  DEPLOY_TOKEN_PROD: ${{ secrets.DEPLOY_TOKEN_PROD }}

jobs:
  deploy-dev:
    if: github.ref == 'refs/heads/dev' && github.actor == 'developer'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Dev
        run: ./deploy.sh
        env:
          TOKEN: ${{ env.DEPLOY_TOKEN_DEV }}

  deploy-prod:
    if: github.ref == 'refs/heads/main' && github.actor == 'release-manager'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Prod
        run: ./deploy.sh
        env:
          TOKEN: ${{ env.DEPLOY_TOKEN_PROD }}

这强制要求：

只有开发人员角色可以使用 dev 令牌触发部署开发科。
只有发布经理角色可以使用 prod 令牌部署到生产环境主科。

这种范围内的秘密使用降低了令牌泄漏在各个环境中升级的风险，并且 执行最低权限 CI/CD pipelines 遵循严格的访问控制策略。

工件访问控制

使用强制访问控制锁定工件注册表。 CI/CD 系统应该负责发布，而不是个人开发人员。

使用 RBAC 定义哪些团队可以从特定注册表中提取代码。开发人员可能只需要对生产环境软件包的读取权限。

				
					json
{
  "rules": [
    {
      "action": "read",
      "resource": "npm-package:internal/*",
      "allowed_roles": ["developer", "qa"]
    },
    {
      "action": "write",
      "resource": "npm-package:internal/*",
      "allowed_principals": ["ci-pipeline"]
    }
  ]
}

开发工作流中常见的访问控制失败

过度宽松的回购访问

问题： 授予太多用户对存储库的写入/管理访问权限。
事情的经过： 团队成员晋升或加入时无需审核权限，导致角色臃肿。
攻击者利用： 攻击者利用窃取的凭证或社会工程学手段攻击这些账户。一旦进入账户，他们就可以注入恶意代码、后门程序，或删除历史记录以隐藏痕迹。

开发和生产之间的共享权限

问题： 让开发和生产 pipeline的共享权限。
事情的经过： 团队在不同环境中重复使用相同的部署令牌或 CI 服务帐户。
攻击者利用： 开发环境的破坏使攻击者能够访问生产环境。强制访问控制可以通过将权限绑定到特定环境来防止这种情况。

手动上传工件

问题： 允许手动将工件上传到生产注册表。
事情的经过： 开发人员绕过 pipeline用于快速修复或热补丁。
攻击者利用： 受感染的开发人员机器可以将恶意软件直接上传到工件存储，绕过所有 CI/CD 安全检查。

注册管理机构政策滥用风险： 手动发布软件产品会在软件供应链中创建一个关键的攻击面。攻击者利用松懈的访问控制策略可以将恶意代码插入受信任的软件包或容器镜像，从而导致下游广泛入侵。近期发生的软件供应链事件表明，不受监管的工件上传可能会迅速升级为重大安全漏洞，影响无数用户和系统。

例子：一个一名拥有 npm 完整注册权限的实习生误发布了一个不稳定版本。如果攻击者入侵了该实习生的机器，他们可能会发布恶意软件。

实施强访问控制的实用步骤

将角色映射到精确的权限，抛弃“一刀切”的设置
自动检查您的访问控制策略 CI/CD pipelines
通过强制访问控制锁定注册表
持续记录并监控对关键系统的访问
像对待代码一样对待访问控制策略。每个错误都可能被利用

Xygeni 的作用：在 DevOps 工作流中执行和监控访问策略

西吉尼 通过解决 DevSecOps 中实际的日常访问控制策略实施挑战，帮助您将强制访问控制从理论转化为实践 pipelines.

解决 Git 访问权限过高的问题： Xygeni 持续监控 Git 代码库是否存在 RBAC 违规行为，例如未审核的角色分配或缺少分支保护。当访问控制策略偏离既定规则时，它会发出警报，并强制执行纠正措施，以避免意外合并或恶意 PR。
锁定 CI/CD Pipelines: CI 作业有时会超出预期的范围。Xygeni 检测到 CI/CD 作业请求或操作超出其分配的角色，实时识别范围蔓延和权限滥用。这有助于在内部实施 MAC 访问控制原则 pipeline通过将访问权限严格与工作的身份和目的联系起来。
执行工件发布控制： 如果开发人员仍在手动上传工件或图像，Xygeni 会阻止这种情况。它采用注册表级强制访问控制，以便只有经过验证的 pipeline 身份可以发布工件。无需再人工上传到生产注册表。
监控访问和标记异常： 使用 Xygeni，您可以了解谁访问了什么、何时访问了什么以及如何访问。它持续跟踪机密使用情况、存储库访问和注册表交互，以检测异常行为、标记错误配置并帮助进行事后分析。

底线： Xygeni 为访问控制策略带来自动化和强制执行，因此您的 DevOps 环境保持安全而不会减慢您的速度。

您需要什么样的访问控制策略？让我们来详细分析

必读文章