Service Account, API Key ve Non-Human Identity Güvenliği: Secrets Management ve Machine Identity

Kurumsal kimlik ve erişim yönetimi uzun yıllar boyunca ağırlıklı olarak insan kullanıcılar üzerinden ele alındı. Çalışan hesapları, administrator kimlikleri, MFA, SSO, passwordless authentication ve privileged access management gibi konular Identity Security programlarının merkezinde yer aldı. Ancak modern cloud, DevOps, SaaS, API ve automation mimarileriyle birlikte kurumların sahip olduğu kimliklerin büyük bir bölümü artık insanlara ait değildir.

Application'lar birbirleriyle iletişim kurar. CI/CD pipeline production environment'a deployment yapar. Backup application database'e bağlanır. Monitoring agent sunuculardan veri toplar. Kubernetes workload cloud API'lerini kullanır. RPA bot business process yürütür. AI Agent kurumsal applications üzerinde aksiyon alır.

Bu yapıların tamamı bir şekilde authentication ve authorization ihtiyacı duyar.

İşte bu nedenle modern Identity Security'nin en hızlı büyüyen alanlarından biri Non-Human Identity Security – NHI Security haline gelmiştir.

Service accounts, API keys, service principals, certificates, access tokens, workload identities ve application secrets modern kurumların görünmeyen kimlik altyapısını oluşturur. Bu credentials çoğu zaman kullanıcı hesabından daha uzun süre yaşar, MFA kullanmaz ve doğrudan production systems'a erişebilir.

Bu nedenle temel soru artık yalnız:

“Kullanıcı hesabı güvenli mi?”

değildir.

Aynı zamanda şu sorunun cevabı verilmelidir:

“Kurum adına otomatik işlem yapan bütün makineler, uygulamalar ve servisler hangi kimlikle çalışıyor ve bu kimliklerin yetkileri ne kadar güvenli?”

Non-Human Identity Nedir?

Non-Human Identity, insan kullanıcı yerine application, service, workload, device, bot veya automation process tarafından kullanılan kimliktir.

Bu kimlikler farklı technologies ile temsil edilebilir.

Örneğin:

Service Account

Service Principal

API Key

Access Token

Certificate

SSH Key

Workload Identity

Managed Identity

birer Non-Human Identity mekanizması olabilir.

NHI'nin temel amacı machine-to-machine communication sırasında authentication sağlamaktır.

Örneğin bir application database'e bağlandığında database onun insan olup olmadığını önemsemez. Application'ın geçerli credential sunup sunmadığına bakar.

Bu credential compromise edilirse attacker application gibi davranabilir.

Bu nedenle NHI security doğrudan machine authentication güvenliğidir.

Service Account Nedir?

Service Account, application veya background service tarafından kullanılan özel bir account türüdür.

Örneğin Windows service:

svc_backup

account'u ile çalışabilir.

Bir application server:

svc_app_prod

hesabı ile database'e bağlanabilir.

Bu accounts çoğu zaman interactive user login için kullanılmaz.

Ancak büyük problem şudur:

Service account credentials genellikle uzun süre değiştirilmez.

Çünkü password change application'ı bozabilir.

Bu nedenle kurumlarda:

“Bu account'un password'una dokunmayın, sistem çalışmaz.”

yaklaşımı oldukça yaygındır.

Sonuç olarak 5–10 yıldır aynı password'u kullanan service accounts ortaya çıkabilir.

Bu ciddi bir Identity Security riskidir.

Service Account Neden Normal Kullanıcı Hesabından Daha Riskli Olabilir?

Human user password'u belirli aralıklarla değişebilir.

MFA kullanılabilir.

Login behavior izlenebilir.

Employee işten ayrıldığında account kapatılabilir.

Service account ise yıllarca aktif kalabilir.

Owner'ı belli olmayabilir.

MFA uygulanamaz.

Password application configuration içinde tutulabilir.

Ayrıca service account high privilege taşıyabilir.

Bu nedenle attacker service account credential'ı ele geçirdiğinde uzun süre fark edilmeden access sağlayabilir.

Service accounts'ın riskini artıran üç temel faktör vardır:

Long-Lived Credential

High Privilege

Low Visibility

Bu üçü birlikte ciddi attack surface oluşturur.

Service Account Inventory Neden İlk Adımdır?

Service Account Security programının en önemli başlangıç noktası inventory'dir.

Kurum şu sorulara cevap verebilmelidir:

Kaç service account var?

Hangi sistemlerde kullanılıyor?

Owner kim?

Hangi application kullanıyor?

Hangi permissions'a sahip?

Interactive login açık mı?

Password ne zaman değişti?

Credential nerede saklanıyor?

Bu soruların cevabı bilinmiyorsa güvenli rotation veya governance uygulanamaz.

Çünkü service account password'unu değiştirmek bağlı application'ı durdurabilir.

Bu nedenle discovery ve dependency mapping kritik öneme sahiptir.

Dependency Mapping Nedir?

Dependency Mapping, bir service account veya secret'ın hangi systems ve applications tarafından kullanıldığını belirleme sürecidir.

Örneğin:

