Azure Key Vault

发表于 更新于 分类于 Waline：

Azure Key Vault is a tool for securely storing and accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. A vault is logical group of secrets.

上面这一段是Azure官方文档的描述，作者在阅读了Microsoft Azure文档之后，对其基本的概念进行了提取和总结，并在原文中加入了一些自己的理解。阅读完中文就能对key vault有个大概的认识，英文原文是比较专业的描述，不影响理解，如果想进一步了解可以去阅读文末提供的链接。

What is Azure Key Vault

简单来讲，Azure Key Vault 就是提供了一个能够安全存储你的敏感数据的地方，想要获取这些数据就必须通过身份校验以及权限校验，我们可以把类似于证书，数据库配置等敏感信息放在这里，而不需要硬编码到代码中。在使用时我们将敏感信息存储到key vault上后，会获取对应的名称，我们只需要通过api去key vault中通过名字（也可以添加版本信息）获取对应的信息就好，这些信息可以是密钥（只能get公钥），证书信息，或者一些配置信息。当然这些信息并不是任何人直接去调用api就可以获取的，而是需要你的Identity信息被用于创建该Key Vault的Tenant下面的Subscription所承认，获取承认的方式有很多种，可以通过id-token，或者密码等。

Azure Key Vault帮助解决以下问题：

  • 秘密管理 -Azure Key Vault可用于安全存储和严格控制对令牌，密码，证书，API密钥和其他秘密的访问。
  • 密钥管理 -Azure Key Vault也可以用作密钥管理解决方案。使用Azure Key Vault可以轻松创建和控制用于加密数据的加密密钥。
  • 证书管理 -Azure Key Vault也是一项服务，使您可以轻松地调配，管理和部署公共和私有安全套接字层/传输层安全性（SSL / TLS）证书，以与Azure和内部连接的资源一起使用。
  • 存储由硬件安全模块支持的机密-机密和密钥可以通过软件或FIPS 140-2 2级验证HSM进行保护。

使用Azure Key Vault 可以集中存储应用程序的机密数据并可以控制这些数据的分发。而且由于开发人员可以不用在程序中硬编码安全信息，大大提高了程序的安全性。

存储在Azure Key Vault中的信息会被可靠的加密算法保存。

同时Azure Key Vault可以基于Azure AD进行访问的权限控制，同时可以记录下来是谁在什么时间访问了哪一条数据。

Azure Key Vault basic concepts

  • 承租人/租户( Tenant )：承租人是拥有和管理Microsoft云服务的特定实例的组织。最常用于指组织的Azure和Office 365服务集。
  • 保管库所有者( Vault owner )：保管库所有者可以创建密钥保管库并获得对其的完全访问权和控制权。保管库所有者还可以设置审核以记录谁访问了机密和密钥。管理员可以控制密钥生命周期。他们可以滚动到密钥的新版本，进行备份并执行相关任务。
  • 保管箱使用者( Vault consumer )：当保管库所有者授予使用者访问权时，保管箱使用者可以对密钥保管库内的资产执行操作。可用的操作取决于所授予的权限。
  • 资源( Resource )：资源是可通过Azure进行管理的项目。常见示例包括虚拟机，存储帐户，Web应用程序，数据库和虚拟网络。还有更多。
  • 资源组( Resource group )：资源组是一个容器，其中包含Azure解决方案的相关资源。资源组可以包含解决方案的所有资源，也可以仅包含您要作为组进行管理的资源。您可以根据对组织最有意义的决定来决定如何向资源组分配资源。
  • 服务主体( Service principal )：Azure服务主体是用户创建的应用程序，服务和自动化工具用来访问特定Azure资源的安全身份。可以将其视为具有特定角色且受到严格控制的权限的“用户身份”（用户名，密码或证书）。与一般用户身份不同，服务主体只需要做特定的事情。如果仅授予它执行管理任务所需的最低权限级别，则可以提高安全性。
  • Azure Active Directory（Azure AD）：Azure AD是租户的Active Directory服务。每个目录都有一个或多个域。一个目录可以有许多与之关联的订阅，但只能有一个租户。每个组织可以有一个租户，这个租户有自己的ID用于标识自己，每个Tenant都有自己的一个或者多个SubScription，Subscription与Azure AD directory是多对一的关系。每个人都可以去Azure上申请自己的账号，这个账号在Azure上叫做Identity，每个Identity可以创建Azure AD account。如果你的Azure AD account在某个Tenant的Azure AD directory中，并且Tenant授予了你某个Subscription的权限，你就可以使用该Subscription下的Services。具体可以去查看文档
  • Azure租户ID( Azure tenant ID )：租户ID是在Azure订阅中标识Azure AD实例的独特方法。
  • 托管身份( Managed identities )：Azure Key Vault提供了一种安全存储凭据以及其他密钥和机密的方法，但是您的代码需要通过Key Vault进行身份验证才能检索它们。通过使用托管身份，可以通过在Azure AD中为Azure服务提供自动托管身份来简化解决此问题的步骤。您可以使用此身份对Key Vault或支持Azure AD身份验证的任何服务进行身份验证，而无需在代码中包含任何凭据。

