Kimlik ve erişim yönetimi için öneriler

  • Makale

Bu Azure Well-Architected Framework Güvenlik denetim listesi önerisi için geçerlidir:

SE:05 Tüm iş yükü kullanıcıları, ekip üyeleri ve sistem bileşenlerinde katı, koşullu ve denetlenebilir kimlik ve erişim yönetimi (IAM) uygulayın. Erişimi yalnızca gerektiği şekilde sınırlayın. Tüm kimlik doğrulama ve yetkilendirme uygulamaları için modern endüstri standartlarını kullanın. Kimliğe dayalı olmayan erişimi kısıtlayın ve sıkı bir şekilde kontrol edin.

Bu kılavuzda, iş yükü kaynaklarınıza erişmeye çalışan kimliklerin kimliğini doğrulama ve yetkilendirmeye yönelik öneriler açıklanmaktadır.

Teknik denetim açısından bakıldığında kimlik her zaman birincil çevredir. Bu kapsam yalnızca iş yükünüzün kenarlarını içermez. Ayrıca iş yükünüzün içindeki tek tek bileşenleri de içerir. Tipik kimlikler şunlardır:

  • İnsanlar. Uygulama kullanıcıları, yöneticiler, operatörler, denetçiler ve kötü aktörler.

  • Sistemler. İş yükü kimlikleri, yönetilen kimlikler, API anahtarları, hizmet sorumluları ve Azure kaynakları.

  • Anonim. Kim oldukları hakkında herhangi bir kanıt sağlamamış varlıklar.

Tanımlar 

Terimler Tanım
Kimlik Doğrulaması (Kimlik Doğrulaması) Kimliğin kim veya ne olduğunu doğrulayan bir işlem.
Yetkilendirme (AuthZ) Bir kimliğin istenen eylemi gerçekleştirme iznine sahip olup olmadığını doğrulayan bir işlem.
Koşullu erişim Belirtilen ölçütlere göre eylemlere izin veren bir kural kümesi.
IdP Microsoft Entra kimliği gibi bir kimlik sağlayıcısı.
Persona Bir iş işlevi veya bir dizi sorumluluk ve eylem içeren bir başlık.
Önceden paylaşılan anahtarlar Bir sağlayıcı ile tüketici arasında paylaşılan ve güvenli ve üzerinde anlaşmaya varılan bir mekanizma aracılığıyla kullanılan bir gizli dizi türü.
Kaynak kimliği Platform tarafından yönetilen bulut kaynakları için tanımlanmış bir kimlik.
Rol Bir kullanıcının veya grubun neler yapabileceğini tanımlayan bir izin kümesi.
Kapsam Bir rolün çalışmasına izin verilen farklı kuruluş hiyerarşisi düzeyleri. Ayrıca bir sistemdeki bir özellik grubu.
Güvenlik sorumlusu İzinler sağlayan bir kimlik. Kullanıcı, grup veya hizmet sorumlusu olabilir. Tüm grup üyeleri aynı erişim düzeyine sahiptir.
Kullanıcı kimliği Çalışan veya dış kullanıcı gibi bir kişinin kimliği.
İş yükü kimliği Bir iş yükünün diğer hizmet ve kaynaklarda kimliğini doğrulamak için kullanılan bir uygulama, hizmet, betik, kapsayıcı veya başka bir bileşeni için sistem kimliği.

Not

Kimlik, güvenlik sorumlusu adı verilen bir üst öğe altında diğer benzer kimliklerle gruplandırılabilir. Güvenlik grubu, güvenlik sorumlusu örneğidir. Bu hiyerarşik ilişki bakımı basitleştirir ve tutarlılığı artırır. Kimlik öznitelikleri tek tek düzeyde işlenmediğinden hata olasılığı da azalır. Bu makalede kimlik terimi güvenlik sorumlularını kapsar.

Kimlik sağlayıcısının rolü

Kimlik sağlayıcısı (IdP), kullanıcıları dijital kimlik olarak depolayan ve yöneten, bulutta barındırılan bir hizmettir.

Kimlik ve erişim yönetimi için güvenilir bir IdP tarafından sağlanan özelliklerden yararlanın. IdP'yi değiştirmek için özel sistemler uygulamayın. IdP sistemleri, her gün birden çok kiracıda milyarlarca sinyal yakalayarak en son saldırı vektörlerine göre sık sık geliştirilir. Microsoft Entra kimliği, Azure bulut platformu için IdP'dir.

