Üç rol bir erişim modeli değildir.
Birçok uygulama sunum platformu kısa bir rol listesi verir — yönetici, operatör, salt okunur — ve bu listeye sığmayan herkes yönetici olur. Sertifika ekibi tam trafik yetkisi alır, çünkü sertifikalar trafiğin altında durur. İzleme entegrasyonu yönetici jetonu alır, çünkü verilecek daha küçük bir jeton yoktur. Ağ ekibi WAF politikasını düzenleyebilir, çünkü ağ ile güvenlik tek rolü paylaşır.
Sonuç öngörülebilir: denetim "bu değişikliği kim yapmış olabilir" diye sorar ve dürüst cevap "konsolun büyük kısmı" olur. Görev ayrılığı organizasyon şemasında vardır, üründe yoktur.
İkinci arıza yüzey kaymasıdır. Arayüzde uygulanan ama API'de uygulanmayan bir izin, izin değil temennidir. API'ye ulaşabilen herkes, arayüzün reddettiği şeyi yapabilir.
Yaklaşımımız
Rol işi adlandırır. Kapsam etki alanını adlandırır. İkisi de her yüzeyde uygulanır.
Üç değil, on altı rol
Roller, ekiplerin gerçekte bölündüğü hatlardan kesilmiştir: trafik, WAF, ağ, GTM, sertifika ve izleme; bu ayrımın önemli olduğu yerlerde yönetici ve kullanıcı varyantlarıyla. Ayrıca dokunmadan görmesi gerekenler için salt okunur ve yalnız ön yüz rolleri vardır.
Rolün üstüne kapsam
Rol, kullanıcının hangi tür nesneye dokunabileceğini söyler. Kapsam hangilerine dokunabileceğini söyler: izin verilen ön yüz IP'leri, izin verilen arka uç ağları, atanmış vService'ler ve atanmış vDevice'lar. İki Trafik Yöneticisi tek cihazda iki farklı yapıyı, birbirinin servislerini görmeden yönetebilir.
Arayüz, CLI ve API'de tek izin modeli
Etkileşimli CLI arayüzle aynı rolü uygular — Ağ Yöneticisi ağ komutlarını görür, başkasını görmez — ve REST erişimi aynı modelle alan alan denetlenir. Kalıcı API jetonları role bağlıdır; bir hat jetonu hattın haklarını taşır, yöneticinin haklarını değil.
Her yüzey aynı denetim izine yazar
Tıklayarak, komutla veya API çağrısıyla yapılan değişiklik tek bir denetim izine, kayıpsız öncesi/sonrası farklarıyla düşer. Denetçinin sorduğu soru — bunu kim, nereden değiştirdi ve öncesi neydi — değişikliğin nasıl yapıldığından bağımsız olarak tek cevaba sahiptir.
Yetenekler
Rol modelinin kapsadığı şeyler ve üzerine eklenenler.
On altı adlandırılmış yönetici rolü
Tam liste: Admin (süper yönetici) · Trafik Yöneticisi · Trafik Kullanıcısı · Trafik+WAF Yöneticisi · Trafik+WAF Kullanıcısı · WAF Yöneticisi · WAF Kullanıcısı · WAF Salt Okunur · Ağ Yöneticisi · Ağ Kullanıcısı · GTM Kullanıcısı · Sertifika Yöneticisi · İzleme Kullanıcısı · Salt Okunur Kullanıcı · Ön Yüz Kullanıcısı · İstemci (bulut istemcisi). Yönetici ve kullanıcı varyantları, yapılandırma hakkını işletme hakkından ayırır.
Ağ kapsamı — izin verilen ön yüz IP'leri ve arka uç ağları
Kullanıcının erişimi yalnız nesne türüyle değil, adresle de sınırlanır. Yayın yapabileceği ön yüz adresleri ve yönlendirebileceği arka uç ağları kullanıcı bazında listelenir; böylece bir hata, kullanıcının sorumlu olduğu segmentin içinde kalır.
Kaynak kapsamı — atanmış vService ve vDevice
Kullanıcılara sahip oldukları belirli yayınlanmış servisler ve belirli vDevice'lar atanır. Geri kalanı onlar için salt okunur değildir; görünmez.
Sertifika hakları: yönetim ile seçim ayrı
Bir servise sertifika seçme hakkı ile sertifika kütüphanesini yönetme hakkı ayrı haklardır. Uygulama ekibi doğru sertifikayla servis yayınlayabilir ama arkasındaki anahtarı dışa aktaramaz, değiştiremez, silemez.
Kabuk erişimi kullanıcı bazında anahtar
SSH üzerinden CLI ile tarayıcıdaki CLI iki bağımsız anahtardır; her birinin azami oturum sayısı vardır. Bir operatöre, hiçbir yerde SSH hesabı açılmadan tarayıcı konsolu verilebilir.
Kullanıcı bazında kota: bant genişliği, CPU ve bağlantı
Bir rol yalnız izin kümesi değil, kaynak tavanı da taşıyabilir; böylece bir kiracı yöneticisi cihazı herkesin adına tüketemez.
Alan düzeyinde API yetkilendirme
REST erişimi arayüzdeki modelle aynı şekilde alan alan ve bölge bölge denetlenir. Konsolda bir alanı göremeyen rol, o alanı API'den de okuyamaz.
Dizin tabanlı yöneticiler ve güçlü kimlik doğrulama
Yöneticiler yerel hesaplara, LDAP ve Active Directory'ye, RADIUS'a veya muhasebe kaydı tutan TACACS+'a karşı doğrulanır. SMS ve e-posta tek kullanımlık kodla iki faktör, kurtarma jetonları ve TR7'nin kendi iç PKI'sinin verdiği sertifikalarla mTLS yönetici girişi mevcuttur.
Çalışma alanı tercihleri kullanıcıyla birlikte gelir
Dil, tema ve başlık çubuğu düzeni kullanıcı bazında saklanır; operatörün konsolu kümenin hangi düğümüne düşerse düşsün aynı görünür.
İşletme derinliği
Bir erişim modelinin denetimden geçip geçmeyeceğini belirleyen kısımlar.
Görev ayrılığı, vaat değil ifade
WAF, trafik, ağ, GTM ve sertifika ayrı rol aileleri olduğu için, düzenlenmiş sektörlerin klasik şartı — güvenlik politikasını değiştiren kişi trafik yolunu değiştiren kişi olmasın — birinin hatırlaması gereken bir prosedür değil, bir yapılandırmadır.
Gerçekten salt okunur olan salt okunur roller
Salt Okunur Kullanıcı, WAF Salt Okunur ve İzleme Kullanıcısı, denetçilerin, NOC ekibinin ve panoların bir şeyi değiştirebilecek role ihtiyaç duymaması için vardır. İzleme entegrasyonuna yönetici jetonu değil, bunlardan birine bağlı jeton verilir.
Devredilmiş erişim için Ön Yüz Kullanıcısı ve İstemci rolleri
Ön Yüz Kullanıcısı, altındaki platforma dokunmadan yayınlanmış servislerle çalışanları kapsar. İstemci ise bulut istemcisi durumunu kapsar: hesap, servisi işleten değil tüketen tarafa aittir.
Yönetim düzleminde kaba kuvvet savunması
Parola karmaşıklığı zorunlu tutulur; başarısız girişler IP başına ve IP+kullanıcı adı başına, süresi dolan bütçelerle kısılır ve yerleşik CAPTCHA ile desteklenir. Yönetim düzlemi bir saldırı yüzeyi gibi ele alınır, çünkü öyledir.
Yönetim servisleri tek tek bağlanır ve kapsanır
HTTPS, SSH, FTP ve SNMP seçilen adres ve porta bağlanır; her biri kendi izinli ağ listesini (CIDR), kendi sertifikasını ve kendi asgari-azami TLS sürümünü taşır. Konsol TLS 1.3 zorunlu tutarken, henüz onu konuşamayan bir izleme entegrasyonu farklı bir servise TLS 1.2 ile ulaşabilir.
Amaca göre ayrılmış dosya aktarım hesapları
Dosya aktarımı tek ortak hesap üzerinden yürümez. Log dışa aktarımı, yapılandırma yedeği, çevrimdışı IP-istihbarat teslimi ve çevrimdışı güncelleme paketleri için ayrı hesaplar vardır ve her biri yalnız kendi dizinini görür — hava boşluklu işletimi ayrıcalıklı hesap açmadan uygulanabilir kılan budur.
Ne zaman kullanılır
Düzenlemeye tabi görev ayrılığı
Bir bankada WAF politikasının sahibi ile trafiğin sahibi farklı kişiler olmalı ve bu kanıtlanabilmelidir. WAF Yöneticisi ile Trafik Yöneticisi ayrı denetim izlerine sahip ayrı rollerdir; kanıt bir görüşme değil, bir rapordur.
Kendi servisini yayınlayan uygulama ekipleri
Her ekibe, kendi vService'leri ve kendi arka uç ağlarıyla kapsanmış bir Trafik Kullanıcısı rolü verilir. Ekipler değişiklik talebi açmadan yayın yapar ve işletir, başka ekibin servisine erişemez.
Hat ve izleme jetonları
CI/CD hattı dar bir role bağlı kalıcı API jetonu alır, izleme sistemi İzleme Kullanıcısı'na bağlı bir jeton alır. Hiçbiri yönetici hakkı taşımaz; sızan bir jeton sınırlı bir olaydır.
Trafiğin sahibi olmayan sertifika ekibi
Sertifika Yöneticisi anahtar kütüphanesini ve yenilemeleri yönetir; uygulama ekipleri oradan seçer. Özel anahtarın, servisi yayınlayan ekibe teslim edilmesi gerekmez.
Sık sorulan sorular
TR7 kaç yönetici rolüyle geliyor?
CLI arayüzle aynı izinlere tabi mi?
İki yönetici tek cihazda birbirini görmeden farklı servisleri yönetebilir mi?
Bir API jetonu yöneticiden daha az yetkiyle sınırlanabilir mi?
RBAC ek lisans gerektiriyor mu?
Yöneticiler nasıl kimlik doğruluyor?
On altı rol, kullanıcı bazında kapsam, her yüzeyde uygulama
Rol modelini kendi görev ayrılığı şartlarınızla birlikte adım adım gözden geçirelim.