İşlevsel Kimlik Doğrulama ve Yetkilendirme Sistemlerinin Tasarlanması

Bu yazımızda kimlik doğrulama ve yetkilendirmeyi güvenli bir şekilde gerçekleştirebileceğiniz bir sistemden bahsedeceğiz. Başlamak için Kimlik Doğrulama ve Yetkilendirme arasındaki farkın ne olduğunu anlayalım.

• Kimlik doğrulama , bir uygulamaya erişirken kim olduğunuzu ve söylediğiniz kişiyi kanıtlama işlemidir.
• Yetkilendirme , erişim politikalarını, yani kimliğiniz doğrulandıktan sonra yapabileceklerinizi tanımlama ve uygulama sürecidir.

Bu yazıda şunları göreceğiz:

• Kimlik Doğrulama ve Yetkilendirme neden önemlidir?
• Kimlik Doğrulama nasıl çalışır?
• Yetkilendirme nasıl çalışır?
• Kimlik Doğrulama Sistemi Tasarımı
• Çözüm

Kimlik Doğrulama ve Yetkilendirme neden önemlidir?

Diyelim ki bir toplantıdayız ve konuşmayı siz yönetiyorsunuz. Bir şeyin güncellemelerini/durumunu doğru kişiye sormak için, kişiyi tanımlamanız (yani Kimlik Doğrulamanız ) gerekir. Bazı hassas verileri bir kişiyle paylaşmak için bile kişinin kimliğini doğru bir şekilde doğrulamanız gerekir. Kimlik doğrulamanın devreye girdiği yer burasıdır.

Şimdi diyelim ki aynı toplantıda birkaç karar alınması gerekiyor. Bu nedenle, bu kararları alma hakkına sahip olan kişilerin çağrıyı yanıtlayan kişi olması gerekir; herkesin her şeyi yapmasına izin veremeyiz. Açıkçası, bazı insanlar bazı kararları verecek kadar yeterli donanıma sahip değil ve bazıları da kesinlikle bundan en kötü şekilde yararlanmaya çalışacak. Bu, belirli kişilere belirli faaliyetler için hak izinleri veren Yetkilendirmeyi getirir.

Kimlik Doğrulama nasıl çalışır?

Bir kişinin kimliğini doğrulamak için her kişiye benzersiz bir ifade atayabiliriz ve kişiye bu ifadeyi ve adını doğru şekilde söylemesi sağlanır. Tamam diyebiliriz, kişinin kimliğini tespit ettik. Bu, olağan kullanıcı adları ve şifreler yaklaşımıdır. Doğru kimlik bilgileri verildiğinde sistem, kimliğin geçerli olduğunu kabul eder ve erişim izni verir. Bu, 1FA veya Tek faktörlü kimlik doğrulama (SFA) olarak bilinir.

SFA oldukça güvensiz kabul ediliyor. Neden? Çünkü kullanıcılar giriş bilgilerini güvende tutma konusunda oldukça kötüler. Çok faktörlü kimlik doğrulama (MFA), kullanıcıların kimliklerini birden fazla yolla kanıtlamalarını gerektiren daha güvenli bir alternatiftir. Bu tür yollardan bazıları şunlardır:

• Tek kullanımlık PIN numaraları / OTP
• Güvenli 3. taraflarca çalıştırılan kimlik doğrulama uygulamaları (ör. Google/Microsoft Authenticator)
• Biyometri

Kimliği doğrulandıktan sonra kişi, uygulamada özgürce eylemler gerçekleştirmeye devam edecektir. Uygulamanın, kişiyi yolculuk boyunca unutmadan tanıması bekleniyor. İdeal durumda, kullanıcıdan her farklı sayfaya geçiş yaptığında veya bir aktivite yaptığında şifreyi girmesini istemek çok fazla olacaktır. Bu nedenle, kullanıcının kimlik bilgilerini girdikten sonra ve bir kez kimlik doğrulaması yapıldıktan sonra kimliğini doğrulayacak bir yola ihtiyacımız var. Buna Oturum Yönetimi denir.

