Ekipten Ayrılan Çalışanın Hesap Erişimini Kapatma

Bir çalışan ekipten ayrıldığında, insan kaynakları sürecinin tamamlanması erişim kapatma sürecinin de tamamlandığı anlamına gelmez. Laptop teslim alınmış, rozet iade edilmiş olabilir; ama arka planda onlarca hesap hâlâ o kişinin kimliğiyle açık duruyor olabilir. E-posta aktif, proje yönetim aracına giriş yapılabiliyor, müşteri CRM'ine erişim sürüyor.

Yalnızca ihmalden değil, farkında olmadan da böyle olur. Onboarding sırasında hangi hesapların açıldığı sistematik biçimde kaydedilmemişse, offboarding sırasında hangilerini kapatmak gerektiği de tam olarak bilinemez. Ayrılma günü telaşı içinde teknik detaylara zaman ayrılamaz; kapanan hesaplar "yeterli" sayılır, kalanlar görünmez olur.

Laptop teslim alınmış olabilir; parola yöneticisi, CRM ve sosyal panel hâlâ o kişinin oturumunda kalır. Sıra bozulursa kapanış günü logu, kapatılmayan hesabı gösterir. Bazı maddeler BT yetkisi ister, bazıları ekip liderinin birkaç tıklaması.

Erişimi kapatmadan önce: hangi hesaplar mevcut?

Offboarding sürecine başlamadan önce çalışanın eriştiği araçların listesini çıkarmak gerekir. Çoğu ekipte bu liste hazır olmaz; ama onu oluşturmaya yardımcı olacak dört kaynak genellikle mevcuttur. Kimlik sağlayıcısının (IdP, Identity Provider) kullanıcı kayıtları, parola yöneticisindeki paylaşılan kasalar, IT destek talep geçmişi ve son otuz günün giriş logları. Bu dört kaynağın kesişimi, hesapların büyük bölümünü ortaya çıkarır.

Geri kalanı için offboarding görüşmesi işe yarar. Çalışana "hangi araçlara erişimin vardı?" sorusunu sormak, çoğu kişinin cevaplamakta güçlük çekmediği bir sorudur; çıkış sürecini sancılı hale getirmek istemezler. Bu görüşmede ortaya çıkan her araç, kontrol listesine eklenir.

Liste oluşturulmadan kapama işlemine başlanırsa, en riskli hesapların en sona bırakılma ihtimali yükselir. Hangi hesabın kritik olduğu önceden bilinmez; bu nedenle liste eksiksiz olmayabilir, ama başlangıç noktası olması bile süreci yapılandırır. İlk hedef mükemmellik değil, sistematik ilerlemedir.

İlk 30 dakika: kimlik sağlayıcısı ve e-posta

Tek oturum açma (SSO, Single Sign-On) kullanan ekiplerde en hızlı ve kapsamlı adım, kullanıcıyı kimlik sağlayıcısından devre dışı bırakmaktır. Bu işlem yapıldığında, o kimliğe bağlı uygulamalarda oturum büyük çoğunlukla sonlandırılır. Ancak bazı uygulamalar SSO belirteçlerini (token) yerel olarak önbelleğe alır ve birkaç saate kadar aktif kalabilir; bu kısa pencereyi göz ardı etmemek gerekir.

E-posta hesabını kapatmak ayrı bir adımdır. Yalnızca parolayı değiştirmek yetmez; açık oturumlar ve uygulama şifreleri (app password) yoluyla erişim sürebilir. Doğru sıra şöyledir: önce tüm aktif oturumları sonlandırın, ardından yetkilendirilmiş uygulama bağlantılarını iptal edin, son olarak hesabı askıya alın ya da silin.

Arşivleme ihtiyacı varsa e-posta içerikleri erişim kapatılmadan önce kopyalanmalıdır. Ama arşivleme adımı erişim kapatmayı geciktirmemeli; ikisi paralel yürütülmez, önce yedek alınır, sonra hesap kapatılır. Yönlendirme aktif tutulacaksa bu yönlendirme kurumsal bir adrese bağlı olmalı ve belirli bir süre sınırı konulmalıdır.