Kimlik Doğrulaması

Kimlik doğrulaması, kimlikleri doğrulayan bir işlemdir. İstekte bulunan kimlik, doğrulanabilir bir kimlik biçimi sağlamak için gereklidir. Örnek:

  • Kullanıcı adı ve parola.

  • Erişim veren API anahtarı gibi önceden paylaşılan bir gizli dizi.

  • Paylaşılan erişim imzası (SAS) belirteci.

  • TLS karşılıklı kimlik doğrulamasında kullanılan bir sertifika.

Mümkün olduğunca doğrulama işleminin IdP'niz tarafından işlenmesi gerekir.

Yetkilendirme

Yetkilendirme, doğrulanmış kimlik tarafından istenen eylemlere izin veren veya reddeden bir işlemdir. Eylem çalışıyor veya kaynak yönetimiyle ilgili olabilir.

Yetkilendirme, kimliklere izinler atamanızı gerektirir ve bunu IdP'niz tarafından sağlanan işlevleri kullanarak yapmanız gerekir.

Temel tasarım stratejileri

bir iş yüküne yönelik kimlik gereksinimlerinin bütünsel bir görünümünü elde etmek için akışları, iş yükü varlıklarını ve kişiliklerini ve varlıkların ve kişiliklerin gerçekleştireceği eylemleri kataloglamalısınız. Stratejiniz , iş yüküne veya bileşenlerine (dışarıdan erişim) ulaşan akışları ve iş yükünden diğer kaynaklara (iç erişim) ulaşan akışları işleyen tüm kullanım örneklerini kapsamalıdır.

Her kullanım örneğinin, muhtemelen bir varsayım ihlali zihniyetiyle tasarlamanız gereken kendi denetim kümesi olacaktır. Kullanım örneğinin veya kişiliklerin kimlik gereksinimlerine bağlı olarak koşullu seçimleri belirleyin. Tüm kullanım örnekleri için tek bir çözüm kullanmaktan kaçının. Buna karşılık, denetimler gereksiz yönetim ek yüküne neden olacak kadar ayrıntılı olmamalıdır.

Kimlik erişim izini günlüğe kaydetmeniz gerekir. Bunu yapmak denetimleri doğrulamaya yardımcı olur ve uyumluluk denetimleri için günlükleri kullanabilirsiniz.

Kimlik doğrulaması için tüm kimlikleri belirleme

  • Dışarıdan erişim. Kimlik tasarımınız, çeşitli amaçlarla iş yüküne erişen tüm kullanıcıların kimliğini doğrulamalıdır. Örneğin, API'leri çağırarak uygulamaya erişen bir son kullanıcı.

    Ayrıntılı düzeyde, iş yükünün bileşenlerinin dışarıdan da erişmesi gerekebilir. Örneğin, komutları çalıştırmak için portal üzerinden veya işlem erişimine ihtiyacı olan bir operatör.

    Her ikisi de farklı kişiliklere sahip kullanıcı kimliklerine örnektir.

  • İçeriden dışarı erişim. Uygulamanızın diğer kaynaklara erişmesi gerekir. Örneğin, veri platformundan okuma veya veri platformuna yazma, gizli dizileri gizli dizi deposundan alma ve izleme hizmetlerine telemetriyi günlüğe kaydetme. Hatta üçüncü taraf hizmetlere erişmesi bile gerekebilir. Bu erişim gereksinimleri, uygulamanın diğer kaynaklarda kimliğini doğrulamasını sağlayan iş yükü kimliği gerektirir.

    Kavram bileşen düzeyinde geçerlidir. Aşağıdaki örnekte kapsayıcının yapılandırmasını almak için dağıtım işlem hatlarına erişmesi gerekebilir. Bu erişim gereksinimleri için kaynak kimliği gerekir.

Tüm bu kimlikler IdP'niz tarafından doğrulanmalıdır.

Aşağıda, bir mimaride kimliğin nasıl uygulanabileceğine yönelik bir örnek verilmişti:

Bir mimaride kimliğin nasıl uygulanabileceğini gösteren diyagram.

Yetkilendirme eylemlerini belirleme

