Maden Sahalarında Personel ve Araç Takip Projesi Nasıl Planlanır?

Yer altı personel ve araç takibi konuşulurken masa üzerindeki ilk çizim genellikle tag, okuyucu ve merkezi sunucudan oluşur. Sahaya inildiğinde tünel geometrisi, enerji noktaları, toz, nem, titreşim, haberleşme kesintileri ve vardiya akışı bu sade çizimi hızla değiştirir. Bir okuyucunun çalışması, ürettiği olayın operasyon açısından doğru ve zamanında olduğu anlamına gelmez.

Nisan-Temmuz 2026 döneminde ele aldığımız anonim bir saha çalışmasında projeyi cihaz kurulumu değil, operasyonel yetenek geliştirme programı olarak yönettik. Tag reader, hat başı bileşenleri, araç/personel tag’leri ve merkezi uygulama yalnızca teknik yapı taşlarıydı. İş güvenliği, saha operasyonu, altyapı, BT, insan kaynakları ve tedarikçi aynı kabul ölçütlerinde buluşmadan canlıya geçiş planlanmadı.

Sorunun ortaya çıkışı

Kurum, vardiya sırasında personel ve araçların belirlenmiş bölgelere giriş-çıkışını merkezi olarak görmek istiyordu. İlk kapsam cihaz adetleri üzerinden hazırlanmış, hangi iş kararının hangi konum hassasiyetine ve gecikme süresine ihtiyaç duyduğu yazılmamıştı. “Yer altında takip” ifadesi gerçek zamanlı koordinattan bölge bazlı geçiş olayına kadar farklı beklentiler yaratıyordu. Önce bu beklentiyi ölçülebilir kullanım senaryolarına çevirdik.

Saha keşfinde plan üzerindeki güzergâh ile fiili operasyonun farklı olduğu görüldü. Geçici çalışma alanları, hareket eden ekipmanlar, enerji kesintisi olasılığı ve bakım erişimi cihaz yerleşimini etkiliyordu. Merkezi sunucuya bağlantı için tek yol varsayılmış, bağlantı kesildiğinde olayların yerelde tutulup tutulmayacağı netleştirilmemişti. Projenin fiziksel, ağ ve uygulama bağımlılıkları tek takvimde görünmüyordu.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım üretici çizimindeki kapsamanın saha kabulü yerine geçeceğiydi. Kaya yapısı, tünel dönüşleri, metal ekipman, montaj yüksekliği ve hareketli araçlar radyo davranışını değiştirebilir. İkinci varsayım tag görülmüyorsa sorunun doğrudan tag arızası olduğuydu. Okuyucu enerjisi, anten, hat bileşeni, ağ yolu, zaman senkronizasyonu veya sunucu işleme kuyruğu aynı belirtiyi yaratabilir.

Bir başka belirti kullanıcıların ekranda gördüğü konumu kesin koordinat olarak yorumlamasıydı. Sistem bölge veya okuyucu geçişi mantığıyla çalışıyorsa gösterim de bu belirsizliği açıkça ifade etmelidir. “Anlık” sözcüğü de ölçülmemişti; olayın sahada oluşması ile ekranda görünmesi arasında kabul edilen gecikme tanımlanmayınca tedarikçi ve operasyon farklı başarı ölçütleri kullandı.

Teknik analiz

Kapsamayı masa başı tasarım, saha ölçümü ve pilot doğrulama olarak üç aşamaya böldük. Kritik geçiş noktaları, kaçış güzergâhları, girişler ve operasyon bölgeleri kullanım senaryosuna göre sınıflandırıldı. Her cihaz için enerji, montaj, çevresel dayanım, bakım erişimi ve iletişim bağımlılığı kaydedildi. Tek bir kapsama yüzdesi yerine kritik nokta tespit oranı, olay gecikmesi ve kesinti sonrası veri bütünlüğü ölçüldü.

Uçtan uca veri akışı tag’den okuyucuya, ara haberleşme bileşenine, saha ağına, merkezi uygulamaya ve API tüketicisine kadar izlendi. Cihaz ile sunucu saatlerinin güvenilir kaynaktan eşlenmesi olay sırasını korumak için kritik bulundu. Bağlantı kesintisinde tampon kapasitesi, tekrar gönderim, yinelenen kayıt ve kayıp olay davranışı test edildi. API alanları veri sahibi ve amaçla eşleştirildi.

