Bu makalede, Sıfır Güven ilkelerine uygun bir Koşullu Erişim mimarisi açıklanmaktadır. Mimari, yapılandırılmış bir Koşullu Erişim çerçevesi oluşturmak için kişi tabanlı bir yaklaşım kullanır.
Koşullu Erişim Sıfır Güven mimarisi
Önce bir mimari seçmeniz gerekir. Hedeflenen veya Sıfır Güven Koşullu Erişim mimarisini göz önünde bulundurmanızı öneririz. Bu diyagramda ilgili ayarlar gösterilir:
Sıfır Güven Koşullu Erişim mimarisi, Sıfır Güven ilkelerine en uygun mimaridir. Koşullu Erişim ilkesinde Tüm bulut uygulamaları seçeneğini belirtirseniz tüm uç noktalar, bilinen kullanıcı ve bilinen veya uyumlu cihaz gibi sağlanan izin denetimleriyle korunur. Ancak ilke yalnızca Koşullu Erişimi destekleyen uç noktalara ve uygulamalara uygulanmaz. Kullanıcının etkileşimde olduğu tüm uç noktalar için geçerlidir.
Örnek olarak, çeşitli yeni PowerShell ve Microsoft Graph araçlarında kullanılan bir cihaz oturum açma akışı uç noktası verilmiştir. Cihaz oturum açma akışı, IoT cihazı gibi bir oturum açma ekranı göstermenin mümkün olmadığı bir cihazdan oturum açmaya izin vermek için bir yol sağlar.
Verilen cihazda cihaz tabanlı bir oturum açma komutu çalıştırılır ve kullanıcıya bir kod gösterilir. Bu kod başka bir cihazda kullanılır. Kullanıcı adresine gider https://aka.ms/devicelogin ve kullanıcı adını ve parolasını belirtir. Diğer cihazdan oturum açıldıktan sonra, bu kullanıcı bağlamında IoT cihazında oturum açma başarılı olur.
Bu oturum açma işlemindeki zorluk, cihaz tabanlı Koşullu Erişimi desteklememesidir. Bu, tüm bulut uygulamaları için bilinen kullanıcı ve bilinen cihaz gerektiren bir temel ilke uygularsanız kimsenin araçları ve komutları kullanacağı anlamına gelir. Cihaz tabanlı Koşullu Erişim ile aynı soruna sahip başka uygulamalar da vardır.
Hedeflenen diğer mimari, Koşullu Erişim ilkelerinde yalnızca korumak istediğiniz tek tek uygulamaları hedeflediğiniz ilkesine göre oluşturulmuştur. Bu durumda, daha önce Microsoft Entra Id'ye yapılan grafik çağrıları gibi tüm bulut uygulamalarının kapsadığı uç noktalar için cihaz oturumu açma, Koşullu Erişim ilkeleri tarafından korunmadığından çalışmaya devam eder.
İki mimariyi ayırt etmek için cihaz oturum açma bilgilerini örnek olarak kullanırken cihaz oturum açma ile kimlik doğrulaması yapabilirsiniz. Her uygulamanın hedeflenebilir olması ve bu nedenle cihaz tabanlı oturum açma gerektiren bir Koşullu Erişim ilkesinde dışlanabilmesi göz önünde bulundurulduğunda, bir veya birkaç uygulama için cihaz oturum açma işlemine izin verilebilir.
Hedeflenen mimarinin zorluğu, tüm bulut uygulamalarınızı korumayı unutmanızdır. Yine de Koşullu Erişim ilkelerindeki tüm seçilebilir uygulamaları seçebilirsiniz. Korumasız seçilemeyen uygulamalara erişimi bırakırsınız. Office portalına, Azure EA (Kurumsal Anlaşma) portalına ve çok hassas portallar olan güvenlik bilgileri portalına erişim örnekleri verilebilir.
Microsoft ve iş ortakları yeni özellikler yayınladıkçe ve BT yöneticileriniz çeşitli uygulamaları Microsoft Entra ID ile tümleştirdikçe Office 365 ve Microsoft Entra uygulamalarının sayısının zaman içinde artması da dikkate alınmalıdır. Bu tür uygulamaların tümüne erişim, yalnızca Koşullu Erişimi destekleyen ve bu uygulamaya otomatik olarak ilke uygulayan yeni bir uygulamayı algılayan bir mekanizmanız varsa korunur. Böyle bir betiği oluşturmak ve korumak zor olabilir.
Ayrıca, herhangi bir Koşullu Erişim ilkesi için desteklenen en fazla uygulama sayısı yaklaşık 250'dir. Yükün aşıldığıyla ilgili bir hata almadan önce en fazla 600 uygulama ekleyebilirsiniz, ancak bu sayı desteklenmez.
Koşullu Erişim kişilikleri
Koşullu Erişim ilkelerini yapılandırmanın birçok yolu vardır. Yaklaşımlardan biri, erişilen kaynağın duyarlılığına göre ilkeleri yapılandırmaktır. Uygulamada, bu yaklaşımın çeşitli kullanıcılar için kaynaklara erişimi koruyan bir şekilde uygulanması zor olabilir.
Örneğin, hem konuklar hem de çalışanlar tarafından erişilmesi gereken hassas bir kaynağa erişim için bilinen bir kullanıcı ve bilinen bir cihaz gerektiren bir Koşullu Erişim ilkesi tanımlayabilirsiniz. Konuklar yönetilen bir cihazdan erişim girişiminde bulunduğunda erişim isteği çalışmaz. Her iki gereksinimi de karşılamak için Koşullu Erişim ilkesini ayarlamanız gerekir ve bu da genellikle daha az güvenli gereksinimi karşılayan bir ilkeye neden olur.
Bir diğer yaklaşım da kullanıcının kuruluştaki konumuna göre erişim ilkeleri tanımlamayı denemektir. Bu yaklaşım birçok Koşullu Erişim ilkesine neden olabilir ve yönetilemez olabilir.
Daha iyi bir yaklaşım, ortak erişim gereksinimleriyle ilgili ilkeleri yapılandırmak ve aynı gereksinimlere sahip bir grup kullanıcı için bir dizi erişim gereksinimini bir kişilikte paketlemektir. Kişilikler ortak kurumsal öznitelikleri, sorumlulukları, deneyimleri, hedefleri ve erişimi paylaşan kimlik türleridir.
Kurumsal varlıkların ve kaynakların çeşitli kişiler tarafından nasıl eriştiğini anlamak, kapsamlı bir Sıfır Güven stratejisi geliştirmenin ayrılmaz bir parçasıdır.
Microsoft tarafından önerilen bazı Koşullu Erişim kişilikleri burada gösterilmiştir:
Microsoft ayrıca başka bir kişilik grubunun parçası olmayan kimlikler için ayrı bir kişilik tanımlamanızı önerir. Buna Genel kişi adı verilir. Genel, bir kişilik grubunda olmayan kimlikler için ilkeleri ve tüm kişilikler için zorunlu kılınması gereken ilkeleri zorunlu kılmayı amaçlıdır.
Aşağıdaki bölümlerde bazı önerilen kişilikler açıklanmaktadır.
Küresel
Genel, doğası gereği genel ilkeler için bir kişilik/yer tutucudur. Tüm kişilikler için geçerli olan veya belirli bir kişilik için geçerli olmayan ilkeleri tanımlamak için kullanılır. Diğer kişilikler tarafından kapsanmamış ilkeler için kullanın. Tüm ilgili senaryoları korumak için bu kişi gereklidir.
Örneğin, tüm kullanıcılar için eski kimlik doğrulamasını engellemek için bir ilke kullanmak istediğinizi varsayalım. Bunu, çeşitli kişilikler için farklı olabilecek bir grup eski ilke kullanmak yerine genel bir ilke haline getirebilirsiniz.
Başka bir örnek: Belirli bir hesabı veya kullanıcıyı belirli uygulamalardan engellemek istiyorsunuz ve kullanıcı veya hesap kişilerden herhangi birinin parçası değil. Örneğin, Microsoft Entra kiracısında bir bulut kimliği oluşturursanız, microsoft Entra rolleri atanmadığı için bu kimlik diğer kişilerin bir parçası değildir. Yine de kimliğin Office 365 hizmetlerine erişimini engellemek isteyebilirsiniz.
Herhangi bir kişilik grubu tarafından kapsanmayan kimliklerden gelen tüm erişimi engellemek isteyebilirsiniz. Ya da yalnızca çok faktörlü kimlik doğrulamasını zorunlu kılmak isteyebilirsiniz.
Yönetici s
Bu bağlamda yönetici, herhangi bir Microsoft Entra kimliğine veya başka bir Microsoft 365 yönetici rolüne (örneğin, Bulut için Microsoft Defender Uygulamalar, Exchange, Uç Nokta için Defender veya Uyumluluk Yöneticisi) sahip olan, bulut veya eşitlenmiş herhangi bir konuk olmayan kimliktir. Bu rollere sahip olan konuklar farklı bir kişilik kapsamında olduğundan, konuklar bu kişilikten dışlanır.
Bazı şirketlerin, bu kişi için temel alan hassas yönetici rolleri için ayrı hesapları vardır. Yöneticiler bu hassas hesapları en iyi şekilde Bir Privileged Access workstation'dan (PAW) kullanır. Ancak genellikle yönetici hesaplarının kullanıcının tek bir cihazdaki hesaplar arasında geçiş yaptığı standart iş istasyonlarında kullanıldığını görürüz.
Bulut yöneticisi rollerinin duyarlılığına göre ayrım yapmak ve ayrı hesaplar kullanmak yerine şirket içi kişiliğe daha az hassas Azure rolleri atamak isteyebilirsiniz. Bunun yerine Tam Zamanında (JIT) yükseltmeyi kullanabilirsiniz. Bu durumda, bir kullanıcı her kişi için bir tane olmak üzere iki Koşullu Erişim ilkesi kümesi tarafından hedeflenmiştir. PAW kullanıyorsanız, yöneticilerin yalnızca PAW'larda izin verebilmesi için erişimi kısıtlamak için Koşullu Erişim'de cihaz filtreleri kullanan ilkeler de eklemek isteyebilirsiniz.
Geliştiriciler
Geliştiriciler kişisi, benzersiz gereksinimleri olan kullanıcıları içerir. Microsoft Entra Id ile eşitlenen Active Directory hesaplarını temel alır, ancak Azure DevOps, CI/CD işlem hatları, cihaz kodu akışı ve GitHub gibi hizmetlere özel erişime ihtiyaçları vardır. Geliştiriciler kişisi, iç olarak kabul edilen kullanıcıları ve diğerleri dış olarak kabul edilebilir, ancak bir kişinin kişilerden yalnızca birinde olması gerekir.
İç İşlevler
İç öğeler, Microsoft Entra Id ile eşitlenmiş bir Active Directory hesabı olan, şirketin çalışanları olan ve standart bir son kullanıcı rolünde çalışan tüm kullanıcıları içerir. Geliştirici kişisi olan iç kullanıcıları eklemenizi öneririz.
DışLar
Bu kişi, Active Directory hesabı Microsoft Entra Id ile eşitlenmiş olan tüm dış danışmanları barındırıyor. Geliştirici kişisi olan dış kullanıcıları eklemenizi öneririz.
Konuklar
Konuklar, müşteri kiracısına davet edilmiş bir Microsoft Entra konuk hesabına sahip olan tüm kullanıcıları barındırıyor.
Konuk Yönetici
Konuk Yönetici kişisi, daha önce bahsedilen yönetici rollerinden herhangi birine atanmış bir Microsoft Entra konuk hesabına sahip olan tüm kullanıcıları barındırıyor.
Microsoft365ServiceAccounts
Bu kişi, yönetilen hizmet kimliği kullanma gibi ihtiyacı karşılayan başka bir çözüm olmadığında Microsoft 365 hizmetlerine erişmek için kullanılan bulut (Microsoft Entra Id) kullanıcı tabanlı hizmet hesaplarını içerir.
AzureServiceAccounts
Bu kişi, yönetilen hizmet kimliği kullanma gibi başka bir çözüm gereksinimi karşılamadığında Azure (IaaS/PaaS) hizmetlerine erişmek için kullanılan bulut (Microsoft Entra ID) kullanıcı tabanlı hizmet hesaplarını içerir.
CorpServiceAccounts
Bu kişi, şu özelliklerin tümüne sahip kullanıcı tabanlı hizmet hesaplarını içerir:
- kaynağı şirket içi Active Directory.
- Şirket içinden veya Azure gibi başka bir (bulut) veri merkezinde bulunan IaaS tabanlı bir sanal makineden kullanılır.
- Herhangi bir Azure veya Microsoft 365 hizmetine erişen bir Microsoft Entra örneğiyle eşitlenir.
Bu senaryodan kaçınılmalıdır.
WorkloadId varlıkları
Bu kişi, Microsoft Entra hizmet sorumluları ve yönetilen kimlikler gibi makine kimliklerini içerir. Koşullu Erişim artık bu hesaplardaki kaynaklara erişimin korunmasını desteklemektedir ve bu durumda hangi koşulların ve izin denetimlerinin kullanılabildiğiyle ilgili bazı sınırlamalar sağlanmıştır.
Şablon kartlarına erişme
Her kişilik için özellikleri tanımlamak için erişim şablonu kartları kullanmanızı öneririz. Bir örnek aşağıda verilmiştir:
Her kişi için şablon kartı, her kişilik için belirli Koşullu Erişim ilkelerini oluşturmaya yönelik giriş sağlar.
Koşullu Erişim kılavuzu
Oluşturulan kişilere göre gruplama ilkeleri için yapılandırılmış bir yaklaşım içeren Koşullu Erişim çerçevesini gözden geçirin.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazar:
- Claus Jespersen | Baş Danışman Kimliği &Sn
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.
Sonraki adımlar
- Öğrenme yolu: Kimlik ve erişim uygulama ve yönetme
- Koşullu Erişim nedir?
- Sık Kullanılan Koşullu Erişim ilkeleri