Yetenek

Koşullu Erişim Politika Motoru

Her erişim kararı tek motor üzerinden verilir. Kim girer, nasıl doğrulanır, neye ulaşır — tamamı denetlenebilir.

TR7, erişim politikasını statik kurallar yerine servis bazlı karar akışlarıyla yönetir. Her uygulama; hangi kullanıcıların erişebileceğini, hangi MFA faktörlerinin gerektiğini, hangi koşulda ek doğrulama isteneceğini ve ne zaman erişimin reddedileceğini kendi akışı içinde tanımlar. Aynı motor; login, MFA, lockout, SSO yönlendirmesi ve erişim kararlarını birlikte çalıştırır. Kullanıcı bilgisi, cihaz güveni, IP, lokasyon, istek header'ları, upstream sinyaller, servis hassasiyeti ve AAM değişkenleri aynı policy içinde değerlendirilebilir. Her karar adımı kayıt altındadır: hangi koşul çalıştı, hangi veri değerlendirildi, hangi dala gidildi ve hangi sonuç üretildi denetim log'una düşer. Sonuç: TR7'de erişim kararı dış bir policy servisine bırakılmaz. Kimlik doğrulama, MFA, yönlendirme ve koşullu erişim aynı yerel motor üzerinde çalışır; kurum her kararı görebilir, açıklayabilir ve denetleyebilir.

5
Switch pattern eşleşme modu
1
Auth, MFA, karar ve yönlendirme için motor
0
Kimlik doğrulama yolundaki harici policy servisi

Koşullu erişim, basit bir izin listesiyle yönetilemez

Modern erişim kararı artık yalnızca "kullanıcı adı doğru mu?" sorusundan ibaret değildir. Doğru karar; kullanıcının kimliğine, cihazın güven durumuna, lokasyona, zamana, erişilen servisin hassasiyetine, istenen MFA seviyesine ve oturum içindeki risk değişimlerine birlikte bakmalıdır.

Statik kurallar ve düz izin listeleri bu karmaşıklığı taşıyamaz. Zamanla her istisna yeni bir kural, her uygulama yeni bir özel durum, her risk sinyali ayrı bir kontrol noktası hâline gelir. Sonuç; kimsenin uçtan uca okuyamadığı, neden izin verdiği veya neden reddettiği denetimde açıkça anlatılamayan bir policy yığınıdır.

Bazı çözümler bu kararı ayrı bir policy bulutuna taşır. Bu da kimlik doğrulamanın en kritik anını dış bir API'ye bağımlı hâle getirir. Kimlik, MFA, servis yönlendirme ve denetim farklı sistemlere dağıldığında erişim yolu görünmezleşir; kurum sadece sonucu görür, kararın nasıl oluştuğunu değil.

Oysa koşullu erişim, kimliklerinizin ve servislerinizin yanında çalışan tek bir karar motoru olmalıdır. Her adım görünür, her koşul açıklanabilir, her karar denetlenebilir olmalıdır.

Çünkü erişim güvenliği yalnızca kimin girdiğiyle değil; hangi bağlamda, hangi güçte doğrulamayla ve hangi gerekçeyle izin verildiğiyle ilgilidir.

Yaklaşımımız

Kimlik doğrulama, MFA, kararlar ve yönlendirmeyi tek bir servis bazlı tanımda sahiplenen bir akış motoru.

Her servis kendi erişim akışını çalıştırır

Bir erişim akışı; login, MFA, karar noktaları, switch'ler, lockout yönetimi ve access-granted/denied terminal'lerini zincirler. Her servis kendi akışını bildirir; düşük riskli bir intranet uygulaması sade kalır, ayrıcalıklı bir yönetici yolu sıkı kalır — ikisini aynı şekle zorlamadan.

Herhangi bir değişken üzerinde pattern bazlı dallanma

Switch düğümleri akışın görebildiği herhangi bir değişken üzerinde yönlendirir — oturum özellikleri, istek header'ları, değerlendirilmiş şablonlar, edge'inizden gelen upstream sinyaller — beş eşleşme modu (exact, prefix, suffix, contains, regex) ve opsiyonel case-insensitive seçeneği ile. Kararlar pattern eşleşmesi olarak ifade edilir, script olarak değil.

