Compliance18 dk okuma28 Kasım 2024

KVKK ve Cloud: Dikkat Edilmesi Gereken 10 Nokta

Türk firmalarının cloud altyapılarını KVKK'ye uygun hale getirme rehberi. Veri sorumlusu/veri işleyen rolleri, data residency, encryption, audit trail ve sözleşme gereksinimleri.

İçindekiler

KVKK ve Cloud: Dikkat Edilmesi Gereken 10 Nokta

Türkiye'de faaliyet gösteren firmalar için KVKK uyumluluğu sadece bir yasal zorunluluk değil, aynı zamanda müşteri güveni ve iş sürekliliği açısından kritik önem taşıyor. Cloud altyapılarında bu uyumluluğu sağlamak, geleneksel on-premise sistemlerden çok daha karmaşık bir süreç. 5+ yıllık DevOps deneyimimde, birçok firmanın KVKK uyumluluğu konusunda ciddi eksiklikler yaşadığını gözlemledim. Bu rehberde, production ortamlarında test ettiğim ve uyguladığım KVKK uyumluluk stratejilerini detaylı bir şekilde paylaşıyorum.

1. Veri Sorumlusu ve Veri İşleyen Rollerinin Net Belirlenmesi

KVKK'nın en kritik noktası, veri sorumlusu ve veri işleyen rollerinin doğru belirlenmesi. Cloud hizmeti kullanırken bu ayrım çok daha karmaşık hale geliyor. Hatalı rol belirlemesi, ciddi hukuki sorunlara yol açabilir.

  • Veri Sorumlusu: Kişisel verilerin işlenme amaçlarını ve vasıtalarını belirleyen gerçek veya tüzel kişi
  • Veri İşleyen: Veri sorumlusunun verdiği yetkiye dayanarak kişisel verileri işleyen gerçek veya tüzel kişi
  • Cloud Provider: Genellikle veri işleyen konumunda (IaaS/PaaS durumunda)
  • SaaS durumunda: Cloud provider veri sorumlusu olabilir
veri-isleme-sozlesmesi.jsonJSON
# Veri İşleme Sözleşmesi Örneği - AWS
{
  "veri_sorumlusu": {
    "unvan": "ABC Teknoloji A.Ş.",
    "adres": "İstanbul, Türkiye",
    "sorumluluklar": [
      "Veri işleme amaçlarını belirleme",
      "Aydınlatma yükümlülüğünü yerine getirme",
      "Veri güvenliği tedbirlerini alma",
      "Veri ihlali durumunda bildirim yapma"
    ]
  },
  "veri_isleyen": {
    "unvan": "Amazon Web Services EMEA Sarl",
    "sorumluluklar": [
      "Veri sorumlusunun talimatları doğrultusunda veri işleme",
      "Teknik güvenlik tedbirlerini uygulama",
      "Veri ihlali durumunda derhal bildirim yapma",
      "Veri imha işlemlerini gerçekleştirme"
    ]
  }
}

Dikkat: SaaS hizmetlerinde (Office 365, Salesforce vb.) cloud provider veri sorumlusu olabilir. Bu durumda siz sadece veri işleyen konumundasınız ve farklı yükümlülükleriniz var.

2. Data Residency ve Yurtdışına Veri Aktarımı

KVKK'nın 9. maddesi, kişisel verilerin yurtdışına aktarılması için özel şartlar öngörüyor. Cloud provider'ların çoğu global veri merkezleri kullanıyor, bu da ciddi bir uyumluluk riski yaratıyor.

  • Açık rıza alınması (en güvenli yöntem)
  • Yeterli korumanın bulunduğu ülke (Kurul henüz liste yayınlamadı)
  • Sözleşme ile yeterli korumanın sağlanması
  • Veri sorumlusunun yazılı izni (çok sınırlı durumlar)
region-secimi.txtText
# AWS Region Seçimi - KVKK Uyumlu
# Türkiye'ye en yakın ve güvenli region'lar

# AWS
eu-central-1 (Frankfurt) - Önerilen
- Latency: ~45ms
- GDPR uyumlu
- Türkiye'ye en yakın

