İçeriğe geç
Sedat Özdemir
Yazılar

cloud-security

Anahtarı Kapının Üzerinde Unutmak: Kimlik Yönetiminde Neden Hep Aynı Hataları Yapıyoruz?

Kimlik yönetimi sadece şifre belirlemek değildir; bir pentest sırasında tüm sistemi nasıl tek bir unutulmuş token ile ele geçirdiğimi anlatıyorum.

Sedat Özdemir
· 4 dk okuma

Geçen hafta bir sızma testindeyim, sistem oldukça sıkı görünüyor. Firewall’lar ayakta, EDR (Endpoint Detection and Response) her hareketi izliyor, dışarıdan içeriye sızmak neredeyse imkansız gibi. Ama işin aslı, çoğu zaman kapıyı kırmana gerek kalmıyor; çünkü birileri anahtarı paspasın altına bırakmış oluyor. Bu "anahtar" meselesi, yani Identity Management (IAM), aslında siber güvenliğin en yumuşak karnı ama nedense hep en sona bırakılıyor.

Sıkça karşılaştığım bir durum var: Şirketler milyon dolarlık güvenlik yatırımı yapıyor ama bir yazılımcının "işim hızlı bitsin" diye yazdığı ve içinde AWS anahtarları olan bir script, bütün o yatırımı çöp edebiliyor. Kimlik yönetimi dediğimiz şey, sadece kullanıcı adı ve şifreden ibaret değil. Kimin, neye, ne kadar süreyle ve hangi şartlar altında erişebileceği meselesi. Ve inan bana, bu denklemi doğru kuran şirket sayısı bir elin parmaklarını geçmiyor.

"Geçici" Diye Başlayan Felaketler

Bir pentest sırasında başıma geldi; bir Jenkins sunucusuna erişim sağladım. Normalde yetkilerim kısıtlıydı ama bir de ne göreyim? Bir sistem yöneticisi, aylar önce bir sorunu çözmek için kendi yetkili hesabını bir otomasyon script'ine tanımlamış. "İşim bitince silerim" demiş belli ki ama o gün hiç gelmemiş. İşte biz buna "Identity Sprawl" diyoruz. Kontrolsüzce büyüyen, unutulan ve takip edilmeyen kimlikler.

Eğer bir kullanıcıya "lazım olur" diye gereğinden fazla yetki (over-privileged) veriyorsan, aslında saldırgana bir otoyol inşa ediyorsun demektir. Red Team operasyonlarında bizim en sevdiğimiz şey, düşük yetkili bir kullanıcıyı ele geçirip, onun sahip olduğu gereksiz "okuma" veya "listeleme" yetkileriyle sistemde keşif yapmaktır.

Bulut Dünyasında Kimlik Aslında Yeni Network'tür

Eskiden "iç ağdayım, güvendeyim" mantığı vardı. Artık o devir bitti. Şimdi her şey Identity üzerinden dönüyor. Özellikle AWS, Azure veya Google Cloud kullanıyorsan, network kuralları kadar IAM kuralları da kritik. Bir S3 bucket'ın dışarıya açık olması bir hata olabilir ama o bucket'a erişimi olan bir IAM rolünün "AdministratorAccess" yetkisine sahip olması tam bir felakettir.

Sana dikkat etmen gereken bir noktayı söyleyeyim: Service Accounts. İnsanların kullandığı hesapları MFA (Multi-Factor Authentication) ile bir şekilde koruyoruz. Peki ya uygulamaların birbiriyle konuşmak için kullandığı o "makine kimlikleri"? Onlarda MFA yok. Genelde bir yerlerde config.yaml içine hardcoded yazılmış bir token veya bir ortam değişkeni (environment variable) olarak duruyorlar.

Mesela, bak şu basit Python koduna. Çoğu yerde hala böyle şeyler görüyorum:

import boto3

# YAPMAMAN GEREKEN ŞEY:
# Bu anahtarlar bir gün mutlaka bir yerlere sızar (GitHub, log dosyaları vs.)
ACCESS_KEY = "AKIAXXXXXXXXXXXX"
SECRET_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

client = boto3.client(
    's3',
    aws_access_key_id=ACCESS_KEY,
    aws_secret_access_key=SECRET_KEY
)

def download_data():
    # Hassas verileri indiriyoruz...
    pass

