Bu senaryo, kimliği birincil çerçeve olarak ele alan ve miras kısıtlamalarını kısa vadede değişmez gerçekler olarak kabul eden bir gereksinim stratejisi gerektiriyor. Yaklaşım, gereksinimleri "köprü" yetenekleri (geçici birlikte çalışabilirlik) ve "hedef" yetenekler (sıfır güven nihai durumu) olarak ikiye ayırmalıdır. Kritik olarak, strateji, geçici güvenlik borcunun kalıcı mimariye dönüşmesini önlemek için geçiş kontrolleri için açık kapanış maddeleri içermelidir. Son olarak, gereksinimlerin NIST ilkelerine uymak için denetçilere doğrudan kodu inceleme olanağı vermeden uyumluluk kanıtı sağlamak amacıyla Istio metrikleri aracılığıyla telemetri ve gözlemlenebilirliğin zorunlu kılınması gerektiğini belirtmelidir.
Sorun Tanımı
Bir sağlık hizmeti ödeme işleme merkezi, açık kayıt dönemi için ölçeklenebilirlik elde etmek amacıyla Java EE monolitik temizleme uygulamasını Kubernetes mikro hizmetlerine ayırmak zorundaydı. Güvenlik ekibi, her hizmetten hizmete çağrının NIST SP 800-207 gerekliliklerine uygun olarak Istio mTLS kullanarak gerçekleştirilmesini gerektiren katı sıfır güven segmentasyonu talep etti. Ancak, eski sistem Active Directory orman güvenleri ve HTTP/REST'ten önce var olan CORBA çağrılarına dayanıyordu; geliştirme takımı derin Java EE uzmanlığına sahipti ancak bulut tabanlı güvenlik deneyimi yoktu. İşin karmaşasını artıran bir HIPAA uyumluluğu doğrulama son tarihinin zorlayıcı bir kısıt olduğu ve geçiş sırasında %99,99 kesintisizliğin korunması gerektiği ortaya çıktı.
Çözüm 1: Kimlik farkındalığına sahip proxy ile oturum çoğaltma
AD Kerberos biletlerini JWT belirteçlerine çevirmek için Keycloak'ı merkezi bir kimlik doğrulama aracı olarak dağıtmak başlangıçta cazip görünüyordu, çünkü bu, Java EE kod tabanında minimal değişiklik gerektiriyor ve tanıdık kimlik doğrulama desenlerini kullanıyordu. Artıları, kapsamlı geliştirici yeniden eğitimine gerek kalmadan hızlı bir dağıtım ve geçici dönem için merkezi politika yönetimi sağlamasıydı. Ancak, eksileri arasında Keycloak'da yüksek değerli bir saldırı hedefi oluşturmak ve bu durumun proxy arkasındaki doğu-batı trafiği için sıfır güven "asla güvenme, her zaman doğrula" ilkelerini ihlal etmesi bulunuyordu. Ayrıca, yapışkan oturum yönetimi, kesinti olayları sırasında %99,99 kesintisizlik SLA'sını tehdit eden durum senkronizasyon karmaşıklığını artırıyordu ve bu yaklaşım hizmetten hizmete kimlik doğrulama ihtiyacını ele almıyordu.
Çözüm 2: Tam kimlik yeniden yapılandırması ve mavi-yeşil geçiş
Kimlik doğrulama modüllerini Istio hizmet hesaplarını kullanacak şekilde yeniden yazmak ve Kubernetes ile LDAP entegrasyonuna keskin bir geçiş yapmak, derhal saf bir sıfır güven mimarisi sunuyordu. Artıları, tüm miras kimlik borcunun ortadan kaldırılması ve üretim sürecinin ilk gününden itibaren NIST ilkelerine tam uyum sağlanmasıydı. Ancak, eksileri, sekiz aylık bir özel DevSecOps çabası gerektiriyor ve bu da içeride mevcut olmayan bir ihtiyaç olarak yüksek maliyetli müteahhit katılımını gerektiriyordu. Ayrıca, yaklaşım, kimlik sağlayıcı geçişi için kesinti gerektiriyor ve iş kesintisizliği gereksinimlerini ihlal ediyordu, tatil sezonu sırasında kritik finansal işlem işleme için kabul edilemez gerileme riskleri sunuyordu.
Çözüm 3: Yan süreç soyutlaması ile aşamalı yetenek geliştirme
Istio yan süreçlerinin mTLS sonlandırması yaparken kimlik doğrulama başlıklarını miras konteynerlere localhost üzerinden iletmesini sağlamak, pragmatik bir orta yol sağlıyordu. Artıları, miras uygulamanın dahili olarak değişmeden çalışmasına izin vermesi, dışarıda sıfır güven uyumlu görünmesini sağlaması, geliştiricilerin kodlama yerine yapılandırma yoluyla OIDC/OAuth 2.0 kavramlarını kademeli olarak öğrenmesini sağlaması ve büyük riskler olmadan kullanılabilirliği doğrulamak için kanarya dağıtımlarını desteklemesiydi. Eksileri, başlık sahteciliği girişimlerini tespit etmek için artırılmış Falco çalışma zamanı izleme gerektiren geçici "yumuşak güven" alanları oluşturmasıydı ve geçiş sırasında ayrıcalıkların yükseltilmesini önlemek için dikkatli bir sanitizasyon mantığı gerektiriyordu. Nihayetinde, bu yaklaşım, geçici mimari karmaşıklığı iş kesintisi risk azaltma stratejisi olarak kabul etti ve açık kapanış tarihleri RTM'de belgelendi.
Seçilen çözüm ve neden
%99,99 kesintisizlik ve mevcut geliştirici hızının korunmasını içeren "Zorunlu" kriterlerin açıkça belirtildiği bir MoSCoW önceliklendirme atölyesi gerçekleştirdikten sonra Çözüm 3'ü seçtik. Istio'yu dahili yeniden yapılandırma gerektirmeden dışsal bir güvenlik kaplaması olarak ele alarak, CISO'nun NIST uyumluluk gereksinimlerini otomatik OPA politika uygulaması yoluyla karşıladık ve ekibin pratik yan süreç yapılandırması aracılığıyla becerilerini geliştirmesine izin verdik. Bu yaklaşım, geçici güvenlik kontrollerinin, "güven istisnaları" olarak açıkça belgelenmiş olduğu sürece miras bileşenlerle bir arada var olabileceğini kabul etti ve belgelenmiş denetim kontrolleri ile telafi edici izleme kontrolleri sağladı. Karar, CORBA trafiğinin kod değişiklikleri olmaksızın Envoy proxy'leri üzerinden şeffaf bir şekilde tünellenebileceğini gösteren bir kavramsal kanıt ile doğrulandı.
Sonuç
Geçiş sırasında %99,995 kesintisizlik ile taşınma gerçekleştirilmiş, sağlık hizmeti ödeme işlemleri için katı SLA gereksinimlerini aşılmıştır. Istio telemetri, miras CORBA çağrılarının %30'unun gereksiz çapraz hizmet iletişimi olduğunu ortaya çıkarmış ve beklenmedik mimari basitleştirme ve gecikme iyileştirmeleri sağlamıştır. Geliştirme ekibi, teorik eğitim yerine pratik yan süreç yapılandırması deneyimi aracılığıyla dört ay içinde %90 kapsama ile Kubernetes güvenlik sertifikası almıştır. Organizasyon, geçici mimari ile ilgili sıfır bulgu ile HITRUST denetimini başarıyla geçmiştir ve tüm köprü bileşenleri, işlevsel gerileme veya güvenlik olayları olmadan zamanında devre dışı bırakılmıştır.
Sıfır güven geçişi sırasında paralel kimlik sistemlerini sürdürürken yetkilendirme mantığı kaymasını nasıl önlersiniz?
Adaylar genellikle belgeleri güncelleme veya miras ve modern ekipler arasında zorunlu senkronizasyon toplantıları önerirler, bu da operasyonel baskı altında sonuçlanır. Güçlü çözüm, Open Policy Agent (OPA) kullanarak Policy-as-Code uygulamayı gerektiriyor ve bu tek bir yetkilendirme kararları kaynağı oluşturmak için birleşik bir Rego politika deposu oluşturuyor. Bu sistem, hem modern SPIFFE kimlikleri aracılığıyla hem de dış veri paketleri aracılığıyla alınan miras AD grup üyeliklerini aynı politika mantığıyla değerlendirerek, kimlik düzlemleri arasında tutarlı izinler sağlamaktadır. Politika değişikliklerinin her iki kimlik yolu üzerinde otomatik entegrasyon testlerine yönelik tetiklediği bir GitOps boru hattı kurmak, izin kaymasının dakikalar içinde tespit edilmesini sağlar. Kritik içgörü, yetkilendirme mantığını tamamen uygulama kodundan soyutlamak ve bunu hem miras hem de modern yığınlar arasında denetlenebilir durumda kalan sürüm kontrol edilen yapılandırma verisi olarak işlemektir.
Sıfır güven uygulaması başarısını teknik olmayan denetim komitelerine kesin olarak kanıtlayan metrikler nelerdir?
Genç analistler genellikle şifreleme kapsam yüzdelerini veya sertifika döngü sürelerini belirtirler, bu da iş etkisi konusunda endişeli risk odaklı denetim komiteleri ile örtüşmez. Doğru metrik çerçevesi, mikro-segmentasyon yoluyla Ortalama İçerme Süresi (MTTC) yan hareketini nicelleştirmelidir. Bu, pod tehlikeye atıldığında simüle edilen kırmızı takım egzersizleri aracılığıyla ölçülmeli ve izolasyon hızını Istio ağ politikaları ile takip edilmelidir. Ayrıca, uygulamanın kapsayıcılık grafikleri kendisinden önce ve sonra karşılaştırarak Patlama Yüzeyi Azaltma izlemek, nicel saldırı yüzeyinin küçültülmesiyle somut risk azaltımını gösterir. Son olarak, Politika İhlali Giderme Hızını - konfigürasyon kaybının tespiti (örneğin, aşırı izinli bir NetworkPolicy) ve otomatik giderme arasındaki süre - kanıtlamak, operasyonel olgunluğu doğrular. Bu metrikler, teknik kontrolleri nicel iş riski azaltımına dönüştürerek hem teknik güvenlik ekiplerini hem de yönetişim odaklı yönetici paydaşlarını tatmin eder.
Java EE konteyner yönetikli kimlik doğrulaması olmadan dinamik sertifika döngüsüne katılamayan eski sabit hizmet hesaplarının keşfedilmesi durumunda nasıl başa çıkarsınız?
Bu, kitaplarda yer alan sıfır güven desenlerinin genellikle göz ardı ettiği, kimlik doğrulama modüllerinin yeniden yapılandırılmasının kritik iş mantığını destabilize edeceği "değişmez miras" kısıtlamasını temsil eder. Çözüm, eski IIOP/T3 trafiğini mTLS ile sarmak için Envoy yan süreçlerini TCP proxy modunda uygulamayı içerir. Bu, uygulamanın sertifikaları veya anahtar döngüsü yönetimini ele almasını gerektirmeden dışarıda bir SPIFFE kimliği sunar ve miras bileşene localhost üzerinden düz metin iletmek suretiyle, NIST şifreleme gerekliliklerini karşılayan değişmez kod etrafında bir "kriptografik balon" oluşturur. Aynı zamanda, veri tabanı sırları motorları ile HashiCorp Vault'u yeni veri tabanı bağlantıları için dinamik kimlik bilgilerini enjekte etmek amacıyla uygular; miras hizmet hesaplarını ise Istio yetkilendirme politikaları ve gelişmiş Falco çalışma zamanı izleme ile sıkı kontrol altında "yüksek riskli" iş yükleri olarak ele alır. Bu yaklaşım, bazı bileşenlerin değiştirilemeyeceğini, yalnızca sınırlı olabileceğini kabul eder ve gereksinimler bu "güven istisnalarını" açıkça belgelendirip telafi edici kontroller ve zorunlu deprecatio tarihleri ile kalıcı güvenlik borcunu önlemek için gerekli belgelerle desteklemelidir.