SaaS araçları: lisans iptali yeterli değildir

Birçok ekipte "hesabı kapattık" ifadesi aslında "lisansı kaldırdık" anlamına gelir. Oysa bu ikisi farklı işlemlerdir. Lisansı kaldırılmış bir kullanıcı bazı platformlarda hâlâ giriş yapabilir; yalnızca ücretli özelliklere erişimi kısıtlanmıştır. Hesabın gerçekten kapatılması için ilgili platformda kullanıcıyı devre dışı bırakmak ya da tamamen silmek gerekir.

Proje yönetimi araçları, müşteri ilişkileri yönetimi (CRM) platformları, anlık mesajlaşma araçları, dosya depolama servisleri ve tasarım platformları bu gruba girer. Her birinde şu üç soruyu sormak gerekir: Kullanıcı hesabı aktif mi? Kullanıcı adına oluşturulmuş paylaşım bağlantıları açık mı? Üçüncü taraf entegrasyonlar bu kullanıcının kimliğiyle mi çalışıyor?

Paylaşım bağlantıları özellikle gözden kaçar. Çalışan ayrılmadan önce bir müşteri klasörünü ya da proje panosunu dış bağlantıyla paylaşmış olabilir; bu tür bağlantılar hesap kapatıldıktan sonra da aktif kalabilir, çünkü bağlantı hesapla değil doğrudan dosyayla ilişkilendirilmiştir. Dışarıya açık bağlantıların gözden geçirilmesi ve iptal edilmesi, hesap kapatma işleminin ayrı bir parçasıdır.

Paylaşılan hesaplar ve ekip parolaları

Küçük ekiplerde bazı hesaplar gerçek anlamda paylaşılır: sosyal medya hesabına birden fazla kişi aynı kullanıcı adı ve parola ile giriş yapar, ortak bir e-ticaret paneline tek kimlik bilgisiyle girilir. Eski çalışan bu parolayı biliyorsa yapılması gereken hesabı kapatmak değil, parolayı değiştirmektir.

Parola değişikliği tek başına yeterli olmayabilir. Hesabın kurtarma yöntemlerine de bakmak gerekir: telefon numarası, yedek e-posta adresi ve güvenlik soruları eski çalışana ait olabilir. Özellikle sosyal medya hesaplarında SMS ile kurtarma seçeneği kişisel bir numaraya bağlıysa, bu numara kaldırılmadan hesap tam anlamıyla güvence altına alınmış sayılmaz.

Parola yöneticisi kullanan ekiplerde çözüm daha nettir. Eski çalışanın erişimi olan kasaları belirleyin, bu kasalardaki parolaları değiştirin, ardından çalışanın erişimini kaldırın. Bu sıra önemlidir: parolayı değiştirmeden erişimi kaldırmak, çalışanın daha önce kaydettiği ya da ezberlediği parolayı geçersiz kılmaz.

VPN, sunucu ve geliştirici erişimi

Teknik ekiplerde bu kategori özellikle dikkat gerektirir. VPN sertifikaları, SSH anahtarları, API anahtarları ve servis hesapları standart kullanıcı hesabı kapatma sürecinin dışındadır. SSO üzerinden devre dışı bırakılmış bir kullanıcı, hâlâ geçerli bir SSH anahtarıyla sunucuya erişebilir.

Ayrı ayrı kapatılması gereken nesneler:

API anahtarları en sık atlanan kalemdir. Bu anahtarlar genellikle belgelenmemiş, kişisel projelere karışmış ya da eski konfigürasyon dosyalarına gömülmüş olabilir. Çalışanın ayrılmadan önceki son otuz günde yeni bir API anahtarı oluşturup oluşturmadığını kontrol etmek, riski öne almak için iyi bir başlangıç noktasıdır.

MFA cihazları ve kurtarma yöntemleri

İki aşamalı doğrulama (2FA / MFA) hesabı korur; ama hesap kapatma sürecinde MFA cihazının da sistemden ayrılması gerekir. Aksi halde hesap ilerleyen bir tarihte yeniden etkinleştirilse bile giriş için eski çalışanın telefonu gerekebilir. Paylaşılan hesaplarda bu durum özellikle kilitleme riskine yol açar.