Ardından, bu eylemlerin yetkilendirilebilmesi için kimliği doğrulanmış her kimliğin ne yapmaya çalıştığını bilmeniz gerekir. Eylemler, ihtiyaç duydukları erişim türüne bölünebilir:

  • Veri düzlemi erişimi. Veri düzleminde gerçekleştirilen eylemler, iç veya dış erişim için veri aktarımına neden olur. Örneğin, bir uygulama veritabanından veri okur ve bir veritabanına veri yazar, gizli dizileri getirir veya izleme havuzuna günlükler yazar. Bileşen düzeyinde, görüntüleri kayıt defterine veya kayıt defterinden çeken veya bu kayıt defterinden gönderen işlem, veri düzlemi işlemleri olarak kabul edilir.

  • Kontrol düzlemi erişimi. Denetim düzleminde gerçekleşen eylemler bir Azure kaynağının oluşturulmasına, değiştirilmesine veya silinmesine neden olur. Örneğin, kaynak özelliklerinde yapılan değişiklikler.

Uygulamalar genellikle veri düzlemi işlemlerini hedeflerken, işlemler genellikle hem denetim hem de veri düzlemlerine erişirken. Yetkilendirme gereksinimlerini belirlemek için kaynakta gerçekleştirilebilecek işlem eylemlerini not edin. Her kaynak için izin verilen eylemler hakkında bilgi için bkz. Azure kaynak sağlayıcısı işlemleri.

Rol tabanlı yetkilendirme sağlama

Her kimliğin sorumluluğuna bağlı olarak, izin verilmesi gereken eylemleri yetkilendinin. Bir kimliğin yapması gerekenden daha fazlasını gerçekleştirmesine izin verilmemelidir. Yetkilendirme kurallarını ayarlamadan önce kimlerin veya neyin istekte bulunduğunu, bu rolün ne gerçekleştirmesine izin verildiğini ve bunu ne ölçüde yapabileceğini net bir şekilde anlamanız gerekir. Bu faktörler kimlik, rol ve kapsamı birleştiren seçimlere yol açar.

Bir iş yükü kimliğini örnek olarak düşünün. Uygulamanın veritabanına veri düzlemi erişimi olmalıdır, bu nedenle veri kaynağında okuma ve yazma eylemlerine izin verilmelidir. Ancak uygulamanın gizli dizi deposuna denetim düzlemi erişimine ihtiyacı var mı? İş yükü kimliği kötü bir aktör tarafından tehlikeye girerse, gizlilik, bütünlük ve kullanılabilirlik açısından sistemin etkisi ne olur?

Rol ataması

Rol, bir kimliğe atanmış bir izin kümesidir . Yalnızca kimliğin görevi tamamlamasına izin veren roller atayın ve daha fazlasını atayın. Kullanıcının izinleri iş gereksinimleriyle sınırlı olduğunda, sistemdeki şüpheli veya yetkisiz davranışları belirlemek daha kolaydır.

Aşağıdaki gibi sorular sorun:

  • Salt okunur erişim yeterli mi?
  • Kimliğin kaynakları silmek için izinlere ihtiyacı var mı?

Kullanıcıların, uygulamaların veya hizmetlerin Azure kaynaklarına sahip olduğu erişim düzeyini sınırlamak olası saldırı yüzeyini azaltır. Yalnızca belirli görevleri gerçekleştirmek için gereken en düşük izinleri verirseniz, başarılı bir saldırı veya yetkisiz erişim riski önemli ölçüde azalır. Örneğin, güvenlik ekiplerinin tüm teknik ortamlar için yalnızca güvenlik özniteliklerine salt okunur erişime ihtiyacı vardır. Bu düzey, risk faktörlerini değerlendirmek, olası risk azaltmaları belirlemek ve riskleri raporlamak için yeterlidir.

Kuruluş yapısı ve ekip kuruluşu nedeniyle kullanıcıların daha fazla erişime ihtiyaç duyduğu senaryolar vardır. Çeşitli roller arasında çakışma olabilir veya tek kullanıcılar birden çok standart rol gerçekleştirebilir. Bu durumda, bu kullanıcıların her biri için özel bir rol oluşturmak yerine iş işlevini temel alan birden çok rol ataması kullanın. Bunun yapılması rollerin yönetilmesini kolaylaştırır.

