En iyi güvenlik yöntemleri: AgentID için Microsoft Entra SDK'sını sağlamlaştırma

Bu kılavuz, üretim ortamlarında Aracı Kimliği için Microsoft Entra SDK'sını güvenli bir şekilde dağıtmak ve çalıştırmak için kapsamlı güvenlik yapılandırması ve sağlamlaştırma en iyi yöntemlerini sağlar. SDK dağıtımınızın en iyi güvenlik yöntemlerine uygun olduğundan emin olmak için ağ yalıtımı, kimlik bilgisi yönetimi, belirteç doğrulaması, çalışma zamanı güvenliği ve izleme gibi temel güvenlik denetimlerini kapsar.

Dikkat

Microsoft Entra SDK, Aracı Kimliği API’si için asla genel olarak erişilebilir olmamalıdır. Yalnızca aynı güven sınırındaki uygulamalar (örneğin, aynı pod, aynı sanal ağ) tarafından erişilebilir olmalıdır. Varsayılan olarak izin verilen konaklar localhost olarak belirlenmiştir. Bu API'nin genel kullanıma açık olması, kritik bir güvenlik riski olan yetkisiz belirteç alımını etkinleştirebilir. Ayrıca, aynı güven sınırındaki tüm uygulamaların bu API'ye erişimi olacağını unutmayın. Bu sınırdaki her uygulamanın güvenilir ve düzgün bir şekilde güvenli olduğundan emin olun.

SDK'nın çalıştırılması güvenli mi?

Aracı Kimliği için Microsoft Entra SDK'sı güvenlik göz önünde bulundurularak tasarlanmıştır, ancak güvenliği uygun yapılandırma ve dağıtım uygulamalarına bağlıdır. Güvenli bir dağıtım sağlamak için şu en iyi yöntemleri izleyin:

Yalnızca kapsayıcılı ortamlarda çalıştırın
Yalnızca localhost/pod-internal erişimini kısıtlama
Kubernetes Ağ İlkelerini kullanma
Kimlik bilgilerini güvenli bir şekilde depolama (Key Vault, Gizliler)
Kök olmayan kullanıcı olarak çalıştır
Denetim günlüğünü etkinleştirme

Ağ güvenliği

Ağ yalıtımı, kimlik doğrulama işlemlerini korumak için kritik öneme sahiptir. Aracı Kimliği için Microsoft Entra SDK'sı, katı erişim denetimleri ve kapsamlı trafik filtrelemesi ile güvenilen sınırlar içinde çalıştırılmalıdır. Buna yalnızca yerel konak bağlaması, pod iç iletişimi ve kimlik doğrulama uç noktalarına yetkisiz erişimi engelleyen ağ ilkeleri dahildir.

SDK erişimini kısıtlama

Kestrel'i yalnızca localhost üzerinde dinleyecek şekilde yapılandırarak kimlik doğrulama uç noktalarına dış ağ erişimini engelleyin:

containers:
- name: sidecar
  image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
  env:
  - name: Kestrel__Endpoints__Http__Url
    value: "http://127.0.0.1:5000"

Alternatif olarak, erişimi kısıtlamak için Kestrel'in konak filtrelemesini AllowedHosts ile kullanın:

containers:
- name: sidecar
  image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
  env:
  - name: AllowedHosts
    value: "localhost;127.0.0.1"

Yerel pod iletişimini kullanma

Trafiğin aynı pod içinde kaldığından ve ağdan geçmediğinden emin olmak için uygulamanızı localhost aracılığıyla Aracı Kimliği için Microsoft Entra SDK'sı ile iletişim kuracak şekilde yapılandırın:

containers:
- name: app
  env:
  - name: SIDECAR_URL
    value: "http://localhost:5000" # Pod-local communication only

LoadBalancer veya Ingress aracılığıyla asla erişime açma (bu, güvenlik sınırının dışından yetkisiz belirteç alımına izin verir):

# WRONG - exposes Microsoft Entra SDK for Agent ID publicly
apiVersion: v1
kind: Service
metadata:
  name: sidecar-service
spec:
  type: LoadBalancer # Exposes SDK publicly - INSECURE
  selector:
    app: myapp
  ports:
  - port: 5000

Kimlik bilgileri yönetimi

Güvenli kimlik bilgisi yönetimi, SDK güvenliği için temeldir. Gizli verileri ortadan kaldırmak için mümkün olduğunca yönetilen kimlikleri kullanın ve kimlik doğrulama bilgilerini yapılandırırken en az ayrıcalık ilkesini uygulayın.

Kapsayıcılar için İş Yükü Kimliğini Tercih Et

