安全基线 web凭据管理器_服务帐户凭据管理：如何改善安全状况

安全基线 web凭据管理器

背景 (Background)

When you want to make a call to an API to e.g. create a GCS bucket, you use your Google Cloud Platform (GCP) account to be authorized. That account is your identity and it has the format of an email address, like username@yourdomain.com. If you have the proper role/permissions to do so, your call will succeed.

当您要调用API来创建GCS存储桶时 ，可以使用您的Google Cloud Platform(GCP)帐户进行授权。 该帐户就是您的身份，并且具有电子邮件地址的格式，例如username@yourdomain.com。 如果您具有适当的角色/权限，则通话将成功。

Service accounts are another kind of account used by applications, not humans, to make authorized API calls. Service accounts also use an email address to identify them, following a format like this: sa-name@project-id.iam.gserviceaccount.com.

服务帐户是应用程序而非人工使用的另一种帐户，用于进行授权的API调用。 服务帐户还使用电子邮件地址来标识它们，格式如下： sa-name @ project-id .iam.gserviceaccount.com。

Service accounts differ from user accounts in a few ways, and specifically they don’t use passwords for authentication to Google. Instead, they use public & private RSA key-pairs. This may seem cumbersome, compared to managing passwords, but indeed it is a more appropriate mechanism for application authentication. And Google Cloud takes care of all the details for managing these keys: generation, rotation, deletion, escrow.

服务帐户在某些方面与用户帐户有所不同，特别是它们不使用密码进行Google身份验证。 相反，他们使用公共和私有RSA密钥对。 与管理密码相比，这似乎很麻烦，但实际上，这是一种更适合应用程序身份验证的机制。 Google Cloud负责管理这些密钥的所有详细信息：生成，轮换，删除，托管。

However, there are situations in which you need to manage those keys yourself. For example, if your application calling Google APIs is not running in a VM in Cloud but in a machine in your data center or in your laptop, you will need to download corresponding service account’s credentials containing the private RSA key to be able to authenticate to Google. Then, you take responsibility for managing these credentials and keeping them secure. That’s not an easy task and you should consider using a secrets management solution, like HashiCorp Vault.

但是，在某些情况下，您需要自己管理这些密钥。 例如，如果您的调用Google API的应用程序不是在Cloud中的VM中运行，而是在数据中心或笔记本电脑中的计算机中运行，则您需要下载包含私有RSA密钥的相应服务帐户的凭据才能进行身份验证谷歌。 然后，您将负责管理这些凭据并确保其安全。 这不是一件容易的事，您应该考虑使用秘密管理解决方案，例如HashiCorp Vault 。

渗透问题 (The exfiltration problem)

Not every company can afford to use a secrets management solution though. Even if you use it there’s still a possibility for those credentials to be leaked outside your company. It may be the case those credentials are stored in a repository (hopefully not a public one) where many developers have access. Or you may need to pass along those credentials to a partner hence losing visibility and control over them.

但是，并非每个公司都能负担得起使用秘密管理解决方案的费用。 即使您使用它，这些凭据仍然有可能泄漏到公司外部。 这些凭据可能存储在许多开发人员可以访问的存储库中(希望不是公共存储库)。 或者，您可能需要将这些凭据传递给合作伙伴，从而失去对它们的可见性和控制力。

For example, a common situation for a company is to run their CI/CD pipelines on-premises to deploy cloud infrastructure. They use a highly privileged service account to create projects, VPCs, VMs, firewall rules, and all type of resources, usually employing a provisioning tool like Terraform. The provisioning tool needs the service account credentials to call the APIs. If the credentials are exfiltrated an attacker can use them to access your resources and data, putting your business at risk.

例如，公司的常见情况是在本地运行其CI / CD管道以部署云基础架构。 他们使用特权很高的服务帐户来创建项目，VPC，VM，防火墙规则和所有类型的资源，通常使用诸如Terraform之类的供应工具。 设置工具需要服务帐户凭据才能调用API。 如果泄露了凭据，则攻击者可以使用它们来访问您的资源和数据，从而使您的企业面临风险。

Exfiltration of credentials

凭证泄露

减轻风险 (Mitigating the risks)

As I said, once you download credentials from GCP you are responsible for keep them secure. Still, if the risk of exfiltration is high and doesn’t let you sleep well or if you want to have a plan B just in case, you can leverage Cloud IAM to mitigate that risk and improve your security posture.

