İzin Kontrol Modellerinin Ölçeklenememesinin Ardındaki Gerçekler

Bir sabah uyandığınızda izin sistemi sadece iki ekip üyesinin açıklayabildiği bir karmaşaya dönüştüyseniz, artık sisteminizin artık daha fazla ölçeklenemediğini anlamışsınızdır. Bu durum çoğu zaman plansız eklemelerle ve "daha sonra temizleriz" ifadeleriyle ortaya çıkar. Ancak bu "sonra" asla gelmez. Bu, sistemlerin ölçeklenirken karşılaştığı sessiz varsayımlardan sadece biri.

15 rolden 340 role: Korku hikayesine doğru yavaş adımlar

Bir projede izin modelini oluştururken başlangıçta sadece 15 rol tanımlamıştık. Her rol net bir amaca sahipti ve sistemi yeni katılan birine on dakikada açıklayabiliyorduk. Bu sistemi inşa ederken oldukça gururlanmıştım. Ancak iki yıl sonra sistemde 340 rol vardı. Üç yüz kırk. Bu artış planlı değildi; kimse sabah uyandığında "Bugün sistemimize 340 rol lazım" demedi. Süreç şöyle gelişti:

• Bir ekip, belirli bir kaynağa erişim gerektirdiğinde yeni bir rol oluşturuldu.
• Bir yüklenici rolü, standart role çok benzer olsa da tek bir ek izne ihtiyaç duyduğunda yeni bir rol eklendi.
• Geçici olarak oluşturulan acil durum erişim rolü "ihtimal dahilinde" olarak kalmaya devam etti ve hiçbir zaman gözden geçirilmedi.

Her karar o an için mantıklıydı. Ancak kolektif olarak hiç kimsenin tam olarak açıklayamadığı, denetleyemediği ve güvenle yorumlayamadığı bir izin modeli ortaya çıktı. Bu duruma rol patlaması adı verilir. Bu bir disiplin eksikliği değildir; aksine sistemin tasarlandığı temiz durumdan çok daha karmaşık bir gerçekliğe itilmesiyle ortaya çıkan doğal bir sonuçtur.

Basit RBAC neden her zaman başarısız olur?

Rol tabanlı erişim kontrolü (RBAC), erişim kararlarının ikili olduğu durumlarda mükemmel çalışır: ya rolünüz vardır ya da yoktur. Bu model temiz, denetlenebilir ve anlaşılması kolaydır. Ancak gerçek dünya erişim kararları nadiren bu kadar basittir. Örneğin:

• Kullanıcının kendi kayıtlarına erişebilmesi ancak diğer kullanıcılarınkine erişememesi gerekebilir.
• Erişimin proje bittikten sonra sona ermesi gerekebilir.
• Karar, kimin erişim talebinde bulunduğundan çok kaynağın mevcut durumuna bağlı olabilir.

Bu gereksinimler ya daha fazla rol eklemeye (ki bu hızla yönetilemez hale gelir) ya da bağlam farkındalığına sahip daha zengin bir modele yönelmeye iter. Çoğu ekip, anlık ihtiyaçları karşılamak için daha fazla rol yolunu seçer. Bu yolu ben de tercih ettim. Muhtemelen siz de tercih etmişsinizdir. Ancak öznitelik tabanlı veya politika tabanlı erişim kontrolü, başlangıçta daha fazla çalışma gerektirse de uzun vadede çok daha az çaba harcanmasını sağlar. Ne yazık ki "Cuma'ya kadar teslim etmemiz lazım" ihtiyacı, "daha fazla çalışma gerektirecek" seçeneğinin neredeyse %100'ünde galip gelir.

10 dakikalık olay: Neden izinlerin önbelleğe alınması korkutucu?

İyi tasarlanmış bir izin modeli bile değerlendirilmek zorundadır ve ölçek büyüdükçe değerlendirme maliyeti önem kazanır. Bu noktada genellikle önbelleğe alma çözümüne başvurulur: izin kararlarını bir TTL (Time To Live) ile önbelleğe almak. Hızlı, ucuz ve uygulaması kolaydır. Ancak bu TTL penceresinde, izinlerin artık güncel olmayabileceği durumlarla karşılaşılır. Bu genellikle kabul edilebilir bir ödün olarak görülür. Ta ki durum öyle olmadığı ortaya çıkana kadar.

