Koşullu Erişim çerçevesi ve ilkeleri
Bu makalede, Koşullu Erişim Sıfır Güven mimarisinde açıklanan gibi kişi tabanlı Koşullu Erişim mimarisini uygulamaya yönelik bir çerçeve sağlanır. Bu makalede, Koşullu Erişim ilkelerinin nasıl oluşturulacağı ve adlandıracağı hakkında ayrıntılar yer alır. İlke oluşturmak için de bir başlangıç noktası vardır.
Adlandırma standardı dahil olmak üzere burada sağlanan çerçeve gibi bir çerçeve kullanmıyorsanız, ilkeler zaman içinde farklı kişiler tarafından geçici bir şekilde oluşturulma eğilimindedir. Bu, çakışan ilkelere neden olabilir. İlkeyi oluşturan kişi artık kullanılamıyorsa, başkalarının ilkenin amacını bilmesi zor olabilir.
Yapılandırılmış bir çerçeveyi takip etmek, ilkelerin anlaşılmasını kolaylaştırır. Ayrıca tüm senaryoları kapsamayı ve sorun gidermesi zor olan çakışan ilkelerden kaçınmayı kolaylaştırır.
Adlandırma kuralları
Düzgün tanımlanmış bir adlandırma kuralı, sizin ve iş arkadaşlarınızın ilkenin amacını anlamasına yardımcı olur ve bu da ilke yönetimini ve sorun gidermeyi kolaylaştırır. Adlandırma kuralınız, ilkelerinizi yapılandırmak için kullandığınız çerçeveye uygun olmalıdır.
Önerilen adlandırma ilkesi, kişilikleri, ilke türlerini ve uygulamaları temel alır. Şunun gibi görünür:
<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Bu adın bileşenleri burada açıklanmıştır:
| Adlandırma bileşeni | Açıklama/Örnek |
|---|---|
| CA Numarası | İlke Türü kapsamını ve sırasını hızla tanımlamak için kullanılır. Örnek: CA001-CA099. |
| Kişilik | Global, Yönetici s, Internals, Externals, GuestUsers, Guest Yönetici s, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Politika Türü | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| Uygulama | AllApps, O365 (tüm Office 365 hizmetleri için), EXO (Exchange Online için). |
| Platform | AnyPlatform, Unknown, Windows Telefon, macOS, iOS, Android. |
| Denetim Ver | Block, ADHJ, Uyumlu, Yönetilmeyen (yönetilmeyen, cihaz durumu koşulunda belirtilir). |
| Açıklama | İlkenin amacının isteğe bağlı açıklaması. |
Numaralandırma düzeni
Yönetimi kolaylaştırmak için şu numaralandırma düzenini öneririz:
| Kişi grubu | Numara ayırma |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Yönetici s | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-Guest Yönetici s | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadId varlıkları | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Politika tipleri
Önerilen ilke türleri şunlardır:
| Politika türü | Açıklama/Örnekler |
|---|---|
| BaseProtection | Her kişilik için, bu ilke türünün kapsamına alınan bir temel koruma vardır. Yönetilen cihazlardaki kullanıcılar için bu genellikle bilinen kullanıcı ve bilinen cihazdır. Dış konuklar için bilinen kullanıcı ve çok faktörlü kimlik doğrulaması olabilir. Temel koruma, belirli bir kişilikteki kullanıcılar için tüm uygulamalar için varsayılan ilkedir. Belirli bir uygulamanın farklı bir ilkesi olması gerekiyorsa, bu uygulamayı temel koruma ilkesinden hariç tutun ve yalnızca bu uygulamayı hedefleyen açık bir ilke ekleyin. Örnek: İç cihazlar için temel korumanın tüm bulut uygulamaları için bilinen kullanıcı ve bilinen cihaz gerektirdiğini, ancak herhangi bir cihazdan Web üzerinde Outlook izin vermek istediğinizi varsayalım. Exchange Online'ı temel koruma ilkesinden dışlayabilir ve Exchange Online için bilinen cihaz veya çok faktörlü kimlik doğrulaması gerektiren ayrı bir ilke ekleyebilirsiniz. |
| IdentityProtection | Her kişilik için temel korumanın üzerine, kimlikle ilgili Koşullu Erişim ilkelerine sahip olabilirsiniz. Örnekler: Eski kimlik doğrulamasını engelleme, yüksek kullanıcı veya oturum açma riski için fazladan çok faktörlü kimlik doğrulaması gerektirme, çok faktörlü kimlik doğrulama kaydı için bilinen cihaz gerektirme. |
| Dataprotection | Bu ilke türü, temel korumanın üzerinde ek katman olarak verileri koruyan delta ilkelerini gösterir. Örnekler:
|
| AppProtection | Bu ilke türü, temel korumaya bir başka eklemedir. Örnekler:
|
| AttackSurfaceReduction | Bu tür bir ilkenin amacı, çeşitli saldırıları azaltmaktır. Örnekler:
|
| Uyumluluk | Bir kullanıcının müşteri hizmetlerine erişen konukların kullanım koşullarını görüntülemesini istemek için bir uyumluluk ilkesi kullanabilirsiniz. |
Uygulama
Aşağıdaki tabloda bir ilke adının Uygulama bileşeni açıklanmaktadır:
| Uygulama adı | Açıklama/Örnekler |
|---|---|
| AllApps | AllApps, koşullu erişim ilkesinde tüm bulut uygulamalarının hedeflendiğini gösterir. Koşullu Erişimi destekleyenler ve desteklemeyenler de dahil olmak üzere tüm uç noktalar ele alınmıştır. Bazı senaryolarda tüm uygulamaları hedefleme iyi çalışmaz. Tüm uç noktaların bu ilke kapsamında olması için temel ilkedeki tüm uygulamaları hedeflemenizi öneririz. Microsoft Entra Id'de görünen yeni uygulamalar da ilkeye otomatik olarak bağlı kalır. |
| <AppName> | <AppName> , ilkenin ele alan bir uygulamanın adı için yer tutucudur. Adı çok uzun yapmaktan kaçının. Örnek adlar:
|
Platform türü
Aşağıdaki tabloda, bir ilke adının Platform bileşeni açıklanmaktadır:
| Platform türü | Açıklama |
|---|---|
| AnyPlatform | İlke tüm platformları hedefler. Bunu genellikle Herhangi Bir Cihaz'ı seçerek yapılandırabilirsiniz. (Koşullu Erişim ilkelerinde hem platform hem de cihaz sözcüğü kullanılır.) |
| iOS | İlke, Apple iOS platformlarını hedefler. |
| Android | İlke, Google Android platformlarını hedefler. |
| Windows | Bu ilke Windows platformlarını hedefler. |
| Linux | Bu ilke Linux platformlarını hedefler. |
| Windows Telefon | İlke, Windows Telefon platformlarını hedefler. |
| macOS | İlke macOS platformlarını hedefler |
| iOSAndroid | İlke hem iOS hem de Android platformlarını hedefler. |
| Bilinmiyor | İlke, daha önce listelenmeyen tüm platformları hedefler. Bunu genellikle Herhangi Bir Cihaz'ı dahil ederek ve tek tek tüm platformları hariç tutarak yapılandırabilirsiniz. |
Denetim türleri verme
Aşağıdaki tabloda, bir ilke adının Grant Control bileşeni açıklanmaktadır:
| Verme türü | Açıklama/Örnekler |
|---|---|
| öğesini engelle | İlke oturum açmayı engeller |
| Çok faktörlü kimlik doğrulaması | İlke çok faktörlü kimlik doğrulaması gerektirir. |
| Uyumlu | İlke, Endpoint Manager tarafından belirlenen uyumlu bir cihaz gerektirir, bu nedenle cihazın Endpoint Manager tarafından yönetilmesi gerekir. |
| CompliantorAADHJ | İlke uyumlu bir cihaz veya Microsoft Entra karma katılmış bir cihaz gerektirir. Etki alanına katılmış standart bir şirket bilgisayarı da Karma Microsoft Entra Kimliği'ne katılmıştır. Ortak yönetilen veya Microsoft Entra'ya katılmış cep telefonları ve Windows 10 bilgisayarları uyumlu olabilir. |
| UyumluandAADHJ | İlke, uyumlu ve Microsoft Entra karmaya katılmış bir cihaz gerektirir. |
| MFAorCompliant | İlke uyumlu bir cihaz veya uyumlu değilse çok faktörlü kimlik doğrulaması gerektirir. |
| MFAandCompliant | İlke uyumlu bir cihaz ve çok faktörlü kimlik doğrulaması gerektirir. |
| MFAorAADHJ | İlke, Microsoft Entra karma katılmış bir bilgisayar değilse Microsoft Entra karma katılmış bilgisayar VEYA çok faktörlü kimlik doğrulaması gerektirir. |
| MFAandAADHJ | İlke, Microsoft Entra karma katılmış bir bilgisayar VE çok faktörlü kimlik doğrulaması gerektirir. |
| RequireApprovedClient | İlke, onaylı istemci uygulaması gerektirir. |
| AppProtection | İlke için uygulama koruması gerekir |
| Yönetilmeyen | İlke, Microsoft Entra Id tarafından bilinmeyen cihazları hedefler. Örneğin, herhangi bir cihazdan Exchange Online'a erişime izin vermek için bu izin türünü kullanabilirsiniz. |
Adlandırılmış konumlar
Koşullu Erişim ilkelerinde kullanmak üzere bu standart konumları tanımlamanızı öneririz:
- Güvenilen IP'ler / İç ağlar. Bu IP alt ağları, fiziksel erişim kısıtlamalarına veya bilgisayar sistemi yönetimi, ağ düzeyinde kimlik doğrulaması veya yetkisiz erişim algılama gibi diğer denetimlere sahip konumları ve ağları temsil eder. Bu konumlar daha güvenlidir, bu nedenle Koşullu Erişim zorlaması gevşetilebilir. Azure'ın mı yoksa diğer veri merkezi konumlarının mı (IP'ler) bu konuma dahil edilmesi gerektiğini yoksa kendi adlandırılmış konumlarına mı sahip olacağını göz önünde bulundurun.
- Citrix tarafından güvenilen IP'ler. Şirket içinde Citrix varsa, Citrix oturumlarından bulut hizmetlerine bağlanabilmeniz gerekiyorsa Citrix grupları için ayrı giden IPv4 adresleri yapılandırmak yararlı olabilir. Bu durumda, gerekirse bu konumları Koşullu Erişim ilkelerinin dışında tutabilirsiniz.
- Varsa Zscaler konumları. Bilgisayarlarda bir ZPA aracısı yüklüdür ve tüm trafiği İnternet'e veya Zscaler bulutu aracılığıyla iletir. Bu nedenle, Koşullu Erişim'de Zscaler kaynak IP'lerini tanımlamaya ve mobil olmayan cihazlardan gelen tüm isteklerin Zscaler üzerinden gönderilmesini gerektirmeye değer.
- İşletmelere izin verebileceğiniz ülkeler/bölgeler. Ülkeleri/bölgeleri iki konum grubuna bölmek yararlı olabilir: dünyanın çalışanlarının genellikle çalıştığı alanları temsil eden ve diğer konumları temsil eden bölgeler. Bu, kuruluşunuzun normalde çalıştığı alanların dışından gelen isteklere ek denetimler uygulamanıza olanak tanır.
- Çok faktörlü kimlik doğrulamasının zor veya imkansız olabileceği konumlar. Bazı senaryolarda, çok faktörlü kimlik doğrulaması gerektirmek çalışanların işlerini yapmasını zorlaştırabilir. Örneğin, personel sık karşılaşılan çok faktörlü kimlik doğrulama zorluklarına yanıt vermek için zaman veya fırsata sahip olmayabilir. Alternatif olarak, bazı konumlarda RF filtreleme veya elektriksel girişim mobil cihazların kullanımını zorlaştırabilir. Genellikle bu konumlarda başka denetimler kullanırsınız veya bu denetimlere güvenilebilir.
Konum tabanlı erişim denetimleri, istek sırasında kullanıcının konumunu belirlemek için isteğin kaynak IP'sini kullanır. Genel İnternet'te kimlik sahtekarlığı yapmak kolay değildir, ancak ağ sınırları tarafından karşılanan korumanın bir öncekinden daha az ilgili olduğu düşünülebilir. Erişim koşulu olarak yalnızca konumu kullanmanızı önermeyiz. Ancak bazı senaryolarda, etkileşimli olmayan bir senaryoda kullanılan şirket içi bir hizmet hesabından erişimi güvenli hale getirmek gibi kullanabileceğiniz en iyi denetim olabilir.
Önerilen Koşullu Erişim ilkeleri
Önerilen Koşullu Erişim ilkelerini içeren bir elektronik tablo oluşturduk. Elektronik tabloyu buradan indirebilirsiniz.
Önerilen ilkeleri başlangıç noktası olarak kullanın.
İlkeleriniz büyük olasılıkla işletmeniz için önemli olan kullanım örneklerini barındıracak şekilde zaman içinde değişecektir. Değişiklik gerektirebilecek senaryolara birkaç örnek aşağıda verilmiştir:
- Çok faktörlü kimlik doğrulaması, uygulama koruması ve onaylı bir istemci uygulaması temelinde yönetilmeyen tüm cihazları kullanarak çalışanlar için Exchange Online'a salt okunur erişim uygulayın.
- Azure Information Protection tarafından sağlanan gelişmiş koruma olmadan hassas bilgilerin indirilmamasını sağlamak için bilgi koruması uygulayın.
- Konuklar tarafından kopyalanıp yapıştırılanlara karşı koruma sağlayın.
Şu anda genel önizleme aşamasında olan birden çok önizleme olduğundan, yakında önerilen Koşullu Erişim (CA) başlangıç ilkeleri kümesinde güncelleştirmeler yapılmasını bekleyebilirsiniz.
Koşullu Erişim kılavuzu
Artık bir başlangıç koşullu erişim ilkeleri kümeniz olduğuna göre, bunları denetimli ve aşamalı bir şekilde dağıtmanız gerekir. Dağıtım modeli kullanmanızı öneririz.
İşte bir yaklaşım:
İlk fikir, ilkeleri bir kişilik grubu içindeki az sayıda kullanıcıya dağıtmaktır. Bu dağıtım için Persona Ring 0 adlı ilişkili bir Microsoft Entra grubu kullanabilirsiniz. Her şeyin çalıştığını doğruladıktan sonra, ödevi daha fazla üyesi olan bir grup olan Persona Ring 1 olarak değiştirirsiniz.
Ardından, tüm ilkeler dağıtılana kadar aynı halka tabanlı yaklaşımı kullanarak ilkeleri etkinleştirirsiniz.
Genellikle halka 0 ve halka 1'in üyelerini el ile yönetirsiniz. Yüzlerce, hatta binlerce kullanıcı içeren halka 2 veya 3 grubu, belirli bir kişilikteki kullanıcıların yüzdesini temel alan bir dinamik grup aracılığıyla yönetilebilir.
Bir dağıtım modelinin parçası olarak halkaların kullanılması yalnızca ilk dağıtım için değildir. Yeni ilkeler veya mevcut ilkelerde değişiklik yapılması gerektiğinde de bunu kullanabilirsiniz.
Tamamlanmış bir dağıtımla, Koşullu Erişim ilkeleri'nde ele alınan izleme denetimlerini de tasarlamanız ve uygulamanız gerekir.
İlk dağıtımı otomatikleştirmeye ek olarak, CI/CD işlem hatlarını kullanarak ilkelerdeki değişiklikleri otomatikleştirmek isteyebilirsiniz. Bu otomasyon için Microsoft365DSC kullanabilirsiniz.
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.