Edge'den gelen sinyaller akışa dahil olur

Coğrafi konum, IP itibarı, risk skoru, ağ bölgesi — edge'inizin hesaplayabildiği her şey istek header'ı olarak enjekte edilip switch veya karar noktası tarafından okunabilir. Akış tek kaynak olarak kalır; gateway dışından gelen sinyaller, kimlik doğrulama yoluna harici bir servisi sokmadan akışı besler.

Her geçiş denetim log'undadır

Her eylem değerlendirmesi — hangi adım çalıştı, girdi neydi, hangi dal seçildi, hangi terminal'e ulaşıldı — yapılandırılmış bir denetim akışına düşer. Operatörler oturumları adım adım yeniden oynatır; güvenlik ekipleri erişim kararlarını SIEM streaming üzerinden telemetrinin geri kalanıyla ilişkilendirir.

Yetenekler

Akış motoru ayrıntıda, politika kurallarını oluşturan yapı taşları ve bunları genişletmek için planlanan eklemeler.

Akış motoru — auth, MFA, karar ve yönlendirme için tek zincir

Tek motor; login, çok faktörlü challenge, lockout yönetimi, karar noktaları, switch yönlendirmesi ve access-granted / access-denied terminal'lerini orkestre eder. Her adım açık geçişleri olan bir eylemdir; anonim istekten kimliği doğrulanmış oturuma giden yol, dağınık konfigürasyon yerine bileşik bir graf'tır.

Servis bazlı akış tanımı

Her servis kendi akış tanımını kaydeder. Bir SaaS proxy sadece SSO isteyebilir; bir iç uygulama TOTP ekleyebilir; bir production sistemi TOTP artı taze bir OTP artı açık bir karar noktası zincirleyebilir. Bir servisin policy'sini değiştirmek diğerlerini etkilemez.

Switch — pattern eşleşmesine göre çok yollu yönlendirme

Switch eylemi yapılandırılabilir bir değişkeni (header, oturum özelliği, AAM şablonu) değerlendirir ve akışı sıralı bir pattern listesi ile eşleştirerek hedef bir eyleme yönlendirir. Beş eşleşme modu — exact, prefix, suffix, contains, regex — opsiyonel case-insensitive ile birlikte; rol kontrolünden istek yolunda regex eşleşmesine kadar her şeyi kapsar.

Evet/hayır dallanması için karar noktaları

DecisionPoint eylemleri yapılandırılmış bir sinyalin var olup olmamasına göre akışı iki yola böler. Bugün sinyal, edge'iniz (CDN, upstream policy modülü veya ağ gateway'i) tarafından ayarlanan bir istek header'ıdır; eylem yüzeyi akış yapısını sabit tutar, alttaki koşul daha zengin ifadeleri değerlendirecek şekilde geliştirilir.

Koşullarda AAM şablon değişkenleri

Akış konfigürasyonuna gömülen değişkenler — kullanıcı kimliği, grup üyeliği, servis id'si, ortam, özel oturum özellikleri — değerlendirme anında AAM şablon motoru üzerinden çözümlenir. Branding, yönlendirme ve hata mesajlarında kullanılan aynı şablon sözdizimi policy kararlarını da sürükler; operatörler tek bir ikame dili öğrenir ve her yerde kullanır.

Akış tarafından sürülen step-up ve zincirlenmiş MFA

MFA aynı akışın içinde bir eylem olduğu için, koşullu erişim ikinci bir faktörü yalnızca belirli dallarda talep edebilir — örneğin switch admin rolünü tespit ettiğinde TOTP isteyebilir, ya da rota yüksek hassasiyetli bir terminal'e ulaştığında TOTP artı taze OTP zincirleyebilir. Yükseltme policy'de yaşar, kullanıcı algısında değil.

Roadmap — mantıksal operatörlü native koşul DSL'i

