Uygulamanıza her istek geldiğinde, isteğin amaçlandığı kiracıyı belirlemeniz gerekir. Farklı coğrafi bölgelerde barındırılabilen kiracıya özgü altyapınız varsa, gelen isteği bir kiracıyla eşleştirmeniz gerekir. Ardından, isteği aşağıda gösterildiği gibi kiracının kaynaklarını barındıran fiziksel altyapıya iletmeniz gerekir:
Bu sayfada, teknik karar alıcılara istekleri uygun kiracıyla eşlemek için göz önünde bulundurabileceğiniz yaklaşımlar ve yaklaşımlarda yer alan dengeler hakkında rehberlik sağlıyoruz.
Dekont
Bu sayfada çoğunlukla web siteleri ve API'ler gibi HTTP tabanlı uygulamalar ele alınmaktadır. Ancak, aynı temel ilkelerin çoğu diğer iletişim protokollerini kullanan çok kiracılı uygulamalar için 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ü etki alanı 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 Host kiracılara kolayca eşlenmesi olasıdır.
Ancak aşağıdaki soruları göz önünde bulundurun:
- Kullanıcılar hizmete erişmek için hangi etki alanı adını kullanacaklarını nasıl bilecek?
- Tüm kiracıların kullandığı 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 belirler?
- 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ı içeriyor mu?
HTTP isteği özellikleri
Kiracıya özgü etki alanı adlarını kullanmıyorsanız, belirli bir isteğin ait olduğu kiracıyı tanımlamak için HTTP isteğinin yönlerini kullanmaya devam edebilirsiniz. Örneğin, kiracı adını olarak tailwindtraderstanımlayan bir HTTP isteği düşünün. Bu, aşağıdakiler kullanılarak iletilebilir:
- URL yolu yapısı, örneğin
https://app.contoso.com/tailwindtraders/. - URL'de bir sorgu dizesi , örneğin
https://contoso.com/app?tenant=tailwindtraders. - gibi
X-Tenant-Id: tailwindtradersözel bir HTTP isteği üst bilgisi.
Önemli
Özel HTTP isteği üst bilgileri, HTTP GET isteklerinin bir web tarayıcısından verildiği veya isteklerin bazı web ara sunucusu türleri tarafından işlendiği durumlarda kullanışlı değildir. GET işlemleri için yalnızca BIR API oluştururken veya isteği veren istemciyi denetlediğinizde ve istek işleme zincirinde web proxy'si yoksa özel HTTP üst bilgileri kullanmalısınız.
Bu yaklaşımı kullanırken aşağıdaki soruları dikkate almanız gerekir:
- Kullanıcılar hizmete nasıl erişeceklerini bilecek mi? Örneğin, kiracıları tanımlamak için bir sorgu dizesi kullanırsanız, sorgu dizesini ekleyerek merkezi bir giriş sayfasının kullanıcıları doğru kiracıya yönlendirmesi gerekir mi?
- Tüm kiracıların kullandığı 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 belirler?
- Uygulamanız API'ler sağlıyor mu? Örneğin, web uygulamanız tek sayfalı bir uygulama mı (SPA) yoksa API arka ucu olan bir mobil uygulama mı? Bu durumda, 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ğrulaması ve yetkilendirme protokolleri 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 iletmek için kullanılabilir. Sisteminiz daha sonra kullanıcının e-posta adresini içerebilir, kullanıcıdan kiracıya eşlemeyi arayabilir ve ardından isteği uygun dağıtıma iletebilir. Alternatif olarak, kiracı eşlemesini kimlik sisteminize dahil edebilir ve belirteçe bir kiracı kimliği talebi ekleyebilirsiniz.
İstekleri kiracılarla eşlemek için talepler kullanıyorsanız aşağıdaki soruları göz önünde bulundurmanız gerekir:
- Kiracıyı tanımlamak için bir talep kullanacak mısınız? Hangi talebi kullanacaksınız?
- Bir kullanıcı birden çok kiracının üyesi olabilir mi? Bu mümkünse, kullanıcılar birlikte çalışmak istedikleri kiracıları nasıl seçer?
- Tüm kiracılar için merkezi kimlik doğrulama ve yetkilendirme sistemi var mı? Aksi takdirde, tüm belirteç yetkililerinin tutarlı belirteçler ve talepler vermelerini nasıl sağlayacaksınız?
API anahtarları
Birçok uygulama API'leri kullanıma sunar. Bunlar kuruluşunuzda dahili kullanım veya iş ortakları ya da müşteriler tarafından dış kullanım için olabilir. API'ler için yaygın kimlik doğrulama yöntemlerinden biri API anahtarı kullanmaktır. API anahtarları her istekle birlikte sağlanır ve kiracıyı aramak için kullanılabilir.
API anahtarları çeşitli yollarla oluşturulabilir. Yaygın bir yaklaşım, kriptografik olarak rastgele bir değer oluşturmak ve bunu kiracı kimliğiyle birlikte bir arama tablosunda depolamaktır. bir istek alındığında, sisteminiz arama tablosunda API anahtarını bulur ve ardından bu anahtarı bir kiracı kimliğiyle eşleştirir. Bir diğer yaklaşım da içinde kiracı kimliği bulunan anlamlı bir dize oluşturmaktır ve ardından HMAC gibi bir yaklaşım kullanarak anahtarı dijital olarak imzalarsınız. Her isteği işlerken, imzayı doğrular ve sonra kiracı kimliğini ayıklarsınız.
Dekont
API anahtarları, el ile oluşturulması ve yönetilmesi gerektiğinden ve talep içermediğinden yüksek düzeyde güvenlik sağlamaz. Daha modern ve güvenli bir yaklaşım, OAuth 2.0 veya OpenID Bağlan gibi kısa süreli belirteçlerle talep tabanlı yetkilendirme mekanizması kullanmaktır.
Aşağıdaki soruları göz önünde bulundurun:
- API anahtarlarını nasıl oluşturacak ve vereceksiniz?
- API istemcileriniz API anahtarını güvenli bir şekilde nasıl alacak ve depolayacak?
- BIR süre sonra API anahtarlarınızın süresinin dolması gerekiyor mu? İstemcilerinizin API anahtarlarını kapalı kalma süresine neden olmadan nasıl döndüreceksiniz?
- Yalnızca müşteri tarafından alınan API anahtarlarına güvenmek API'leriniz için yeterli düzeyde güvenlik sağlar mı?
Dekont
API anahtarları parolalar ile aynı değildir. API anahtarları sistem tarafından oluşturulmalıdır ve her API anahtarının tek bir kiracıya benzersiz olarak eşlenebilmesi için tüm kiracılar arasında benzersiz olmalıdır. Azure API Management gibi API ağ geçitleri API anahtarları oluşturup yönetebilir, gelen isteklerde anahtarları doğrulayabilir ve anahtarları tek tek API abonelerine eşleyebilir.
İstemci sertifikaları
Bazen karşılıklı TLS (mTLS) olarak da adlandırılan istemci sertifikası kimlik doğrulaması, hizmet-hizmet iletişimi için yaygın olarak 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ılabilecek öznitelikler sağlar. Örneğin, sertifikanın konusu kullanıcının kiracıyı aramak için kullanılabilecek e-posta adresini içerebilir.
Kiracı eşlemesi için istemci sertifikalarını kullanmayı planlarken aşağıdakileri göz önünde bulundurun:
- Hizmetiniz tarafından güvenilen istemci sertifikalarını güvenli bir şekilde nasıl verecek ve yenileyeceksiniz? sertifikaları yönetmek ve vermek için özel bir altyapıya ihtiyaç duyduklarından, istemci sertifikalarının birlikte çalışması 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 eklenecek?
- Çok sayıda istemciniz olduğunda sertifikaları 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 proxy'ler
HTTP isteklerini yönlendirmek için uygulama ara sunucusu olarak da adlandırılan ters ara sunucu kullanılabilir. Ters ara sunucu bir giriş uç noktasından gelen isteği kabul eder ve isteği birçok arka uç uç noktasından birine iletebilir. Ters proxy'ler, çok kiracılı uygulamalar için kullanışlıdır çünkü bir istek bilgisi parçası arasında eşleme gerçekleştirebilir ve görevi uygulama altyapınızdan boşaltabilir.
Birçok ters proxy, kiracı yönlendirmesi hakkında karar vermek için isteğin özelliklerini kullanabilir. Hedef etki alanı adını, URL yolunu, sorgu dizesini, HTTP üst bilgilerini ve hatta belirteçler içindeki talepleri inceleyebilirler.
Azure'da aşağıdaki yaygın ters proxy'ler kullanılır:
- Azure Front Door genel bir 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 genel uç ağını kullanır.
- Azure Uygulaması lication Gateway, arka uç hizmetinizle aynı fiziksel bölgeye dağıttığınız 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 (kendi barındırdığınız) nginx, Traefik ve HAProxy'yi içerir.
İstek doğrulaması
Uygulamanızın aldığı tüm isteklerin kiracı için yetkilendirildiğini doğrulaması önemlidir. Örneğin, uygulamanız istekleri kiracıyla eşlemek için özel bir etki alanı adı kullanıyorsa, uygulamanız yine de uygulama tarafından alınan her isteğin söz konusu kiracı için yetkilendirilip yetkilendirilmediğini denetlemelidir. İstek bir etki alanı adı veya başka bir kiracı tanımlayıcısı içerse de, bu otomatik olarak erişim vermeniz gerektiği anlamına gelmez. OAuth 2.0 kullandığınızda, izleyicileri ve kapsam taleplerini inceleyerek doğrulamayı gerçekleştirirsiniz.
Dekont
Bu, Microsoft Azure İyi Tasarlanmış Çerçeve'deki sıfır güven güvenlik tasarımı ilkesinin bir parçasıdır.
İstek doğrulamasını uygularken aşağıdakileri göz önünde bulundurmanız gerekir:
- Uygulamanıza yönelik tüm istekleri nasıl yetkilendirileceksiniz? İstekleri fiziksel altyapıyla eşlemek için kullandığınız yaklaşımdan bağımsız olarak yetkilendirmeniz gerekir.
- Tüm doğrulama mantığını kendiniz uygulamak yerine güvenilir, yaygın olarak kullanılan ve bakımlı kimlik doğrulama ve yetkilendirme çerçeveleri ile ara yazılım kullanın. Örneğin, belirteç imzası doğrulama mantığı veya istemci sertifikası şifreleme kitaplıkları oluşturmayın. Bunun yerine, uygulama platformunuzun (veya bilinen güvenilen 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çeklendirileceğini göz önünde bulundurun. Örneğin, kiracı eşlemenizin bir parçası olarak bir veritabanı tablosunu sorgularsanız veritabanı büyük miktarda yükü destekleyecek mi? Kiracı eşlemeniz bir belirtecin şifresini çözmeyi gerektiriyorsa hesaplama gereksinimleri zaman içinde çok mu yüksek olacak? Trafiğiniz oldukça mütevazıysa, bu durum genel performansınızı etkilemez. Ancak yüksek ölçekli bir uygulamanız olduğunda, bu eşlemeye uygulanan ek yük önemli hale gelebilir.
Oturum benzeşimi
Kiracı eşleme mantığının performans ek yükünü azaltmaya yönelik bir yaklaşım, oturum benzimi kullanmaktır. Eşlemeyi her istekte gerçekleştirmek yerine, bilgileri yalnızca her oturum için ilk istekte hesaplamayı göz önünde bulundurun. Uygulamanız daha sonra istemciye bir oturum tanımlama bilgisi sağlar. İstemci, oturumdaki sonraki tüm istemci istekleriyle oturum tanımlama bilgisini hizmetinize geri geçirir.
Dekont
Azure'daki birçok ağ ve uygulama hizmeti oturum tanımlama bilgileri verebilir ve oturum benzini kullanarak istekleri yerel olarak yönlendirebilir.
Aşağıdaki soruları göz önünde bulundurun:
- İstekleri kiracılara eşleme yükünü azaltmak için oturum bennizimini kullanabilir misiniz?
- İstekleri her kiracının fiziksel dağıtımlarına yönlendirmek için hangi hizmetleri kullanırsınız? Bu hizmetler tanımlama bilgisi tabanlı oturum benzini destekliyor mu?
Kiracı geçişi
Kiracıların genellikle kiracı yaşam döngüsünün bir parçası olarak yeni altyapıya taşınması gerekir. Kiracı yeni bir dağıtıma taşındığında, eriştiği HTTP uç noktaları değişebilir. Bu durumda, kiracı eşleme işleminizin güncelleştirilmesi gerektiğini göz önünde bulundurun. Aşağıdakileri göz önünde bulundurmanız gerekebilir:
- Uygulamanız eşleme istekleri için etki alanı adları kullanıyorsa, geçiş sırasında bir DNS değişikliği de gerektirebilir. DNS hizmetinizdeki DNS girdilerinin yaşam süresine bağlı olarak DNS değişikliğinin istemcilere yayılması zaman alabilir.
- Geçişiniz geçiş işlemi sırasında uç noktaların adreslerini değiştirirse, kiracı isteklerini geçici olarak otomatik olarak yenilenen bir bakım sayfasına yeniden yönlendirmeyi göz önünde bulundurun.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazar:
- Daniel Scott-Raynsford | İş Ortağı Teknoloji Stratejisti
Diğer katkıda bulunanlar:
- John Downs | Baş Müşteri Mühendisi, Azure için FastTrack
- Paolo Salvatori | Baş Müşteri Mühendisi, Azure için FastTrack
- Arsen Vladimirskiy | Baş Müşteri Mühendisi, Azure için FastTrack
Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.
Sonraki adımlar
Çok kiracılı bir uygulamada etki alanı adlarıyla çalışırken dikkat edilmesi gerekenler hakkında bilgi edinin.