Anahtar kasasına erişimin güvenliğini sağlamaSecure access to a key vault

Azure Key Vault, şifreleme anahtarlarını ve sertifikalar, bağlantı dizeleri ve parolalar gibi gizli dizileri koruyan bir bulut hizmetidir.Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. Bu veriler hassas ve iş açısından kritik olduğundan, yalnızca yetkili uygulamalara ve kullanıcılara izin vererek anahtar kasalarınıza güvenli bir şekilde erişmeniz gerekir.Because this data is sensitive and business critical, you need to secure access to your key vaults by allowing only authorized applications and users. Bu makalede Key Vault erişim modeline genel bir bakış sunulmaktadır.This article provides an overview of the Key Vault access model. Kimlik doğrulama ve yetkilendirmeyi açıklar ve anahtar kasalarınıza erişimin güvenliğini nasıl sağlayabileceğinizi açıklar.It explains authentication and authorization, and describes how to secure access to your key vaults.

Key Vault hakkında daha fazla bilgi için bkz. Azure Key Vault hakkında; anahtar kasasında nelerin depolanabileceği hakkında daha fazla bilgi için bkz. anahtarlar, gizlilikler ve sertifikalar hakkında.For more information on Key Vault, see About Azure Key Vault; for more information on what can be stored in a key vault, see About keys, secrets, and certificates.

Erişim modeline genel bakışAccess model overview

Bir anahtar kasasına erişim, iki arabirim aracılığıyla denetlenir: Yönetim düzlemi ve veri düzlemi.Access to a key vault is controlled through two interfaces: the management plane and the data plane. Yönetim düzlemi Key Vault kendisini yönettiğiniz yerdir.The management plane is where you manage Key Vault itself. Bu düzlemdeki işlemler, anahtar kasalarını oluşturmayı ve silmeyi, Key Vault özelliklerini almayı ve erişim ilkelerini güncelleştirmeyi içerir.Operations in this plane include creating and deleting key vaults, retrieving Key Vault properties, and updating access policies. Veri düzlemi, bir anahtar kasasında depolanan verilerle çalıştığınız yerdir.The data plane is where you work with the data stored in a key vault. Anahtarlar, gizli diziler ve sertifikalar ekleyebilir, silebilir ve değiştirebilirsiniz.You can add, delete, and modify keys, secrets, and certificates.

Her iki düzlem de kimlik doğrulaması için Azure Active Directory (Azure AD) kullanır.Both planes use Azure Active Directory (Azure AD) for authentication. Yönetim düzlemi, yetkilendirme için Azure rol tabanlı erişim denetimi (Azure RBAC) kullanır ve veri düzlemi, Key Vault veri düzlemi işlemleri için Key Vault erişim ilkesi ve Azure RBAC kullanır.For authorization, the management plane uses Azure role-based access control (Azure RBAC) and the data plane uses a Key Vault access policy and Azure RBAC for Key Vault data plane operations.

Her iki düzlemde bir anahtar kasasına erişmek için, tüm çağıranların (kullanıcılar veya uygulamalar) uygun kimlik doğrulaması ve yetkilendirmesi olması gerekir.To access a key vault in either plane, all callers (users or applications) must have proper authentication and authorization. Kimlik doğrulama, arayanın kimliğini belirler.Authentication establishes the identity of the caller. Yetkilendirme, çağıranın hangi işlemleri yürütebileceğini belirler.Authorization determines which operations the caller can execute. Key Vault kimlik doğrulaması, herhangi bir güvenlik sorumlusunun kimliğini kimlik doğrulamasından getirmekten sorumlu olan Azure ACTIVE DIRECTORY (Azure AD)ile birlikte çalışıyor.Authentication with Key Vault works in conjunction with Azure Active Directory (Azure AD), which is responsible for authenticating the identity of any given security principal.

Güvenlik sorumlusu, Azure kaynaklarına erişim isteyen bir Kullanıcı, Grup, hizmet veya uygulamayı temsil eden bir nesnedir.A security principal is an object that represents a user, group, service, or application that's requesting access to Azure resources. Azure her güvenlik sorumlusuna benzersiz bir nesne kimliği atar.Azure assigns a unique object ID to every security principal.

  • Bir Kullanıcı güvenlik sorumlusu, Azure Active Directory bir profili olan bir bireyi tanımlar.A user security principal identifies an individual who has a profile in Azure Active Directory.

  • Bir Grup güvenlik sorumlusu Azure Active Directory içinde oluşturulan bir kullanıcı kümesini tanımlar.A group security principal identifies a set of users created in Azure Active Directory. Gruba atanan tüm roller veya izinler, Grup içindeki tüm kullanıcılara verilir.Any roles or permissions assigned to the group are granted to all of the users within the group.

  • Hizmet sorumlusu , bir kullanıcı veya Grup yerine bir kod parçası olan bir uygulamayı veya hizmeti tanımlayan bir güvenlik sorumlusu türüdür.A service principal is a type of security principal that identifies an application or service, which is to say, a piece of code rather than a user or group. Hizmet sorumlusunun nesne KIMLIĞI, ISTEMCI kimliği olarak bilinir ve Kullanıcı adı gibi davranır.A service principal's object ID is known as its client ID and acts like its username. Hizmet sorumlusunun istemci gizli dizisi veya sertifikası , parolası gibi davranır.The service principal's client secret or certificate acts like its password. Birçok Azure hizmeti, yönetilen kimliğin istemci kimliği ve sertifika otomatik yönetimiyle atanmasını destekler.Many Azure Services supports assigning Managed Identity with automated management of client ID and certificate. Yönetilen kimlik, Azure 'da kimlik doğrulaması için en güvenli ve önerilen seçenektir.Managed identity is the most secure and recommended option for authenticating within Azure.