Kullanıcının kimliğini doğrulamanın 2 yolu:

• Oturum tabanlı kimlik doğrulama : Bir kullanıcı bir tarayıcı üzerinden bir web sitesinde oturum açtığında, sunucu o kullanıcı için bir oturum oluşturur ve bir oturum kimliği atar. Bu oturum kimliği sunucu tarafından referans olarak saklanır ve tarayıcıdaki bir çerezde saklanmak üzere kullanıcıya geri gönderilir. Artık kullanıcı her istekte bulunduğunda tarayıcı istekle birlikte oturum kimliğini de gönderecektir. Bu, isteğin doğrulanmasına yardımcı olacaktır. Ve böylece kullanıcı sitedeyken kimlik doğrulaması korunur.
• Token tabanlı kimlik doğrulama : Bunun için sunucu, kullanıcıya gönderilen ve yalnızca tarayıcı tarafından HttpOnly Cookies olarak kaydedilen şifrelenmiş bir token oluşturur. Kullanıcı bilgileri, izinler ve tokenın geçerlilik süresi gibi gerekli tüm bilgiler token içerisinde şifrelenir. Belirteç, sunucuya yapılan çağrılar için birlikte gönderilir. Sunucu, gizli anahtarla jetonun şifresini çözer ve kullanıcıyı doğrular. Bu jeton aralıklarla yenilenir.

Bu iki yaklaşım arasındaki temel fark, belirteç tabanlı kimlik doğrulamanın Durumsuz olması ve belirtecin sunucu tarafında saklanmasına gerek olmamasıdır. Ancak oturum tabanlı kimlik doğrulama için belirtecin sunucu tarafında da saklanması gerekir, bu da onu Durum Bilgili yapar. Bu da sistem ölçeklendiğinde veya kullanıcı sayısı arttığında komplikasyonları beraberinde getirir.

Belirteç tabanlı kimlik doğrulama için çoğunlukla JWT'leri (JSON Web Belirteçleri) kullanırız.

Yetkilendirme nasıl çalışır?

Kullanıcının kimliği doğrulandıktan sonra, yalnızca erişim iznine sahip olduğu kaynaklara erişmesine izin verildiğinden emin olmamız gerekir. Hassas verilere yetkisiz erişim felakete yol açabilir. En az ayrıcalık ilkesine göre şirketler genellikle erişim politikalarını, sizin için kesinlikle gerekli olan şeylere varsayılan olarak erişebileceğiniz şekilde ayarlarlar. Ve daha sonra buna doğru ek erişime sahip olursunuz. Erişimi bölümlere ayırmanın yaygın yolları şunlardır:

• Rol Tabanlı Erişim Kontrolü (RBAC) : Kullanıcılar, belirlenmiş izinlerle birlikte gelen belirli bir gruba/role atanır. Örnekler: yönetici, üye, sahip.
• Politika Tabanlı Erişim Kontrolü (PBAC) : Politikalara ve kurallara göre yetkilendirme sırasında erişim ayrıcalıklarını dinamik olarak belirler. Politikalar kullanıcı rollerine, iş fonksiyonlarına ve organizasyonel gereksinimlere dayanmaktadır.
• Nitelik Tabanlı Erişim Kontrolü (ABAC) : Kullanıcılara unvan, sertifika, eğitim gibi niteliklere ve/veya konum gibi çevresel faktörlere göre erişim izni verilir.
• Erişim Kontrol Listeleri (ACL'ler) : Her kullanıcı veya varlığın, telefonunuza yeni bir uygulama yüklemeye ve hangi izinleri vereceğine (konum hizmetleri, kişiler vb.) karar vermeye benzer şekilde açılıp kapatılabilen bireysel izinleri vardır.

ACL, ABAC veya RBAC'a göre sıklıkla ayrıntılı düzeyde kullanılır; örneğin, bireysel kullanıcılara belirli bir dosyaya erişim izni vermek için. ABAC ve RBAC genellikle şirket çapında politikalar olarak oluşturulmuştur.

Kimlik Doğrulama Sistemi Tasarımı

Gereksinimler

Öncelikle sistemin Fonksiyonel gereksinimlerini tanımlayarak başlayalım:

• Kayıt : Kullanıcıların gerekli bilgileri sağlayarak kayıt olmalarına izin verin.
• Giriş : Kullanıcıların kimlik bilgilerini temel alarak kimliklerini doğrulayın.
• Oturum Yönetimi : Güvenliği sağlamak için kullanıcı oturumlarını verimli bir şekilde yönetin.
• Şifre Kurtarma : Kullanıcıların şifrelerini kurtarmaları için güvenli bir süreç sağlayın.
• Erişim Kontrolü : Farklı kullanıcı türleri için rolleri ve izinleri tanımlayın.
• Denetim İzi : Denetim için kimlik doğrulama olaylarının ayrıntılı günlüklerini tutun.
• Performans : Düşük gecikme ve hızlı yanıt süreleri sağlayın.

Bu makale kapsamında dikkate almayacağımız birkaç işlevsel olmayan gereksinim şunlardır:

• Çok Faktörlü Kimlik Doğrulama (MFA) : Sağlam bir MFA sistemi uygulayın.
• Güvenlik : Şifreleme, güvenli depolama ve güvenli iletişim yoluyla veri güvenliğine öncelik verin.
• Ölçeklenebilirlik : Sistemi, artan sayıda kullanıcı ve işlemi yönetebilecek şekilde tasarlayın.
• Güvenilirlik : Sistemin kapalı kalma süresini en aza indirin ve yüksek kullanılabilirlik sağlayın.
• Kullanılabilirlik : Kusursuz bir deneyim için sezgisel bir kullanıcı arayüzü geliştirin.

Kapasite Tahmini

Trafik Tahmini

Öncelikle Trafik Tahmini ile başlayalım. Aylık ortalama 100.000 trafik olduğunu varsayıyoruz. Aylık 100.000 kullanıcı trafiğini tahmin ediyoruz. Bu da saniyede 0,04 istek anlamına gelir. Her talebe %90 oranında 500 ms içinde yanıt vermemiz gerekir, yani 500 ms'lik bir p90 gecikmesine ihtiyacımız var.

 assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04

Hizmet Seviyesi Hedefi (SLO) : 500 ms (kabul edilebilir maksimum gecikme süresi, sistemdeki yükten bağımsız) Hesaplamalarımıza göre 1 bulut sunucusunun alabileceği ortalama kapasite, bir isteğin karşılanması için yaklaşık 35 ms'dir; özel istek.

Yukarıdaki metrikleri kullanarak türetilmiş iki metrik daha oluşturalım.

• Kapasite : Örnek başına kabul edilebilir biriktirme listesi : Bir örnek tarafından SLO'dan ödün vermeden kabul edilebilecek maksimum istek (yük) sayısı.
• Talep : Örnek başına biriktirme listesi : Mevcut trafiğe bağlı olarak bir birime/örneğe akan isteklerin (yük) toplam sayısı.

Böylece,

 SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04

Mevcut talep ve kapasiteye göre gerekli toplam bulut sunucusu sayısını hesaplayalım.

 total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1

Böylece ayda 100 bin isteği, saniyede 0,04 istekle, 1 örnekle rahatlıkla halledebilecektik. Her birimin SLO'dan ödün vermeden saniyede 20 isteği işleyebildiği yer.

Depolama Tahmini

İdeal olarak, kimlik doğrulama ve yetkilendirme erişimi için her kullanıcının kullanıcı ayrıntılarını saklamamız gerekir. Varsayalım ki, 5kb /kullanıcı

 monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB

Yani her ay 500 yeni kullanıcıyı bünyemize katacağımızı varsayarsak 2 GB daha fazla depolama alanına ihtiyacımız olacak. Kimlik doğrulama günlüklerini tutmak istememiz durumunda. Her kimlik doğrulama isteğinin depolanmasının 2 kb sürmesi bekleniyor.

 auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB

Bu nedenle, aylık trafiğin 100 bin olduğunu varsayarsak, her ay ek 200 MB'a ihtiyacımız olacaktır.

Veri tabanı tasarımı

Artık kapasite tahminini yaptık. İşlevsel gereksinimleri desteklemek için gereken veritabanının şemalarını oluşturalım.

Hızlıca masaların üzerinden geçelim. 6 adet tablo kullanıyoruz.

1. Kullanıcılar - Tüm kullanıcı bilgilerini saklamak için
2. Kimlik bilgileri - Kullanıcı yetkilendirildikten sonra erişim/yenileme kimlik bilgilerini saklamak için.
3. Şifreler - Kullanıcının şifrelenmiş kullanıcı şifrelerini saklamak için.
4. PasswordRequests - Belirli bir kullanıcı için gelen şifre değiştirme isteklerini saklamak için.
5. Oturumlar - Kullanıcının ne zaman aktif bir oturumu olduğunu ve son etkinliğinin ne zaman olduğunu saklamak için.
6. ActivityApproval - Belirli bir kullanıcı tarafından gerçekleştirilen ve yönetici tarafından doğrulanacak bir etkinliğe ilişkin onay isteklerini depolamak için.

Kimlik Doğrulama Sistemi için Üst Düzey Tasarım

Sistem Uç Noktaları

Gereksinimlerin Yerine Getirilmesi

Şimdi her şey hazır olduğuna göre tüm gereksinimleri nasıl tamamlayabileceğimizi görelim.

Kayıt

• Gereksinim - Yeni bir kullanıcı uygulamamızı ziyaret ettiğinde. Kullanıcıyı bir sonraki ziyaretinde yetkilendirebilmemiz/tanımlayabilmemiz için kullanıcı ayrıntılarını saklamamız gerekir.
• Gerçekleştirildi - Yeni bir kullanıcı uygulamayı ziyaret ettiğinde ve e-posta adresi ve şifresiyle birlikte kullanıcı ayrıntılarını girdiğinde. Bu veritabanında yakalanacak. Kullanıcı ayrıntıları Kullanıcı tablosunda saklanacaktır. Ve şifre, kimlik bilgileri tablosunda şifrelenmiş bir biçimde saklanacaktır.

Giriş yapmak

• Gereksinim - Mevcut bir kullanıcı uygulamamızı ziyaret ettiğinde. Kullanıcının eylemlerini yetkilendirebilmemiz/tanımlayabilmemiz ve kendisine ait verileri gösterebilmemiz için kullanıcıyı tanımlamamız gerekir.
• Gerçekleştirildi - Mevcut bir kullanıcı uygulamayı ziyaret ettiğinde ve ayrıntılarını, e-posta adresini ve şifresini girdiğinde. Parolayı karma hale getiriyoruz ve karma değerini, Kimlik Bilgileri Tablosunda kullanıcı için saklanan karma değeriyle eşleştiriyoruz. Eşleşirse kullanıcıyı başarıyla tanımlayabilmişiz demektir. Aksi halde kayıt olurken girdikleri şifreyi doğru girmeleri gerekir. Bu işleme Kimlik Doğrulama adı verilir.

Oturum Yönetimi

• Gereksinim - Kullanıcı, kullanıcı ve parolasını girerek kimliğini doğruladığında. Gelecekteki işlemlerini gerçekleştirirken/hassas verileri görmeye çalışırken, şifrelerini tekrar tekrar girmelerine gerek kalmadan oturumlarının açık kalmasını sağlamalıyız.
• Yerine Getirildi - Kullanıcı başarıyla kimlik doğrulaması yaptığında. Kimlik Doğrulama sunucusu istemciyle 2 jetonu paylaşacaktır. Bir erişim_token ve bir yenileme_token . Access_token, şifrelenmiş verilere sahip olabilir ve güvenlik nedeniyle kısa bir son kullanma süresine sahiptir. İstemci erişim_tokenine sahip olduğunda, isteğin kimliğinin doğrulanmasına yardımcı olan her istekle birlikte erişim_tokenini de geri gönderir. Access_token'in süresi dolduğunda, istemcinin sağlanan yenileme_tokenini kullanarak yeni bir erişim_token istemesi gerekir. Bu, oturumun sürdürülmesine yardımcı olur.

Şifre kurtarma

• Gereksinim - Bir kullanıcı şifresini unuttuğunda şifresini güvenli bir şekilde sıfırlayabilmesi gerekir.
• Gerçekleştirildi - Kullanıcı şifresini unuttuğunda, e-posta adresini şifremi unuttum sayfasına gönderebilir; biz de tek seferlik bir kod oluşturup bağlantıyı e-postalarına göndereceğiz. Kullanıcı kodu ve e-posta adresini içeren bu bağlantıya tıkladığında. Şifre kurtarma isteğinin orijinal olduğunu güvenli bir şekilde tespit edebileceğiz. Ve kullanıcının yeni şifresini belirlemesini sağlayın. Ve böylece şifreyi kurtarabilmek.

Giriş kontrolu

• Gereksinim - Bir kullanıcı belirli bir eylemi gerçekleştirdiğinde, kullanıcının bu eylemi gerçekleştirmek için kimliğinin doğrulandığından emin olmamız ve ancak o zaman eylemin gerçekleşmesine izin vermemiz gerekir.
• Yerine getirildi - Basitlik açısından 1-12 arası eylem listesi tutacağız. Her kullanıcı için, o kullanıcıya yönelik kimliği doğrulanmış eylemleri sürdüreceğiz. Şimdi kullanıcının #id 4 eylemini gerçekleştirmeye çalıştığını varsayalım. Kullanıcının eylem 4'ü gerçekleştirme izinlerine sahip olup olmadığını kontrol edeceğiz. Evetse, devam edip isteği tamamlayacağız. Aksi halde izin eksikliği nedeniyle isteğin başarılı olmadığını gösteririz.

Denetim İzi

• Gereksinim - Bir güvenlik olayı olması durumunda, inceleyebilmek ve ne olabileceğine dair makul bir nedene/veya bunun olası nedeninin ne olabileceğine dair herhangi bir ipucuna sahip olmak için yeterli sayıda günlüğe sahip olabilmeliyiz.
• Gerçekleştirildi - Bu tür senaryolarda, sunucuda gerçekleşen her kimlik doğrulama eyleminin günlüklerini tutabiliriz. (A). Her oturum açma talebi için, kimlik doğrulamanın ne zaman gerçekleştiği, nereden geldiği, ips ve diğer ilgili ayrıntılara ilişkin bir günlük tutacağız. (B). Her şifre kurtarma isteği için, isteğin ne zaman başlatıldığı, nereden başlatıldığı, ips, isteğin tamamlanıp tamamlanmadığı ve diğer ilgili ayrıntılara ilişkin bir günlük tutacağız. (C). Ek olarak, bir kullanıcının bir eylem için yetkilendirildiği/yetkisiz olduğu her seferde ve kim tarafından günlükler tutacağız. Bu günlükler genel olarak bazı senaryoları anlamaya çalışmanız durumunda ne olabileceğini gösterebilmelidir.

Verim

• Gereksinim - Kapasite tahmini bölümünde tartışıldığı gibi performans gereksinimi, 0,04 istek/saniye ve ayda 100 bin istektir.
• Gerçekleştirildi - Kapasite tahmini bölümünde, gereksinimi yeterli sayıda sunucuyla zaten ele aldık.

Çözüm

Bu yazımızda Kimlik Doğrulama ile Yetkilendirme arasındaki farkın ne olduğunu anlayarak başladık. Daha sonra bir Kimlik Doğrulama ve Yetkilendirme Sistemi oluşturduk. Bu güvenlidir, emniyetlidir, endüstri standartlarını karşılarken ve istenen tüm gereksinimleri karşılarken performans sağlar. İleriye dönük olarak makalenin belirli bölümlerini güncelleyerek güncel kalmasını sağlayabilirim ve böyle bir sistemin oluşturulmasıyla ilgili daha fazla bilgi ve içgörüyü kapsayabilirim.