Neler değişti

Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.

Sürüm 10 → 11

Güncelleme

Atamalar, onaylar ve yönetişim üzerine yeni modül: uygulamalara SCIM gönderimi, grup üyelikleri ve dizine geri yazma, organizasyon şeması içe aktarımı, onay kuyrukları, vekâlet ve sahipler, erişim paketleri ve sertifikasyon kampanyaları. Bu konular MCSA sınavında yer alıyor ve daha önce anlatılmıyordu.

3 ders güncellendi

İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.

Uygulamalara SCIM gönderimi

Üreticisi standart `/Users` ve `/Groups` uç noktaları sunan bir uygulama SCIM 2.0 konuşur. Böyle bir uygulama için konnektör gerekmez: Applications → uygulama → `Provisioning` sekmesi → `SCIM` sekmesi, uygulamaya atanmış kişileri gönderir. Böylece hesap, kullanıcı atandığında oluşur ve atama bittiğinde kalkar. ### Yön: Monosign istemcidir Monosign, uygulamanın SCIM uç noktasını çağırır. **Kendi SCIM uç noktası yoktur**; bu yüzden Microsoft Entra ID gibi başka bir kimlik sistemi kullanıcıları SCIM ile Monosign'a gönderemez. Kimlikleri içeri almak için bir kullanıcı kaynağı kullanın: dizin konnektörü ya da içe aktarma. Önceki dersteki `SCIM Entitlement Provider` da bir istemcidir; karşı sistemin SCIM uç noktasını okur. ### Ayarlar - `Enable Provisioning`: ana anahtar. Kapalıyken hiçbir çağrı yapılmaz. - `API Url` ve `API Key`: SCIM taban adresi ve bearer belirteci. - `Enable Auto-sync` ve `Timing`: saatlik ya da günlük, UTC ile zamanlanmış gönderim. `Force Sync` hemen bir gönderim çalıştırır. - Bir kullanıcı uygulamaya elle ya da bir kuralla atandığında veya uygulamadan çıkarıldığında da gönderim hemen çalışır. ### Gönderim kullanıcılara ne yapar Yeni atama önce hedefte aranır, sonra `POST /Users` ile oluşturulur ya da `PUT /Users/{id}` ile güncellenir. **Pasif hale gelen atama** `DELETE /Users/{id}` ile **silinir**. Monosign hiçbir zaman `active = false` göndermez; atama yeniden etkinleştirildiğinde hedef, **yeni bir SCIM kimliği** ile yeni bir hesap oluşturur. Uygulama bir kullanıcının geçmişini yalnızca hesap var olduğu sürece tutuyorsa, ayrılan kişinin ataması değişmeden önce bu geçmişin nasıl dışa aktarılacağını uygulama sahibiyle kararlaştırın. ::diagram lc-scim-push-lifecycle Varsayılan profilinde adı (first name) boş olan kullanıcı, hiçbir ileti olmadan atlanır. Hedefte tek bir kişi eksikse profilini kontrol edin. ### Gönderim gruplara ne yapar Eşlediğiniz `Groups`, SCIM grupları olarak gönderilir. Gönderim ardından **hedefte, eşlenen gruplardan biri olmayan her grubu siler**; uygulamanın kendi yöneticilerinin oluşturduğu gruplar da buna dahildir. `externalId` değeri GUID olmayan bir hedef grup, grup adımının tamamını durdurur. Zaten grupları olan bir uygulamada grup gönderimini açmadan önce o grupları listeleyin ve hangilerinin Monosign'a ait olacağına karar verin. ### Bir şey başarısız olduğunda SCIM gönderimleri Reports → `Provisions` altında listelenmez. Tek iz servis günlüğüdür: durum kodu ve yanıt gövdesiyle birlikte `SCIM API returned error` gibi bir satır arayın. Bir sonraki zamanlanmış çalışma yeniden dener. ### Provision servisleri ve kullanıcı verisi Bazı entegrasyonlar SCIM yerine kuralları olan bir provision servisi kullanır. `User Provisioning Service` her kullanıcıyı bu kurallara göre değerlendirir. **E-posta adresi olmayan, etkin olmayan ya da durumu `Enabled` olmayan kullanıcıyı hiçbir kuralla eşleşmiyor sayar** ve bu, kullanıcının erişiminin geri alınmasına yol açar. Dizinden içe aktarmanın ardından, bu kullanıcılar değerlendirilmeden önce e-posta özniteliğini doldurun. > İpucu: İlk gönderimi uygulamanın bir test ortamına karşı çalıştırın. Hedefteki bir silme işlemi Monosign'dan geri alınamaz. ::shot lc-provisions

Onaylar, vekâlet ve sahipler