Key Vault kimlik doğrulaması hakkında daha fazla bilgi için bkz. Azure Key Vault kimlik doğrulamaFor more information about authentication to Key Vault, see Authenticate to Azure Key Vault

Key Vault kimlik doğrulama seçenekleriKey Vault authentication options

Bir Azure aboneliğinde bir Anahtar Kasası oluşturduğunuzda, bu, aboneliğin Azure AD kiracısı ile otomatik olarak ilişkilendirilir.When you create a key vault in an Azure subscription, it's automatically associated with the Azure AD tenant of the subscription. Her iki düzlemdeki tüm çağıranlar bu kiracıya kaydolmalıdır ve anahtar kasasına erişmek için kimliğini doğrular.All callers in both planes must register in this tenant and authenticate to access the key vault. Her iki durumda da, uygulamalar üç şekilde Key Vault erişebilir:In both cases, applications can access Key Vault in three ways:

  • Yalnızca uygulama: uygulama bir hizmet sorumlusunu veya yönetilen kimliği temsil eder.Application-only: The application represents a service principal or managed identity. Bu kimlik, anahtar kasasından düzenli olarak sertifikalara, anahtarlara veya gizli uygulamalara erişmesi gereken uygulamalar için en yaygın senaryolardır.This identity is the most common scenario for applications that periodically need to access certificates, keys, or secrets from the key vault. Bu senaryonun çalışması için, objectId uygulamanın erişim ilkesinde belirtilmesi gerekir ve applicationId belirtilmemelidir veya olması gerekir null .For this scenario to work, the objectId of the application must be specified in the access policy and the applicationId must not be specified or must be null.
  • Yalnızca Kullanıcı: Kullanıcı, kiracıda kayıtlı herhangi bir uygulamadan anahtar kasasına erişir.User-only: The user accesses the key vault from any application registered in the tenant. Bu tür erişimin örnekleri Azure PowerShell ve Azure portal içerir.Examples of this type of access include Azure PowerShell and the Azure portal. Bu senaryonun çalışması için, objectId kullanıcının erişim ilkesinde belirtilmesi ve applicationId belirtilmemelidir veya olması gerekir null .For this scenario to work, the objectId of the user must be specified in the access policy and the applicationId must not be specified or must be null.
  • Uygulama-Plus-Kullanıcı (bazen bileşik kimlik olarak adlandırılır): kullanıcının belirli bir uygulamadan anahtar kasasına erişmesi ve uygulamanın, kullanıcının kimliğine bürünmek için, Kullanıcı adına kimlik doğrulaması (OBO) akışı kullanması gerekir.Application-plus-user (sometimes referred as compound identity): The user is required to access the key vault from a specific application and the application must use the on-behalf-of authentication (OBO) flow to impersonate the user. Bu senaryonun çalışması için, her ikisi applicationId de objectId erişim ilkesinde belirtilmelidir.For this scenario to work, both applicationId and objectId must be specified in the access policy. , applicationId Gerekli uygulamayı tanımlar ve objectId kullanıcıyı tanımlar.The applicationId identifies the required application and the objectId identifies the user. Şu anda bu seçenek Azure RBAC veri düzlemi için kullanılamaz.Currently, this option isn't available for data plane Azure RBAC.

Tüm erişim türlerinde, uygulama Azure AD ile kimlik doğrulaması yapar.In all types of access, the application authenticates with Azure AD. Uygulama, uygulama türüne göre desteklenen herhangi bir kimlik doğrulama yöntemini kullanır.The application uses any supported authentication method based on the application type. Uygulama, erişim izni vermek için düzlemdeki bir kaynak için bir belirteç alır.The application acquires a token for a resource in the plane to grant access. Kaynak, Azure ortamına göre yönetim veya veri düzleminde bir uç noktadır.The resource is an endpoint in the management or data plane, based on the Azure environment. Uygulama belirteci kullanır ve Key Vault bir REST API isteği gönderir.The application uses the token and sends a REST API request to Key Vault. Daha fazla bilgi edinmek için tüm kimlik doğrulama akışınıgözden geçirin.To learn more, review the whole authentication flow.

Her iki düzlemde kimlik doğrulama için tek bir mekanizmanın çeşitli avantajları vardır:The model of a single mechanism for authentication to both planes has several benefits:

  • Kuruluşlar, kuruluştaki tüm anahtar kasaları için merkezi olarak erişimi denetleyebilir.Organizations can control access centrally to all key vaults in their organization.
  • Bir Kullanıcı ayrılsa bile, kuruluştaki tüm anahtar kasalarına erişimi anında kaybeder.If a user leaves, they instantly lose access to all key vaults in the organization.
  • Kuruluşlar, ek güvenlik için Multi-Factor Authentication 'ı etkinleştirmek gibi Azure AD 'deki seçenekleri kullanarak kimlik doğrulamasını özelleştirebilir.Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security.

Kaynak uç noktalarıResource endpoints