正如我所说，一旦您从GCP下载凭据，便有责任确保其安全。 但是，如果渗出的风险很高并且无法让您睡个好觉，或者如果您想制定计划B以防万一，则可以利用Cloud IAM减轻这种风险并改善安全状况。

Of course, the more privileged the service account, the higher the risk. If you could reduce its permissions you would be in a much better situation if it were compromised, since now the risk of someone accessing your systems and causing harm would be lower. But you still need complete access so, how to achieve both things at the same time?

当然，服务帐户的特权越多，风险就越高。 如果您可以减少它的权限，那么即使它受到威胁，也会处于更好的状况，因为现在，有人访问您的系统并造成损害的风险会更低。 但是您仍然需要完全访问权限，那么，如何同时实现这两个目标？

That’s something you can get by impersonating service accounts. The idea of impersonation is to use one identity A to act as another identity B but without having access to B’s credentials. This is achieved by granting identity A the ability to get an access token for identity B. This is the only permission we will grant to identity A, and whenever it wants to access any resource it will have to present the access token. In Google Cloud, this permission is granted through the Service Account Token Creator role. It allows you to create OAuth2 access tokens for a service account that Google uses to authorize API calls (there are more permissions in this role that I will not deal with in this article).

您可以通过模拟服务帐户来获得。 模拟的想法是使用一个身份A充当另一个身份B，但无需访问B的凭据。 这是通过向身份A授予获取身份B的访问令牌的能力来实现的。这是我们将授予身份A的唯一权限，并且每当要访问任何资源时，都必须提供访问令牌。 在Google Cloud中，此权限是通过服务帐户令牌创建者角色授予的。 它允许您为Google用于授权API调用的服务帐户创建OAuth2访问令牌(此角色中有更多权限，我在本文中将不涉及)。

Let’s take the example of deploying cloud infrastructure through Terraform from on-premises. sa-folder@ is a highly privileged service account you use to access resources in a folder representing an environment, e.g. production. Its credentials shouldn’t leave GCP so we create another service account sa-external@ to use on our CI/CD. We grant to this service account the token creator role on sa-folder@:

让我们以从本地通过Terraform部署云基础架构为例。 sa-folder @是高特权服务帐户，用于访问代表环境(例如生产环境)的文件夹中的资源。 它的凭据不应该离开GCP，因此我们创建了另一个服务帐户sa-external @以在我们的CI / CD上使用。 我们向此服务帐户授予sa-folder @上的令牌创建者角色：

Impersonation through Service Account Token Creator role

通过服务帐户令牌创建者角色进行模拟

The following example shows how to do this through ‘gcloud’ commands:

以下示例显示了如何通过“ gcloud”命令执行此操作：

# Create the highly privileged service account
$ gcloud iam service-accounts create sa-folder --project ${PROJECT_A_ID}# Assign roles on production folder. Using just 'owner' for simplicity
$ gcloud resource-manager folders add-iam-policy-binding ${PROD_FOLDER_ID} \
 --member=serviceAccount:sa-folder@${PROJECT_A_ID}.iam.gserviceaccount.com \
 --role=roles/owner# Create the external service account
$ gcloud iam service-accounts create sa-external --project ${PROJECT_B_ID}# Assign 'token creator' role on sa-folder@
$ gcloud iam service-accounts add-iam-policy-binding sa-folder@${PROJECT_A_ID}.iam.gserviceaccount.com \
 --project ${PROJECT_A_ID} \
 --member=serviceAccount:sa-external@${PROJECT_B_ID}.iam.gserviceaccount.com \
 --role=roles/iam.serviceAccountTokenCreator

Now you can download sa-external@’s credentials to use them out of GCP, by issuing calls to get access tokens for sa-folder@.

现在，您可以通过发出调用以获取sa-folder @的访问令牌的方式，下载sa-external @的凭据以在GCP中使用它们。

You may wonder, how is this better than the original situation? It is still possible to use sa-external@ to access resources! Of course it is, otherwise we couldn’t fulfill our own requirements. However there’s a level of indirection now, sa-extenal@ is not allowed to access resources in our projects directly so any API call will fail, with the exception of creating a token for sa-folder@. That’s another piece of information an attacker will need besides the credentials, and the added indirection will allow us to put more security controls.

您可能想知道，这比原始情况更好吗？ 仍然可以使用sa-external @来访问资源！ 当然可以，否则我们将无法满足自己的要求。 但是现在存在一个间接级别，不允许sa-extenal @直接访问我们项目中的资源，因此任何API调用都会失败，除了为sa-folder @创建令牌外。 这是攻击者除凭据之外还需要的另一条信息，而添加的间接访问将使我们能够放置更多的安全控件。

