Amikor egy kérés érkezik az alkalmazásba, meg kell határoznia azt a bérlőt, akire a kérés irányul. Ha olyan bérlőspecifikus infrastruktúrával rendelkezik, amely akár különböző földrajzi régiókban is üzemeltethető, a bejövő kérést egy bérlővel kell egyeztetnie. Ezután továbbítania kell a kérést az adott bérlő erőforrásait üzemeltető fizikai infrastruktúrának, az alábbi ábrán látható módon:
Ezen az oldalon útmutatást nyújtunk a műszaki döntéshozóknak azokról a megközelítésekről, amelyeket megfontolhat a kérések megfelelő bérlőhöz való leképezéséhez, valamint a megközelítésekben érintett kompromisszumokhoz.
Megjegyzés:
Ez a lap elsősorban HTTP-alapú alkalmazásokat, például webhelyeket és API-kat tárgyal. Számos alapelv vonatkozik azonban a más kommunikációs protokollokat használó több-bérlős alkalmazásokra is.
A bérlők azonosításának megközelítései
Több módon is azonosíthatja a bérlőt egy bejövő kéréshez.
Tartománynevek
Ha bérlőspecifikus tartomány- vagy altartományneveket használ, valószínű, hogy a kérések egyszerűen leképezhetők a bérlőkhöz a Host fejléc vagy egy másik HTTP-fejléc használatával, amely tartalmazza az egyes kérések eredeti állomásnevét.
Fontolja meg azonban a következő kérdéseket:
- Honnan tudják a felhasználók, hogy melyik tartománynevet használják a szolgáltatás eléréséhez?
- Van egy központi belépési pontja, például egy kezdőlap vagy egy bejelentkezési oldal, amelyet az összes bérlő használ? Ha igen, hogyan azonosítják a felhasználók a hozzáférést igénylő bérlőt?
- Milyen egyéb információkat használ a bérlőhöz való hozzáférés ellenőrzéséhez, például az engedélyezési jogkivonatokhoz? Az engedélyezési jogkivonatok tartalmazzák a bérlőspecifikus tartományneveket?
HTTP-kérés tulajdonságai
Ha nem használ bérlőspecifikus tartományneveket, előfordulhat, hogy a HTTP-kérés szempontjaival azonosítja azt a bérlőt, akire egy adott kérés vonatkozik. Vegyük például egy HTTP-kérést, amely a bérlő nevét azonosítja.tailwindtraders Ez a következő módon közölhető:
- Az URL-elérési út struktúrája, például
https://app.contoso.com/tailwindtraders/. - Egy lekérdezési sztring az URL-címben, például
https://contoso.com/app?tenant=tailwindtraders. - Egyéni HTTP-kérés fejléce, például
X-Tenant-Id: tailwindtraders.
Fontos
Az egyéni HTTP-kérésfejlécek nem hasznosak, ha a HTTP GET-kéréseket webböngészőből adják ki, vagy ahol a kéréseket valamilyen webproxy kezeli. Api létrehozásakor csak egyéni HTTP-fejléceket kell használnia a GET-műveletekhez, vagy ha a kérést kiosztó ügyfelet vezérli, és a kérésfeldolgozási lánc nem tartalmaz webes proxyt.
Ha ezt a megközelítést használja, vegye figyelembe a következő kérdéseket:
- Tudják a felhasználók, hogyan férhetnek hozzá a szolgáltatáshoz? Ha például egy lekérdezési sztringet használ a bérlők azonosításához, a központi kezdőlapnak a megfelelő bérlőhöz kell irányítania a felhasználókat a lekérdezési sztring hozzáadásával?
- Rendelkezik központi belépési ponttal, például egy kezdőlaptal vagy bejelentkezési oldallal, amelyet minden bérlő használ? Ha igen, hogyan azonosítják a felhasználók a hozzáférést igénylő bérlőt?
- Az alkalmazás biztosít API-kat? A webalkalmazás például egyoldalas alkalmazás (SPA) vagy egy API-háttérrendszerrel rendelkező mobilalkalmazás? Ha igen, előfordulhat, hogy api-átjárót vagy fordított proxyt használhat a bérlőleképezés végrehajtásához.
Jogkivonat jogcímek
Számos alkalmazás használ jogcímalapú hitelesítési és engedélyezési protokollokat, például OAuth 2.0-t vagy SAML-t. Ezek a protokollok engedélyezési jogkivonatokat biztosítanak az ügyfél számára. A jogkivonatok jogcímek készletét tartalmazzák, amelyek az ügyfélalkalmazással vagy a felhasználóval kapcsolatos információk. A jogcímek olyan információk közlésére használhatók, mint a felhasználó e-mail-címe. A rendszer ezután felveheti a felhasználó e-mail-címét, megkeresheti a felhasználó–bérlő megfeleltetést, majd továbbíthatja a kérést a megfelelő üzembe helyezéshez. Vagy akár a bérlőleképezést is belefoglalhatja az identitásrendszerbe, és hozzáadhat egy bérlőazonosító-jogcímet a jogkivonathoz.
Ha jogcímekkel rendeli le a kéréseket a bérlőkhöz, vegye figyelembe az alábbi kérdéseket:
- Használ egy jogcímet egy bérlő azonosításához? Melyik jogcímet fogja használni?
- Egy felhasználó több bérlő tagja lehet? Ha ez lehetséges, akkor hogyan választják ki a felhasználók azokat a bérlőket, amellyel dolgozni szeretnének?
- Létezik központi hitelesítési és engedélyezési rendszer az összes bérlőhöz? Ha nem, hogyan biztosítja, hogy minden jogkivonat-szolgáltató konzisztens jogkivonatokat és jogcímeket állítson ki?
API-kulcsok
Számos alkalmazás tesz elérhetővé API-kat. Ezek lehetnek belső használatra a szervezeten belül, vagy partnerek vagy ügyfelek általi külső használatra. Az API-k hitelesítésének gyakori módja egy API-kulcs használata. Az API-kulcsok minden kéréshez meg vannak adva, és a bérlő keresésére használhatók.
Az API-kulcsok többféleképpen is létrehozhatók. Gyakori módszer egy kriptográfiai véletlenszerű érték létrehozása és tárolása egy keresési táblában a bérlőazonosító mellett. Amikor egy kérés érkezik, a rendszer megkeresi az API-kulcsot a keresési táblában, majd megfelel egy bérlőazonosítónak. Egy másik módszer egy értelmes sztring létrehozása, benne egy bérlőazonosítóval, majd a HMAC-hoz hasonló megközelítéssel digitálisan alá kell írnia a kulcsot. Az egyes kérések feldolgozásakor ellenőrzi az aláírást, majd kinyeri a bérlőazonosítót.
Megjegyzés:
Az API-kulcsok nem biztosítanak magas szintű biztonságot, mert manuálisan kell létrehozni és felügyelni őket, és mivel nem tartalmaznak jogcímeket. Modernebb és biztonságosabb módszer egy jogcímalapú engedélyezési mechanizmus használata rövid élettartamú jogkivonatokkal, például OAuth 2.0 vagy OpenID Csatlakozás.
A következő kérdéseket kell figyelembe venni:
- Hogyan fog API-kulcsokat létrehozni és kiadni?
- Hogyan kapják meg és tárolják biztonságosan az API-ügyfelek az API-kulcsot?
- Szüksége van az API-kulcsok lejáratára egy idő után? Hogyan forgathatja el az ügyfelek API-kulcsait állásidő nélkül?
- Csak az ügyfél által hengerelt API-kulcsokra támaszkodva biztosít megfelelő szintű biztonságot az API-k számára?
Megjegyzés:
Az API-kulcsok nem azonosak a jelszavakkal. Az API-kulcsokat a rendszernek kell létrehoznia, és az összes bérlőben egyedinek kell lennie, hogy az egyes API-kulcsok egyedileg leképezhetők legyenek egyetlen bérlőre. Az API-átjárók( például az Azure API Management) API-kulcsokat hozhatnak létre és kezelhetnek, érvényesíthetik a bejövő kérelmek kulcsait, és leképezhetik a kulcsokat az egyes API-előfizetőkhöz.
Ügyféltanúsítványok
Az ügyféltanúsítvány-hitelesítést , más néven kölcsönös TLS-t (mTLS) gyakran használják a szolgáltatásközi kommunikációhoz. Az ügyféltanúsítványok biztonságos módot biztosítanak az ügyfelek hitelesítésére. A jogkivonatokhoz és jogcímekhez hasonlóan az ügyféltanúsítványok olyan attribútumokat is biztosítanak, amelyek a bérlő meghatározására használhatók. A tanúsítvány tárgya például tartalmazhatja a felhasználó e-mail-címét, amely a bérlő keresésére használható.
Ha ügyféltanúsítványokat szeretne használni a bérlőleképezéshez, vegye figyelembe a következőket:
- Hogyan fogja biztonságosan kiadni és megújítani a szolgáltatás által megbízhatónak minősíthető ügyféltanúsítványokat? Az ügyféltanúsítványok használata összetett lehet, mivel speciális infrastruktúrát igényelnek a tanúsítványok kezeléséhez és kiállításához.
- Az ügyféltanúsítványok csak kezdeti bejelentkezési kérelmekhez lesznek használva, vagy csatolva lesznek a szolgáltatáshoz érkező összes kéréshez?
- A tanúsítványok kiállításának és kezelésének folyamata kezelhetetlenné válik, ha nagy számú ügyféllel rendelkezik?
- Hogyan valósítja meg a leképezést az ügyféltanúsítvány és a bérlő között?
Fordított proxyk
A fordított proxy, más néven alkalmazásproxy http-kérések átirányítására használható. A fordított proxy fogad egy bejövő végponttól érkező kérést, és a kérést a számos háttérvégpont egyikére továbbítja. A fordított proxyk több-bérlős alkalmazások esetében hasznosak, mivel bizonyos kérelemadatok közötti leképezést elvégezhetik, és ki tudják kapcsolni a feladatot az alkalmazásinfrastruktúrából.
Számos fordított proxy használhatja a kérés tulajdonságait a bérlői útválasztással kapcsolatos döntés meghozatalához. Megvizsgálhatják a céltartománynevet, az URL-címet, a lekérdezési sztringet, a HTTP-fejléceket és még a jogkivonatokon belüli jogcímeket is.
Az Azure-ban a következő gyakori fordított proxyk használatosak:
- Az Azure Front Door egy globális terheléselosztó és webalkalmazási tűzfal. A Microsoft globális peremhálózatát használja gyors, biztonságos és nagy mértékben méretezhető webalkalmazások létrehozásához.
- Azure-alkalmazás Átjáró egy felügyelt webes forgalom terheléselosztója, amelyet a háttérszolgáltatással megegyező fizikai régióban helyez üzembe.
- Az Azure API Management API-forgalomra van optimalizálva.
- A kereskedelmi és nyílt forráskódú technológiák (amelyeket ön üzemeltet) közé tartozik az nginx, a Traefik és a HAProxy.
Érvényesítés kérése
Fontos, hogy az alkalmazás ellenőrizze, hogy a kapott kérések engedélyezve vannak-e a bérlő számára. Ha például az alkalmazás egyéni tartománynévvel rendeli le a kéréseket a bérlőhöz, akkor az alkalmazásnak továbbra is ellenőriznie kell, hogy az alkalmazás által fogadott összes kérelem jogosult-e az adott bérlőre. Annak ellenére, hogy a kérelem tartománynevet vagy más bérlőazonosítót tartalmaz, ez nem jelenti azt, hogy automatikusan hozzáférést kell adnia. Az OAuth 2.0 használatakor az ellenőrzést a célközönség és a hatókör jogcímeinek vizsgálatával hajtja végre.
Megjegyzés:
Ez a Microsoft Azure Well-Architected Framework zéró megbízhatósági biztonsági tervezési elvének része.
A kérelmek érvényesítésekor a következőket kell figyelembe vennie:
- Hogyan fogja engedélyezni az alkalmazáshoz érkező összes kérést? Engedélyeznie kell a kéréseket, függetlenül attól, hogy milyen megközelítést használ a fizikai infrastruktúrára való leképezéshez.
- Használjon megbízható, széles körben használt és jól karbantartott hitelesítési és engedélyezési keretrendszereket és köztes szoftvereket ahelyett, hogy az összes érvényesítési logikát saját maga valósítja meg. Például ne hozzon létre jogkivonat-aláírás érvényesítési logikát vagy ügyféltanúsítvány-titkosítási kódtárakat. Ehelyett használja az alkalmazásplatform (vagy ismert megbízható csomagok) érvényesített és tesztelt funkcióit.
Teljesítmény
A bérlőleképezési logika valószínűleg az alkalmazás minden kérésén fut. Fontolja meg, hogy a bérlőleképezési folyamat mennyire lesz skálázható a megoldás növekedésével. Ha például egy adatbázistáblát a bérlőleképezés részeként kérdez le, az adatbázis nagy mennyiségű terhelést támogat? Ha a bérlőleképezés egy jogkivonat visszafejtését igényli, a számítási követelmények idővel túl magasak lesznek? Ha a forgalom meglehetősen szerény, akkor ez valószínűleg nem befolyásolja az általános teljesítményt. Ha azonban nagy léptékű alkalmazással rendelkezik, a leképezéssel járó többletterhelés jelentőssé válhat.
Munkamenet-affinitás
A bérlőleképezési logika teljesítményterhelésének csökkentésének egyik módszere a munkamenet-affinitás használata. Ahelyett, hogy minden kérésen végrehajtanák a leképezést, fontolja meg, hogy csak az egyes munkamenetek első kérésén számítsa ki az információkat. Az alkalmazás ezután egy munkamenet-cookie-t biztosít az ügyfélnek. Az ügyfél visszaküldi a munkamenet-cookie-t a szolgáltatásnak az adott munkameneten belüli összes további ügyfélkéréssel.
Megjegyzés:
Az Azure számos hálózati és alkalmazásszolgáltatása képes munkamenet-cookie-kat kiadni, és natív módon irányítani a kéréseket munkamenet-affinitás használatával.
A következő kérdéseket kell figyelembe venni:
- Használhat munkamenet-affinitást a bérlőkhöz való leképezési kérelmek többletterhelésének csökkentéséhez?
- Milyen szolgáltatásokat használ a kérelmeknek az egyes bérlők fizikai üzembe helyezéséhez való átirányításához? Ezek a szolgáltatások támogatják a cookie-alapú munkamenet-affinitást?
Bérlői migrálás
A bérlőket gyakran át kell helyezni az új infrastruktúrába a bérlői életciklus részeként. Amikor egy bérlőt áthelyeznek egy új üzembe helyezésre, az általuk elért HTTP-végpontok megváltozhatnak. Ha ez történik, vegye figyelembe, hogy a bérlőleképezési folyamatot frissíteni kell. Előfordulhat, hogy a következőket kell figyelembe vennie:
- Ha az alkalmazás tartományneveket használ a leképezési kérelmekhez, akkor a migráláskor DNS-módosításra is szükség lehet. A DNS-módosítás a DNS-szolgáltatás DNS-bejegyzéseinek élettartamától függően időbe telhet az ügyfelek felé történő propagáláshoz.
- Ha az áttelepítés a migrálási folyamat során módosítja a végpontok címét, fontolja meg a bérlő kéréseinek ideiglenes átirányítását egy automatikusan frissülő karbantartási lapra.
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerző:
- Daniel Scott-Raynsford | Partnertechnológiai stratéga
Egyéb közreműködők:
- John Downs | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
- Paolo Salvatori | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
- Arsen Vladimirskiy | Az Azure-hoz készült FastTrack vezető ügyfélmérnöke
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
További lépések
Megismerheti a több-bérlős alkalmazások tartományneveivel kapcsolatos szempontokat.