İstekleri çok kiracılı bir çözümde kiracılara eşleme

Makale
12/09/2021
Okumak için 7 dakika

Uygulamanıza her istek geldiğinde, isteğin amaçladığı kiracıyı belirlemeniz gerekir. Farklı coğrafi bölgelerde barındırılan kiracıya özgü altyapınız olduğunda, gelen isteği bir kiracıyla eşleşmeniz gerekir. Ardından, aşağıda gösterildiği gibi isteği kiracının kaynaklarını barındıran fiziksel altyapıya iletmeniz gerekir:

Mantıksal kiracıdan fiziksel kiracı altyapısına bir isteği eşlemeyi gösteren diyagram.

Bu sayfada, teknik karar almacılara istekleri uygun kiracıyla eşlemek için göz önünde bulundurabilirsiniz yaklaşımlar hakkında rehberlik sağlarız ve yaklaşımlarda yer alan tradeoff'lar.

Not

Bu sayfa çoğunlukla web siteleri ve API'ler gibi HTTP tabanlı uygulamaları ele amektedir. Ancak, temel alınan ilkelerin çoğu diğer iletişim protokollerini kullanan çok kullanıcılı uygulamalar için de geçerlidir.

Kiracıları belirleme yaklaşımları

Gelen istek için kiracıyı tanımlamanın birden çok yolu vardır.

Etki alanı adları

Kiracıya özgü etkialanı veya alt etki alanı adları kullanıyorsanız, isteklerin üst bilgi veya her istek için özgün ana bilgisayar adını içeren başka bir HTTP üst bilgisi kullanılarak kolayca kiracılara eşlenebiliyor olması olasıdır.

Ancak, aşağıdaki soruları göz önünde önünden yapın:

Kullanıcılar hizmete erişmek için hangi etki alanı adını kullanacağız?
Tüm kiracıların kullanabileceği giriş sayfası veya oturum açma sayfası gibi merkezi bir giriş noktanız var mı? Bunu yaparsanız, kullanıcılar erişmesi gereken kiracıyı nasıl belirleyecek?
Kiracıya erişimi doğrulamak için yetkilendirme belirteçleri gibi başka hangi bilgileri kullanıyorsunuz? Yetkilendirme belirteçleri kiracıya özgü etki alanı adlarını mı içerir?

HTTP isteği özellikleri

Kiracıya özgü etki alanı adlarını kullanasanız da HTTP isteğinin yönlerini kullanarak belirli bir isteğin hangi kiracıya yönelik olduğunu tanımlayabilirsiniz. Örneğin, kiracı adını olarak tanımlayan bir HTTP isteği tailwindtraders düşünün. Bu, aşağıdakiler kullanılarak iletildi:

GIBI URL yolu yapısı.
URL'de gibi bir sorgu dizesi.
gibi özel bir HTTP isteğiüst bilgisi.

Önemli

Özel HTTP isteği üst bilgileri, HTTP GET isteklerinin bir web tarayıcısında veya isteklerin bazı türlerde web tarayıcılarından iş web proxy. Özel HTTP üst bilgilerini yalnızca BIR API'yi oluştururken GET işlemleri için kullansanız veya isteği soruna neden olan istemciyi kontrol ediyorsanız ve istek işleme zincirine web proxy özel http üst bilgileri kullansanız.

Bu yaklaşımı kullanırken aşağıdaki soruları dikkate alalız:

Kullanıcılar hizmete nasıl erişecek? Örneğin, kiracıları tanımlamak için bir sorgu dizesi kullanırsanız, merkezi bir giriş sayfasının sorgu dizesini ekleyerek kullanıcıları doğru kiracıya yönlendirecek mi?
Tüm kiracıların kullanabileceği giriş sayfası veya oturum açma sayfası gibi merkezi bir giriş noktanız var mı? Bunu yaparsanız, kullanıcılar erişmesi gereken kiracıyı nasıl belirleyecek?
Uygulamanız API'ler sağlar mı? Örneğin, web uygulamanız tek sayfalı bir uygulama mı (SPA) yoksa API arka ucu olan bir mobil uygulama mı? Varsa, kiracı eşlemesi gerçekleştirmek için bir API ağ geçidi veya ters ara sunucu kullanabilirsiniz.

Belirteç talepleri

Birçok uygulama OAuth 2.0 veya SAML gibi talep tabanlı kimlik doğrulama ve yetkilendirme protokollerini kullanır. Bu protokoller istemciye yetkilendirme belirteçleri sağlar. Belirteç, istemci uygulaması veya kullanıcıhakkında bilgi parçaları olan bir talep kümesi içerir. Talepler, kullanıcının e-posta adresi gibi bilgileri iletişim kurmak için kullanılabilir. Sisteminiz daha sonra kullanıcının e-posta adresini içerebilir, kullanıcıdan kiracıya eşlemeyi sınar ve ardından isteği uygun fiziksel kiracı altyapısına iletebilirsiniz. Ya da kimlik sisteminize kiracı eşlemesi ekleyebilir ve belirteçe bir kiracı kimliği talebi eklersiniz.

