Mikro hizmetler ve tüketiciler için yetkilendirme ve kimlik doğrulama sistemi

Şirket sistemimizi mikro servis tabanlı bir sistemde yeniden düzenlemeyi planlıyoruz. Bu mikro hizmetler kendi şirket içi uygulamalarımız ve gerekirse 3. taraf iş ortakları tarafından kullanılacaktır. Biri rezervasyon, diğeri ürünler vb.

Rolleri ve kapsamları nasıl ele alacağımızdan emin değiliz. Buradaki fikir, Yöneticiler, Aracılar ve Son Kullanıcılar gibi 3 temel kullanıcı rolü oluşturmak ve tüketici uygulamalarının gerektiğinde kapsamları ince ayarlamasına izin vermektir.

• Yöneticiler varsayılan olarak tüm kaynakları (şirketleri için) oluşturabilir, güncelleyebilir, okuyabilir ve silebilir.
• Temsilciler şirketleri için veri oluşturabilir, güncelleyebilir ve okuyabilir.
• Son Kullanıcılar veri oluşturabilir, güncelleyebilir, silebilir ve okuyabilir, ancak aracılarla veya yöneticilerle aynı uç noktalara erişemez. Ayrıca aracılar veya yöneticilerle aynı düzeyde değil, veri oluşturabilir veya değiştirebilirler. Örneğin, son kullanıcılar hesap bilgilerini güncelleyebilir veya okuyabilir, aynı aracılar onlar için yapabilir, ancak yönetici notlarını göremez veya güncelleyemez.

Temsilcilerin varsayılan olarak şirketleri için her kaynağı oluşturabildiğini, okuyabildiğini ve güncelleyebildiğini ve belirteçleri / oturumları için talep edilebilecek maksimum kapsamları olduğunu, ancak müşteri (API tüketicisi) uygulaması geliştiricilerinin temsilcilerinden birinin yalnızca belirli kaynakları okuyup oluşturun.

Bunu iç güvenliğimizde ele almak ve bu verileri veri tabanımıza yazmasına izin vermek veya istemcilerin daha az kapsamlı bir jeton isteyerek dahili olarak işlemesine izin vermek ve hangi aracısının veritabanında hangi kapsama sahip olacağını yazmalarına izin vermek daha iyi bir uygulamadır. ? Bu şekilde sadece jeton kapsamlarını izlememiz gerekir.

Bunun dezavantajı, ekibimizin dahili uygulamalarımızda ince ayarlı erişim mekanizmaları oluşturması gerektiğidir.

Bu düşünme şekli ile, mikro hizmetler ve yetkilendirme sistemi müşterilerin ihtiyaçları ile uğraşmamalıdır, çünkü bunlar sadece tüketicidir ve sistemin bir parçası değildir (bu tüketicilerin bazıları kendi dahili uygulamalarımız olsa da)?

Bu heyet iyi bir yaklaşım mı?

Kimlik doğrulama ve yetkilendirme her zaman iyi konulardır

Çalışmakta olduğum çok kiracılı hizmetteki yetkilerle nasıl başa çıkacağımızı açıklamaya çalışacağım. Kimlik doğrulama ve yetkilendirme, JSON Web Token açık standardı kullanılarak belirteç tabanlıdır. Hizmet, her tür istemcinin (web, mobil ve masaüstü uygulamaları) erişebileceği bir REST API'sini sunar. Bir kullanıcının kimliği doğrulandığında, hizmet sunucuya her istekte gönderilmesi gereken bir erişim belirteci sağlar.

Bu yüzden sunucu uygulamasındaki verileri nasıl algıladığımız ve ele aldığımıza dayanarak kullandığımız bazı kavramları tanıtayım.

Kaynak : Bir istemcinin hizmet üzerinden erişebileceği herhangi bir birim veya veri grubudur. Kontrol etmek istediğimiz tüm kaynaklara tek bir isim veriyoruz. Örneğin, bir sonraki uç nokta kurallarına sahip olarak bunları şu şekilde adlandırabiliriz:

product

/products
/products/:id

payment

/payments/
/payments/:id

order

/orders
/orders/:id
/orders/:id/products
/orders/:id/products/:id

Diyelim ki şimdiye kadar hizmetimizde üç kaynağımız var ; product, paymentve order.

Eylem : Bir kaynak üzerinde gerçekleştirilebilen bir işlemdir, okuma, oluşturma, güncelleme, silme, vb. Sadece klasik CRUD işlemleri olmak gerekli değildir follow, örneğin, WebSockets kullanarak bir tür bilgiyi yayan bir hizmeti göstermek istemektedir.

Yetenek : actiona resource. Örneğin; temelde sadece bir kaynak / eylem çiftidir. Ancak buna bir ad ve açıklama da ekleyebilirsiniz.

Rol : Kullanıcının sahip olabileceği bir dizi yetenek. Örneğin, bir rol Cashier"ödeme oku", "ödeme oluştur" veya bir rol Seller"ürünü oku", "okuma sırası", "güncelleme sırası", "siparişi sil" özelliklerine sahip olabilir.

Son olarak, bir kullanıcının kendisine atanmış çeşitli rolleri olabilir.

açıklama

Daha önce söylediğim gibi, JSON Web Token'ı kullanıyoruz ve bir kullanıcının sahip olduğu yetenekler tokenın yükünde bildiriliyor. Bu nedenle, küçük bir perakende mağazası için aynı anda kasiyer ve satıcının rollerine sahip bir kullanıcımız olduğunu varsayalım. Yük aşağıdaki gibi görünecektir:

{
    "scopes": {
        "payment": ["read", "create"],
        "order": ["read", "create", "update", "delete"]
    }
}

İddiada görebileceğiniz gibi scopes, rollerin (kasiyer, satıcı) adını belirtmiyoruz, bunun yerine, yalnızca ilgili kaynaklar ve eylemler belirtiliyor. İstemci bir uç noktaya istek gönderdiğinde, hizmet, erişim belirtecinin gerekli kaynağı ve eylemi içerip içermediğini kontrol etmelidir. Örneğin GET, uç noktaya yapılan bir istek /payments/88başarılı olacaktır, ancak DELETEaynı uç noktaya yapılan bir istek başarısız olmalıdır.

• Kaynakların nasıl gruplandırılacağı ve adlandırılacağı, eylemlerin ve yeteneklerin nasıl tanımlanacağı ve adlandırılacağı geliştiriciler tarafından alınan bir karar olacaktır.

• Roller nelerdir ve bu roller hangi yeteneklere sahip olacak, müşteriler tarafından alınan kararlardır.

Elbette, jetonu veren kullanıcıyı ve müşteriyi (kiracı) tanımlamak için yüke ekstra özellikler eklemeniz gerekir.

{
    "scopes": {
        ...
    },
    "tenant": "acme",
    "user":"coyote"
}

Bu yöntemle, herhangi bir kullanıcı hesabının erişiminize ince ayar yapabilirsiniz. Ve en önemlisi, sorunuzda belirttiğiniz gibi Yönetici, Aracılar ve Son Kullanıcılar gibi çeşitli önceden tanımlanmış ve statik roller oluşturmanız gerekmez . Bir Süper Kullanıcı bir sahibi bir kullanıcı olacak roletüm resourcesve actionskendisine atanmış hizmet.

Şimdi, ya 100 kaynak varsa ve hepsine veya neredeyse hepsine erişim sağlayan bir rol istiyorsak? Jeton yükümüz çok büyük olurdu. Bu, kaynakları iç içe geçirerek ve yalnızca ana kaynağı erişim belirteci kapsamına ekleyerek çözülür.

Yetkilendirme, her uygulamanın gereksinimlerine bağlı olarak ele alınması gereken karmaşık bir konudur.

