Yetenek

Backend TLS Inline İnceleme

Kurum servislerine şifreli giderken bile trafiği görünür, denetlenebilir ve kontrol edilebilir tutun.

TR7, istemci tarafındaki TLS oturumunu sonlandırdıktan sonra kurum servislerine giden trafiği yeniden şifreler; bu sırada WAAP denetimi, imza skorlama, yanıt gövdesi inceleme ve hassas veri maskeleme kontrollerini aynı güvenlik hattı içinde çalıştırır. Böylece "şifreli trafik" güvenlik kontrollerinin kör noktası hâline gelmez. AAM zincirin iki ucunda da kimlik doğrulaması yapabilir: istemci tarafında sertifika kontrolü, kurum servisi tarafında ise istemci sertifikası, özel CA doğrulaması, SNI, TLS sürüm sınırları ve şifre takımı politikaları ayrı ayrı yönetilir. Kurum servisleri kendinden imzalı sertifika, iç CA veya sertifika sabitleme seçenekleriyle güvenli şekilde doğrulanabilir. Sonuç: TR7, TLS'i sadece sonlandıran bir ara katman değil; şifreli trafik içinde güvenlik denetimini, veri sızıntısı kontrolünü, mTLS kimlik zincirini ve denetim telemetrisini bir arada yöneten kurumsal geçiş noktasıdır.

2
Yönlü TLS denetimi — ön taraf ve kurum servisi ayrı ayrı
2
Yönlü mTLS — istemci sertifikası ve kurum servisi sertifikası
20+
CEF kayıtlarında kurum servisi TLS telemetri alanı

Şifreli kurum servisi trafiği güvenlik kontrolünden kaçıyorsa, TLS güven değil körlük üretir.

Kurumsal mimarilerde TLS çoğu zaman "uçtan uca şifreleme" olarak anlatılır; fakat güvenlik denetimi açısından kritik soru şudur: Trafik şifreliyken WAAP, imza motoru ve veri sızıntısı kontrolleri gerçekten içeriği görebiliyor mu? Geleneksel yaklaşımlarda TLS ön tarafta sonlandırılır, kurum servisine giden trafik yeniden şifrelenir veya ham iletilir; ancak bu geçişte yanıt gövdesi ve hassas veri kontrolleri çoğu zaman devre dışı kalır.

Sıfır güven mimarisinde yalnızca istemcinin kimliği yeterli değildir. Kurum servisi tarafındaki sertifikanın da doğrulanması, doğru CA zinciriyle kontrol edilmesi ve gerektiğinde mTLS ile geçiş katmanının kendisini de kimliklendirmesi gerekir. Tek yönlü sertifika kontrolü, modern kurum içi servis trafiğinde eksik bir güven modeli oluşturur.

Yanıt gövdesi incelemesi ayrı bir zorluktur. Kart numarası, hasta kayıt numarası, kimlik verisi veya kurum içi hassas alanlar çoğu zaman uygulama yanıtında ortaya çıkar. Trafik yeniden şifrelendikten sonra güvenlik katmanı bu gövdeyi göremiyorsa, veri sızıntısı tespiti ve maskeleme sadece teorik bir özellik olarak kalır.

Özel CA dosyaları, sertifika zinciri doğrulaması, SNI, TLS 1.2/1.3 sınırları, ALPN ve şifre takımı politikaları elle yönetildiğinde operasyon karmaşıklaşır. Bir servis modern TLS isterken, başka bir geçiş dönemi servisi eski şifre takımlarına ihtiyaç duyabilir. Bu farklar merkezi politika olmadan yönetildiğinde güvenlik standardı servis bazında dağılır.

TR7'nin çözmesi gereken problem tam olarak budur: Kurum servisine şifreli giden trafiği güvenli bırakırken, güvenlik denetimini, mTLS kimliğini, hassas veri kontrolünü ve denetim kaydını kaybetmemek.

Yaklaşımımız

TR7, kurum servisi TLS hattını güvenlik denetimi, kimlik doğrulama ve politika kontrolüyle birlikte ele alır.

Yeniden şifreleme sırasında güvenlik denetimi kesintiye uğramaz

TR7, ön tarafta TLS'i sonlandırır, trafiği güvenlik hattından geçirir ve kurum servisine yeniden şifreleyerek iletir. Yanıt gövdesi inceleme, maskeleme ve değiştirme kuralları yeniden şifreleme öncesinde çalışır.