Uygulamalar, uç noktalar aracılığıyla düzlemleri erişir.Applications access the planes through endpoints. İki düzlemi için erişim denetimleri bağımsız olarak çalışır.The access controls for the two planes work independently. Bir uygulamaya anahtar kasasındaki anahtarları kullanma izni vermek için, Key Vault erişim ilkesi veya Azure RBAC kullanarak veri düzlemi erişimi verirsiniz.To grant an application access to use keys in a key vault, you grant data plane access by using a Key Vault access policy or Azure RBAC. Kullanıcıya Key Vault özelliklerine ve etiketlere yönelik okuma erişimi vermek, ancak verilere (anahtarlar, gizlilikler veya sertifikalar) erişmek için Azure RBAC ile yönetim düzlemi erişimi verirsiniz.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 Azure RBAC.

Aşağıdaki tabloda yönetim ve veri düzlemleri için uç noktalar gösterilmektedir.The following table shows the endpoints for the management and data planes.

Erişim   düzlemiAccess plane Erişim uç noktalarıAccess endpoints OperationsOperations Erişim   denetimi mekanizmasıAccess control mechanism
Yönetim düzlemiManagement plane GenelGlobal:
management.azure.com:443management.azure.com:443

Azure Çin 21Vianet:Azure China 21Vianet:
management.chinacloudapi.cn:443management.chinacloudapi.cn:443

Azure ABD kamu:Azure US Government:
management.usgovcloudapi.net:443management.usgovcloudapi.net:443

Azure Almanya:Azure Germany:
management.microsoftazure.de:443management.microsoftazure.de:443
Anahtar kasaları oluşturun, okuyun, güncelleştirin ve silinCreate, read, update, and delete key vaults

Key Vault erişim ilkelerini ayarlamaSet Key Vault access policies

Key Vault etiketlerini ayarlaSet Key Vault tags
Azure RBACAzure RBAC
Veri düzlemiData plane GenelGlobal:
<vault-name>.vault.azure.net:443<vault-name>.vault.azure.net:443

Azure Çin 21Vianet:Azure China 21Vianet:
<vault-name>.vault.azure.cn:443<vault-name>.vault.azure.cn:443

Azure ABD kamu:Azure US Government:
<vault-name>.vault.usgovcloudapi.net:443<vault-name>.vault.usgovcloudapi.net:443

Azure Almanya:Azure Germany:
<vault-name>.vault.microsoftazure.de:443<vault-name>.vault.microsoftazure.de:443
Anahtarlar: şifreleme, şifre çözme, wrapKey, unwrapKey, imzala, doğrula, alma, listeleme, oluşturma, güncelleştirme, içeri aktarma, silme, kurtarma, yedekleme, geri yükleme, TemizlemeKeys: encrypt, decrypt, wrapKey, unwrapKey, sign, verify, get, list, create, update, import, delete, recover, backup, restore, purge

Sertifikalar: managecontacts, getısers, listissuers, setısers, silme, yönetim verenler, alma, listeleme, oluşturma, içeri aktarma, güncelleştirme, silme, kurtarma, yedekleme, geri yükleme, TemizlemeCertificates: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, recover, backup, restore, purge

Gizlilikler: Al, Listele, ayarla, Sil, kurtar, Yedekle, geri yükle, temizleSecrets: get, list, set, delete,recover, backup, restore, purge
Key Vault erişim ilkesi veya Azure RBACKey Vault access policy or Azure RBAC

Yönetim düzlemi ve Azure RBACManagement plane and Azure RBAC

Yönetim düzleminde, bir çağıranın yürütebileceği işlemleri yetkilendirmek için Azure rol tabanlı erişim denetimi (Azure RBAC) kullanırsınız.In the management plane, you use Azure role-based access control (Azure RBAC) to authorize the operations a caller can execute. Azure RBAC modelinde, her Azure aboneliğinin bir Azure AD örneği vardır.In the Azure RBAC model, each Azure subscription has an instance of Azure AD. Bu dizinden kullanıcılara, gruplara ve uygulamalara erişim izni verirsiniz.You grant access to users, groups, and applications from this directory. Azure aboneliğindeki Azure Resource Manager dağıtım modelini kullanan kaynakları yönetmek için erişim izni verilir.Access is granted to manage resources in the Azure subscription that use the Azure Resource Manager deployment model.

Bir kaynak grubunda bir Anahtar Kasası oluşturup Azure AD 'yi kullanarak erişimi yönetebilirsiniz.You create a key vault in a resource group and manage access by using Azure AD. Kullanıcılara veya gruplara bir kaynak grubundaki anahtar kasalarını yönetme yeteneği vermiş olursunuz.You grant users or groups the ability to manage the key vaults in a resource group. Uygun Azure rolleri atayarak erişimi belirli bir kapsam düzeyinde verirsiniz.You grant the access at a specific scope level by assigning appropriate Azure roles. Anahtar kasalarını yönetmek üzere bir kullanıcıya erişim izni vermek için, belirli bir kapsamdaki kullanıcıya önceden tanımlı bir Key Vault katılımcısı rolü atarsınız.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. Aşağıdaki kapsamlar düzeyleri bir Azure rolüne atanabilir:The following scopes levels can be assigned to an Azure role:

  • Abonelik: abonelik düzeyinde atanan bir Azure rolü, bu aboneliğin içindeki tüm kaynak grupları ve kaynaklar için geçerlidir.Subscription: An Azure role assigned at the subscription level applies to all resource groups and resources within that subscription.
  • Kaynak grubu: kaynak grubu düzeyinde atanan bir Azure rolü, bu kaynak grubundaki tüm kaynaklar için geçerlidir.Resource group: An Azure role assigned at the resource group level applies to all resources in that resource group.
  • Belirli kaynak: belirli bir kaynak için atanan bir Azure rolü bu kaynak için geçerlidir.Specific resource: An Azure role assigned for a specific resource applies to that resource. Bu durumda, kaynak belirli bir Anahtar Kasası olur.In this case, the resource is a specific key vault.