Mitigating the exfiltration of credentials

减轻凭证泄露

It is true that the process is a bit more complex now. It requires one more service account and two-step authorization. However the benefits of the increased security outweigh the added complexity. I will elaborate on this in following sections.

的确，现在的过程有些复杂。 它需要一个以上的服务帐户和两步授权。 但是，提高安全性的好处胜于增加的复杂性。 我将在以下各节中对此进行详细说明。

Regarding the extra step to authenticate, it only happens once at the beginning and the software flow is not substantially changed. For example, the Google provider for Terraform includes this feature and makes it really easy to use it. The following code shows the steps needed:

关于认证的额外步骤，它仅在开始时执行一次，并且软件流程没有实质性改变。 例如，Terraform的Google提供程序包括此功能，并使其真正易于使用。 以下代码显示了所需的步骤：

• First, declare a Terraform data source to get an OAuth2 access token for the highly privileged service account, sa-folder@. The script is run with sa-external@’s credentials.

  首先，声明一个Terraform 数据源以获取具有高度特权的服务帐户sa-folder @的OAuth2访问令牌。 该脚本使用sa-external @的凭据运行。

provider "google" {
  alias = "initial"
}data "google_service_account_access_token" "default" {
  provider               = google.
  target_service_account = "sa-folder@
  scopes                 = ["cloud-platform"]
  lifetime               = "3600s"
}

Note that the token is non-refreshable and can have a maximum lifetime of 1 hour.

请注意，令牌不可刷新，最长寿命为1小时。

• Then define a provider using the new access token, and use this provider to generate any resource.
  然后，使用新的访问令牌定义一个提供程序，并使用该提供程序生成任何资源。

provider "google" {
  access_token = data.google_service_account_access_token.default.access_token
}resource “google_compute_network” “vpc_network” {
  provider = google
  name  = “vpc-test”
}

审核访问 (Auditing access)

Audit is also simplified and enhanced when using impersonation. For example, auditing access for sa-folder@ means you have to audit every possible resource the service account can access to. Given this service account has access to multiple resources, its logs will be numerous and spread throughout multiple projects. However, an API call to get an access token for a service account produces an audit log. This way you can easily spot when the impersonation was used to access any resource without searching through all your projects. And every audit log from any resource accessed will also include the impersonating service account if one was used, as part of the authentication info.

使用模拟时，审核也得到简化和增强。 例如，审核sa-folder @的访问权限意味着您必须审核服务帐户可以访问的所有可能资源。 鉴于该服务帐户可以访问多个资源，因此其日志将很多并且分布在多个项目中。 但是，获取服务帐户访问令牌的API调用会生成审核日志。 这样，您无需浏览所有项目就可以轻松发现模拟何时用于访问任何资源。 来自任何访问的资源的每个审核日志还将包括模拟服务帐户(如果已使用)，作为身份验证信息的一部分。

Audit log of an impersonation API call

模拟API调用的审核日志

This capability can be used to enhance your security in some situations. Imagine you have several partners who require the same access to your systems. You can have one privileged service account and create impersonating service accounts and corresponding credentials per partner. This way, if one of the credentials is exfiltrated you can precisely point to the specific partner who should improve their security controls. Also, through IAM you can disable impersonating permissions for that partner without affecting the rest. The audit log for getting an access token includes other information like the caller IP and caller user agent, so you can develop programmatic solutions to harden your security further.

在某些情况下，可以使用此功能来增强安全性。 想象一下，您有几个需要对您的系统具有相同访问权限的合作伙伴。 您可以拥有一个特权服务帐户，并为每个合作伙伴创建模拟服务帐户和相应的凭据。 这样，如果泄露了一个凭证，则可以精确地指向应该改善其安全控制的特定合作伙伴。 另外，通过IAM，您可以禁用该伙伴的模拟权限，而不会影响其余的伙伴。 获取访问令牌的审核日志包括其他信息，例如呼叫者IP和呼叫者用户代理 ，因此您可以开发编程解决方案来进一步增强安全性。

If you try to achieve similar results without using impersonation you will see how painful it may be. And in particular, if you were thinking on creating several credentials for the same service account to distribute to your partners, it doesn’t help. Every credential has a key identifier but this key id is not recorded in audit logs.

