Azure'da kimlik ve erişim yönetimi: Entra ID ve RBAC birlikte nasıl çalışır

Entra ID ve RBAC: aynı şey değil, birlikte çalışır

Kimlik ve erişim yönetiminde temel sorular şunlardır: kim olduğunuzu nasıl doğruluyoruz, ve doğruladıktan sonra ne yapmanıza izin veriyoruz? Microsoft Entra ID (eski adıyla Azure Active Directory) ilk soruyu yanıtlar: kullanıcıları, grupları, uygulamaları ve cihazları tutan, oturum açma ve çok adımlı doğrulamayı yöneten bulut tabanlı kimlik hizmetidir. Azure RBAC (rol tabanlı erişim denetimi) diğer soruyu yanıtlar: kimlik doğrulandıktan sonra Azure kaynakları üzerinde hangi işlemleri yapabileceğini belirler.

Karıştırılmaması gereken bir ayrım daha vardır. Entra ID'nin kendi yönetici rolleri, dizinin kendisini (kullanıcı oluşturma, parola sıfırlama, uygulama kaydı gibi) yönetir. Azure RBAC rolleri ise abonelik, kaynak grubu ve kaynaklar gibi Azure bileşenlerini yönetir. Bir kişi dizin yöneticisi olmadan abonelikte sahip olabilir ya da tersi.

Bu hizmetleri birlikte doğru kurmak, "herkes yönetici" ya da "kimse bir şey yapamıyor" uçlarından kaçınmanın yoludur.

RBAC nasıl çalışır: kim, ne yapabilir, nerede?

Bir rol ataması şu bileşenlerden oluşur:

• Güvenlik sorumlusu. Kimin erişeceği: kullanıcı, grup, hizmet sorumlusu veya yönetilen kimlik.
• Rol tanımı. Hangi işlemlerin yapılabileceği: okuma, yazma, silme ve yönetim eylemlerinin toplamı.
• Kapsam. Rolün nerede geçerli olduğu: yönetim grubu, abonelik, kaynak grubu veya tek bir kaynak.

Kapsamlar hiyerarşiktir ve atamalar aşağıya doğru kalıtılır. Aboneliğe verilen bir rol, içindeki tüm kaynak gruplarında ve kaynaklarda geçerlidir. Bu yüzden rolü mümkün olan en dar kapsama atamak güvenlik ilkesidir.

Yerleşik rollerin temelini hatırlamak yararlıdır: Okuyucu (Reader) yalnızca görüntüler. Katkıda Bulunan (Contributor) kaynakları oluşturur ve değiştirir ama başkalarına yetki veremez. Sahip (Owner) tüm yönetim işlemlerine ek olarak erişim yetkisi de verebilir. Birçok hizmetin kendi özel rolleri de vardır; örneğin sanal makine ya da depolama için daha ince yetkiler. Yerleşik roller yetersiz kalırsa özel rol tanımlanabilir. Rollerin güncel listesini ve adlarını Microsoft belgelerinden kontrol edin.

Adım adım erişim yapılandırması

Yeni bir ekip için erişim kurarken şu sıra iyi çalışır:

• Kimlikleri düzenleyin. Kullanıcıları doğrudan değil, işlev bazlı gruplar halinde yönetin: örneğin ağ yöneticileri, uygulama geliştiricileri, denetçiler.
• Gerekli işlemleri belirleyin. Ekibin ne yapması gerektiğini yazın; ardından bu işleme yetecek en dar yerleşik rolü bulun.
• Kapsamı belirleyin. Rolün yalnızca ilgili kaynak grubunda mı yoksa tüm abonelikte mi geçerli olacağına karar verin. Mümkünse kaynak grubu düzeyinde kalın.
• Rolü gruba atayın. Kullanıcıya doğrudan atama yerine gruba atama, ekip değişimlerini kolaylaştırır.
• Güvenli oturum açmayı zorunlu kılın. Çok adımlı doğrulama ve koşullu erişim politikaları kimlik hırsızlığına karşı korur.
• Doğrulayın. Yeni kullanıcıyla oturum açıp beklenen işlemlerin çalıştığını ve beklenmeyenlerin engellendiğini test edin.
• Düzenli gözden geçirin. Erişim incelemeleriyle gerekmeyen yetkileri kaldırın.

Bu akışı komut satırı ve şablon olarak kodlamak, ortamlar arası tutarlılığı sağlar.

En az yetki ilkesi ve ayrıcalıklı erişim

En az yetki ilkesi, kimliğe işini yapması için gereken en dar yetkiyi vermektir. Pratikte bu, Sahip rolünü sınırlı sayıda kişiye vermek, çoğu kullanıcıya Okuyucu veya Katkıda Bulunan gibi dar roller atamak ve yönetim işlemlerini normal çalışma kimliğinden ayırmak anlamına gelir.

