# IGA Nedir? Identity Governance and Administration, Access Review ve Yetki Yönetimi **URL:** https://securesys.com.tr/tr/bilgi-merkezi/kimlik-ve-erisim-yonetimi/iga-nedir-identity-governance ![IGA Nedir? Identity Governance and Administration, Access Review ve Yetki Yönetimi](/images/bilgi-merkezi/covers/cover-pamiam-05.webp) Kurumsal yapılarda kimlik ve erişim yönetimi yalnızca kullanıcıların sisteme giriş yapmasını sağlamak veya administrator hesaplarını korumakla sınırlı değildir. Bir çalışanın hesabı doğru şekilde oluşturulmuş, MFA ile korunmuş ve kurumsal uygulamalara güvenli biçimde erişiyor olabilir. Ancak bu kullanıcının sahip olduğu yetkilerin hâlâ gerekli olup olmadığı ayrı bir sorudur. İşte **IGA – Identity Governance and Administration**, tam olarak bu problemi ele alır. IAM, kullanıcıların kimlik doğrulamasını ve erişim yaşam döngüsünü yönetir. PAM, yüksek yetkili privileged access'i kontrol altına alır. IGA ise kimliklerin sahip olduğu yetkilerin gerçekten gerekli, doğru, uygun ve denetlenebilir olup olmadığını değerlendirir. Bu nedenle modern Identity Security mimarisinde IGA şu soruya cevap verir: **“Bir kullanıcının bu erişime gerçekten ihtiyacı var mı ve bu erişim hâlâ doğru mu?”** Bu soru özellikle binlerce çalışan, yüzlerce uygulama, cloud services, SaaS platforms ve çok sayıda role sahip büyük kurumlarda kritik hale gelir. Çünkü zaman içerisinde kullanıcılar rol değiştirir, departman değiştirir, farklı projelere katılır, geçici yetkiler alır ve yeni applications kullanmaya başlar. Eğer eski erişimler düzenli olarak kaldırılmazsa kullanıcıların üzerinde gereğinden fazla permission birikmeye başlar. Bu durum **Permission Creep**, **Privilege Creep** veya **Access Accumulation** olarak adlandırılabilir. IGA'nın temel amacı bu birikimi görünür hale getirmek, access riskini azaltmak ve kurumun yetki modelini sürekli olarak kontrol altında tutmaktır. ### IGA Nedir ve IAM'den Nasıl Ayrılır? Identity Governance and Administration, kimliklerin ve erişim haklarının yaşam döngüsünü yönetirken aynı zamanda governance, compliance ve risk kontrolleri uygulayan teknoloji ve süreçlerin bütünüdür. IAM daha operasyonel bir yapı olarak düşünülebilir. Örneğin: Yeni çalışan başlar. Hesap açılır. E-mail verilir. SSO sağlanır. MFA aktif edilir. Belirli application access'leri atanır. Bu süreç IAM tarafından yönetilebilir. IGA ise daha sonra şunu sorar: #### Bu kullanıcının sahip olduğu yetkilerin tamamı hâlâ gerekli mi? Örneğin kullanıcı bir yıl önce Finance departmanında çalışmış olabilir ve financial reporting application'a erişim kazanmıştır. Daha sonra Sales departmanına geçmiştir. Yeni Sales permissions eklenmiştir ancak Finance access kaldırılmamıştır. Teknik olarak kullanıcı hesabı doğru çalışmaktadır. Ancak governance açısından risk vardır. IGA bu nedenle yalnız access provisioning değil, access doğruluğunu ve sürdürülebilirliğini yönetir. Basitleştirirsek: **IAM → Access verir.** **IGA → Access'in doğru olup olmadığını kontrol eder.** **PAM → Yüksek yetkili access'i daha sıkı korur.** Bu üç yapı modern identity architecture içerisinde birlikte çalışır. ### Identity Governance Neden Gereklidir? Bir kurum büyüdükçe yetkiler karmaşık hale gelir. Küçük bir şirkette bir yöneticinin hangi kullanıcının hangi application'a eriştiğini bilmesi kolay olabilir. Ancak binlerce employee bulunan bir organization'da tek bir user onlarca veya yüzlerce entitlement'a sahip olabilir. Örneğin bir employee: Microsoft 365 ERP CRM HR Application File Share Cloud Storage Database Reporting BI Platform Project Management VPN Git Repository gibi systems'a erişebilir. Bu access'lerin her biri farklı permissions içerebilir. Read Write Export Admin Approve Create Delete gibi entitlement'lar oluşabilir. Kullanıcı role değiştirdikçe yeni permissions eklenir. Eski permissions kaldırılmazsa risk giderek büyür. Bu nedenle Identity Governance yalnız compliance ihtiyacı değil, doğrudan security requirement'tır. ### Entitlement Nedir? IGA dünyasında en önemli kavramlardan biri **Entitlement**'dır. Entitlement bir identity'nin belirli bir resource üzerinde sahip olduğu access right veya permission'dır. Örneğin: “SAP Finance Read” “Salesforce Admin” “SharePoint Confidential Library Access” “Database Export Permission” birer entitlement olabilir. Bir kullanıcının sahip olduğu toplam access rights onun entitlement profile'ını oluşturur. IGA'nın görevi bu entitlement'ları inventory haline getirmek ve şu soruları sormaktır: Bu erişimi kim verdi? Ne zaman verildi? Business justification var mı? Owner kim? Ne kadar süre geçerli? Hâlâ gerekli mi? Risk seviyesi nedir? Bu visibility olmadan access governance uygulanamaz. ### Access Review Nedir? Access Review, kullanıcıların mevcut erişimlerinin hâlâ gerekli olup olmadığını periyodik olarak değerlendirme sürecidir. Örneğin her üç ayda bir manager'a çalışanlarının erişimleri gösterilebilir. Manager: Approve Revoke Modify kararı verebilir. Bu basit görünse de büyük kurumlarda binlerce access decision ortaya çıkabilir. Bu nedenle IGA platformları access review süreçlerini otomatikleştirir. Örneğin manager'a: “Ahmet hâlâ Finance Reporting Access'e ihtiyaç duyuyor mu?” sorusu yöneltilir. Manager access'i onaylayabilir veya revoke edebilir. Bu işlem audit trail ile kaydedilir. Böylece kurum access governance sürecini belgeleyebilir. ### Access Certification Nedir? Access Certification, kullanıcıların sahip olduğu access rights'ın belirli yetkili kişiler tarafından resmi şekilde doğrulanmasıdır. Bu süreç compliance açısından özellikle önemlidir. Örneğin: Financial System Access Privileged Application Access Critical Data Access gibi entitlement'lar belirli aralıklarla certification'a tabi tutulabilir. Certification yalnız manager tarafından yapılmak zorunda değildir. Resource Owner Application Owner Data Owner Security Team gibi farklı approvers kullanılabilir. Bu şekilde access responsibility dağıtılmış olur. ### Manager Review Her Zaman Yeterli midir? Hayır. Manager çalışanının ne iş yaptığını bilir ancak uygulamadaki permission'ın teknik anlamını bilmiyor olabilir. Örneğin: FIN_AP_47 şeklinde bir role görür. Manager bunun ne anlama geldiğini bilmiyorsa access review formaliteye dönüşebilir. Bu nedenle entitlement names business-friendly hale getirilmelidir. Örneğin: FIN_AP_47 yerine: **“Vendor Payment Approval – Level 2”** gibi açıklayıcı naming kullanılabilir. IGA'nın başarısı yalnız access review ekranı sunmakla değil, decision maker'ın doğru karar verebileceği context'i sağlamasıyla ölçülür. ### Role-Based Access Control ve IGA IGA environments içerisinde RBAC yani **Role-Based Access Control** önemli bir governance modelidir. User'a her permission ayrı ayrı verilmek yerine role atanır. Örneğin: Finance Analyst Sales Representative HR Specialist Database Administrator gibi roles tanımlanabilir. Her role belirli entitlement set içerir. Bu sayede provisioning ve governance kolaylaşır. Ancak role design dikkatli yapılmalıdır. Çok geniş roles aşırı permission verebilir. Çok fazla küçük role ise **Role Explosion** oluşturabilir. Bu nedenle role engineering ve role governance IGA'nın önemli alanlarından biridir. ### Role Mining Nedir? Role Mining, mevcut user permissions'ı analiz ederek benzer access patterns üzerinden role önerileri oluşturmayı amaçlar. Örneğin organization'da 150 Sales employee'nin büyük bölümü aynı 12 application permission'ını kullanıyor olabilir. IGA analytics bu pattern'i tespit ederek: #### Sales Standard Role oluşturulmasını önerebilir. Bu access model'in standardize edilmesini sağlar. Ancak mevcut permissions zaten yanlış veya aşırı ise role mining bu yanlışlığı role haline getirebilir. Bu nedenle role mining sonuçları business ve security teams tarafından review edilmelidir. ### Birthright Access Nedir? Birthright Access, user'ın organization'a katıldığında job role veya employee type nedeniyle otomatik aldığı temel access rights'tır. Örneğin her employee: Corporate E-mail Intranet Collaboration Platform Basic HR System access alabilir. Bu access'lerin otomatik verilmesi onboarding sürecini hızlandırır. Ancak birthright permissions minimum seviyede tutulmalıdır. Özellikle sensitive data veya privileged actions birthright access olarak verilmemelidir. Temel yaklaşım: **Default Access = Minimum Required** olmalıdır. ### Access Request Management Nedir? User ihtiyaç duyduğu additional access için request oluşturabilir. Örneğin: “Project X SharePoint Access” veya: “Financial Reporting Read Access” talep edebilir. IGA platformu request'i workflow üzerinden ilgili approver'a yönlendirebilir. Approval sürecinde: Business Justification Manager Approval Resource Owner Approval Risk Check SoD Check gibi kontroller uygulanabilir. Bu manuel e-mail ve ticket-based access management'e göre daha kontrollü bir model sağlar. ### Access Request Süreli Olmalı mı? Birçok access request permanent olarak verilir. Bu zaman içerisinde excessive permissions oluşturabilir. Daha güvenli model access'i mümkün olduğunda time-bound hale getirmektir. Örneğin: Project Access = 90 gün External Consultant Access = 30 gün Temporary Finance Role = 14 gün süre sonunda access otomatik expire olabilir. Bu yaklaşım PAM'deki JIT Access ile benzer security principle taşır. **Gerekli erişim yalnız gerekli süre boyunca verilmelidir.** ### Segregation of Duties – SoD Nedir? Segregation of Duties, yani Görevlerin Ayrılığı, kritik business process'in tek kişi tarafından tamamen kontrol edilmesini engellemeyi amaçlar. Örneğin bir financial process içerisinde aynı user'ın: Vendor Create ve Payment Approve permissions'ına sahip olması fraud riskini artırabilir. Bu iki entitlement ayrı ayrı normal olabilir. Ancak birlikte risk oluştururlar. IGA platformu bu **toxic combination** ilişkilerini tespit edebilir. Access request sırasında user yeni role talep ettiğinde system mevcut permissions ile conflict olup olmadığını kontrol edebilir. Bu sayede access verilmeden önce SoD violation önlenebilir. #### Toxic Combination Nedir? Toxic Combination, ayrı ayrı kabul edilebilir permissions'ın birlikte kullanıldığında yüksek risk oluşturmasıdır. Örneğin: Create User Assign Administrator Role kombinasyonu yüksek riskli olabilir. Başka örnek: Create Vendor Approve Payment veya: Create Purchase Order Approve Purchase Order olabilir. IGA'nın önemli capabilities'inden biri bu relationships'ı görünür hale getirmektir. Çünkü yalnız permission listesine bakıldığında risk fark edilmeyebilir. #### Preventive ve Detective SoD SoD iki farklı şekilde uygulanabilir. **Preventive SoD**, riskli permission combination oluşmadan önce access request'i engeller. Örneğin user Payment Approver ise Vendor Creator role talebi block edilir. **Detective SoD** ise mevcut systems üzerinde bulunan conflicts'i tespit eder. Örneğin geçmişten kalan toxic combination raporlanır ve remediation başlatılır. Mature IGA architecture iki yaklaşımı birlikte kullanabilir. ### Permission Creep Nasıl Oluşur? Permission Creep çoğunlukla kötü niyetli bir işlem sonucu oluşmaz. Organizasyonel değişikliklerin doğal sonucudur. Employee işe başlar. Beş applications access alır. Altı ay sonra yeni project'e katılır. Üç yeni permission eklenir. Bir yıl sonra role değiştirir. Yeni role için yedi permission daha eklenir. Eski permissions'ın bir kısmı kaldırılmaz. Üç yıl sonra user'ın gerçek görevinden çok daha geniş access footprint'i oluşur. Bu durum attacker account'u compromise ettiğinde impact'i büyütür. Dolayısıyla IGA'nın güvenlik faydası yalnız compliance değildir. **Compromise Impact Reduction** sağlar. ### Joiner-Mover-Leaver ile IGA İlişkisi IAM Joiner-Mover-Leaver process'i automate edebilir. Ancak IGA bu lifecycle'ın governance kısmını güçlendirir. Joiner aşamasında role-based birthright access verilebilir. Mover aşamasında eski permissions otomatik review edilebilir. Leaver aşamasında tüm entitlement'lar revoke edilebilir. Özellikle Mover process kritik öneme sahiptir. Çünkü organization içinde role değiştiren user'ın account'u kapatılmaz. Bu nedenle eski access kolayca unutulabilir. IGA mover event'i trigger olarak kullanarak: Current Access Review Old Role Removal New Role Assignment SoD Check yapabilir. Bu access accumulation'ı azaltır. ### Orphaned Access Nedir? Orphaned Account kavramına benzer şekilde, owner veya business need'i kalmamış access rights da olabilir. Örneğin project sona ermiştir ancak project group permissions hâlâ users üzerinde bulunur. Application owner değişmiştir ve entitlement'ın ne işe yaradığı artık bilinmemektedir. Bu durum **orphaned entitlement** veya unmanaged access problemine dönüşebilir. IGA düzenli access review ve entitlement ownership ile bu riski azaltır. ### Entitlement Owner Neden Önemlidir? Her sensitive access right için business owner belirlenmesi governance açısından önemlidir. Security team her application permission'ın business impact'ini bilemeyebilir. Örneğin: “Refund Approval Level 3” permission'ının kimlere verilmesi gerektiğini Finance process owner daha iyi bilir. IGA bu nedenle access responsibility'yi yalnız IT üzerinde bırakmaz. Business ownership oluşturur. Bu access governance'ın en önemli kültürel dönüşümlerinden biridir. ### IGA ve Privileged Access Nasıl Birlikte Çalışır? PAM privileged access'in nasıl kullanılacağını kontrol eder. IGA ise bu privileged access'in kimin üzerinde bulunması gerektiğini govern eder. Örneğin user: Database Administrator Role için eligible olabilir. IGA: Bu user'ın role sahip olmaya business requirement'ı var mı? SoD conflict var mı? Access review yapıldı mı? sorularını yönetir. PAM ise: Role ne zaman activate edilecek? MFA uygulandı mı? Session kaydedilecek mi? Privilege ne zaman expire olacak? sorularını yönetir. Bu iki katman birlikte çalıştığında daha güçlü privileged identity governance sağlanır. ### IGA ve Cloud IAM İlişkisi Cloud environments entitlement sayısını ciddi şekilde artırabilir. AWS, Azure ve Google Cloud gibi platforms granular permission models sunar. Tek bir cloud identity yüzlerce action permission'a sahip olabilir. Bu durum access governance'ı zorlaştırır. IGA cloud identities ve roles'i governance kapsamına alabilir. Ancak cloud permission optimization için CIEM capabilities de gerekebilir. IGA daha çok: #### Kim hangi access'e sahip olmalı? sorusuna odaklanırken CIEM: #### Cloud üzerinde hangi permissions gerçekten kullanılıyor ve hangileri gereksiz? sorusuna daha derin cevap verebilir. Bu nedenle modern Identity Security Architecture içerisinde IGA ve CIEM birbirini tamamlar. ### IGA ve CIEM Arasındaki Fark IGA organization genelindeki identity governance'a odaklanır. Human identities, applications ve enterprise entitlements yönetilebilir. CIEM ise özellikle cloud infrastructure entitlements üzerinde visibility ve optimization sağlar. Örneğin cloud role 150 permission içeriyor ancak user son 90 günde yalnız 8 permission kullanmış. CIEM bu excessive permission'ı tespit edebilir. IGA ise bu role'ün user'a atanmasının business olarak uygun olup olmadığını evaluate edebilir. Bu iki perspective birlikte Least Privilege yaklaşımını güçlendirir. ### IGA ve Non-Human Identity IGA geleneksel olarak human workforce identities üzerinde yoğunlaşmıştır. Ancak modern organizations içerisinde service accounts, bots, workloads ve AI Agents giderek daha fazla access kullanmaktadır. Bu identities için de governance gerekir. Örneğin service account: Kim tarafından oluşturuldu? Owner kim? Hangi application kullanıyor? Hangi permissions'a sahip? Ne kadar süredir aktif? Hâlâ gerekli mi? Bu sorular human identity için ne kadar önemliyse NHI için de o kadar önemlidir. Bu nedenle modern Identity Governance scope'u: #### Human Identity Governance modelinden: #### Human + Machine Identity Governance modeline doğru genişlemektedir. ### AI Agent Governance ve IGA Agentic AI, IGA açısından yeni bir governance problemi ortaya çıkarmaktadır. Bir AI Agent user adına applications'a erişebilir. CRM record değiştirebilir. File okuyabilir. API kullanabilir. Financial workflow başlatabilir. Bu durumda agent'a verilen entitlements da governance kapsamına alınmalıdır. Örneğin: Agent hangi user adına çalışıyor? Agent'ın kendi identity'si var mı? Hangi applications'a erişebilir? Hangi actions yapabilir? Permission permanent mı? Business owner kim? Approval gerekiyor mu? Audit trail tutuluyor mu? Bu soruların cevapları geleceğin **AI Identity Governance** modelini oluşturacaktır. AI Agent'a permission verirken traditional RBAC tek başına yeterli olmayabilir. Context-aware ve task-specific authorization gerekebilir. Örneğin agent: “invoice read” yapabilir ancak: “payment approve” yapamaz. Bu fine-grained authorization ve governance yaklaşımı Identity Security'nin yeni gelişen alanlarından biridir. ### Risk-Based Access Review Nedir? Traditional access review cycles bütün users için aynı olabilir. Örneğin yılda bir kez tüm access'ler review edilir. Ancak bu yaklaşım high-risk permissions için yeterli olmayabilir. Risk-Based Access Review yaklaşımında entitlement'ın risk seviyesine göre review frequency değişir. Örneğin: Low Risk Access → Yıllık Review Sensitive Data Access → Quarterly Review Privileged Access → Monthly veya Event-Based Review uygulanabilir. Bu security resources'ın kritik access'lere odaklanmasını sağlar. ### Event-Driven Access Review Modern IGA yalnız calendar-based certification ile sınırlı olmak zorunda değildir. Belirli events review trigger edebilir. Örneğin: Department Change Manager Change High-Risk Sign-In New Privileged Role Long Dormancy Project Completion olduğunda access review otomatik başlatılabilir. Bu static governance modelinden dynamic governance modeline geçiştir. ### Usage-Based Access Governance User'ın sahip olduğu entitlement yıllardır aktif olabilir ancak hiç kullanılmıyor olabilir. Bu durumda şu soru sorulmalıdır: #### Kullanılmayan access neden açık kalıyor? Usage analytics IGA ile entegre edildiğinde unused access rights tespit edilebilir. Örneğin user 180 gündür application'a login olmamışsa access certification trigger edilebilir. Bu Least Privilege yaklaşımını daha data-driven hale getirir. ### AI Destekli Role Mining ve Access Recommendation Modern IGA platforms analytics ve machine learning kullanarak access decisions konusunda öneriler oluşturabilir. Örneğin similar role'deki employees'ın büyük bölümü belirli application access'e sahipken yeni employee'da access yoksa recommendation oluşturulabilir. Tersi durumda user'ın peers'larına kıyasla unusual permissions'a sahip olduğu tespit edilebilir. Bu **Peer Group Analysis** ve **Access Intelligence** yaklaşımıdır. Ancak AI recommendation nihai authorization decision olarak görülmemelidir. Özellikle high-risk access için human governance korunmalıdır. AI: #### Decision Support sağlamalı, otomatik broad privilege üretmemelidir. ### Access Intelligence Nedir? Access Intelligence, identity, entitlement, usage ve risk data'sını analiz ederek erişim hakkında daha anlamlı context oluşturmayı amaçlar. Örneğin user'ın bir permission'a sahip olması tek başına bilgi verir. Ancak şu bilgiler birlikte değerlendirildiğinde daha güçlü insight oluşur: User'ın role'ü nedir? Peers bu permission'a sahip mi? Permission ne kadar süredir kullanılmıyor? Sensitive resource mu? SoD conflict yaratıyor mu? User high-risk identity mi? Bu context access review kalitesini artırabilir. ### IGA Platformları Hangi İşlevleri Sağlar? Kurumsal IGA platforms genel olarak şu capabilities etrafında konumlanabilir: Identity Lifecycle Governance Access Request Access Certification Role Management Entitlement Management SoD Access Analytics Automated Provisioning Policy Enforcement gibi alanlar. SailPoint, Saviynt ve One Identity gibi platformlar enterprise Identity Governance use case'leri için bilinen çözümler arasındadır. Ancak ürün seçimi yalnız feature comparison üzerinden yapılmamalıdır. Özellikle: application integration, entitlement volume, identity count, workflow complexity, cloud strategy, PAM integration, HR integration, custom applications gibi architecture requirements değerlendirilmelidir. IGA projesinin en zor tarafı çoğu zaman ürünü kurmak değil, kurumun dağınık entitlement modelini anlamlı ve yönetilebilir hale getirmektir. ### SailPoint, Saviynt ve One Identity Nasıl Konumlanır? SailPoint enterprise identity governance alanında access certification, lifecycle, entitlement governance ve role-based governance gibi use case'lerle yaygın olarak ilişkilendirilen platformlardan biridir. Saviynt cloud-oriented identity governance ve application entitlement governance use case'leriyle değerlendirilebilir. One Identity ise identity governance ve privileged access dahil farklı identity security capabilities sunan ürün ailesine sahiptir. Bu ürünlerin hangisinin uygun olduğu: on-premises ve cloud distribution, application landscape, ERP integration, workflow requirements, PAM ecosystem, identity volume gibi factors'a göre değişebilir. Burada amaç vendor ranking yapmak değil, IGA'nın ürün kategorisini anlamaktır. ### IGA Projesi Nasıl Başlatılmalıdır? Başarılı IGA projesinin ilk adımı bütün applications'ı tek seferde governance platformuna bağlamak olmamalıdır. Öncelikle high-risk business systems belirlenebilir. Örneğin: ERP Financial Applications HR Critical Databases Privileged Systems önceliklendirilebilir. Daha sonra entitlement inventory oluşturulur. Permissions business-friendly isimlerle tanımlanır. Owners belirlenir. Access review workflow'ları tasarlanır. SoD rules oluşturulur. Role model geliştirilir. Bu şekilde IGA gradual olarak genişletilir. ### IGA ve HR Entegrasyonu Neden Önemlidir? HR system çoğu organization için workforce identity lifecycle'ın authoritative source'u olabilir. Yeni employee HR'da oluşturulduğunda Joiner process başlar. Department değiştiğinde Mover process trigger edilir. Termination gerçekleştiğinde Leaver process başlatılır. Bu nedenle IGA ve HR integration güçlü lifecycle governance sağlar. Ancak HR data'nın doğruluğu kritiktir. Yanlış department veya manager information yanlış access decisions'a neden olabilir. Bu nedenle Identity Governance aynı zamanda data quality problemidir. ### Access Review Fatigue Nedir? Manager'a yüzlerce entitlement gönderildiğinde her birini dikkatlice review etmesi zorlaşır. User hızlı şekilde: Approve All yapabilir. Bu **Access Review Fatigue** olarak düşünülebilir. Review process çok fazla noise üretiyorsa governance formaliteye dönüşür. Bu nedenle intelligent scoping uygulanmalıdır. Özellikle: High-Risk Access Unusual Access Unused Access SoD Conflicts Privileged Access önceliklendirilebilir. Low-risk standard birthright permissions ayrı process ile yönetilebilir. Bu şekilde review kalitesi yükseltilir. ### Rubber-Stamp Approval Riski Access review sürecindeki diğer önemli risk **Rubber-Stamp Approval**'dır. Reviewer entitlement'ların tamamını anlamadan sürekli approve edebilir. Bunun önüne geçmek için: Business-friendly descriptions, risk scores, usage information, peer comparison, last access date gibi context gösterilebilir. Örneğin reviewer şu bilgiyi görürse: **“Bu kullanıcı bu erişimi 14 aydır kullanmadı.”** revoke kararı vermesi kolaylaşabilir. ### IGA ve Compliance IGA birçok regulatory ve compliance requirement açısından da değer sağlar. Kurumlar belirli systems'a kimlerin access ettiğini, access'in kim tarafından onaylandığını ve ne zaman review edildiğini göstermek zorunda olabilir. IGA bu süreçler için audit trail oluşturur. Ancak IGA yalnız audit sırasında kullanılacak compliance tool olarak görülmemelidir. Doğru uygulandığında attack surface'i azaltır. Çünkü gereksiz access'in kaldırılması attacker'ın compromised identity üzerinden ulaşabileceği resources'ı sınırlar. ### Least Privilege ve IGA Least Privilege yalnız PAM ile ilgili değildir. Normal workforce users için de uygulanmalıdır. Kullanıcının işini yapması için gereken access verilmeli, gereksiz permissions kaldırılmalıdır. IGA bu principle'ı sürekli hale getirir. Başlangıçta minimum access verilir. Zaman içerisinde changes review edilir. Unused access kaldırılır. High-risk entitlements daha sık certification'a alınır. Bu şekilde Least Privilege tek seferlik configuration değil, sürekli governance process haline gelir. ### Zero Trust ve IGA Arasındaki İlişki Zero Trust yalnız authentication sırasında user ve device'ı verify etmek değildir. Authorization'ın da sürekli doğru olması gerekir. User doğru kimlik olabilir ancak yanlış privilege'a sahip olabilir. Bu durumda authentication güçlü olsa bile security risk devam eder. Bu nedenle Zero Trust için: #### Verify Identity kadar: #### Verify Entitlement da önemlidir. IGA bu ikinci katmanı sağlar. Modern Zero Trust authorization modeli: **Identity + Device + Risk + Entitlement + Context** birlikte değerlendirilmelidir. ### IGA ile SOC Entegrasyonu IGA traditionally governance platformu olarak görülür. Ancak SOC için de değerli context sağlar. Örneğin SIEM suspicious user activity tespit etti. SOC şu bilgiyi görmek isteyebilir: User hangi applications'a erişebiliyor? Privileged roles var mı? Sensitive data access'i var mı? SoD conflicts mevcut mu? Recent access change var mı? IGA bu entitlement context'i sağlayabilir. Bu şekilde incident severity daha doğru değerlendirilebilir. ### IGA ve ITDR Entegrasyonu ITDR risky identity behavior tespit ettiğinde IGA access review trigger edebilir. Örneğin user'da unusual privileged activity tespit edildi. System: Emergency Access Review başlatabilir. High-risk entitlements temporary olarak suspend edilebilir. Bu geleceğin Identity Security Architecture'ında governance ile threat detection'ın birleştiği önemli noktadır. Model: **Detect Risk → Re-Evaluate Access → Reduce Entitlement** şeklinde olabilir. ### IGA KPI'ları Nasıl Belirlenir? IGA programı yalnız kaç access review tamamlandığıyla ölçülmemelidir. Daha anlamlı KPI'lar kullanılabilir: Access Review Completion Rate Revoked Access Ratio Unused Access Reduction Orphaned Entitlement Count SoD Violation Count Mover Access Cleanup Rate Leaver Deprovisioning Completion High-Risk Access Review Frequency Time-Bound Access Ratio Role Coverage gibi göstergeler kullanılabilir. Özellikle: **Access Review Completion = %100** olması tek başına başarı değildir. Bütün reviewers her şeyi approve ediyorsa gerçek governance oluşmamıştır. Daha önemli metric: #### Review sonucunda gereksiz access gerçekten azaltılıyor mu? olmalıdır. ### IGA'da En Sık Yapılan Hatalar Kurumsal IGA projelerinde sık görülen hatalar şunlardır: - IGA'yı yalnız compliance aracı görmek - Entitlement inventory oluşturmamak - Permission isimlerini business için anlaşılmaz bırakmak - Resource owner belirlememek - Access Review'ları yılda bir formalite olarak yapmak - Reviewer'a gereğinden fazla access göndermek - Rubber-Stamp Approval'ı izlememek - Permission Creep'i ölçmemek - Mover process'i governance dışında bırakmak - SoD rules tanımlamamak - Toxic Combinations'ı analiz etmemek - Birthright Access'i gereğinden geniş tanımlamak - Temporary Access'i permanent vermek - Unused Access'i kaldırmamak - Service Accounts'ı governance kapsamına almamak - Cloud Entitlements'ı dışarıda bırakmak - PAM ve IGA'yı ayrı silolar olarak yönetmek - AI Agent permissions'ı governance dışı bırakmak - HR data quality sorunlarını göz ardı etmek - Access review completion'ı tek başarı metriği kabul etmek ### IGA Security Checklist Kurumlar aşağıdaki kontrolleri kullanarak Identity Governance olgunluklarını değerlendirebilir: - Entitlement Inventory mevcut mu? - Applications'ın business owners'ı belli mi? - Sensitive permissions sınıflandırılmış mı? - Access Request workflow kullanılıyor mu? - Business justification zorunlu mu? - Access approvals kayıt altına alınıyor mu? - Birthright Access minimum seviyede mi? - RBAC uygulanıyor mu? - Role Mining yapılıyor mu? - Role Explosion kontrol ediliyor mu? - Access Reviews düzenli yapılıyor mu? - High-Risk Access daha sık review ediliyor mu? - Access Certification uygulanıyor mu? - Unused permissions tespit ediliyor mu? - Dormant access kaldırılıyor mu? - Mover process eski permissions'ı kaldırıyor mu? - Leaver process bütün entitlement'ları revoke ediyor mu? - Temporary Access expiry kullanıyor mu? - External User access süreli mi? - SoD policies tanımlı mı? - Toxic Combinations tespit ediliyor mu? - Privileged Access IGA governance kapsamına alınıyor mu? - IGA ve PAM entegre mi? - Cloud Entitlements governance kapsamına alınıyor mu? - Service Accounts için owner tanımlı mı? - Non-Human Identities governance kapsamına alınıyor mu? - AI Agent permissions kayıt altında mı? - Access Review sırasında usage data gösteriliyor mu? - Peer Group Analysis kullanılıyor mu? - IGA logs SIEM/SOC için erişilebilir mi? - Risk event sonrası emergency review yapılabiliyor mu? ### IGA Olgunluk Modeli **Seviye 1 – Manuel Yetki Yönetimi:** Access requests e-mail veya ticket ile yapılır. Permissions'ın merkezi inventory'si yoktur. Kullanıcıların neye eriştiğini görmek zordur. **Seviye 2 – Merkezi Access Review:** Critical applications için entitlement inventory ve periyodik access certification uygulanır. Manager reviews başlar. **Seviye 3 – Automated Governance:** Joiner-Mover-Leaver, Access Request, SoD ve Role-Based Governance otomatik hale gelir. Temporary access ve business ownership yaygınlaşır. **Seviye 4 – Risk-Based Identity Governance:** High-risk, unused ve unusual permissions analytics ile tespit edilir. Review frequency access riskine göre değişir. IGA, PAM ve cloud entitlement management birlikte çalışır. **Seviye 5 – Continuous Adaptive Governance:** Human, Machine ve AI Agent identities sürekli entitlement evaluation'a tabi tutulur. Access decisions usage, risk, peer analysis ve real-time identity signals ile yeniden değerlendirilir. Bu dönüşüm: #### Manual Access Management ↓ #### Periodic Certification ↓ #### Automated Governance ↓ #### Risk-Based Governance ↓ #### Continuous Identity Governance şeklinde ilerler. ### Sık Sorulan Sorular #### IGA nedir? IGA, Identity Governance and Administration; kullanıcıların ve diğer identities'in sahip olduğu access rights'ın yaşam döngüsünü, doğruluğunu, riskini ve governance süreçlerini yöneten teknoloji ve süreçlerin bütünüdür. #### IAM ile IGA arasındaki fark nedir? IAM identity authentication ve access lifecycle'ını yönetirken IGA verilen access'in hâlâ gerekli ve uygun olup olmadığını govern eder. #### PAM ile IGA arasındaki fark nedir? PAM privileged access'in güvenli kullanımını kontrol eder. IGA ise user'ın bu privileged access'e sahip olmasının business olarak uygun olup olmadığını yönetir. #### Access Review nedir? Kullanıcıların mevcut permissions'ının hâlâ gerekli olup olmadığının belirli aralıklarla veya risk event sonrasında değerlendirilmesidir. #### Access Certification nedir? Access rights'ın authorized reviewer tarafından resmi olarak onaylanması veya kaldırılması sürecidir. #### Entitlement nedir? Bir identity'nin belirli resource üzerinde sahip olduğu permission veya access right'tır. #### Permission Creep nedir? Kullanıcının zaman içerisinde role ve proje değişiklikleri nedeniyle eski permissions'ı kaybetmeden yeni permissions edinmesi sonucunda gereğinden fazla access biriktirmesidir. #### SoD nedir? Segregation of Duties, kritik process'in tüm adımlarının aynı kullanıcı tarafından gerçekleştirilememesini sağlayan görevlerin ayrılığı prensibidir. #### Toxic Combination nedir? Ayrı ayrı kabul edilebilir ancak birlikte kullanıldığında yüksek risk oluşturan permission kombinasyonudur. #### Birthright Access nedir? Kullanıcının işe başladığında job role veya employee type nedeniyle otomatik aldığı temel access rights'tır. #### Role Mining nedir? Mevcut user permissions ve access patterns analiz edilerek uygun business roles oluşturulmasını destekleyen yöntemdir. #### IGA ile CIEM aynı şey midir? Hayır. IGA kurum genelindeki identity governance'a odaklanırken CIEM özellikle cloud infrastructure permissions ve excessive entitlements üzerinde yoğunlaşır. #### Service Account'lar IGA kapsamında olmalı mı? Evet. Service account yüksek privilege veya sensitive access kullanıyorsa owner, business purpose ve permissions düzenli olarak govern edilmelidir. #### AI Agent permissions IGA kapsamına alınmalı mı? AI Agent applications ve data üzerinde action gerçekleştirebiliyorsa identity ve entitlement governance kapsamına alınmalıdır. Agent'ın hangi yetkilere sahip olduğu, hangi amaçla kullandığı ve owner'ının kim olduğu belirlenmelidir. #### SailPoint ve Saviynt ne tür ürünlerdir? Enterprise Identity Governance and Administration use case'leri için kullanılan IGA platformlarıdır. Access certification, lifecycle governance, entitlement management ve role governance gibi capabilities sağlayabilirler. #### Access Review yılda bir yapılması yeterli mi? Her access için aynı frequency uygun değildir. Sensitive veya privileged access için daha sık veya event-driven review uygulanabilir. ### Sonuç: Kimliği Doğrulamak Yetmez, Yetkiyi de Sürekli Doğrulamak Gerekir Modern Identity Security içerisinde güçlü authentication son derece önemlidir. SSO kullanabilirsiniz. MFA uygulayabilirsiniz. Passkey kullanabilirsiniz. Phishing-resistant authentication sağlayabilirsiniz. Ancak doğru şekilde authentication yapan user yanlış permissions'a sahipse security problemi devam eder. Bu nedenle: #### Strong Authentication ≠ Correct Authorization IAM kimliğin sisteme güvenli şekilde ulaşmasını sağlar. PAM yüksek privilege'ın güvenli kullanılmasını sağlar. IGA ise identity'nin sahip olduğu access'in doğru olup olmadığını sürekli sorgular. Bu yüzden IGA'nın merkezindeki soru: **“Kullanıcı bu erişimi almış mı?”** değil, **“Kullanıcının bu erişime bugün hâlâ ihtiyacı var mı?”** olmalıdır. Modern governance modeli yalnız periodic access certification'a dayanmamalıdır. Cloud, hybrid work, SaaS ve Non-Human Identity adoption arttıkça access relationships sürekli değişmektedir. Bu nedenle Identity Governance da: #### Periodic modelden: #### Continuous modele doğru evrilmektedir. Geleceğin IGA architecture'ı: Identity lifecycle, Access Usage, Risk Signals, Peer Group Analytics, Cloud Entitlements, Privileged Access, Machine Identity ve AI Agent permissions verilerini birlikte değerlendirmek zorunda kalacaktır. Bu yaklaşımın temel formülü: **Know the Identity → Know the Entitlement → Know the Business Need → Know the Risk → Remove What Is Not Needed** şeklinde özetlenebilir. Daha kısa ifadeyle: **Doğru kimliğe doğru yetkiyi vermek kadar, artık gerekli olmayan yetkiyi zamanında kaldırmak da güvenliğin parçasıdır.** Ve bu bölümün en önemli cümlesi: **Modern Identity Governance'ın gerçek başarısı kaç erişimin onaylandığıyla değil, kurumda gereksiz, kullanılmayan ve riskli yetkilerin ne kadar hızlı tespit edilip kaldırıldığıyla ölçülmelidir.**