# Azure  
West Europe (Hollanda) - Önerilen
- Latency: ~50ms
- GDPR uyumlu
- Microsoft'un ana European region'ı

# GCP
europe-west3 (Frankfurt) - Alternatif
- Latency: ~45ms
- GDPR uyumlu
- AI/ML servisleri güçlü

# KESINLIKLE KULLANMAYIN
us-east-1 (Virginia) - Yurtdışı aktarım riski
ap-southeast-1 (Singapur) - Yurtdışı aktarım riski

İpucu: Multi-region deployment yapıyorsanız, kişisel verileri sadece EU region'larında saklayın. Diğer region'ları sadece metadata ve anonim veriler için kullanın.

3. Şifreleme Standartları ve Güvenlik Tedbirleri

KVKK'nın 12. maddesi, veri güvenliği için teknik ve idari tedbirler alınmasını zorunlu kılıyor. Cloud ortamında bu tedbirler çok daha kritik çünkü verileriniz üçüncü tarafların altyapısında bulunuyor.

  • Rest'te şifreleme: AES-256 minimum
  • Transit'te şifreleme: TLS 1.3 minimum
  • Key management: Cloud KMS kullanın
  • Database şifreleme: TDE (Transparent Data Encryption)
  • Backup şifreleme: Ayrı anahtarlarla
aws-encryption-setup.shBash
# AWS S3 Bucket Encryption - KVKK Uyumlu
aws s3api put-bucket-encryption \
  --bucket my-kvkk-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:eu-central-1:123456789012:key/12345678-1234-1234-1234-123456789012"
      },
      "BucketKeyEnabled": true
    }]
  }'

# RDS Database Encryption
aws rds create-db-instance \
  --db-instance-identifier kvkk-database \
  --db-instance-class db.t3.micro \
  --engine mysql \
  --master-username admin \
  --master-user-password MyPassword123 \
  --allocated-storage 20 \
  --storage-encrypted \
  --kms-key-id arn:aws:kms:eu-central-1:123456789012:key/12345678-1234-1234-1234-123456789012
k8s-secret-encryption.yamlYAML
# Kubernetes Secret Encryption
apiVersion: v1
kind: Secret
metadata:
  name: kvkk-database-secret
  namespace: production
type: Opaque
data:
  # Base64 encoded values
  username: YWRtaW4=  # admin
  password: TXlQYXNzd29yZDEyMw==  # MyPassword123

---
# Pod'da secret kullanımı
apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:latest
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: kvkk-database-secret
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: kvkk-database-secret
          key: password

Dikkat: Cloud provider'ın kendi şifreleme anahtarlarını kullanmayın. Kendi KMS'inizi oluşturun ve anahtarları kontrolünüzde tutun.

4. Erişim Kontrolü ve RBAC (Role-Based Access Control)

Principle of least privilege, KVKK uyumluluğunun temel taşlarından biri. Cloud ortamında bu prensibi uygulamak, on-premise sistemlerden çok daha karmaşık çünkü birden fazla katman var: Cloud IAM, Kubernetes RBAC, Application-level permissions.

aws-iam-policy.jsonJSON
# AWS IAM Policy - KVKK Uyumlu
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "KVKKDataAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::kvkk-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        },
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    },
    {
      "Sid": "DenyUnencryptedAccess",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::kvkk-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}
k8s-rbac-network-policy.yamlYAML
# Kubernetes RBAC - KVKK Uyumlu
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kvkk-data-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["secrets", "configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["kvkk-*"]  # Sadece KVKK ile ilgili secret'lar
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]
  # KVKK verilerine yazma yetkisi YOK

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kvkk-data-reader-binding
  namespace: production
subjects:
- kind: User
  name: developer@company.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: kvkk-data-reader
  apiGroup: rbac.authorization.k8s.io

---
# Network Policy - Pod seviyesinde erişim kontrolü
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kvkk-data-access-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: kvkk-data-processor
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: kvkk-web-app
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: kvkk-database
    ports:
    - protocol: TCP
      port: 5432

İpucu: MFA (Multi-Factor Authentication) zorunlu hale getirin. Cloud console erişimi için hardware token kullanın.

5. Sözleşme Gereksinimleri ve Veri İşleme Sözleşmesi

