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.
Operasyonel derinlik
Policy değişikliklerinin güvenli dağıtılmasını ve kolay denetlenmesini sağlayan mekanik.
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.
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.
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.
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.
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?
Coğrafi konum, zaman ve cihaz duruşu gibi koşullar nasıl değerlendirilir?
Switch (pattern eşleşmeli yönlendirme) regex destekliyor mu?
Her erişim kararı nasıl denetlenir?
Bir policy değişikliği canlıya çıkmadan test edilebilir mi?
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.