Tek bir policy'nin kimlik, grup, zaman, kaynak IP, coğrafi konum ve cihaz duruşunu tek okunabilir bir kurala — örneğin 'rol admin VE zaman mesai içinde VE coğrafi köken izin verilen listede VE cihaz güveni eşik üstü' diyen tek ifadeye — birleştirmesini sağlayan native bir ifade dili geliştirilmektedir. Aynı mantık bugün Switch ve DecisionPoint eylemlerini zincirleyerek elde edilebilir; DSL yaygın zincirleri tek ifadeye sıkıştırır.

Roadmap — yerleşik geo, zaman ve cihaz değerlendiricileri

IP-to-geo arama, zaman penceresi ve cihaz güven skoru (endpoint trust manager üzerinden) için native değerlendiriciler yol haritasındadır; böylece akışlar bu sinyallere upstream'in önce hesaplaması gerekmeden dallanabilir. Tercih ettiği bir geo veya IP itibar kaynağına zaten sahip ortamlar için header enjeksiyon yolu desteklenmeye devam eder.

Operasyonel derinlik

Policy değişikliklerinin güvenli dağıtılmasını ve kolay denetlenmesini sağlayan mekanik.

01

Girdi ve sonuçla adım bazlı denetim

Akıştaki her eylem değerlendirmesi yapılandırılmış bir denetim girdisi yazar — eylem id'si, eylem türü, girdi değişkenleri, seçilen dal, ulaşılan terminal, gecikme. Oturumlar dağınık log'lardan yeniden inşa edilmek yerine tek bir zaman çizelgesi görünümünde adım adım yeniden oynatılır.

02

Redis üzerinden koordine durumsuz akış yürütme

Akış durumu Redis'te yaşar; böylece herhangi bir gateway örneği herhangi bir oturumu herhangi bir adımda alabilir. Yatay ölçeklendirme ve sıfır kesintili rolling upgrade, devam eden kimlik doğrulama durumunu kaybetmez; operatörler bir yük dengeleyici arkasında birden fazla gateway pod'u koordinasyon yükü olmadan çalıştırabilir.

03

Akış boyunca koordineli kilitleme

Başarısız faktör denemeleri, reddedilen MFA challenge'lar ve access-denied terminal'leri platformun login-attack-protection katmanının kullandığı aynı kilitleme sayaçlarını besler. Bir kullanıcı, bir switch dalını paralel bir denemeyi farklı bir adımda beklerken, başarısız bir faktörü yeniden deneyerek brute-force edemez.

04

Sürümlü akış konfigürasyonu

Akış tanımları gateway'e teslim edilen JSON konfigürasyonunda yaşar; konfigürasyon değişiklikleri ortam başına aşamalı, gözden geçirilmiş ve dağıtılmış olabilir. Sürümlü konfigürasyon ile adım bazlı denetimin birleşimi 'bu kullanıcı dün neden içeri girdi?' sorusunu tek bir kaynaktan cevaplanabilir kılar.

05

Roadmap — görsel akış oluşturucu

Akış motoru için grafiksel bir editör geliştirilmektedir; operatörler erişim akışlarını görsel olarak oluşturup geçişleri doğrulayabilir ve JSON'ı elle düzenlemeden sentetik kullanıcılarla sonuçları önizleyebilir. Yayınlanana kadar akışlar sürümlü konfigürasyonda tanımlanır ve standart değişiklik kontrolüyle gözden geçirilir.

06

Roadmap — dry-run policy testi

Planlanan dry-run modu, gerçek kullanıcıları etkilemeden bir akıştan sentetik bir oturum geçirir; eylem-eylem izi ve nihai sonucu döndürür. Görsel oluşturucu ile birleştiğinde policy değişikliklerini kör production dağıtımları yerine test edilebilir artefaktlara dönüştürür.

Hangi senaryolarda kullanılır

Servis bazlı MFA dayatması

Kullanıcıyı kimlik doğrulayan aynı akış motoru, belirli bir servisin MFA gerektirip gerektirmediğine, hangi faktörün uygulanacağına ve güvenilir cihaz kısayolunun geçerli olup olmadığına karar verir. MFA policy ayrı bir ürün değildir — o servisin erişim akışındaki bir düğümdür.