Önceden tanımlanmış birkaç rol vardır.There are several predefined roles. Önceden tanımlanmış bir rol gereksinimlerinize uygun değilse, kendi rolünüzü tanımlayabilirsiniz.If a predefined role doesn't fit your needs, you can define your own role. Daha fazla bilgi için bkz. Azure yerleşik rolleri.For more information, see Azure built-in roles.

Microsoft.Authorization/roleAssignments/write Microsoft.Authorization/roleAssignments/delete Kullanıcı erişimi Yöneticisi veya sahibi gibi izinlerinizin ve izninizin olması gerekirYou need to have Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleAssignments/delete permissions, such as User Access Administrator or Owner

Önemli

Bir kullanıcının bir Contributor Anahtar Kasası yönetim düzlemine izinleri varsa, kullanıcı Key Vault erişim ilkesi ayarlayarak kendilerine veri düzlemine erişim izni verebilir.If a user has Contributor permissions to a key vault management plane, the user can grant themselves access to the data plane by setting a Key Vault access policy. ContributorAnahtar kasalarınıza kimin rol erişimi olduğunu sıkı bir şekilde denetleyebilirsiniz.You should tightly control who has Contributor role access to your key vaults. Anahtar kasalarınızı, anahtarlarınızı, sırları ve sertifikalarınızı yalnızca yetkili kişilerin erişebildiğinden ve yönetebilmesi için emin olun.Ensure that only authorized persons can access and manage your key vaults, keys, secrets, and certificates.

Veri düzlemi ve erişim ilkeleriData plane and access policies

Bir Anahtar Kasası için Key Vault erişim ilkeleri ayarlayarak veri düzlemi erişimi verebilirsiniz.You can grant data plane access by setting Key Vault access policies for a key vault. Bu erişim ilkelerini ayarlamak için, bir Kullanıcı, Grup veya uygulamanın Key Vault Contributor Bu anahtar kasası için yönetim düzlemi için izinleri olması gerekir.To set these access policies, a user, group, or application must have Key Vault Contributor permissions for the management plane for that key vault.

Bir anahtar kasasındaki anahtarlar veya gizlilikler için belirli işlemleri yürütmek üzere bir Kullanıcı, Grup veya uygulama erişimi verirsiniz.You grant a user, group, or application access to execute specific operations for keys or secrets in a key vault. Key Vault, bir Anahtar Kasası için en fazla 1.024 erişim ilkesi girişini destekler.Key Vault supports up to 1,024 access policy entries for a key vault. Birkaç kullanıcıya veri düzlemi erişimi sağlamak için bir Azure AD güvenlik grubu oluşturun ve bu gruba kullanıcı ekleyin.To grant data plane access to several users, create an Azure AD security group and add users to that group.

Kasa ve gizli dizi işlemlerinin tam listesini şurada görebilirsiniz: Key Vault Işlem başvurusuYou can see the full list of vault and secret operations here: Key Vault Operation Reference

Key Vault erişim ilkeleri, izinleri anahtarlar, gizlilikler ve sertifikalara ayrı olarak verir.Key Vault access policies grant permissions separately to keys, secrets, and certificates. Anahtarlar, gizli diziler ve sertifikalar için erişim izinleri kasa düzeyindedir.Access permissions for keys, secrets, and certificates are at the vault level.

Anahtar Kasası erişim ilkeleri kullanma hakkında daha fazla bilgi için bkz. Key Vault erişim Ilkesi atamaFor more information about using key vault access policies, see Assign a Key Vault access policy

Önemli

Key Vault erişim ilkeleri kasa düzeyinde geçerlidir.Key Vault access policies apply at the vault level. Bir kullanıcıya anahtar oluşturma ve silme izni verildiğinde, bu işlemleri ilgili anahtar kasasındaki tüm anahtarlar üzerinde gerçekleştirebilirler.When a user is granted permission to create and delete keys, they can perform those operations on all keys in that key vault. Key Vault erişim ilkeleri, belirli bir anahtar, gizli dizi ya da sertifika gibi ayrıntılı, nesne düzeyindeki izinleri desteklemez.Key Vault access policies don't support granular, object-level permissions like a specific key, secret, or certificate.

Veri düzlemi ve Azure RBACData plane and Azure RBAC

Azure rol tabanlı erişim denetimi, tek tek anahtar kasaları üzerinde etkinleştirilebilen Azure Key Vault veri düzlemine erişimi denetlemek için alternatif bir izin modelidir.Azure role-based access control is an alternative permission model to control access to Azure Key Vault data plane, which can be enabled on individual key vaults. Azure RBAC izin modeli dışlamalı ve ayarlanmış bir kez kasa erişim ilkeleri devre dışı duruma gelmiştir.Azure RBAC permission model is exclusive and once is set, vault access policies became inactive. Azure Key Vault anahtarlar, gizlilikler veya sertifikalara erişmek için kullanılan ortak izin kümelerini çevreleyen bir dizi Azure yerleşik rol tanımlar.Azure Key Vault defines a set of Azure built-in roles that encompass common sets of permissions used to access keys, secrets, or certificates.