Donanım güvenlik anahtarı kullananlar için fiziksel cihazın geri alınması ve sistemdeki kaydının silinmesi gerekir. Authenticator uygulaması kullananlar için hesabın kayıtlı cihaz listesini temizlemek, yeni bir TOTP kodu üretilememesini sağlar. Kurtarma kodları da bu süreçte geçersiz kılınmalıdır; bazı platformlar kurtarma kodlarını yenilemek için ayrı bir adım gerektirir.

SMS ile doğrulama kullanan hesaplarda çalışanın telefon numarası kurtarma yöntemi olarak kayıtlıysa bu numara kaldırılmalıdır. Hesabın kendi numarasına bağlı olmadığından emin olmak, özellikle paylaşılan iş hesaplarında hesabın gerçekten kuruma ait kalmasını sağlar.

Kapanış günü giriş loglarını okumak

Hesapları kapattıktan sonra kapanış günü ve ertesi günün giriş loglarını incelemek, gözden kaçan erişimleri ortaya çıkarır. Başarısız giriş denemeleri değil, başarılı girişler aranır. Bir hesap kapatıldıktan sonra hâlâ başarılı giriş gösteriyorsa ya işlem tam uygulanmamıştır ya da o hesabın SSO'dan bağımsız alternatif bir giriş yolu vardır.

Logları okurken şu sinyallere bakın: mesai saati dışı başarılı giriş, alışılmadık coğrafi konumdan bağlantı, kapatılan hesapla aynı IP'den başka bir hesaba giriş. Hiçbiri tek başına kesin bir ihlal kanıtı değildir, ama her biri soruşturulması gereken bir işarettir.

Loglar genellikle kimlik sağlayıcısında, e-posta platformunda ve bulut sağlayıcısında ayrı ayrı tutulur. Bu üç kaynağı kapanış günü kontrol etmek, hesapların gerçekten kapandığını doğrulamanın en güvenilir yoludur. Yalnızca işlemi yapmak yetmez; işlemin etkili olduğunu görmek gerekir.

Ayrılma kaydı ve hesap envanteri

Her ayrılma süreci, kapatılan hesapların listesinin belgelenmesiyle tamamlanmalıdır. Bu belge ileride iki amaca hizmet eder: bir güvenlik olayında "o dönemde hangi erişimler açıktı?" sorusuna yanıt verir; yeni bir çalışan benzer rolde başladığında hangi hesapların açılması gerektiğini gösterir.

Belge karmaşık olmak zorunda değildir. Her satırda platform adı, hesap türü, kapatma tarihi ve işlemi yapan kişinin adı yeterlidir. Onboarding sırasında da aynı format kullanılırsa zaman içinde ekibin gerçek erişim haritası oluşur; bu harita sonraki offboarding süreçlerini çok daha hızlı kılar.

Kapatma işleminin gözden geçirilmesi tek kişinin sorumluluğunda bırakılırsa o kişinin gözden kaçırdığı şey de gözden kaçmış olur. İkinci gözün devreye girmesi yani farklı bir ekip üyesinin listeyi tamamlandıktan sonra geçmesi, atlanan maddeleri yakalamak için düşük maliyetli ama etkili bir yöntemdir.

Ekipten ayrılmalar planlı olduğunda bu süreci yönetmek görece kolaydır. Ayrılmanın ani ya da çatışmalı geçtiği durumlarda hız daha kritik hale gelir; ama adımların sırası değişmez. Önce kimlik sağlayıcısı, sonra kritik servisler, ardından paylaşılan hesaplar ve geliştirici erişimleri. Sıra bozulunca en riskli noktalar en sona kalır.

Listenin tamamı ilk seferinde eksiksiz çıkmayabilir. Bir sonraki ayrılmada atlanan bir kategori fark edilir ve listeye eklenir. Zamanla liste ekibe özel hale gelir ve hangi araçların kullanıldığını doğru yansıtır. Mükemmel bir şablon aramak yerine işleyen bir listenin üzerine yeni ayrılmalarda yaşanan deneyimleri eklemek, uzun vadede daha güvenilir bir süreç oluşturur.