svc_reporting

account'u bir Windows Scheduled Task,

iki application server

ve bir reporting engine

tarafından kullanılıyor olabilir.

Password değiştirilmeden önce bu dependencies bilinmelidir.

Aksi halde rotation sonrasında:

services stop,

application errors,

database connection failures

oluşabilir.

Bu nedenle service account security yalnız password rotation değildir.

Asıl konu:

Credential Lifecycle + Dependency Awareness

birlikte yönetmektir.

Service Account Password Rotation Nasıl Yapılır?

Service account credentials düzenli olarak rotate edilmelidir.

Ancak manual rotation operational risk yaratabilir.

Modern PAM ve Secrets Management platforms bu süreci automate edebilir.

Örneğin sistem:

service account password'u değiştirir,

target application configuration'ını update eder,

service'i restart eder,

health check yapar.

Bu automated rotation modelidir.

Amaç static credential lifetime'ı azaltmaktır.

API Key Nedir?

API Key, application veya user'ın API service'e access sağlaması için kullanılan credential türüdür.

Basit ve kullanışlı olması nedeniyle yaygın şekilde kullanılır.

Örneğin application:

Authorization: API_KEY

benzeri bir mekanizma kullanabilir.

Ancak API key security açısından önemli risk taşır.

Çünkü API key çoğunlukla bearer credential'dır.

Yani key'i bilen kişi kullanabilir.

Bu nedenle key source code repository'ye sızarsa attacker access sağlayabilir.

API Key Güvenliği Nasıl Sağlanır?

API keys için temel prensipler şunlardır:

Secret olarak saklanmalıdır.

Source code içine yazılmamalıdır.

Minimum permissions verilmelidir.

Regular rotation uygulanmalıdır.

Usage monitoring yapılmalıdır.

Expiry mümkünse kullanılmalıdır.

Sensitive APIs için static API key yerine stronger authentication methods tercih edilmelidir.

Bu yaklaşım API security ile Identity Security'nin kesişim noktasıdır.

Hardcoded Secret Nedir?

Hardcoded Secret, password, API key, token veya other credential'ın source code içerisine doğrudan yazılmasıdır.

Örneğin:

DB_PASSWORD = "Prod12345"

veya:

AWS_ACCESS_KEY = "..."

gibi configuration'lar hardcoded secret riskidir.

Bu secret source code repository'ye push edildiğinde repository access'i olan herkes tarafından görülebilir.

Public repository ise internet üzerinde attacker tarafından discover edilebilir.

Git history nedeniyle secret sonradan silinse bile geçmiş commit'lerde kalabilir.

Bu nedenle hardcoded secret DevSecOps açısından ciddi bir security finding'dir.

Secret Git Repository'den Silinirse Risk Biter mi?

Hayır.

Secret daha önce commit edildiyse exposed kabul edilmelidir.

Yalnız dosyadan silmek yeterli değildir.

Credential rotate edilmelidir.

Çünkü attacker secret'ı geçmiş commit'ten veya cached repository'den elde etmiş olabilir.

Bu nedenle temel incident response yaklaşımı:

Secret Exposed → Revoke / Rotate

olmalıdır.

Secrets Management Nedir?

Secrets Management, applications ve workloads tarafından kullanılan sensitive credentials'ın merkezi, kontrollü ve otomatik şekilde yönetilmesini sağlayan security approach'tur.

Secrets:

Passwords

API Keys

Tokens

Certificates

Encryption Keys

Database Credentials

olabilir.

Secrets Manager'ın temel görevi bu credentials'ı güvenli şekilde saklamak, access policy uygulamak, audit trail oluşturmak ve mümkün olduğunda rotation sağlamaktır.

Bu nedenle Secrets Management modern DevSecOps architecture'ın temel bileşenlerinden biridir.

Secret Vault Nedir?

Secret Vault, sensitive credentials'ın encrypted ve access-controlled şekilde saklandığı merkezi yapıdır.

Application secret'ı source code içerisinde tutmak yerine runtime sırasında Vault üzerinden alabilir.

Traditional model:

Application Code → Static Password

Modern model:

Application Identity → Vault → Secret

şeklindedir.

Daha ileri modelde ise secret bile static olmak zorunda değildir.

Vault temporary credential üretebilir.

Dynamic Secrets Nedir?

Dynamic Secrets, ihtiyaç anında oluşturulan ve belirli süre sonra automatically expire edilen credentials'dır.

Örneğin application database'e bağlanmak istediğinde Vault yeni database username-password oluşturabilir.

Credential:

30 dakika

geçerli olur.

Sonrasında revoke edilir.

Bu yaklaşım static service account password riskini ciddi şekilde azaltabilir.

Çünkü attacker credential'ı ele geçirse bile kullanım süresi sınırlıdır.

Dynamic Secrets'in temel güvenlik modeli:

Create on Demand → Use → Expire → Destroy

şeklindedir.

Short-Lived Credential Nedir?

Short-Lived Credential, uzun süreli static password veya API key yerine kısa süre geçerli olan authentication credential'dır.

Bu credential:

token,

certificate,

temporary password

olabilir.