Uygulanan çözüm veya önerilen mimari

Önce sınırlı fakat operasyon açısından temsilî bir pilot bölge seçildi. Okuyucu ve hat bileşenleri saha güvenliği kurallarına uygun monte edildi; enerji ve ağ yolları izlenebilir biçimde etiketlendi. Merkezi SmartFlow benzeri uygulama yedekleme, izleme ve zaman senkronizasyonu olan sunucu katmanında çalıştırıldı. Üretim ağına erişimler gerekli akışlarla sınırlandı ve uzaktan bakım ayrı onay sürecine bağlandı.

Pilot kabulü cihazın çevrimiçi görünmesine değil, tanımlı personel ve araç senaryolarının doğru olay üretmesine dayandı. Sonuçlar operasyon, iş güvenliği ve BT tarafından birlikte imzalandı. Yaygınlaştırma lokasyon paketlerine ayrıldı; her pakette saha hazırlığı, kurulum, test, eğitim ve as-built dokümantasyon tamamlanmadan sonraki bölgeye geçilmedi. API entegrasyonu pilot veri kalitesi doğrulandıktan sonra açıldı.

Alternatifler ve karar gerekçesi

Bölge bazlı RFID benzeri yaklaşım daha sade altyapı ve belirli geçiş noktalarında güvenilir olay sağlayabilir; sürekli ve hassas koordinat beklentisini karşılamaz. UWB gibi daha hassas çözümler daha yoğun altyapı, kalibrasyon ve maliyet gerektirebilir. Wi-Fi veya BLE tabanlı seçenekler mevcut altyapıdan yararlanabilir, ancak yer altı ortamında kapsama ve cihaz davranışı mutlaka sahada doğrulanmalıdır.

Tek seferde tüm sahaya yayılım takvimi kısaltıyor gibi görünür; tasarım hatasını çoğaltma ve operasyonu zorlayacak büyük değişiklik riski taşır. Pilot sonrası dalgalı yayılım daha uzun planlama gerektirir, fakat yerleşim standardını gerçek veriye göre geliştirir. Kullanım senaryosu bölge geçişi olduğu için teknoloji kararını pazarlama hassasiyetine değil, kabul edilen doğruluk ve bakım yapılabilirliğine bağladık.

Güvenlik ve operasyonel riskler

Konum olayları çalışan davranışı ve iş güvenliğiyle ilişkili kişisel veri oluşturabilir. Amaç, erişim rolleri, saklama süresi, çalışan bilgilendirmesi ve hukuki dayanak proje başında belirlenmelidir. Yönetim ekranları herkese açılmamalı, rapor dışa aktarımları izlenmeli ve testte gerçek kişi yerine kontrollü kimlikler kullanılmalıdır. API kimlikleri kod veya dokümana yazılmadan güvenli kasada tutulmalıdır.

Sistem tek başına hayat güvenliği sağlayan mekanizma olarak kabul edilmemelidir; kapsama veya bağlantı kesintisi mümkün olduğundan mevcut acil durum prosedürlerini tamamlamalıdır. Yanlış konumun operasyon kararına etkisi ve manuel doğrulama yöntemi yazılmalıdır. Cihaz arızası, enerji kesintisi, sunucu doluluğu ve zaman sapması için alarm ile müdahale sahibi bulunmalı; yedek parça ve saha erişimi planlanmalıdır.

Çıkarılan Dersler

Kontrol Listesi

Orta ölçekli bir işletmede satınalma dosyaları ortak klasör, e-posta ve kişisel takip tablolarına dağılmıştı. Talep formunun son sürümü, hangi teklifin onaylandığı ve sözleşmenin nerede olduğu ancak süreci bilen kişilerden öğrenilebiliyordu. M-Files gündeme geldiğinde ilk beklenti bütün belgeleri tek klasöre taşımaktı. Oysa eski klasör mantığını yeni araca kopyalamak, dağınıklığı yalnızca daha modern bir ekrana taşır.

DMS projesinde odak dosyanın konumu değil, belgenin ne olduğu ve hangi iş kararına bağlı olduğudur. Talep, teklif, değerlendirme, sipariş ve sözleşme ayrı nesneler olsa da ortak süreç kimliğiyle ilişkilendirilmelidir. Teknoloji ancak karar hakları, veri sahipliği ve ERP sınırı tanımlandığında fayda üretir. Bu nedenle kuruluma ekranlardan değil, gerçek satınalma akışından başladık.

