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. , bir uygulamaya erişirken kim olduğunuzu ve söylediğiniz kişiyi kanıtlama işlemidir. Kimlik doğrulama , erişim politikalarını, yani kimliğiniz doğrulandıktan sonra yapabileceklerinizi tanımlama ve uygulama sürecidir. Yetkilendirme 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 ) 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. Kimlik Doğrulamanız Ş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 getirir. Yetkilendirmeyi 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 (SFA) olarak bilinir. Tek faktörlü kimlik doğrulama 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 denir. Oturum Yönetimi Kullanıcının kimliğini doğrulamanın 2 yolu: : 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. Oturum 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. Token tabanlı kimlik doğrulama Bu iki yaklaşım arasındaki temel fark, belirteç tabanlı kimlik doğrulamanın 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 yapar. Bu da sistem ölçeklendiğinde veya kullanıcı sayısı arttığında komplikasyonları beraberinde getirir. Durumsuz Durum Bilgili 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: : Kullanıcılar, belirlenmiş izinlerle birlikte gelen belirli bir gruba/role atanır. Örnekler: yönetici, üye, sahip. Rol Tabanlı Erişim Kontrolü (RBAC) : 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. Politika Tabanlı Erişim Kontrolü (PBAC) : Kullanıcılara unvan, sertifika, eğitim gibi niteliklere ve/veya konum gibi çevresel faktörlere göre erişim izni verilir. Nitelik Tabanlı Erişim Kontrolü (ABAC) : 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. Erişim Kontrol Listeleri (ACL'ler) 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 tanımlayarak başlayalım: Fonksiyonel gereksinimlerini : Kullanıcıların gerekli bilgileri sağlayarak kayıt olmalarına izin verin. Kayıt : Kullanıcıların kimlik bilgilerini temel alarak kimliklerini doğrulayın. Giriş : Güvenliği sağlamak için kullanıcı oturumlarını verimli bir şekilde yönetin. Oturum Yönetimi : Kullanıcıların şifrelerini kurtarmaları için güvenli bir süreç sağlayın. Şifre Kurtarma : Farklı kullanıcı türleri için rolleri ve izinleri tanımlayın. Erişim Kontrolü : Denetim için kimlik doğrulama olaylarının ayrıntılı günlüklerini tutun. Denetim İzi : Düşük gecikme ve hızlı yanıt süreleri sağlayın. Performans Bu makale kapsamında dikkate almayacağımız birkaç şunlardır: işlevsel olmayan gereksinim : Sağlam bir MFA sistemi uygulayın. Çok Faktörlü Kimlik Doğrulama (MFA) : Şifreleme, güvenli depolama ve güvenli iletişim yoluyla veri güvenliğine öncelik verin. Güvenlik : Sistemi, artan sayıda kullanıcı ve işlemi yönetebilecek şekilde tasarlayın. Ölçeklenebilirlik : Sistemin kapalı kalma süresini en aza indirin ve yüksek kullanılabilirlik sağlayın. Güvenilirlik : Kusursuz bir deneyim için sezgisel bir kullanıcı arayüzü geliştirin. Kullanılabilirlik Kapasite Tahmini Trafik Tahmini Öncelikle 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. Trafik Tahmini 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 : 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. Hizmet Seviyesi Hedefi (SLO) Yukarıdaki metrikleri kullanarak daha oluşturalım. türetilmiş iki metrik : Örnek başına kabul edilebilir biriktirme listesi : Bir örnek tarafından SLO'dan ödün vermeden kabul edilebilecek maksimum istek (yük) sayısı. Kapasite : Örnek başına biriktirme listesi : Mevcut trafiğe bağlı olarak bir birime/örneğe akan isteklerin (yük) toplam sayısı. Talep 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. Kullanıcılar - Tüm kullanıcı bilgilerini saklamak için Kimlik bilgileri - Kullanıcı yetkilendirildikten sonra erişim/yenileme kimlik bilgilerini saklamak için. Şifreler - Kullanıcının şifrelenmiş kullanıcı şifrelerini saklamak için. PasswordRequests - Belirli bir kullanıcı için gelen şifre değiştirme isteklerini saklamak için. Oturumlar - Kullanıcının ne zaman aktif bir oturumu olduğunu ve son etkinliğinin ne zaman olduğunu saklamak için. 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ı Uç nokta Tanım /giriş yapmak Kullanıcı kimlik bilgilerini doğrulayın. /çıkış Yap Kullanıcı oturumunu sonlandırın ve kimlik doğrulama belirteçlerini iptal edin. /kayıt olmak Yeni bir kullanıcı oluşturun. /güncelleme/:kullanıcıKimliği Kullanıcı bilgilerini güncelleyin. /delete/:kullanıcıKimliği Bir kullanıcı hesabını silin. /grant/:userId/:izin Bir kullanıcıya belirli izinler verin. /revoke/:kullanıcıKimliği/:izin Bir kullanıcının izinlerini iptal edin. /kontrol/:kullanıcıKimliği/:kaynak Kullanıcının belirli bir kaynağa erişimini kontrol edin. /create/:kullanıcıKimliği Yeni bir kullanıcı oturumu oluşturun. /expire/:sessionId Bir kullanıcı oturumunun sona ermesi. /validate/:sessionId Etkin bir kullanıcı oturumunu doğrulayın. Gereksinimlerin Yerine Getirilmesi Şimdi her şey hazır olduğuna göre tüm gereksinimleri nasıl tamamlayabileceğimizi görelim. Kayıt - 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. Gereksinim - 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. Gerçekleştirildi Giriş yapmak - 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. Gereksinim - 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 adı verilir. Gerçekleştirildi Kimlik Doğrulama Oturum Yönetimi - 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. Gereksinim - Kullanıcı başarıyla kimlik doğrulaması yaptığında. Kimlik Doğrulama sunucusu istemciyle 2 jetonu paylaşacaktır. Bir ve bir . 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. Yerine Getirildi erişim_token yenileme_token Şifre kurtarma - Bir kullanıcı şifresini unuttuğunda şifresini güvenli bir şekilde sıfırlayabilmesi gerekir. Gereksinim - 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. Gerçekleştirildi Giriş kontrolu - 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. Gereksinim - 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. Yerine getirildi Denetim İzi - 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. Gereksinim - 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. Gerçekleştirildi Verim - Kapasite tahmini bölümünde tartışıldığı gibi performans gereksinimi, 0,04 istek/saniye ve ayda 100 bin istektir. Gereksinim - Kapasite tahmini bölümünde, gereksinimi yeterli sayıda sunucuyla zaten ele aldık. Gerçekleştirildi Çö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.