İstekleri kiracılara eşlemek için talepler kullanıyorsanız aşağıdaki soruları göz önünde bulundursanız:

Bir kiracıyı tanımlamak için bir talep kullanmayacak mısınız? Hangi talebi kullanasınız?
Bir kullanıcı birden çok kiracının üyesi olabilir mi? Bu mümkün olursa, kullanıcılar çalışmak istediğiniz kiracıları nasıl seçer?
Tüm kiracılar için merkezi bir kimlik doğrulama ve yetkilendirme sistemi var mı? Yoksa, tüm belirteç yetkililerinin tutarlı belirteçler ve talepler çıkarması için nasıl emin olursunuz?

API anahtarları

Birçok uygulama API'leri ortaya çıkarır. Bunlar, kuruluş içinde veya iş ortakları ya da müşteriler tarafından dış kullanım için olabilir. API'ler için yaygın bir kimlik doğrulama yöntemi, API anahtarı kullanmaktır. API anahtarları her istekle birlikte sağlanır ve kiracıyı bakmak için kullanılabilir.

API anahtarları çeşitli yollarla oluşturulabilirsiniz. Yaygın bir yaklaşım, şifrelemeyle rastgele bir değer oluşturmak ve bunu kiracı kimliğiyle birlikte bir arama tablosunda depolamaktır. Bir istek alınca, sisteminiz arama tablosunda API anahtarını bulur ve ardından bunu bir kiracı kimliğiyle eşler. Başka bir yaklaşım, içine kiracı kimliği ekli anlamlı bir dize oluşturmak ve ardından HMAC gibi bir yaklaşım kullanarak anahtarı dijital olarak imzalamaktır. Her isteği işlenince imzayı doğrular ve kiracı kimliğini ayıklarsanız.

Not

API anahtarları, el ile oluşturularak yönetilleri gereken ve talep içermeyilen için yüksek düzeyde güvenlik sağlamaz. Daha modern ve güvenli bir yaklaşım, OAuth 2.0 veya OpenID kimlik doğrulaması gibi kısa süreli belirteçlerle talep tabanlı yetkilendirme mekanizması Bağlan.

Aşağıdaki soruları göz önünde bulundurun:

API anahtarlarını nasıl oluşturur ve oluşturursunuz?
API istemcileriniz API anahtarını güvenli bir şekilde nasıl alır ve depolar?
API anahtarlarınızı bir süre sonra süresinin dolması gerekiyor mu? İstemcinizin API anahtarlarını kapalı kalma süresine neden olmadan nasıl döndürebilirsiniz?
Yalnızca müşteri tarafından yuvarlanan API anahtarlarına güvenmek API'leriniz için yeterli bir güvenlik düzeyi mi sağlar?

Not

API anahtarları parolalar ile aynı değildir. API anahtarları sistem tarafından oluşturulmalı ve her API anahtarının tek bir kiracıyla benzersiz bir şekilde eşlenene bir şekilde tüm kiracılar arasında benzersiz olması gerekir. Azure API Management gibi API ağ geçitleri,API anahtarları oluşturma ve yönetme, gelen isteklerde anahtarları doğrulama ve anahtarları tek tek API abonelerine eşleme.

İstemci sertifikaları

Bazen karşılıklı TLS (mTLS) olarak da adlandırılan istemci sertifikası kimlik doğrulaması genellikle hizmet-hizmet iletişimi için kullanılır. İstemci sertifikaları, istemcilerin kimliğini doğrulamak için güvenli bir yol sağlar. Belirteçlere ve taleplere benzer şekilde, istemci sertifikaları kiracıyı belirlemek için kullanılan öznitelikler sağlar. Örneğin, sertifikanın konusu kullanıcının e-posta adresini içerebilir ve kiracıyı bakmak için kullanılabilir.

Kiracı eşlemesi için istemci sertifikalarını kullanmayı planlarken şunları göz önünde bulundurabilirsiniz:

Hizmetiniz tarafından güvenilen istemci sertifikalarını nasıl güvenli bir şekilde ve yenilersiniz? Sertifika yönetmek ve sertifikalar yapmak için özel bir altyapıya ihtiyaçları olduğu için, istemci sertifikaları ile çalışmak karmaşık olabilir.
İstemci sertifikaları yalnızca ilk oturum açma istekleri için mi kullanılacak yoksa hizmetinize yönelik tüm isteklere mi bağlanacak?
Çok sayıda istemciniz olduğunda sertifika verme ve yönetme işlemi yönetilemez hale gelecek mi?
İstemci sertifikası ile kiracı arasındaki eşlemeyi nasıl uygulayacaksınız?