Sorunun ortaya çıkışı

Farklı birimler kendi talep şablonlarını kullanıyor, teklifler e-postada kalıyor ve onaylar bazen yalnızca mesajla veriliyordu. Dosya adındaki “son”, “final” ve tarih ekleri versiyon kontrolü sanılıyordu. Denetimde bir satınalma kararının talep, karşılaştırma ve yetkili onay zincirini göstermek zaman alıyordu. Aynı tedarikçiye ait belgeler farklı klasörlerde tekrar tutuluyor, saklama süreleri uygulanamıyordu.

İlk belirtiler ve yanlış varsayımlar

İlk varsayım taranmış PDF yüklemenin dijitalleşme olduğuydu. Aranabilirlik artsa da zorunlu metadata ve süreç durumu olmadan kontrol gelişmez. Diğer varsayım bütün alanları ilk günden zorunlu yapmaktı; bu kullanıcıyı sistem dışı kanallara iter. ERP’nin ya tamamen devre dışı kalacağı ya da her şeyi yöneteceği düşüncesi de yanlıştı. İşlem sistemi ile belge ve onay sistemi arasında açık sınır gerekiyordu.

Teknik analiz

Talep numarası, şirket, lokasyon, maliyet merkezi, kategori, tutar aralığı, süreç sahibi ve saklama sınıfını temel metadata olarak belirledik. Nesne ilişkileri sayesinde teklifleri talebe, siparişi onay kararına bağladık. Yetki modeli belge türünden çok süreç rolü ve organizasyon bağlamına dayandı. ERP’de oluşan tedarikçi ve sipariş anahtarlarının DMS’ye nasıl aktarılacağı, hata ve yinelenen kayıt senaryolarıyla birlikte analiz edildi.

Uygulanan çözüm veya önerilen mimari

Önce tek bir satınalma kategorisinde pilot workflow kurduk: taslak, birim onayı, bütçe kontrolü, satınalma değerlendirmesi, karar ve arşiv. Her durumda düzenleme ve görüntüleme hakları ayrı tanımlandı. M-Files versiyon geçmişini resmi kayıt olarak tuttu; onay yorumu ve zaman damgası korundu. ERP entegrasyonunda yalnızca gerekli ana veriler ve onaylanmış sonuç taşındı. Kullanıcılara ekran eğitimi yerine örnek iş senaryoları verildi.

Alternatifler ve karar gerekçesi

ERP’nin yerleşik satınalma modülü işlem bütünlüğünde güçlü olabilir; DMS ise belge yoğun süreç, arama ve kayıt yönetiminde avantaj sağlar. SharePoint veya başka içerik platformları da doğru bilgi mimarisiyle aynı ihtiyacın bir bölümünü karşılayabilir. Ürün seçimini mevcut lisans, entegrasyon yetkinliği ve kayıt yönetimi ihtiyacına göre yaptık. M-Files’ı ERP yerine değil, kontrollü belge ve karar katmanı olarak konumlandırdık.

Güvenlik ve operasyonel riskler

Teklifler, sözleşmeler ve ticari koşullar geniş erişime açılmamalıdır. Kalıtımlı yetkiler, dış paylaşım, indirme ve çevrimdışı kopya senaryoları test edildi. Entegrasyon hesabına yalnızca gerekli nesne ve işlemler için yetki verildi; kişisel hesap kullanılmadı. Workflow arızasında satınalmanın durmaması için kontrollü manuel prosedür ve sonradan sisteme işleme kuralı tanımlandı. Saklama ve silme hukuki gereksinimlerle uyumlu tutuldu.

Çıkarılan Dersler

Kontrol Listesi

ERP bütçesi hazırlanırken kullanıcı listesindeki herkese aynı lisansı vermek en kolay yöntemdir; genellikle en doğru yöntem değildir. Bir projede depo çalışanı mal kabul yapıyor, bakım teknisyeni iş emri kapatıyor, yönetici yalnızca onay veriyor ve finans uzmanı çok sayıda modülde kayıt oluşturuyordu. Hepsini “ERP kullanıcısı” başlığı altında saymak hem gereksiz maliyet hem de yanlış yetki tasarımı doğuruyordu.