mTLS kimliği zincirin iki ucunda ayrı yönetilir

İstemci tarafındaki sertifika doğrulaması ile kurum servisi tarafındaki istemci sertifikası birbirinden bağımsız yapılandırılır. Bu sayede AAM, hem kullanıcı erişiminde hem de servis geçişinde güvenilir kimlik katmanı oluşturur.

Her servis havuzu kendi sertifika doğrulamasını alır

Kurum servisi sertifikası özel CA dosyasıyla doğrulanabilir ve gerekli durumlarda sertifika sabitleme seçeneğiyle güçlendirilebilir. SNI desteği, aynı altyapı üzerinde farklı servis kimliklerinin doğru şekilde ayrılmasına yardımcı olur.

TLS güvenlik profili servis bazında uygulanır

En düşük ve en yüksek TLS sürümü, şifre takımı politikası ve ALPN ayarları servis havuzu seviyesinde tanımlanır. Böylece modern servisler sıkı politikalarla, geçiş dönemindeki servisler ise kontrollü istisnalarla yönetilir.

Yetenekler

TR7, kurum servisi TLS hattını yalnızca bağlantı ayarı olarak değil, denetlenebilir bir güvenlik politikası olarak yapılandırır.

Kurum servisi TLS bağlantısı servis havuzu seviyesinde etkinleştirilir

`sslService: true` yapılandırmasıyla TR7, ilgili kurum servisi bağlantısını TLS üzerinden kurar. Bu yapılandırma, trafiğin iç ağa açık metinle taşınmasını engeller ve servis geçişini şifreli hâle getirir. Kurum, ön tarafta TLS sonlandırma yaparken servis tarafında yeniden şifreleme politikasını merkezi olarak yönetebilir.

Sertifika doğrulaması özel CA zinciriyle zorunlu hâle getirilebilir

`sslVerify: required` seçildiğinde TR7, kurum servisi sertifikasını özel CA dosyasıyla doğrular. Her servis havuzu için ayrı CA içeriği kullanılabilir; bu da iç CA, kendinden imzalı sertifika veya ayrılmış güven zinciri kullanan yapılarda esneklik sağlar. Doğrulama kapatılabilir olsa da kurumsal güvenlik için önerilen model zorunlu doğrulamadır.

Kurum servisi mTLS geçişi istemci sertifikasıyla kimlik kazanır

`sslClientCert` ve ilgili sertifika nesnesiyle TR7, kurum servisine bağlanırken istemci sertifikası sunabilir. Bu yapı, servisin yalnızca doğru geçiş katmanından gelen bağlantıları kabul etmesini sağlar. Özellikle AAM ile korunan uygulamalarda, kullanıcı erişimi ve servis geçişi aynı güven zincirinin iki ayrı halkası olarak yönetilir.

TLS sürüm sınırları güvenlik profili üzerinden belirlenir

`minSslVersion` ve `maxSslVersion` ayarlarıyla kurum servisi bağlantılarında TLS sürüm aralığı tanımlanır. Örneğin yalnızca TLS 1.2 ve TLS 1.3'e izin veren bir profil uygulanabilir. Bu yapılandırma, eski protokollerin kontrolsüz kullanılmasını engeller ve servis bazında uyumluluk geçişlerini daha güvenli hâle getirir.

Şifre takımı politikası hazır profil veya manuel listeyle uygulanır

`cipherAlgorithm` alanı hazır güvenlik profili veya manuel liste olarak yapılandırılabilir. Manuel modda `manualCipherAlgorithmList` kullanılarak izin verilen şifre takımları açıkça belirlenir. ECDHE tabanlı takımlar dahil olmak üzere kurumun güvenlik standardı servis bazında uygulanabilir.

Eski servisler için kontrollü geçiş şifre takımı tanımlanabilir

Geçiş dönemindeki eski kurum servisleri için düşük güvenlikli şifre takımı seçeneği kontrollü istisna olarak kullanılabilir. Bu seçenek kalıcı güvenlik modeli değil, modernleştirme sürecinde servis kesintisini önlemek için dikkatle yönetilmesi gereken bir uyumluluk köprüsüdür. Operasyon ekipleri böylece ön tarafta modern TLS politikasını korurken, eski servisleri planlı şekilde dönüştürebilir.