Security avantajı attack window'u azaltmasıdır.

Attacker credential ele geçirse bile expiry sonrasında kullanamaz.

Bu nedenle modern machine identity architecture mümkün olduğunca:

Long-Lived Secrets → Short-Lived Credentials

dönüşümüne yönelmelidir.

Workload Identity Nedir?

Workload Identity, application, container, virtual machine, serverless function veya CI/CD pipeline gibi workload'ların kendi kimliğiyle authenticate olmasını sağlayan modeldir.

Bu yaklaşımda application'ın static username-password taşıması gerekmez.

Platform workload'u tanır ve temporary token verir.

Bu cloud-native environments için güçlü bir modeldir.

Workload Identity modern Machine Identity Security'nin en önemli bileşenlerinden biridir.

Managed Identity Neden Önemlidir?

Managed Identity, cloud provider tarafından yönetilen workload identity modelidir.

Application manual secret saklamak zorunda kalmaz.

Örneğin application database access için client secret kullanmak yerine managed identity ile authentication yapabilir.

Bu şu riskleri azaltır:

Secret Storage

Secret Rotation

Credential Leakage

Hardcoded Credentials

Bu nedenle mümkün olduğunda managed identity, static service principal secret'a tercih edilebilir.

Service Principal Güvenliği

Service Principal cloud application veya automation için kullanılan machine identity'dir.

Service principal high privilege taşıyabilir.

Örneğin CI/CD pipeline production subscription üzerinde Contributor role kullanabilir.

Problem, service principal credential'ın uzun süre geçerli olmasıdır.

Bu nedenle:

certificate-based authentication,

federated identity,

short-lived token,

least privilege

tercih edilmelidir.

Service principal permissions düzenli olarak CIEM ve IGA ile review edilmelidir.

Workload Identity Federation Nedir?

Workload Identity Federation, external system'ın cloud provider'a static credential saklamadan authenticate olmasını sağlar.

Örneğin CI/CD platform:

permanent AWS access key

saklamak yerine federated identity token kullanabilir.

Cloud platform bu token'ı doğrular ve temporary credential üretir.

Bu model credential storage riskini ciddi şekilde azaltabilir.

CI/CD Secrets Neden Kritik?

CI/CD pipelines production environments üzerinde yüksek yetkiyle işlem yapabilir.

Deployment yapabilir.

Database migrations çalıştırabilir.

Cloud infrastructure oluşturabilir.

Bu nedenle CI/CD secrets attacker için son derece değerlidir.

Repository veya pipeline compromise olduğunda attacker production credentials ele geçirebilir.

Bu nedenle pipeline secrets:

central secret store,

short-lived credential,

OIDC federation,

restricted scope

ile yönetilmelidir.

Pipeline'a Administrator Password Koymak Neden Yanlış?

CI/CD pipeline içerisinde static administrator password bulunması ciddi risk oluşturur.

Çünkü pipeline logs,

configuration,

backup,

repository

üzerinden secret sızabilir.

Ayrıca credential uzun süre değişmeyebilir.

Daha güvenli model:

Pipeline Identity → Temporary Role → Deployment

şeklindedir.

Bu DevSecOps ve Zero Trust machine identity yaklaşımıdır.

Kubernetes Secrets Güvenli mi?

Kubernetes Secrets uygulamaların sensitive data taşıması için kullanılabilir.

Ancak Kubernetes Secret kullanmak tek başına enterprise-grade secrets management anlamına gelmez.

Secret storage, encryption, RBAC ve cluster security doğru yapılandırılmalıdır.

Critical secrets için external secrets manager integration değerlendirilebilir.

Amaç application secrets'ın cluster configuration içerisinde uncontrolled şekilde yayılmasını engellemektir.

Kubernetes Service Account Nedir?

Kubernetes Service Account, pod veya workload'un Kubernetes API ile authenticate olmasını sağlayabilir.

Yanlış RBAC configuration service account'a gereğinden fazla permission verebilir.

Örneğin pod compromise olduğunda attacker service account token kullanarak cluster üzerinde broader access sağlayabilir.

Bu nedenle Kubernetes service accounts için:

Least Privilege

Dedicated Identity

Token Expiry

RBAC Review

uygulanmalıdır.

Certificate-Based Machine Identity

Machine authentication yalnız passwords ve tokens ile yapılmaz.

Certificates da machine identity için kullanılabilir.

Mutual TLS, yani mTLS, iki system'in birbirini certificate üzerinden doğrulamasını sağlayabilir.

Bu özellikle service-to-service communication için güçlü authentication sağlar.

Ancak certificate lifecycle yönetilmezse farklı riskler oluşur.

Expired certificates outages yaratabilir.

Long-lived certificates compromise riskini artırabilir.

Bu nedenle certificate lifecycle da Machine Identity Security'nin parçasıdır.

PKI ve Machine Identity İlişkisi

Public Key Infrastructure, digital certificates'ın oluşturulması, dağıtılması, doğrulanması ve revoke edilmesini sağlar.

Modern environments'da machine identities arttıkça certificate sayısı da ciddi biçimde artabilir.

