Dinamik mikroservis ortamlarında IP adresi ve sabit sertifika dosyasıyla kimlik yönetmek zorlaşır. İş yükleri ölçeklenir, farklı düğümlere taşınır ve kısa süre içerisinde yeniden oluşturulur.
SPIFFE standartları ve SPIRE uygulaması, iş yüklerini çalışma ortamına göre doğrulayarak kısa ömürlü kriptografik kimlik belgeleri sağlayabilir.
Spiffe Ve Spire Nedir: Hızlı Bakış
| Kontrol alanı | Temel amaç |
|---|---|
| Güven Alanını Tasarlayın | Kuruluş, ortam ve sınırlar için anlaşılır trust domain yapısı belirleyin. |
| SPIFFE ID Adlandırmasını Standartlaştırın | Kimlik adlarında ekip, ortam, hizmet ve rol gibi bilgileri tutarlı biçimde kullanın. |
| Node Attestation Uygulayın | Ajanın güvenilir düğümde çalıştığını bulut, TPM, Kubernetes veya desteklenen yöntemle doğrulayın. |
| Workload Attestation Kullanın | Süreç, kullanıcı, Kubernetes etiketi veya diğer seçicilerle doğru iş yükünü belirleyin. |
| Kısa Ömürlü SVID Kullanın | Sertifika ve JWT tabanlı kimlik belgelerini otomatik ve kısa süreli yenileyin. |
| mTLS Politikalarını Kimliğe Bağlayın | Ağ adresi yerine doğrulanmış SPIFFE ID üzerinden servisler arası erişim verin. |
SPIFFE ile SPIRE Arasındaki Fark
SPIFFE, yazılım iş yüklerini tanımlamak için açık standartlar bütünüdür. SPIFFE ID ve SVID gibi kavramları tanımlar. SPIRE ise SPIFFE API’lerini uygulayan, düğüm ve iş yükü doğrulaması yapan üretim odaklı bir sistemdir.
SPIRE Server güven alanını ve kayıtları yönetirken SPIRE Agent düğüm üzerinde çalışır, iş yüklerini doğrular ve Workload API üzerinden kimlik belgelerini sunar.
Spiffe Ve Spire Nedir: 11 Kritik Adım
1. Güven Alanını Tasarlayın
Kuruluş, ortam ve sınırlar için anlaşılır trust domain yapısı belirleyin.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
2. SPIFFE ID Adlandırmasını Standartlaştırın
Kimlik adlarında ekip, ortam, hizmet ve rol gibi bilgileri tutarlı biçimde kullanın.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
3. Node Attestation Uygulayın
Ajanın güvenilir düğümde çalıştığını bulut, TPM, Kubernetes veya desteklenen yöntemle doğrulayın.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
4. Workload Attestation Kullanın
Süreç, kullanıcı, Kubernetes etiketi veya diğer seçicilerle doğru iş yükünü belirleyin.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
5. Kısa Ömürlü SVID Kullanın
Sertifika ve JWT tabanlı kimlik belgelerini otomatik ve kısa süreli yenileyin.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
6. mTLS Politikalarını Kimliğe Bağlayın
Ağ adresi yerine doğrulanmış SPIFFE ID üzerinden servisler arası erişim verin.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
7. Kayıtları Kodla Yönetin
Registration entry ve politika değişikliklerini sürüm kontrolü ve inceleme sürecine bağlayın.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
8. Ajan Erişimini Koruyun
Workload API soketine yalnızca yerel ve yetkili iş yüklerinin erişmesini sağlayın.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
9. Federasyon Sınırlarını Planlayın
Farklı trust domainler arasında güven gerektiğinde açık ve dar federasyon politikası kurun.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
10. Yüksek Erişilebilirlik Sağlayın
SPIRE Server, veri deposu ve imzalama bileşenleri için yedekli mimari tasarlayın.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
11. İptal ve Olay Müdahalesini Test Edin
Yanlış kayıt veya ele geçirilen düğümde kimlik verilmesini hızla durdurma adımlarını deneyin.
Bu adımı uygularken kurumun veya ürünün gerçek ihtiyaçlarını, erişim modelini ve risk seviyesini dikkate alın. Kararı belgelemek ve sonucu düzenli olarak yeniden doğrulamak, tek seferlik kurulumdan daha güvenli bir yaklaşım sağlar.
Uygulama Yol Haritası
- Mevcut varlıkları, kimlikleri, veri akışlarını ve sorumluları envantere alın.
- İş açısından kritik senaryoları ve kabul edilemez riskleri belirleyin.
- Küçük bir pilot kapsam seçerek kontrolleri ölçülebilir biçimde uygulayın.
- Günlük kayıtları, uyarıları ve düzeltme görevlerini ortak iş akışına bağlayın.
- Başarıyı yalnızca bulunan hata sayısıyla değil, azaltılan gerçek riskle ölçün.
- Yeni sürüm, entegrasyon veya mimari değişiklik sonrasında kontrolleri yeniden doğrulayın.
Sık Yapılan Hatalar
- SPIFFE ID yapısını plansız oluşturmak
- Geniş selector ile birden fazla iş yüküne aynı kimliği vermek
- Workload API soket izinlerini açık bırakmak
- Uzun ömürlü sertifikaya geri dönmek
- Federasyon güvenini bütün alanlara açmak
- SPIRE veri deposu ve imzalama anahtarını yedeklememek
Spiffe Ve Spire Nedir: Sık Sorulan Sorular
SPIFFE bir ürün müdür?
Hayır. İş yükü kimliği için açık standartlar bütünüdür.
SPIRE ne yapar?
Düğüm ve iş yükü doğrulaması yaparak SPIFFE uyumlu kısa ömürlü kimlik belgeleri verir.
SVID nedir?
SPIFFE Verifiable Identity Document, iş yükü kimliğini X.509 sertifikası veya JWT biçiminde taşıyan doğrulanabilir belgedir.
Kubernetes olmadan kullanılabilir mi?
Evet. SPIRE sanal makine, fiziksel sunucu ve farklı platformlarda çalışabilir.
SPIFFE Zero Trust ile uyumlu mu?
İş yüklerini kriptografik kimlikle doğruladığı için Zero Trust mimarisindeki güçlü kimlik yaklaşımını destekleyebilir.
İlgili İçerikler
SASE nedir Workload Identity Federation CTEM nedir
Resmî ve Güvenilir Kaynaklar
Sonuç
SPIFFE ve SPIRE nedir yaklaşımı, yalnızca yeni bir ürün satın almak veya bir özelliği etkinleştirmek değildir. Envanter, en az ayrıcalık, kısa ömürlü kimlik bilgileri, doğrulama, görünürlük ve düzenli denetim birlikte uygulanmalıdır.
Başarılı sonuç için küçük bir kapsamla başlayın, sorumluları belirleyin ve her değişiklikten sonra kontrolleri tekrar test edin. Böylece SPIFFE ve SPIRE nedir konusu teorik bir güvenlik başlığından ölçülebilir bir risk azaltma programına dönüşebilir.