Tek tek kaynaklara veya kullanıcılara özel olarak başvuran izinlerden kaçının. Ayrıntılı ve özel izinler karmaşıklık ve karışıklık oluşturur çünkü amacı benzer olan yeni kaynaklara iletmez. Bu, bakımı zor olan ve hem güvenliği hem de güvenilirliği olumsuz etkileyen karmaşık bir eski yapılandırma oluşturabilir.

Denge: Ayrıntılı erişim denetimi yaklaşımı, kullanıcı etkinliklerinin daha iyi denetlenip izlenmesini sağlar.

Rolün ilişkili bir kapsamı da vardır. Rol izin verilen yönetim grubunda, abonelikte, kaynak grubunda veya kaynak kapsamında veya başka bir özel kapsamda çalışabilir. Kimliğin sınırlı bir izin kümesi olsa bile, kapsamı kimliğin iş işlevinin dışındaki kaynakları içerecek şekilde genişletme risklidir. Örneğin, tüm kaynak koduna ve verilere okuma erişimi tehlikeli olabilir ve denetlenmelidir.

Rol tabanlı erişim denetimi (RBAC) kullanarak kimliklere rol atarsınız. Erişim denetimini tutarlı bir şekilde uygulamanıza ve sıkı bir şekilde iptal etmenizi sağlayan özelliklerden yararlanmak için her zaman IdP tarafından sağlanan RBAC'yi kullanın.

Yerleşik rolleri kullanın. Çoğu kullanım örneğini kapsayacak şekilde tasarlanmıştır. Özel roller güçlü ve bazen yararlıdır, ancak bunları yerleşik rollerin çalışmadığı senaryolar için ayırmanız gerekir. Özelleştirme, karışıklığı artıran karmaşıklığa yol açar ve otomasyonu daha karmaşık, zorlayıcı ve kırılgan hale getirir. Bu faktörlerin tümü güvenliği olumsuz etkiler.

En az ayrıcalıkla başlayan roller verin ve operasyonel veya veri erişim gereksinimlerinize göre daha fazla ekleyin. Teknik ekiplerinizin izinleri uygulamak için açık rehberliğe sahip olması gerekir.

RBAC üzerinde ayrıntılı denetim istiyorsanız, rol ataması üzerinde eylemler ve öznitelikler gibi bağlama göre koşullar ekleyin.

Koşullu erişim seçimleri yapma

Tüm kimliklere aynı erişim düzeyini vermeyin. Kararlarınızı iki ana faktöre dayandırın:

  • Zaman. Kimliğin ortamınıza ne kadar süreyle erişebileceği.

  • Ayrıcalık. İzin düzeyi.

Bu faktörler birbirini dışlamaz. Daha fazla ayrıcalığı ve sınırsız erişim süresi olan güvenliği aşılmış bir kimlik, sistem ve veriler üzerinde daha fazla denetim sahibi olabilir veya ortamı değiştirmeye devam etmek için bu erişimi kullanabilir. Bu erişim faktörlerini hem önleyici bir önlem olarak hem de patlama yarıçapını kontrol etmek için kısıtlar.

  • Tam Zamanında (JIT) yaklaşımları, gerekli ayrıcalıkları yalnızca ihtiyaç duyulduğunda sağlar.

  • Yeterli Erişim (JEA) yalnızca gerekli ayrıcalıkları sağlar.

Birincil faktörler zaman ve ayrıcalık olsa da, geçerli olan başka koşullar da vardır. Örneğin, ilkeleri ayarlamak için erişimin kaynaklandığı cihazı, ağı ve konumu da kullanabilirsiniz.

Kullanıcı kimliği ve konumu, cihaz durumu, iş yükü bağlamı, veri sınıflandırması ve anomaliler gibi parametreler de dahil olmak üzere yetkisiz erişimi filtreleyen, algılayan ve engelleyen güçlü denetimler kullanın.

Örneğin, iş yükünüz satıcılar, iş ortakları ve müşteriler gibi üçüncü taraf kimlikler tarafından erişilmesi gerekebilir. Tam zamanlı çalışanlara sağladığınız varsayılan izinler yerine uygun erişim düzeyine sahip olmaları gerekir. Dış hesapların net bir şekilde farklılaşması, bu vektörlerden gelen saldırıları önlemeyi ve algılamayı kolaylaştırır.

