Azure Key Vault temel kavramları

Azure Key Vault, gizli dizileri güvenli bir şekilde depolamaya ve bunlara erişmeye yönelik bir bulut hizmetidir. Gizli dizi, API anahtarları, parolalar, sertifikalar veya şifreleme anahtarları gibi erişimi sıkı bir şekilde denetlemek istediğiniz her şeydir. Key Vault hizmeti iki tür kapsayıcıyı destekler: kasalar ve yönetilen donanım güvenlik modülü (HSM) havuzları. Kasalar yazılım ve HSM destekli anahtarların, gizli dizilerin ve sertifikaların depolanmasını destekler. Yönetilen HSM havuzları yalnızca HSM destekli anahtarları destekler. Tüm ayrıntılar için bkz. Azure Key Vault REST API'ye genel bakış.

Diğer önemli terimler şunlardır:

  • Kiracı: Kiracı, Microsoft bulut hizmetlerinin belirli bir örneğine sahip olan ve onu yöneten kuruluştur. Genellikle bir kuruluş için Azure ve Microsoft 365 hizmetleri kümesine başvurmak için kullanılır.

  • Kasa sahibi: Kasa sahibi, anahtar kasası oluşturabilir ve anahtar kasası üzerinde tam erişime ve denetime sahip olabilir. Kasa sahibi, gizli dizilere ve anahtarlara kimlerin eriştiğini günlüğe kaydetmek için belirli denetim özellikleri de ayarlayabilir. Yöneticiler anahtarların yaşam döngüsünü kontrol edebilir. Anahtarı yeni sürüme geçirebilir, yedekleyebilir ve ilgili görevleri gerçekleştirebilirler.

  • Kasa tüketicisi: Kasa tüketicisi, kasa sahibi tarafından tüketici erişimi sağlandığında, anahtar kasasındaki varlıklar üzerinde belirli eylemler gerçekleştirebilir. Kullanılabilen eylemler verilen izinlere bağlıdır.

  • Yönetilen HSM Yöneticileri: Yönetici rolüne atanan kullanıcılar Yönetilen HSM havuzu üzerinde tam denetime sahiptir. Diğer kullanıcılara denetimli erişim yetkisi vermek için daha fazla rol ataması oluşturabilirler.

  • Yönetilen HSM Şifreleme Yetkilisi/Kullanıcı: Yönetilen HSM'deki anahtarları kullanarak şifreleme işlemleri gerçekleştirecek kullanıcılara veya hizmet sorumlularına genellikle atanan yerleşik roller. Şifreleme Kullanıcısı yeni anahtarlar oluşturabilir ancak anahtarları silemez.

  • Yönetilen HSM Şifreleme Hizmeti Şifreleme Kullanıcısı: Müşteri tarafından yönetilen anahtarla bekleyen verilerin şifrelenmesi için genellikle hizmet hesapları tarafından yönetilen hizmet kimliğine (örneğin Depolama hesabı) atanan yerleşik rol.

  • Kaynak: Azure aracılığıyla kullanılan, yönetilebilir bir öğedir. Yaygın örnekler sanal makine, depolama hesabı, web uygulaması, veritabanı ve sanal ağdır. Çok daha fazlası var.

  • Kaynak grubu: Kaynak grubu, Azure çözümleri için ilgili kaynakları bir arada tutan kapsayıcılardır. Kaynak grubu bir çözümün tüm kaynaklarını veya yalnızca grup olarak yönetmek istediğiniz kaynakları içerebilir. Kuruluş için önemli olan faktörleri temel alarak kaynakları kaynak gruplarına nasıl ayıracağınıza siz karar verirsiniz.

  • Güvenlik sorumlusu: Azure güvenlik sorumlusu, kullanıcı tarafından oluşturulan uygulamaların, hizmetlerin ve otomasyon araçlarının belirli Azure kaynaklarına erişmek için kullandığı bir güvenlik kimliğidir. Bunu belirli bir role ve sıkı denetimli izinlere sahip bir "kullanıcı kimliği" (kullanıcı adı ve parola veya sertifika) olarak düşünün. Bir güvenlik sorumlusu, genel kullanıcı kimliğinin aksine yalnızca belirli şeyler yapmalıdır. Yalnızca yönetim görevlerini gerçekleştirmek için gereken en düşük izin düzeyini verirseniz güvenliği artırır. Bir uygulama veya hizmetle kullanılan güvenlik sorumlusuna hizmet sorumlusu adı verilir.

  • Azure Active Directory (Azure AD): Azure AD, bir kiracıya ilişkin Active Directory hizmetidir. Her dizinde bir veya daha fazla etki alanı vardır. Dizinde birden fazla abonelik bulunabilir ancak tek bir kiracı olur.

  • Azure kiracı kimliği: Kiracı kimliği, bir Azure aboneliğinde Azure AD örneğini tanımlamanın benzersiz bir yoludur.

  • Yönetilen kimlikler: Azure Key Vault kimlik bilgilerini ve diğer anahtarları ve gizli dizileri güvenli bir şekilde depolamak için bir yol sağlar, ancak kodunuzun bunları almak için Key Vault için kimlik doğrulaması yapması gerekir. Yönetilen kimlik kullanmak, Azure hizmetlerine Azure AD'de otomatik olarak yönetilen bir kimlik vererek bu sorunun çözülmesini kolaylaştırır. Bu kimliği kullanarak, Key Vault veya Azure AD kimlik doğrulamasını destekleyen tüm hizmetler için kodunuzda kimlik bilgileri bulunmasına gerek kalmadan kimlik doğrulaması yapabilirsiniz. Daha fazla bilgi için aşağıdaki görüntüye ve Azure kaynakları için yönetilen kimliklere genel bakışa bakın.