Azure AD güvenlik sorumlusuna bir Azure rolü atandığında Azure, bu güvenlik sorumlusu için bu kaynaklara erişim izni verir.When an Azure role is assigned to an Azure AD security principal, Azure grants access to those resources for that security principal. Erişim, aboneliğin düzeyi, kaynak grubu, Anahtar Kasası veya tek bir anahtar, gizli dizi ya da sertifika kapsamına eklenebilir.Access can be scoped to the level of the subscription, the resource group, the key vault, or an individual key, secret, or certificate. Azure AD güvenlik sorumlusu, bir Kullanıcı, Grup, uygulama hizmeti sorumlusu veya Azure kaynakları için yönetilen bir kimlikolabilir.An Azure AD security principal may be a user, a group, an application service principal, or a managed identity for Azure resources.

Kasa erişim ilkeleri üzerinde Azure RBAC iznini kullanmanın önemli avantajları, merkezi erişim denetimi yönetimi ve Privileged Identity Management (PIM)ile Tümleştirmesidir.Key benefits of using Azure RBAC permission over vault access policies are centralized access control management and its integration with Privileged Identity Management (PIM). Privileged Identity Management, önem verdiğiniz kaynaklarda aşırı, gereksiz veya kötüye erişim izinlerinin riskini azaltmak için zamana dayalı ve onay tabanlı rol etkinleştirmesi sağlar.Privileged Identity Management provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about.

Azure RBAC ile Key Vault veri düzlemi hakkında daha fazla bilgi için bkz. Azure rol tabanlı erişim denetimi ile Key Vault anahtarlar, sertifikalar ve gizli dizilerFor more information about Key Vault data plane with Azure RBAC, see Key Vault keys, certificates, and secrets with an Azure role-based access control

Güvenlik duvarları ve sanal ağlarFirewalls and virtual networks

Ek bir güvenlik katmanı için güvenlik duvarlarını ve sanal ağ kurallarını yapılandırabilirsiniz.For an additional layer of security, you can configure firewalls and virtual network rules. Key Vault güvenlik duvarlarını ve sanal ağları, varsayılan olarak tüm ağlardan gelen trafiğe (internet trafiği dahil) erişimi reddedecek şekilde yapılandırabilirsiniz.You can configure Key Vault firewalls and virtual networks to deny access to traffic from all networks (including internet traffic) by default. Belirli Azure sanal ağlarından ve genel İnternet IP adresi aralıklarından trafiğe erişim izni vererek uygulamalarınız için güvenli bir ağ sınırı oluşturabilirsiniz.You can grant access to traffic from specific Azure virtual networks and public internet IP address ranges, allowing you to build a secure network boundary for your applications.

Hizmet uç noktalarını nasıl kullanabileceğinizi gösteren bazı örnekler şunlardır:Here are some examples of how you might use service endpoints:

  • Şifreleme anahtarlarını, uygulama gizli dizilerini ve sertifikaları depolamak için Key Vault kullanıyorsunuz ve genel İnternet 'ten anahtar kasanıza erişimi engellemek istiyorsunuz.You are using Key Vault to store encryption keys, application secrets, and certificates, and you want to block access to your key vault from the public internet.
  • Anahtar kasanıza yalnızca uygulamanızın veya kısa bir ana bilgisayar listesinin bir listesini, anahtar kasanıza bağlanabilmesi için, anahtar kasanıza erişimi kilitlemek istiyorsunuz.You want to lock down access to your key vault so that only your application, or a short list of designated hosts, can connect to your key vault.
  • Azure sanal ağınızda çalışan bir uygulamanız var ve tüm gelen ve giden trafik için bu sanal ağ kilitli.You have an application running in your Azure virtual network, and this virtual network is locked down for all inbound and outbound traffic. Uygulamanızın parolaları veya sertifikaları getirmek veya şifreleme anahtarlarını kullanmak için Key Vault bağlanması gerekir.Your application still needs to connect to Key Vault to fetch secrets or certificates, or use cryptographic keys.

Key Vault güvenlik duvarı ve sanal ağlar hakkında daha fazla bilgi için bkz. Azure Key Vault güvenlik duvarlarını ve sanal ağları yapılandırmaFor more information about Key Vault firewall and virtual networks, see Configure Azure Key Vault firewalls and virtual networks

Not

Key Vault güvenlik duvarları ve sanal ağ kuralları yalnızca Key Vault veri düzlemine uygulanır.Key Vault firewalls and virtual network rules only apply to the data plane of Key Vault. Key Vault denetim düzlemi işlemleri (oluşturma, silme ve değiştirme işlemleri, erişim ilkelerini ayarlama, güvenlik duvarlarını ayarlama ve sanal ağ kuralları), güvenlik duvarları ve sanal ağ kurallarından etkilenmez.Key Vault control plane operations (such as create, delete, and modify operations, setting access policies, setting firewalls, and virtual network rules) are not affected by firewalls and virtual network rules.

Özel uç nokta bağlantısıPrivate endpoint connection