Ayrıcalıklı kimlikler için sürekli yetki yerine gerektiğinde ve süreli yetki yaklaşımı güvenlidir. Entra ID'nin ayrıcalıklı kimlik yönetimi özelliği, kullanıcının yüksek yetkili rolü yalnızca gerektiğinde, onayla ve zaman sınırlı etkinleştirmesine imkân verir. Bu özellik belirli lisans düzeyleri gerektirir; güncel koşulları belgelerden kontrol edin.

Uygulamaların ve otomasyonların kimliği de aynı titizlikle yönetilmelidir. Uygulamalar için parola ve anahtar gömmek yerine yönetilen kimlik kullanın. Yönetilen kimlik, Azure kaynağına (örneğin bir VM'ye veya uygulama hizmetine) Azure tarafından yönetilen bir kimlik verir; böylece gizli bilgi saklamadan diğer hizmetlere erişilir. Hizmet sorumluları kullanıldığında da yetki dar tutulmalıdır.

Yalnızca ayrıcalıklı kullanıcılar için değil, acil erişim hesapları için de net bir yönetim planı olmalıdır.

Örnek: depolama hesabına uygulama erişimi vermek

Örneğin bir geliştirme ekibi, uygulamasının bir depolama hesabındaki dosyaları okumasını istiyor. İlk akla gelen çözüm, depolama hesabı anahtarını uygulama yapılandırmasına yazmaktır. Bu yaklaşım anahtar sızarsa hesabın tamamını açığa çıkarır.

Bunun yerine ekip, uygulamanın çalıştığı kaynağa bir yönetilen kimlik atıyor. Ardından bu kimliğe, yalnızca ilgili depolama hesabı kapsamında, dosya okumaya yeten dar bir yerleşik rol atıyor. Uygulama kodu, kimlik bilgisi içermeden Azure'ın sağladığı kimlikle oturum açıyor. Anahtar yönetimi, rotasyon ve sızıntı riski ortadan kalkıyor.

Aynı ekibin üyeleri ise bir güvenlik grubuna ekleniyor; gruba geliştirme ortamının kaynak grubunda Katkıda Bulunan, üretim kaynak grubunda ise yalnızca Okuyucu rolü veriliyor. Üretim değişiklikleri ayrı bir yetkili grup ve onay süreciyle yapılıyor. Böylece hem günlük geliştirme hızı korunuyor hem de üretim ortamı yanlışlıkla bozulamıyor.

Sık yapılan hatalar

• Herkese abonelik düzeyinde Sahip ya da Katkıda Bulunan vermek. Yetki gereğinden geniş olur, hata ve kötüye kullanım riski artar.
• Kullanıcılara tek tek rol atamak. Ekip değişince eski atamalar unutulur; grup tabanlı yönetim tercih edilmelidir.
• Entra ID rolleri ile Azure rollerini karıştırmak. Birinin yetkisi diğerini kendiliğinden vermez.
• Çok adımlı doğrulamayı yönetici hesaplarında bile zorunlu tutmamak.
• Uygulamalara parola ve anahtar gömmek. Yönetilen kimlik kullanılabilecek yerlerde gizli bilgi saklamayın.
• Erişim incelemesi yapmamak. Eski çalışanlara ve tamamlanmış projelere ait yetkiler birikir.
• Özel rolleri gelişigüzel çoğaltmak. Yerleşik roller yetiyorsa özel rol yaratmayın; yönetimi zorlaşır.
• Etkinlik günlüklerini izlememek. Yetki değişiklikleri ve olağan dışı oturum açmalar fark edilmez.

Öğrenme yolu ve Mindset programlarında nerede çalışılır

Başlangıçta kimlik doğrulama ile yetkilendirme arasındaki farkı, Entra ID'deki kullanıcı ve grup yapısını ve temel RBAC rollerini öğrenin. Sonra kapsam hiyerarşisi, özel roller, koşullu erişim ve çok adımlı doğrulama gelir. İleri düzeyde ayrıcalıklı kimlik yönetimi, erişim incelemeleri, yönetilen kimlikler ve kurumsal kimlik federasyonu yer alır.

Mindset kataloğunda Azure Administrator (AZ-104) Hazırlık programı "AZ-104 Sınav Yapısı ve Kimlik Yönetimi" modülünü yönetişim, sanal makine, ağ, depolama ve izleme-yedekleme konularıyla birlikte sunar. Microsoft Azure Eğitimi ise "Kimlik & Erişim Yönetimi" başlığını bulut temelleri, kaynak yönetimi, ağ, depolama ve güvenlik başlıklarıyla birlikte ele alır. Bulut yöneticileri, güvenlik ve BT operasyon ekipleri bu programları kendi kimlik ve abonelik yapıları üzerinden çalışmayı tercih edebilir.