0Pricing
Cloud & IT Cert Prep · 课时

安全机密管理与环境变量

使用机密管理器(Vault、AWS Secrets Manager)并在运行时注入环境变量,避免在源代码中硬编码机密。

安全机密管理与环境变量 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cloud & IT Cert Prep 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。

硬编码 Secret 问题

硬编码 Secret——直接嵌入源代码中的 API 密钥、数据库密码、TLS 私钥和 OAuth 令牌——是最常见且最容易避免的安全漏洞之一。源代码中的 Secret 会暴露在版本控制历史中(即使删除后仍可能存在),所有拥有仓库访问权限的开发人员都能看到;当仓库意外公开时,也经常会发生泄露。GitGuardian 和 truffleHog 等工具会持续扫描 GitHub 等平台上泄露的 Secret。

# DANGEROUS: hardcoded secret in source code
# db_password = 'P@ssw0rd#2026'
# api_key = 'sk-live-abc123xyz789'
# aws_secret = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'

# These secrets are now:
# - In git history (even if later deleted)
# - Visible to all repo contributors
# - Potentially in CI/CD logs
# - Often leaked when repos go public accidentally

环境变量:更好,但仍然不够

环境变量通过主机 OS 或容器编排器在运行时注入 Secret,从而将 Secret 从源代码中移除。应用程序读取 os.environ['DB_PASSWORD'],而不是读取硬编码的值。这比硬编码更好,但环境变量也存在弱点:它们会出现在进程列表中,会被子进程继承,而且经常进入崩溃转储和调试日志,同时还需要手动轮换。它们适用于开发环境,但单独使用不足以满足生产环境的 Secret 管理需求。

# Environment variable pattern:
# In .env file (NEVER commit to git):
# DB_PASSWORD=P@ssw0rd#2026
# API_KEY=sk-live-abc123xyz789

# In .gitignore:
# .env
# *.env
# .env.*

# In application code:
# db_password = os.environ.get('DB_PASSWORD')
# api_key = os.environ.get('API_KEY')

# Risk: env vars visible in 'ps aux' output,
# inherited by child processes, appear in /proc/<pid>/environ

专用 Secret 管理器

Secret 管理器是专门用于存储、轮换和审计 Secret 访问的系统。主要解决方案包括 HashiCorp Vault(开源版和企业版)、AWS Secrets Manager、Azure Key Vault和Google Cloud Secret Manager。应用程序会在运行时向 Secret 管理器进行身份验证,获取 Secret 并使用它——Secret 从不会存储在磁盘或环境变量中。所有访问都会被记录,从而可以审计谁在何时访问了哪个 Secret。

# HashiCorp Vault secret retrieval (conceptual):
# Application authenticates to Vault using:
#   - AWS IAM role (in cloud environments)
#   - Kubernetes service account token
#   - AppRole credentials

# After authentication, retrieve secret:
# vault kv get -field=password secret/prod/database

# In application (Python SDK):
# client = hvac.Client(url='https://vault.company.com')
# client.auth.aws.iam_login(role='prod-app')
# secret = client.secrets.kv.read_secret('prod/database')
# db_password = secret['data']['password']

自动 Secret 轮换

相比环境变量,Secret 管理器的一项重要优势是自动轮换。AWS Secrets Manager 可以按计划自动轮换 RDS 数据库密码(例如每 30 天一次),而不需要重新部署应用程序。Secret 管理器会同时更新数据库中的密码和所存储的 Secret。每次连接时获取 Secret 的应用程序会自动获得新的凭据。这消除了服务账户密码“永久不变”的常见做法。

# AWS Secrets Manager rotation configuration:
# Secret:         prod/app-database-credentials
# Rotation:       enabled
# Frequency:      every 30 days
# Lambda function: SecretsManager-MyRDSRotation

# Rotation process:
# 1. Lambda creates new DB password
# 2. Updates secret in Secrets Manager
# 3. Updates password on RDS instance
# 4. Tests new credentials work
# 5. Deprecates old credentials
# Application: always calls GetSecretValue at runtime -> gets fresh value

The .gitignore 防御

防止密钥被提交的第一道防线,是妥善维护的 .gitignore 文件,排除所有可能包含密钥的文件。不过,.gitignore 只能防止未来的提交,已经提交的密钥仍会保留在 git 历史记录中。如果密钥被意外提交,必须立即将其视为已泄露:轮换该密钥,然后可以选择使用 git filter-repo 等工具重写历史记录(合规要求通常需要这样做,但仅此还不够,因为密钥可能已经被提取)。

# Recommended .gitignore entries for secret files:
# .env
# .env.*
# *.pem
# *.key
# *.p12
# *.pfx
# credentials.json
# service_account*.json
# secrets.yaml
# config/secrets.yml
# terraform.tfvars  (may contain cloud credentials)
# .aws/credentials

# Pre-commit hook to scan for secrets before commit:
# pre-commit install
# hook: detect-secrets / gitleaks / truffleHog

基础设施即代码中的密钥

基础设施即代码(IaC)文件(Terraform、CloudFormation、Kubernetes 清单)经常包含密钥,例如数据库连接字符串、环境变量声明中的 API 密钥以及 TLS 证书。这些文件通常会被提交到版本控制系统,从而造成密钥暴露风险。解决方案包括 Vault 动态密钥(Vault 会为每次 Terraform 运行生成专用的短期凭据)、Kubernetes Secrets(存储在 etcd 中,必须进行静态加密),以及在运行时从密钥管理器同步密钥到 Kubernetes 的 external-secrets-operator。

密钥的最小权限原则