Yanıt gövdesi inceleme ve maskeleme yeniden şifreleme öncesinde çalışır

TR7, kurum servisinden gelen yanıtı yeniden kullanıcıya iletmeden önce gövde inceleme kurallarını çalıştırabilir. Maskeleme, değiştirme ve WAAP imza değerlendirmeleri şifreli geçiş hattının içinde kaybolmaz. Kart numarası, kayıt numarası veya hassas alanların uygulama yanıtında görünmesi durumunda güvenlik katmanı hâlâ müdahale edebilir.

İki yönlü TLS telemetrisi CEF kayıtlarında görünür hâle gelir

TR7, ön taraf ve kurum servisi tarafındaki TLS bilgilerini denetim kayıtlarına ayrı ayrı yazabilir. Şifre takımı, protokol, anahtar algoritması, sertifika konusu, sertifika veren kurum ve geçerlilik tarihleri gibi 20'den fazla TLS telemetri alanı izlenebilir. Bu görünürlük, olay analizi ve uyumluluk denetimlerinde şifreli zincirin kanıtlanmasını kolaylaştırır.

Operasyonel derinlik

Kurum servisi TLS incelemesi, günlük operasyonlarda sertifika yönetimi, denetim kaydı, istisna kontrolü ve kurtarma senaryolarıyla birlikte düşünülmelidir.

01

Servis bazlı CA yönetimi

Her servis havuzu kendi CA dosyasıyla doğrulama yapabilir. Bu, farklı iç CA zincirleri kullanan departmanlar veya izole vTenant yapıları için önemlidir. Sertifika yenileme süreçlerinde doğru CA içeriğinin doğru havuza bağlı kalması operasyonel hataları azaltır.

02

Sertifika sabitleme seçeneği

CA zinciri doğrulamasına ek olarak sertifika parmak izi sabitleme seçeneği kullanılabilir. Bu model, sertifika otoritesi güveninden daha sıkı bir servis kimliği kontrolü gerektiğinde faydalıdır. Özellikle kritik kurum servislerinde beklenmeyen sertifika değişimleri daha hızlı fark edilir.

03

Yanıt yakalama sınırları

Yanıt başlıkları ve gövde işleme için tanımlı yakalama alanları operasyonel görünürlük sağlar. Varsayılan 4.096 baytlık yakalama uzunluğu, log ve inceleme maliyetini sınırlarken temel denetim bilgisini korur. Daha geniş inceleme ihtiyacı olan senaryolarda kural kapsamı dikkatli tasarlanmalıdır.

04

Eski TLS istisnaları

Eski servisler için düşük güvenlikli şifre takımı seçeneği yalnızca geçiş dönemi ihtiyacı olarak ele alınmalıdır. Bu tür istisnalar ayrı politika, ayrı izleme ve net modernizasyon planıyla yönetilmelidir. Ön tarafta güçlü TLS standardı korunurken iç taraftaki teknik borç görünür hâle getirilir.

05

Denetim ve olay analizi

CEF kayıtlarında ön taraf ve kurum servisi tarafı TLS bilgileri ayrı ayrı izlenebilir. Protokol, şifre takımı, sertifika DN bilgileri ve geçerlilik tarihleri olay incelemelerinde bağlantının gerçek güvenlik durumunu gösterir. Bu kayıtlar, uyumluluk ekiplerinin "hangi servis hangi sertifikayla ve hangi TLS politikasıyla çalıştı" sorusuna cevap vermesini sağlar.

06

AAM ile kimlik zinciri

AAM, istemci tarafındaki erişim kimliğiyle kurum servisi tarafındaki mTLS kimliğini aynı geçiş mimarisinde birleştirebilir. Kullanıcı doğrulaması, uygulama erişimi ve servis kimliği birbirinden kopuk katmanlar olarak kalmaz. Bu yapı, sıfır güven mimarilerinde kimliğe dayalı geçiş kontrolünü güçlendirir.

Hangi senaryolarda kullanılır

Ödeme uygulamalarında kart verisi maskeleme

Finans ve ödeme sistemleri, internetten gelen trafiği AAM üzerinden doğrulayıp kurum servisine yeniden şifreli iletebilir. TR7, yanıt gövdesinde kart numarası benzeri alanları tespit edip maskeleyerek veri sızıntısı riskini azaltır.

