SaaS Uygulamalarında Yetkilendirme ve Erişim Kontrolü Rehberi

Bulut Yazılımlarında Yetkilendirmenin Önemi

Bulut yazılımlarında kullanıcılar tek bir merkezi veritabanını ortaklaşa kullanır. Çünkü SaaS şirketleri maliyetleri düşürmek için kaynakları paylaşımlı olarak sunar. Bir kullanıcının diğer müşterilerin verilerine erişmesi felaketle sonuçlanır. Dolayısıyla SaaS uygulamalarında yetkilendirme mimarisi veri gizliliğinin en temel garantisidir.

Ayrıca kurumsal müşteriler kendi iç hiyerarşilerini bulut platformuna yansıtmak ister. Zira bir şirketin finans müdürü ile stajyeri aynı verilere erişmemelidir. İnce taneli yetkilendirme kurumsal satışların tamamlanmasında ana belirleyicidir. Bu nedenle SaaS uygulamalarında yetkilendirme altyapısı doğrudan ticari büyümeyi destekler.

Hukuki düzenlemeler veri sorumlularına erişim kayıtlarını tutma zorunluluğu getirir. Nitekim KVKK ve SOC 2 standartları en az yetki prensibini şart koşar. Yöneticiler çalışanlara yalnızca işlerini yapacakları kadar yetki vermelidir. Sonuç olarak SaaS uygulamalarında yetkilendirme kuralları yasal yaptırımların önüne geçer.

Temel Yetkilendirme Modelleri

SaaS platformlarında erişim kontrolü farklı yaklaşımlarla kurgulanır. Çünkü yazılımın karmaşıklığı ve kullanıcı sayısı uygun mimariyi doğrudan belirler. Ekiplerin bu modelleri tanıması doğru tercihler yapmasını sağlar.

Kimlik Doğrulama ile Yetkilendirmenin Ayrımı

Kimlik doğrulama kullanıcının platforma giriş anahtarıdır. Örneğin kullanıcı şifresini girer ve kimliğini ispatlar. Ancak yetkilendirme kullanıcının hangi odaya gireceğini belirler. Geliştiricilerin bu iki kavramı birbirine karıştırması büyük mantık hataları doğurur.

Saldırganlar geçerli bir oturum açtıktan sonra diğer uç noktaları tarar. Zira sistem yetki kontrolünü eksik yaparsa saldırganlar başkalarının kaynaklarını rahatlıkla siler. Dolayısıyla SaaS uygulamalarında yetkilendirme her istek anında bağımsız olarak çalışmalıdır.

Rol Tabanlı Erişim Kontrolü

Rol tabanlı erişim modeli sektörde en yaygın tercihtir. Çünkü bu yöntemi kurgulamak ve yönetmek geliştiricilere büyük kolaylık sağlar. Bu modelde izinleri doğrudan kullanıcılara değil, rollere tanımlarlar. Kullanıcıları ise bir veya daha fazla role atarlar.

Tipik bir SaaS uygulamasında yönetici, editör ve görüntüleyici rolleri yer alır. Fakat platform büyüdükçe roller yetersiz kalmaya başlar. Şirketler her özel talep için yeni roller türetir. Bu duruma sektörde rol patlaması adı verilir.

Ekipler rol karmaşasını önlemek adına hiyerarşik RBAC yapıları kurar:

• Temel İzin Tanımları: İzinleri atomik parçalara bölerek tanımlamak (`invoice:read`, `invoice:delete`).
• Rol Matrisi: Her rolün hangi izin paketlerine sahip olduğunu net tablolarla belirlemek.
• Hiyerarşik Kalıtım: Üst rollerin alt rollerin yetkilerini otomatik devralmasını sağlamak.
• Kiracıya Özel Roller: Kurumsal müşterilerin kendi özel rollerini oluşturmasına izin vermek.

Rollerin iyi planlanması sistem performansını artırır. Ancak statik roller dinamik senaryolarda çaresiz kalabilir. Özellikle mesai saatleri dışındaki erişimleri kısıtlamak RBAC ile zordur. Bu nedenle SaaS uygulamalarında yetkilendirme adımları zamanla daha esnek modellere kayar.

Öznitelik Tabanlı Erişim Kontrolü

Öznitelik tabanlı model erişim kararlarını anlık değişkenlere göre verir. Çünkü yalnızca kullanıcının kim olduğu değil, şartların ne olduğu da önemlidir. Sistem kullanıcı özelliklerini, kaynak özelliklerini ve ortam şartlarını birlikte değerlendirir.

Örneğin bir hekim hasta kayıtlarını görebilir. Fakat ABAC ile bu kuralı yalnızca hekimin nöbetçi olduğu saatlerle sınırlandırırlar. Benzer şekilde kullanıcının coğrafi konumu ve IP adresi de kararı etkiler. Bu esneklik üst düzey güvenlik sağlar.

Mühendisler ABAC modelinde şu dört temel öznitelik grubunu kullanır:

1. Özne Öznitelikleri: Kullanıcının departmanı, unvanı, kıdemi ve güvenlik yetki düzeyi.
2. Kaynak Öznitelikleri: Dosyanın gizlilik derecesi, oluşturulma tarihi ve ait olduğu proje.
3. Eylem Öznitelikleri: Yapılmak istenen okuma, yazma, onaylama veya silme işlemi.
4. Çevre Öznitelikleri: Giriş yapılan saat, cihaz türü ve ağın güvenlik durumu.