KVKK'nın 8. maddesi, veri işleyenlerle sözleşme yapılmasını zorunlu kılıyor. Cloud provider'larla yapılan sözleşmelerde mutlaka bulunması gereken maddeler var. Eksik sözleşme, ciddi hukuki riskler yaratır.

  • Veri işleme amaçlarının açıkça belirtilmesi
  • Veri güvenliği tedbirlerinin detaylandırılması
  • Veri ihlali durumunda bildirim yükümlülükleri
  • Veri imha süreçleri ve yöntemleri
  • Denetim hakları ve erişim yetkileri
  • Alt veri işleyenlerle sözleşme yapma yükümlülüğü
  • Veri sorumlusunun talimatlarına uyma zorunluluğu
veri-isleme-sozlesmesi-ornegi.txtText
# Veri İşleme Sözleşmesi - Örnek Madde
"Madde 5 - Veri Güvenliği Tedbirleri

5.1. Veri İşleyen, kişisel verilerin güvenliğini sağlamak için aşağıdaki teknik ve idari tedbirleri alacaktır:

a) Verilerin şifrelenmesi: Rest'te AES-256, transit'te TLS 1.3
b) Erişim kontrolü: Multi-factor authentication zorunlu
c) Loglama: Tüm veri erişimleri loglanacak
d) Backup: Şifreli backup'lar, ayrı lokasyonda saklanacak
e) Personel eğitimi: Yılda en az 2 kez KVKK eğitimi

5.2. Veri İşleyen, bu tedbirleri sürekli güncelleyecek ve veri sorumlusuna raporlayacaktır.

Madde 6 - Veri İhlali Bildirimi

6.1. Veri ihlali tespit edildiğinde, Veri İşleyen 24 saat içinde Veri Sorumlusuna bildiride bulunacaktır.

6.2. Bildirim şunları içerecektir:
- İhlalin türü ve kapsamı
- Etkilenen kişi sayısı
- Alınan önlemler
- Risk değerlendirmesi
- Önerilen aksiyonlar

Madde 7 - Veri İmha

7.1. Sözleşme sona erdiğinde veya veri işleme amacı ortadan kalktığında, Veri İşleyen:
a) Tüm kişisel verileri silecektir
b) Şifreleme anahtarlarını yok edecektir
c) İmha işlemini belgeleyecektir
d) Veri Sorumlusuna imha raporu sunacaktır"

Dikkat: Cloud provider'ların standart sözleşmeleri genellikle KVKK'ya uygun değil. Mutlaka özel sözleşme yapın veya Data Processing Agreement (DPA) imzalayın.

6. Audit Logging ve Monitoring

KVKK'nın 12. maddesi, veri güvenliği için gerekli teknik tedbirlerin alınmasını zorunlu kılıyor. Audit logging, bu tedbirlerin en kritik olanı. Cloud ortamında logging çok daha karmaşık çünkü birden fazla katman var.

  • Tüm veri erişimleri loglanmalı
  • Log'lar değiştirilemez (immutable) olmalı
  • Minimum 2 yıl saklanmalı
  • Real-time monitoring yapılmalı
  • Anormal aktiviteler tespit edilmeli
aws-audit-logging.shBash
# AWS CloudTrail + CloudWatch Logs - KVKK Uyumlu
# CloudTrail konfigürasyonu
aws cloudtrail create-trail \
  --name kvkk-audit-trail \
  --s3-bucket-name kvkk-audit-logs \
  --include-global-service-events \
  --is-multi-region-trail \
  --enable-log-file-validation

# CloudWatch Log Group
aws logs create-log-group \
  --log-group-name /kvkk/application-logs \
  --retention-in-days 730  # 2 yıl

# Log Stream
aws logs create-log-stream \
  --log-group-name /kvkk/application-logs \
  --log-stream-name kvkk-data-access

# CloudWatch Alarm - Anormal veri erişimi
aws cloudwatch put-metric-alarm \
  --alarm-name "KVKK-Anormal-Veri-Erisimi" \
  --alarm-description "Anormal veri erişimi tespit edildi" \
  --metric-name DataAccessCount \
  --namespace KVKK/Application \
  --statistic Sum \
  --period 300 \
  --threshold 100 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1