Bu nedenle kurumlar yalnız user certificates değil:

servers,

services,

containers,

APIs,

IoT devices

üzerindeki certificates'ı da inventory ve lifecycle management kapsamına almalıdır.

Bu alan Machine Identity Management olarak giderek önem kazanmaktadır.

SSH Key Güvenliği

SSH keys özellikle Linux server administration ve automation için yaygın kullanılır.

Ancak private key yıllarca değişmeden kullanılırsa static credential haline gelir.

Shared SSH keys accountability sorununa yol açabilir.

Bir administrator ayrıldığında key'in hangi servers üzerinde bulunduğunu bilmek zor olabilir.

Bu nedenle SSH key inventory ve rotation önemlidir.

Mümkün olduğunda temporary certificates veya centrally managed access models değerlendirilebilir.

Secrets Sprawl Nedir?

Secrets Sprawl, credentials'ın organization içerisinde kontrolsüz biçimde yayılmasıdır.

Secret:

source code,

environment variable,

Excel file,

ticket,

e-mail,

configuration file,

developer laptop

gibi birçok yerde bulunabilir.

Bu durum secret rotation'ı zorlaştırır.

En önemli problem, kurumun aynı secret'ın kaç yerde kullanıldığını bilmemesidir.

Bu nedenle Secrets Management programının hedeflerinden biri secrets sprawl'u azaltmaktır.

Secret Zero Problemi Nedir?

Secrets Management architecture'ın klasik sorularından biri şudur:

Application Vault'a nasıl authenticate olacak?

Vault secret'ı saklıyor olabilir.

Ancak application Vault'a erişmek için başka bir secret kullanıyorsa başlangıç problemi oluşur.

Bu Secret Zero problemi olarak bilinir.

Modern çözüm application'ı environment identity ile doğrulamaktır.

Örneğin:

Workload Identity

Managed Identity

Certificate

Federated Identity

kullanılabilir.

Böylece static bootstrap password ihtiyacı azaltılır.

PAM ve Secrets Management Aynı Şey midir?

Hayır.

PAM özellikle human privileged access, administrator accounts, session management ve credential vaulting use case'lerine odaklanabilir.

Secrets Management ise applications, DevOps pipelines ve machine identities tarafından kullanılan credentials üzerine yoğunlaşır.

Ancak iki alan birbirine yaklaşmaktadır.

Modern enterprise environment'da hem human privileged credentials hem machine secrets merkezi security architecture içinde değerlendirilmelidir.

Basitleştirirsek:

PAM → Human Privileged Access

Secrets Management → Machine/Application Credentials

Ancak modern platformlar bu iki alanı kısmen birlikte sunabilir.

HashiCorp Vault Nerede Konumlanır?

HashiCorp Vault, secrets management, dynamic credentials ve machine authentication use case'lerinde yaygın olarak değerlendirilen platforms'dan biridir.

Database credentials, API secrets, tokens ve certificates gibi sensitive data merkezi olarak yönetilebilir.

Dynamic Secrets önemli capabilities'den biridir.

Ancak Secrets Vault ile full enterprise PAM aynı şey değildir.

Örneğin full PAM deployment:

RDP Session Recording

SSH Session Proxy

Privileged Human Workflow

gibi capabilities gerektirebilir.

Bu nedenle product category doğru anlaşılmalıdır.

Cloud-Native Secret Managers

Cloud providers da secrets management services sunabilir.

Bu services application secrets'ın cloud environment içerisinde merkezi yönetilmesini sağlayabilir.

Ancak multi-cloud veya hybrid environments'da secrets farklı platforms'a dağılabilir.

Bu nedenle kurumun:

centralized governance,

rotation,

ownership,

audit

modelini netleştirmesi gerekir.

Amaç hangi ürün kullanılırsa kullanılsın secret lifecycle'ın kontrol altında tutulmasıdır.

Non-Human Identity Governance

NHI yalnız credential management problemi değildir.

Governance da gereklidir.

Her machine identity için şu bilgiler bilinmelidir:

Owner kim?

Business purpose nedir?

Hangi application kullanıyor?

Hangi resource'lara erişiyor?

Privilege seviyesi nedir?

Credential type nedir?

Expiration var mı?

Son kullanım ne zaman?

Owner organization'dan ayrılırsa ne olacak?

Bu nedenle modern IGA programs NHI governance alanına genişlemektedir.

NHI Ownership Neden Kritik?

Human account'un owner'ı bellidir.

Service account veya API key'in owner'ı çoğu zaman bilinmez.

Bu durum remediation sırasında ciddi problem yaratır.

Security team unused secret bulur ancak silmeye korkar.

Çünkü hangi application'ın bozulacağını bilmez.

Bu yüzden her NHI için technical ve business owner tanımlanmalıdır.

No Owner = No Governance

prensibi uygulanabilir.

Dormant Non-Human Identity Nedir?

Uzun süredir kullanılmayan service account, API key veya service principal dormant identity olarak değerlendirilebilir.

Bu credentials attack surface oluşturmaya devam eder.

Örneğin eski project bitmiştir ancak service principal hâlâ Contributor role taşımaktadır.

