SCIM Nedir, Kullanıcı Yönetimini Nasıl Otomatikleştirir?

SCIM, bulut uygulamaları ve kurumsal sistemler arasında kullanıcı kimlik verilerinin senkronizasyonunu otomatikleştiren açık standartlı bir protokoldür. Dağınık SaaS altyapılarında kullanıcı açma, yetki güncelleme ve hesap kapatma işlemlerini merkezi bir noktadan yöneterek güvenlik risklerini en aza indirir.

SCIM Nedir, Kullanıcı Yönetimini Nasıl Otomatikleştirir sorusunun pratik yanıtı, modern işletmelerin yüzlerce farklı bulut uygulaması üzerinde manuel kullanıcı yönetimi yapma zorunluluğunu ortadan kaldıran standart bir mimaride yatar. İşletmeler büyüdükçe ve kullanılan SaaS araçlarının sayısı arttıkça, Bilgi Teknolojileri (BT) ve İnsan Kaynakları (İK) departmanlarının her yeni çalışan için onlarca platformda ayrı hesap açması, unvan değişikliklerinde yetkileri güncellemesi ve işten ayrılışlarda erişimleri anında kesmesi operasyonel bir çıkmaza dönüşür. Bu rehberde, SCIM standardının teknik altyapısını, IdP ve SP mimarisini, yaşam döngüsü yönetimini (JML) ve kurumsal güvenlik süreçlerine doğrudan etkisini derinlemesine inceleyeceğiz.

SCIM (System for Cross-domain Identity Management) Nedir?

System for Cross-domain Identity Management (SCIM), farklı alan adları, kurumlar ve bulut platformları arasında kullanıcı kimlik verilerinin değişimini kolaylaştırmak amacıyla tasarlanmış açık standartlı bir protokoldür. Internet Engineering Task Force (IETF) tarafından RFC 7643 (Temel Şema Tanımı) ve RFC 7644 (Protokol Tanımı) standartlarıyla resmileştirilen SCIM, modern kimlik ve erişim yönetimi (IAM - Identity and Access Management) mimarisinin omurgasını oluşturur. Temel hedefi, kullanıcı provizyonu (provisioning) ve deprovizyonu (deprovisioning) süreçlerini basitleştirmek, tescilli (proprietary) API entegrasyonlarının getirdiği karmaşıklığı ortadan kaldırmaktır.

SCIM geliştirilmeden önce kurumsal BT ekipleri, her bir üçüncü taraf SaaS uygulaması için özel bağlayıcılar (custom connectors) veya senaryo bazlı entegrasyon betikleri (scripts) yazmak zorundaydı. Örneğin; bir şirketin kullandığı insan kaynakları yazılımından Slack, Salesforce, GitHub, Zoom ve Google Workspace platformlarına kullanıcı aktarabilmesi için her bir platformun tescilli API mimarisine, farklı JSON/XML formatlarına ve kimlik doğrulama modellerine uyum sağlaması gerekiyordu. Bu durum yalnızca yüksek yazılım geliştirme ve bakım maliyetleri doğurmakla kalmıyor, API güncellemelerinde entegrasyonların kopmasına ve veri uyumsuzluklarına yol açıyordu.

SCIM standardı, veri taşıma formatı olarak JSON (JavaScript Object Notation) nesnelerini ve iletişim katmanı olarak doğrudan RESTful HTTP metodlarını (GET, POST, PUT, PATCH, DELETE) kullanarak bu heterojen yapıyı standartlaştırır. SCIM sayesinde bir Kimlik Sağlayıcı (Identity Provider - IdP), destekleyen tüm Hizmet Sağlayıcılara (Service Provider - SP) aynı standart istek formatıyla veri gönderebilir. Bu durum, BT departmanlarının SaaS ekosistemini dakikalar içinde merkezi kimlik dizinine bağlamasına imkan tanır.

SCIM Standart Şema Yapısı ve Öznitelik Eşleme

