Ana içeriğe geç
BULUT MİMARİSİ

Bulut Kimlik ve Yetki Yönetimi: Google Cloud, AWS, Azure

İnsan ve uygulama kimlikleri, kısa ömürlü erişim, en az yetki, kaynak sınırları ve erişim doğrulaması için üç platformlu teknik rehber.

İçerik güncellemesi:

Mimari ve çalışma modeli

Kimlik doğrulama kişinin veya servisin kim olduğunu, yetkilendirme hangi işlemi hangi kaynakta yapabileceğini belirler. Konsola giriş izni, veritabanı okuma izniyle aynı değildir. Kontrol düzlemi erişimi ile veri düzlemi erişimini ayrı matrise yazın; bir kaynak oluşturma yetkisi dolaylı veri erişimi veya başka bir kimliği kullanma imkânı da yaratabilir.

İnsan kimlikleri için federasyon, MFA, grup/rol ataması ve süreli yönetici yükseltmesi değerlendirilir. Uygulama için kişisel yönetici hesabı kullanılmaz. AWS IAM rolleri, Google Cloud service account ve Workload Identity Federation, Azure managed identity seçenekleri hedef servis desteğine göre uygulanır. Kısa ömürlü token statik sır riskini azaltır, fakat aşırı yetkili kimliği güvenli hale getirmez.

Yetki mirası ve platforma özgü politika değerlendirmesi önemlidir. Account, project, subscription veya organization sınırları aynı terimler değildir. Geniş üst-seviye rol dar kaynak yetkisini aşabilir; engelleyici politika, koşul ve özel rol davranışı farklı olabilir. Kullanıcıya görünen tek atamayı değil etkili yetkiyi inceleyin.

Erişim kaldırma testi yeni ve mevcut oturumu kapsamalıdır. Token geçerliliği veya kaynak cachei nedeniyle değişiklik anında etkili olmayabilir. Acil erişim kimliği günlük iş hesabından ayrılır, kullanımı izlenir ve kurtarma yolunun ana kimlik sağlayıcısı kaybında çalıştığı sınanır.

  1. 1Kimlik ve kapsam
  2. 2Token / oturum
  3. 3Etkili yetki
  4. 4İşlem ve audit
İzinli işlemle birlikte kapsam dışı erişimin reddini kanıtlayın.

Tasarım parametreleri

Kimlik türü
İnsan, uygulama ve break-glass kimliğinin sahibi ve lifecycleını ayırın.
Etkili yetki
Rol, kaynak, üst kapsam, koşul ve engelleyici kontrolleri birlikte inceleyin.
Token kapsamı
Audience, süre ve hedef servis desteğini kaydedin; farklı servisin tokenını yeniden kullanmayın.
Olay kanıtı
Kimlik, eylem, kaynak, karar ve zamanı audit kaydında eşleştirin.

Platformlardaki uygulama karşılıkları

Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.

KonuGoogle CloudAmazon Web Services (AWS)Microsoft Azure
İnsan erişimiCloud Identity / Workforce Identity Federation ve IAMIAM Identity Center ve federationMicrosoft Entra ID ve Azure RBAC
Uygulama kimliğiService account, bağlı kimlik veya Workload Identity FederationIAM role ve desteklenen STS oturumlarıManaged identity veya workload identity federation
Kaynak sınırıOrganization / folder / projectOrganization / account / resourceManagement group / subscription / resource group / resource
DenetimCloud Audit LogsAWS CloudTrailAzure Activity Log; veri erişimi için ilgili servis logları ayrıca gerekir.

Hesap ve uygulama örneği

CI/CD yalnız test ortamındaki bir storage alanına dosya yazacak olsun. Pipelinea tüm cloud hesabı için admin rolü vermek yerine hedef kaynak ve gerekli eylemleri sınırlandırın. OIDC federasyonunda issuer, audience ve repository/branch gibi claim koşullarını doğrulayın; herhangi bir pipelineın aynı kimliği almasını önleyin.

Pilot testte izinli dosya yazma başarılı, başka storagea yazma ve IAM değiştirme reddedilmelidir. Yetkiyi geri alın, hem eski token hem yeni oturum sonucunu ölçün. Reddedilen işlemin audit kanıtını bulun. Test yalnız giriş başarısı değil, sınırın gerçekten korunmasıdır.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Giriş başarılı, veri erişimi 403Kontrol düzlemi rolü veri düzlemi yetkisi vermiyor olabilir.Hedef servis, resource scope ve etkili izni doğrulayın.
Pipeline token alamıyorIssuer, audience veya claim eşleşmesi yanlış olabilir.Paylaşmadan token metadata ve trust koşullarını yetkili ortamda inceleyin.
Rol kaldırıldı ama erişim sürüyorToken veya kaynak cachei farklı sürede yenilenebilir.Yeni/mevcut oturumu ayrı zamanlayıp etkili rol mirasını kontrol edin.

Kabul ve doğrulama kontrolleri

  1. İzinli işlemle birlikte kapsam dışı erişimin reddini kanıtlayın.
  2. İnsan ve uygulama rollerini ayrı envantere alın.
  3. Uzun ömürlü sır gereksinimini gerekçelendirin.
  4. Federasyon trust koşullarını daraltıp test edin.
  5. Erişim iptalini yeni ve mevcut oturumda ölçün.
  6. Acil erişimi kayıt ve alarmıyla tatbik edin.

İlgili kavramlar

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

En az ayrıcalık ve görev ayrımı

En az ayrıcalık, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Politikanın yaşam döngüsü

Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.

Telemetri ve zaman eşleştirmesi

Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Birincil teknik dokümantasyon

İçeriğin hazırlanması

Doz Teknoloji Teknik Ekibi. Açıklamalar ilgili sağlayıcıların teknik dokümantasyonu, ortak mimari ilkeler ve açık varsayımlı örneklerle hazırlanmıştır. Hesap ve senaryolar açıklama amaçlıdır; müşteri ortamında yapılmış test veya sonuç iddiası taşımaz. Uygulamada sürüm, bölge, servis kapsamı ve destek koşulları yeniden doğrulanmalıdır.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!