Attacker eski credential'ı bulursa kullanabilir.

Bu nedenle NHI için last-used analytics önemlidir.

Non-Human Identity ve CIEM

Machine identities cloud environment'da excessive permissions taşıyabilir.

Service principal 300 permission'a sahip olabilir ancak yalnız 5 tanesini kullanıyor olabilir.

CIEM actual usage ile granted permissions arasındaki farkı analiz edebilir.

Bu machine identity Least Privilege için kritik visibility sağlar.

Non-Human Identity ve ITDR

ITDR yalnız human identities'i izlememelidir.

Machine identity behavior da analiz edilmelidir.

Örneğin service account normalde yalnız:

Application Server → Database

traffic üretmektedir.

Bir gün:

Developer Laptop → Cloud Console

üzerinden kullanılmaya başlanırsa anormaldir.

Bu behavior NHI compromise göstergesi olabilir.

Service Account Interactive Login Neden Risklidir?

Bir service account application tarafından kullanılmak üzere oluşturulduysa interactive login çoğu durumda gerekli değildir.

Attacker credential'ı ele geçirdiğinde RDP veya SSH ile login yapabiliyorsa risk artar.

Bu nedenle service account logon rights sınırlandırılmalıdır.

Account yalnız gerekli service context içerisinde kullanılmalıdır.

API Key Scope Neden Minimum Olmalı?

API key yalnız belirli endpoint veya operation için kullanılacaksa full API access verilmemelidir.

Örneğin monitoring application yalnız:

Read Metrics

yapacaksa:

Delete Resource

permission'a ihtiyacı yoktur.

Bu Least Privilege prensibi API credentials için de geçerlidir.

Secret Rotation Frequency Nasıl Belirlenir?

Her secret için aynı rotation period uygun olmayabilir.

Risk-based approach kullanılabilir.

High-Privilege Static Secret

daha sık rotate edilebilir.

Low-risk veya short-lived credentials için farklı lifecycle uygulanabilir.

Asıl hedef manual calendar rotation değil, mümkün olduğunda:

Automatic + Short-Lived + On-Demand

credential modeline geçmektir.

Credential Expiry Neden Önemli?

Expiry olmayan credentials unutulabilir.

Bir API key 7 yıl boyunca kullanılabilir durumda kalabilir.

Bu nedenle mümkün olduğunda expiration tanımlanmalıdır.

Credential süresi dolmadan automation ile renewal yapılabilir.

Bu yaklaşım dormant credentials riskini azaltır.

Secret Scanning Nedir?

Secret Scanning, source code ve repositories içerisinde accidentally committed credentials'ı tespit etmeye yönelik güvenlik kontrolüdür.

Scan sırasında:

API Keys

Cloud Credentials

Passwords

Private Keys

Tokens

tespit edilmeye çalışılır.

Secret scanning DevSecOps pipeline'a entegre edilebilir.

Commit öncesi veya CI aşamasında detection yapılabilir.

Ancak exposed secret bulunduğunda yalnız code'dan silinmemeli; credential rotate edilmelidir.

Pre-Commit Secret Detection

Developer credential'ı repository'ye push etmeden önce local hook veya development tooling secret pattern tespit edebilir.

Bu preventive control'dür.

CI pipeline'daki scanning ise detective control sağlayabilir.

En güçlü yaklaşım iki katmanı birlikte kullanmaktır.

Secrets Management ve Zero Trust

Zero Trust machine identity için de geçerlidir.

Application güvenilir network içinde olduğu için otomatik trusted kabul edilmemelidir.

Her workload unique identity ile authenticate olmalıdır.

Access:

Identity

Resource

Context

Minimum Permission

üzerinden verilmelidir.

Bu Zero Trust for Workloads yaklaşımıdır.

mTLS ve Zero Trust Service-to-Service Communication

Microservices architecture içerisinde services birbirleriyle sürekli communication kurar.

Network'in internal olması tek başına trust nedeni olmamalıdır.

mTLS kullanıldığında her service certificate ile authenticate olabilir.

Bu service identity doğrulaması sağlar.

Service mesh architectures bu modeli automate edebilir.

Bu nedenle modern Zero Trust yalnız users'a değil workloads'a da uygulanır.

AI Agent Non-Human Identity midir?

AI Agent bir user adına veya autonomous şekilde applications üzerinde işlem yapıyorsa machine identity olarak değerlendirilmelidir.

Agent'a shared human account vermek uygun değildir.

Her agent için unique identity kullanılmalıdır.

Bu sayede:

hangi agent hangi işlemi yaptı,

hangi permission ile yaptı,

hangi data'ya erişti

audit edilebilir.

AI Agent Security'nin önemli kısmı identity management olacaktır.

AI Agent Secret'ları Nasıl Korunmalı?

AI Agent API keys, cloud tokens veya database credentials kullanabilir.

Bu secrets prompt içerisinde veya code configuration'ında tutulmamalıdır.

Agent runtime sırasında Secrets Manager üzerinden temporary credential alabilir.

Daha ileri modelde agent'ın workload identity'si kullanılarak static secret tamamen kaldırılabilir.