Ters ters yanlar

HTTP isteklerini yönlendirmek için uygulama ara sunucusu olarak da adlandırılan bir ters ara sunucu kullanılabilir. Ters ara sunucu, giriş uç noktasına gelen bir isteği kabul eder ve isteği birçok arka uç uç noktandan biri iletir. Ters ara bilgiler, istek bilgileri arasında eşleme gerçekleştirerek görevi uygulama altyapınıza boşaltmaları için çok kullanıcılı uygulamalar için yararlıdır.

Birçok ters sunucu, kiracı yönlendirmesi hakkında karar verme isteği özelliklerini kullanabilir. Hedef etki alanı adını, URL yolunu, sorgu dizesini, HTTP üst bilgilerini ve hatta belirteçlerin içindeki talepleri inceler.

Azure'da aşağıdaki yaygın ters ters yanlılıklar kullanılır:

Azure Front Door yük dengeleyici ve web uygulaması güvenlik duvarıdır. Hızlı, güvenli ve yüksek oranda ölçeklenebilir web uygulamaları oluşturmak için Microsoft küresel uç ağına sahiptir.
Azure Application Gateway, arka uç hizmetiniz ile aynı fiziksel bölgeye dağıtan, yönetilen bir web trafiği yük dengeleyicidir.
Azure API Management API trafiği için iyileştirilmiştir.
Ticari ve açık kaynak teknolojileri (kendiniz barındırın) nginx, Traefik ve HAProxy'yi içerir.

İstek doğrulaması

Uygulamanın aldığı tüm isteklerin kiracı için yetkilendiril olduğunu doğrulaması önemlidir. Örneğin, uygulamanız istekleri kiracıya eşlemek için özel bir etki alanı adı kullanıyorsa, uygulama tarafından alınan her isteğin o kiracı için yetkilendirildi olup değildir. İstek bir etki alanı adı veya başka bir kiracı tanımlayıcısı içerir ancak bu, otomatik olarak erişim izni ver verilmeli anlamına değildir. OAuth 2.0'ı kullanarak hedef kitleyi ve kapsam taleplerini incelersiniz.

Not

Bu, Microsoft Azure Well-Architected Framework'te sıfır güven güvenliği tasarım ilkesinin bir parçası.

İstek doğrulamayı uygulamaya alırken, şunları göz önündeniz gerekir:

Uygulamanıza yapılan tüm istekleri nasıl yetkilendirebilirsiniz? İstekleri fiziksel altyapıyla eşlemek için hangi yaklaşımdan olursa olsun yetkilendirmeniz gerekir.
Tüm doğrulama mantığını kendiniz uygulamak yerine güvenilen ve yaygın olarak kullanılan kimlik doğrulama ve yetkilendirme çerçevelerini ve ara yazılımı kullanın. Örneğin, belirteç imzası doğrulama mantığı veya istemci sertifikası şifreleme kitaplıkları oluşturma. Bunun yerine, uygulama platformunun (veya bilinen güvenilir paketlerin) doğrulanmış ve test edilmiş özelliklerini kullanın.

Performans

Kiracı eşleme mantığı büyük olasılıkla uygulamanıza yapılan her istekte çalışır. Çözümünüz büyüdükçe kiracı eşleme işleminin ne kadar iyi ölçeklendireceklerini göz önünde bulundurabilirsiniz. Örneğin, kiracı eşlemenizin bir parçası olarak bir veritabanı tablosu sorgularsanız, veritabanı büyük miktarda yükü destekler mi? Kiracı eşlemeniz bir belirteci çözmeyi gerektiriyorsa, işlem gereksinimleri zaman içinde çok mu yüksek olur? Trafiğiniz oldukça küçükse, genel performansınızı etkileme olasılığı düşük olabilir. Ancak, yüksek ölçekli bir uygulama söz konusu olduğunda, bu eşlemeyle ilgili ek yük önemli hale geldi.

Oturum benzeşimi

Kiracı eşleme mantığının performans yükünü azaltmaya yönelik bir yaklaşım oturum benzeşliği kullanmaktır. Eşlemeyi her istekte gerçekleştirmek yerine, bilgileri yalnızca her oturum için ilk istekte hesaplamayı göz önünde bulundurabilirsiniz. Ardından, uygulamanız istemciye oturum tanımlama bilgisi sağlar ve bu oturum içindeki sonraki tüm istemci istekleriyle birlikte hizmetinize geri geçirebilirsiniz.

Not

Azure'daki birçok ağ ve uygulama hizmeti oturum tanımlama bilgileri ve oturum benzeşliği kullanarak istekleri yerel olarak yönlendirebilir.