SCIM'in gücü, önceden tanımlanmış ve genişletilebilir veri modelinden gelir. RFC 7643 standardı altında kullanıcılar için User, gruplar için ise Group şemaları standartlaştırılmıştır. Bu şemalarda kullanıcı adı (userName), e-posta adresi (emails), ad-soyad (name.givenName, name.familyName), departman (department), yönetici bilgisi (manager) gibi temel kurumsal öznitelikler evrensel bir yapıda tanımlanır.

Aşağıdaki yapı, standart bir SCIM 2.0 JSON kullanıcı nesnesinin nasıl yapılandırıldığını göstermektedir:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "EMP-94821",
  "userName": "[email protected]",
  "name": {
    "formatted": "Ahmet Yılmaz",
    "familyName": "Yılmaz",
    "givenName": "Ahmet"
  },
  "displayName": "Ahmet Yılmaz",
  "emails": [
    {
      "value": "[email protected]",
      "type": "work",
      "primary": true
    }
  ],
  "active": true,
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "94821",
    "department": "Yazılım Geliştirme",
    "division": "Mühendislik",
    "manager": {
      "value": "[email protected]",
      "displayName": "Bulut Kaya"
    }
  }
}

Bu veri yapısı, IdP tarafında tutulan kullanıcı özniteliklerinin (attributes) hedef SaaS uygulaması üzerindeki karşılıklarıyla doğrudan eşlenmesini (attribute mapping) sağlar. SCIM protokolü, bu eşleme kurallarını merkezi olarak işletir; böylece bir kullanıcının departmanı veya unvanı değiştiğinde, SCIM uç noktasına iletilen bir PATCH isteği ile hedef uygulamadaki yetkilendirme grupları otomatik olarak güncellenir.

---

SCIM Mimarisi Nasıl Çalışır? Temel Bileşenler

SCIM mimarisi, istemci-sunucu (Client-Server) modeline dayanır. Kimlik ve erişim yönetimi terminolojisinde bu iki taraf Kimlik Sağlayıcı (Identity Provider - IdP / SCIM Client) ve Hizmet Sağlayıcı (Service Provider - SP / SCIM Server) olarak adlandırılır. Mimarinin sorunsuz işlemesi, her iki tarafın IETF tarafından belirlenen RESTful uç nokta standartlarına ve hata işleme kurallarına tam uyum göstermesiyle mümkündür.

Kimlik Sağlayıcı (IdP), organizasyondaki yetkili kimlik kaynağıdır (Authoritative Source). Bu kaynak; Microsoft Entra ID (eski adıyla Azure AD), Okta, PingIdentity, OneLogin gibi bir IAM çözümü veya Workday, BambooHR gibi bir bulut İK yazılımı olabilir. IdP, SCIM mimarisinde istemci (Client) rolünü üstlenir. Kullanıcıların eklenmesi, bilgilerin güncellenmesi veya hesapların dondurulması gibi tetikleyici olaylar doğrudan IdP üzerinde gerçekleşir ve IdP bu değişiklikleri hedef uygulamalara iletmek üzere HTTP istekleri üretir.

Hizmet Sağlayıcı (SP) ise kullanıcıların işlerini yürütmek için kullandığı hedef uygulamalardır (örneğin Notion, Jira, AWS, Datadog veya kurumsal iç yazılımlar). SP, bünyesinde bir SCIM sunucusu (SCIM Server) barındırır. Bu sunucu, IdP'den gelen REST isteklerini dinleyen /Users, /Groups ve /Schemas gibi standart API uç noktalarını (endpoints) dış dünyaya açar. Gelen istekleri doğrular, yetkilendirir ve kendi yerel veritabanında gerekli CRUD (Create, Read, Update, Delete) işlemlerini gerçekleştirir.

