İnsan Olmayan Kimlikleri Kim Yönetiyor? | RSA Identity Security #13

Machine & Non-Human Identities: İnsan Olmayan Kimlikleri Kim Yönetiyor?

Bir çalışanın kurumdan ayrılması durumunda ne yapılacağı genellikle bellidir. Kullanıcı hesabı kapatılır. Erişimleri kaldırılır. Yetkileri iptal edilir.

Peki ya kurum içinde çalışan ama hiçbir insana ait olmayan binlerce kimlik?

Servis hesapları, uygulamalar, API'ler, botlar, otomasyon araçları, cloud workload'ları ve sistemler arası entegrasyonlar da her gün kritik kaynaklara erişiyor.

Üstelik çoğu zaman insan kullanıcılarından çok daha uzun süre aktif kalıyorlar.

Kimlik güvenliğinin yeni sorusu artık yalnızca “Hangi kullanıcı erişiyor?” değil.

“Hangi makine, uygulama veya servis erişiyor ve neden?”

Her Kimlik Bir İnsan Değildir

Modern BT ortamlarında sistemler sürekli olarak birbirleriyle iletişim kuruyor.

Bir uygulama veritabanına bağlanıyor. Bir API başka bir servisten veri çekiyor. Bir automation platformu altyapıda değişiklik yapıyor. Bir cloud workload başka bir kaynağa erişiyor. Bir servis hesabı kritik bir uygulamayı çalıştırıyor.

Bu işlemlerin gerçekleşebilmesi için kullanılan dijital kimlikler genel olarak Non-Human Identities (NHI) veya Machine Identities olarak tanımlanıyor.

Örneğin;

• Service account'lar,

• Application identity'ler,

• API identity'leri,

• Bot ve automation account'ları,

• Cloud workload identity'leri,

• Container ve microservice identity'leri,

• Sistemler arası entegrasyon hesapları.

Bunların hiçbiri insan değil. Ancak sahip oldukları erişim hakları son derece gerçek.

Görünmeyen Kimlikler, Görünmeyen Riskler

Non-human identity'lerin en önemli problemlerinden biri zaman içinde görünmez hâle gelebilmeleridir.

Bir servis hesabı yıllar önce oluşturulmuş olabilir. Bir proje için açılan API erişimi proje bittikten sonra hâlâ aktif olabilir. Bir uygulama hesabına gereğinden fazla yetki verilmiş olabilir. Bir entegrasyon kaldırılmış ancak ona ait kimlik veya erişim bilgileri sistemde kalmış olabilir.

Sonuç olarak kurum içinde;

• Sahibi bilinmeyen hesaplar,

• Kullanılmayan ancak aktif kimlikler,

• Gereğinden fazla yetkiye sahip servis hesapları,

• Süresi dolmayan erişim bilgileri,

• Kim tarafından oluşturulduğu bilinmeyen entegrasyonlar

zamanla ciddi bir saldırı yüzeyi oluşturabilir.

Bir Servis Hesabının Parolası Ne Zaman Değişti?

İnsan kullanıcılarında parola politikaları, MFA ve erişim kontrolleri artık standart güvenlik uygulamaları arasında. Machine identity'lerde ise durum her zaman bu kadar kontrollü değil.

Bazı servis hesapları uzun süre aynı credential ile çalışabilir. API key'ler kod içerisinde saklanabilir. Secret ve token'lar farklı sistemlerde kontrolsüz şekilde bulunabilir.

Daha da önemlisi, bu kimlikler çoğu zaman arka planda çalıştığı için normal kullanıcı hesapları kadar görünür değildir.

Bu nedenle yalnızca credential'ı korumak yeterli değildir. Asıl ihtiyaç, non-human identity'nin kendisini ve yaşam döngüsünü yönetmektir.

Machine Identity'lerin de Bir Yaşam Döngüsü Olmalı

İnsan kullanıcılarında olduğu gibi non-human identity'ler için de temel sorular cevaplanabilmelidir:

• Bu kimlik neden oluşturuldu?

• Hangi uygulama veya servis tarafından kullanılıyor?

• Sahibi kim?

• Hangi sistemlere erişebiliyor?

• Hangi yetkilere sahip?

• Hâlâ gerekli mi?

• En son ne zaman kullanıldı?

Bir machine identity oluşturulduğu andan kaldırıldığı ana kadar görünür ve yönetilebilir olmalıdır.

Bu yaklaşım sayesinde unutulmuş hesapların ve gereksiz erişimlerin kalıcı güvenlik risklerine dönüşmesi önlenebilir.

Least Privilege Yalnızca İnsanlar İçin Değildir

Bir uygulamanın çalışması için belirli bir veritabanına erişmesi gerekiyorsa, neden tüm veritabanlarına erişebilsin?

Bir automation hesabının belirli bir işlemi gerçekleştirmesi gerekiyorsa, neden sürekli geniş yönetici yetkilerine sahip olsun?

Least Privilege prensibi machine identity'ler için de geçerlidir.

Her servis, uygulama veya workload yalnızca görevini gerçekleştirmek için ihtiyaç duyduğu kaynaklara ve yetkilere erişebilmelidir.

Böylece bir machine identity ele geçirilse bile saldırganın hareket alanı sınırlandırılabilir.

AI ve Otomasyon Bu Problemi Daha da Büyütüyor

Cloud-native mimariler, DevOps, API ekonomisi ve otomasyon zaten çok sayıda non-human identity oluşturuyordu. Şimdi buna AI sistemleri ve AI agent'ları da ekleniyor.

Bir AI agent; uygulamalara bağlanabilir, veriye erişebilir, API çağrıları yapabilir, iş süreçlerini başlatabilir ve bazı durumlarda sistemler üzerinde işlem gerçekleştirebilir.

Bu da Identity Security açısından yeni bir soruyu gündeme getiriyor:

Bir insan tarafından gerçekleştirilmeyen ancak kurum adına işlem yapan dijital kimliklerin erişimini nasıl yöneteceğiz?

Kimlik güvenliği stratejilerinin artık yalnızca çalışanları değil, kurum adına işlem yapabilen tüm dijital kimlikleri kapsaması gerekiyor.

Identity Security'nin Kapsamı Genişliyor

Modern kurumlarda kimlik ekosistemi artık yalnızca çalışanlardan oluşmuyor.

İnsanlar, cihazlar, uygulamalar, servisler, workload'lar, botlar ve AI agent'ları aynı dijital ekosistem içerisinde kaynaklara erişiyor.

Bu nedenle Identity Security'nin temel prensipleri;

Discover → Identify → Authenticate → Authorize → Monitor → Govern

yalnızca insan kullanıcılarına değil, non-human identity'lere de uygulanmalıdır.

Çünkü saldırgan açısından hesabın arkasında bir insanın veya uygulamanın bulunması önemli değildir. Önemli olan o kimliğin hangi kaynaklara erişebildiğidir.

Key Takeaway

Kurumunuzdaki en kritik kimliklerden bazıları hiçbir çalışana ait olmayabilir.

Service account'lar, API'ler, uygulamalar, workload'lar, botlar ve AI agent'ları kritik sistemlere erişirken çoğu zaman insan kullanıcılarından daha az görünür olabilir.

Modern Identity Security yalnızca “Kim erişiyor?” sorusunu değil, “İnsan olsun veya olmasın, hangi kimlik neye erişiyor, neden erişiyor ve bu erişime hâlâ ihtiyacı var mı?” sorusunu da cevaplayabilmelidir.

RSA Thursday | Identity Security Series #13

Prepared by Zero Second

Helping organizations secure every identity, human and non-human