Kimlik Doğrulaması

Key Vault ile herhangi bir işlem yapmak için önce kimlik doğrulaması yapmanız gerekir. Key Vault için kimlik doğrulaması yapmanın üç yolu vardır:

  • Azure kaynakları için yönetilen kimlikler: Azure'da bir sanal makineye uygulama dağıttığınızda, sanal makinenize Key Vault erişimi olan bir kimlik atayabilirsiniz. Kimlikleri diğer Azure kaynaklarına da atayabilirsiniz. Bu yaklaşımın avantajı, uygulamanın veya hizmetin ilk gizli dizinin döndürmesini yönetmemedir. Azure, kimliği otomatik olarak döndürür. Bu yaklaşımı en iyi yöntem olarak öneririz.
  • Hizmet sorumlusu ve sertifika: Key Vault erişimi olan bir hizmet sorumlusu ve ilişkili bir sertifika kullanabilirsiniz. Uygulama sahibinin veya geliştiricinin sertifikayı döndürmesi gerektiğinden bu yaklaşımı önermiyoruz.
  • Hizmet sorumlusu ve gizli dizi: Key Vault kimlik doğrulaması yapmak için bir hizmet sorumlusu ve gizli dizi kullanabilirsiniz ancak bunu önermeyiz. Key Vault kimlik doğrulaması için kullanılan bootstrap gizli dizisini otomatik olarak döndürmek zordur.

Aktarımdaki verilerin şifresi

Azure Key Vault, Azure Key Vault ile istemciler arasında seyahat ederken verileri korumak için Aktarım Katmanı Güvenliği (TLS) protokollerini zorunlu kıldı. İstemciler, Azure Key Vault ile TLS bağlantısı anlaşması sağlar. TLS güçlü kimlik doğrulaması, ileti gizliliği ve bütünlüğü (ileti kurcalama, kesme ve sahtecilik algılamayı etkinleştirme), birlikte çalışabilirlik, algoritma esnekliği ve dağıtım ve kullanım kolaylığı sağlar.

Mükemmel İletme Gizliliği (PFS), müşterilerin istemci sistemleriyle Microsoft bulut hizmetleri arasındaki bağlantıları benzersiz anahtarlarla korur. Bağlantılar ayrıca RSA tabanlı 2.048 bit şifreleme anahtarı uzunluklarını da kullanır. Bu birleşim, birinin aktarımda olan verileri kesmesini ve verilere erişmesini zorlaştırır.

Key Vault rolleri

Geliştiricilerin ve güvenlik yöneticilerinin ihtiyaçlarını karşılamaya Anahtar Kasası'nın nasıl yardımcı olabileceğini daha iyi anlamak için aşağıdaki tabloyu kullanın.

Rol Sorun bildirimi Azure Anahtar Kasası tarafından çözüldü
Bir Azure uygulaması geliştiricisi "Azure için imzalama ve şifreleme anahtarlarını kullanan bir uygulama yazmak istiyorum. Ancak çözümün coğrafi olarak dağıtılmış bir uygulamaya uygun olması için bu anahtarların uygulamamın dışında olmasını istiyorum.

