Koşullu Erişimde Zamana Dayalı Kısıtlamaları Etkinleştirme

Bir kullanıcının etki alanına bağlı sistemlere erişimini kısıtlama yeteneği, Active Directory şemasındaki Oturum Açma Saatleri özniteliğinin kullanılması yoluyla Windows 2000 sunucusundan bu yana Active Directory'nin bir özelliği olmuştur.

Yıllar geçtikçe bunda pek bir şey değişmedi, basit bir işlev sağlıyor, oysa bir kullanıcı izin verilen saatler dışında sistemlerine giriş yapmaya çalışırsa, bu giriş reddedilecek.

Şu anda Microsoft Entra'nın ne olduğuna bakıldığında, bazı profesyoneller benzer şekilde adlandırılan iki hizmet arasında özellik eşitliği eksikliğinden şikayet ederken, bazıları kimlik ve erişime yönelik modern çalışma yaklaşımını coşkuyla benimsiyor. Temel olarak, şirket içi ve bulut tabanlı kimlik çözümleri, kimlik ve erişim yönetimi hizmetleri sunmak için aynı temel üzerinde çalışır, ancak bunların uygulamaları oldukça farklıdır ve bunun için iyi bir nedeni vardır.

Ne yazık ki bugüne kadar Microsoft Entra'da (eski adıyla Azure Active Directory) zamana dayalı erişim kontrolüne benzer bir çözüm henüz mevcut değil. Bununla birlikte, Microsoft Entra'da da benzer kontrollerin olması ihtimali hoş bir düşünce, çünkü zaman dilimlerini değiştirme ve basit kaçınma tekniklerinin zorluğu Microsoft'un çözemeyeceği kadar külfetli değil. Bu yazıda beni bir şeylerin değişmekte olduğuna inandıran bazı bulguları inceleyeceğim.

Koşullu Erişim aracılığıyla olası zamana dayalı kısıtlamaların belirlenmesi

Şu anda, Microsoft'tan Koşullu Erişim'de zaman bazlı kısıtlamalar üzerinde çalıştıklarına dair herhangi bir duyuru veya hatta bir şaka yapılmadı; bunların tümü kamuya açık olan bilgiler etrafında yapılan spekülasyonlardır.

Microsoft Entra yönetim merkezindeki Koşullu Erişim sihirbazı aracılığıyla erişimi zamana/güne dayalı olarak kontrol edecek böyle bir ayarın mevcut olmadığı açıktır, ancak Microsoft Graph'ı kontrol edersek ne olur?

Koşullu Erişim ilkelerim (https://graph.microsoft.com/beta/policies/conditionalAccessPolicies) için Beta uç noktasına basit bir GET isteğinde bulunarak, < adı verilen boş bir özelliğin döndürüldüğünü görebiliriz. güçlü>zamanlar.

Elbette bu çok da abartılacak bir şey değil. Twitter ve Reddit gibi sosyal medya forumlarında bazı soruların sorulması, bu mülkle nasıl etkileşime geçileceği ve bunun ne için olabileceği konusunda daha fazla spekülasyona yol açtı; yalnızca beta uç noktasında mevcut olmasına rağmen hala halka açık olarak iade ediliyor. Çoğu durumda açıklanamayan hataları önlemek için Microsoft Graph'ın GA sürümünün (v1.0) önerilmesine rağmen, birçok Microsoft belgesinde ve önerisinde beta uç noktasının hala kullanıldığı/gerekli olduğu ve bunun da şu soruyu gündeme getirdiği için bunu belirtiyorum: bu bilgiler neden iade ediliyor?

Henüz kullanmadıysanız Microsoft Graph Explorer aracı nasıl kullanılır hakkındaki rehberimi takip edin. Bu, herhangi bir PowerShell kullanıcısı için izinleri bulmanıza, kod örneklerini bulmanıza ve komut dosyaları yazmanıza yardımcı olacak harika bir araçtır!

Koşullu Erişimde olası zaman ayarları

Microsoft Graph'ın Koşullu Erişim politikalarına verdiği yanıttaki ayrıntıları belirlemenin başka bir yolu da Chromium web tarayıcılarındaki (örneğin Edge veya Google Chrome) geliştirici araçlarıdır. Bu, blog yazımda çok fazla ayrıntıya girdiğim bir konu: PowerShell ile Invoke-MgGraphRequest Nasıl Kullanılır.

Özetlemek gerekirse, portalda değişiklik yaparken Microsoft Graph yanıtlarını ve yüklerini görüntülemek için bu web tarayıcısında yerleşik olarak bulunan ağ araçlarını inceleme özelliğini kullanabilirsiniz. Daha sonra bu bilgiyi bir dahaki sefere aynı değişikliği programlı olarak yapmak için kullanabilirsiniz.

Özellikle, yeni bir Koşullu Erişim politikası oluştururken kaydet'e tıklayıp değişiklik isteğimin görünmesini bekledikten sonra, önceden bir doğrulama isteğinin gerçekleştiğini fark ettim:

Bu isteğin yükünü görüntüledikten sonra, doğrulama amacıyla şablonlu/örnek verileri ve bu durumda zaman tabanı koşullarının verilerini ve biçimini nasıl ayrıştırdığını görebilirsiniz:

Bu veriler uygun şekilde biçimlendirilmiş JSON'da aşağıdaki gibi görünür. Tarih aralığı, daysOfWeek, startTime & endTime, timezoneID< gibi bazı önemli değerleri not edin. ve isExcludeSet. Bu değerlerin her biri gelecekteki ayarların göstergesi olabilir.

"time": {
      "applyCondition": false,
      "all": 0,
      "included": {
        "dateRange": {
          "startDateTime": "2023-8-16 0:0:0",
          "endDateTime": "2023-8-17 0:0:0"
        },
        "daysOfWeek": {
          "allDay": false,
          "day": [
            0,
            1,
            2,
            3,
            4,
            5,
            6
          ],
          "startTime": "2023-8-16 0:0:0",
          "endTime": "2023-8-17 0:0:0"
        },
        "timezoneId": "",
        "type": 0,
        "isExcludeSet": false
      },
      "excluded": {
        "dateRange": {
          "startDateTime": "2023-8-16 0:0:0",
          "endDateTime": "2023-8-17 0:0:0"
        },
        "daysOfWeek": {
          "allDay": false,
          "day": [
            0,
            1,
            2,
            3,
            4,
            5,
            6
          ],
          "startTime": "2023-8-16 0:0:0",
          "endTime": "2023-8-17 0:0:0"
        },
        "timezoneId": "",
        "type": 0,
        "isExcludeSet": false
      }
},

Çözüm

Ne yazık ki, genel Graph API tarafından açığa çıkan parametreler yalnızca tahmin edilebilir. Bu ayarlar bir ihtimal mi yoksa Microsoft'ta aktif olarak geliştiriliyor mu?

Bu yazının yazıldığı tarihte herhangi bir kamu duyurusu yapılmamıştır ve bu yazıda yer alan bilgiler, Microsoft Graph Beta API'sinin yanıtları aracılığıyla sunulan bilgilerden türetilmiştir.

İlgili makaleler