Full User ve Limited Task User ayrımı ürün broşüründeki kısa tanımlarla yapılamaz. Lisans hakları sözleşme ve sürüme göre değişebilir; ayrıca teknik olarak yapılabilen işlem lisans açısından izinli olmayabilir. Biz önce kişileri değil işleri sınıflandırdık, sonra rol paketlerini lisans koşullarıyla eşleştirdik. Böylece görüşme fiyat pazarlığından önce gerçek kullanım modeline dayandı.

Sorunun ortaya çıkışı

İlk kullanıcı sayısı departman yöneticilerinden istenmiş ve sisteme erişebilecek herkes full lisans olarak yazılmıştı. Ancak bazı kişiler ayda birkaç onay yapacak, bazıları dashboard görecek, bazıları ise üretim ve finans süreçlerinde yoğun işlem gerçekleştirecekti. Vardiyalı büyüme ve dış hizmet kullanıcıları hesaba katılmamıştı. Bu liste üzerinden alınan teklif ileride gerçek kullanım ve denetim sorunu yaratabilirdi.

İlk belirtiler ve yanlış varsayımlar

Unvanı yönetici olan herkesin full, saha çalışanının limited olması gerektiği varsayıldı. Oysa yönetici bütçe düzenleyebilir, teknisyen farklı modüllerde planlama yapabilir. “Sadece okuyor” ifadesi de yeterli değildi; rapor üretme, veri dışa aktarma ve toplu işlem hakları farklı olabilir. Named user lisansını vardiya hesabıyla paylaşmak maliyet düşürmez; sözleşme ve izlenebilirlik riski yaratır.

Teknik analiz

Her rol için ekran adı yerine iş fiili yazdık: talep oluşturur, mal kabul eder, iş emri planlar, mali kayıt girer, workflow onaylar veya rapor görüntüler. İşlem sıklığı, modül kapsamı, veri değiştirme yetkisi ve görev ayrılığı eklendi. Bu matrisi üreticinin güncel lisans tanımı ve sözleşme maddeleriyle doğruladık. Geçici proje kullanıcıları, entegrasyon hesapları ve mobil kullanım ayrıca değerlendirildi.

Uygulanan çözüm veya önerilen mimari

Rol kataloğunu Full, Limited Task, Self-service ve salt raporlama adayları olarak grupladık; nihai sınıfı üreticinin yazılı teyidiyle belirledik. Kimlik yaşam döngüsü İK ana verisine bağlandı. Kullanıcı rol değiştirince lisans ihtiyacının yeniden değerlendirilmesi için workflow kuruldu. Lisans havuzuna büyüme payı eklendi ancak belirsizliği büyük bir yedek alımla örtmedik. Üç aylık kullanım ve yetki gözden geçirmesi planlandı.

Alternatifler ve karar gerekçesi

Concurrent lisans bazı platformlarda vardiyalı kullanım için uygun olabilir, fakat her ürün sunmaz ve kapasite tepe anına göre boyutlanır. İş ortakları için portal veya self-service lisansı daha doğru olabilir. BI aracı, ERP’ye salt raporlama amacıyla giren kullanıcı sayısını azaltabilir; bunun veri güvenliği ayrıca yönetilmelidir. Kararı yalnız ilk yıl fiyatına değil, beş yıllık rol büyümesi ve sözleşme esnekliğine göre verdik.

Güvenlik ve operasyonel riskler

Lisansı düşürmek amacıyla yetkiyi yapay biçimde bölmek kontrol boşluğu yaratabilir. Ortak hesaplar bireysel iz bırakmadığı için kullanılmadı. Full lisans verilen kişinin otomatik olarak geniş yetki almaması sağlandı; lisans hakkı ile uygulama rolü ayrı kavramlardır. Sözleşme yorumları yazılı teyit edildi, kullanım ölçümü kişisel performans takibine dönüştürülmedi ve ayrılan çalışanların erişim ile lisansı zamanında geri alındı.

Çıkarılan Dersler

Kontrol Listesi

Bir maden işletmesinde ERP görüşmesi finans ekranlarıyla başladığında toplantının önemli bölümü doğru sorular sorulmadan geçebilir. Muhasebe, vergi ve genel satınalma elbette zorunludur; fakat cevher hareketi, ekipman bakımı, laboratuvar sonucu, vardiya tüketimi ve proje maliyeti farklı dosyalarda kaldığında yönetim aynı işletmeye ait birden fazla gerçekle karşılaşır. Finansal kapanış düzgün olsa bile operasyonel karar gecikebilir.