Bunun yerine, her zaman Role-based veya Identity Federation mantığını kullanmalısın. Eğer kodun bir EC2 üzerinde çalışıyorsa, ona bir IAM Role ata. Kodun içinden key yönetmekle uğraşma. Boto3 kütüphanesi gidip o rolün geçici anahtarlarını kendisi alır. İşin aslı, en güvenli anahtar, senin hiç görmediğin anahtardır.

Secrets Management: Paspasın Altındaki Anahtarları Toplamak

Bence kimlik yönetiminin en kritik parçası Secrets Management. Şifreleri, API key'leri ve sertifikaları nasıl sakladığın, senin profesyonellik seviyeni belirler. Eğer bu veriler bir text dosyasında duruyorsa, geçmiş olsun.

Benim önerim, HashiCorp Vault gibi bir araç kullanman veya bulut sağlayıcının (AWS Secrets Manager vb.) sunduğu çözümlere yönelmen. Kodun içinden bir şifre çağırman gerektiğinde şöyle bir yapı kurmalısın:

import boto3
import json
from botocore.exceptions import ClientError

def get_secret():
    secret_name = "prod/database/password"
    region_name = "eu-central-1"

    # Secrets Manager istemcisini oluştur
    session = boto3.session.Session()
    client = session.client(
        service_name='secretsmanager',
        region_name=region_name
    )

    try:
        get_secret_value_response = client.get_secret_value(
            SecretId=secret_name
        )
    except ClientError as e:
        # Hata yönetimi burada kritik
        raise e

    # Şifreyi json olarak al ve kullan
    secret = get_secret_value_response['SecretString']
    return json.loads(secret)

# Kullanım:
db_creds = get_secret()
# db_creds['password'] ile bağlantını kur

Bu şekilde yaptığında, şifre değişse bile kodunu güncellemen gerekmez. Ayrıca kimin ne zaman o şifreye eriştiğini de loglayabilirsin. Bir Red Teamer olarak, loglanmayan her erişim benim için bir bayramdır.

"En Az Yetki" Prensibi Bir Slogan Değildir

Herkes "Least Privilege" (En Az Yetki) diyor ama kimse uygulamıyor. Neden? Çünkü zor. Bir yazılımcıya tam yetki vermek, "sana sadece şu 3 tabloya erişim veriyorum" demekten çok daha kolay. Ama o yazılımcının hesabı çalındığında, saldırgan sadece o 3 tabloya değil, tüm veritabanına, yedeklere ve hatta altyapıya erişiyor.

Geçenlerde bir analiz yaparken gördüm; bir şirkette stajyerin hesabıyla prod (canlı) ortamdaki Kubernetes cluster'ını silecek yetki varmış. "Neden?" diye sorduğumda, "Setup yaparken hata alıyordu, biz de geçici olarak admin yaptık, öyle kalmış" dediler. Bu cümle, siber güvenlikte duyabileceğin en tehlikeli cümledir.

Peki Ne Yapmalı?

Bence bu işi kökten çözmek istiyorsan şu 3 adıma odaklanmalısın:

  1. Envanter Çıkar: Kimin nerede hesabı var? Hangi uygulama hangi yetkiyle çalışıyor? İnan bana, bilmediğin onlarca "zombi" hesap bulacaksın.
  2. Just-In-Time (JIT) Access: Birine 7/24 admin yetkisi verme. İhtiyacı olduğunda 1 saatliğine o yetkiyi alsın, işi bitince otomatik kapansın.
  3. İzleme ve Alarm: Bir kullanıcı normalde erişmediği bir kaynağa erişmeye çalışıyorsa veya gece yarısı alışılmadık bir yerden login oluyorsa telefonun çalmalı.

Kimlik yönetimi sıkıcı gelebilir, kabul ediyorum. Firewall kuralı yazmak veya exploit geliştirmek kadar "havalı" değil. Ama bir sistemi gerçekten korumak istiyorsan, o sistemin "kim olduğunu" çok iyi bilmen gerekiyor.

Öğrenmeye açık kal, çünkü biz Red Team tarafında her gün yeni bir "unutulmuş yetki" arıyor olacağız. Eğer bir gün senin sistemine gelirsem, umarım o paspasın altındaki anahtarı çoktan kaldırmış olursun.

Görüşmek üzere, güvenli kal!

İlgili yazılar