+-------------------------------------------------------------+
|               Kimlik Sağlayıcı (SCIM Client)                |
|      (Microsoft Entra ID, Okta, PingIdentity vb.)           |
+-------------------------------------------------------------+
                               |
                               |  1. POST /Users (Kullanıcı Oluştur)
                               |  2. PATCH /Users/{id} (Yetki Güncelle)
         HTTPS / OAuth 2.0     |  3. PUT /Groups/{id} (Grup Eşlemesi)
         Bearer Token          |  4. DELETE veya active:false (Deprovizyon)
                               v
+-------------------------------------------------------------+
|               Hizmet Sağlayıcı (SCIM Server)                |
|         (Slack, GitHub, Salesforce, Notion vb.)             |
+-------------------------------------------------------------+

SCIM RESTful API Uç Noktaları ve CRUD Operasyonları

SCIM protokolü, kaynak yönetimini doğrudan HTTP metodları ile standartlaştırır. Bir SP'nin SCIM 2.0 uyumlu kabul edilebilmesi için belirli temel uç noktaları eksiksiz desteklemesi gerekir. Bu operasyonlar veri yönetiminin temelini oluşturur:

SCIM 2.0 ile birlikte performans optimizasyonu için PATCH metodu standart hale getirilmiştir. Bir kullanıcının yalnızca telefon numarası veya departmanı değiştiğinde tüm kullanıcı nesnesini PUT ile göndermek yerine, yalnızca ilgili alanı içeren küçük bir JSON Patch yükü gönderilir. Bu durum, binlerce kullanıcının bulunduğu kurumsal yapılarda ağ trafiğini ve API kota (rate limit) tüketimini ciddi oranda azaltır.

Senkronizasyon Modelleri: Push ve Pull Mekanizmaları

SCIM entegrasyonlarında veri akışı çoğunlukla Push tabanlı (İtme) çalışır. IdP üzerinde bir kullanıcı oluşturulduğunda veya güncellendiğinde, IdP olayı anında algılar ve hedef sistemin SCIM uç noktasına gerçek zamanlı bir HTTP isteği gönderir. Bu model, özellikle işten ayrılma durumlarında kritik önem taşır; erişim saniyeler içinde kesilir.

İkinci model ise Periyodik Mutabakat (Reconciliation / Pull tabanlı) döngüsüdür. IdP, belirli zaman aralıklarında (örneğin her 40 dakikada bir) SP'nin /Users uç noktasına GET sorgusu atarak startIndex ve count parametreleriyle mevcut kullanıcı listesini çeker. Bu işlem, hedef sistem üzerinde doğrudan (manuel olarak) yapılan izinsiz değişiklikleri tespit etmek, veri tutarsızlıklarını (drift) gidermek ve IdP ile SP'nin tam senkronize kalmasını sağlamak amacıyla kullanılır.

---

SCIM Kullanıcı Yönetimini Nasıl Otomatikleştirir?

Kurumsal kimlik yönetiminde kullanıcı süreçleri JML (Joiner, Mover, Leaver) yaşam döngüsü modeliyle tanımlanır. SCIM, bu üç aşamanın tamamında insan müdahalesini ortadan kaldırarak İnsan Kaynakları sistemleri ile BT altyapısı arasında tam otomatik bir köprü kurar.

Manuel süreçlerde bir çalışanın şirkete katılması, terfi alması veya ayrılması durumunda BT destek ekipleri her bir SaaS platformu için bilet (ticket) açmak, hesapları tek tek oluşturmak ve yetkileri kontrol etmek zorundadır. Bu operasyon hem zaman alıcıdır hem de insan hatasına açıktır. SCIM, İK yönetim sistemindeki (HRIS) tek bir veri değişimini tüm SaaS ekosistemine saniyeler içinde yansıtır.

[ İK Sistemi / HRIS ] (Örn: Workday, BambooHR)
          |
          | (Yeni Personel Girişi / Unvan Değişimi / Çıkış Bildirimi)
          v
