Büyük bir kurumun binlerce kullanıcısı, yüzlerce sistemi ve on binlerce erişim yetkisi vardır. Beş yıl önce kredi biriminde olup şimdi pazarlamada çalışan bir çalışan büyük olasılıkla eski yetkilerini hâlâ taşır. Projesi sona ermiş bir yüklenicinin hesabı hâlâ aktif olabilir. Geçici bir entegrasyon için oluşturulan hizmet hesapları, parolası hiç değişmeden yıllarca kalır. Bunların hiçbiri tek başına bir felaket değildir; ancak birlikte, hiçbir denetçinin göz ardı etmeyeceği ve hiçbir güvenlik ekibinin elle yönetemeyeceği bir risk düzeyi oluştururlar.
Burada iki kavramı birbirinden ayırmak esastır. Kimlik ve erişim yönetimi (IAM), bu kişinin iddia ettiği kişi olup olmadığı ve şu anda bu işlemi yapmaya yetkili olup olmadığı sorusunu yanıtlar: kimlik doğrulama, tek oturum açma, çok faktörlü doğrulama ve token üretimi. Kimlik yönetişimi ve yönetimi (IGA) ise daha derin bir soruyu ele alır: bu kişinin bu erişime hiç sahip olması gerekip gerekmediği, bunu kimin onayladığı ve ne zaman gözden geçirilmesi gerektiği. Yalnızca IAM'e sahip kurumlar ön kapıyı iyi kilitler, ancak kime anahtar verildiğine dair hiçbir kayıtları yoktur.
Tercih edilen mimari, ikisini tek bir ortak kimlik kaynağı üzerinde birbirini tamamlayan katmanlar olarak tasarlar. Merkezde, İK sistemi ve taraf ana verisiyle beslenen ve her kimliği işe girişten ayrılışa kadar yaşam döngüsü boyunca izleyen bir kimlik dizini bulunur. OpenID Connect ve SAML gibi açık standartlar üzerine kurulan IAM katmanı, her uygulama, API ve ajan için kimlik doğrulama ve token üretimini üstlenir. IGA katmanı rolleri, politikaları, talep ve onay iş akışlarını, periyodik erişim gözden geçirmelerini ve görevler ayrılığını yönetir ve sonucu hedef sistemlere somut yetkiler olarak aktarır.
İlk pratik husus rol modelinin tasarımıdır. Roller mevcut erişimlerden değil, kurumun gerçek yapısından ve iş tanımlarından türetilmelidir; aksi hâlde geçmişte biriken tüm fazla yetkiler rol olarak resmîleştirilir. Uygulanabilir bir yaklaşım, birim ve pozisyona göre atanan temel rolleri bireysel olarak talep edilen yetkilerle birleştirir. Örneğin her şube çalışanı şube temel rolünü otomatik olarak alır, ancak tanımlı bir eşiğin üzerindeki kredileri onaylama erişimi bir talep, yönetici onayı ve bir bitiş tarihi gerektirir.
İkinci husus yaşam döngüsünün otomasyonudur. En etkili güvenlik kontrolü erişimi zamanında kaldırmaktır ve bu ancak İK olaylarına bağlandığında güvenilir olur. Bir çalışanın kaydı ayrılan statüsüne geçtiğinde hesaplar o anda devre dışı bırakılmalı, tokenlar iptal edilmeli ve yetkiler geri alınmalıdır. Birimler arası bir nakil, yalnızca yeni rolü eskisinin üzerine eklemekle kalmamalı, eski rolü kaldırıp yenisini vermelidir. Bu olay güdümlü bağlantı, güvenlik ekibinin iş yükünü manuel gözden geçirmeden istisnaların denetimine kaydırır.
Üçüncü husus insan dışı kimliklerdir. Hizmetler, zamanlanmış işler, IoT cihazları ve giderek artan biçimde YZ ajanları bir kimliğe, bir yetki setine ve adı belirli bir sahibe ihtiyaç duyar. Bu kimlikler insan kullanıcılarla aynı yaşam döngüsünden ve aynı periyodik gözden geçirmeden geçmelidir. Bir kullanıcı adına hareket eden bir ajan dar kapsamlı ve kısa ömürlü bir token taşımalı ve yaptığı her işlem hem ajana hem de kullanıcıya atfedilmelidir; böylece denetim izi hiçbirini kaybetmez.
Bu alandaki tuzaklar çoktur. Birincisi, veri modeli ve süreç yerine bir araçla başlamak; hiçbir ürün, kimsenin tanımlamadığı rolleri tanımlayamaz. İkincisi, yöneticilerin her şeyi okumadan onayladığı göstermelik erişim gözden geçirmeleri; çözüm, her yetkinin en son ne zaman kullanıldığı gibi bağlamı göstermek ve her gözden geçirmeyi kısa tutmaktır. Üçüncüsü, standart arayüzleri olmayan ve hâlâ dosyalar ve doğrudan veritabanı erişimiyle yönetilen eski sistemleri göz ardı etmek. Dördüncüsü, IAM ve IGA'yı ilk değerini sunmadan güvenilirliğini yitiren tek bir devasa projede birleştirmek.
Niadad'da Shanasa platformu («شناسا») açık standartlara dayalı kimlik ve erişim katmanını sağlar: kullanıcılar, hizmetler ve ajanlar için merkezi kimlik doğrulama, tek oturum açma, çok faktörlü doğrulama ve token üretimi. Parsa platformu («پارسا») politika ve yönetişim katmanını üstlenir: rol ve erişim politikası tanımı, talep ve onay iş akışları, periyodik gözden geçirmeler ve görevler ayrılığı. Niadad'ın bankacılık programında bu ikisi, Ashna taraf ana verisi ve API ağ geçidinin yanında yer alır; böylece kimlik, kaynaktan uygulama noktasına kadar tutarlı tek bir zincir olarak yönetilir.
Kurumsal güvenlik sonuçta tek bir basit soruya dayanır: herhangi bir anda kimin neye ve neden erişimi olduğunu söyleyebiliyor musunuz? IAM "kim" sorusunu, IGA ise "neden" sorusunu yanıtlar. Her ikisine de sahip bir kurum yalnızca denetimlerden geçmekle kalmaz, sistemlerini kontrolü kaybetmeden yeni kullanıcılara, iş ortaklarına ve ajanlara güvenle açabilir. Bu iş hiçbir zaman bitmez, çünkü kurumlar değişmeye devam eder; ancak doğru mimariyle ayak uydurmak periyodik bir acil durum olmaktan çıkar ve rutine dönüşür.