Monopam Vault: Discovery, Vault'a alma ve rotasyon
Neler değişti
Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.
Sürüm 9 → 10
GüncellemeVault'u üretimde işletmeye dair yeni modül: vault anahtarı ve yeniden şifreleme, başarısız rotasyonlardan kurtulma, sır eşitlemeleri ve paylaşılan öğeler, belirteç kodlaması, makine kimlikleri ve dinamik sır kiralamaları. Modülde artık diyagramlar ve sonunda önce neye bakılacağını gösteren bir liste var.
3 ders güncellendisüre
İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.
Süre 24 dakikadan 26 dakikaya değişti.
Kiracı veritabanındaki her sır, her Monopam sürecinin başlarken ortamından okuduğu bir anahtarla şifrelenir. Anahtar ayarlanmamışsa Monopam yerleşik bir anahtar kullanır. Bu yerleşik anahtar ürünün içinde gelir; sıradan okumaya karşı korur ama hem veritabanı dökümünü hem yazılımı elinde tutan birine karşı korumaz. Üretim kurulumu kendi anahtarını ayarlar.
| Değişken | Amaç |
| --- | --- |
| `MONOPAM_VAULT_KEY` | Etkin anahtar. Yeni yazmalar bunu kullanır |
| `MONOPAM_VAULT_KEY_VERSION` | Etkin anahtarın sürüm numarası. Büyük sayı daha yeni anahtar demektir |
| `MONOPAM_VAULT_KEYS` | Eski anahtarlar; onlarla yazılmış satırlar okunabilsin diye tutulur |
Bunlar birlikte **anahtar halkasını** oluşturur. Süper yönetici durumu vault bakım anahtar durumu ile denetleyebilir; bu, etkin sürümü ve kurulumun dış anahtarla çalışıp çalışmadığını bildirir.
### Çoğu olayı açıklayan üç kural
**1. Her süreç ve yalnızca başlangıçta.** Web sunucusu ve her gateway sırları çözer; hepsinin aynı anahtar halkasına ihtiyacı vardır. Ortam başlangıçta bir kez okunur, bu yüzden değişiklik süreç yeniden başlayana kadar hiçbir şey yapmaz. Klasik belirti: anahtar yalnızca web sunucusunda ayarlanmıştır. Tarayıcıda parola göstermek çalışır, çünkü web sunucusu çözebilir; SSH ve RDP ise başarısız olur, çünkü gateway çözemez. Anahtarı her ana bilgisayarda ayarlayın, her birini yeniden başlatın ve bunun için bir bakım penceresi planlayın.
**2. İş anahtarı izler, tersi olmaz.** Anahtar her yerde yerine oturduktan sonra süper yönetici yeniden şifreleme işini çalıştırır; iş mevcut satırları etkin anahtarla yeniden yazar. İşi dış anahtar olmadan çalıştırmak güvenlik kazancı sağlamaz: satırlar yerleşik anahtarla yeniden yazılır ve bir uyarı kaydedilir.
**3. Eski anahtarlar iş sıfır hata bildirene kadar kalır.** İş sonucu, tablo başına kaç değeri taradığını, yükselttiğini ve kaçında başarısız olduğunu listeler. Başarısız değer, işin çözemediği bir satırdır; genellikle yazıldığı anahtar sürümü halkada eksiktir. İş böyle satırlara dokunmaz. Eski anahtarları şimdi kaldırırsanız o satırlar kalıcı olarak okunamaz olur. Eksik anahtarı `MONOPAM_VAULT_KEYS` içine ekleyin, yeniden başlatın, işi yeniden çalıştırın ve eski anahtarları ancak her yerde `FailedValues` sıfır olan bir çalıştırmadan sonra kaldırın.
::diagram pam-vault-key-change
### Kurtarma yoktur
Kaybedilen anahtar kurtarılamaz ve onunla şifrelenen her satır okunamaz kalır. Değişikliğe başlamadan önce anahtarı Monopam dışında, örneğin erişimi kısıtlı bir parola yöneticisinde saklayın ve ona sahip olduğunuz en hassas kimlik bilgisi gibi davranın.
> İpucu: değişiklikten önce ve sonra vault bakım anahtar durumunu okuyun. Öncesinde kurulumun dış anahtarla çalışıp çalışmadığını söyler. Sonrasında etkin sürüm sizin ayarladığınız sürüm olmalıdır.
Rotasyon hedefteki parolayı değiştirir ve ardından bağımlı sistemleri, örneğin hesabı kullanan bir servisi ya da uygulama havuzunu güncelleyen otomasyonları çalıştırır. Rotasyon politikasındaki `If Automation Fails` ayarı, bu otomasyonlardan biri başarısız olduğunda ne olacağını belirler.
| Seçim | Monopam ne yapar | Ne zaman uygundur |
| --- | --- | --- |
| `Revert to the previous password` (varsayılan) | Hedefi geri değiştirir; vault ve hedef eski parolada buluşur | Bağımlı sistem çalışmaya devam etmeli ve hedef ikinci bir değişikliği kaldırıyorsa |
| `Keep the new password` | Vault'u ve hedefi yeni parolada bırakır ve öğeyi takip için işaretler | Art arda ikinci bir değişiklik hesabı kilitleyecekse |
Geri almanın gerçekte ne olduğunu düşünün: ilkinden birkaç saniye sonra hedefte ikinci bir parola değişikliği. Hızlı değişikliklerden sonra hesabı kilitleyen bir sistemde tehlikeli olan bu ikinci değişikliktir. Orada yeni parolayı korur ve bağımlı sistemi elle onarırsınız.
### Geri alma da başarısız olursa
`Password Rotation Revert Error: Manual Intervention Required` denetim olayı, otomasyonun başarısız olduğunu ve geri dönme girişiminin de başarısız olduğunu söyler. Vault ve hedef artık farklı parolalar tutuyor olabilir ve Monopam hedefin hangisini kabul ettiğini bilemez.
Tıklamaya başlamayın. Önce hedefin şu an hangi parolayı kabul ettiğini belirleyin. Sonra buna göre hareket edin: vault doğru değeri tutuyor ve hedefin uyumlu hâle getirilmesi gerekiyorsa `Reconcile`, önceki değer geçerliyse Password History üzerinden geri alma ve ardından `Reconcile`, ya da ana bilgisayarda elle sıfırlama. Kilitleme eşiği olan bir sistemde parolaları yanlış sırayla denemek hesabı kilitler ve bir rotasyon sorununu kesintiye çevirir.
::diagram pam-rotation-outcomes
### Döndürülen sır nereye gider
**Sır eşitlemeleri.** Bir vault öğesi AWS Secrets Manager gibi harici bir depoya eşitlenebilir. Eşitleme yalnızca parola kesinleştiğinde kuyruğa alınır: kayıttan sonra ya da geri alınmamış başarılı bir rotasyondan sonra. Başarısız olup geri alınan rotasyon hiçbir şey göndermez; böylece harici depo on saniye yaşamış bir parolayı hiç görmez.
**Kiracılar arası paylaşılan öğeler.** Bir hizmet sağlayıcı, ana kiracısındaki bir öğeyi sırrı kopyalamadan müşteri kiracısında kullanılabilir yapabilir. Müşterinin çalışanlarının ne yapabileceğini mod belirler.
| Mod | Müşteri kiracısı ne yapabilir |
| --- | --- |
| `Sessions only` (varsayılan) | Hesapla oturum açabilir. Sır gösterilmez, vault API'sinden dönmez ve betik belirteçlerine konmaz |
| `Sessions and reveal` | Değeri de okuyabilir |
Sır yalnızca ana kiracıda yaşar. Rotasyon, geçmiş ve mutabakat orada yapılır; müşteri kiracısındaki her kullanım o andaki güncel değeri okur, böylece döndürülen parola her yerde aynı anda günceldir.
**Başlatıcılarda ve betiklerde belirteçler.** `{{Vault.appadmin.Password}}` gibi bir belirteç ham değeri yerleştirir. Yapıştırdığınız yerin kendi sözdizimi varsa ham değer yanlıştır. Bir URL'de `&` ya da `#` içeren parola adresi bozar. Bir kodlama değiştiricisi ekleyin: `{{Vault.appadmin.Password:url}}` değeri yüzde kodlamasıyla kodlar, `:sh` ve `:ps` değeri tek tırnaklı kabuk ya da PowerShell dizgisi içinde güvenli kılar, `:base64` ise Base64 çözen bir aktarım için kodlar. Değiştiriciler zincirlenemez; yanlış yazılan değiştirici hata vermeden yok sayılır ve ham değeri verir. Bu yüzden özel karakterlerle dolu bir parolayla deneyin.
> İpucu: başarısız bir rotasyondan sonra hesaba dokunmadan önce denetim kaydını okuyun. Geri alma başarılıysa vault ve hedef eski parolada buluşur ve yalnızca bağımlı sistemin onarılması gerekir. İkisinin farklı olabileceğini yalnızca `Password Rotation Revert Error: Manual Intervention Required` gösterir.
İnsanlar sırları tarayıcıda görüntüler. Pipeline'lar, pod'lar ve operatörler ise sırları Secrets Store'dan bir **makine kimliği** (`Secrets` > `Identities`) ile okur. Kimlik oturum açar, kısa ömürlü bir belirteç alır ve proje, ortam ve klasör üzerindeki **izinlerinin** (grant) elverdiğini okur.
### Oturum açma yöntemini seçmek
| Yöntem | Makine kendini neyle kanıtlar | Ne zaman seçilir | Bedeli |
| --- | --- | --- | --- |
| Universal Auth | İstemci kimliği ve istemci sırrı | Çağıran her yerde çalışabiliyorsa; belirteç vereni yalnızca iç ağda olan bir CI sunucusu dahil | Saklanması ve elle döndürülmesi gereken bir sır |
| OIDC | Platformundan gelen, verenin açık anahtarları ve bağlı talep (bound claim) ile denetlenen imzalı bir belirteç | Platformun vereni herkese açık erişilebiliyorsa; barındırılan pipeline servislerinde olduğu gibi | Hiçbir şey saklanmaz. Monopam verenin açık belgelerine ulaşamıyorsa çalışmaz |
| Kubernetes | Kümenin bir servis hesabı belirteci | İş yükü bir kümede çalışıyorsa | Monopam kümeye ulaşabilmelidir |
Örnek: bir ekip, barındırılan bir pipeline servisinde deposunda uzun ömürlü belirteç istemez. Bağlı talebi iş akışının kaynağıyla eşleşen bir OIDC kimliği pipeline'a kısa ömürlü bir belirteç verir ve sızacak bir şey bırakmaz. Kendi barındırdıkları derleme sunucusu da belirteç üretir ama vereni yalnızca ağ içinden görünür; Monopam bunları doğrulayamaz. O sunucu Universal Auth alır ve `Allowed IP ranges` derleme ağına ayarlanır; böylece sızan bir sır başka yerde işe yaramaz.
### Olaydan önce bilinmesi gereken davranışlar
- **Belirteçler kimlikteki değişikliklerden uzun yaşar.** Kimliği devre dışı bırakmak ya da `Rotate Secret`, yeni oturum açmaları hemen durdurur. Verilmiş belirteçler `Token TTL (minutes)` bitene kadar çalışmaya devam eder. Gerçek sınırlama süreniz kısa bir TTL'dir.
- **`Rotate Secret` geri alınamaz.** Eski sır hemen ölür. Onu hâlâ taşıyan her çağıran, yenisini alana kadar `Invalid client credentials.` ile başarısız olur. Mümkünse önce dağıtın ve paylaşılan bir kimliği asla gelişigüzel döndürmeyin.
- **`Allowed IP ranges` yalnızca oturum açarken denetlenir**, her okumada değil. Yük dengeleyici arkasında çağıran adresi `X-Forwarded-For` içindeki ilk IPv4 adresidir. Dengeleyici bu başlığı ayarlamazsa her çağıran dengeleyici gibi görünür ve kısıtlı kimlik reddedilir. Başlığı düzeltin. Dengeleyicinin adresini aralığa eklemeyin; bu, arkasındaki herkesi geçirir.
- **Başarısız oturum açmalar adresi duraklatır.** Beş dakika içindeki onuncu başarısızlıktan itibaren adres, pencerenin geri kalanında `Too many failed logins` alır. Tek NAT adresinin arkasındaki otuz pipeline aynı kaderi paylaşır; eski sırla döngüye giren tek bir iş hepsini durdurur.
- **Retler kodu gövdede taşır.** Makine API'sindeki bir yetki reddi, içinde `"code":403` bulunan HTTP 400 ile yanıtlanır. İstemciler gövdeyi okumalıdır.
- **`Restricted (never visible)` bir ekran ayarıdır.** Değeri web arayüzünde gizler. İzni olan makine onu yine alır; makine API'sinden de Vault uyumlu API'den de. Bir makinenin okuyabileceğini yalnızca izinler sınırlar.
### Dinamik sırlar
Dinamik sır (`Secrets` > `Dynamic`) isteğe bağlı olarak kısa ömürlü bir kimlik bilgisi, örneğin bir veritabanı girişi oluşturur ve bunu bir **kiralama** (lease) olarak verir. Kiralama bittiğinde Monopam kimlik bilgisini hedefte iptal eder.
| Durum | Ne olur | Ne yaparsınız |
| --- | --- | --- |
| Bir uygulama veritabanı kiralamasını tekrar tekrar yeniler | Her yenileme kiralamayı uzatır ama oluşturma zamanı artı `Max TTL (minutes)` ötesine asla geçmez | Uygulamanın bu sınırdan önce yeni kiralama isteyip yeniden bağlanmasını sağlayın |
| Kiralama dolduğunda hedefe ulaşılamadı | Kiralama `Revoke Failed` gösterir. Monopam yeniden denemez | Üretilen girişi hedefte elle kaldırın. Hâlâ var olabilir |
| Bir Kubernetes belirteci kiralaması yenilenir | Yenileme reddedilir | Belirtecin süresi dolmadan yeni kiralama isteyin |
::diagram pam-machine-lease
İzlenmesi gereken durum `Revoke Failed` durumudur. Monopam'in oluşturduğu bir kimlik bilgisinin kimse fark etmeden yaşamaya devam edebileceği tek durum budur.
### Önce neye bakılır
| Belirti | Önce bakılacak yer |
| --- | --- |
| Bir kimliğin tüm çağıranları `Invalid client credentials.` ile başarısız | Birinin `Rotate Secret` kullanıp kullanmadığı. Eski sır anında ölür |
| Birçok pipeline aynı anda `Too many failed logins` alıyor | Paylaşılan NAT adresinin arkasında eski sırla döngüye girmiş tek bir iş |
| Kısıtlı bir kimlik yük dengeleyicinin arkasında reddediliyor | Dengeleyicinin `X-Forwarded-For` başlığını ayarlayıp ayarlamadığı |
| İstemci, ret beklenen yerde HTTP 400 bildiriyor | Gövde: `"code":403` yetkilendirme reddidir |
| Devre dışı bırakılan kimlik hâlâ sır okuyor | Verilmiş belirteçleri `Token TTL (minutes)` bitene kadar yaşar |