IdP seçiminiz bu farklılığı sağlayabilmeli, en az ayrıcalığı temel alan izinler veren yerleşik özellikler sağlayabilmelidir ve yerleşik tehdit bilgileri sağlayabilmelidir. Buna erişim isteklerinin ve oturum açmaların izlenmesi dahildir. Azure IdP Microsoft Entra kimliğidir. Daha fazla bilgi için bu makalenin Azure kolaylaştırma bölümüne bakın.

Kritik etki hesapları

Yönetim kimlikleri, gerçekleştirdikleri görevler bu sistem ve uygulamalardan oluşan geniş bir kümeye ayrıcalıklı erişim gerektirdiğinden en yüksek etkiye sahip güvenlik risklerinden bazılarını ortaya çıkarır. Gizliliğin ihlal edilmesi veya kötüye kullanılması, işletmeniz ve bilgi sistemleri üzerinde zararlı bir etkiye sahip olabilir. Yönetimin güvenliği en kritik güvenlik alanlarından biridir.

Ayrıcalıklı erişimin belirlenen saldırganlara karşı korunması, bu sistemleri risklerden yalıtmak için eksiksiz ve düşünceli bir yaklaşım benimsemenizi gerektirir. Uygulanabilecek bazı stratejiler şunlardır:

  • Kritik etki hesaplarının sayısını en aza indirin.

  • Mevcut kimlikler için ayrıcalıkları yükseltmek yerine ayrı roller kullanın.

  • IdP'nizin JIT özelliklerini kullanarak kalıcı veya sürekli erişimden kaçının. Cam kıran durumlar için acil durum erişim sürecini izleyin.

  • Parolasız kimlik doğrulaması veya çok faktörlü kimlik doğrulaması gibi modern erişim protokollerini kullanın. Bu mekanizmaları IdP'nize haricileştirin.

  • Koşullu erişim ilkelerini kullanarak temel güvenlik özniteliklerini zorunlu tutun.

  • Kullanılmayan yönetim hesaplarının yetkisini alma.

Ortamlar arasında tek bir kimlik kullanın ve tek bir kimliği kullanıcı veya sorumluyla ilişkilendirin. Bulut ve şirket içi ortamlardaki kimliklerin tutarlılığı, insan hatalarını ve sonuçta ortaya çıkan güvenlik risklerini azaltır. Kaynakları yöneten her iki ortamdaki ekiplerin güvenlik güvencelerini karşılamak için tutarlı ve yetkili bir kaynağa ihtiyacı vardır. Karma ortamlardaki kimliklerin eşitlenmiş olduğundan emin olmak için merkezi kimlik ekibinizle birlikte çalışın.

Risk: Yüksek ayrıcalıklı kimliklerin eşitlenmesiyle ilişkili bir risk vardır. Bir saldırgan şirket içi varlıkların tam denetimini alabilir ve bu da bulut hesabının başarılı bir şekilde ele geçirilmesine yol açabilir. Saldırı yüzeyine ekleyebilen hesapları filtreleyerek eşitleme stratejinizi değerlendirin.

Kimlik yaşam döngüsünü yönetmek için süreçler oluşturma

Kimliklere erişim, kimliklerin erişdiği kaynaklardan daha uzun süre dayanmamalıdır. Ekip yapısında veya yazılım bileşenlerinde değişiklik olduğunda kimlikleri devre dışı bırakma veya silme işlemine sahip olduğunuzdan emin olun.

Bu kılavuz kaynak denetimi, veriler, denetim düzlemleri, iş yükü kullanıcıları, altyapı, araçlar, verilerin izlenmesi, günlükler, ölçümler ve diğer varlıklar için geçerlidir.

Dijital kimliklerin, yüksek ayrıcalıklı kullanıcıların, dış/konuk kullanıcıların ve iş yükü kullanıcılarının yaşam döngüsünü yönetmek için bir kimlik idaresi süreci oluşturun. Kimlikler kuruluş veya takımdan ayrıldığında iş yükü izinlerinin kaldırıldığından emin olmak için erişim gözden geçirmeleri uygulayın.

Kimliksizliğe dayalı gizli dizileri koruma

Önceden paylaşılan anahtarlar gibi uygulama gizli dizileri sistemdeki savunmasız noktalar olarak kabul edilmelidir. İki yönlü iletişimde sağlayıcının veya tüketicinin güvenliği tehlikeye atılırsa önemli güvenlik riskleri ortaya eklenebilir. Bu anahtarlar operasyonel süreçler getirdiği için de zahmetli olabilir.