Bu, Agentic AI Security için önemli bir tasarım prensibidir.

AI Agent İçin Least Privilege

AI Agent'a broad administrator permissions verilmemelidir.

Agent yalnız görevi için gerekli actions'a sahip olmalıdır.

Örneğin SOC Agent'ın işi endpoint isolate etmekse yalnız:

Read Alert

Isolate Endpoint

permissions yeterli olabilir.

Global EDR administrator permission gerekli değildir.

Bu Task-Scoped Agent Authorization yaklaşımıdır.

Agent Credential Lifetime

Autonomous agents continuous olarak çalışabilir.

Bu nedenle permanent credential vermek kolay görünebilir.

Ancak compromise durumunda yüksek risk oluşturur.

Daha güvenli model agent'ın:

short-lived tokens,

workload identity,

dynamic credentials

kullanmasıdır.

Bu sayede permanent secret attack surface'i azaltılır.

Machine Identity ile Human Identity Arasındaki Fark

Human Identity genellikle:

SSO

MFA

Passwordless

kullanabilir.

Machine Identity ise:

Certificate

Token

API Key

Workload Identity

kullanabilir.

Human identity behavior hours ve devices üzerinden analiz edilebilir.

Machine identity behavior ise protocols, source systems ve API actions üzerinden baseline edilebilir.

Bu nedenle aynı security policy iki identity type için yeterli değildir.

Ancak ortak prensipler aynıdır:

Unique Identity

Least Privilege

Short Credential Lifetime

Continuous Monitoring

Clear Ownership

Machine Identity Security Mimarisi Nasıl Kurulur?

Modern architecture şu flow üzerinden düşünülebilir:

Workload

↓

Machine Identity

↓

Authentication / Federation

↓

Secrets or Token Service

↓

Short-Lived Credential

↓

Target Resource

↓

Audit & Monitoring

Bu modelde workload static credential taşımak zorunda değildir.

Credential runtime sırasında oluşturulabilir ve işlem sonrasında expire olabilir.

Bu yaklaşım traditional service account security'den çok daha güçlüdür.

Secrets Management ile SIEM ve SOC Entegrasyonu

Secrets infrastructure'daki events security monitoring için yüksek değere sahiptir.

Örneğin:

Secret Read

Secret Rotation

Failed Vault Authentication

New Secret Creation

Mass Secret Retrieval

Policy Change

gibi events SIEM'e gönderilebilir.

Bir application normalde günde 5 kez secret okuyorken birden 10.000 secret read yapıyorsa unusual behavior olabilir.

Bu nedenle secrets platform yalnız storage değil security telemetry source olarak da kullanılmalıdır.

Break-Glass Machine Credential

Bazı critical environments'da automation failure durumunda emergency credential gerekebilir.

Ancak bu credential da tightly controlled olmalıdır.

Offline veya isolated şekilde korunabilir.

Her kullanım audit ve immediate rotation gerektirebilir.

Break-glass secret normal application configuration içerisinde tutulmamalıdır.

Secrets Backup Güvenliği

Vault veya secrets platform backup'ları son derece kritiktir.

Encrypted secret database backup attacker için high-value target olabilir.

Bu nedenle:

backup encryption,

access restriction,

offline/immutable protection,

restore testing

uygulanmalıdır.

Secrets platform restore edilemiyorsa application recovery de mümkün olmayabilir.

Bu nedenle Secrets Management aynı zamanda Business Continuity konusudur.

High Availability Secrets Management İçin Neden Önemlidir?

Applications runtime sırasında Vault'a bağlıysa secrets platform outage production services'ı etkileyebilir.

Bu nedenle HA architecture önemlidir.

Ancak caching kullanılıyorsa security trade-off değerlendirilmelidir.

Secret'ın application üzerinde ne kadar süre cached kalacağı belirlenmelidir.

Availability ile credential exposure arasında denge kurulmalıdır.

Secrets Management Programı Nasıl Başlatılmalı?

İlk adım enterprise-wide secret discovery olmalıdır.

Source code repositories,

CI/CD pipelines,

configuration files,

cloud platforms,

databases

incelenebilir.

Bulunan credentials risk seviyesine göre sınıflandırılabilir.

Öncelik:

Cloud Administrator Keys

Database Admin Credentials

Production API Keys

CI/CD Secrets

gibi high-impact credentials olabilir.

Sonrasında central Vault adoption başlatılabilir.

NHI Security Roadmap

Olgun bir Non-Human Identity Security programı şu aşamalarla ilerleyebilir:

Discovery: Service accounts, API keys ve machine identities bulunur.

Ownership: Her identity için owner belirlenir.

Classification: Privilege ve business criticality belirlenir.

Centralization: Secrets merkezi platforma alınır.

Rotation: Static credentials rotate edilir.

Modernization: Workload Identity ve short-lived credentials'a geçilir.

Least Privilege: Permissions optimize edilir.

Monitoring: NHI behavior izlenir.

Governance: Periodic review uygulanır.

Bu dönüşüm yalnız teknoloji değil process ve ownership gerektirir.

Non-Human Identity Security KPI'ları