Ne olursa olsun, hizmetlerinizin, kullanıcıları doğrulamak için yazdığınız bir kimlik doğrulama hizmeti tarafından sağlanan bir kimlik belirteci kabul etmesini isteyeceğinizi düşünüyorum. Bu, mikro hizmetlerinizin kötüye kullanılmasını önlemenin en kolay / güvenli yoludur. Ayrıca, genel olarak, bir müşterinin iyi bir deneyime sahip olmasını istiyorsanız, kritik özellikleri kendiniz uygulamalı ve sunduğunuz özelliklerin iyi uygulandığından emin olmak için kapsamlı bir şekilde test etmelisiniz.

Tüm arayanların mikro hizmetlerinizin kimliklerinin doğrulandığına dair kanıt sağlaması gerektiğinden, bu kimlik doğrulamasına izinleri de bağlayabilirsiniz. Bir kullanıcıyı rasgele bir erişim grubuna (veya süslü olmak istiyorsanız gruplara bağlama) sağlarsanız, izinlere karşı çıkarmaya karşı izin ekleme burada daha zor olur.), Müşterilerinizden neden kullanıcının neden olduğu hakkında daha az soru olacaktır. x istenmeyen bir işlem yapabildi. Her durumda, birisi her hizmet için erişim listesi denetimi yapmak zorundadır, bu yüzden siz de olabilirsiniz. Tüm hizmetlerin başında kolayca kodlanabilecek bir şey (if ( !TokenAuthorized(this.ServiceName, this.token) { Raise error }) Siz de yapabilirsiniz ve kullanıcı gruplarını kendiniz takip edebilirsiniz. Bir izin grubu yöneticisine sahip olmanız ve bunu kullanıcı yönetimi kullanıcı arayüzünde çalıştırmanız gerektiği doğrudur (karışıklığı önlemek için tanımı düzenlerken bir gruba bağlı olan kullanıcıları kesinlikle listeleyin . Ama bu zor bir iş değil. Tüm servisler için meta verilere sahip olun ve grup ile servis arasındaki eşlemeyi kimlik doğrulama işlemine ekleyin.

Tamam, bu yüzden birkaç ayrıntı var, ancak bu işlevselliği isteyen müşterilerinizin her biri bunu her durumda kodlamak zorunda kalacak ve üç seviyeli kullanıcı izinlerini destekliyorsanız, kullanıcı erişimi başına da genişletebilirsiniz. grupları. Muhtemelen temel grup izinleri ile kullanıcıya özgü izinler arasında mantıksal bir kavşak doğru toplama olacaktır, ancak Yönetici, Aracı, Son kullanıcı temel izinlerine temel izinler ekleyip alabilmek istiyorsanız, yapmanız gerekir izin gruplarındaki olağan üç durum bayrağı: İzin Ekle, İzin Verme, Varsayılan İzin ve izinleri uygun şekilde birleştirin.

(Not olarak, konuşmanın her iki ucunun güvenliği konusunda endişeleriniz varsa, bunların hepsi SSL veya iki yönlü SSL gibi bir şey üzerinde gerçekleşmelidir. Bu belirteçleri bir saldırgana "sızdıysanız", d bir şifre kırdı.)

Bence burada iki seçeneğiniz var.

• Sadece aynı uygulamaya yapılandırılabilir erişime sahip olmanız gerekiyorsa, hizmetlerin izinleri kontrol etmesini sağlayın ve müşterilerinize her bir role verilen izinleri değiştirmelerini sağlayan bir arayüz verin. Bu, çoğu kullanıcının 'sorun' müşterilerinin rolleri değiştirebileceği veya ihtiyaçlarına göre yenilerini oluşturabileceği varsayılan rol kurulumunu kullanmasına izin verir.

• Müşterileriniz kendi uygulamalarını geliştiriyorsa, kendi ara API'lerini tanıtmalıdırlar. Bu, size yönetici olarak bağlanır, ancak hizmetlerinizi aramadan önce gelen isteği kendi özel kimlik doğrulama gereksinimlerine göre kontrol eder

Güvenlik değerlendirmesi

Tasarımınızı iyi anlarsam, bazı kaynak erişim kontrol mekanizmalarını istemci tarafına devretmeyi planlıyorsunuz, yani tüketen bir uygulama kullanıcının görebileceği öğeleri azaltır. Varsayımınız:

mikro hizmetler ve yetkilendirme sistemi müşterilerin ihtiyaçları ile uğraşmamalıdır, çünkü bunlar sadece tüketicidir ve sistemin bir parçası değildir

Burada ciddi işler için iki ciddi sorun görüyorum:

• Dışarıdaki bazı hileli kullanıcılar (örneğin partnerinizin tesislerinden birinde) müşteri uygulamasını tersine çevirir ve API'yi öğrenir, şirketinin müşteriye getirdiği kısıtlamaları aşar ve bu bilgileri şirketinize zarar vermek için kullanırsa ne olur? Şirketiniz hasar talebinde bulunacak, ancak parnter şirketi verilerinizi yeterince iyi korumak için araçlar sağlamadığınızı iddia edecektir.
• Genellikle, hassas verilerin kötüye kullanılması (veya denetimin riski keşfedeceği) ve yönetiminizin bu verilerin daha sıkı bir şekilde kontrol edilmesini istemesi yalnızca zaman meselesidir.

Bu yüzden bu tür olayları tahmin etmenizi ve yetkilendirme taleplerini yerine getirmenizi tavsiye ederim. Erken bir yeniden yapılandırma aşamasındasınız ve bunları mimarinizde (hepsini uygulamasanız bile) daha sonra dikkate almak çok daha kolay olacaktır.

Mevcut konumunuzu takip ediyorsanız, en azından bilgi güvenliği görevlinize danışın.

Nasıl uygulanır?

Hile var:

Bu şekilde, yalnızca jeton kapsamlarını izlememiz gerekir.

Tamam, müşteri tarafından seçilen bazı genel simgeleri kullanmayı düşünüyorsunuz. Yine gözümdeki bir zayıflık, çünkü bazı müşteriler kontrolünüz dışında olabilir.

Zaten JWT kullanıp kullanmadığınızı veya başka teknikler kullanıp kullanmadığınızı bilmiyorum . Ancak JWT kullanıyorsanız, kullanıcının kimliğini taşıyan bir kimlik belirteciniz olabilir (ve başlangıçtaki uygulamayı güvenli bir şekilde tanımlayan ikinci bir belirteç bile olabilir; ).

Eğer bir microservice mimarisi için gitmek niyetinde, ben önermek istiyorum farkını amke kullanıcı yönetimi ve kimlik doğrulama işleminin (özel servis olarak çalışmalıdır) ve spesifik her microservice etmektir erişim denetimi (arasına ve gerektiği her biri tarafından yerel olarak ele alınmalıdır). Tabii ki bazı yönetici istemciler, kullanım kolaylığı için çeşitli hizmetler arasında kapsamlı bir genel bakış sunmalıdır).

Burada da kısa bir cevap var. "Müşterilerinize" sunmak istediğiniz tüm temel özellikleri kendiniz uygulamalısınız. Zaten kullanıcı kimlik doğrulaması yaptığınızdan, istemcilerin kullanıcı izinleri gibi temel davranışları eklemeleri sorunlu görünmektedir; uygulamayı istemciye bırakırsanız, aynı izin kodunun birden çok uygulamasını "destekleyebilir". "Sahip olmamanıza" rağmen, kodlarında hatalar olacaktır ve istemcilerinizin bekledikleri işlevselliklere sahip olmalarını istersiniz, bu nedenle bir müşterinin yaşadığı sorunların çözümünü desteklersiniz. Birden fazla kod tabanını desteklemek eğlenceli değildir.