程序员征服基础设施即代码安全系列：密码的明文存储

在贵组织内部署安全的基础设施即代码（IaC）时，进展如何？这可能需要一定的学习过程，但掌握这些技能将是提升专业水平、在同行中脱颖而出，并更好地保护终端用户数据的绝佳机会。

在开始“Coders Conquer Security”系列的下一章之前，我想邀请您参与一个关于敏感数据存储漏洞的游戏化挑战；立即开始游戏，并从 Kubernetes、Terraform、Ansible、Docker 或 CloudFormation 中选择一个进行挑战：

感觉如何？如果您的知识储备还有待加强，请继续阅读：

如今，大多数计算机安全的核心都离不开密码。即使采用了双重身份验证或生物识别等其他安全手段，大多数组织仍将基于密码的安全机制作为其防护体系的一部分。对于许多公司而言，密码甚至是唯一的安全防线。

我们使用密码的频率极高，以至于我们甚至制定了创建密码的规则。这本意是为了降低密码遭受暴力破解或盲目猜测攻击的风险。当然，正如NordPass近期的一份报告所显示的那样，仍有人在使用弱密码。很难相信在2020年，人们竟然还在使用“12345”以及“chocolate”、“password”和“God”等容易被猜到的词汇来保护他们最敏感的资产。

总会有人不愿使用强密码，但大多数专业组织会强制用户按特定要求设置访问密码或短语。我们现在都已熟知这些规则：密码必须至少包含八个字符，且必须同时包含大小写字母、至少一个数字以及一个特殊字符。

糟糕的是，即使所有用户都严格遵守了创建强密码的规则，如果这些密码以明文形式存储，依然毫无意义。如果黑客能够读取整个密码文件，那么“12345”和“Nuts53!SpiKe&Dog12”在安全性上并无区别。

为什么以明文形式存储密码很危险？

以明文形式存储密码非常危险，因为它将系统和用户都置于风险之中。显而易见，如果黑客能够找到并读取用于访问系统的每一个密码，那将是一场灾难。他们可以轻易找到拥有管理员权限的用户，进而攻破整个系统或网站。由于他们使用的是合法的用户名和密码，内部安全机制可能无法察觉到入侵，或者在造成损失很久之后才发现。

让攻击者能够轻易窃取明文存储的密码也会伤害用户，因为许多人习惯重复使用密码。由于我们设置的密码创建规则过于复杂，许多人为了方便记忆，会在多个网站上重复使用相同的密码。如果攻击者攻破了一个密码文件，他们几乎肯定会尝试使用相同的用户名和密码访问其他系统，这使用户面临极大的二次犯罪风险。

在定义AWS资源时，如果不小心以明文形式存储密码，或者没有意识到这可能带来的严重后果，是很容易发生的。例如，以下代码是在使用Terraform模板定义AWS资源时存储密码的一种常见方法：

resource "aws_db_instance" "default" {
 engine                 = "mysql"
 allocated_storage      = 10
 instance_class         = "db.t2.micro"
 username               = "admin"
 password               = "s3.cr3t.admin.p2ss"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

在该示例中，用于管理AWS MySQL数据库实例的密码是以明文形式存储的。这意味着任何有权访问源代码仓库的人都可以读取甚至复制该密码。

保护密码的方法因框架而异，但每个平台都有相应的保护措施。例如，MySQL密码可以存储在AWS Secrets Manager等安全存储服务中：

resource "aws_db_instance" "default" {
 engine            = "mysql"
 allocated_storage = 10
 instance_class    = "db.t2.micro"
 username          = "admin"
 password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
 db_subnet_group_name   = aws_db_subnet_group.default.name
 vpc_security_group_ids = [aws_security_group.default.id]
}

在该示例中，Terraform模板将从AWS Secrets Manager服务中获取密码，因此密码永远不会以明文形式出现在模板文件中。

通过避免明文存储来保护密码

密码是您系统的核心钥匙，绝不应以明文形式存储。即使是组织内部人员，也不应有权访问庞大且未受保护的密码库，这也不应成为被认可的业务协议（如今有许多密码管理器支持加密凭据共享——没有任何借口！）。此外，还存在恶意内部人员窥探文件并获取非法访问权限的风险。

至于外部攻击，试想一下，如果通过SQL注入漏洞找到了数据库的后门，同时又获取了存储密码的目录，那将是双重打击。您认为这需要太多巧合才能实现吗？遗憾的是，这种场景确实在索尼2011年的数据泄露事件中发生过。当时超过一百万个客户密码以明文形式存储，Lulzsec黑客组织通过常见的SQL注入攻击获取了这些密码以及更多信息。

所有密码都应受到底层框架所提供防御机制的保护。对于 Terraform，切勿将密码存储在模板文件中。建议根据基础设施提供商的不同，使用 AWS Secrets Manager 或 Azure Key Vault 等安全存储服务。

强制用户创建安全密码固然重要，但后端也必须采取相应措施。避免以明文形式存储密码，对于保护用户和系统安全至关重要。明文存储的主要风险在于访问控制薄弱，实际上任何人都能查看这些密码。在基础设施即代码（IaC）环境中，由于更多人能够接触到敏感信息，因此必须对密码进行妥善哈希处理，并仅授予极少数必要人员访问权限，这一点尤为关键。

欢迎访问 Secure Code Warrior 博客页面，深入了解此漏洞，并学习如何保护您的组织和客户免受其他安全缺陷与漏洞的侵害。您还可以 尝试 IaC 挑战演示，在 Secure Code Warrior 培训平台上磨练并更新您的网络安全技能。