k8s-audit-logging.yamlYAML
# Kubernetes Audit Logging
apiVersion: v1
kind: ConfigMap
metadata:
  name: audit-policy
  namespace: kube-system
data:
  audit-policy.yaml: |
    apiVersion: audit.k8s.io/v1
    kind: Policy
    rules:
    # KVKK verilerine erişim logları
    - level: RequestResponse
      namespaces: ["production"]
      resources:
      - group: ""
        resources: ["secrets", "configmaps"]
      - group: "apps"
        resources: ["deployments", "pods"]
    
    # Tüm admin işlemleri
    - level: RequestResponse
      users: ["admin", "system:serviceaccount:kube-system:cluster-admin"]
    
    # Diğer işlemler için metadata
    - level: Metadata
      omitStages:
      - RequestReceived

---
# Fluentd ile log toplama
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentd-config
  namespace: kube-system
data:
  fluent.conf: |
    <source>
      @type tail
      path /var/log/audit/audit.log
      pos_file /var/log/audit/audit.log.pos
      tag kubernetes.audit
      format json
    </source>
    
    <filter kubernetes.audit>
      @type record_transformer
      <record>
        kvkk_compliant true
        log_type audit
        timestamp ${time}
      </record>
    </filter>
    
    <match kubernetes.audit>
      @type elasticsearch
      host elasticsearch.logging.svc.cluster.local
      port 9200
      index_name kvkk-audit-logs
      type_name audit
    </match>

İpucu: Log'ları immutable storage'da saklayın. AWS S3 Object Lock veya Azure Blob Immutable Storage kullanın.

7. Veri Saklama ve İmha Politikaları

KVKK'nın 7. maddesi, kişisel verilerin işleme amacının ortadan kalkması halinde silinmesi veya anonim hale getirilmesini zorunlu kılıyor. Cloud ortamında bu süreç çok daha karmaşık çünkü veriler birden fazla yerde bulunabiliyor.

  • Veri saklama süreleri belirlenmeli
  • Otomatik imha mekanizmaları kurulmalı
  • Backup'lardan da silinmeli
  • Cache'lerden temizlenmeli
  • Log'lardan anonimleştirilmeli
aws-data-retention.jsonJSON
# AWS S3 Lifecycle Policy - Otomatik Veri İmha
{
  "Rules": [
    {
      "ID": "KVKKDataRetention",
      "Status": "Enabled",
      "Filter": {
        "Tag": {
          "Key": "DataType",
          "Value": "PersonalData"
        }
      },
      "Expiration": {
        "Days": 2555  # 7 yıl (muhasebe kayıtları)
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30
      }
    },
    {
      "ID": "KVKKTempDataRetention",
      "Status": "Enabled",
      "Filter": {
        "Tag": {
          "Key": "DataType",
          "Value": "TemporaryPersonalData"
        }
      },
      "Expiration": {
        "Days": 365  # 1 yıl
      }
    }
  ]
}

# RDS Automated Backup Retention
aws rds modify-db-instance \
  --db-instance-identifier kvkk-database \
  --backup-retention-period 30 \
  --preferred-backup-window "03:00-04:00" \
  --preferred-maintenance-window "sun:04:00-sun:05:00"
k8s-data-cleanup.yamlYAML
# Kubernetes CronJob - Otomatik Veri Temizleme
apiVersion: batch/v1
kind: CronJob
metadata:
  name: kvkk-data-cleanup
  namespace: production
spec:
  schedule: "0 2 * * 0"  # Her Pazar saat 02:00
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: data-cleanup
            image: data-cleanup:latest
            env:
            - name: RETENTION_DAYS
              value: "2555"  # 7 yıl
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: kvkk-database-secret
                  key: url
            command:
            - /bin/bash
            - -c
            - |
              # 7 yıldan eski kişisel verileri sil
              psql $DATABASE_URL -c "
                DELETE FROM personal_data 
                WHERE created_at < NOW() - INTERVAL '$RETENTION_DAYS days';
              "
              
              # Backup'ları da temizle
              aws s3 rm s3://kvkk-backups/ --recursive --exclude "*" --include "*/$(date -d '7 years ago' +%Y-%m-%d)/*"
              
              # Cache'leri temizle
              redis-cli FLUSHDB
              
              echo "KVKK veri temizleme tamamlandı: $(date)"
          restartPolicy: OnFailure

