Azure Cosmos DB Erişimi: Ekip Büyürken Rol ve Kapsam

Proje bir ya da iki kişiyle başlar, sonra geliştiriciler, operasyon ekibi, analistler ve uygulamalar aynı Azure Cosmos DB hesabına erişmek ister. Herkese aynı izinleri vermek kısa vadede pratiktir; karşılığında her kimlik, yaptığı işin gerektirdiğinden daha güçlü hale gelir. Aşağıdaki model erişimi kişilere değil işlere göre düzenliyor ve tekrar edilebilir birkaç basit kalıba dayanıyor: yönetim erişimini veri erişiminden ayırmak, rolleri gruplara ve iş yükü kimliklerine atamak, mümkün olan en dar kapsamı kullanmak.

Not: Buradaki anlatım Azure Cosmos DB for NoSQL odaklı. Kimlik doğrulama ve yetkilendirme seçenekleri diğer Azure Cosmos DB API’lerinde farklılık gösterir.

Hesabı yönetmek ile veriyi kullanmak aynı şey değil

Azure Cosmos DB erişimi iki ayrı düzlemde ele alınır:

• Control plane: Azure kaynaklarının yönetimi. Hesap yapılandırması, veritabanı ve container oluşturma, throughput değiştirme ve rol atamalarını yönetme bu kapsamdadır. Bu izinler Azure role-based access control (Azure RBAC) ile verilir.
• Data plane: Item’larla çalışmak. Okuma, sorgulama, oluşturma, güncelleme ve silme işlemleri buraya girer. Azure Cosmos DB for NoSQL bu düzlem için kendi yerel data-plane RBAC modelini sunar.

Pratikte sık sık birbirine karışan görevleri ayıran da bu sınır. Bir platform mühendisi, müşteri verisini okumadan hesap yapılandırmasını yönetebilir; bir uygulama da throughput veya ağ ayarlarına dokunmadan item okuyup yazabilir.

Bir ayrıntı atlanmasın: Azure tarafında Owner veya Contributor olmak otomatik olarak item erişimi vermez. Aynı şekilde bir Cosmos DB veri rolü de hesabı yapılandırma yetkisi sağlamaz.

Küçük bir rol modeliyle başlayın

Her ekip üyesi için ayrı bir özel rol üretmek yerine ekibin gerçekten yaptığı işlerden yola çıkın. Kaynakta önerilen başlangıç noktaları şöyle:

Kimlik veya grup	İhtiyacı	Başlangıç noktası
Uygulama geliştiricileri	Özellik geliştirmek ve test etmek	Üretim dışı ortamlarda Data Contributor
Üretimdeki uygulama	Tek bir iş yükünü çalıştırmak	Kapsamı daraltılmış veri rolüne sahip managed identity
Site reliability engineer	Sağlık ve yapılandırma teşhisi	Cosmos DB Operator; gerekirse geçici veri erişimi
Veri analistleri	Onaylı salt-okunur sorgular	Raporlama verisi üzerinde yerleşik Data Reader
Platform mühendisleri	Hesap, container ve throughput yönetimi	Cosmos DB Operator veya özel bir Azure rolü

Veri düzleminde iki yerleşik rol birçok senaryoyu karşılar:

Kimlik şunu yapacaksa…	Şununla başlayın…
Item okumak, sorgu çalıştırmak ve change feed okumak	Cosmos DB Built-in Data Reader
Item okumak, oluşturmak, güncellemek ve silmek	Cosmos DB Built-in Data Contributor

Data Contributor rolü silme iznini de kapsıyor. Bir uygulamanın yazması gerekiyor ama hiçbir zaman silmemesi gerekiyorsa, yalnızca gerekli action’ları içeren özel bir veri rolü tanımlamak doğru yaklaşım.

Control plane tarafında ise geniş kapsamlı bir contributor rolü yerine Cosmos DB Operator çoğu zaman daha güvenli: Azure Cosmos DB kaynaklarını yönetmeye izin verir, hesap anahtarlarına ve bağlantı dizelerine erişimi engeller.

İnsanlar için gruplar, uygulamalar için managed identity

Rolleri tek tek kullanıcılara atadığınızda, ekibe katılımlar, takım değişiklikleri ve ayrılmalar arttıkça takip edilemez hale gelir. Bunun yerine rolleri Microsoft Entra güvenlik gruplarına atayın.

Grup adı servisi, ortamı ve sorumluluğu birlikte anlatmalı:

• cosmos-orders-dev-contributors
• cosmos-orders-prod-data-readers
• cosmos-orders-prod-operators

Bir geliştirici takım değiştirdiğinde abonelikler ve hesaplar arasında rol ataması aramazsınız, yalnızca grup üyeliğini güncellersiniz.

Uygulamalar bu insan erişim gruplarını paylaşmamalı; her iş yüküne kendi managed identity’sini verin. Bir orders API’si orders container’ı üzerinde Data Contributor’a ihtiyaç duyarken raporlama işi raporlama veritabanında Data Reader ile yetinebilir. Kimlikler ayrı olunca hem izinler hem etkinlik kayıtları anlaşılır kalıyor.

