Vault PKI Secrets Engine ile Kurumsal Dahili Sertifika Otoritesi (CA) Oluşturma

 · 

Vault PKI Secrets Engine ile Kurumsal Dahili Sertifika Otoritesi (CA) Oluşturma

Vault PKI Secrets Engine ile Kurumsal Dahili Sertifika Otoritesi (CA) Oluşturma

Kurumsal altyapılarda, özellikle mikroservis mimarileri ve otomasyonun yaygınlaşmasıyla birlikte, güvenli iletişimin temeli olan X.509 sertifikalarının yönetimi kritik bir zorluk haline gelmiştir. Harici CA'lar genellikle dışa dönük hizmetler için tercih edilirken, şirket içi sistemler, API'ler ve servisler arası mTLS (Mutual TLS) iletişimi için dahili bir Sertifika Otoritesi'ne (CA) ihtiyaç duyulur. HashiCorp Vault'un PKI Secrets Engine'i, bu ihtiyacı karşılamak için güçlü, otomatize edilebilir ve merkezi bir çözüm sunar.

Vault PKI Secrets Engine Nedir?

Vault PKI Secrets Engine, Vault içinde bir veya daha fazla PKI hiyerarşisi oluşturmanıza ve yönetmenize olanak tanıyan bir eklentidir. Bu motor sayesinde, kök CA (Root CA), ara CA'lar (Intermediate CA) oluşturabilir, bu CA'lar aracılığıyla sertifikalar basabilir, iptal edebilir ve sertifika iptal listelerini (CRL) veya OCSP (Online Certificate Status Protocol) yanıtlayıcılarını yönetebilirsiniz. Tüm bu işlemler API aracılığıyla otomatize edilebilir, bu da DevOps süreçlerine mükemmel entegrasyon sağlar.

Vault Üzerinde Root CA Kurulumu

Dahili bir PKI hiyerarşisi oluşturmanın ilk adımı bir Root CA tanımlamaktır. Güvenlik prensipleri gereği, Root CA'nın çevrimdışı (offline) tutulması ve yalnızca ara CA'ları imzalamak için kullanılması önerilir. Ancak Vault, operasyonel kolaylık sağlamak için Root CA'yı da yönetebilir. Bu örnekte, Root CA'yı Vault içinde oluşturacağız.

PKI Secrets Engine'i Etkinleştirme

Öncelikle PKI secrets engine'i etkinleştirmemiz gerekir. Root CA için ayrı bir mount path kullanmak iyi bir pratiktir.

vault secrets enable -path=pki_root pki

Bu komut, pki_root yolunda bir PKI secrets engine örneğini etkinleştirir.

Root CA Oluşturma

Şimdi pki_root motoru üzerinde bir Root CA sertifikası ve anahtarı oluşturalım. Bu işlem, Vault'un kendi içinde bir CSR (Certificate Signing Request) oluşturup kendini imzalamasını sağlar.

vault write pki_root/root/generate/internal common_name="MyCompany Root CA" ttl="87600h" key_bits="4096" max_path_length="1"

Açıklama:

  • common_name: Sertifikanın ortak adı.
  • ttl: Sertifikanın geçerlilik süresi (örneğin 10 yıl).
  • key_bits: Anahtarın bit uzunluğu (4096 bit önerilir).
  • max_path_length: Bu CA'dan sonra kaç adet ara CA olabileceğini belirler. Root CA için genellikle 1 veya 2 yeterlidir.

Bu komut başarılı olursa, Vault size Root CA sertifikası detaylarını ve CA zincirini gösterecektir.

CRL Endpoint Yapılandırması

Sertifika iptal listelerinin (CRL) nerede yayınlanacağını Vault'a bildirmemiz gerekir. Bu, iptal edilen sertifikaların durumunu kontrol etmek için kullanılır.

vault write pki_root/config/urls issuing_certificates="http://127.0.0.1:8200/v1/pki_root/ca" crl_distribution_points="http://127.0.0.1:8200/v1/pki_root/crl"

Burada 127.0.0.1:8200 yerine Vault sunucunuzun erişilebilir adresini yazmalısınız. Production ortamlarında bu genellikle bir load balancer veya özel bir domain adresi olur.

Ara CA (Intermediate CA) Kurulumu

Root CA doğrudan uygulama sertifikalarını imzalamamalıdır. Bunun yerine, bu görevi bir veya daha fazla Ara CA'ya devretmeliyiz. Bu, Root CA'nın güvenliğini artırır.

Yeni Bir PKI Secrets Engine Etkinleştirme (Intermediate İçin)

