Personel Ana Verisi Güncel Değilse Hangi Sistemler Etkilenir?

Bir çalışanın birimi değişmişti. Bordro işlemi doğru ilerliyor, fakat eski dağıtım grubundan e-posta almaya, eski birimin dokümanlarını görmeye ve ITSM portalında yanlış yöneticiye onay göndermeye devam ediyordu. Her sistemde ayrı düzeltme yapılınca sorun geçici olarak kapandı; bir sonraki organizasyon değişikliğinde aynı tablo tekrarlandı.

Personel ana verisi çoğu kurumda İK konusu olarak görülür, fakat teknik etkisi kimlik yaşam döngüsünün tamamına yayılır. Çalışan numarası, durum, başlangıç-bitiş tarihi, yönetici, birim, lokasyon ve görev kodu güvenilir değilse otomasyon hatayı daha hızlı dağıtır. Bu nedenle entegrasyon projesinden önce kaynak sistem, veri sahibi ve kalite kuralı üzerinde uzlaşmak gerekir.

Sorunun ortaya çıkışı

Bordro uygulamasındaki organizasyon alanları bazı çalışanlarda boş, bazılarında serbest metin ve eski değerlerle doluydu. Entra grupları, e-posta listeleri, DMS yetkileri ve ITSM yönlendirmeleri bu alanların farklı kopyalarına dayanıyordu. Yeni başlayan hesabı elle açılıyor, ayrılan çalışan bildirimi e-postayla geliyordu. Sistemler tek tek çalışsa da çalışan yaşam döngüsü uçtan uca güvenilir değildi.

İlk belirtiler ve yanlış varsayımlar

Yanlış mail grubu yalnız iletişim sorunu sanıldı; oysa aynı nitelik erişim kuralını da besleyebilirdi. İlk çözüm, BT’nin eksik alanları entegrasyon tablosunda düzeltmesiydi. Bu ikinci bir gölge ana veri oluşturdu ve İK değişikliğinde güncelliğini kaybetti. API kurmanın veri kalitesini çözeceği varsayımı da yanlıştı. API, hatalı kaydı tutarlı ve hızlı biçimde çoğaltabilir.

Teknik analiz

Her hedef sistemin kullandığı personel niteliklerini çıkardık ve alan bazında source of truth belirledik. Benzersiz çalışan anahtarı isim veya e-posta olmadı. Zorunluluk, referans listesi, geçerlilik tarihi ve yönetici döngüsü kontrolleri tanımlandı. Joiner, mover ve leaver olaylarının hangi sürede hangi sisteme ulaşacağı yazıldı. Yeniden işe alım, vekalet, çift görev ve dış kaynak çalışan senaryoları ayrıca test edildi.

Uygulanan çözüm veya önerilen mimari

İK sistemi personel statüsü ve organizasyonun yetkili kaynağı olarak konumlandı. Entegrasyon katmanı yalnız doğrulanmış kayıtları hedef sistemlere taşıdı; reddedilen kayıtları veri sahibine açık hata mesajıyla döndürdü. Yetkiler doğrudan kişiye değil mümkün olduğunca rol ve grup kurallarına bağlandı. Kritik ayrılış olayı periyodik toplu aktarımı beklemeden işlendi. Mutabakat raporu kaynak ve hedefteki aktif hesap farklarını düzenli gösterdi.

Alternatifler ve karar gerekçesi

Tam IAM/IGA platformu gelişmiş yaşam döngüsü ve erişim gözden geçirmesi sunabilir, fakat veri temeli bozuksa beklenen değeri vermez. Basit zamanlanmış aktarım düşük hacimde yeterli olabilir; hata kuyruğu ve mutabakat şarttır. Manuel süreç istisnalar için kalabilir, ana yöntem olmamalıdır. Önce veri sözlüğü ve temel entegrasyonu kurduk, karmaşık yönetişim aracını olgunluk arttığında değerlendirdik.

Güvenlik ve operasyonel riskler