Program başarısı şu metrics üzerinden izlenebilir:

Total Non-Human Identity Count

Unknown Owner NHI Count

Dormant Service Account Count

Long-Lived Secret Count

Hardcoded Secret Findings

Static API Key Count

Secret Rotation Coverage

Workload Identity Adoption

Managed Identity Adoption

Short-Lived Credential Ratio

Overprivileged Service Account Count

Expired Certificate Incidents

NHI Security Incident Count

Bu metrics kurumun machine identity attack surface'ini ölçmeye yardımcı olur.

Service Account ve Secrets Management'ta En Sık Yapılan Hatalar

Kurumlarda şu hatalar sık görülür:

• Service Accounts için owner belirlememek
• Yıllarca password değiştirmemek
• Shared service accounts kullanmak
• Service Accounts'a Domain Admin vermek
• Interactive login'i açık bırakmak
• API keys'i source code içinde saklamak
• Repository'den secret silince riskin bittiğini düşünmek
• Secrets'ı Excel veya e-mail ile paylaşmak
• CI/CD pipeline'a static administrator password koymak
• Long-Lived Cloud Keys kullanmak
• Service Principal secrets'ı rotate etmemek
• Kubernetes Service Accounts'a broad RBAC vermek
• SSH keys'i yıllarca değiştirmemek
• Secret inventory tutmamak
• Credential dependencies'i mapping etmemek
• Secrets Manager'ı yalnız encrypted storage olarak kullanmak
• Workload Identity'yi değerlendirmemek
• Dynamic Secrets kullanma fırsatını kaçırmak
• NHI behavior monitoring yapmamak
• AI Agents'a shared human credentials vermek

Non-Human Identity ve Secrets Security Checklist

Kurumlar aşağıdaki kontrolleri değerlendirebilir:

• Service Account inventory mevcut mu?
• Her service account'un owner'ı belli mi?
• Business purpose kayıtlı mı?
• Service Account interactive login kısıtlı mı?
• Service Account privileges minimum mu?
• Credential dependencies biliniyor mu?
• Automatic rotation uygulanıyor mu?
• Static passwords azaltılıyor mu?
• API Key inventory mevcut mu?
• API Key scope minimum mu?
• API Keys expiry kullanıyor mu?
• Hardcoded Secret scanning yapılıyor mu?
• Git repositories secret scanning kapsamında mı?
• Exposed secrets hemen rotate ediliyor mu?
• Central Secrets Manager kullanılıyor mu?
• Vault access MFA/policy ile korunuyor mu?
• Secrets logs SIEM'e gidiyor mu?
• Dynamic Secrets değerlendiriliyor mu?
• Short-Lived Credentials kullanılıyor mu?
• Managed Identity kullanılıyor mu?
• Workload Identity uygulanıyor mu?
• Workload Identity Federation değerlendiriliyor mu?
• CI/CD secrets merkezi yönetiliyor mu?
• Kubernetes service accounts least privilege mı?
• Certificates inventory'de mi?
• Certificate expiry monitoring var mı?
• SSH keys inventory'de mi?
• Dormant NHI tespit ediliyor mu?
• CIEM machine identities'i analiz ediyor mu?
• ITDR NHI behavior'ını izliyor mu?
• AI Agents unique identity kullanıyor mu?
• Agent credentials short-lived mı?
• Agent permissions task-scoped mı?
• Vault HA/DR test edilmiş mi?

Non-Human Identity Security Olgunluk Modeli

Seviye 1 – Static Credentials: Service account passwords, API keys ve secrets applications içerisinde manuel tutulur. Inventory ve ownership sınırlıdır.

Seviye 2 – Central Secrets Management: Critical secrets merkezi Vault'a alınır. Basic rotation ve audit uygulanır.

Seviye 3 – Automated Credential Lifecycle: Service account rotation, CI/CD integration, secret scanning ve certificate lifecycle automate edilir.

Seviye 4 – Workload Identity Security: Static credentials azaltılır. Managed Identity, federation, dynamic secrets ve short-lived credentials yaygınlaşır.

Seviye 5 – Adaptive Machine Identity Security: Human, Machine ve AI Agent identities ortak governance içerisinde yönetilir. Permissions usage ve risk signals üzerinden sürekli optimize edilir. Permanent machine secrets minimum seviyeye iner.

Bu dönüşüm:

Static Service Accounts

↓

Central Vault

↓

Automated Secrets Management

↓

Workload Identity

↓

Ephemeral Machine Identity

şeklinde ilerler.

Sık Sorulan Sorular

Non-Human Identity nedir?

Non-Human Identity, human user yerine application, service, workload, bot, device veya automation process tarafından kullanılan kimliktir.

Service Account nedir?

Application veya background service tarafından authentication ve authorization için kullanılan özel account türüdür.

Machine Identity nedir?

Server, application, workload veya automated system'ın digital environment içerisinde kendisini doğrulamak için kullandığı kimliktir.

API Key nedir?

Application'ın API service'e authentication veya access sağlaması için kullanılan credential türüdür.

API Key güvenli midir?

