Servisler Arası Kimlik — İç Ağdan Gelen Her İstek Güvenilir mi?
Önce şunu oku: API Gateway ve Service Discovery — İstek Doğru Kapıyı Nasıl Bulur
30 saniyede özet
İç ağa güvenmek, hatalı bir servise ya da ele geçirilmiş bir pod'a her kapıyı açar. Ortak anahtar kimin çağırdığını söylemez. Servis başına sertifika (mTLS) ve en az yetki kuralı, yalnızca izinli servisin işi yapmasını sağlar.
Bir banka binasında içeri girebilen herkes her kapıyı açabiliyor. Sonra bütün çalışanlara aynı anahtar veriliyor; kasayı kimin açtığını kimse bilmiyor. En sonunda herkese kişiye özel bir kart veriliyor ve her kapının hangi kartlara açıldığı bir listede duruyor.
-
Bayt: Muhasebe defteri yalnızca iç ağdan istek kabul ediyor. Dışarısı zaten giremez, değil mi?
-
Sen: Bugün defterde tanımadığımız bir borç kaydı var. İstek pazarlama servisinin pod'undan gelmiş.
-
Bayt: Pod ele geçirilmiş! Ortak anahtar da ortamında duruyormuş; defter onu havale servisinden ayıramadı.
-
Bayt: Herkese kişiye özel bir kart, her kapıya da bir izin listesi lazım.
İçeride olmak bir kimlik değil
Servislerin çoğu, iç ağdan gelen her isteğe güvenir. Ama iç ağdan hatalı bir servis de, VPN’deki bir betik de, ele geçirilmiş bir makine de istek atar.
Herkesin taşıdığı ortak bir anahtar, anahtarsız betiği durdurur. Ama kimin çağırdığını söylemez: anahtarı ortamında taşıyan her pod, havale servisiyle aynı görünür.
Kafam karıştı, daha basit anlat
İç ağ bir kimlik değildir. Ortak anahtar “içeriden” der, “kim” demez.
İç ağdan gelen her isteğe güvenmenin sorunu nedir?
Bütün servislerin aynı API anahtarını kullanmasının zayıf yanı nedir?
Kişiye özel kart, kapıya özel izin
Her servisin kendi sertifikası var ve defter yalnızca havale servisinin borç yazmasına izin veriyor. Ele geçirilmiş pazarlama pod'u kendi sertifikasıyla borç isteği atıyor. Ne olur? Cevabı göster
Reddedilir. Defter, çağıranın pazarlama servisi olduğunu sertifikasından bilir. Kural ona borç izni vermez; saldırgan, ele geçirdiği pod’un izinleriyle sınırlı kalır.
Adım adım oku
- Binanın içindeysen her kapı açık.
- Herkese aynı anahtar: kim açtı, bilinmez.
- Kişiye özel kart, kapıya özel izin.
- İçeride olmak kimlik değildir.
mTLSİki tarafın da sertifikasıyla kim olduğunu kanıtladığı TLS bağlantısı. Servisler arası çağrıda çağıranın kimliğini verir.Sözlükte gör →’de bağlantının iki tarafı da sertifikasıyla kim olduğunu kanıtlar. Defter servisi artık her çağıranın adını bilir.
Kimlik tek başına yetmez; her servise yalnızca işi için gereken izin verilir. Buna least privilegeBir kullanıcıya, servise ya da ajana yalnızca işini yapmasına yetecek kadar izin vermek. Kandırılsa ya da yanılsa bile yapabileceği zararı sınırlar.Sözlükte gör → denir. Konuma değil, her isteğin kimliğine ve iznine bakan bu yaklaşıma sıfır güvenAğdaki konuma değil, her isteğin kanıtlanmış kimliğine ve iznine güvenen güvenlik yaklaşımı.Sözlükte gör → denir.
Kafam karıştı, daha basit anlat
Sertifika kim olduğunu söyler, kural neye izni olduğunu. İkisi birlikte çalışır.
mTLS neyi sağlar?
Kimliğin yanında neden bir yetki kuralı da gerekir?
Kendin gör
Muhasebe defterine borç yazma istekleri
Tohum 715285Hedef: muhasebe defteri · istek: “bu hesaptan borç yaz”
- Havale servisiortak anahtar var · kendi sertifikası var
- Rapor servisi (hata yüzünden borç yazmaya çalışıyor)ortak anahtar var · kendi sertifikası var
- VPN’deki bir geliştirici dizüstündeki betikanahtar yok · sertifika yok
- Ele geçirilmiş pazarlama pod’uortak anahtar var · kendi sertifikası var
✕ yanlış karar: 0
Şu an ne oldu?
İç ağdaysa güven
Dört farklı kaynak, hesaptan borç yazmak istiyor.
Görevler0/3
VPN’deki bir betik borç yazabilsinaçık
İpucu
İç ağa güven.
Betik dursun, ele geçirilmiş pod yine borç yazsınaçık
İpucu
Ortak anahtar.
Yalnızca havale servisi borç yazabilsinaçık
İpucu
Servis başına kimlik.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. İç ağa güven: hatalı rapor servisi, VPN’deki betik ve ele geçirilmiş pod da borç yazdı.
- “Ortak anahtar” seç. Anahtarsız betik durdu; anahtarı taşıyan rapor servisi ve pazarlama pod’u yine borç yazdı.
- “Servis başına sertifika” seç. Yalnızca havale servisi borç yazabildi.
Ele geçirilmiş bir pazarlama pod'u kendi sertifikasıyla defter servisine borç isteği atıyor. mTLS ve kural varken ne olur?
Service mesh (örneğin Istio, Linkerd) bu konuda ne yapar?
Tuzaklar
Uzun ömürlü sertifikalar. Sızan bir sertifika süresi dolana kadar işe yarar. Servis sertifikalarını kısa ömürlü tut ve otomatik yenile; bunu bir service mesh ya da sertifika yöneticisi yapabilir.
Ortak sırrı döndürmek. Ortak anahtar sızınca bütün servisler aynı anda güncellenmeli; biri unutulursa çağrıları kırılır. Servis başına kimlikte yalnızca sızan servis değişir.
Kullanıcı ile servisi karıştırmak. JWT isteğin kimin adına yapıldığını söyler, mTLS hangi servisin gönderdiğini. Defter ikisine birden bakabilir.
Kafam karıştı, daha basit anlat
Kimliği kısa ömürlü tut, sırrı servis başına ayır, kullanıcıyı ve servisi ayrı sor.
Servis sertifikaları neden kısa ömürlü ve otomatik yenilenen tutulur?
Derinleş · Muhasebe defteri: yalnızca havale servisi borç yazabilir 2 dosya · ~56 satır · ilk okumada atlayabilirsin
Kendini sına
İç ağdan gelen bir istek her zaman güvenilirdir.
Ortak anahtar sızdı. Değiştirmenin zorluğu nedir?
Aklında kalacak üç şey
- 1 İç ağda olmak bir kimlik değildir. Hatalı bir servis ya da ele geçirilmiş bir makine de iç ağdan istek atar.
- 2 Ortak bir API anahtarı isteğin içeriden geldiğini söyler, kimden geldiğini söylemez; anahtarı taşıyan herkes her şeyi yapabilir.
- 3 Servis başına sertifika kimliği, yetki kuralı ise izni verir: her servis yalnızca işini yapabilir.
4 kart sonraki derste seni bekliyor