Anybody with an Azure subscription can create and use key vaults. Although Key Vault benefits developers and security administrators, it can be implemented and managed by an organization’s administrator who manages other Azure services.

Security

这一部分主要讲的就是Azure Key Vault是如何确保你的信息只能被你授权的人看到。

对于Key Vault的管理有两种级别，也对应着两种access model，第一种级别叫做management plane，这种级别的关系可以对Key Vault本身进行操作，可以创建和删除一个Key Vault，第二种级别就是对Key Vault中的数据进行管理。但是不管那种级别，其身份校验都是通过Azure AD来实现的，通过基于**角色的权限控制（RBAC）**来判断一个用户可以对Key Vault做出怎样的操作。

在不同级别之下做出的RBAC只适用于该级别之下的用户，比如你在Subscription的级别下做出的RBAC就只适用于该Subscription下的用户。

同时对于secret， key，certificate的权限管理是分开的，也就是说你同一个Subscription下的用户在同一个Key Vault中可能对secret有访问权限，但是对于key却没有。

You need to protect encryption keys and secrets like certificates, connection strings, and passwords in the cloud so you are using Azure Key Vault. Since you are storing sensitive and business critical data, you need to take steps to maximize the security of your vaults and the data stored in them.

Identity and access management

When you create a key vault in an Azure subscription, it’s automatically associated with the Azure AD tenant of the subscription. Anyone trying to manage or retrieve content from a vault must be authenticated by Azure AD.

  • Authentication establishes the identity of the caller.
  • Authorization determines which operations the caller can perform. Authorization in Key Vault uses a combination of Role based access control (RBAC) and Azure Key Vault access policies.

Access model overview

Access to vaults takes place through two interfaces or planes. These planes are the management plane and the data plane.

  • The management plane is where you manage Key Vault itself and it is the interface used to create and delete vaults. You can also read key vault properties and manage access policies.
  • The data plane allows you to work with the data stored in a key vault. You can add, delete, and modify keys, secrets, and certificates.

To access a key vault in either plane, all callers (users or applications) must be authenticated and authorized. Both planes use Azure Active Directory (Azure AD) for authentication. For authorization, the management plane uses role-based access control (RBAC) and the data plane uses a Key Vault access policy.

The model of a single mechanism for authentication to both planes has several benefits:

  • Organizations can control access centrally to all key vaults in their organization.
  • If a user leaves, they instantly lose access to all key vaults in the organization.
  • Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security

Managing administrative access to Key Vault

When you create a key vault in a resource group, you manage access by using Azure AD. You grant users or groups the ability to manage the key vaults in a resource group. You can grant access at a specific scope level by assigning the appropriate RBAC roles. To grant access to a user to manage key vaults, you assign a predefined key vault Contributor role to the user at a specific scope. The following scopes levels can be assigned to an RBAC role:

  • Subscription: An RBAC role assigned at the subscription level applies to all resource groups and resources within that subscription.
  • Resource group: An RBAC role assigned at the resource group level applies to all resources in that resource group.
  • Specific resource: An RBAC role assigned for a specific resource applies to that resource. In this case, the resource is a specific key vault.