Bunu yaptığınızda gizli dizileri kullanmaktan kaçının ve yalnızca kaynaklarına değil uygulamaya kullanıcı erişimi için kimlik tabanlı kimlik doğrulamasını kullanmayı göz önünde bulundurun.

Aşağıdaki listede kılavuzun özeti verilmiştir. Daha fazla bilgi için bkz. Uygulama gizli dizileri için öneriler.

  • Bu gizli dizileri, bir gizli dizi deposundan dinamik olarak çekilebilen varlıklar olarak değerlendirin. Bunlar uygulama kodunuz, IaC betikleri, dağıtım işlem hatları veya başka bir yapıta sabit kodlanmış olmamalıdır.

  • Gizli dizileri iptal etme yeteneğine sahip olduğunuzdan emin olun.

  • Anahtar döndürme ve süre sonu gibi görevleri işleyen işlem uygulamalarını uygulayın.

Döndürme ilkeleri hakkında bilgi için bkz. İki kimlik doğrulama kimlik bilgisi kümesine sahip kaynaklar için gizli dizi döndürmeyi otomatikleştirme ve Öğretici: Key Vault'de sertifika otomatik döndürme sıklığını güncelleştirme.

Geliştirme ortamlarını güvende tutma

Tüm kod ve betikler, işlem hattı araçları ve kaynak denetim sistemleri iş yükü varlıkları olarak kabul edilmelidir. Yazma işlemlerine erişim otomasyon ve eş gözden geçirme ile sınırlanmalıdır. Kaynak koduna okuma erişimi , bilinmesi gereken rollerle sınırlı olmalıdır. Kod depolarının sürüm oluşturması ve eşler tarafından yapılan güvenlik kodu incelemelerinin geliştirme yaşam döngüsüyle tümleştirilmiş düzenli bir uygulama olması gerekir. Kaynakları düzenli olarak tarayan ve en son güvenlik açıklarını tanımlayan bir sürecin olması gerekir.

GitHub gibi dağıtım ortamlarından kaynaklara erişim vermek için iş yükü kimliklerini kullanın.

Denetim kaydını tutma

Kimlik yönetiminin bir yönü, sistemin denetlenebilir olmasını sağlamaktır. Denetimler, varsayım ihlali stratejilerinin etkili olup olmadığını doğrular. Denetim kaydının tutulması şunları kullanmanıza yardımcı olur:

  • Kimliğin güçlü kimlik doğrulamasıyla doğrulandığını doğrulayın. İnkar saldırılarını önlemek için herhangi bir eylemin izlenebilir olması gerekir.

  • Zayıf veya eksik kimlik doğrulama protokollerini algılamanın yanı sıra kullanıcı ve uygulama oturum açma işlemleri hakkında görünürlük ve içgörüler elde edin.

  • Güvenlik ve uyumluluk gereksinimlerine göre kimliklerden iş yüküne erişimi değerlendirin ve kullanıcı hesabı riskini, cihaz durumunu ve ayarladığınız diğer ölçütleri ve ilkeleri göz önünde bulundurun.

  • Uyumluluk gereksinimlerinin ilerleme durumunu veya sapma durumunu izleyin.

Çoğu kaynağın veri düzlemi erişimi vardır. Kaynaklara erişen kimlikleri ve gerçekleştirdikleri eylemleri bilmeniz gerekir. Bu bilgileri güvenlik tanılaması için kullanabilirsiniz.

Daha fazla bilgi için bkz . Güvenlik izleme ve tehdit analiziyle ilgili öneriler.

Azure kolaylaştırma

Her zaman tüm kullanılabilir veri noktalarını dikkate alıp koşullu erişim kullanan modern kimlik doğrulama protokollerini kullanmanızı öneririz. Microsoft Entra Kimliği, Azure'da kimlik ve erişim yönetimi sağlar. Azure'ın yönetim düzlemini kapsar ve çoğu Azure hizmetlerinin veri düzlemleriyle tümleşiktir. Microsoft Entra kimliği, iş yükü aboneliğiyle ilişkili kiracıdır. Kimlikleri ve izin verilen izinlerini izler ve yönetir ve gözetim veya insan hatası riskini en aza indirmek için genel yönetimi basitleştirir.