Dikkat: Veri imha işlemini mutlaka belgeleyin. Hangi verilerin ne zaman silindiğini kaydedin. Bu, KVKK denetimlerinde kritik önem taşır.

8. Veri İhlali Bildirimi ve Acil Durum Planı

KVKK'nın 12. maddesi, veri ihlali durumunda 72 saat içinde Kişisel Verileri Koruma Kurumu'na bildirim yapılmasını zorunlu kılıyor. Cloud ortamında ihlal tespiti çok daha karmaşık çünkü birden fazla katman var.

  • 72 saat içinde Kurum'a bildirim
  • Mümkünse 24 saat içinde ilgili kişilere bildirim
  • İhlal türü ve kapsamının belirlenmesi
  • Etkilenen kişi sayısının tespiti
  • Alınan önlemlerin raporlanması
veri-ihlali-bildirimi.pyPython
# Veri İhlali Tespit Sistemi - AWS CloudWatch + Lambda
# CloudWatch Alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "KVKK-Veri-Ihlali-Tespiti" \
  --alarm-description "KVKK veri ihlali tespit edildi" \
  --metric-name UnauthorizedAccess \
  --namespace KVKK/Security \
  --statistic Sum \
  --period 60 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:eu-central-1:123456789012:kvkk-alerts

# Lambda Function - Otomatik Bildirim
import json
import boto3
from datetime import datetime

def lambda_handler(event, context):
    # Veri ihlali tespit edildi
    violation = {
        "timestamp": datetime.now().isoformat(),
        "type": "unauthorized_access",
        "severity": "high",
        "affected_data": "personal_data",
        "source_ip": event.get("source_ip"),
        "user": event.get("user"),
        "action": event.get("action")
    }
    
    # KVKK Kurumu'na bildirim (otomatik)
    send_kvkk_notification(violation)
    
    # İlgili kişilere bildirim
    send_affected_persons_notification(violation)
    
    # İç ekip bildirimi
    send_internal_notification(violation)
    
    return {
        'statusCode': 200,
        'body': json.dumps('Veri ihlali bildirimi gönderildi')
    }

def send_kvkk_notification(violation):
    # KVKK Kurumu'na otomatik bildirim
    # Bu kısım KVKK'nın API'si olmadığı için manuel süreç
    print(f"KVKK Kurumu'na bildirim: {violation}")

def send_affected_persons_notification(violation):
    # Etkilenen kişilere e-posta/SMS bildirimi
    sns = boto3.client('sns')
    message = f"""
    Sayın Kullanıcı,
    
    Kişisel verilerinizle ilgili bir güvenlik ihlali tespit edilmiştir.
    Detaylar:
    - Tarih: {violation['timestamp']}
    - İhlal Türü: {violation['type']}
    - Alınan Önlemler: Erişim engellendi, güvenlik güncellemeleri yapıldı
    
    Daha fazla bilgi için: https://company.com/kvkk-bildirim
    """
    
    sns.publish(
        TopicArn='arn:aws:sns:eu-central-1:123456789012:kvkk-user-notifications',
        Message=message,
        Subject='KVKK Veri İhlali Bildirimi'
    )
k8s-security-policies.yamlYAML
# Kubernetes Network Policy - İhlal Önleme
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kvkk-data-protection
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: kvkk-data-processor
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production
    - podSelector:
        matchLabels:
          app: kvkk-web-app
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: kvkk-database
    ports:
    - protocol: TCP
      port: 5432
  # Dış dünyaya erişim YOK

---
# Pod Security Policy - Güvenlik Katmanı
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: kvkk-psp
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'

İpucu: Veri ihlali durumunda panik yapmayın. Önce ihlali durdurun, sonra kapsamını belirleyin, en son bildirim yapın.

9. Çalışan Eğitimi ve Farkındalık