每个 Application 或服务都应只能访问其明确需要的密钥,这就是应用于密钥的最小权限原则。Web Application 需要数据库 password,但不需要 CA 私钥。报告任务需要只读数据库凭据,而不需要写入权限。密钥管理器通过访问策略强制执行这一原则:策略规定哪些身份(IAM 角色、服务账户、AppRoles)可以读取哪些密钥,并记录所有访问,以便进行 audit。

# Vault policy: web application can read DB password only
# policy name: web-app-policy
# path 'secret/prod/database' {
#   capabilities = ['read']
# }
# path 'secret/prod/tls-certs/*' {
#   capabilities = []  # DENY - app does not need TLS keys
# }

# This policy is assigned to the web app's AppRole.
# The reporting service gets a separate policy with
# only 'secret/prod/reporting-db-readonly' access.

动态密钥

动态密钥会按需为特定请求者生成,并自动过期。Vault 可以生成一个临时数据库凭据,有效期为 1 小时,并与请求它的特定服务关联。过期后,数据库会自动撤销该凭据。这种方式意味着不存在可供窃取的长期静态凭据;即使攻击者获取了动态凭据,它也会很快过期,并且在 audit 日志中与请求者身份相关联。

# Vault dynamic secrets: temporary DB credentials
# Application calls Vault to get a DB credential:
# vault read database/creds/web-app-role
#
# Vault response:
# username: v-web-app-x7k2m-1234567890  (unique, temporary)
# password: A1b2C3d4E5f6G7h8            (randomly generated)
# lease_duration: 1h                     (auto-expires)
#
# After 1 hour, Vault instructs DB to revoke this user.
# No static password ever exists for the attacker to steal.

CI/CD 流水线中的密钥

CI/CD 流水线经常需要密钥,例如用于部署的云提供商凭据、Docker registry 令牌和签名密钥。Never 将密钥存储在流水线脚本或配置文件中。相反,请使用流水线平台内置的密钥存储(GitHub Actions Secrets、GitLab CI Variables、Jenkins Credentials Store),或在运行时使用机器身份从中央 Vault 获取密钥。将密钥变量标记为在日志中隐藏,以防止其意外暴露在构建输出中。

# GitHub Actions: using secrets in pipeline
# secrets.yml in GitHub Settings -> Secrets (encrypted storage)
# Secret: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

# In .github/workflows/deploy.yml:
# env:
#   AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
#   AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

# Best practice: use OIDC federation instead
# GitHub -> AWS trust relationship via OIDC token
# -> No static AWS keys needed at all

审计密钥访问

密钥管理器会为每个密钥访问事件提供全面的 audit 日志:哪个身份访问了哪个密钥、来自哪个 IP、访问时间,以及访问是成功还是被拒绝。这些日志对于合规(SOC 2、PCI-DSS)和事件响应至关重要。当怀疑某个凭据已遭泄露时,audit 日志可以显示哪些系统在何时访问过它,从而支持快速识别可能受影响的系统并作出遏制决策。

用于防止密钥泄露的提交前钩子

提交前钩子是在每次 git 提交最终完成前自动运行的脚本,可在密钥进入版本控制历史记录之前检测到它们。detect-secrets(Yelp)、GitLeaks 和 git-secrets(AWS)等工具可以作为提交前钩子运行,扫描暂存文件中是否存在与 API 密钥、连接字符串、私钥和 JWT 令牌匹配的模式。如果检测到密钥,提交会被拒绝,并提示开发人员删除该凭据。提交前框架让您可以轻松地在团队之间添加和共享钩子配置。

# Installing detect-secrets as pre-commit hook:
# 1. Install: pip install detect-secrets
# 2. Create baseline: detect-secrets scan > .secrets.baseline
# 3. Add to .pre-commit-config.yaml:
#    repos:
#      - repo: https://github.com/Yelp/detect-secrets
#        rev: v1.4.0
#        hooks:
#          - id: detect-secrets
#            args: ['--baseline', '.secrets.baseline']
# 4. Install hooks: pre-commit install

# Now every commit attempt is scanned:
# git commit -m 'add config'
# -> detect-secrets runs
# -> if AWS key pattern found: COMMIT BLOCKED
# -> developer must remove secret and use secrets manager

快速检查

测试您对本课 CompTIA Security+(SY0-701)概念的理解。

课程回顾

在本课中,您学到了:必须消除源代码中的硬编码密钥,并使用 Vault 或 AWS Secrets Manager 等密钥管理器替代;自动轮换会移除长期凭据,防止攻击者在首次入侵后继续滥用;动态密钥和最小权限访问策略可以降低任何单个暴露密钥的价值。接下来,我们将学习依赖项安全和软件组成分析。

常见问题解答

「安全机密管理与环境变量」课时是免费的吗?

是的 — 「安全机密管理与环境变量」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Cloud & IT Cert Prep 课程的其余内容,请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。

「安全机密管理与环境变量」这节课中我会学到什么?

使用机密管理器(Vault、AWS Secrets Manager)并在运行时注入环境变量,避免在源代码中硬编码机密。 你通过在浏览器中直接运行的动手代码来练习 Cloud & IT Cert Prep,全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Cloud & IT Cert Prep 需要有经验吗?

无需任何先前经验。CoddyKit 上的 Cloud & IT Cert Prep 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。

「安全机密管理与环境变量」课时需要多长时间?

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。

我能在这节 Cloud & IT Cert Prep 课中编写并运行代码吗?

能。每节 Cloud & IT Cert Prep 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 输入验证与输出编码
  2. 安全机密管理与环境变量
  3. 依赖项安全与软件组成分析
  4. DevSecOps:将安全左移到流水线中
← 返回 Cloud & IT Cert Prep