Servis Hesabı Nedir?

Tanım

Servis hesabı, bir uygulamanın, servisin, betiğin veya iş yükünün diğer sistemlere kimlik doğrulamak ve işlem yapmak için kullandığı insan dışı bir kimliktir. İnsanları temsil eden kullanıcı hesaplarının aksine, servis hesapları yazılım süreçlerini temsil eder.

Terim birçok platformu kapsar:

• Active Directory — servis hesapları (SA olarak kullanılan normal kullanıcı hesapları), Managed Service Account (MSA), Group Managed Service Account (gMSA), delegated Managed Service Account (dMSA).
• Google Cloud — Service Account (@project.iam.gserviceaccount.com sonekli özel principal türü).
• AWS — IAM User (bazen iş yükleri için), IAM Role (iş yükleri için tercih edilen).
• Azure — service principal, managed identity.
• Kubernetes — pod/namespace başına ServiceAccount kaynağı.
• SaaS — tedarikçi "API hesapları" veya "entegrasyon hesapları".

Kısaca:

Servis hesabı, bir uygulamanın diğer sistemlerle konuşmak için kullandığı kimliktir — bir kişi hesabı gibi, ama yazılım için.

---

Neden Önemli

• Servis hesapları her yerdedir — her uygulama, entegrasyon, betik ve toplu iş bir ya da birden fazla servis hesabına sahiptir.
• Servis hesapları genellikle:
  • Sıradan kullanıcılardan daha fazla yetkiye sahiptir.
  • MFA kullanmaz.
  • Daha az izlenir.
  • Aktif bir yaşam döngüsü yoktur.
  • Sızdırılan uzun ömürlü kimlik bilgileri taşır.
• Servis hesapları modern ihlallerde başlıca hedeflerdir.

---

Servis Hesabı Türleri

Active Directory

• Kullanıcı tabanlı SA — SA olarak kullanılan normal AD kullanıcısı. SPN kayıtlıysa Kerberoasting'e açıktır.
• MSA — tek makineye bağlı; parolası otomatik yönetilir.
• gMSA — gruba bağlı; otomatik yönetilir; birden fazla makine.
• dMSA — delege edilmiş; yeni (Server 2025); eski servis hesaplarının daha güvenli alternatifi.

Google Cloud

• @project.iam.gserviceaccount.com sonekli servis hesapları.
• JSON anahtarı (yeni kullanım için önerilmez) ya da impersonation / Workload Identity Federation ile kimlik doğrular.

AWS

• IAM user (eski yaklaşım; iş yükleri için önerilmez).
• İş yüklerinin üstlendiği IAM role (tercih edilen).
• Kubernetes için IRSA.

Azure

• App registration / service principal (OAuth uygulamaları).
• Managed identity (sistem atamalı / kullanıcı atamalı).

Kubernetes

• Her pod'un bir Kubernetes servis hesabı vardır; yetkiler Role / ClusterRole ile verilir.
• IRSA / GKE Workload Identity / AKS Workload Identity ile bulut IAM'e federe edilir.

SaaS

• Salesforce Connected App'ler.
• Microsoft 365 uygulama kimlikleri.
• Tedarikçiye özgü "API kullanıcıları".

---

Yaygın Riskler

Kerberoasting (AD)

SPN'i olan kullanıcı tabanlı servis hesapları çevrimdışı parola kırmaya açıktır.

Uzun Ömürlü Statik Anahtarlar

GCP SA JSON anahtarları, AWS IAM erişim anahtarları, Azure SP gizli anahtarları — sızar, hiç döndürülmez.

Koda Gömülü Kimlik Bilgileri

Kodda, yapılandırmalarda, betiklerde, CI gizli değerlerinde.

Aşırı Yetkilendirme

"Kolaylık olsun" diye Editor / Owner / SA Admin verilen servis hesapları.

Paylaşılan Servis Hesapları

Tek bir servis hesabının birçok uygulama tarafından kullanılması; denetim izinde atıf kaybolur.

Sahipsiz Servis Hesapları

Ayrılan çalışanların oluşturduğu ve hiç kapatılmayan hesaplar.

Domain-Wide Delegation

Herhangi bir kullanıcı adına işlem yapabilen Workspace servis hesapları.

Hatalı Yapılandırılmış Federasyon

Zayıf öznitelik koşullarına sahip Workload Identity havuzları.

---

Gerçek Dünya Örnekleri

1. Kerberoasting ile Ele Geçirme

SQL Server için kullanılan kullanıcı tabanlı servis hesabının SPN'i ve zayıf bir parolası (8 karakter) vardı. Saldırgan Kerberos bileti istedi, çevrimdışı kırdı ve veritabanı yöneticisi oldu. Önlem: gMSA / dMSA'ya geçiş, uzun parolalar, Kerberos armoring.

2. Sızan GCP Servis Hesabı Anahtarı