Bu özellikler, kullanıcı segmentleri için aynı Microsoft Entra kimliği ve izin modeliyle yerel olarak tümleştirilir:

Microsoft Kimlik Doğrulama Kitaplığı (MSAL) veya web uygulamaları için kimlik doğrulaması gibi platform özellikleri aracılığıyla özel uygulamaların kimlik doğrulaması ve yetkilendirmesi için Microsoft Entra kimliğini kullanabilirsiniz. Azure'ın yönetim düzlemini, Azure hizmetlerinin çoğunun veri düzlemlerini ve uygulamalarınız için tümleştirme özelliklerini kapsar.

Microsoft Entra Kimliği'ndeki yenilikler'i ziyaret ederek güncel kalabilirsiniz.

Denge: Microsof Microsoft Entra Kimliği, diğer temel hizmetler gibi tek bir hata noktasıdır. Kesinti Microsoft tarafından düzeltilinceye kadar geçici bir çözüm yoktur. Ancak, Microsoft Entra zengin özellik kümesi özel çözümler kullanma riskine ağır basıyor.

Azure, OAuth2 ve OpenID Connect gibi açık protokolleri destekler. Kendi akışlarınızı tasarlamak yerine bu standart kimlik doğrulama ve yetkilendirme mekanizmalarını kullanmanızı öneririz.

Azure RBAC

Azure RBAC, Microsoft Entra kimliğindeki güvenlik sorumlularını temsil eder. Tüm rol atamaları Azure RBAC aracılığıyla yapılır. İhtiyacınız olan izinlerin çoğunu sağlayan yerleşik rollerden yararlanın. Daha fazla bilgi için bkz. yerleşik rolleri Microsoft Entra.

Bazı kullanım örnekleri şunlardır:

RBAC hakkında daha fazla bilgi için bkz. Azure RBAC için en iyi yöntemler.

Öznitelik tabanlı denetimler hakkında bilgi için bkz. Azure ABAC nedir?.

İş yükü kimliği

Microsoft Entra kimliği uygulamanızın kimliğini işleyebilir. Uygulamayla ilişkili hizmet sorumlusu erişim kapsamını dikte edebilir.

Daha fazla bilgi için bkz . İş yükü kimlikleri nedir?.

Yönetilen kimlik kullandığınızda hizmet sorumlusu da soyutlanır. Bunun avantajı, Azure'ın uygulama için tüm kimlik bilgilerini yönetmesidir.

Tüm hizmetler yönetilen kimlikleri desteklemez. Yönetilen kimlikleri kullanamıyorsanız, hizmet sorumlularını kullanabilirsiniz. Ancak, hizmet sorumlularını kullanmak yönetim ek yükünüzü artırır. Daha fazla bilgi için bkz. Azure kaynakları için yönetilen kimlikler nedir?.

Kaynak kimliği

Yönetilen kimlik kavramı Azure kaynaklarına genişletilebilir. Azure kaynakları, Microsoft Entra kimlik doğrulamasını destekleyen diğer hizmetlerde kimliklerini doğrulamak için yönetilen kimlikleri kullanabilir. Daha fazla bilgi için bkz. Diğer hizmetlere erişmek için yönetilen kimlikleri kullanabilen Azure hizmetleri.

Koşullu erişim ilkeleri

Koşullu erişim, erişim kararı için ilkenizi açıklar . Koşullu erişimi kullanmak için kullanım örneği için gereken kısıtlamaları anlamanız gerekir. İşletimsel gereksinimlerinize göre bir erişim ilkesi ayarlayarak koşullu erişim Microsoft Entra yapılandırın.

Daha fazla bilgi için bkz . Koşullu erişim: Kullanıcılar, gruplar ve iş yükü kimlikleri.

Grup erişim yönetimi

Belirli kullanıcılara izin vermek yerine, Microsoft Entra kimliğindeki gruplara erişim atayın. Bir grup yoksa, bir grup oluşturmak için kimlik ekibinizle birlikte çalışın. Ardından Azure dışında grup üyeleri ekleyip kaldırabilir ve izinlerin güncel olduğundan emin olabilirsiniz. Grubu posta listeleri gibi başka amaçlar için de kullanabilirsiniz.

Daha fazla bilgi için bkz. Microsoft Entra kimliğindeki grupları kullanarak erişim denetiminin güvenliğini sağlama.

Tehdit algılama