Önleyici tetikler ve erişim talepleri, bir atamanın yoluna insanları koyar. Doğru kişinin talebi zamanında görüp görmeyeceğini üç şey belirler. ### Bekleyen atama nerede durur `Require approval` kararlı bir tetikte kişilerin haberdar edilmesi için `Approval workflow` gerekir. Alan boşsa talep **elle işlenen bir kuyruğa** gider: tetiğin `Approvals` sekmesinde görünür ve kimseye haber verilmez. Erişim ancak `Approve` sonrasında verilir. Ya bir iş akışı seçin ya da o sekmeye bakmayı birinin düzenli işi haline getirin. ### Bir adımda kim işlem yapabilir Bir iş akışı adımı kişilere ya da `Group Approval` ile gruplara atanabilir. Grup adımları, adım her okunduğunda **güncel üyeliğe** göre çözülür. Gruba eklenen kişi hemen işlem yapabilir. Gruptan çıkarılan kişinin `Approvals` gelen kutusundaki `Active` sekmesinden satır hemen kalkar; `History` satırları ise işlemi yapan kişide kalır. Güncel üyelerden herhangi biri adımı tamamlar; boş bir grup adımı bekletir. ### Vekâlet Security → `Delegations`, bir kullanıcının onaylarını belirli bir süre için başka birine devreder: `Assign`, ardından `User (from)`, `Delegated User (to)` ve başlangıç ile bitiş tarihleri. Vekilin atamaları **adım oluşturulurken** eklenir. Sonradan tanımlanan bir vekâlet, zaten beklemekte olan adımlara bağlanmaz; o adımları elle başka bir onaylayıcıya verin. Vekâleti planlı bir izinden önce tanımlayın, iznin ilk gününde değil. ::diagram lc-approval-routing ::shot lc-delegations ### Sahipler Pek çok karar "sahibe" gider, bu yüzden sahiplerin kayıtlı olması gerekir. Governance → `Owners`; bir uygulamanın, kullanıcının, grubun, rolün, iznin, kaynağın ya da yapay zekâ ajanının sahibini `Direct Manager` ya da `Governance Owner` olarak tutar. Grupların, rollerin ve izinlerin kendi sayfalarında ayrıca bir `Owners` sekmesi vardır. **Uygulamalarda yoktur**: uygulama sahibini Governance → `Owners` altından ya da nesne sahipleri API'siyle (`v1.5/object-owners`) atayın. Sertifikasyon kampanyaları gözden geçirenleri bu satırlardan seçer, tetikler de onlara bildirim gönderir. Bir kampanya yalnızca yapılandırıldığı `Owner Type` değerini okur; diğer türle kaydedilmiş bir sahip seçilmez. > İpucu: Bir onay kaybolmuş gibi göründüğünde şu sırayla üç şeye bakın: atanan grubun üyeliği, başka bir üyenin karar verip vermediği ve akışın iptal edilip edilmediği.

Erişim paketleri ve sertifikasyon kampanyaları

Yaşam döngüsü otomasyonu, kişilerin varsayılan olarak ihtiyaç duyduğu erişimi verir. Erişim paketleri kişilerin talep ettiğini karşılar; sertifikasyon kampanyaları ise ellerindeki erişimin hâlâ doğru olduğunu teyit eder. ### Erişim paketleri Governance → `Access Packages`, kişilerin talep edebileceği demetleri tanımlar: bir başlık, bir `Policy`, bir `Lifetime`, onay için isteğe bağlı bir `Workflow` ve tek bir katalogdan kaynaklar. `Assigned Object(s)`, paketi kimin taşıdığını listeler. - **Bir atamayı kaldırmak** (v2026.10), o atamanın onaylanmış talebinin oluşturduğu yetkileri geri alır. Kullanıcının başka bir kaynaktan, örneğin doğrudan rol atamasından gelen erişimi kalır. Reddedilen bir geri alma günlüğe yazılır. - **Politika kullanımdayken kilitlidir.** Bir paketin başvurduğu politika tanımı ne devre dışı bırakılabilir ne de kaldırılabilir. Önce onu her paketten ayırın. Kaldırma geçici silmedir, geçmiş kalır. ::shot lc-access-packages ### Sertifikasyon kampanyaları Governance → `Certifications` tanımları tutar: neyin gözden geçirileceği, kimin gözden geçireceği, ne sıklıkta ve kaç gün süreyle. Bir servis, zamanı gelen tanımı öğeleri ve gözden geçirenleriyle bir kampanyaya dönüştürür. - **Gözden geçirenler kampanya başlarken belirlenir**; `Reviewer Type` değerine göre: adı verilen kullanıcılar, `User Manager`, bir kural ya da sahipler. Sonradan değişen yönetici ya da sahip, öğeleri taşımaz. Sertifikasyon yöneticisi `Reassign` ya da `Add Reviewer` kullanır. - **Hiçbir şey üst düzeye aktarılmaz.** Tek takip, hatırlatma e-postaları ve elle yeniden atamadır. - **Bitiş tarihi karar vermez.** Tanım kararları `Approve All` ya da `Reject All` ile önceden işaretlemiyorsa, kimsenin gözden geçirmediği öğeler kararsız kalır ve kampanya yalnızca `Completed` olarak işaretlenir. Kampanya sürerken gözden geçirenleri takip edin ve kararsız öğeleri açık bulgu olarak raporlayın. ::diagram lc-campaign-course ### Parçalar nasıl birleşir | İhtiyaç | Araç | | --- | --- | | Bir gruptaki herkesin sahip olması gereken erişim | Otomasyon kuralı | | Kişinin onay ve bitiş tarihiyle talep ettiği erişim | Erişim paketi | | Erişimin hâlâ gerekli olduğunun kanıtı | Sertifikasyon kampanyası | | Karar verecek sorumlu kişi | Governance → `Owners` | > İpucu: Kampanya başlamadan önce her öğenin bir gözden geçireni olacağını kontrol edin: profillerde yöneticiler dolu olmalı, sahipler de kampanyanın okuduğu türle kayıtlı olmalı.