Hatalı leaver kaydı erişimin gereğinden uzun sürmesine, hatalı mover kaydı yetki birikimine yol açar. Entegrasyon servis hesabı en az yetkiyle ve gizli bilgi kasası üzerinden yönetildi. Personel verisinin tamamı her hedefe gönderilmedi; amaç için gereken alanlar seçildi. Loglarda gereksiz kişisel veri maskelendi. Otomatik kapatma hatasına karşı insan onaylı istisna ve hızlı geri yükleme prosedürü oluşturuldu.

Çıkarılan Dersler

Kontrol Listesi

Kullanıcıların çok sayıda parola hatırlaması SSO projesini başlatan görünür şikâyetti. Ancak envanter çalışmasında daha önemli bir sorun ortaya çıktı: işten ayrılan bir kişinin bazı bulut uygulamalarındaki yerel hesabı günler sonra kapatılıyordu. Parola sayısını azaltmak değerliydi, fakat merkezi kimliğin asıl getirisi erişimi tek politika ve yaşam döngüsü altında yönetebilmekti.

SSO, her uygulamaya aynı parolayı göndermek değildir. Kimlik sağlayıcı, SAML veya OpenID Connect gibi protokollerle uygulamaya doğrulanmış kimlik beyanı sunar. Uygulamanın oturum davranışı, yerel hesapları ve yetkilendirmesi yine ayrıca tasarlanır. Bu ayrım anlaşılmadığında başarılı giriş ekranı, yanlışlıkla başarılı bir IAM projesi sanılabilir.

Sorunun ortaya çıkışı

Kurumsal uygulamaların bir bölümü dizin hesabı, bir bölümü yerel kullanıcı, bazıları da ortak hesap kullanıyordu. Parola sıfırlama talepleri artıyor ve yeni çalışan açılışı uygulama sahiplerine e-postayla dağıtılıyordu. Ayrılış kontrol listesi uygulama envanteri güncel olmadığı için eksik kalabiliyordu. Yönetim tek giriş istedi; BT olarak kapsamı kimlik, provisioning ve yetki yaşam döngüsünü içerecek biçimde genişlettik.

İlk belirtiler ve yanlış varsayımlar

“Entra’ya bağlanınca bütün hesaplar kapanır” varsayımı doğru değildi. SSO oturumu engelleyebilir, fakat uygulamadaki yerel hesap, API anahtarı veya aktif oturum devam edebilir. Her uygulamanın SAML desteklemesi de aynı kaliteyi sağlamaz; grup claim sınırları, kullanıcı eşleme ve logout davranışı değişir. Ayrıca break-glass hesabını normal SSO akışına bağlamak acil durumda tek hata noktası yaratabilir.

Teknik analiz

Uygulama envanterine sahip, kullanıcı sayısı, veri sınıfı, protokol, provisioning yöntemi, yerel hesap ve kritik bağımlılık alanları eklendi. SAML ve OIDC seçenekleri ürün dokümanı ve test tenantında doğrulandı. NameID veya subject eşlemesinde değişebilir e-posta yerine kararlı kimlik değerlendirildi. MFA ve koşullu erişimin hangi uygulamalarda uygulanacağı, servis hesapları ve mobil istemcilerle birlikte analiz edildi.

Uygulanan çözüm veya önerilen mimari

Kimlik sağlayıcı merkezde, uygulamalar federasyon tarafında konumlandı. Pilot için etkisi yüksek fakat geri dönüşü kolay bir SaaS seçildi. Grup tabanlı atama ve mümkün olan uygulamalarda SCIM provisioning kullanıldı. Yerel parola ile giriş kontrollü biçimde kapatılmadan önce yönetici kurtarma yolu test edildi. İşe giriş, rol değişimi ve ayrılış akışları İK kaynağına bağlandı; başarılı giriş kadar erişim kaldırma testi de kabul kriterine girdi.

Alternatifler ve karar gerekçesi

Parola kasası, federasyon desteklemeyen eski uygulamalarda kontrollü bir geçiş çözümü olabilir; gerçek SSO ve yaşam döngüsü sağlamaz. Reverse proxy tabanlı erişim bazı web uygulamalarını kapsar, fakat protokol ve destek sınırları vardır. Uygulamayı değiştirmek pahalı olabilir, ancak kritik ve destek dışı kimlik yapısında uzun vadede doğru seçenek olabilir. Her uygulama için risk, maliyet ve emeklilik tarihiyle ayrı karar verdik.