Business Central, Dynamics 365 Finance and Supply Chain, IFS ve benzeri platformların her birinin güçlü olduğu alanlar ve farklı uygulama yükleri vardır. Ürün adından önce işletme modelini anlamak gerekir. Biz seçim çalışmasını demo özelliklerinden değil, ocaktan veya yer altından başlayıp stok, işleme, satış ve finans kaydına uzanan uçtan uca senaryolardan yürüttük.

Sorunun ortaya çıkışı

Mevcut sistem temel muhasebe ve bordro ihtiyacını karşılıyor, ancak bakım planları ayrı uygulamada, depo hareketleri tabloda, laboratuvar sonuçları başka bir veritabanında tutuluyordu. Ekipman duruşunun üretim ve maliyet etkisi ancak ay sonunda elle birleştirilebiliyordu. Yeni ERP talebi önce finans yenilemesi gibi tanımlandı. Süreç haritası çıkarıldığında asıl ihtiyacın varlık yoğun operasyonu bütünleştirmek olduğu ortaya çıktı.

İlk belirtiler ve yanlış varsayımlar

“Her ERP aynı muhasebeyi yapar, geri kalanı özelleştiririz” varsayımı tehlikeliydi. Yoğun özelleştirme yükseltme ve destek maliyetini artırır. Diğer uçta, sektör etiketli ürünün tüm süreçleri hazır getireceği düşünülebilir; yerel mevzuat, işletme yöntemi ve entegrasyonlar yine çalışma ister. En çok ekranı gösteren demo da en uygun çözüm değildir. Kritik senaryonun standartta ne kadar karşılandığı ölçülmelidir.

Teknik analiz

Üretim miktarı ve kalite, varlık hiyerarşisi, önleyici bakım, yedek parça, seri ve lot takibi, laboratuvar entegrasyonu, saha bağlantısı, proje bütçesi ve birim maliyet için gereksinimler yazıldı. Her madde must-have, differentiator veya sonraki faz olarak sınıflandı. Offline çalışma, mobil kullanım, API, raporlama, yerel destek ve veri taşıma kapasitesi incelendi. Tedarikçilere aynı uçtan uca senaryolar canlı gösterim için verildi.

Uygulanan çözüm veya önerilen mimari

Önerilen mimari ERP’yi finans, tedarik, stok, proje ve varlık kayıtlarının omurgası yaptı; uzman saha ve laboratuvar sistemleri doğrulanmış entegrasyonlarla bağlı kaldı. Ana veri sahipleri ekipman, malzeme, lokasyon ve maliyet merkezi bazında belirlendi. Fazlandırma önce temel finans ve tedarik, sonra bakım ve üretim, ardından ileri planlama olacak şekilde risk bazlı yapıldı. Her faz için veri, süreç ve kabul sahibi atandı.

Alternatifler ve karar gerekçesi

Daha hafif bir finans ERP’si hızlı ve düşük maliyetli olabilir; uzman bakım ve üretim araçlarıyla entegrasyon olgunluğu varsa geçerli seçenektir. Geniş kurumsal platform daha bütünleşik yapı sunar fakat proje kapasitesi ve değişim yönetimi ister. Best-of-breed yaklaşımı fonksiyon derinliği sağlar, veri ve entegrasyon yönetişimini zorlaştırır. Kararı marka büyüklüğüne değil, standart uyum, toplam sahip olma maliyeti ve kurumun işletme kapasitesine dayandırdık.

Güvenlik ve operasyonel riskler

ERP kesintisi saha ve finansı aynı anda etkileyebileceği için yüksek erişilebilirlik, yedekleme ve geri dönüş testleri tasarıma dahil edildi. Görev ayrılığı; tedarikçi açma, sipariş, mal kabul ve ödeme zincirinde test edildi. Saha entegrasyonları doğrudan geniş veritabanı yetkisiyle kurulmadı. Ticari tekliflerde gerçek üretim ve rezerv verisi paylaşılmadı; maskelenmiş senaryolar kullanıldı. Bulut veya şirket içi tercihte veri konumu ve bağlantı bağımlılığı değerlendirildi.

Çıkarılan Dersler

Kontrol Listesi

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