Genel olarak Key Vault açığa çıkmasına tamamen engel olmak için bir Azure özel uç noktası kullanılabilir.In case of a need to completely block Key Vault exposure to the public, an Azure Private Endpoint can be used. Azure özel uç noktası, Azure özel bağlantısı tarafından desteklenen bir hizmete özel ve güvenli bir şekilde bağlanan bir ağ arabirimidir.An Azure Private Endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. Özel uç nokta, sanal ağınızdan bir özel IP adresi kullanarak hizmeti sanal ağınıza etkin bir şekilde getiriyor.The private endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet. Hizmete giden tüm trafik özel uç nokta aracılığıyla yönlendirilebilir, bu nedenle ağ geçitleri, NAT cihazları, ExpressRoute veya VPN bağlantıları ya da genel IP adresleri gerekmez.All traffic to the service can be routed through the private endpoint, so no gateways, NAT devices, ExpressRoute or VPN connections, or public IP addresses are needed. Sanal ağınız ve hizmet arasındaki trafik, Microsoft omurga ağı üzerinden geçer ve genel İnternet’ten etkilenme olasılığı ortadan kaldırılır.Traffic between your virtual network and the service traverses over the Microsoft backbone network, eliminating exposure from the public Internet. Bir Azure kaynağı örneğine bağlanarak, erişim denetimi için en yüksek düzeyde ayrıntı düzeyi sağlayabilirsiniz.You can connect to an instance of an Azure resource, giving you the highest level of granularity in access control.

Azure hizmetleri için özel bağlantı kullanımı için genel senaryolar:Common scenarios for using Private Link for Azure services:

  • Azure platformunda özel olarak erişim Hizmetleri: Sanal ağınızı, kaynak veya hedef üzerinde genel bir IP adresi olmadan Azure 'daki hizmetlere bağlayın.Privately access services on the Azure platform: Connect your virtual network to services in Azure without a public IP address at the source or destination. Hizmet sağlayıcıları kendi sanal ağındaki hizmetlerini işleyebilir ve tüketiciler kendi yerel sanal ağında bu hizmetlere erişebilir.Service providers can render their services in their own virtual network and consumers can access those services in their local virtual network. Özel bağlantı platformu, Azure omurga ağı üzerinden tüketici ve hizmetler arasındaki bağlantıyı işleymeyecektir.The Private Link platform will handle the connectivity between the consumer and services over the Azure backbone network.

  • Şirket içi ve eşlenmiş ağlar: Azure 'Da, ExpressRoute özel EŞLEMESI, VPN tünelleri ve eşlenmiş sanal ağlar üzerinden şirket içinden çalışan hizmetlere özel uç noktalar kullanarak erişin.On-premises and peered networks: Access services running in Azure from on-premises over ExpressRoute private peering, VPN tunnels, and peered virtual networks using private endpoints. Hizmete ulaşmak için genel eşlemeyi ayarlama veya internet 'e çapraz geçiş yapma gereksinimi yoktur.There's no need to setup public peering or traverse the internet to reach the service. Özel bağlantı, iş yüklerini Azure 'a geçirmek için güvenli bir yol sağlar.Private Link provides a secure way to migrate workloads to Azure.

  • Veri sızıntılarına karşı koruma: özel bir uç nokta, tüm hizmet yerine bir PaaS kaynağı örneğine eşlenir.Protection against data leakage: A private endpoint is mapped to an instance of a PaaS resource instead of the entire service. Tüketiciler yalnızca belirli bir kaynağa bağlanabilir.Consumers can only connect to the specific resource. Hizmette başka bir kaynağa erişim engellenir.Access to any other resource in the service is blocked. Bu mekanizma, veri sızıntısı risklerine karşı koruma sağlar.This mechanism provides protection against data leakage risks.

  • Küresel erişim: diğer bölgelerde çalışan hizmetlere özel olarak bağlanın.Global reach: Connect privately to services running in other regions. Tüketicinin sanal ağı A bölgesinde olabilir ve B bölgesinde özel bağlantı arkasındaki hizmetlere bağlanabilir.The consumer's virtual network could be in region A and it can connect to services behind Private Link in region B.

  • Kendi hizmetlerinizi genişletin: hizmetinizi Azure 'daki tüketicilere özel olarak işlemek için aynı deneyimi ve işlevselliği etkinleştirin.Extend to your own services: Enable the same experience and functionality to render your service privately to consumers in Azure. Hizmetinizi standart bir Azure Load Balancer arkasına yerleştirerek özel bağlantı için etkinleştirebilirsiniz.By placing your service behind a standard Azure Load Balancer, you can enable it for Private Link. Tüketici daha sonra kendi sanal ağında özel bir uç nokta kullanarak doğrudan hizmetinize bağlanabilir.The consumer can then connect directly to your service using a private endpoint in their own virtual network. Bağlantı isteklerini bir onay çağrı akışı kullanarak yönetebilirsiniz.You can manage the connection requests using an approval call flow. Azure özel bağlantısı, farklı Azure Active Directory kiracılarına ait tüketiciler ve hizmetler için geçerlidir.Azure Private Link works for consumers and services belonging to different Azure Active Directory tenants.

Özel uç noktalar hakkında daha fazla bilgi için bkz. Azure özel bağlantısı ile Key VaultFor more information about private endpoints, see Key Vault with Azure Private Link

ÖrnekExample