Güvenlik ve operasyonel riskler

Merkezi kimlik sağlayıcının kesintisi çok sayıda uygulamayı etkiler; acil erişim hesapları, izleme ve iletişim planı hazırlandı. Koşullu erişim politikaları önce rapor modunda ve pilot grupla test edildi. Token ömrü, oturum iptali ve ayrılış gecikmesi ölçüldü. Claim içine gereksiz kişisel veya organizasyon verisi koyulmadı. Sertifika sona erme tarihleri sahipli bir takvime alındı ve değişiklikler çift taraflı koordine edildi.

Çıkarılan Dersler

Kontrol Listesi

Bir danışmana şirket uzantılı adres vermek, yazışmayı kolaylaştırırken karşı tarafa kurumsal kimlik de kazandırır. Alıcılar bu kişinin çalışan mı, yüklenici mi olduğunu ayırt etmeyebilir; uygulamalar da aynı adresi otomatik güven sinyali sayabilir.

20 Temmuz 2026 tarihindeki vakada resmi sözleşmesi tamamlanmadan teklif üzerinden hizmet veren kişiler için hesap talep edilmişti. Talebi yalnızca lisans açısından değil, kimlik yaşam döngüsü, veri sahipliği ve kurum adına iletişim riski açısından değerlendirdik.

İş biriminin talebi makuldü: danışmanın toplantılara katılması, belgeler üzerinde çalışması ve dış paydaşlarla düzenli iletişim kurması gerekiyordu. Ancak çözümün mutlaka çalışanla aynı kimlik türü olması gerekmiyordu. Kurumsal dizinde oluşan her nesnenin görünmeyen yan etkileri vardır; otomatik gruplar, uygulama varsayılanları ve paylaşım kolaylıkları zamanla erişimi büyütebilir. Bu nedenle hesabın ilk günkü yetkisinden çok, altı ay sonra kim tarafından hatırlanacağına odaklandık. Sorumlu sponsor, hizmet ilişkisini düzenli doğrulamadıkça teknik ekibin sözleşmenin bittiğini kendiliğinden bilmesi beklenemez.

Sorunun ortaya çıkışı

İş birimi hızlı iletişim ve toplantı erişimi için şirket hesabı istiyordu. Talepte hizmet bitiş tarihi, veri kapsamı, sponsor ve kapanış koşulu yoktu. Hesap açıldığında adres defteri, paylaşım davetleri ve bazı varsayılan uygulama erişimleri beklenenden geniş olabilirdi.

BT talebi tamamen reddetmek yerine iş ihtiyacını ve kimlik ihtiyacını ayırdı. Dış toplantı katılımı, konuk erişimi veya paylaşımlı kanal yeterliyse tam posta kutusu gerekmiyordu. Kurum adına yazışma gerekiyorsa hukuki ilişki ve sorumluluklar önce netleşmeliydi.

İlk belirtiler ve yanlış varsayımlar

“Sadece e-posta” ifadesi en yaygın yanlış varsayımdı. Modern bulut ortamında posta kimliği dosya paylaşımı, ekip üyeliği, uygulama kaydı ve parola sıfırlama akışlarına bağlanabilir. Lisans atanmaması da kimlik nesnesinin riskini ortadan kaldırmaz.

Yönetici onayı tek başına yeterli sayılıyordu; oysa hesabın günlük sponsoru, hizmet süresi ve veri sınıfı bilinmelidir. Danışmanın kendi cihazını kullanması halinde cihaz güvenliği, veri indirme ve olay bildirim yükümlülüğü ayrıca ele alınmalıdır.

Teknik analiz

Hesap türü çalışan kimliğinden ayrılmalı, görünür ad ve dizin niteliği dış kullanıcı durumunu doğru yansıtmalıdır. MFA, Conditional Access, riskli oturum politikaları ve cihaz koşulları uygulanmalıdır. Varsayılan grup üyelikleri ve otomatik lisans atamaları incelenmelidir.

Erişimler rol bazlı ve süreli olmalı; posta yönlendirme, uygulama onayı, toplu indirme ve hassas paylaşım olayları izlenmelidir. Hesap etkinliği yalnızca oturum açmaya göre değil, sponsor teyidiyle gözden geçirilmelidir. Offboarding, posta ve dosya sahipliğini yasal saklama gereksinimleriyle birlikte yönetmelidir.

