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ı | contractor_access |
| Yüklenici, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | IP alt ağı (Genel) 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ı | block_highrisk |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanmıyorsa |
| Koşul 1 özelliği | IP alt ağı (Genel) 74.125.195.105 |
| Erişim düzeyi ataması | Üst düzey kuruluş birimi Tüm uygulamalar |
Google Cloud'da belirli bir özel ağdan erişime izin verme
Birçok şirket, kullanıcı trafiğini Sanal Özel Bulut (VPC) üzerinden Google'a yönlendirir. VPC, Google Cloud ortamındaki güvenli ve izole edilmiş bir ağdır.
VPC'niz üzerinden yönlendirilen trafiğin özel IP adresleri kullanabileceğini unutmayın. Bu durum, genel IP veya bölge politikalarıyla ilgili sorunlara yol açabilir.
Bu örnekte, bu belirli VPC'lerden gelen trafiğe izin verebilirsiniz.
| Erişim düzeyi adı | vpc_access |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| condition [durum] özellikleri için aynı değerleri kullanıyor. |
IP alt ağı (Özel) Özel IP alt ağı: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC alt ağı: 74.125.192.0/18 |
| Erişim düzeyi ataması |
Tüm kullanıcılar için kuruluş birimleri Yüklenicilerin kullandığı tüm uygulamalar |
Dikkate alınması gereken noktalar:
- Yalnızca doğrudan trafik: Bu erişim düzeyi yalnızca izin verilenler listesindeki VPC'den Google'ın sunucularına doğrudan ulaşan trafik için geçerlidir. Trafik önce başka bir ağdan veya tünelden geçiyorsa erişim izni verilmez. Google yalnızca trafiği sunucularına gönderen son VPC'yi tanır.
- Yönetici izinleri: Yöneticilerin VPC'leri görüntüleyip bu erişim düzeyini yapılandırabilmesi için uygun Kimlik ve Erişim Yönetimi (IAM) rolüne (ör. compute.networks.list, compute.subnetworks.list vb.) sahip olması gerekir.
- Harici VPC'ler: İzin verilenler listenize eklediğiniz VPC, mevcut Google Cloud alanınızın dışında olabilir. Harici VPC'yi eklemek için yöneticinin görüntüleme izni olmalıdır.
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ı | sales_access |
| 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 |
VEYA |
|
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 |
VEYA |
|
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ı |
aldesktop_access |
|
Kullanıcılar, şu koşulda erişim elde eder: |
Özellikler karşılanıyorsa |
|
Koşul 1 özelliği |
Cihaz politikası
Cihaz şifreleme = 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ı |
almobile_access |
|
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 ya da insan kaynakları gibi hassas verilerle çalışan kuruluş birimleri için yapılandırabilirsiniz.
Cihaz şifrelemeyi, 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
Bu örnekte, cihaz şifreleme, minimum işletim sistemi sürümü ve şirkete ait cihaz özellikleri tek bir erişim düzeyinde yer almaktadır. Erişim sağlamak için kullanıcıların tüm koşulları karşılaması gerekir.
Ö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ı | device_security |
| 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 politikası Cihaz OS |
3 ayrı erişim düzeyi
Bu örnekte, cihaz şifreleme, minimum işletim sistemi sürümü ve şirkete ait cihaz özellikleri 3 ayrı erişim düzeyindedir. Kullanıcıların erişim sağlamak için yalnızca bir erişim düzeyindeki koşulları karşılaması gerekir. Bu, erişim düzeyleri için mantıksal bir OR 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ı 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ı | device_encryption |
| 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ı | corp_device |
| 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
Bu örnekte, cihaz şifreleme, minimum işletim sistemi sürümü ve şirkete ait cihaz güvenlik şartları 3 ayrı erişim düzeyindedir. Bu 3 erişim düzeyi, dördüncü erişim düzeyinde iç içe yerleştirilmiştir.
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ıdaki "3 ayrı erişim düzeyi" bölümünde açıklandığı şekilde 3 erişim düzeyi oluşturun: "device_encryption", "corp_device" 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ı | device_security |
| 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 device_encryption |
| Koşul 1 ve koşul 2'yi birleştirme | VE |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | Erişim düzeyi corp_device |
| Koşul 2 ve koşul 3'ü birleştirme | VE |
| Kullanıcı, şu koşulda erişim elde eder: | Özellikler karşılanıyorsa |
| Koşul 1 özelliği | Erişim düzeyi min_os |