Azure ETL流程硬编码密码是否合规？求安全实践建议

硬编码登录账号、密码的做法完全不符合行业安全规范，存在极高的安全与合规风险，具体问题如下：

• 数据泄露风险：代码或配置提交到版本控制系统（如Azure DevOps Repos）后，所有有权限查看代码的人员都能获取敏感凭证；一旦代码泄露，攻击者可直接利用凭证访问Blob Storage、HiveDB、SQL Server等核心数据源，造成数据泄露或篡改。
• 合规性违规：GDPR、HIPAA、ISO27001等主流合规标准明确要求敏感信息需加密存储、遵循最小权限原则，硬编码凭证直接违反这类要求，可能引发合规处罚。
• 维护成本极高：凭证轮换（密码过期、权限变更）时，需修改所有涉及的脚本/配置再重新部署，容易遗漏且效率低下，还可能引发部署错误。

针对你司使用的Azure+Databricks环境，给出以下专业替代方案：

1. 用Azure Key Vault存储敏感凭证 #

将所有账号、密码、连接字符串等敏感信息存入Azure Key Vault，再通过Databricks的密钥范围关联访问：

• 在Databricks中创建Azure Key Vault-backed Secret Scope，关联对应Key Vault。
• 脚本中通过密钥API获取凭证，示例改造：

  def f_read_from_sql(tab, url=None):
      uid = dbutils.secrets.get(scope="etl-secrets", key="sql-us-admin-uid")
      pwd_sc = dbutils.secrets.get(scope="etl-secrets", key="sql-us-admin-pwd")
      # 后续数据库连接逻辑
  

2. 优先使用Azure AD身份认证 #

针对Azure生态内服务，用Azure AD身份认证替代账号密码，彻底避免硬编码：

• Blob Storage：给Databricks集群的服务主体分配Storage Blob Data Reader等最小权限，通过Azure AD认证访问存储，无需账号密码。
• HiveDB/Databricks Metastore：使用Databricks服务主体或用户的Azure AD身份认证，避免硬编码数据库账号。
• SQL Server：配置Azure AD认证，让Databricks通过服务主体或托管身份连接，无需硬编码SQL账号密码。

3. Azure DevOps流水线的凭证管理 #

在CI/CD流程中，禁止硬编码敏感信息：

• 使用Azure DevOps Library的变量组，将敏感变量标记为"保密"，流水线中直接引用变量，不会暴露明文。
• 配置Azure DevOps与Key Vault集成，流水线直接从Key Vault拉取凭证，避免在流水线中存储敏感信息。

4. 遵循最小权限原则 #

给ETL流程使用的账号分配仅能完成必要操作的权限：

• 比如Blob Storage仅允许读取指定容器，SQL Server仅允许读取目标表，避免使用示例中USadmin1这类高权限管理员账号，降低凭证泄露后的影响范围。

内容的提问来源于stack exchange，提问作者nemrod1986