安全密码储存开发方法

开发和部署安全服务和应用程序需要与许多内部和外部系统整合，例如：身份验证和云端储存。
许多软件开发都需要与越来越多的服务整合，这要求开发人员处理多个机敏资料。
例如：资料库凭证，API Token，OAuth机敏资料等。

一旦将它们保存到设定文件中，它们经常会被放入云端的版本控制系统中，进入攻击者的手中。
机敏资料是出於某种原因而组成的，通常可以提供对许多资料，计算资源或权限帐户的存取。
我们必须妥善处理机敏资料，确保我们限制机敏资料的使用范围以及最小权限，并使意外泄漏的可能性降低。

问题范例

到Github的凭证泄漏是常见且麻烦的问题。
这可以使恶意行为者存取内部系统，资料，API等。
例如：在公开Web服务器上意外地取得包含凭证的Script文件。

常见范例是授予自己"管理员"的权限，因此他们不必担心确定自己所需的最低权限。
当这些凭证泄漏时，恶意参与者可以执行"管理员"可以做的任何事情。
例如：授予对该用户可能是其成员的所有群组的存取权限。

这些小组有潜力跨越团队，专案，客户等。
当开发人员使用自己的 LDAP/Google 凭证来测试时，通常会看到这种情况。
尽管它很便利，但却是一个坏习惯。

程序码中常见的机敏资料（未加密）
- 原始 HTML 页面
- 部署的 Javascript
- 公开 Github
- 公开 AWS Bucket
- 已部署的执行档文件
- 部署的 Script
- 部落格贴文

所有内容除机敏资料管理员外，永远不要在任何地方键入机敏资料。
混淆或替代(ROT-13、BASE-64编码等）也不是保护机敏资料的有效方法。

机敏资料

机敏资料是可以用来进行身份验证或授权的任何内容。

• 用户密码
• API Token
• TLS 证书

秘密也是任何机敏资料，敏感或个人身份讯息（PII）

• 信用卡
• 身分证号码
• 护照号码

最佳做法

常见范例：

• CI/CD Script
• 通过移动/网路应用存取云端资源
• 後端的服务帐户身份验证
• 私钥加密
• 传输加密（例如：HTTPS/TLS）

根据经验，应该在每个机会中都使用临时凭证。
并非所有系统都以支持此功能的方式建构，因此强烈建议使用管理工具，例如：AWS（Amazon Web Services）管理。
环境变量是可传递的，但不建议使用。
绝对不应该在程序码中储存机敏资料讯息。

保护机敏资料

在按照上述步骤准备好应用程序之後，请利用秘密管理基础结构来安全地储存和存取您的秘密。
Google Cloud KMS（金钥管理服务）或Amazon AWS KMS中的云端选项。

应用程序安全团队拥有监视源程序码资料库中机敏资料的工具，但是该机制仅应为最後一道防线。

GCP：

在Google Cloud中进行应用程序身份验证的最佳做法是使用服务帐户。
不要将服务帐户密码储存在应用程序源程序码中，而应使用指向应用程序源程序码外部的凭证（例如：保险柜）的环境变量。
限制谁可以充当服务帐户。
被授予服务帐户"服务帐户执行者"角色的用户可以存取该服务帐户有权存取的所有资源。

AWS：

AWS金钥通常采用以下格式：

• ʻAWS_ACCESS_KEY_ID：AKIA ****************`
• ʻAWS_SECRET_ACCESS_KEY：SYU *************************************`

这些金钥由AWS IAM（身份和存取管理）或AWS STS产生。

由IAM生成的金钥：这些金钥分配给IAM用户（每个用户最多2个金钥），个人（人员）或服务帐户（非人员）都可以使用。
但是，尽管这些金钥可用於服务帐户，但最佳实践是尽可能利用STS生成临时凭证，以供应用系统使用。

STS生成的金钥：这些金钥是临时金钥，预设情况下会在12小时（最少15分钟，最大36小时）内失效。
建议以最短的持续时间生成这些金钥。
受到破坏的金钥很快对恶意行为者变得毫无用处。
开发人员通常会使用他们的个人存取金钥，当有人离开公司并终止其帐户时，这可能会导致意外中断。
STS也避免了这种情况。

python
```
＃建立一个Session
session = boto3.Session（）

＃使用Session建立一个sts客户端
sts = session.client（"sts"）

＃取得当前Session的临时登入资料
token = sts.get_session_token（）['Credentials']
```

授予金钥的存取权限受随附的IAM策略（最小1，最大10）控制。
如果泄漏，则这些金钥会立即授予对随附IAM策略所允许的所有资源的全域存取权限。

为了安全，金钥维护必须遵循以下条件：

• 切勿使用为单个用户生成的金钥；始终使用临时STS金钥，附加的IAM角色或服务帐户（非人工IAM用户）。
  这是为了确保在例如：个人在公司内部变动或离开公司
• 确保以最低权限建立策略。
  对於不同的实例，最好是建立具有较少权限的多个服务帐户，而不是共享具有过多权限的单个帐户。
• 尽可能使用STS Token。
  如果角色分配可用於您在AWS中使用的任何服务，则应使用IAM角色和STS来获取临时凭证。

证书泄漏

凭证泄漏很关键，因为它们通常会授予对系统的高级别存取权限，并可能导致资料和系统受损。

常见问题

在大多数情况下，开发/测试环境与开发环境几乎相同。
一些情况下使用者又共享环境，从而增加了攻击者横向移动的风险。

除了对基础架构的直接风险外，现在这些秘密本身还储存在代管程序码的服务器以及任何复制或分支的程序码的人的所有开发人员工作站上。
假设应该是公开的秘密，因为仅限於没有办法追踪它们的传播。

当然，与个人密码一样，我们经常会遇到重用的情况。
因此，您的登入机敏资料与生产机敏资料相同。

我的测试程序码如何？

如果测试程序码利用"虚拟"凭证来测试解析程序码或错误处理。
这些"虚拟"凭证用於针对本地或临时模拟进行测试。
而"永久性"测试设施存在着有与开发/测试环境中相同的问题。

参考资料

• 红队资料
  • https://github.com/yeyintminthuhtut/Awesome-Red-Teaming
• AWS资料
  • 管理AWS存取金钥的最佳实践：https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best- practices.html
  • 使用AWS Secrets Manager：https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating.html
• GCP资料
  • 服务帐户：https://cloud.google.com/iam/docs/understanding- service- accounts
  • 环境变数：https://cloud.google.com/functions/docs/env-var