Bu örnekte, TLS/SSL için bir sertifika, verileri depolamak için Azure depolama ve Azure Storage 'daki verileri şifrelemek için RSA 2.048 bitlik bir anahtar kullanan bir uygulama geliştiriyoruz.In this example, we're developing an application that uses a certificate for TLS/SSL, Azure Storage to store data, and an RSA 2,048-bit key for encrypting data in Azure Storage. Uygulamamız bir Azure sanal makinesinde (VM) (veya bir sanal makine ölçek kümesi) çalışır.Our application runs in an Azure virtual machine (VM) (or a virtual machine scale set). Uygulama gizli dizileri depolamak için bir Anahtar Kasası kullanabiliriz.We can use a key vault to store the application secrets. Azure AD ile kimlik doğrulaması yapmak için uygulama tarafından kullanılan önyükleme sertifikasını depolayabiliriz.We can store the bootstrap certificate that's used by the application to authenticate with Azure AD.

Aşağıdaki depolanmış anahtarlar ve gizli anahtarlara erişmeniz gerekir:We need access to the following stored keys and secrets:

  • TLS/SSL sertifikası: TLS/SSL için kullanılır.TLS/SSL certificate: Used for TLS/SSL.
  • Depolama anahtarı: depolama hesabına erişmek için kullanılır.Storage key: Used to access the Storage account.
  • RSA 2.048 bit anahtarı: Azure depolama tarafından sarmalama/sarmalama verileri şifreleme anahtarı için kullanılır.RSA 2,048-bit key: Used for wrap/unwrap data encryption key by Azure Storage.
  • Uygulama tarafından yönetilen kimlik: Azure AD kimlik doğrulaması için kullanılır.Application Managed Identity: Used to authenticate with Azure AD. Key Vault Erişimi verildikten sonra, uygulama depolama anahtarını ve sertifikayı getirebilir.After access to Key Vault is granted, application can fetch the storage key and certificate.

Uygulamamızı kimin yönetebileceğini, dağıtabileceğinizi ve denetleyeceğinizi belirlemek için aşağıdaki rolleri tanımlamanız gerekir:We need to define the following roles to specify who can manage, deploy, and audit our application:

  • Güvenlik ekibi: CSO (Güvenlik Müdürü) veya benzer katkıda bulunanlar ofisindeki BT personeli.Security team: IT staff from the office of the CSO (Chief Security Officer) or similar contributors. Güvenlik ekibi, gizli dizileri doğru bir şekilde ping işlemi yapmaktan sorumludur.The security team is responsible for the proper safekeeping of secrets. Gizlilikler, TLS/SSL sertifikaları, şifreleme için RSA anahtarları, bağlantı dizeleri ve depolama hesabı anahtarları içerebilir.The secrets can include TLS/SSL certificates, RSA keys for encryption, connection strings, and storage account keys.
  • Geliştiriciler ve işleçler: uygulamayı geliştiren ve Azure 'da dağıtan personel.Developers and operators: The staff who develop the application and deploy it in Azure. Bu ekibin üyeleri güvenlik personelinin bir parçası değildir.The members of this team aren't part of the security staff. Bunlar TLS/SSL sertifikaları ve RSA anahtarları gibi hassas verilere erişemez.They shouldn't have access to sensitive data like TLS/SSL certificates and RSA keys. Yalnızca dağıttıkları uygulamanın gizli verilere erişimi olmalıdır.Only the application that they deploy should have access to sensitive data.
  • Denetçiler: Bu rol, geliştirme veya genel BT personelinin üyesi olmayan katkıda bulunanlar içindir.Auditors: This role is for contributors who aren't members of the development or general IT staff. Güvenlik standartlarıyla uyumluluğu sağlamak için sertifikaların, anahtarların ve parolaların kullanımını ve bakımını gözden geçirir.They review the use and maintenance of certificates, keys, and secrets to ensure compliance with security standards.

Uygulamamızın kapsamı dışında başka bir rol var: abonelik (veya kaynak grubu) Yöneticisi.There's another role that's outside the scope of our application: the subscription (or resource group) administrator. Abonelik Yöneticisi güvenlik ekibi için ilk erişim izinlerini ayarlar.The subscription admin sets up initial access permissions for the security team. Uygulama için gerekli kaynaklara sahip bir kaynak grubunu kullanarak güvenlik ekibine erişim izni verir.They grant access to the security team by using a resource group that has the resources required by the application.

Rollerimiz için aşağıdaki işlemleri yetkilendirmemiz gerekir:We need to authorize the following operations for our roles:

Güvenlik ekibiSecurity team

  • Anahtar kasaları oluşturun.Create key vaults.
  • Key Vault günlüğünü açın.Turn on Key Vault logging.
  • Anahtar ve gizli dizileri ekleyin.Add keys and secrets.
  • Olağanüstü durum kurtarma için anahtarların yedeklerini oluşturun.Create backups of keys for disaster recovery.
  • Belirli işlemler için kullanıcılara ve uygulamalara izin vermek üzere Key Vault erişim ilkeleri ayarlayın ve roller atayın.Set Key Vault access policies and assign roles to grant permissions to users and applications for specific operations.
  • Anahtarları ve gizli dizileri düzenli olarak alın.Roll the keys and secrets periodically.