Geo ve IP itibar farkındalıklı erişim

Edge bileşenleri (CDN, IP itibar feed'leri, ağ gateway'i) coğrafi ve itibar header'larını enjekte eder; akışın switch ve karar noktaları bu sinyallere göre dallanır — örneğin bilinen kötü amaçlı ağlardan girişleri reddeder veya yüksek riskli bölgeleri daha sıkı MFA zincirlerine yönlendirir.

Rol ve grup tabanlı dallanma

Kullanıcı rolüne veya grup üyeliğine göre yönlendiren switch düğümleri, erişim katmanlarını tek bir akışta oluşturur — yöneticiler daha sıkı MFA ile bir yoldan geçer, normal kullanıcılar sürtünmesiz bir yoldan geçer, yükleniciler zaman ve varlık listesine bağlı üçüncü bir yoldan geçer. Akış tek bir artefakt olarak denetlenebilir kalır.

Uyumluluk kapsamlı erişim yolları

PCI-DSS, HIPAA, KVKK, ISO 27001 kapsamlı servisler kendi daha sıkı akışlarını çalıştırır — zorunlu MFA, oturum başında zorunlu kayıt, güvenilir cihaz kısayolu yok. Denetçi, üst üste binen bir kural yığını yerine tek bir akış tanımı ve tek bir denetim akışı inceler.

Sık sorulanlar

Bir koşullu erişim policy'si bugün nasıl tanımlanır?
Policy'ler servis bazında sürümlü konfigürasyonda bir akış olarak tanımlanır — login, MFA, switch düğümleri, karar noktaları ve access-granted/denied terminal'leri, aralarında açık geçişlerle. Görsel akış oluşturucu yol haritasındadır; yayınlanana kadar operatörler akışları JSON'da oluşturur ve standart değişiklik kontrolüyle gözden geçirir.
Coğrafi konum, zaman ve cihaz duruşu gibi koşullar nasıl değerlendirilir?
Bugün bu sinyaller edge bileşenleri (CDN, IP itibar feed'i, endpoint trust gateway'i, ağ gateway'i) tarafından enjekte edilen istek header'ları olarak gelir ve akış içindeki Switch ile DecisionPoint eylemleri tarafından değerlendirilir. Geo, zaman penceresi ve cihaz güven skoru için native değerlendiriciler yol haritasındadır; böylece akışlar upstream'in önce hesaplaması gerekmeden bu sinyallere dallanabilir.
Switch (pattern eşleşmeli yönlendirme) regex destekliyor mu?
Evet. Switch beş eşleşme modunu destekler — exact, prefix, suffix, contains ve regex — non-regex modlar için opsiyonel case-insensitive ile. Switch tarafından değerlendirilen değişken; akışın görebildiği herhangi bir AAM şablonu, header veya oturum özelliği olabilir.
Her erişim kararı nasıl denetlenir?
Her eylem değerlendirmesi; eylem id'si, eylem türü, girdi değişkenleri, seçilen dal ve ulaşılan terminal'i içeren yapılandırılmış bir denetim girdisi yazar. Oturumlar bu tek zaman çizelgesinden adım adım yeniden oynatılabilir; denetim akışı platformun standart streaming hedefi üzerinden SIEM'inize yönlendirilebilir.
Bir policy değişikliği canlıya çıkmadan test edilebilir mi?
Bugün policy değişiklikleri sürümlü konfigürasyon ve aşamalı ortamlar üzerinden doğrulanır — diğer gateway konfigürasyonuna uygulayacağınız aynı değişiklik kontrol pratiği. Sentetik oturumları bir akıştan geçiren ve tam eylem-eylem izini ile sonucu döndüren bir dry-run modu yol haritasındadır ve planlanan görsel akış oluşturucu ile birlikte gelir.

Erişim politikanızı tek bir motora geri alın

Tek akış motoru, tek kaynak, tek denetim akışı — her servis, her adım, her karar için. Kendi uygulamalarınız üzerinde canlı bir kurulumda gezdirelim.