Dağıtım otomasyonu da çalışan uygulamadan farklı bir kimlik kullanmalı; container oluşturmak ile item işlemek farklı işler.

Her atamayı işin kapsamına göre daraltın

Bir data-plane rolü hesap, veritabanı veya container düzeyinde atanabilir. Kimliğin işini yapabileceği en dar kapsamı seçin.

Sipariş işleyen bir uygulama tüm hesap yerine yalnızca orders container’ı üzerinde Data Contributor kullanabilir. Bir analist de operasyonel veriye hiç erişmeden raporlama veritabanında Data Reader ile çalışabilir.

Ortamları birbirinden ayrı tutun; geliştirme erişimi sessizce üretim erişimine dönüşmemeli. Kaynakta önerilen varsayılanlar şöyle:

Ortam	İnsan erişimi için kullanışlı varsayılan
Development	Ekibin kaynakları içinde contributor erişimi
Test	Dağıtım ve test için gereken erişim
Production	Veri erişimi yok ya da salt-okunur; gerektiğinde yükseltme

Rol ve kapsam birlikte çalışır: Hesap kapsamında verilen dar bir rol bile gereğinden fazla veriyi açabilir, container kapsamındaki geniş bir rol de iş yükünün yapmaması gereken işlemlere izin verebilir.

Üretim yetkisi kalıcı değil, geçici olsun

Üretim olayları bazen daha geniş erişim gerektirir, ama bu erişimin kalıcı olması gerekmez.

Azure RBAC atamaları için Microsoft Entra Privileged Identity Management ile uygun (eligible) atamalar kullanılabilir. Cosmos DB veri düzlemi erişimi içinse kontrollü bir süreç öneriliyor: Olaya müdahale eden kişiyi özel bir gruba eklemek, gerekçeyi kaydetmek, kısa bir süre sonra üyeliği kaldırmak.

Amaç olay müdahalesini yavaşlatmak değil, olay sırasında verilen erişimin olay bittikten sonra da yerinde kalmasını önlemek.

Hesap anahtarları modeli devre dışı bırakabilir

Hesap anahtarını alabilen bir kimlik, anahtar tabanlı kimlik doğrulama açık olduğu sürece bu anahtarla geniş veri erişimi elde edebilir. Özenle daraltılmış data-plane rolleriniz de böylece anlamsızlaşır.

Kişiler için Microsoft Entra kimlik doğrulamasını, Azure iş yükleri için managed identity’yi tercih edin. Mevcut uygulamaları planlı biçimde taşıyın:

1. Anahtar kullanan uygulama, script, notebook ve araçların envanterini çıkarın.
2. Her iş yüküne bir kimlik ve gereken veri rolünü verin.
3. Gerekli tüm işlemleri ve ortamları test edin.
4. Eski kopyaları geçersiz kılmak için anahtarları rotasyona sokun.
5. Tüm bağımlılıklar taşındıktan sonra local authentication’ı devre dışı bırakın.

Çalışan tüm yolları doğrulamadan anahtar tabanlı kimlik doğrulamayı kapatmayın. Bunu test edilmeden açılıp kapatılan bir anahtar değil, bir göç süreci olarak ele alın. Anahtar kullanımına görünürlük kazanmak için Azure Cosmos DB’deki güvenli anahtar rotasyonu rehberinden yararlanabilirsiniz.

Özet ve sonraki adım

İyi bir erişim modeli karmaşık bir yeniden tasarımla başlamak zorunda değil. Bugün elinizdeki erişimden yola çıkın, onu insanların ve uygulamaların yaptığı işlere göre düzenleyin; rolü, kapsamı ve süreyi pratikte mümkün olan en dar seviyede tutun.

Ekip büyüdükçe her kimlik için şu dört soruyu sorun:

• Bu kimlik hangi işi yapıyor?
• Bu iş control plane’de mi, data plane’de mi?
• Bu işi destekleyen en dar rol hangisi?
• İhtiyaç duyduğu en küçük kapsam ve en kısa süre ne?

Dört soru, tek seferlik izin kararlarına göre çok daha iyi ölçekleniyor. İnsanlara ve uygulamalara ihtiyaç duydukları erişimi veriyor, geniş üretim erişimini varsayılan yapmıyor.

Kaynaklar ve İleri Okuma

• devblogs.microsoft.com

• My Team Is Growing, How Do I Structure Who Gets Access to What? — Azure Cosmos DB Blog (Iria Osara, Sudhanshu Khera)
• Azure Cosmos DB’de güvenli anahtar rotasyonu
• Azure Cosmos DB Blog
• Azure Cosmos DB YouTube kanalı
• Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor
• Azure Cosmos DB RBAC: Tek Kişilik Projede Gerekli mi?
• Azure Cosmos DB Safe Key Rotation ile Anahtar Görünürlüğü