Geliştiriciler ve operatörlerDevelopers and operators

  • Hem önyükleme hem TLS/SSL sertifikaları (parmak izleri), depolama anahtarı (gizli URI) ve sarmalama/sarmalama için RSA anahtarı (anahtar URI) için Güvenlik ekibinden başvuru alın.Get references from the security team for the bootstrap and TLS/SSL certificates (thumbprints), storage key (secret URI), and RSA key (key URI) for wrap/unwrap.
  • Sertifikaları ve gizli dizileri programlı bir şekilde erişmek için uygulamayı geliştirin ve dağıtın.Develop and deploy the application to access certificates and secrets programmatically.

DenetçilerAuditors

  • Anahtarların ve parolaların doğru kullanımını ve veri güvenliği standartlarıyla uyumluluğunu onaylamak için Key Vault günlüklerini gözden geçirin.Review the Key Vault logs to confirm proper use of keys and secrets, and compliance with data security standards.

Aşağıdaki tabloda rollerimiz ve uygulamamız için erişim izinleri özetlenmektedir.The following table summarizes the access permissions for our roles and application.

RolRole Yönetim düzlemi izinleriManagement plane permissions Veri düzlemi izinleri-kasa erişim ilkeleriData plane permissions - vault access policies Veri düzlemi izinleri-Azure RBACData plane permissions -Azure RBAC
Güvenlik ekibiSecurity team Katkıda bulunan Key VaultKey Vault Contributor Sertifikalar: tüm işlemlerCertificates: all operations
Anahtarlar: tüm işlemlerKeys: all operations
Gizlilikler: tüm işlemlerSecrets: all operations
Key Vault YöneticisiKey Vault Administrator
Geliştiriciler ve   işleçlerDevelopers and operators Key Vault dağıtma izniKey Vault deploy permission

Note: Bu izin, dağıtılan VM 'lerin bir anahtar kasasından gizli dizileri almasına izin verir.Note: This permission allows deployed VMs to fetch secrets from a key vault.
YokNone YokNone
DenetçilerAuditors YokNone Sertifikalar: listeCertificates: list
Anahtarlar: listelemeKeys: list
Parolalar: listelemeSecrets: list

Not: Bu izin, denetçilerin, günlüklere yayılmayan anahtarlar ve gizli diziler için öznitelikleri (Etiketler, etkinleştirme tarihleri, sona erme tarihleri) incelemeye olanak sağlar.Note: This permission enables auditors to inspect attributes (tags, activation dates, expiration dates) for keys and secrets not emitted in the logs.
Key Vault okuyucuKey Vault Reader
Azure Depolama HesabıAzure Storage Account YokNone Anahtarlar: get, List, wrapKey, unwrapKeyKeys: get, list, wrapKey, unwrapKey
Key Vault şifreleme hizmeti şifreleme kullanıcısıKey Vault Crypto Service Encryption User
UygulamaApplication YokNone Gizlilikler: get, ListSecrets: get, list
Sertifikalar: get, ListCertificates: get, list
Key Vault okuyucu, Key Vault gizli KullanıcıKey Vault Reader, Key Vault Secret User

Üç takım rolünün, Key Vault izinlerle birlikte diğer kaynaklara erişmesi gerekir.The three team roles need access to other resources along with Key Vault permissions. VM 'Leri (veya Azure App Service Web Apps özelliğini) dağıtmak için, geliştiricilere ve operatörlere erişim dağıtımı gerekir.To deploy VMs (or the Web Apps feature of Azure App Service), developers and operators need deploy access. Denetçilerin Key Vault günlüklerinin depolandığı depolama hesabına okuma erişimi olması gerekir.Auditors need read access to the Storage account where the Key Vault logs are stored.

Örneğimizde basit bir senaryo açıklanmaktadır.Our example describes a simple scenario. Gerçek yaşam senaryoları daha karmaşık olabilir.Real-life scenarios can be more complex. Gereksinimlerinize göre anahtar kasanıza yönelik izinleri ayarlayabilirsiniz.You can adjust permissions to your key vault based on your needs. Güvenlik ekibinin, uygulamalarında DevOps personeli tarafından kullanılan anahtar ve gizli başvuruları (URI 'Ler ve parmak izleri) sağladığını kabul ediyoruz.We assumed the security team provides the key and secret references (URIs and thumbprints), which are used by the DevOps staff in their applications. Geliştiricilere ve işleçlere herhangi bir veri düzlemi erişimi gerekmez.Developers and operators don't require any data plane access. Anahtar kasanızın güvenliğini sağlama konusunda odaklandık.We focused on how to secure your key vault.

Not

Bu örnek, Key Vault erişimin üretimde nasıl kilitli olduğunu gösterir.This example shows how Key Vault access is locked down in production. Geliştiricilerin, kasalarını, VM 'Leri ve uygulamayı geliştirdikleri depolama hesabını yönetmek için tam izinlerle kendi aboneliğine veya kaynak grubuna sahip olmaları gerekir.Developers should have their own subscription or resource group with full permissions to manage their vaults, VMs, and the storage account where they develop the application.

KaynaklarResources

Sonraki adımlarNext steps

Azure Key Vault'ta kimliği doğrulamaAuthenticate to Azure Key Vault

Key Vault erişim ilkesi atamaAssign a Key Vault access policy

Anahtarlar, gizlilikler ve sertifikalara erişim için Azure rolü atamaAssign Azure role to access to keys, secrets, and certificates

Key Vault güvenlik duvarlarını ve sanal ağları yapılandırmaConfigure Key Vault firewalls and virtual networks

Key Vault özel bağlantı bağlantısı oluşturmaEstablish a private link connection to Key Vault