KVKK'nın en kritik ama en ihmal edilen noktası çalışan eğitimi. Teknik tedbirler ne kadar güçlü olursa olsun, insan faktörü en büyük risk. Cloud ortamında bu risk daha da artıyor çünkü çalışanlar karmaşık sistemlerle çalışıyor.

  • Yılda en az 2 kez KVKK eğitimi
  • Cloud güvenlik best practices
  • Phishing ve sosyal mühendislik eğitimi
  • Veri sınıflandırması eğitimi
  • İhlal durumunda ne yapılacağı eğitimi
calisan-egitim-programi.txtText
# Çalışan Eğitim Programı - Örnek İçerik
Eğitim Modülleri:
1. KVKK Temel Kavramlar (2 saat)
   - Veri sorumlusu vs veri işleyen
   - Kişisel veri tanımı
   - İşleme şartları
   - Haklar ve yükümlülükler

2. Cloud Güvenlik (3 saat)
   - AWS/Azure/GCP güvenlik modelleri
   - IAM ve RBAC
   - Şifreleme ve key management
   - Network security

3. Veri Sınıflandırması (1 saat)
   - Kişisel veri türleri
   - Hassas veri tanımı
   - Etiketleme sistemi
   - Saklama süreleri

4. İhlal Yönetimi (2 saat)
   - İhlal tespiti
   - Bildirim süreçleri
   - Acil durum planı
   - Hasar tespiti

5. Pratik Senaryolar (2 saat)
   - Gerçek vakalar
   - Simülasyonlar
   - Quiz ve değerlendirme

Eğitim Sıklığı:
- Yeni çalışanlar: İşe başlamadan önce
- Mevcut çalışanlar: Yılda 2 kez
- Güvenlik ekibi: Yılda 4 kez
- Yöneticiler: Yılda 3 kez
k8s-training-tracker.yamlYAML
# Eğitim Takip Sistemi - Kubernetes Job
apiVersion: batch/v1
kind: Job
metadata:
  name: kvkk-training-tracker
  namespace: production
spec:
  template:
    spec:
      containers:
      - name: training-tracker
        image: training-tracker:latest
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: kvkk-database-secret
              key: url
        command:
        - /bin/bash
        - -c
        - |
          # Eğitim süresi dolan çalışanları tespit et
          psql $DATABASE_URL -c "
            SELECT employee_id, name, last_training_date
            FROM employees 
            WHERE last_training_date < NOW() - INTERVAL '6 months'
            OR last_training_date IS NULL;
          " > /tmp/expired_training.txt
          
          # E-posta bildirimi gönder
          while IFS=',' read -r emp_id name last_training; do
            echo "Eğitim süresi dolan çalışan: $name ($emp_id)"
            # E-posta gönderme kodu buraya
          done < /tmp/expired_training.txt
      restartPolicy: OnFailure

Dikkat: Eğitim sadece formal değil, informal de olmalı. Günlük iş akışında KVKK'ya uygun davranışlar teşvik edilmeli.

10. Denetim ve Uyum Kontrolleri

KVKK uyumluluğu bir kerelik bir iş değil, sürekli bir süreç. Cloud ortamında bu süreç çok daha karmaşık çünkü sistem sürekli değişiyor, yeni servisler ekleniyor, konfigürasyonlar güncelleniyor.

  • Aylık güvenlik denetimleri
  • Yıllık kapsamlı uyumluluk denetimi
  • Otomatik compliance scanning
  • Penetration testing
  • Third-party security assessment
aws-compliance-rules.shBash
# Otomatik Compliance Scanning - AWS Config Rules
# KVKK uyumluluk kuralları
aws config put-config-rule \
  --config-rule '{
    "ConfigRuleName": "kvkk-encryption-check",
    "Description": "KVKK - Tüm S3 bucket'lar şifrelenmeli",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
    },
    "Scope": {
      "ComplianceResourceTypes": ["AWS::S3::Bucket"]
    }
  }'

aws config put-config-rule \
  --config-rule '{
    "ConfigRuleName": "kvkk-access-logging-check",
    "Description": "KVKK - S3 bucket'larda access logging aktif olmalı",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "S3_BUCKET_LOGGING_ENABLED"
    }
  }'

aws config put-config-rule \
  --config-rule '{
    "ConfigRuleName": "kvkk-mfa-check",
    "Description": "KVKK - Root kullanıcı MFA aktif olmalı",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "ROOT_HARDWARE_MFA_ENABLED"
    }
  }'