Doğru scope, secure storage, rotation ve monitoring uygulanırsa kullanılabilir. Ancak long-lived ve broad API keys ciddi risk oluşturabilir.

Hardcoded Secret nedir?

Password, API key veya token gibi credential'ın source code içine doğrudan yazılmasıdır.

Hardcoded Secret nasıl önlenir?

Secrets source code dışında merkezi Secrets Manager veya runtime identity mechanisms üzerinden sağlanmalıdır. Secret scanning de kullanılabilir.

Secrets Management nedir?

Application ve workloads tarafından kullanılan passwords, API keys, tokens ve certificates gibi sensitive credentials'ın merkezi ve güvenli lifecycle yönetimidir.

Dynamic Secret nedir?

İhtiyaç anında oluşturulan ve kısa süre sonra automatically expire veya revoke edilen credential'dır.

Short-Lived Credential nedir?

Belirli kısa süre için geçerli olan authentication credential'dır.

Managed Identity nedir?

Cloud provider tarafından lifecycle'ı yönetilen ve workload'un manuel secret saklamadan authentication yapmasını sağlayan identity modelidir.

Workload Identity nedir?

Application, container, serverless function veya pipeline gibi workload'un authentication için kullandığı machine identity'dir.

Workload Identity Federation nedir?

Workload'un long-lived static credential taşımadan external identity token üzerinden cloud environment'a temporary access sağlamasıdır.

Service Principal nedir?

Application veya automation tarafından kullanılan cloud-based Non-Human Identity türüdür.

Secrets Manager ile PAM aynı şey midir?

Hayır. PAM daha çok human privileged access ve privileged sessions üzerinde yoğunlaşırken Secrets Management applications ve machine credentials üzerinde yoğunlaşır. İki alan birbirini tamamlar.

HashiCorp Vault PAM midir?

HashiCorp Vault güçlü Secrets Management ve dynamic credential use case'leri sağlar. Ancak RDP/SSH privileged session management gibi full human PAM capabilities ayrı değerlendirilmelidir.

Service Account password rotation sistemi bozar mı?

Dependencies doğru analiz edilmeden yapılan rotation outage oluşturabilir. Bu nedenle dependency mapping ve automated update mekanizmaları önemlidir.

NHI için MFA kullanılabilir mi?

Human-oriented MFA çoğu machine identity için uygun değildir. Bunun yerine workload identity, certificates, short-lived tokens ve cryptographic authentication kullanılır.

AI Agent Non-Human Identity midir?

Evet. Kurumsal systems üzerinde autonomous veya delegated action gerçekleştiren AI Agent ayrı bir machine identity olarak yönetilmelidir.

Sonuç: Kimlik Güvenliği Artık Yalnız İnsanları Korumak Değildir

Modern kurumlarda çalışan sayısı birkaç bin olabilir.

Ancak applications, service accounts, API keys, certificates, containers, cloud workloads ve automation identities'in sayısı bunun çok üzerine çıkabilir.

Bu nedenle geleceğin Identity Security problemi büyük ölçüde Non-Human Identity Security problemidir.

Kurum bütün çalışanlarında:

MFA,

Passkey,

Conditional Access,

PAM

kullanabilir.

Ancak production database'in administrator password'u application configuration içerisinde yıllardır değişmeden duruyorsa identity security hâlâ eksiktir.

Aynı şekilde bütün administrators phishing-resistant MFA kullanıyor olabilir.

Ancak CI/CD pipeline source code içerisinde permanent cloud administrator access key taşıyorsa attack surface devam eder.

Bu nedenle modern Identity Security mimarisi:

Human Identity Security

ile

Machine Identity Security

arasında ayrım yapmadan ortak prensipler uygulamalıdır.

Bu prensipler:

Unique Identity

Least Privilege

Short Credential Lifetime

Centralized Governance

Continuous Monitoring

olmalıdır.

Machine identity tarafındaki en önemli dönüşüm ise static secrets'tan uzaklaşmaktır.

Traditional model:

Application → Username + Password

idi.

Daha modern model:

Application → Vault → Secret

haline geldi.

Bir sonraki aşama ise:

Workload → Identity → Temporary Credential

modelidir.

En olgun modelde application üzerinde permanent secret bırakılmaz.

Credential yalnız ihtiyaç olduğunda oluşturulur.

İşlem tamamlandığında expire edilir.

Bu yaklaşım:

Zero Standing Credential

olarak düşünülebilir.

AI Agents, autonomous automation ve cloud-native applications yaygınlaştıkça bu yaklaşım daha da kritik hale gelecektir.

Çünkü geleceğin kurumlarında yalnız insanların değil, yazılımların da kimlikleri olacaktır.

Ve bu identity'lerin sahip olduğu privileges, kurumun gerçek attack surface'inin önemli bölümünü oluşturacaktır.

Bu bölümün en önemli cümlesi:

Modern Identity Security'nin başarısı yalnız çalışan parolalarını ve administrator hesaplarını korumakla değil, kurum adına işlem yapan her application, service, workload ve AI Agent'ın kimliğini, credential'ını ve yetkisini aynı disiplinle yönetmekle ölçülmelidir.