Kodu kendim yazmak zorunda kalmadan bu anahtarların ve parolaların korunmasını istiyorum. Ayrıca bu anahtarların ve gizli dizilerin en iyi performansla uygulamalarımdan kolayca kullanılabilmesini istiyorum."
√ Anahtarlar bir kasada depolanır ve gerektiğinde URI tarafından çağrılır.

√ Anahtarlar, endüstri standardında algoritmalar, anahtar uzunlukları ve donanım güvenliği modülleri kullanılarak Azure tarafından korunur.

√ Anahtarlar uygulamalarla aynı Azure veri merkezinde bulunan HSM'lerde işlenir. Bu yöntem, şirket içi gibi ayrı konumlarda bulunan anahtarlardan daha fazla güvenilirlik ve daha az gecikme sağlar.
Hizmet olarak yazılım (SaaS) geliştiricisi "Müşterilerimin kiracı anahtarları ve gizli dizileri için sorumluluk veya olası sorumluluk istemiyorum.

Müşterilerin anahtarlarına sahip olmasını ve bunları yönetmesini istiyorum, böylece en iyi yaptığım şeyi yapmaya odaklanabilirim, bu da temel yazılım özelliklerini sağlar."
√ Müşteriler kendi anahtarları Azure'a aktarabilir ve bunları yönetebilir. Bir SaaS uygulamasının müşterilerin anahtarlarını kullanarak şifreleme işlemleri gerçekleştirmesi gerektiğinde, Key Vault bu işlemleri uygulama adına yapar. Uygulama müşterilerin anahtarlarını görmüyor.
Güvenlik başkanı (CSO) "Uygulamalarımızın güvenli anahtar yönetimi için FIPS 140-2 Düzey 2 veya FIPS 140-2 Düzey 3 HSM'lerle uyumlu olduğunu bilmek istiyorum.

Kuruluşumun anahtar yaşam döngüsü denetimine sahip olduğundan ve anahtar kullanımını izleyebildiğinden emin olmak istiyorum.

Birden çok Azure hizmeti ve kaynağı kullansak da anahtarları Azure'da tek bir konumdan yönetmek istiyorum."
√ FIPS 140-2 Düzey 2 doğrulanmış HSM'ler için kasa seçin.
√ FIPS 140-2 Düzey 3 doğrulanmış HSM'ler için yönetilen HSM havuzlarını seçin.

√ Anahtar Kasası, Microsoft anahtarlarınızı görmeyecek ve ayıklamayacak şekilde tasarlanmıştır.
√ Anahtar kullanımı neredeyse gerçek zamanlı olarak günlüğe kaydedilir.

√ Kasa, Azure'da kaç kasanız olduğuna, bunların hangi bölgeleri desteklediğine ve hangi uygulamaların bunları kullandığına bakmaksızın tek bir arabirim sağlar.

Bir Azure aboneliği olan herhangi biri, anahtar kasalarını oluşturabilir ve kullanabilir. geliştiricilere ve güvenlik yöneticilerine Key Vault fayda sunsa da, diğer Azure hizmetlerini yöneten bir kuruluşun yöneticisi tarafından uygulanabilir ve yönetilebilir. Örneğin, bu yönetici bir Azure aboneliğiyle oturum açabilir, anahtarların depolandığı kuruluş için bir kasa oluşturabilir ve aşağıdaki gibi işlemsel görevlerden sorumlu olabilir:

  • Bir anahtar veya gizli anahtarı oluşturma veya içeri aktarma
  • Bir anahtar veya gizli anahtarı iptal etme veya silme
  • Kullanıcıların veya uygulamaların, anahtar ve gizli anahtarları yönetmeleri veya kullanmaları için anahtar kasasına erişmelerini yetkilendirme
  • Anahtar kullanımını (örneğin, imzalama veya şifreleme) yapılandırma
  • Anahtar kullanımını izleme

Bu yönetici daha sonra geliştiricilere uygulamalarından arama yapma URI'leri verir. Bu yönetici, güvenlik yöneticisine önemli kullanım günlüğü bilgilerini de verir.

Azure Key Vault'nin çalışma şekline genel bakış

Geliştiriciler ayrıca anahtarları doğrudan API'lerini kullanarak yönetebilir. Daha fazla bilgi için bkz. Anahtar Kasası geliştirici kılavuzu.

Sonraki adımlar

Azure Anahtar Kasası çoğu bölgede kullanılabilir. Daha fazla bilgi için bkz. Anahtar Kasası fiyatlandırma sayfası.