Güvenlik Sözlüğü: Her Geliştirici Ekibinin Bilmesi Gereken 50+ Terim

Güvenlik terminoloji karışıklığının ekibine haftalarca iş kaybettirdiği anlar yaşadın mı? Ben yaşadım. Authentication sistemleri ile çalışmak gösterdi ki en büyük güvenlik hataları genellikle basit yanlış iletişimle başlıyor. OAuth2 uzmanın "authentication yapıyoruz" diye ısrar edip güvenlik audit'in OAuth2'nin authentication'ı handle etmediği için fail olduğu zaman... bu pahalı bir öğrenme deneyimi oldu.

Bu sözlük sadece tanımlar değil. Implementation bağlamı, yaygın yanlış anlamalar ve prodüksiyon sistemlerinden öğrenilen dersler içeren bir saha rehberi. Stakeholder'ların buzzword'leri yanlış kullandığı ya da SMS OTP'nin neden güvenli olmadığını açıklaman gereken anlar için referansın olarak düşün.

Authentication Temelleri#

MFA (Multi-Factor Authentication)#

Tanım: İki veya daha fazla bağımsız faktör tipi gerektiren authentication: bildiğin (şifre), sahip olduğun (telefon), ya da olduğun (parmak izi) bir şey.

Implementation Gerçeği: Gerçek MFA farklı faktör tipleri gerektirir. Şifre + güvenlik sorusu MFA değil - ikisi de bilgi faktörü.

// FIDO2/WebAuthn ile doğru MFA implementation'ıinterface MFAChallenge {  primaryAuth: 'password' | 'biometric';  secondaryAuth: 'totp' | 'webauthn' | 'sms'; // SMS'ten kaçın  fallbackOptions: string[];}
const authenticateUser = async (challenge: MFAChallenge) => {  const primaryResult = await validatePrimary(challenge.primaryAuth);  if (!primaryResult.success) return { success: false };
  const secondaryResult = await validateSecondary(challenge.secondaryAuth);  return { success: secondaryResult.success };};

Öğrenilen Ders: "Finansal bir müşteriyle çalışırken, SMS OTP'lerin SIM swapping saldırılarına karşı önemli bir zaafiyet oluşturduğunu öğrendik. Bu, 'yıllarca çalıştı'nın yeterli güvenlik gerekçesi olmadığını gösterdi - tehdit manzaraları konfor alanlarından daha hızlı gelişiyor."

Metrikler: Doğru MFA, hesap ele geçirmeyi %99.9 azaltır vs two-step verification için %80.

2FA vs 2SV (Two-Factor vs Two-Step Verification)#

Ana Fark: 2FA farklı faktör tiplerini kullanır, 2SV aynı tipi iki kez kullanabilir.

• 2FA: Şifre (bilgi) + hardware key (sahiplik)
• 2SV: Şifre (bilgi) + SMS kodu (yine bilgi - telefon numaranı biliyorsun)

Sektör Karışıklığı: Google kendi UI'ında 2SV implementation'ına "2FA" diyor, yaygın yanlış anlamaya katkıda bulunuyor.

Implementation Rehberliği: Mümkün olduğunda hardware key'ler veya biometric authenticator'larla gerçek 2FA'yı tercih et.

OTP (One-Time Password)#

TOTP (Time-based OTP): 30 saniyelik pencereler, RFC 6238 standardı HOTP (Counter-based OTP): Daha az yaygın, RFC 4226 standardı SMS OTP: SIM swapping vulnerabilities nedeniyle deprecated

import { authenticator } from 'otplib';
// Yeni kullanıcı için TOTP secret oluşturconst secret = authenticator.generateSecret();
// Kullanıcının TOTP'sini validate etconst validateTOTP = (token: string, secret: string): boolean => {  try {    return authenticator.verify({ token, secret });  } catch (error) {    return false;  }};
// Clock drift için her zaman window tolerance kullanauthenticator.options = { window: 1 }; // 1 step tolerance izin ver

Implementation: Yeni sistemler için Google Authenticator veya Authy gibi authenticator app'leri kullan, SMS asla.

Biometric Authentication#

Tipler: Parmak izi, yüz tanıma, iris tarama, ses paterni Ana Metrikler: False Acceptance Rate (FAR) vs False Rejection Rate (FRR)

Kritik Kural: Biometric'i asla tek authentication olarak kullanma - her zaman ikinci faktör olarak. Biometric data tehlikeye girerse değiştirilemez.

Platform Entegrasyonu:

// WebAuthn biometric authenticationconst authenticateWithBiometric = async () => {  const credential = await navigator.credentials.create({    publicKey: {      challenge: new Uint8Array(32),      rp: { name: "Uygulamanız" },      user: { id: userId, name: username, displayName: displayName },      pubKeyCredParams: [{ alg: -7, type: "public-key" }],      authenticatorSelection: {        authenticatorAttachment: "platform", // Built-in biometric        userVerification: "required"      }    }  });};