[ Merkezi Kimlik Sağlayıcı / IdP ] (Örn: Microsoft Entra ID, Okta)
          |
          +-------------------+-------------------+
          | (SCIM Protokolü)  | (SCIM Protokolü)  | (SCIM Protokolü)
          v                   v                   v
     [ Slack SP ]       [ GitHub SP ]       [ Salesforce SP ]
 (Hesap Otomatik     (Ekibe Dahil Edildi (Lisans Tanımlandı
     Açıldı)          & Yetki Verildi)     & Rol Eşlendi)

1. İşe Alım (Onboarding / Joiner): Otomatik Provizyon

Yeni bir personel işe başladığında süreç İK yazılımında personelin kaydının oluşturulmasıyla başlar. SCIM destekli bir yapıda süreç şu adımlarla tamamen otomatik işler:

1. İK uzmanı, çalışanın bilgilerini (ad, soyad, departman, unvan, işe başlama tarihi) sisteme girer.

2. IdP, İK sistemindeki yeni kaydı algılar ve çalışan için merkezi dizinde kurumsal bir kimlik ([email protected]) oluşturur.

3. Çalışanın departmanına (örneğin "Finans") bağlı dinamik grup kuralları tetiklenir.

4. IdP, çalışanın ihtiyaç duyduğu tüm finans araçlarına (ERP, muhasebe yazılımı, iletişim kanalları) paralel olarak POST /Users SCIM istekleri gönderir.

5. Çalışan ilk iş gününde bilgisayarını açtığında, tüm uygulamalardaki hesapları açılmış, rollerine uygun yetkiler atanmış ve lisansları rezerve edilmiş olarak hazırdır.

2. Rol ve Departman Değişiklikleri (Mover): Dinamik Yetki Güncellemesi

Şirket içi transferler, terfiler veya departman değişiklikleri güvenlik açıklarının en sık yaşandığı alanlardır. "Yetki Birikmesi" (Privilege Creep) olarak bilinen bu risk, çalışanın eski departmanındaki yetkilerinin iptal edilmeyip üzerine yeni yetkilerin eklenmesiyle ortaya çıkar.

SCIM, Rol Tabanlı Erişim Kontrolü (RBAC - Role-Based Access Control) kurallarını grup öznitelikleri üzerinden senkronize eder. Çalışanın unvanı "Satış Temsilcisi"nden "Pazarlama Uzmanı"na geçtiğinde:

• IdP üzerindeki grup üyeliği değişir.

• SCIM istemcisi, Satış araçlarına PATCH /Users/{id} göndererek lisansı düşürür veya hesabı askıya alır.

• Pazarlama araçlarının SCIM uç noktasına istek gönderilerek yeni rol ve erişim yetkileri atanır.

• Bu işlem, çalışanın artık ihtiyaç duymadığı hassas verilere erişimini anında sonlandırır.

3. İşten Çıkış (Offboarding / Leaver): Anında Deprovizyon

İşten ayrılan personelin erişimlerinin açık kalması, veri sızıntılarının ve fidye yazılımı (ransomware) saldırılarının başlıca nedenlerinden biridir. SCIM, işten ayrılış anında kritik bir güvenlik kalkanı sağlar:

1. İK sistemi çalışanın durumunu "Pasif" (Terminated) olarak günceller.

2. IdP, bu değişikliği anında algılayarak bağlı tüm SaaS platformlarına aşağıdaki gibi bir SCIM PATCH isteği iletir:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

1. Hizmet Sağlayıcılar active: false değerini aldığı anda kullanıcının mevcut oturumlarını (session tokens) sonlandırır, şifresini geçersiz kılar ve hesabı askıya alır.

2. Bu işlem sayesinde hiçbir sistemde manuel hesap kapatma unutulmaz; yetkisiz veri indirme, e-posta yönlendirme veya müşteri veritabanına erişim girişimleri kökten engellenir.

---

