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.
- 1Kimlik ve kapsam
- 2Token / oturum
- 3Etkili yetki
- 4İşlem ve audit
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.
| Konu | Google Cloud | Amazon Web Services (AWS) | Microsoft Azure |
|---|---|---|---|
| İnsan erişimi | Cloud Identity / Workforce Identity Federation ve IAM | IAM Identity Center ve federation | Microsoft Entra ID ve Azure RBAC |
| Uygulama kimliği | Service account, bağlı kimlik veya Workload Identity Federation | IAM role ve desteklenen STS oturumları | Managed identity veya workload identity federation |
| Kaynak sınırı | Organization / folder / project | Organization / account / resource | Management group / subscription / resource group / resource |
| Denetim | Cloud Audit Logs | AWS CloudTrail | Azure 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
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Giriş başarılı, veri erişimi 403 | Kontrol düzlemi rolü veri düzlemi yetkisi vermiyor olabilir. | Hedef servis, resource scope ve etkili izni doğrulayın. |
| Pipeline token alamıyor | Issuer, 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üyor | Token veya kaynak cachei farklı sürede yenilenebilir. | Yeni/mevcut oturumu ayrı zamanlayıp etkili rol mirasını kontrol edin. |
Kabul ve doğrulama kontrolleri
- İzinli işlemle birlikte kapsam dışı erişimin reddini kanıtlayın.
- İnsan ve uygulama rollerini ayrı envantere alın.
- Uzun ömürlü sır gereksinimini gerekçelendirin.
- Federasyon trust koşullarını daraltıp test edin.
- Erişim iptalini yeni ve mevcut oturumda ölçün.
- 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.
İlgili bulut rehberleri
Google Cloud, AWS ve Azure: Bulut Platformu Nasıl Seçilir?
İş yükü, servis modeli, veri yerleşimi, güvenlik, kurtarma ve toplam maliyet üzerinden Google Cloud, AWS ve Azure değerlendirmesi.
Bulut Ağ Tasarımı: Google Cloud VPC, AWS VPC ve Azure VNet
Adres planı, platform sınırları, routing, private erişim, firewall ve hibrit bağlantıların tasarımı ve hata teşhisi.
Bulut Geçişi: Google Cloud, AWS ve Azure Migration Planı
Keşif, bağımlılık analizi, servis seçimi, veri eşitleme, cutover ve rollback adımlarıyla kontrollü bulut geçişi.
Bulut Maliyeti ve FinOps: Google Cloud, AWS, Azure
Compute, storage, veri çıkışı, log ve lisans maliyetini; bütçe, rightsizing ve taahhütlerle birlikte yönetin.
Bulut Yedekleme ve Disaster Recovery: Google Cloud, AWS, Azure
Backup, replication ve HA ayrımı; bağımsız kurtarma erişimi, RPO/RTO, region kaybı ve failback testleri.
Bulut kurulum, işletim ve destek hizmetleri
Platform seçimini mevcut ürünleriniz, iş yükünüz ve işletim ihtiyaçlarınızla birlikte değerlendiriyoruz.