如果您尝试在不使用模拟的情况下获得相似的结果，您会发现它可能会很痛苦。 特别是，如果您正在考虑为同一服务帐户创建多个凭据以分发给您的合作伙伴，那将无济于事。 每个凭据都有一个密钥标识符，但是此密钥ID不会记录在审核日志中。

再一层 (One more layer)

We have seen how impersonation can help mitigate risks of exfiltrations in several ways while also improving credentials management. We can go further and, for some cases, add another layer of security. Cloud IAM offers you one more mechanism you can leverage to improve your security posture, alone or in combination with impersonation: Cloud IAM Conditions.

我们已经看到模拟如何以多种方式帮助减轻渗透风险，同时还改善凭证管理。 我们可以走得更远，在某些情况下，还可以增加另一层安全性。 Cloud IAM为您提供了一种可以单独或与模拟结合使用来改善安全状况的机制： Cloud IAM条件 。

With IAM Conditions, you can specify conditions to enforce attribute-based access control on IAM grants. This means that a role granted to an identity on a resource can be conditioned to certain attributes of the resource like its type, or attributes of the request like the IP from where the API call is made. Which attributes you can use depends on the Google Cloud service, but the number of attributes and services supporting them are growing.

使用IAM条件，您可以指定条件以对IAM授予实施基于属性的访问控制。 这意味着授予资源身份的角色可以以资源的某些属性(例如其类型)或请求的属性(例如从中进行API调用的IP)为条件。 您可以使用哪些属性取决于Google Cloud服务，但是支持它们的属性和服务的数量正在增加。

Let’s take the scenario of running a CI/CD pipeline on-premises. You created sa-folder@, and sa-external@ with the token creator role on sa-folder@. Let’s say you only deploy to production on Mondays, after reviewing changes committed and have your SRE team ready for unexpected events. In this case, the permanent grant of sa-external@ on sa-folder@ is really not needed, and an unneeded security risk too. But granting and removing access repeatedly is not practical. You can develop a programmatic solution, however IAM Conditions offers a better way. With it, you can define your own deployment window, granting impersonating permissions only on Mondays during working hours:

让我们以在本地运行CI / CD管道为例。 您在sa-folder @上创建了具有令牌创建者角色的sa-folder @和sa-external @。 假设您仅在检查已提交的更改并让SRE团队为意外事件做好准备之后，才在星期一部署到生产。 在这种情况下，实际上不需要在sa-folder @上永久授予sa-external @的权限，并且也不需要不必要的安全风险。 但是反复授予和删除访问权限是不切实际的。 您可以开发程序化解决方案，但是IAM条件提供了更好的方法。 使用它，您可以定义自己的部署窗口 ，仅在工作时间的星期一授予模拟权限：

Applying IAM Conditions to create a deployment window

应用IAM条件创建部署窗口

By creating this deployment window, you are reducing the window of opportunity for an attacker to access your systems. Your SecOps team will appreciate it and feel a bit more relaxed during weekends. And any attempt to access out of this window will generate an audit log that you can act upon.

通过创建此部署窗口，可以减少攻击者访问系统的机会。 您的SecOps团队将不胜感激，并在周末感到更加轻松。 并且，任何尝试访问此窗口之外的操作都会生成审核日志，您可以对其进行操作。

If a static deployment window doesn’t fit your needs and you need on-demand access, you can create a solution based e.g. on Cloud Functions that on a press of a button configures IAM Conditions to grant temporary access for a certain period of time.

如果静态部署窗口无法满足您的需要，并且您需要按需访问，则可以创建基于云功能的解决方案，例如，只需按一下按钮即可将IAM条件配置为在一段时间内授予临时访问权限的Cloud Functions 。

结论 (Conclusion)

Downloading service account’s credentials should be avoided, management of credentials is a risky task difficult to get right. But sometimes you don’t have an option. To help mitigate the associated risks, I explained some techniques and mechanisms you can easily apply to improve your security posture. You should do your due diligence when managing secrets, and I hope this article will help you!

应避免下载服务帐户的凭据，凭据管理是一项危险的任务，难以正确处理。 但是有时候您别无选择。 为了帮助减轻相关的风险，我解释了一些可以轻松应用于改善安全状况的技术和机制。 在管理机密信息时，您应该尽职调查，希望本文对您有所帮助！

翻译自: https://medium.com/google-cloud/service-account-credentials-management-how-to-improve-your-security-posture-663bca03a52

安全基线 web凭据管理器