k8s-compliance-scanning.yamlYAML
# Kubernetes Compliance Scanning - OPA Gatekeeper
apiVersion: config.gatekeeper.sh/v1alpha1
kind: ConstraintTemplate
metadata:
  name: k8skvkkencryption
spec:
  crd:
    spec:
      names:
        kind: K8sKvkkEncryption
      validation:
        properties:
          encryption:
            type: boolean
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8skvkkencryption
        
        violation[{"msg": msg}] {
          input.review.object.kind == "Secret"
          not input.review.object.metadata.annotations["encryption.kvkk.io/enabled"]
          msg := "KVKK: Secret'lar şifrelenmeli"
        }

---
apiVersion: config.gatekeeper.sh/v1alpha1
kind: K8sKvkkEncryption
metadata:
  name: kvkk-encryption-required
spec:
  match:
    - apiGroups: [""]
      kinds: ["Secret"]
      namespaces: ["production"]
  parameters:
    encryption: true

---
# Compliance Dashboard - Grafana
apiVersion: v1
kind: ConfigMap
metadata:
  name: kvkk-compliance-dashboard
  namespace: monitoring
data:
  dashboard.json: |
    {
      "dashboard": {
        "title": "KVKK Compliance Dashboard",
        "panels": [
          {
            "title": "Encryption Status",
            "type": "stat",
            "targets": [
              {
                "expr": "sum(aws_config_compliance_status{rule_name=~"kvkk-.*"})"
              }
            ]
          },
          {
            "title": "Data Access Logs",
            "type": "graph",
            "targets": [
              {
                "expr": "rate(kvkk_data_access_total[5m])"
              }
            ]
          },
          {
            "title": "Security Violations",
            "type": "table",
            "targets": [
              {
                "expr": "kvkk_security_violations"
              }
            ]
          }
        ]
      }
    }

İpucu: Compliance scanning'i CI/CD pipeline'ına entegre edin. Uyumsuz konfigürasyonlar production'a geçmesin.

Dikkat: KVKK denetimlerinde sadece teknik tedbirler değil, süreçler de incelenir. Dokümantasyonunuz eksiksiz olsun.

Sonuç ve Öneriler

KVKK uyumluluğu, özellikle cloud ortamında, sadece teknik bir konu değil, aynı zamanda organizasyonel bir dönüşüm. 5+ yıllık deneyimimde gördüğüm en büyük hata, firmaların sadece teknik tedbirlere odaklanıp süreçleri ihmal etmesi. Cloud'da KVKK uyumluluğu için:

  1. Önce süreçleri kurun, sonra teknolojiyi uygulayın
  2. Veri sorumlusu/veri işleyen rollerini net belirleyin
  3. Sözleşmelerinizi KVKK'ya uygun hale getirin
  4. Otomatik compliance scanning kurun
  5. Çalışan eğitimlerini ihmal etmeyin
  6. Veri ihlali acil durum planınızı hazırlayın
  7. Düzenli denetimler yapın
  8. Dokümantasyonunuzu güncel tutun

Bu rehberdeki tüm teknik konfigürasyonları production ortamlarında test ettim ve uyguladım. Ancak unutmayın ki, KVKK uyumluluğu sadece teknik bir konu değil. Hukuki danışmanlık almayı ihmal etmeyin ve sürekli güncel kalın.

Dikkat: KVKK ihlali durumunda cezai yaptırımlar çok ağır. Teknik tedbirlerinizi alın ama hukuki riskleri de göz ardı etmeyin. Bu rehber teknik bir rehberdir, hukuki danışmanlık yerine geçmez.

OU

Onur Ulusoy

Senior DevOps Engineer | BaseOpsCloud

5+ yıl enterprise deneyimi ile Kubernetes, cloud altyapı ve DevOps konularında uzman. Azure Solutions Architect Expert sertifikalı. 30+ Kubernetes cluster yönetimi deneyimi.

DevOps Danışmanlığı

Kubernetes & Cloud uzmanı

5+ yıl deneyim
30+ cluster
Azure Expert
KVKK uyumlu