SCIM Kullanmamanın Kurumsal Güvenlik Riskleri

SCIM protokolünün kullanılmadığı ortamlarda kullanıcı yönetimi tamamen manuel süreçlere, e-posta yazışmalarına ve destek biletlerine dayanır. Ortalama 500 çalışanı olan bir şirketin 80 ila 120 arasında farklı SaaS uygulaması kullandığı düşünüldüğünde, her işten ayrılışta onlarca platformun tek tek kontrol edilmesi imkansız hale gelir. Bu durum işletmeleri çok boyutlu güvenlik ve uyumluluk riskleriyle karşı karşıya bırakır.

Atıl Hesap (Orphaned Account) Tehlikesi ve Veri İhlalleri

İşten ayrılan bir çalışanın SaaS platformlarındaki hesaplarının silinmemesi veya dondurulmaması sonucu sistemde kalan hesaplara Atıl Hesap (Orphaned Account) adı verilir. Siber saldırganlar, kurumsal ağlara sızmak için çoğunlukla bu unutulmuş, çok faktörlü doğrulaması (MFA) devre dışı kalmış veya izlenmeyen hesapları hedef alır.

Sektörel siber güvenlik raporlarına göre, içeriden gelen tehditlerin (insider threats) ve veri hırsızlığı vakalarının önemli bir bölümü eski çalışanların açık kalan hesapları üzerinden gerçekleştirilmektedir. Şirketten ayrılan bir satış yöneticisi, CRM hesabının açık olduğunu fark ederek müşteri portföyünü indirebilir; bir yazılımcı kurumsal GitHub deposundaki kaynak kodlara erişmeye devam edebilir. SCIM, deprovizyonu otomatikleştirerek atıl hesap oluşumunu mimari olarak imkansız kılar.

Manuel İşlemlerde İnsan Hatası ve Operasyonel Yük

Manuel provizyon süreçleri ciddi bir operasyonel maliyet doğurur:

• Gecikmeli Başlangıçlar: Yeni işe giren personelin ihtiyaç duyduğu araçlara erişmesi günlerce sürebilir, bu da iş gücü kaybına yol açar.

• Yanlış Yetkilendirme: Destek personelinin kopyala-yapıştır yaparken yanlış rol ataması sonucu bir çalışana finansal verilere veya yönetici paneline erişim gibi yetkiler verilebilir.

• Lisans Maliyeti İsrafı: Kullanılmayan veya işten çıkan personelin SaaS lisansları manuel olarak iptal edilmediğinde şirketler her ay binlerce dolar gereksiz abonelik ücreti ödemeye devam eder.

KVKK, GDPR, SOC 2 ve ISO 27001 Uyumluluk Zafiyetleri

Uluslararası güvenlik ve gizlilik standartları, erişim yönetiminin sıkı biçimde denetlenmesini ve belgelenmesini zorunlu kılar:

• KVKK ve GDPR: Kişisel verilere erişimi olan personelin görevi bittiği anda erişim yetkisinin kaldırılmasını şart koşar. Eski çalışanın erişiminin açık kalması doğrudan mevzuat ihlali sayılır ve ağır idari para cezalarına yol açar.

• ISO 27001 (Madde A.9 - Erişim Kontrolü): Kullanıcı erişim haklarının zamanında geri alınmasını ve periyodik olarak gözden geçirilmesini zorunlu tutar.

• SOC 2 (Trust Services Criteria): Kullanıcı yetkilendirmelerinin merkezi olarak loglanmasını, otomatik provizyon ve deprovizyon süreçlerinin kanıtlanabilir olmasını denetler.

SCIM entegrasyonu olmadan bu denetimlerden geçmek için denetçilere yüzlerce ekran görüntüsü ve manuel onay formu sunmak gerekir. SCIM ise merkezi IdP üzerinden üretilen tek bir denetim günlüğü (audit log) ile tüm sistemlerdeki erişim hareketlerini saniyeler içinde kanıtlama imkanı sunar.