Yazılımcılar ABAC kurallarını dinamik mantıksal ifadelerle yazar. Örneğin sistem `kullanıcı finans birimindeyse ve mesai saatindeyse izin ver` kuralını çalıştırır. Nitekim SaaS uygulamalarında yetkilendirme bu yaklaşımla kurumsal ihtiyaçlara tam uyum sağlar.

İlişki Tabanlı Erişim Kontrolü (ReBAC)

Google mühendislerinin geliştirdiği Zanzibar mimarisi ReBAC modeline öncülük eder. Çünkü modern SaaS ürünlerinde veriler birbirine grafik ağlarıyla bağlanır. Bir kullanıcının bir belgeye erişimi diğer nesnelerle olan ilişkisine dayanır.

Google Drive veya Notion gibi platformlar bu mantıkla çalışır. Kullanıcı bir klasörün üyesiyse o klasör içindeki tüm dokümanları otomatik okur. Sistem ilişkileri hiyerarşik zincirler halinde birbirine aktarır. Bu model izin yönetimini kullanıcılar için oldukça sezgisel kılar.

ReBAC sistemleri nesne ilişkilerini grafik veritabanlarında saklar. Örneğin sistem `Kullanıcı A, Proje B üyesidir` ilişkisini tutar. Yöneticiler `Proje B, Belge C sahibidir` ilişkisini eklediğinde erişim otomatik çözülür. Dolayısıyla SaaS uygulamalarında yetkilendirme süreçleri karmaşık ekipleri zahmetsizce yönetir.

Çok Kiracılı Yapılarda Veri Ayrımı

Çok kiracılı yazılımlarda veri sızıntılarını önlemek yazılımcının en büyük sınavıdır. Çünkü tek bir dikkatsizlik tüm veritabanını dışarı sızdırabilir. BOLA ve IDOR açıkları bu ihmallerden beslenir. Geliştiriciler veri tabanı katmanında tavizsiz bariyerler kurmalıdır.

Veri tabanı motorları bu izolasyonu sağlamak için özel yetenekler sunar. PostgreSQL üzerindeki Satır Düzeyi Güvenlik mekanizması harika bir kalkan oluşturur. Geliştiriciler her tablodaki satıra kiracı kimliği damgalar. Veritabanı motoru oturum kimliği eşleşmeyen satırları sorgu sonuçlarına asla eklemez.

Teknik ekipler çok kiracılı güvenliği korumak için şu kuralları işletir:

• Otomatik Kiracı Filtreleme: ORM katmanında tüm sorgulara otomatik kiracı filtresi eklemek.
• Veritabanı Şeması Ayrımı: Bütçesi yüksek kurumsal müşterilere tamamen bağımsız şemalar tahsis etmek.
• Önbellek İzolasyonu: Redis üzerindeki tüm anahtarları kiracı ön ekiyle saklamak.
• Bağlam Doğrulama: API isteklerindeki kiracı kimliği ile istenen nesneyi karşılaştırmak.

Yalnızca uygulama koduna güvenmek yeterli koruma sağlamaz. Zira yazılımcı bir sorguda filtre koşulunu yazmayı unutabilir. Bu nedenle SaaS uygulamalarında yetkilendirme kurallarını doğrudan veritabanı motoruna emanet etmek gerekir.

Platformlarının kiracı izolasyonunu denetletmek isteyen bulut şirketleri, kapsamlı sızma testi hizmetleri ile mantıksal yetki kaçaklarını erkenden kapatır.

Merkezi Yetkilendirme Motorları

Yetki kodlarını uygulama içine dağıtmak büyük bir teknik borç doğurur. Çünkü basit koşul kontrolleri binlerce satır koda yayılır. Bir kural değiştiğinde ekipler tüm uygulamayı baştan derlemek zorunda kalır. Bu sorunu çözmek için Politika Tabanlı Erişim yaklaşımını kullanırlar.

Ekipler erişim kararlarını uygulama dışındaki bağımsız bir yetki motoruna devreder. Uygulama yalnızca kullanıcının eylem iznini sorgular. Yetki motoru kuralları değerlendirir ve onay ya da ret yanıtı döner. Open Policy Agent bu alanda en popüler açık kaynak çözümdür.

Merkezi motorlar güvenlik yönetimini standart hale getirir. Güvenlik yöneticileri yetki kurallarını koddan bağımsız günceller. Ayrıca sistem tüm erişim kararlarını merkezi olarak kaydeder. Böylece SaaS uygulamalarında yetkilendirme denetimlerini kolayca raporlarlar.

Erişim altyapısını güçlendirmek isteyen şirketler, Sibertim bulut siber güvenlik danışmanlığı alarak yetkilendirme mimarilerini uluslararası standartlara kavuşturur.

Kurumsal Erişim Savunma Yol Haritası

Yetkilendirme mimarisini kurmak sürekli bakım gerektiren bir süreçtir. Şirketler ürünlerini geliştirirken güvenlik modellerini de büyütmelidir. Sağlam bir altyapı inşa etmek için aşağıdaki adımları izlemek gerekir:

• En Az Yetki Prensibi: Kullanıcılara ve servislere yalnızca ihtiyaç duydukları asgari izinleri tanımlamak.
• Düzenli Erişim İncelemeleri: Ayrılan personelin veya iptal edilen aboneliklerin yetkilerini anında silmek.
• Merkezi Loglama: Reddedilen tüm erişim denemelerini SIEM sistemlerine aktararak izlemek.
• Otomatik Yetki Testleri: Birim testlerine BOLA ve yetki aşımı senaryolarını eklemek.
• Bağımsız Denetimler: Yılda en az iki kez dışarıdan uzman ekiplere mantıksal yetki testleri yaptırmak.

Sık Sorulan Sorular