Controlling access to Key Vault data

Key Vault access policies grant permissions separately to keys, secrets, or certificate. You can grant a user access only to keys and not to secrets. Access permissions for keys, secrets, and certificates are managed at the vault level.

Network access

You can reduce the exposure of your vaults by specifying which IP addresses have access to them. The virtual network service endpoints for Azure Key Vault allow you to restrict access to a specified virtual network. The endpoints also allow you to restrict access to a list of IPv4 (internet protocol version 4) address ranges. Any user connecting to your key vault from outside those sources is denied access.

After firewall rules are in effect, users can only read data from Key Vault when their requests originate from allowed virtual networks or IPv4 address ranges. This also applies to accessing Key Vault from the Azure portal. Although users can browse to a key vault from the Azure portal, they might not be able to list keys, secrets, or certificates if their client machine is not in the allowed list. This also affects the Key Vault Picker by other Azure services. Users might be able to see list of key vaults, but not list keys, if firewall rules prevent their client machine.

Azure Key Vault security worlds and geographic boundaries

Azure Key Vault 是一个多租户服务，同一个Azure Location使用同一个HSM，享有相同的安全边界，也就是在同一个安全世界中。

同时Azure Key Vault可以对数据进行备份，但是备份需要满足两个条件：

  • 两个Azure locations 在同一地理位置
  • 两个key vaults 属于同一个订阅

Secure access to a key vault

Access model overview

对密钥库的访问通过两个接口进行控制:管理平面和数据平面。管理平面是您管理密钥库本身的地方。此平面中的操作包括创建和删除密钥保险库、检索密钥保险库属性和更新访问策略。数据平面是处理存储在密钥库中的数据的地方。您可以添加、删除和修改密钥、秘密和证书。
要访问任一平面中的密钥库，所有调用方(用户或应用程序)必须具有适当的身份验证和授权。身份验证建立

Active Directory authentication

When you create a key vault in an Azure subscription, it’s automatically associated with the Azure AD tenant of the subscription. All callers in both planes must register in this tenant and authenticate to access the key vault. In both cases, applications can access Key Vault in two ways:

  • User plus application access: The application accesses Key Vault on behalf of a signed-in user. Examples of this type of access include Azure PowerShell and the Azure portal. User access is granted in two ways. Users can access Key Vault from any application, or they must use a specific application (referred to as compound identity).
  • Application-only access: The application runs as a daemon service or background job. The application identity is granted access to the key vault.

For both types of access, the application authenticates with Azure AD. The application uses any supported authentication method based on the application type. The application acquires a token for a resource in the plane to grant access. The resource is an endpoint in the management or data plane, based on the Azure environment. The application uses the token and sends a REST API request to Key Vault. To learn more, review the whole authentication flow.

The model of a single mechanism for authentication to both planes has several benefits:

  • Organizations can control access centrally to all key vaults in their organization.
  • If a user leaves, they instantly lose access to all key vaults in the organization.
  • Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security.

Resource endpoints

应用程序通过端点访问两个平面。

The access controls for the two planes work independently. To grant an application access to use keys in a key vault, you grant data plane access by using a Key Vault access policy. To grant a user read access to Key Vault properties and tags, but not access to data (keys, secrets, or certificates), you grant management plane access with RBAC. **

Certificate

About keys, secrets, and certificates

Azure Key Vault使Microsoft Azure应用程序和用户能够存储和使用几种类型的秘密/密钥数据

  • 加密密钥（Cryptographic key）：支持多种密钥类型和算法，并允许对高价值密钥使用硬件安全模块（HSM）。我们通过api其实只能获取到公钥。
  • 机密(Secrets)：提供机密的安全存储，例如密码和数据库连接字符串。
  • 证书(Certificates)：支持基于密钥和机密构建的证书，并添加了自动续订功能。
  • Azure存储(Azure Storage)：可以为您管理Azure存储帐户的密钥。在内部，Key Vault可以使用Azure存储帐户列出（同步）密钥，并定期重新生成（旋转）密钥。

Key Vaults keys