---

SCIM vs. SAML ve OAuth: Temel Farklar Nelerdir?

Kimlik ve erişim yönetimi alanında en sık yapılan hatalardan biri SCIM, SAML (Security Assertion Markup Language) ve OAuth/OIDC (OpenID Connect) protokollerinin birbirinin alternatifi gibi düşünülmesidir. Bu teknolojiler birbirinin rakibi değil, modern sıfır güven (Zero Trust) mimarisinde farklı görevleri üstlenen tamamlayıcı yapı taşlarıdır.

Temel ayrım üç kavram üzerinden yapılır:

1. Kimlik Doğrulama (Authentication - AuthN): "Kullanıcı gerçekten iddia ettiği kişi mi?" (SAML 2.0 / OIDC)

2. Yetkilendirme (Authorization - AuthZ): "Bu kullanıcının hangi kaynaklara erişim izni var?" (OAuth 2.0)

3. Kullanıcı Yönetimi / Provizyon (Provisioning): "Bu kullanıcının hedef sistemde hesabı var mı, güncel bilgileri neler?" (SCIM 2.0)

+-----------------------------------------------------------------------------+
|                      MODERN IAM STANDARTLARI HARİTASI                       |
+-----------------------------------------------------------------------------+
|  Protokol  | Temel Görevi       | Veri Formatı | Ne Zaman Tetiklenir?       |
|------------|--------------------|--------------|----------------------------|
|  SAML 2.0  | Kimlik Doğrulama   | XML          | Kullanıcı giriş yaparken   |
|            | (SSO / AuthN)      |              | (Login anında)             |
|------------|--------------------|--------------|----------------------------|
|  OIDC      | Kimlik Doğrulama   | JSON / JWT   | Modern web/mobil girişte   |
|            | (SSO / AuthN)      |              | (Login anında)             |
|------------|--------------------|--------------|----------------------------|
|  OAuth 2.0 | Yetki Verme        | JSON / Token | API erişimlerinde          |
|            | (AuthZ / Delegasyon|              | (Yetkilendirme anında)     |
|------------|--------------------|--------------|----------------------------|
|  SCIM 2.0  | Kullanıcı Yönetimi | JSON / REST  | Arka planda sürekli        |
|            | (CRUD Provizyon)   |              | (İK ve dizin olaylarında)  |
+-----------------------------------------------------------------------------+

JIT (Just-in-Time) Provizyon Neden SCIM'in Yerini Tutamaz?

SAML 2.0 protokolü, "Just-in-Time (JIT) Provisioning" adı verilen bir mekanizmaya sahiptir. JIT ile bir kullanıcı hedef uygulamaya SAML üzerinden ilk kez Tek Oturum Açma (SSO) ile giriş yaptığında, SAML Assertion belgesi içindeki öznitelikler okunarak hedef sistemde anında bir hesap oluşturulabilir.

Ancak JIT provizyonun SCIM karşısında kritik eksiklikleri vardır:

• Giriş Zorunluluğu: JIT yalnızca kullanıcı sisteme ilk kez giriş yaptığında tetiklenir. Kullanıcı hiç giriş yapmazsa hesap oluşmaz, bu da ekiplerin önceden lisanslama ve yetkilendirme planlaması yapmasını engeller.

• Deprovizyon Yapamaz: JIT tamamen tek yönlü ve oturum açma odaklıdır. Bir çalışan işten ayrıldığında SAML JIT bunu hedef sisteme bildiremez. Kullanıcı SSO ile giriş yapamasa bile yerel şifresiyle veya API anahtarlarıyla hedef uygulamaya doğrudan erişmeye devam edebilir.

• Öznitelik Senkronizasyonu Yoktur: Kullanıcının unvanı veya departmanı değiştiğinde, kullanıcı tekrar SSO yapana kadar hedef sistemdeki bilgiler güncellenmez.

SCIM ise arka planda (kullanıcının giriş yapmasından bağımsız olarak) sürekli çalışır. Hesapları önceden açar, grup üyeliklerini anlık eşitler ve işten çıkışta hesabı derhal devre dışı bırakır.

---

İşletmenizde SCIM Entegrasyonuna Başlarken Dikkat Edilmesi Gerekenler

SCIM entegrasyonu gerçekleştirmek, yalnızca IdP panelinde bir düğmeyi açmaktan ibaret değildir. Yanlış yapılandırılmış bir SCIM eşlemesi, hedef sistemdeki mevcut kullanıcı verilerinin üzerine yazılmasına (data overwrite), yanlışlıkla toplu hesap dondurmalarına veya lisans kotalarının aşılmasına neden olabilir. Başarılı bir entegrasyon için aşağıdaki teknik aşamaların titizlikle planlanması gerekir.

1. Entegrasyon Öncesi Veri Temizliği ve Mutabakat

SCIM'i devreye almadan önce mevcut kimlik veritabanı ile hedef SaaS uygulamalarındaki kullanıcı listeleri eşleştirilmelidir.

• Benzersiz Tanımlayıcı (Unique Identifier): IdP ile SP arasında eşleştirme yapılacak alan (genellikle userName veya emails) belirlenmelidir. İsim benzerlikleri veya harf hataları olan hesaplar önceden temizlenmelidir.

• Hesap Birleştirme (Account Linking): Hedef sistemde zaten var olan hesapların SCIM tarafından mükerrer (duplicate) olarak yeniden açılmaması için IdP'deki externalId alanı hedef sistemdeki mevcut kullanıcı ID'si ile eşleştirilmelidir.

2. SCIM Uç Nokta Güvenliği ve Token Yönetimi

SCIM API uç noktaları tüm kurumsal kullanıcı verilerini taşıdığı için en üst düzeyde korunmalıdır:

• Kimlik Doğrulama: SCIM uç noktaları mutlaka OAuth 2.0 Bearer Token mekanizması ile korunmalıdır. Statik, süresiz API anahtarları yerine periyodik olarak döndürülen (token rotation) erişim belirteçleri tercih edilmelidir.

• Ağ Güvenliği ve IP Kısıtlaması: Hedef SP'nin SCIM sunucusu, yalnızca yetkili IdP'nin IP adres bloklarından gelen isteklere izin verecek şekilde güvenlik duvarı (WAF) kurallarıyla sınırlandırılmalıdır.

• Aktarım Sırasında Şifreleme: Tüm SCIM trafiği TLS 1.3 (minimum TLS 1.2) protokolü üzerinden şifrelenmelidir.

3. Hata Yönetimi, API Kotaları ve Rollback Planı

Kurumsal ölçekte binlerce kullanıcının senkronize edildiği durumlarda API limitleri ve hata senaryoları hesaba katılmalıdır:

• Rate Limiting: SP'nin API kota sınırları (örneğin dakikada 100 istek) IdP üzerinde doğru yapılandırılmalıdır. Aksi takdirde IdP'nin gönderdiği toplu istekler SP tarafından HTTP 429 Too Many Requests hatasıyla reddedilir ve senkronizasyon kuyruğu tıkanır.

• Hata Bildirimleri: Provizyon başarısızlıklarında (örneğin zorunlu bir özniteliğin eksik olması durumunda dönen HTTP 400 Bad Request), BT yöneticilerine anında e-posta veya webhook uyarısı düşen bir izleme altyapısı kurulmalıdır.

• Kademeli Dağıtım: SCIM entegrasyonu tüm şirkete aynı anda açılmamalıdır. Önce 5-10 kişilik bir test grubuyla pilot uygulama yapılmalı, özniteliklerin doğru eşlendiği doğrulandıktan sonra departman bazlı kademeli geçiş sağlanmalıdır.

---