Uygulanan çözüm veya önerilen mimari

Önce konuk erişimi ve mevcut dış iletişim seçenekleri değerlendirildi. Kurumsal posta kutusu gerçekten gerekliyse sözleşme sahibi, iş sponsoru, veri sınıfı, başlangıç ve bitiş tarihi zorunlu alan yapıldı. Hesap ayrı yüklenici grubunda sınırlı politikalarla açıldı.

Süre bitiminden önce sponsora otomatik gözden geçirme gönderildi; teyit gelmezse erişim askıya alındı. Uzatma yeni onay gerektirdi. Hizmet bitiminde oturumlar sonlandırıldı, grup ve uygulama atamaları kaldırıldı, içerik sahipliği kayıtlı prosedüre göre devredildi.

Alternatifler ve karar gerekçesi

Konuk hesap, federasyon ve güvenli dosya paylaşım alanı birçok senaryoda kurumsal posta kutusundan daha düşük risklidir. Paylaşımlı posta kutusu bireysel hesap yerine kullanılmamalıdır; hesap verebilirliği zayıflatır. Danışmanın kendi kurumsal adresiyle yazışması kimlik sınırını daha açık tutabilir.

Tam hesap yalnızca danışmanın kurum adına düzenli iletişim kurması ve iç uygulamalara tanımlı erişim gerektirmesi halinde seçildi. Kolaylık tek başına gerekçe kabul edilmedi. Karar, en az ayrıcalık ve açık kurumsal temsil ihtiyacına göre verildi.

Güvenlik ve operasyonel riskler

Hesap ele geçirilirse saldırgan şirket uzantısını sosyal mühendislik için kullanabilir. Dış danışmanların cihaz ve ağ kontrolleri kurum çalışanlarıyla aynı olmayabilir. Güçlü MFA, oturum koşulları, veri kaybı kontrolleri ve olay bildirim zorunluluğu bu nedenle önemlidir.

Sahipsiz hesaplar yıllarca açık kalabilir, lisans tüketebilir ve denetim bulgusu yaratabilir. Sponsor işten ayrıldığında sahiplik otomatik devredilmelidir. Hukuk, İK, satınalma ve BT arasında kapanış tetikleyicisi kurulmadıkça teknik otomasyon tek başına yeterli olmaz.

Çıkarılan Dersler

Kontrol Listesi

Yüklenici erişimlerinde sorun çoğu zaman ilk gün değil, iş bittikten aylar sonra ortaya çıkar. Proje ekibi dağılmış, sponsor değişmiş ve geçici denilen hesap hâlâ çalışıyor olabilir. Bu tabloyu düzeltmenin yolu her talebi tek tek hatırlamak değil, ortak minimum standardı sürece yerleştirmektir.

20 Temmuz 2026 tarihinde mevcut prosedürü güçlendirirken teknik kontrol listesini sözleşme ve veri yönetişimiyle birleştirdik. Standart, küçük bakım firmasından uzun süreli danışmana kadar riskle orantılı çalışmalı; düşük riskli işi gereksiz bürokrasiyle durdurmamalıydı.

Prosedürü hazırlarken erişim isteyen tarafın dilini de sadeleştirdik. İş sahibi ağ segmenti veya teknik rol adı bilmek zorunda değildi; hangi işi yapacağını, hangi veriye ihtiyaç duyduğunu ve ne zamana kadar çalışacağını açıklaması yeterliydi. Teknik ekip bu ihtiyacı uygun erişim paketine çevirdi. Böylece güvenlik formu uzmanlık sınavına dönüşmedi, buna karşılık “her yere erişsin” gibi belirsiz talepler kabul edilmedi. Ölçüm tarafında açılış süresi kadar süresi dolmuş hesap, sponsorsuz kimlik ve gözden geçirmede kaldırılan gereksiz yetki sayısını takip ettik.

Sorunun ortaya çıkışı

Farklı iş birimleri yüklenici hesaplarını e-posta, telefon veya servis talebiyle açtırıyordu. Taleplerde sistem, veri sınıfı ve süre bilgisi tutarlı değildi. BT hesabı açsa bile sözleşme bitişinden haberdar olmuyor, satınalma kaydı ile kimlik kaydı eşleşmiyordu.

