Bu makalede, bağlama duyarlı erişimle ilgili bazı yaygın kullanım alanları açıklanmakta ve temel modda geliştirilen örnek yapılandırmalar paylaşılmaktadır.
Gelişmiş modda geliştirilen (CEL düzenleyicisi kullanılarak) erişim düzeyleriyle ilgili örnekleri Gelişmiş mod için bağlama duyarlı erişim örnekleri sayfasından inceleyebilirsiniz.
Yüklenicilere yalnızca kurumsal ağ üzerinden erişim izni verme
Birçok şirket, kurumsal kaynaklara yüklenici erişimini kısıtlamak istemektedir. Genel destek çağrılarını yanıtlamak için yüklenicilerle işbirliği yapan veya yardım ve çağrı merkezlerinde çalışan şirketler bu duruma örnek olarak verilebilir. Tam zamanlı çalışanlara benzer şekilde, yüklenicilerin de bağlama duyarlı erişim politikaları kapsamına girmeleri için desteklenen lisansları olması gerekir.
Bu örnekte, yükleniciler kurumsal kaynaklara yalnızca belirli bir şirket IP adresi aralığından erişebilirler.
| Erişim düzeyi adı | yüklenici_erişimi |
| Yüklenici, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | IP alt ağı 74.125.192.0/18 |
| Erişim düzeyi ataması | Yüklenicilere yönelik kuruluş birimleri Yüklenicilerin kullandığı tüm uygulamalar |
Bilinen saldırgan IP adreslerinden erişimi engelleme
Şirket kaynaklarının güvenliğinin ihlal edilmesini önlemek için birçok şirket, bilinen yüksek riskli kaynaklara erişimi engellemektedir.
Bu örnekte 74.125.195.105 kodlu IP adresi engellenmiştir. Oturumlar başka bir IP adresinden geliyorsa kullanıcılar kurumsal kaynaklara erişebilir. Birden çok IP adresi ve aralık belirtebilirsiniz.
| Erişim düzeyi adı | yüksekrisk_engelle |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanmıyorsa |
| Koşul 1 özelliği | IP alt ağı 74.125.195.105 |
| Erişim düzeyi ataması | Üst düzey kuruluş birimi Tüm uygulamalar |
Belirli konumlardan erişime izin verme veya erişimi engelleme
Düzenli olarak şirketin uzaktaki ofislerine veya iş ortaklarının ofislerine giden çalışanlarınız varsa kurumsal kaynaklara erişebilecekleri coğrafi konumları belirtebilirsiniz.
Örneğin, bir grup satış temsilcisi Avustralya ve Hindistan'daki müşterileri düzenli olarak ziyaret ediyorsa grubun erişimini merkez ofis, Avustralya ve Hindistan arasında sınırlandırabilirsiniz. Bir iş gezisi sırasında kişisel tatil amacıyla başka ülkelere seyahat ederlerse bu ülkelerden kurumsal kaynaklara erişemezler.
Bu örnekte, satış temsilcileri kurumsal kaynaklara yalnızca ABD'den (merkez ofis), Avustralya'dan ve Hindistan'dan erişebilir.
| Erişim düzeyi adı | satış_erişimi |
| Satış ekibi şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | Coğrafi kaynak ABD, Avustralya, Hindistan |
| Erişim düzeyi ataması | Satış temsilcileri grubu Satış temsilcilerinin kullandığı tüm uygulamalar |
Kullanıcıların koşulları karşılamadıklarında erişim elde edebileceğini belirterek belirli ülkelerden erişimi reddetmek için bir politika oluşturabilirsiniz. Erişimi engellemek istediğiniz ülkeleri listelersiniz.
Atama sırasında birden fazla erişim düzeyi seçmek yerine, iç içe yerleştirilmiş erişim düzeylerini kullanın
Bazı durumlarda, belirli bir kuruluş birimine veya gruba ve bir uygulamaya (veya uygulama grubuna) erişim düzeyleri atamayı denediğinizde uygulama veya erişim düzeyi sayısını azaltmanızı isteyen bir hata mesajı görebilirsiniz.
Bu hatayı önlemek için, atama sırasında kullanılan erişim düzeylerini tek bir erişim düzeyinde iç içe yerleştirerek erişim düzeyi sayısını azaltabilirsiniz. İç içe yerleştirilmiş erişim düzeyi bir OR işlemiyle, her biri tek bir erişim düzeyi içeren birden çok koşulu birleştirir.
Bu örnekte, USWest, USEast ve USCentral, 3 ayrı erişim düzeyindedir. Kullanıcıların, USWest OR USEast OR USCentral erişim düzeylerinin herhangi birinin koşullarını karşılaması durumunda uygulamalara erişebilmelerini istediğinizi varsayalım. OR operatörünü kullanarak iç içe yerleştirilmiş tek bir erişim düzeyi (USRegions) oluşturabilirsiniz. Erişim düzeylerini atama zamanı geldiğinde, kuruluş birimi veya grup için uygulamaya USRegions erişim düzeyini atayın.
|
Erişim düzeyi adı |
USRegions |
|
Kullanıcı, şu koşulda erişim elde eder: |
Özellikler karşılanıyorsa |
|
Koşul 1 özelliği (her koşul için yalnızca 1 erişim düzeyi) |
Erişim düzeyi USWest |
|
Koşul 1 ve koşul 2'yi birleştirme |
OR |
|
Kullanıcı, şu koşulda erişim elde eder: |
Özellikler karşılanıyorsa |
|
Koşul 2 özelliği |
Erişim düzeyi USEast |
|
Koşul 2 ve koşul 3'ü birleştirme |
OR |
|
Kullanıcı, şu koşulda erişim elde eder: |
Özellikler karşılanıyorsa |
|
Koşul 3 özelliği |
Erişim düzeyi USCentral |
Masaüstü cihazların şirket cihazı olmasını zorunlu kılma ancak mobil cihazları bu kuraldan hariç tutma
Şirketler, masaüstü cihazlar söz konusu olduğunda şirkete ait cihazların kullanılmasını zorunlu kılarken kişisel mobil cihazların kullanımına izin verebilir.
İlk önce masaüstü cihazlar için bir erişim düzeyi oluşturun:
|
Erişim düzeyi adı |
masaüstü_erişimi |
|
Kullanıcılar, şu koşulda erişim elde eder: |
Özellikler karşılanıyorsa |
|
Koşul 1 özelliği |
Cihaz politikası
Cihaz şifrelemesi = Desteklenmiyor Cihaz OS macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
Ardından, mobil cihazlar için bir erişim düzeyi oluşturun:
|
Erişim düzeyi adı |
mobil_erişimi |
|
Kullanıcılar, şu koşulda erişim elde eder: |
Özellikler karşılanıyorsa |
|
Koşul 1 özelliği |
Cihaz OS iOS = 0.0.0 Android = 0.0.0 |
Temel cihaz güvenliğini zorunlu kılma
Günümüzde kurumsal şirketlerin çoğu, çalışanların şirket kaynaklarına erişmesi için şifrelenmiş ve minimum işletim sistemi sürümü şartlarını karşılayan cihazları zorunlu kılmaktadır. Bazıları çalışanların şirkete ait cihazları kullanmasını da zorunlu kılar.
Bu politikaları tüm kuruluş birimleriniz veya şirket yöneticileri, finans veya insan kaynakları gibi hassas verilerle çalışan kuruluş birimleri için yapılandırabilirsiniz.
Cihaz şifrelemesini, minimum işletim sistemi sürümünü ve şirkete ait cihazları içeren bir politikayı yapılandırmak için kullanabileceğiniz birkaç yöntem vardır. Bunların her birinin avantajları ve dezavantajları vardır.
Tüm güvenlik şartlarını karşılayan 1 erişim düzeyi
Örneğin, bir kullanıcı cihazı şifrelenmişse ve şirkete aitse ancak işletim sisteminin uyumlu bir sürümünü çalıştırmıyorsa erişim reddedilir.
Avantaj: Kurulumu kolaydır. Bir uygulamaya bu erişim düzeyini atadığınızda, kullanıcının tüm şartları karşılaması gerekir.
Dezavantaj: Farklı kuruluş birimlerine güvenlik şartlarını ayrı ayrı atamak için her bir güvenlik şartına ayrı bir erişim düzeyi oluşturmanız gerekir.
| Erişim düzeyi adı | cihaz_güvenliği |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği (Tüm özellikleri bir koşula ekleyebilir veya 3 koşul oluşturup bunları AND ile birleştirebilirsiniz.) |
Cihaz OS |
3 ayrı erişim düzeyi
Örneğin, şifrelenmiş cihazı olan ve işletim sisteminin eski bir sürümünü kişisel bir cihazda çalıştıran bir kullanıcı erişim elde edebilir.
Avantaj: Erişim düzeylerini tanımlamanın ayrıntılı bir yoludur. Farklı kuruluş birimlerine ayrı erişim düzeyleri atayabilirsiniz.
Dezavantaj: Kullanıcılar bu koşulları yalnızca tek bir erişim düzeyinde karşılamalıdır.
| Erişim düzeyi adı | cihaz_şifreleme |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği |
Cihaz politikası |
| Erişim düzeyi adı | kurumsal_cihaz |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği |
Cihaz politikası |
| Erişim düzeyi adı | min_os |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği |
Cihaz politikası |
İç içe erişim düzeylerine sahip 1 erişim düzeyi
Uygulamalara dördüncü erişim düzeyini atadığınızda, kullanıcıların erişim elde etmek için iç içe yerleştirilmiş 3 erişim düzeyinin her birindeki koşulları karşılaması gerekir. Bu, erişim düzeyleri için mantıksal bir AND işlemidir.
Örneğin, şifrelenmiş cihazı olan ve işletim sisteminin eski bir sürümünü kişisel bir cihazda çalıştıran bir kullanıcının erişimi reddedilir.
Avantaj: Erişim düzeyi 1, 2 ve 3'te güvenlik şartlarını birbirinden ayırma esnekliğini korursunuz. 4. erişim düzeyini kullanarak, tüm güvenlik şartlarını karşılayan bir politikayı da zorunlu kılabilirsiniz.
Dezavantaj: Denetleme günlüğü, erişim düzeyi 1, 2 ve 3 uygulamalara doğrudan atanmadığı için erişim düzeyi 4'e (erişim düzeyi 1, 2 ve 3'e değil) reddedilen erişimleri yakalar.
Yukarıda "3 ayrı erişim düzeyi" bölümünde açıklandığı şekilde 3 erişim düzeyi oluşturun: "cihaz_şifreleme," "kurumsal_cihaz," ve "min_os." Ardından, 3 koşulu olan ve "cihaz_güvenliği" adı verilen dördüncü bir erişim düzeyi oluşturun. Her koşul, özellik olarak bir erişim düzeyine sahiptir. (Her koşul için yalnızca 1 erişim düzeyi özelliği ekleyebilirsiniz.)
| Erişim düzeyi adı | cihaz_güvenliği |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği (koşul başına yalnızca 1 erişim düzeyi) |
Erişim düzeyi cihaz_şifreleme |
| Koşul 1 ve koşul 2'yi birleştirme | AND |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | Erişim düzeyi kurumsal_cihaz |
| Koşul 2 ve koşul 3'ü birleştirme | AND |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | Erişim düzeyi min_os |