Kapsayıcılı dağıtımlar (AKS) için Microsoft Entra İş Yükü Kimliği kullanarak gizli verileri tamamen ortadan kaldırın ve dosya tabanlı belirteç projeksiyonu ile güvenli kimlik bilgileri yönetimini sağlayın.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myapp-sa
  annotations:
    azure.workload.identity/client-id: "<managed-identity-client-id>"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: myapp-sa
      containers:
      - name: sidecar
        image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
        env:
        - name: AzureAd__ClientId
          value: "<web-api-client-id>"
        
        # Workload Identity credentials - uses file-based token projection
        - name: AzureAd__ClientCredentials__0__SourceType
          value: "SignedAssertionFilePath"

Benefits: İş yükü kimliği, gizli anahtarları depolama veya döndürme gereksinimini ortadan kaldırırken otomatik kimlik bilgisi yönetimi, Azure RBAC tümleştirmesi ve tam bir denetim izi sağlar. Belirteç, iş yükü kimliği web kancası tarafından pod'a otomatik olarak yansıtılır ve SDK bunu kimlik bilgisi türünü kullanarak SignedAssertionFilePath okur. Bu yaklaşım, geleneksel gizli dizi tabanlı kimlik doğrulamasına kıyasla güvenlik risklerini ve operasyonel ek yükü önemli ölçüde azaltır.

Note: Azure VM'ler ve Uygulama Hizmetleri (kapsayıcısız ortamlar) için bunun yerine SignedAssertionFromManagedIdentity kimlik bilgisi türüyle sistem veya kullanıcı tarafından atanan yönetilen kimlikleri kullanın. Daha fazla bilgi için bkz. Yönetilen Kimliği Kullanma.

Gizli bilgiler yerine sertifikalar kullanma

İstemci sırları önlenemediğinde kimlik doğrulaması için sertifikaları kullanmayı tercih edin. Sertifikalar, ortak anahtar şifrelemesi kullandığından ve ayıklaması veya kötüye kullanımı daha zor olduğundan istemci gizli dizilerinden daha güçlü güvenlik sağlar. Merkezi yönetim ve otomatik yenileme için sertifikaları Azure Key Vault depolayın:

- name: AzureAd__ClientCredentials__0__SourceType
  value: "KeyVault"
- name: AzureAd__ClientCredentials__0__KeyVaultUrl
  value: "https://your-keyvault.vault.azure.net"
- name: AzureAd__ClientCredentials__0__KeyVaultCertificateName
  value: "your-cert-name"

Benefits: Azure Key Vault otomatik döndürme, erişim ilkeleri ve kapsamlı denetim ile merkezi sertifika yönetimi sağlarken, sertifikaların kapsayıcı görüntülerine hiçbir zaman katıştırılmamasını sağlar. Daha fazla bilgi için bkz. Kimlik Doğrulaması için Sertifikaları Kullanma.

Gizli bilgileri güvenli bir şekilde saklayın

Kubernetes Gizli Dizileri, yönetilen kimlikler veya sertifikalar bir seçenek değilse istemci gizli dizilerini depolamak için uygundur, ancak gizli dizilerin bekleme sırasında şifrelendiğinden ve erişimin sıkı bir şekilde denetlendiğinden emin olun:

apiVersion: v1
kind: Secret
metadata:
  name: app-cert
type: Opaque
data:
  certificate.pfx: <base64-encoded-pfx>
  certificate.password: <base64-encoded-password>

---
containers:
- name: sidecar
  volumeMounts:
  - name: cert-volume
    mountPath: /certs
    readOnly: true
  env:
  - name: AzureAd__ClientCredentials__0__SourceType
    value: "Path"
  - name: AzureAd__ClientCredentials__0__CertificateDiskPath
    value: "/certs/certificate.pfx"
  - name: AzureAd__ClientCredentials__0__CertificatePassword
    valueFrom:
      secretKeyRef:
        name: app-cert
        key: certificate.password

volumes:
- name: cert-volume
  secret:
    secretName: app-cert
    items:
    - key: certificate.pfx
      path: certificate.pfx
    defaultMode: 0400  # Read-only for owner

İstemci gizli anahtarları (mümkünse kaçının)

İstemci sırlarının kullanılması gerekiyorsa, riski en aza indirmek için ek güvenlik önlemleri uygulayın. İstemci sırları, yönetilen kimlikler veya sertifikalara göre daha az güvenlidir, bu nedenle kısa son kullanma süreleri, beklemede şifreleme ile güvenli depolama, RBAC aracılığıyla kısıtlı erişim ve sık döngü programları gibi ek koruma gerektirir. Dağıtım bildirimlerinde görünür olan kapsayıcı görüntülerde veya ortam değişkenlerinde asla gizli bilgileri depolamayın.

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  client-secret: "<your-client-secret>"