Minimum standart talep, risk sınıflandırma, onay, sağlama, izleme, gözden geçirme ve kapanış aşamalarını tanımladı. Her aşamanın sahibi belirlendi; güvenlik kontrolü yalnızca BT’nin son dakikada uyguladığı teknik engel olmaktan çıkarıldı.

İlk belirtiler ve yanlış varsayımlar

VPN erişiminin güvenli bağlantı sağladığı için yeterli olduğu düşünülüyordu. Oysa doğru kişiyi, yönetilen cihazı, izinli hedefi ve zaman aralığını ayrıca doğrulamak gerekir. MFA da aşırı yetkiyi veya paylaşılmış hesabı güvenli hale getirmez.

Tedarikçi şirketin güvenilir olması, her çalışanının süresiz erişim alabileceği anlamına gelmez. İsimli hesap, güncel personel listesi ve ayrılan personelin hızlı bildirimi gerekir. Ortak hesaplar izlenebilirliği bozar; acil durum dışında kullanılmamalı ve istisna olarak yönetilmelidir.

Teknik analiz

Talepte iş gerekçesi, hedef sistem, gerekli rol, veri sınıfı, cihaz sahipliği, lokasyon ve süre zorunlu tutuldu. Risk arttıkça güvenlik incelemesi, yönetilen sıçrama noktası, oturum kaydı veya daha dar zaman penceresi eklendi. Ayrıcalıklı erişim normal kullanıcı erişiminden farklı onaylandı.

Kimlik federasyonu mümkünse yaşam döngüsünü kolaylaştırabilir; yine de yerel yetkilendirme ve erişim gözden geçirmesi gerekir. Loglar kim, ne zaman, hangi kaynağa erişti sorularını yanıtlamalıdır. Periyodik inceleme yalnızca hesap varlığını değil, rolün hâlâ gerekli olup olmadığını sorgulamalıdır.

Uygulanan çözüm veya önerilen mimari

Servis kataloğunda risk bazlı yüklenici erişim formu oluşturuldu. Sözleşme veya gizlilik şartı doğrulanmadan teknik sağlama başlamadı. Onaylanan rol hazır erişim paketinden verildi; elle eklenen yetkiler gerekçeli istisna oldu.

Kimlik sistemi bitiş tarihinde otomatik askıya alma yaptı, sponsor incelemesi uzatma için zorunlu tutuldu. Kapanışta oturumlar, gruplar, anahtarlar, cihaz sertifikaları ve uygulama yetkileri kontrol edildi. Rapor, satınalma ve sözleşme envanteriyle düzenli karşılaştırıldı.

Alternatifler ve karar gerekçesi

Her yükleniciye aynı ağır kontrolü uygulamak kolay yönetilir görünse de düşük riskli erişimlerde verimsizdir. Tamamen vaka bazlı karar ise tutarsızlık yaratır. Üç risk seviyesi ve her seviyeye bağlı minimum kontrol seti dengeli sonuç verdi.

Doğrudan VPN yerine uygulama yayını, sıçrama sunucusu veya kimlik tabanlı erişim bazı senaryolarda daha dar kapsam sağlar. Seçim ürün modasına göre değil, hedef sistemin niteliği, oturum izleme ihtiyacı ve saha bağlantı koşullarına göre yapıldı.

Güvenlik ve operasyonel riskler

Üçüncü taraf cihazında zararlı yazılım, paylaşılan kimlik bilgisi veya yetersiz yama seviyesi kuruma taşınabilir. Cihaz koşulu uygulanamıyorsa erişim izole çalışma alanı üzerinden sınırlandırılmalıdır. Hassas veri indirme ve dışa aktarma ayrıca kontrol edilmelidir.

Aşırı bürokrasi kullanıcıyı kontrol dışı araçlara yöneltebilir. Süreç hızlı, ölçülebilir ve acil erişim için kayıtlı istisna içermelidir. Log saklama, oturum kaydı ve kişisel veri konuları sözleşme ve mevzuatla uyumlu olmalıdır.

Çıkarılan Dersler

Kontrol Listesi