Ara CA için de ayrı bir PKI secrets engine örneği etkinleştirelim.

vault secrets enable -path=pki_int pki

Ara CA İçin CSR Oluşturma

Şimdi pki_int motorunda bir CSR oluşturalım. Bu CSR'ı Root CA'mız ile imzalayacağız.

vault write -format=json pki_int/intermediate/generate/internal common_name="MyCompany Intermediate CA" ttl="43800h" key_bits="4096" > intermediate_csr.json

Oluşan CSR'ı csr alanından alalım:

CSR=$(jq -r '.data.csr' intermediate_csr.json)

Root CA ile Ara CA CSR'ını İmzalama

Şimdi Root CA'mızı kullanarak Ara CA'mızın CSR'ını imzalayalım.

vault write pki_root/root/sign-intermediate csr="$CSR" common_name="MyCompany Intermediate CA" format="pem_bundle" ttl="43800h" > signed_intermediate.json

Bu komut, Root CA tarafından imzalanmış Ara CA sertifikasını döndürür. Bu sertifikayı certificate alanından alalım:

INTERMEDIATE_CERT=$(jq -r '.data.certificate' signed_intermediate.json)

İmzalanmış Ara CA Sertifikasını Vault'a Tanıtma

İmzalanan Ara CA sertifikasını pki_int motoruna tanıtalım.

vault write pki_int/intermediate/set-signed certificate="$INTERMEDIATE_CERT"

Ara CA İçin CRL Endpoint Yapılandırması

Ara CA için de CRL endpoint'ini yapılandırmamız gerekiyor.

vault write pki_int/config/urls issuing_certificates="http://127.0.0.1:8200/v1/pki_int/ca" crl_distribution_points="http://127.0.0.1:8200/v1/pki_int/crl"

Sertifika Rolleri Tanımlama

Artık bir ara CA'mız olduğuna göre, bu CA'dan sertifika basmak için roller tanımlayabiliriz. Rol, belirli bir tür sertifika (örn. web sunucusu, istemci, uygulama) için bir şablon görevi görür ve hangi alanların zorunlu olduğunu, TTL değerlerini ve diğer kısıtlamaları belirler.

Örnek Rol Oluşturma: Web Sunucusu Sertifikası

web-server adında bir rol oluşturalım.

vault write pki_int/roles/web-server 
allowed_domains="example.com,internal.mycompany.com" 
allow_subdomains=true 
max_ttl="720h" 
organization="MyCompany Inc." 
country="TR" 
locality="Istanbul" 
province="Istanbul" 
key_usage="DigitalSignature,KeyEncipherment" 
extended_key_usage="ServerAuth" 
enforce_hostnames=false

Açıklama:

  • allowed_domains: Bu rol ile sertifika basabilecek domainler.
  • allow_subdomains: Alt domainlere izin verilip verilmediği.
  • max_ttl: Bu rol ile basılan sertifikaların maksimum geçerlilik süresi.
  • key_usage ve extended_key_usage: Sertifikanın kullanım amacını belirler (örn. web sunucusu için ServerAuth).

Sertifika Üretimi ve Yönetimi

Roller tanımlandıktan sonra, uygulamalarınız veya servisleriniz API aracılığıyla sertifika isteyebilir.

Sertifika Üretme

web-server rolünü kullanarak bir sertifika isteyelim.

vault write pki_int/issue/web-server common_name="mywebapp.internal.mycompany.com" ttl="24h"

Bu komut, mywebapp.internal.mycompany.com için bir sertifika, özel anahtar ve CA zinciri döndürecektir. Uygulamanız bu çıktıları alıp kullanabilir. Otomasyon senaryolarında, bu çıktıları alıp ilgili servisin dosyalarına yazmak için bir ara katman (örn. Kubernetes admission controller, Ansible playbook) kullanılabilir.

Sertifika İptali

Bir sertifikanın güvenliği ihlal edildiğinde veya artık gerekli olmadığında iptal edilmesi gerekir. Vault, seri numarası üzerinden sertifika iptalini destekler.

vault write pki_int/revoke serial_number="<sertifika-seri-numarası>"

İptal edilen sertifikalar CRL'de yayınlanır ve OCSP yanıtlayıcısı aracılığıyla durumu sorgulanabilir.

Gerçek Dünya Senaryosu: Mikroservis Ortamında mTLS

Bir Kubernetes kümesinde çalışan mikroservisler arasında güvenli iletişim sağlamak için Vault PKI'yi nasıl kullanabileceğimize bakalım:

1. **Init Container:** Her bir mikroservis pod'u başlatıldığında, bir init container Vault'tan kendi servisi için bir sertifika ve özel anahtar talep eder. Bu sertifika, servisin common_name veya SAN (Subject Alternative Name) alanlarında servis adını ve/veya IP adresini içerir. İlgili rol, sadece belirli domainlere veya alt domainlere sertifika basılmasına izin verecek şekilde yapılandırılmıştır.

2. **Certificate Sidecar/Agent:** Sertifikaların TTL'leri genellikle kısadır (örn. 24 saat veya 7 gün). Bu nedenle, bir sidecar konteyneri (örn. Vault Agent) sertifikayı periyodik olarak otomatik yenilemekten sorumludur. Bu, sertifika manuel yenileme yükünü ortadan kaldırır ve kesintisiz hizmet sağlar.

3. **Servis Mesh Entegrasyonu:** Istio gibi bir servis mesh kullanılıyorsa, Vault'u Istio'nun CA'sı olarak entegre etmek mümkündür. Bu sayede, Istio'nun otomatik mTLS yetenekleri Vault'un sağladığı güçlü PKI yönetimiyle birleşir. Vault, Istio'nun Workload CA'sına sertifikalar sağlayarak, tüm mesh içindeki servislerin birbirine güvenli bir şekilde bağlanmasını sağlar.

4. **Uygulama İçi Kullanım:** Uygulama kodu, güvenli API çağrıları yaparken veya gelen bağlantıları kabul ederken bu sertifikaları kullanır. Örneğin, bir Go uygulaması HTTPS sunucusu kurarken veya bir REST istemcisi ile harici bir servise bağlanırken bu sertifikaları yükleyebilir.

// Go dilinde bir HTTPS sunucusu örneği
package main

import (
	"fmt"
	"net/http"
)

func helloHandler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Hello, secure world!")
}

func main() {
	http.HandleFunc("/", helloHandler)
	// Vault'tan alınan sertifika ve anahtar yolları
	certFile := "/etc/certs/tls.crt"
	keyFile := "/etc/certs/tls.key"

	fmt.Println("Starting HTTPS server on :8443")
	err := http.ListenAndServeTLS(":8443", certFile, keyFile, nil)
	if err != nil {
		fmt.Printf("Server failed: %s\n", err)
	}
}

Bu senaryoda, /etc/certs/tls.crt ve /etc/certs/tls.key dosyaları, Vault Agent veya init container tarafından dinamik olarak oluşturulan ve güncellenen sertifika ve özel anahtar dosyalarını temsil eder.

Güvenlik ve Operasyonel Best Practices

  • **Erişim Kontrolü (ACL):** Her bir rol ve PKI motoru için granüler ACL politikaları tanımlayın. Yalnızca yetkili kullanıcıların veya servis hesaplarının sertifika basmasına veya iptal etmesine izin verin. Örneğin, bir servis sadece kendi rolünden sertifika basma yetkisine sahip olmalıdır.
  • **Audit Logging:** Vault'un tüm işlemlerini audit loglarına kaydedin. Bu, güvenlik denetimleri ve olay incelemesi için hayati öneme sahiptir.
  • **Key Rotation:** Hem Root CA hem de Intermediate CA anahtarlarının belirli aralıklarla döndürülmesi düşünülmelidir. Bu işlem karmaşık olsa da, uzun vadeli güvenlik için önemlidir.
  • **Disaster Recovery:** Vault'un kendi DR mekanizmalarını (snapshot, replikasyon) kullanarak PKI verilerinizin yedekliliğini ve kurtarılabilirliğini sağlayın. CA anahtarlarının kaybolması, tüm PKI hiyerarşisinin çökmesi anlamına gelir.
  • **Sertifika Geçerlilik Süreleri:** Uygulama sertifikaları için kısa TTL'ler (örn. birkaç gün veya hafta) kullanın. Bu, bir sertifikanın sızdırılması durumunda etkisini sınırlar ve otomasyonu teşvik eder.
  • **CRL/OCSP Doğrulama:** Sertifika kullanan tüm uygulamaların CRL'leri veya OCSP yanıtlarını düzenli olarak kontrol ettiğinden emin olun.

Vault PKI Secrets Engine, dahili CA yönetimi için kurumsal düzeyde bir çözüm sunar. Doğru yapılandırma ve otomasyon ile, sertifika yönetimi süreçlerinizi basitleştirebilir, güvenlik duruşunuzu güçlendirebilir ve altyapınızdaki güvenli iletişimi standartlaştırabilirsiniz.

← Blog Listesine Dön