Sağlık portallarında hasta verisi denetimi

Sağlık kurumları, portal yanıtlarında hasta kayıt numarası veya benzer hassas alanların görünmesini kontrol etmek isteyebilir. TR7, kurum servisine şifreli geçişi korurken yanıt gövdesi incelemesini sürdürebilir.

Sıfır güven servis geçiş mimarisi

Büyük kurumlar, yalnızca kullanıcıyı değil servis geçiş katmanını da sertifikayla kimliklendirmek ister. TR7, ön tarafta istemci doğrulaması ve kurum servisi tarafında mTLS ile iki yönlü güven zinciri kurar.

Uyumluluk denetimi için TLS kanıt zinciri

Denetim ekipleri, hangi protokolün, hangi şifre takımının ve hangi sertifikanın kullanıldığını kanıtlamak zorundadır. TR7, iki yönlü TLS telemetrisini CEF kayıtlarına taşıyarak şifreli trafiğin denetlenebilir olmasını sağlar.

Sık sorulanlar

TR7, kurum servisine giden trafiği yeniden şifrelerken WAAP denetimi gerçekten çalışıyor mu?
Evet. TR7, ön tarafta TLS'i sonlandırır, trafiği WAAP, imza skorlama ve yanıt gövdesi inceleme kurallarından geçirir; ardından kurum servisine yeniden şifreli olarak iletir. Maskeleme ve değiştirme kuralları yeniden şifreleme öncesinde çalıştığından güvenlik denetimi şifreli geçiş hattının kör noktasına düşmez.
mTLS yapılandırması ön taraf ve kurum servisi için ayrı ayrı mı yönetilir?
Evet. İstemci tarafındaki sertifika doğrulaması ile kurum servisi tarafındaki istemci sertifikası birbirinden bağımsız yapılandırılır. AAM, kullanıcı erişiminde sertifika kontrolü yaparken kurum servisine bağlanırken de istemci sertifikası sunabilir. Bu iki katman birbirini etkilemeden ayrı politikalarla yönetilir.
Her kurum servisi için farklı CA dosyası kullanılabilir mi?
Evet. Her servis havuzu kendi özel CA dosyasıyla yapılandırılabilir. Bu, farklı iç CA zincirleri kullanan departmanlar, izole vTenant yapıları veya kendinden imzalı sertifika kullanan servisler için önemlidir. Sertifika sabitleme seçeneğiyle CA zinciri doğrulaması daha da güçlendirilebilir.
TLS 1.3 ve ECDHE kurum servisi bağlantılarında destekleniyor mu?
Evet. `minSslVersion` ve `maxSslVersion` ayarlarıyla TLS 1.3 dahil sürüm aralığı tanımlanabilir. ECDHE tabanlı şifre takımları `cipherAlgorithm` veya `manualCipherAlgorithmList` alanlarıyla açıkça belirtilebilir. SNI desteği de aynı altyapı üzerinde farklı servis kimliklerinin doğru şekilde ayrılmasını sağlar.
CEF kayıtlarında hangi TLS telemetri bilgileri görünür?
Ön taraf ve kurum servisi tarafına ait TLS bilgileri ayrı ayrı kaydedilir. Şifre takımı, protokol, anahtar algoritması, sertifika konu DN, sertifika veren DN, ALPN, geçerlilik başlangıcı ve bitiş tarihleri dahil olmak üzere 20'den fazla telemetri alanı izlenebilir. Bu kayıtlar uyumluluk denetimlerinde şifreli zincirin kanıtlanmasını kolaylaştırır.
Geçiş dönemindeki eski servisler için eski şifre takımı kullanılması gerekiyorsa ne yapılır?
Eski kurum servisleri için düşük güvenlikli şifre takımı seçeneği kontrollü istisna olarak yapılandırılabilir. Bu seçenek kalıcı bir güvenlik modeli değildir; modernleştirme sürecinde servis kesintisini önlemek için ayrı politika ve izleme altında yönetilmelidir. Ön tarafta güçlü TLS standardı korunurken iç taraftaki teknik borç görünür hâle getirilir.

Kurum servislerinize giden TLS hattını denetlenebilir kılın

Yeniden şifreleme sırasında güvenlik denetimi, mTLS kimlik zinciri ve veri maskeleme bir arada. Kendi altyapınızda canlı bir kurulumda gezdirelim.