Servis hesabı JSON anahtarı GitHub'a commit'lendi; bir tarayıcı buldu; proje numaralandırıldı. Önlem: gizli değer taraması, Workload Identity Federation'a geçiş, anahtar döndürme.

3. Aşırı Yetkili Servis Hesabı

CI servis hesabı "dağıtım" için Project Editor yetkisine sahipti. CI ele geçirilince üretim veritabanına zarar verildi. Önlem: servis başına kapsamlı roller, en az ayrıcalık.

4. Sahipsiz Servis Hesabı

Beş yıl önce ayrılan bir geliştiricinin oluşturduğu servis hesabı hâlâ aktifti ve 23 IAM bağlamasında yer alıyordu. Denetimde keşfedildi. Önlem: insan dışı kimlik yaşam döngüsü süreci, düzenli gözden geçirme.

5. Domain-Wide Delegation İstismarı

Bir otomasyon betiği DwD yetkili Workspace servis hesabı kullanıyordu. Betik ele geçirilince herhangi bir kullanıcının e-postasına erişildi. Önlem: DwD kaldırıldı, kullanıcı başına OBO akışına geçildi, yüksek riskli senaryolara insan onayı eklendi.

---

En İyi Uygulamalar

1. Tüm platformlardaki servis hesaplarını envanterleyin.
2. Her servis hesabına bir sahip (adı belli bir insan) atayın.
3. Uygulama / amaç başına ayrı servis hesabı — paylaşım yok.
4. Anahtar yerine federasyon / managed identity tercih edin.
5. Mümkün olan her yerde statik anahtarları kaldırın; kaçınılmazsa döndürün.
6. Üç ayda bir gözden geçirilen en az ayrıcalık.
7. AD'de kullanıcı tabanlı servis hesapları yerine gMSA / dMSA.
8. Mümkünse kullanıcı hesaplarında SPN olmasın.
9. Güçlü parola ya da parolasız (platform tarafından yönetilen).
10. Servis hesabı kullanımında denetim ve anomali tespiti.
11. Yaşam döngüsü iş akışı — sağlama ve kapatma.
12. Uyumluluk eşlemesi.

---

Kontrol Listesi

• Tüm servis hesaplarının envanteri var mı?
• Sahipler atandı mı?
• Amaç başına ayrı (paylaşım yok) mı?
• Federasyon / managed identity tercih ediliyor mu?
• Statik anahtarlar en aza indirildi ve döndürülüyor mu?
• En az ayrıcalık üç ayda bir gözden geçiriliyor mu?
• AD'de gMSA / dMSA kullanılıyor mu?
• SPN'li kullanıcı tabanlı servis hesabı yok mu?
• Denetim ve anomali tespiti var mı?
• Yaşam döngüsü iş akışı var mı?
• Sahipsiz hesaplar kapatılıyor mu?
• Uyumluluk eşlendi mi?

---

Forestall Nasıl Yardımcı Olur

Forestall; bulut, AD, SaaS ve Kubernetes genelindeki servis hesaplarını sürekli olarak keşfeder, envanterler ve riske göre sıralar — önceliklendirilmiş düzeltme rehberliğiyle birlikte.

---

Sık Sorulan Sorular

Servis hesabı ile kullanıcı hesabı arasındaki fark nedir?

Kullanıcı hesabı bir kişiyi temsil eder; etkileşimli kimlik doğrulama ve MFA kullanır. Servis hesabı yazılımı temsil eder; programatik kimlik doğrulama yapar; MFA yoktur.

MSA yerine gMSA mı kullanmalıyım?

Evet — gMSA birden fazla makineyi destekler ve daha esnektir. Mümkünse dMSA (Server 2025) daha da iyidir.

GCP servis hesabı JSON anahtarları neden risklidir?

Uzun ömürlüdür, kolayca sızar ve büyük ölçekte döndürülmesi zordur. Modern en iyi uygulama: Workload Identity Federation ve impersonation.

Kubernetes servis hesapları için ne yapmalı?

Kullanın; statik bulut kimlik bilgilerini ortadan kaldırmak için IRSA / GKE Workload Identity / AKS Workload Identity ile bulut IAM'e federe edin.

Servis hesaplarını uygulamalar arasında paylaşmalı mıyım?

Hayır — uygulama başına ayrı servis hesabı atfı korur ve en az ayrıcalığı mümkün kılar.

---

Sonuç

Servis hesapları modern otomasyonun yükünü taşır — ve en çok hedeflenen kimlik yüzeylerinden biridir. Envanterleyin, sahip atayın, federasyon / managed identity ile statik anahtarları kaldırın, en az ayrıcalığı uygulayın, yaşam döngüsünü otomatikleştirin, anomalileri izleyin ve modern alternatiflere geçin (AD'de gMSA / dMSA; bulutta WIF / managed identity). Doğru yapıldığında servis hesaplarınız ortamınızın en büyük yönetilmeyen riski olmaktan çıkıp yönetilen bir varlığa dönüşür.