Privacy Endişeleri: Biometric template'ler güvenli saklanmalı ve revoke edilebilir olmalı. Apple'ın Secure Enclave'i ve Android'in TEE'si mevcut best practice'ler.

Modern Authentication Protocol'leri#

OAuth2#

Amacı: Authorization framework'ü (authentication DEĞİL!) Yaygın Karışıklık: "Login için OAuth2 kullanıyoruz" - Hayır, OAuth2 birinin ne yapabileceğini söyler, kim olduğunu değil.

Grant Type'ları:

• Authorization Code + PKCE (SPA'lar için önerilen)
• Client Credentials (service-to-service)
• Device Flow (IoT/TV app'leri)
• Implicit Flow (deprecated, güvenlik sorunları)

// PKCE ile güvenli OAuth2 implementation'ıconst oauth2Flow = async () => {  const codeVerifier = generateCodeVerifier();  const codeChallenge = await generateCodeChallenge(codeVerifier);
  const authUrl = `${authServer}/authorize?` +    `response_type=code&` +    `client_id=${clientId}&` +    `redirect_uri=${redirectUri}&` +    `scope=${scope}&` +    `code_challenge=${codeChallenge}&` +    `code_challenge_method=S256`;
  // Authorization code ile callback'ten sonra  const tokenResponse = await exchangeCodeForToken(code, codeVerifier);};

Implementation Öğrenmesi: "Bir ekip uygulanması yaygın OAuth2 karışıklığını ortaya çıkardı. Haftalarca çalışmadan sonra OAuth2'nin authorization'u handle ettiğini, authentication değil - kimlik doğrulama için OIDC gerektirdiğini keşfettik. Bu, terminoloji yanlış anlaşılmasının nasıl pahalı mimari hatalar oluşturduğunu vurguladı."

OIDC (OpenID Connect)#

Tanım: OAuth2 üzerine inşa edilmiş authentication katmanı Ana Ekleme: Kullanıcının kim olduğunu gerçekten söyleyen ID token'ları

Ana Komponenler:

• ID Token (kullanıcı bilgisi ile JWT)
• UserInfo Endpoint
• Discovery Endpoint (/.well-known/openid-configuration)

interface OIDCTokenResponse {  access_token: string;    // API call'ları için (OAuth2)  id_token: string;        // Authentication için (OIDC)  refresh_token: string;   // Yeni token'lar almak için  token_type: 'Bearer';  expires_in: number;}
const validateIdToken = async (idToken: string) => {  const jwks = await fetchJWKS(issuer);  const payload = jwt.verify(idToken, jwks);
  // Gerekli claim'leri validate et  assert(payload.iss === expectedIssuer);  assert(payload.aud === clientId);  assert(payload.exp > Date.now() / 1000);
  return payload; // Kullanıcı kimlik bilgisi içerir};

Ne Zaman Kullan: Modern web app'leri, mobile app'ler, SPA'lar - kullanıcının kim olduğunu bilmeye ihtiyaç duyan her şey.

ID Token (OIDC)#

Tanım: OpenID Connect'in parçası olan, kullanıcı kimlik bilgilerini içeren JWT Amacı: Authentication (kullanıcının kim olduğu) vs access token (ne yapabileceği)

Yapısı: Belirli claim'lere sahip standart JWT

interface IDTokenPayload {  iss: string;      // Issuer (kimlik sağlayıcısı)  sub: string;      // Subject (kullanıcı tanımlayıcısı)  aud: string;      // Audience (client ID'niz)  exp: number;      // Expiry timestamp  iat: number;      // Issued at timestamp  auth_time: number; // Kullanıcının gerçekte kimlik doğrulaması yaptığı zaman  nonce?: string;   // Replay attack'leri önler
  // Standart profil claim'leri  name?: string;  email?: string;  picture?: string;
  // Custom claim'ler  roles?: string[];  department?: string;}
const validateIDToken = async (idToken: string) => {  // 1. Provider'ın public key'lerini kullanarak signature'ı doğrula  const jwks = await fetchJWKS(issuerUrl + '/.well-known/jwks.json');  const decoded = jwt.verify(idToken, jwks) as IDTokenPayload;
  // 2. Standart claim'leri doğrula  if (decoded.iss !== expectedIssuer) throw new Error('Invalid issuer');  if (decoded.aud !== clientId) throw new Error('Invalid audience');  if (decoded.exp <= Math.floor(Date.now() / 1000)) throw new Error('Token expired');
  // 3. max_age belirtildiyse auth_time'ı doğrula  if (maxAge && decoded.auth_time < (Date.now()/1000 - maxAge)) {    throw new Error('Authentication too old');  }
  return decoded;};

Access Token'lardan Temel Farkları:

• ID token'lar client app'in kullanıcının kim olduğunu bilmesi içindir
• Access token'lar API çağrılarının kullanıcının ne yapabileceğini bilmesi içindir
• ID token'lar API'lara gönderilmemelidir (access token kullanın)
• ID token'lar kullanıcı profil bilgilerini içerir

Yaygın Hatalar:

• ID token'ı API authentication için kullanmak (güvenlik riski)
• Signature'ı server-side doğrulamamak
• ID token payload'ında hassas veri saklamak (şifrelenmemiştir)
• ID token'ları uygulamalar arasında paylaşmak

Yaygın Hata: "Bir geliştirme ekibi API çağrıları için ID token kullanıyordu çünkü 'kullanıcı bilgisi içeriyor.' Bu, concern'leri net bir şekilde ayırma ihtiyacını vurguladı: ID token'lar client app'lerin kullanıcının kim olduğunu bilmesi için, access token'lar API'ların ne yapabileceklerini bilmesi için."

SAML 2.0#

Tanım: XML tabanlı authentication ve authorization standardı Enterprise Gerçeği: Fortune 500 şirketlerinde hala dominant

Flow Tipleri:

• SP-initiated (uygulamanız flow'u başlatır)
• IdP-initiated (identity provider flow'u başlatır)

Implementation Karmaşıklığı: XML signature'lar, sertifika yönetimi ve karmaşık konfigürasyon nedeniyle yüksek.

<!-- SAML Assertion Örneği --><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">  <saml:Subject>    <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">      [email protected]    </saml:NameID>  </saml:Subject>  <saml:AttributeStatement>    <saml:Attribute Name="Role">      <saml:AttributeValue>Manager</saml:AttributeValue>    </saml:Attribute>  </saml:AttributeStatement></saml:Assertion>

Stratejik Öğrenme: "'Modernleştirme' için SAML'den OIDC'ye migration, enterprise müşterilerin mevcut altyapıya dayalı güçlü tercihlere sahip olduğunu ortaya çıkardı. Her iki protokol de farklı organizasyonel ihtiyaçlara ve bağlamlara hizmet ediyor."

Protocol Karşılaştırma Matrisi#

Token Güvenliği#

JWT (JSON Web Token)#

Yapı: Header.Payload.Signature (hepsi Base64URL encoded)

Best Practice'ler:

• Access token'lar için maksimum 15 dakika expiry
• Mümkün olduğunda RS256'yı (asymmetric) HS256'ya (symmetric) tercih et
• Payload'a hassas veri koyma (sadece Base64, şifreli değil)

interface JWTPayload {  iss: string;  // Issuer  sub: string;  // Subject (kullanıcı ID)  aud: string;  // Audience  exp: number;  // Expiry (UNIX timestamp)  iat: number;  // Issued at  nbf: number;  // Not before  jti: string;  // JWT ID (revocation için)}
const validateJWT = (token: string, publicKey: string): JWTPayload => {  const decoded = jwt.verify(token, publicKey, {    algorithms: ['RS256'],    issuer: expectedIssuer,    audience: expectedAudience  });
  // Expiry'yi her zaman server-side kontrol et  if (decoded.exp <= Math.floor(Date.now() / 1000)) {    throw new Error('Token expired');  }
  return decoded as JWTPayload;};

Güvenlik Olayı: "JWT token'larının 'kolaylık' için 30 günlük expiry'ye ayarlanması durumunda bir prodüksiyon sorunu oluştu. Compromise edildiğinde, bu uzun süre zaafiyet pencereleri oluşturdu. Bu, uygun refresh mekanizmalarıyla kısa ömürlü access token'ların önemini pekiştirdi."

JWKS (JSON Web Key Set)#

Tanım: JWT imzalarını doğrulamak için kullanılan public key'leri içeren JSON dokümanı, genellikle /.well-known/jwks.json'da servis edilir.

Implementation: OAuth2/OpenID Connect provider'ları token doğrulaması için public key'lerini JWKS olarak yayınlar.

interface JWKSKey {  kty: string;  // Key type (RSA, EC)  use: string;  // Usage (sig for signature)  kid: string;  // Key ID  n: string;    // RSA modulus (Base64URL)  e: string;    // RSA exponent (Base64URL)}
const fetchJWKS = async (issuerUrl: string): Promise<JWKSKey[]> => {  const response = await fetch(`${issuerUrl}/.well-known/jwks.json`);  const jwks = await response.json();  return jwks.keys;};
// kid (Key ID) ile doğru key'i bulconst getSigningKey = (jwks: JWKSKey[], kid: string): JWKSKey => {  const key = jwks.find(k => k.kid === kid);  if (!key) throw new Error(`Key ${kid} not found in JWKS`);  return key;};

Debugging Deneyimi: "Invalid signature hataları günlerce sürdü, provider'ın key rotation'ından sonra JWKS cache'imizin güncellenmediğini keşfedene kadar. Bu, uygun cache refresh stratejileri ve kid header doğrulaması ihtiyacını vurguladı."

Best Practice'ler:

• JWKS'i cache et ama otomatik refresh implement et
• kid (Key ID) match'ini her zaman verify et
• Key rotation'ı graceful handle et

Signing Key / Private Key#

Tanım: JWT'leri dijital olarak imzalamak için kullanılan kriptografik private key, authenticity'yi kanıtlayan signature kısmını oluşturur.

Implementation: Güvenli bir şekilde saklanmalı ve düzenli olarak rotate edilmeli. Sadece token issuer'ın erişimi olmalı.

// Server-side JWT signing (RS256)const signJWT = (payload: JWTPayload, privateKey: string): string => {  return jwt.sign(payload, privateKey, {    algorithm: 'RS256',    keyid: currentKeyId,  // JWKS lookup için kid include et    expiresIn: '15m'  });};
// Key rotation stratejisiinterface SigningKeyPair {  kid: string;  privateKey: string;  publicKey: string;  createdAt: Date;}
const rotateSigningKeys = async (): Promise<void> => {  // Yeni keypair generate et  const newKeyPair = generateRSAKeyPair();
  // Yeni private key'i güvenli şekilde store et  await keyStore.store(newKeyPair.kid, newKeyPair.privateKey);
  // JWKS'i yeni public key ile update et  await updateJWKS(newKeyPair.publicKey, newKeyPair.kid);
  // Eski key'i grace period boyunca aktif tut  scheduleKeyRetirement(previousKeyId, '24h');};

Security Gereksinimleri:

• Private key'leri HSM veya secure key management system'de store et
• Key'leri düzenli rotate et (minimum aylık)
• Private key'leri asla log'larda veya client code'da expose etme
• Güçlü key length'leri kullan (RSA 2048+ veya EC P-256+)

Lifecycle Management Öğrenmesi: "'Geçici' bir signing key, ertelenen key rotation planları nedeniyle yıllarca kullanımda kaldı. Güvenlik tehlikeye girdiğinde, bu uygun key lifecycle management'ın gelecek iş olarak değil, ilk günden uygulanması gereken bir gereklilik olduğunu gösterdi."

Access Token'lar vs Refresh Token'lar#

Access Token'lar: Kısa ömürlü (5-15 dakika), API call'ları için kullanılır Refresh Token'lar: Daha uzun ömürlü (7 gün), yeni access token'lar almak için kullanılır

Storage Stratejisi:

• Access token'lar: Sadece memory'de (localStorage asla)
• Refresh token'lar: Mümkün olduğunda güvenli, httpOnly cookie'ler

class TokenManager {  private accessToken: string | null = null;  private refreshToken: string | null = null;  private refreshPromise: Promise<string> | null = null;
  async getValidAccessToken(): Promise<string> {    if (this.accessToken && !this.isTokenExpired(this.accessToken)) {      return this.accessToken;    }
    // Concurrent refresh request'leri önle    if (!this.refreshPromise) {      this.refreshPromise = this.refreshAccessToken();    }
    return this.refreshPromise;  }
  private async refreshAccessToken(): Promise<string> {    try {      const response = await fetch('/auth/refresh', {        method: 'POST',        credentials: 'include', // httpOnly refresh token'ı dahil et      });
      const { access_token, refresh_token } = await response.json();
      this.accessToken = access_token;      // Refresh token rotation - her zaman yeni refresh token al      if (refresh_token) {        this.refreshToken = refresh_token;      }
      return access_token;    } finally {      this.refreshPromise = null;    }  }}

Token Rotation: Compromise olduğunda hasarı sınırlamak için refresh token'ları kullanımda her zaman rotate et.

Bearer Token'lar vs API Key'ler#

Bearer Token'lar: Dinamik, kısa ömürlü, OAuth2/JWT ecosystem'inin parçası API Key'ler: Statik, uzun ömürlü, basit authentication mekanizması

Ne Zaman Kullan:

• Bearer token'lar: Kullanıcı authentication'ı, dinamik permissions
• API key'ler: Service-to-service, basit entegrasyonlar, webhook'lar

Güvenlik Karşılaştırması:

// Bearer Token (kullanıcı auth için tercih edilen)const callAPIWithBearer = async (endpoint: string) => {  const token = await tokenManager.getValidAccessToken();  return fetch(endpoint, {    headers: {      'Authorization': `Bearer ${token}`    }  });};
// API Key (service auth için kabul edilebilir)const callAPIWithKey = async (endpoint: string) => {  return fetch(endpoint, {    headers: {      'X-API-Key': process.env.API_KEY, // Asla client'ta expose etme      'User-Agent': 'MyService/1.0'    }  });};

Zero Trust & Modern Güvenlik#

Zero Trust Architecture#

İlke: "Asla güvenme, her zaman doğrula" Ana Komponenler: Identity, device, network, uygulama, data doğrulama

Implementation Aşamaları:

1. Identify: Tüm kullanıcıları, cihazları, uygulamaları, dataları map'le
2. Protect: Least-privilege erişim kontrollerini implement et
3. Detect: Anomali ve tehditler için monitör et
4. Respond: Otomatik tehdit response ve remediation

Migration Zaman Çizelgesi: Enterprise için tipik olarak 18-24 ay Maliyet Analizi: $500K-$2M başlangıç yatırım, ama breach etkisinde %50 azalma

// Zero Trust policy örneğiinterface ZeroTrustPolicy {  user: {    verified: boolean;    riskScore: number;    mfaCompleted: boolean;  };  device: {    managed: boolean;    compliant: boolean;    lastSeen: Date;  };  network: {    location: string;    trustLevel: 'high' | 'medium' | 'low';  };  resource: {    classification: 'public' | 'internal' | 'confidential' | 'restricted';    requiredClearance: number;  };}
const evaluateAccess = (policy: ZeroTrustPolicy): boolean => {  // Continuous verification - her request  if (!policy.user.verified || !policy.user.mfaCompleted) return false;  if (!policy.device.managed || !policy.device.compliant) return false;  if (policy.user.riskScore > policy.resource.requiredClearance) return false;
  return true;};

ZTNA (Zero Trust Network Access)#

Değiştirdiği: Geleneksel VPN'i microsegmentation ile Faydaları: Uygulama-spesifik erişim, gelişmiş performans (VPN'den %40 daha hızlı)

Implementation Tipleri:

• Agent-based: Her cihazda software
• Agentless: Browser tabanlı erişim

Major Vendor'lar: Zscaler, Palo Alto Prisma, Cloudflare Access

SASE (Secure Access Service Edge)#

Komponenler: SD-WAN + ZTNA + CASB + FWaaS + SWG Tanım: Networking ve güvenliği birleştiren cloud-native güvenlik platformu

ROI: Güvenlik stack karmaşıklığında %30 azalma Maliyet: Kullanıcı başına ayda $50-150 Zaman Çizelgesi: 3-5 yıllık stratejik girişim

Web Güvenlik Header'ları#

HSTS (HTTP Strict Transport Security)#

Amaç: Belirtilen süre için HTTPS'i zorlar Header Örneği: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Implementation Stratejisi:

# Test için kısa süre ile başlaadd_header Strict-Transport-Security "max-age=300" always;
# Test'ten sonra süreyi artıradd_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
# Son olarak maksimum güvenlik için preload ekleadd_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Preload Listeleri: Chrome, Firefox, Edge HSTS domain'lerin hardcoded listelerini tutuyor.

CSP (Content Security Policy)#

Amaç: Resource yüklemesini kontrol ederek XSS ve injection saldırılarını önler

Progressive Implementation:

# Report-only mode ile başlaContent-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report
# Temel policyContent-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
# Sıkı policy (hedef)Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:

Yaygın Pitfall: Third-party script'lerin bozulması (Google Analytics, chat widget'ları). Her zaman önce report-only mode'da test et.

Certificate Pinning (Deprecated)#

Durum: HPKP 2024 itibariyle resmi olarak ölü Risk: Key'ler beklenmedik şekilde değişirse self-DOS

Modern Alternatif: Certificate Transparency (CT) + CAA record'lar

; CAA record örneğiexample.com. CAA 0 issue "letsencrypt.org"example.com. CAA 0 issuewild ";"example.com. CAA 0 iodef "mailto:[email protected]"

Erişim Kontrol Modelleri#

RBAC (Role-Based Access Control)#

Pattern: Kullanıcılar → Roller → İzinler En İyi Kullanım: Stabil organizasyon yapıları için

-- RBAC Database SchemaCREATE TABLE roles (  id UUID PRIMARY KEY,  name VARCHAR(255) NOT NULL,  description TEXT);
CREATE TABLE permissions (  id UUID PRIMARY KEY,  resource VARCHAR(255) NOT NULL,  action VARCHAR(255) NOT NULL);
CREATE TABLE role_permissions (  role_id UUID REFERENCES roles(id),  permission_id UUID REFERENCES permissions(id),  PRIMARY KEY (role_id, permission_id));
CREATE TABLE user_roles (  user_id UUID REFERENCES users(id),  role_id UUID REFERENCES roles(id),  granted_at TIMESTAMP DEFAULT NOW(),  PRIMARY KEY (user_id, role_id));

Role Explosion Önleme: Her permission kombinasyonu için spesifik roller oluşturmak yerine hiyerarşik roller ve role composition kullan.

ABAC (Attribute-Based Access Control)#

Pattern: Kullanıcı, kaynak, ortam ve aksiyon attribute'larına dayalı dinamik izinler

Örnek Policy: "Doktorlar çalışma saatlerinde kendi departmanlarındaki hasta kayıtlarını görüntüleyebilir"

interface ABACAttributes {  user: {    role: string;    department: string;    clearanceLevel: number;  };  resource: {    type: string;    owner: string;    classification: string;  };  environment: {    time: Date;    location: string;    network: string;  };  action: string;}
const evaluateABACPolicy = (attrs: ABACAttributes): boolean => {  // Karmaşık kural değerlendirmesi  if (attrs.user.role === 'doctor' &&      attrs.resource.type === 'patient_record' &&      attrs.action === 'read') {
    const currentHour = attrs.environment.time.getHours();    const isWorkHours = currentHour >= 8 && currentHour <= 18;    const sameDepartment = attrs.user.department === attrs.resource.owner;
    return isWorkHours && sameDepartment;  }
  return false;};

Kullanım Alanı: Statik rollerle modellenemeyen karmaşık, contextual erişim gereksinimleri.

IAM (Identity and Access Management)#

Tanım: Kapsamlı identity yaşam döngüsü yönetimi Komponenler: Authentication, authorization, administration, audit

Major Platformlar & Maliyetler:

• AWS IAM: $0 (temel), advanced kullanıcı başına ayda$6
• Azure AD: Kullanıcı başına ayda $6-22
• Okta: Kullanıcı başına ayda $8-15
• Auth0: 1000 kullanıcı başına ayda $23-240

Federation: Birden çok identity kaynağının (Active Directory, Google Workspace, vs.) bağlanması

Principle of Least Privilege#

Tanım: Minimum gerekli izinleri ver Implementation: Time-bound erişim (JIT/JEA), düzenli erişim incelemeleri

// Just-in-Time (JIT) erişim örneğiinterface JITAccessRequest {  userId: string;  resource: string;  permissions: string[];  duration: number; // dakika  justification: string;  approver?: string;}
const grantJITAccess = async (request: JITAccessRequest) => {  // Hassas kaynaklar için onay gerekli  if (request.resource.includes('production')) {    await requireApproval(request);  }
  // Otomatik revocation ile erişim ver  await grantPermissions(request.userId, request.permissions);
  // Otomatik revocation'ı schedule et  setTimeout(async () => {    await revokePermissions(request.userId, request.permissions);  }, request.duration * 60 * 1000);
  // Audit için logla  auditLog.log('JIT_ACCESS_GRANTED', request);};

Otomasyon: Kullanım pattern'larına dayalı olarak kullanılmayan izinleri otomatik olarak kaldır.

Emerging Standardlar (2024)#

Passkey'ler (FIDO2/WebAuthn)#

Tanım: Device-native biometric veya PIN kullanarak passwordless authentication Benimsenme: 2024'te hızla büyüyor, Apple, Google, Microsoft'tan güçlü destekle

Implementation:

// Yeni kullanıcı için passkey oluşturconst createPasskey = async () => {  const credential = await navigator.credentials.create({    publicKey: {      challenge: new Uint8Array(32),      rp: { name: "Uygulamanız", id: "yourapp.com" },      user: {        id: new TextEncoder().encode(userId),        name: userEmail,        displayName: userName      },      pubKeyCredParams: [        { type: "public-key", alg: -7 },  // ES256        { type: "public-key", alg: -257 } // RS256      ],      authenticatorSelection: {        authenticatorAttachment: "platform", // Cihaza built-in        requireResidentKey: true,        userVerification: "required"      }    }  });
  // Credential ID ve public key'i server'da sakla  await registerCredential(userId, credential);};
// Passkey ile authenticateconst authenticateWithPasskey = async () => {  const assertion = await navigator.credentials.get({    publicKey: {      challenge: new Uint8Array(32),      allowCredentials: userCredentials.map(cred => ({        type: "public-key",        id: cred.id      })),      userVerification: "required"    }  });
  // Assertion'ı server'da verify et  const isValid = await verifyAssertion(assertion);  return isValid;};

Kullanıcı Deneyimi: Touch Face ID veya Windows Hello, hatırlanacak şifre yok.

FIDO2 Komponentleri#

WebAuthn: Browser'lar tarafından implement edilen W3C standardı (%95 coverage) CTAP2: Platform ve authenticator'lar arasındaki communication protocol

Authenticator Tipleri:

• Platform: Cihaza built-in (Touch ID, Face ID, Windows Hello)
• Roaming: External key'ler (YubiKey, USB/NFC cihazlar)

DPoP (Demonstration of Proof of Possession)#

Amaç: Token hırsızlığı/replay'ini önlemek için OAuth2 token'larını client'ın private key'ine bağlar Durum: RFC 9449 (2023), erken benimsenme aşaması

Implementation: Client her token kullanımında private key sahipliğini prove eder

// DPoP token bindingconst createDPoPProof = async (httpMethod: string, url: string, accessToken: string) => {  const header = {    typ: 'dpop+jwt',    alg: 'ES256',    jwk: publicKeyJWK  };
  const payload = {    jti: generateUUID(),    htm: httpMethod,    htu: url,    iat: Math.floor(Date.now() / 1000),    ath: await sha256(accessToken) // Access token hash  };
  return jwt.sign(payload, privateKey, { header });};
// API request ile DPoP proof kullanconst callAPIWithDPoP = async (url: string, accessToken: string) => {  const dPopProof = await createDPoPProof('GET', url, accessToken);
  return fetch(url, {    headers: {      'Authorization': `DPoP ${accessToken}`,      'DPoP': dPopProof    }  });};

Legacy Authentication Metodları#

Basic Authentication#

Metod: Authorization header'da Base64 encoded username:password Güvenlik: Düşük - credential'lar her request ile gönderiliyor

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Kullanım Alanları: Basit script'ler, legacy sistem entegrasyonu Gereksinimler: HTTPS kullanımı ZORUNLU

Digest Authentication#

Durum: Eski - bozuk MD5 hashing kullanıyor Kullanım: Sadece legacy sistem desteği, yeni sistemler için asla

Migration Yolu: OAuth2/OIDC ile değiştir ya da minimum modern token-based auth.

Mutual TLS (mTLS)#

Tanım: Hem client hem server sertifika sunar Kullanım Alanları: Service-to-service communication, IoT cihazlar, yüksek güvenlik ortamları

// mTLS client konfigürasyonuconst httpsOptions = {  cert: fs.readFileSync('client-cert.pem'),  key: fs.readFileSync('client-key.pem'),  ca: fs.readFileSync('ca-cert.pem'),  rejectUnauthorized: true};
const makeSecureRequest = () => {  return fetch('https://api.example.com/secure', {    agent: new https.Agent(httpsOptions)  });};

Operasyonel Yük: Sertifika yönetimi, rotation, revocation list'leri Modern Alternatif: Otomatik mTLS ile service mesh (Istio, Linkerd)

Maliyet Analizi & ROI#

Implementation Maliyetleri#

Operasyonel Maliyetler#

Yıllık Maliyetler:

• MFA support ticket'ları: Başlangıçta helpdesk volume'inde %30 artış
• Şifre reset'leri: Incident başına $70 (passwordless ile %90 azalma)
• Sertifika yönetimi: 1000 sertifika başına 1 FTE
• Güvenlik audit compliance: Yıllık $100K-500K

Güvenlik ROI Metrikleri#

Risk Azaltma:

• MFA: Hesap ele geçirmede %99.9 azalma
• Zero Trust: Breach etkisinde %50 azalma
• SASE: Güvenlik tool karmaşıklığında %30 azalma
• Passkeys: Phishing başarı oranında %90 azalma

Finansal Faydalar:

• Ortalama data breach maliyeti: $4.88M (IBM 2024 Cost of a Data Breach Report)
• MFA implementation maliyeti: $20K-50K
• ROI break-even: İlk önlenen incident

Takip Edilecek Metrikler#

Authentication Metrikleri#

• Failed authentication oranı (hedef: <%2)
• MFA benimsenme yüzdesi (admin hesaplar için hedef: %100)
• Ortalama authentication süresi (hedef: <3 saniye)
• Şifre reset frekansı (passwordless ile azalt)
• Token refresh oranı ve hataları

Güvenlik Metrikleri#

• Güvenlik incident'ları için Mean Time to Detect (MTTD)
• Tehditlere Mean Time to Respond (MTTR)
• Privilege escalation denemeleri
• Olağandışı authentication pattern'ları (coğrafi, zaman tabanlı)
• Cross-origin authentication hataları

Kullanıcı Deneyimi Metrikleri#

• Login başarı oranı (hedef: >%99)
• Authentication abandonment oranı (hedef: <%1)
• Support ticket volume'ü
• Session süre pattern'ları
• Biometric authentication hata oranı

Yaygın Pitfall'lar & Implementation Dersleri#

Authentication Pitfall'ları#

• OAuth2 Karışıklığı: Authentication için OAuth2'yi OIDC olmadan kullanmak (orada bulundum, pahalı hata)
• Şifre Storage: Plaintext veya zayıf hash'lenmiş şifreler saklamak (Argon2id kullan)
• Token Ömürleri: Rotation olmadan uzun ömürlü token'lar (30 günlük JWT kabusum)
• SMS OTP Bağımlılığı: 2025'te SMS'i tek ikinci faktör olarak kullanmak (SIM swapping gerçek)
• Account Lockout: Eksik veya yetersiz lockout policy'leri

Implementation Pitfall'ları#

• Tek Hata Noktası: Fallback authentication metodunun olmaması
• Session Yönetimi: Zayıf session handling ve timeout policy'leri
• Rate Limiting: Authentication endpoint'lerinde eksik rate limiting
• Bilgi Disclosure: User enumeration'a olanak sağlayan error mesajları
• Synchronous Validation: Performansı etkileyen blocking token validation

Operasyonel Pitfall'lar#

• Token Revocation: Compromise edilmiş token'ları revoke etme mekanizmasının olmaması
• Audit Boşlukları: Kapsamlı authentication logging'in eksikliği
• Key Rotation: Fail olan manuel key rotation süreçleri
• Sertifika Süresi: Otomatik sertifika yenileme yok (sabah 3'te sayfalama)
• Manuel Provisioning: Otomatik kullanıcı yaşam döngüsü yönetiminin eksikliği

Implementation Başarı Hikayeleri#

Finansal Hizmetler Dönüşümü#

"50.000 kullanıcıyı 18 ayda username/password'dan FIDO2 passkey'lere migrate ettik. Phishing incident'ları sıfıra düştü - implementation sonrası 12 ayda tam anlamıyla sıfır başarılı saldırı. Support ticket'lar %60 azaldı. CFO $800K yatırımdan şüpheliydi, ilk büyük incident'ı önleyene kadar. 8 ayda ROI pozitif."

Healthcare SAML Federation#

"15 hastane sistemini SAML federation kullanarak entegre ettik. Single sign-on, ortalama klinisyen login süresini 2 dakikadan 10 saniyeye düşürdü. Bunu vardiya başına birden çok kez giriş yapan 10.000 klinisyenle çarptığında, günlük 500 saat tasarruf ettik. IT sistemleriyle klinisyen memnuniyeti %40 arttı."

Perakende Zero Trust Yolculuğu#

"18 aylık Zero Trust implementation'ımız sadece güvenlik hakkında değildi - erişim hakkında düşünme şeklimizi dönüştürdü. Forensics analizimize göre bize $10M+ malolacak 3 potansiyel breach'i önledik. Asıl kazanç? 15 nokta çözümü konsolide ederek güvenlik tool maliyetlerimizi yıllık$2M azalttık. Compliance score'larımızı %35 geliştirdik."

Farklı Ne Yapardım#

Teknik Kararlar#

• OIDC ile Başla: SAML'i sadece enterprise müşteriler özellikle gerektirdiğinde ekle
• Passkeys First: 2025'te herhangi bir yeni proje için FIDO2/WebAuthn'i ilk günden implement et
• Managed Services: Authentication sistemleri inşa etmek yerine Auth0, Okta veya AWS Cognito kullan
• Sertifika Otomasyonu: Otomatik sertifika yönetimini (Let's Encrypt, AWS ACM) hemen implement et
• Token Rotation: Refresh token rotation'ını başlangıçtan design et, sonradan ekleme olarak değil

Süreç Geliştirmeleri#

• Güvenlik Eğitimi İlk: İlk incident'tan sonra değil, implement etmeden önce ekibi eğit
• Incremental Rollout: Authentication metod rollout'ları için feature flag'leri kullan
• A/B Testing: Kullanıcı deneyimi etkisi için authentication flow'larını test et
• Friction Monitoring: Authentication friction'ını sürekli ölç ve optimize et
• Düzenli Tatbikatlar: Güvenlik incident response tatbikatlarını üç ayda bir gerçekleştir

Stratejik Seçimler#

• Satın Al vs İnşa Et: Authentication altyapısını her zaman satın al - güvenlik farklılaştırıcı değil
• Otomasyon Yatırımı: İlk günden güvenlik otomasyonuna yoğun yatırım yap
• Ölçek Planlama: Başlangıçtan 10x büyüme için design et
• Compliance Önden: Mimari kararlardan önce regülatif gereksinimleri (SOX, HIPAA, GDPR) düşün
• Kültür İnşa Etme: Teknik implementation'ın yanında güvenlik kültürüne odaklan

Ana Çıkarımlar#

Geliştirici İçin#

1. Asla şifre saklama - Doğru hashing kullan (salt ile Argon2id)
2. Token'ları kısa ömürlü tut - JWT access token'lar için maksimum 15 dakika
3. Her zaman server-side validate et - Client-side validation'a güvenme
4. Rate limiting implement et - Tüm authentication endpoint'lerinde
5. Her şeyi logla - Authentication event'leri audit ve forensics için kritik

Mimar İçin#

1. Zero Trust için design et - İlk günden breach varsay
2. Birden çok auth metodunu planla - Kullanıcıların fallback seçeneklere ihtiyacı var
3. Concern'leri ayır - Authentication ≠ authorization
4. Token rotation kabiliyeti inşa et - Eninde sonunda ihtiyacın olacak
5. Federation'ı erken düşün - Enterprise müşteriler talep edecek

Güvenlik Ekipleri İçin#

1. MFA pazarlık götürmez - 2025'te mazeret yok
2. SMS OTP'yi deprecated et - SIM swapping çok yaygın
3. Continuous auth implement et - Sadece login'de değil
4. Behavioral pattern'ları monitör et - Olağandışı aktivite detection
5. Düzenli assessment'lar - Minimum üç aylık güvenlik incelemeleri

Yönetim İçin#

1. Güvenlik bir yatırım - Maliyet merkezi değil
2. UX ve güvenlik bir arada var olabilir - Doğru yapıldığında güvenlik kullanıcı deneyimini geliştirir
3. Compliance minimum - Güvenlik hedefi değil
4. Incident response planlama - En iyisini umut et, en kötüsü için planla
5. Kültür tool'ları yener - En iyi güvenlik teknolojisi iyi güvenlik kültürü olmadan başarısız olur

Unutma: En güvenli sistem, kullanıcılar kullanamaz veya kullanmayacaksa işe yaramaz. Sanat, temel ilkeler üzerinde asla taviz vermezken güvenlik ve kullanılabilirlik arasındaki dengeyi bulmaktır. Bu sistemlerle çalışmak gösterdi ki en zor kısmı teknoloji değil - herkesin bu kavramların neden önemli olduğunu ve nasıl bir araya geldiklerini anlamasını sağlamak.

Bu sözlük saha rehberin olarak hizmet ediyor. Bookmark et, mimari tartışmalarda referans alarak kullan ve ekiplerini eğitmek için kullan. Bir dahaki sefere biri "authentication için OAuth2" önerdiğinde ya da "SMS OTP sorun değil" dediğinde, tam olarak ne söylemen gerektiğini ve neden bileceksin.