Microsoft Entra ID Koruması kimlik tabanlı riskleri algılamanıza, araştırmanıza ve düzeltmenize yardımcı olabilir. Daha fazla bilgi için bkz. Kimlik Koruması nedir?.

Tehdit algılama, şüpheli etkinlik uyarısına tepki verme veya etkinlik günlüklerinde anormal olayları proaktif olarak arama biçimini alabilir. Microsoft Sentinel'deki Kullanıcı ve Varlık Davranışı Analizi (UEBA), şüpheli etkinlikleri algılamayı kolaylaştırır. Daha fazla bilgi için bkz. UEBA ile gelişmiş tehditleri tanımlama.

Hibrit sistemler

Azure'da, hesapları mevcut Active Directory'nizde yüksek ayrıcalıklara sahip Microsoft Entra kimliğiyle eşitlemeyin. Bu eşitleme, Connect Sync yapılandırmasında varsayılan Microsoft Entra engellenir, bu nedenle yalnızca bu yapılandırmayı özelleştirmediğinizden emin olmanız gerekir.

Microsoft Entra kimliğinde filtreleme hakkında bilgi için bkz. Connect Sync: Filtrelemeyi yapılandırma Microsoft Entra.

Kimlik günlüğü

Denetim izi olarak kullanabileceğiniz bilgileri yaymak için Azure kaynaklarında tanılama ayarlarını etkinleştirin. Tanılama bilgileri, hangi kimliklerin hangi kaynaklara erişme girişiminde olduğunu ve bu girişimlerin sonucunu gösterir. Toplanan günlükler Azure İzleyici'ye gönderilir.

Dezavantaj: Günlükleri depolamak için kullanılan veri depolama alanı nedeniyle günlüğe kaydetme maliyetlerine neden olur. Ayrıca, özellikle kod üzerinde ve uygulamaya eklediğiniz günlük çözümleri üzerinde performans etkisine neden olabilir.

Örnek

Aşağıdaki örnekte bir kimlik uygulaması gösterilmektedir. Gerekli erişim düzeylerini sağlamak için farklı kimlik türleri birlikte kullanılır.

Kimlik uygulamasını gösteren diyagram.

Kimlik bileşenleri

  • Sistem tarafından yönetilen kimlikler. Microsoft Entra kimliği, Azure Key Vault ve veri depoları gibi kullanıcılarla yüzleşmeyen hizmet veri düzlemlerine erişim sağlar. Bu kimlikler ayrıca RBAC aracılığıyla iş yükü bileşenleri, dağıtım aracıları ve ekip üyeleri için Azure yönetim düzlemine erişimi de denetler.

  • İş yükü kimlikleri. Azure Kubernetes Service (AKS) kümesindeki uygulama hizmetleri, çözümdeki diğer bileşenlerde kimliklerini doğrulamak için iş yükü kimliklerini kullanır.

  • Yönetilen kimlikler. İstemci rolündeki sistem bileşenleri, derleme aracıları dahil olmak üzere sistem tarafından yönetilen kimlikleri kullanır.

  • İnsan kimlikleri. Kullanıcı ve işleç kimlik doğrulaması, Microsoft Entra kimliğine veya Microsoft Entra kimliğine (yerel, B2B veya B2C) temsilci olarak atandı.

Önceden paylaşılan gizli dizilerin güvenliği tüm uygulamalar için kritik öneme sahiptir. Azure Key Vault, Redis ve üçüncü taraf gizli dizileri de dahil olmak üzere bu gizli diziler için güvenli bir depolama mekanizması sağlar.

Gizli dizilerin gizliliğinin tehlikeye atılmadığından emin olmak için döndürme mekanizması kullanılır. Kullanıcıların kimliğini doğrulamak için OAuth 2 ve OpenID Connect'in Microsoft kimlik platformu uygulamasına yönelik belirteçler kullanılır.

Azure İlkesi, Key Vault gibi kimlik bileşenlerinin erişim ilkeleri yerine RBAC kullanmasını sağlamak için kullanılır. JIT ve JEA, insan operatörler için geleneksel ayakta izinler sağlar.

Erişim günlükleri tüm bileşenlerde Azure Tanılama veya kod bileşenleri için kod aracılığıyla etkinleştirilir.

Güvenlik denetim listesi

Önerilerin tamamına bakın.

Güvenlik denetim listesi