---
containers:
- name: sidecar
  env:
  - name: AzureAd__ClientCredentials__0__SourceType
    value: "ClientSecret"
  - name: AzureAd__ClientCredentials__0__ClientSecret
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: client-secret

Dikkat

Gizli bilgileri hiçbir zaman kaynak denetimine işlemeyin. Dış gizli yönetimini (Azure Key Vault, Korumalı Gizliler vb.) kullanın.

Belirteç güvenliği

Belirteç güvenliği, SDK tarafından yalnızca geçerli, uygun kapsamlı belirteçlerin kabul edilmesini ve işlenmesini sağlar. Yetkisiz erişimi önlemek ve belirtecin kötüye kullanımını sınırlamak için belirteç doğrulama, kapsam gereksinimleri ve hedef kitle denetimleri uygulayın.

Kapsam doğrulamayı etkinleştirme

Gelen tokenlar için belirli kapsamlar gerektirir (boşlukla ayrılmış):

- name: AzureAd__Scopes
  value: "access_as_user"

Uygun hedef kitleyi ayarlama

Beklenen hedef kitleyi belirteç doğrulaması için yapılandırın:

- name: AzureAd__Audience
  value: "api://your-api-id"

Uyarı

Beklenen hedef kitle değeri, uygulama kaydınızın requestedAccessTokenVersion değerine bağlıdır:

Sürüm 2: {ClientId} değerini doğrudan kullanın
Sürüm 1 veya null: Uygulama Kimliği URI'sini kullanın (genellikle api://{ClientId} özelleştirmediğiniz sürece)

Kullanmadan önce belirteçleri doğrulama

Kullanıcı belirteçlerini kabul etmeden önce her zaman çağır /Validate :

GET /Validate
Authorization: Bearer <user-token>

Çalışma zamanı güvenliği

Çalışma zamanı güvenlik denetimleri SDK kapsayıcısını değişiklik, ayrıcalık yükseltme ve yetkisiz yetenek erişimine karşı korur. Saldırı yüzeyini azaltmak için kapsayıcıyı en düşük ayrıcalıklarla ve salt okunur dosya sistemleriyle çalışacak şekilde yapılandırın.

Salt-okunur kök dosya sistemi

Kapsayıcı dosya sisteminin değiştirilmesini engelle:

securityContext:
  readOnlyRootFilesystem: true

Pod güvenlik ilkesi

Güvenlik standartlarını zorunlu kılma:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: sidecar-psp
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
  - ALL
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'MustRunAs'
  fsGroup:
    rule: 'MustRunAs'
  readOnlyRootFilesystem: true

Kayıt ve izleme

Etkin loglama ve izleme, anomalileri algılamanıza, sorunları gidermenize ve uyumluluk için denetim izlerini korumanıza olanak tanır. Ortamınız için uygun günlük düzeylerini yapılandırın ve SDK'nın beklendiği gibi çalıştığından emin olmak için sistem durumu yoklamaları uygulayın.

Uygun günlük kaydını yapılandırın

Üretim ortamı:

- name: Logging__LogLevel__Default
  value: "Warning"
- name: Logging__LogLevel__Microsoft.Identity.Web
  value: "Information"

Geliştirme ortamı (ayrıntılı):

- name: Logging__LogLevel__Default
  value: "Debug"
- name: ASPNETCORE_ENVIRONMENT
  value: "Development"

Sağlık izlemeyi etkinleştirme

Canlılık ve hazır olma yoklamalarını yapılandırın:

livenessProbe:
  httpGet:
    path: /health
    port: 5000
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /health
    port: 5000
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3

En iyi yöntemler denetim listesi

SDK dağıtımınızın ağ, kimlik bilgileri, belirteçler, çalışma zamanı ve izleme boyutları genelinde önerilen tüm güvenlik uygulamalarını izlediğini güvence altına almak için bu kapsamlı denetim listesini kullanın.

Ağ:

[ ] SDK yalnızca localhost/127.0.0.1 üzerinde dinler
[ ] LoadBalancer veya Ingress aracılığıyla asla kullanıma sunulmaz
[ ] Ağ ilkeleri dış erişimi kısıtlar
[ ] Dış iletişim için HTTPS/TLS

Kimlik bilgi -leri:

[ ] ile kapsayıcılar için İş Yükü Kimliğini kullanma (AKS, Kubernetes, Docker) SignedAssertionFilePath
[ ] SignedAssertionFromManagedIdentity ile VM'ler/Uygulama Hizmetleri için Yönetilen Kimlik kullanın
[ ] Sertifikaları gizli anahtarlar yerine tercih edin
[ ] Güvenli yönetim sisteminde depolanan sırlar
[ ] Düzenli kimlik bilgisi yenileme

Belirteçler

[ ] Kapsam doğrulaması etkinleştirildi
[ ] İzleyici doğrulaması yapılandırıldı
[ ] Belirteçler kullanımdan önce doğrulandı

Çalışma zamanı:

[ ] Kapsayıcı root yetkisine sahip olmayan olarak çalışır
[ ] Salt okunur ana dizin dosya sistemi
[ ] Güvenlik bağlamı uygulandı
[ ] Kaynak sınırları ayarlandı

Izleme:

[ ] Uygun kayıt tutma yapılandırıldı
[ ] Sağlık kontrolleri etkin
[ ] Denetim günlüğü etkinleştirildi
[ ] Uyarılar yapılandırıldı

Ortak güvenlik desenleri

Başvuru uygulamaları, birden çok güvenlik denetiminin uyumlu dağıtım desenleri halinde nasıl birleştirildiği gösterir. Bu desenler, çeşitli tehdit modellerinde üretim dağıtımları için şablon görevi görür.

Yüksek Güvenlikli Dağıtım

apiVersion: v1
kind: ServiceAccount
metadata:
  name: secure-app-sa
  annotations:
    azure.workload.identity/client-id: "<managed-identity-id>"

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: secure-app-sa
      securityContext:
        fsGroup: 2000
      containers:
      - name: sidecar
        image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
        ports:
        - containerPort: 5000
        env:
        - name: Kestrel__Endpoints__Http__Url
          value: "http://127.0.0.1:5000"
        - name: AzureAd__TenantId
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: tenant-id
        - name: AzureAd__ClientId
          value: "<managed-identity-client-id>"
        securityContext:
          runAsNonRoot: true
          runAsUser: 1000
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "250m"
        livenessProbe:
          httpGet:
            path: /health
            port: 5000
          initialDelaySeconds: 10
          periodSeconds: 10

Kimlik bilgilerini düzenli olarak döndürme

Kimlik bilgilerinin döndürülmesi, kimlik bilgilerinin sızdırılması veya güvenliğinin aşılması durumunda saldırganların fırsat penceresini azaltır. Döndürme sıklığı, kimlik bilgisi türüne ve kuruluşunuzun güvenlik ilkesine bağlıdır:

İstemci gizli anahtarları: 90 günde bir (önerilir)
Sertifikalar: Süre dolmadan önce, genellikle 1-2 yılda bir
İmzalı HTTP İstekleri (SHR) anahtarları: Kuruluşunuzun güvenlik ilkesini izleyin

Implementation guidance: Otomatik döndürme özellikleriyle Azure Key Vault'u kullanın veya dış gizli yönetici (Mühürlenmiş Sırlar gibi) çözümlerini dağıtım işlem hattınıza entegre edin. Bu, el ile müdahaleyi en aza indirir ve tutarlı döndürme zamanlamaları sağlar.

Güvenliği aşılmış kimlik bilgilerine yanıt verme

Kimlik bilgilerinin gizliliğinin ihlal edildiğini düşünüyorsanız, olayı kapsamak ve yetkisiz erişimi önlemek için şu adımları hemen izleyin:

> Microsoft Entra ID
Yeni kimlik bilgileri oluşturun - Güvenliği aşılmış olanları değiştirmek için Microsoft Entra ID'de yeni istemci gizli dizileri veya sertifikaları oluşturun.
Gizli dizi yönetim sisteminizi güncelleştirin - Yeni kimlik bilgilerini Kubernetes Gizli Dizilerinde veya uygun erişim denetimleriyle Azure Key Vault depolayın.
SDK kapsayıcılarını yeniden dağıtma - Tüm çalışan örneklerin değişiklikleri almasını sağlayarak dağıtımlarınızı yeni kimlik bilgilerini kullanacak şekilde güncelleştirin.
Erişim günlüklerini görüntüleyin - Yetkisiz belirteç isteklerinin veya risk altındaki pencere sırasında şüpheli etkinliğin işaretleri için Azure İzleyici ve Kubernetes denetim günlüklerini denetleyin.
Olayı belgeleyin - Olayın ayrıntılarını (keşfedildiğinde, nasıl gerçekleştiğinde, nelere erişildiğinde) kaydedin ve yinelenmeyi önlemek için kuruluşunuzun olay yanıtı yordamlarını izleyin.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2026-04-19