Key Vault中的加密密钥表示为JSON Web密钥[JWK]对象。JWK / JWA基本规范也得到了扩展，以启用Key Vault实施所特有的密钥类型。例如，使用特定于HSM供应商的包装导入密钥，可以安全地运输只能在Key Vault HSM中使用的密钥。

  • “软”密钥：Key Vault在软件中处理过的密钥，但是使用HSM中的系统密钥在静止状态下进行了加密。客户可以导入现有的RSA或EC（椭圆曲线）密钥，或请求Key Vault生成一个。
  • “硬”键：在HSM（硬件安全模块）中处理的键。这些密钥在Key Vault HSM安全世界之一（每个地理区域都有一个安全世界以保持隔离）中受到保护。客户端可以以软形式或通过从兼容的HSM设备导出来导入RSA或EC密钥。客户还可以请求Key Vault生成密钥。此密钥类型将key_hsm属性添加到JWK获取以携带HSM密钥材料。

在密钥库中创建密钥后，可以使用该密钥执行以下加密操作：

  • 签名并验证：严格来说，此操作是“签名哈希”或“验证哈希”，因为Key Vault不支持内容哈希作为签名创建的一部分。应用程序应对要在本地签名的数据进行哈希处理，然后请求Key Vault对哈希进行签名。对于可能无法访问[公开]密钥材料的应用程序，为方便操作提供了对签名哈希的验证的支持。为了获得最佳的应用程序性能，请验证是否在本地执行操作。
  • 密钥加密/包装：可以将存储在Key Vault中的密钥用于保护另一个密钥，通常是对称内容加密密钥（CEK）。当Key Vault中的密钥不对称时，将使用密钥加密。例如，RSA-OAEP和WRAPKEY / UNWRAPKEY操作等效于ENCRYPT / DECRYPT。如果“密钥保管库”中的密钥是对称的，则使用密钥包装。例如，AES-KW。支持WRAPKEY操作是为了方便无法访问[公开]密钥资料的应用程序。为了获得最佳的应用程序性能，WRAPKEY操作应在本地执行。
  • 加密和解密：存储在Key Vault中的密钥可用于加密或解密单个数据块。块的大小由密钥类型和所选的加密算法确定。为方便起见，提供了Encrypt操作，用于可能无法访问[公开]密钥资料的应用程序。为了获得最佳的应用程序性能，应在本地执行加密操作。

Key Vault secrets

From a developer’s perspective, Key Vault APIs accept and return secret values as strings. Internally, Key Vault stores and manages secrets as sequences of octets (8-bit bytes), with a maximum size of 25k bytes each. The Key Vault service doesn’t provide semantics for secrets. It merely accepts the data, encrypts it, stores it, and returns a secret identifier (“id”). The identifier can be used to retrieve the secret at a later time.

For highly sensitive data, clients should consider additional layers of protection for data. Encrypting data using a separate protection key prior to storage in Key Vault is one example.

Key Vault also supports a contentType field for secrets. Clients may specify the content type of a secret to assist in interpreting the secret data when it’s retrieved. The maximum length of this field is 255 characters. There are no pre-defined values. The suggested usage is as a hint for interpreting the secret data. For instance, an implementation may store both passwords and certificates as secrets, then use this field to differentiate. There are no predefined values.

Key Vault Certificates

Key Vault certificates support provides for management of your x509 certificates and the following behaviors:

  • Allows a certificate owner to create a certificate through a Key Vault creation process or through the import of an existing certificate. Includes both self-signed and Certificate Authority generated certificates.
  • Allows a Key Vault certificate owner to implement secure storage and management of X509 certificates without interaction with private key material.
  • Allows a certificate owner to create a policy that directs Key Vault to manage the life-cycle of a certificate.
  • Allows certificate owners to provide contact information for notification about life-cycle events of expiration and renewal of certificate.
  • Supports automatic renewal with selected issuers - Key Vault partner X509 certificate providers / certificate authorities.

本文章只是对于Azure Key Vault的基本概念的及其之间关系的简介，对于更加详细的信息，比如Key Vault具体是如何监控，节流，身份验证，请求参数之类的详细信息可以去查看文末的官方文档。

参考文章：

https://docs.microsoft.com/en-us/azure/key-vault/

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-manage-groups