Geçmişte izin kararlarını on dakikalık bir TTL ile önbelleğe alan bir sistem üzerinde çalışıyorduk. Güvenlik ekibi acil durumlarda erişimi anında iptal etme ihtiyacını sorduğunda "On dakika kadar sürebilir" yanıtını vermiştik ve kabul edilmişti. Ardından bir kimlik bilgisi ihlal edildi ve güvenlik ekibi erişimi iptal etti. Ancak sistem sekiz dakika boyunca o kullanıcının taleplerini işlemeye devam etti. Sekiz dakika çoğu durumda uzun bir süre değildir. Ancak aktif bir olay sırasında gerçek zamanlı erişim kayıtlarını izleyerek, iptal edilen erişimin neden hala çalıştığını açıklamaya çalışmak oldukça farklı bir deneyimdir. Bu problemi nasıl çözdüğümü yorumlarda tahmin etmeye çalışın. Neyse ki o odanın atmosferini asla unutmadım. Artık izin önbelleklerinde TTL kullanmadan önce o odanın havasını düşünmeden edemiyorum. Bu ödün — önbellek TTL’si ile iptal hızı arasındaki denge — takımınız tarafından bilinçli olarak tartışılmış olsun ya da olmasın, zaten mevcuttur. Tek değişken, bunu bilinçli olarak mı yaptığınız yoksa bir olay sırasında mı keşfettiğinizdir.

Yüksek hacimde denetim kayıtları: Uyumluluktan daha fazlası

Her erişim kararının izlenebilir olması gerekir: kim talep etti, neye yetkiliydi, hangi karar alındı ve neden? Saniyede 100.000 karar verildiğinde, denetim kayıtları için önemli bir yazma hacmi ortaya çıkar. Eşzamanlı yazmalar gecikmeye neden olur. Eşzamansız yazmalar ise karar alındıktan sonra denetim kaydının kaybedilmesi riskini ortaya çıkarır — ki bu da hiçbir takımın karşılaşmak istemeyeceği bir uyumluluk konuşmasıdır. Ben bu konuşmayı yaşadım. Eğlenceli değildi. Sistemler üzerinde çalışırken "Önce kaydet, sonra çalıştır" gereksiniminin olduğu projelerde bulundum. Bu kısıtlama mimarinin tamamını yeniden şekillendirir: gecikme bütçesi, hata durumları, depolama tasarımı. Başından itibaren planlanması gereken bir durumdur. Var olan bir sisteme "önce kaydet, sonra çalıştır" mantığını eklemek pahalıdır ve nadiren temiz bir şekilde ilerler. Nasıl bildiğimi sormayın.

Erişim verme kolaydır. Revokasyon gerçek testi ortaya koyar.

Erişim verme basittir. Veritabanında bir satır oluşturun, tamamdır. Revokasyon ise tasarım kalitesinin asıl sınandığı yerdir. Erişim, önbellekler, replikalar ve izinlerin kopyasını yüklemiş uzun süren işlemler de dahil olmak üzere her yerden iptal edilmelidir. Revokasyona başlamadan önce çalışmaya başlayan ve bir saat sonra hala çalışmaya devam eden bir toplu işlem — teknik olarak her kontrol anında geçerliydi. Ancak toplu davranış yanlıştır. Bu boşluğu bir uyumluluk ekibine açıklamak istemezsiniz. "Teknik olarak her kontrol anında geçerliydi..." açıklaması umduğunuz etkiyi yaratmayacaktır.

Revokasyonun gerçekten çalışmasını sağlamak, sisteminizde "anında" ne anlama geldiğine dair açık bir karar vermek ve bunu destekleyecek altyapıyı inşa etmek anlamına gelir. Bunun kendiliğinden düzeleceğini varsaymamalısınız. Düzeltmeyecektir.

Bugün sistemlerimizi tasarlarken rol patlaması, önbellek TTL’leri ve revokasyon stratejilerini baştan ele almak zorundayız. Aksi takdirde, sistemler ölçeklendikçe izin karmaşası da büyümeye devam eder. Gelecek projelerinizde bu konuları erken aşamada ele almanız, hem güvenlik hem de teknik borç açısından uzun vadede size kazanç sağlayacaktır.