Lopullinen opas monivuokraajatodennuksen ja -valtuutuksen määrittämiseen
Monivuokraajasovelluksen luominen voi olla monimutkaista. Tässä artikkelissa on koottu kaikki aiemmat kirjoituksemme monivuokraaja- ja organisaatiostrategioista. Toivomme, että se voi auttaa sinua säästämään aikaa ja pääsemään alkuun helposti.
Product & Design
Monivuokraajasovelluksen rakentaminen voi olla haastavaa, koska on otettava huomioon monia näkökulmia. Tämä artikkeli kokoaa kaikki aiemmat blogikirjoituksemme monivuokraaja- ja organisaatiokäytännöistä. Nopeaa aloitusta ja ajan säästämistä varten tutustu vain tähän artikkeliin, se sisältää kaiken tarvitsemasi!
Yleiset ohjeet on esitetty seuraavissa vaiheissa:
- Ymmärrä monivuokraaja-arkkitehtuuri
- Kartoitamme monivuokraajasovelluksesi käyttötapaukset
- Saavuta vuokraajan eristys
- Määritä, miten haluat hallita identiteetit
- Valitse sopivat valtuutusmallit
Mitä on monivuokraaja-arkkitehtuuri
Ohjelmiston monivuokraus on ohjelmistoarkkitehtuuri, jossa yksi instance of ohjelmisto toimii palvelimella ja palvelee useita vuokralaisia. Tällaisella tavalla suunnitellut järjestelmät ovat "yhteisiä" (eivät "dedikoituja" tai "eristettyjä").
Vuokralainen on ryhmä käyttäjiä, joilla on yhteinen pääsy ja tiettyjä käyttöoikeuksia ohjelmistoinstanssiin.
Yksi monivuokraamisen keskeisistä ajatusmalleista on "yhteinen". Monivuokrauksen laajemmassa määritelmässä sillä, että sovellus on monivuokraaja, ei tarkoita, että jokainen ratkaisun komponentti on jaettu. Pikemminkin se tarkoittaa, että ainakin jotkut ratkaisun osat uudelleenkäytetään usean vuokralaisen kesken. Tämän termin laajamittainen ymmärtäminen voi auttaa sinua paremmin ymmärtämään asiakkaasi tarpeita ja sitä, mistä he tulevat.
Kun ymmärrät monivuokraaja-arkkitehtuurin, seuraava askel on soveltaa sovellustasi todellisiin tilanteisiin keskittyen tiettyihin tuote- ja liiketoimintatarpeisiin.
Mitä ovat monivuokraajasovellusten käyttötapaukset?
Monivuokraus SaaS:ssä
Monivuokraajasovellukset löytävät usein paikkansa yritys-asiakas (B2B) ratkaisuissa, kuten tuottavuustyökalut, yhteistyöohjelmistot ja muut ohjelmistopalvelutuotteet (SaaS). Tässä kontekstissa jokainen "vuokralainen" edustaa tyypillisesti yritysasiakasta, jolla voi olla useita käyttäjiä (sen työntekijöitä). Lisäksi yritysasiakkaalla voi olla useita vuokralaisia, jotka edustavat erillisiä organisaatioita tai liiketoimintaosastoja.
Monivuokraus yleisissä B2B käyttötapauksissa
B2B-sovellukset menevät SaaS-tuotteiden yli ja usein liittyvät monivuokraajasovellusten käyttöön. B2B-kontekstissa nämä sovellukset toimivat yleisenä alustana eri tiimeille, yritysasiakkaille ja kumppaniyhtiöille pääsyä sovelluksillesi.
Esimerkiksi harkitse kyydinjakoyhtiötä, joka tarjoaa sekä B2C että B2B sovelluksia. B2B-sovellukset palvelevat useita yritysasiakkaita, ja monivuokraaja-arkkitehtuurin käyttöönotto voi auttaa heidän työntekijöiden ja resurssien hallinnassa. Esimerkiksi, jos yritys haluaa ylläpitää yhtenäistä käyttäjätunnistusjärjestelmää, se voi suunnitella arkkitehtuurin seuraavan esimerkin mukaisesti:
Sarahilla on sekä henkilökohtainen että liiketoimintatunnus. Hän käyttää kyydinjakopalvelua matkustajana ja toimii myös kuljettajana vapaa-ajallaan. Ammattimaisessa roolissaan hän myös hallitsee liiketoimintaansa ja käyttää tätä liiketoiminnan tunnusta ollakseen kumppani Yrityksen 1 kanssa.
Miksi sinun pitäisi ottaa monivuokraus käyttöön SaaS-tuotteessa
Skaalaaminen monivuokrauksella
Yritysliiketoiminnassa monivuokraus on avain tehokkaaseen saatavuustarpeiden, resurssihallinnan, kustannusten hallinnan ja tietoturvan täyttämiseen. Teknologisella tasolla monivuokraalähestymistavan omaksuminen tehostaa kehitysprosessejasi, minimoi teknisiä haasteita ja edistää saumattomasti laajenemista.
Yhtenäisen kokemuksen luominen
Kun tarkastellaan SaaS-tuotteiden juuria, se on verrattavissa rakennukseen, joka pitää sisällään useita asuntoja. Kaikki vuokralaiset jakavat yhteisiä hyödykkeitä kuten vesi, sähkö ja kaasu, mutta heillä on itsenäinen hallinta omasta tilasta ja resursseista. Tämä lähestymistapa yksinkertaistaa omaisuuden hallintaa.
Turvallisuuden varmistaminen vuokralaisen eristyksen kautta
Monivuokrausarkkitehtuurissa termi "vuokralainen" otetaan käyttöön luomaan rajoja, jotka erottavat ja turvaavat eri vuokralaisten resurssit ja tiedot jaetussa instanssissa. Tämä takaa, että jokaisen vuokralaisen tiedot ja toiminnot pysyvät erillisinä ja turvallisina, vaikka ne hyödyntäisivät samaa pohjarakennetta.
Miksi sinun pitäisi saavuttaa vuokralaisen eristys?
Kun keskustellaan monivuokraajasovelluksista, on aina tarpeen saavuttaa vuokralaisen eristys. Tämä tarkoittaa eri vuokralaisten tietojen ja resurssien erillään ja turvassa pitämistä jaetussa järjestelmässä (esimerkiksi pilvi-infrastruktuuri tai monivuokraajasovellus). Tämä estää luvattomat yritykset päästä toisen vuokralaisen resursseihin.
Vaikka selitys saattaa vaikuttaa abstraktilta, käytämme esimerkkejä ja keskeisiä yksityiskohtia tarkempaan selitykseen eristysajattelusta ja parhaista käytännöistä vuokralaisen eristyksen saavuttamiseen.
Vuokralaisen eristys ei ole ristiriidassa monivuokraamisen "yhteisen" ajattelumallin kanssa
Tämä johtuu siitä, että vuokralaisen eristys ei ole välttämättä infrastruktuuriresurssitason konstruktio. Monivuokrauksen ja eristyksen maailmassa jotkut näkevät eristyksen ankarana jakona infrastruktuuriresurssien välillä. Tämä johtaa yleensä malliin, jossa jokaisella vuokralaisella on erillinen tietokantakokoelma, laskentainstansseja, tilejä tai yksityisiä pilviä. Yhteisten resurssien tilanteissa, kuten monivuokraajasovelluksissa, eristyksen saavuttaminen voi olla looginen konstruktio.
Vuokralaisen eristys keskittyy yksinomaan "vuokralaisen" kontekstin käyttöön, jotta resurssien käyttö voidaan rajoittaa. Se arvioi nykyisen vuokralaisen kontekstia ja käyttää sitä kontekstia määrittääkseen, mitkä resurssit ovat kyseiselle vuokralaiselle käytettävissä.
Todennus ja valtuutus eivät ole yhtä kuin "eristys"
Todennuksen ja valtuutuksen käyttäminen pääsyn hallitsemiseksi SaaS-ympäristöissäsi on tärkeää, mutta se ei riitä täydelliseen eristykseen. Nämä mekanismit ovat vain osa turvallisuuspalapeliä.
Usein kysytään, voinko käyttää yleisiä valtuutusratkaisuja ja roolipohjaista pääsynhallintaa saavuttaakseni vuokralaisen eristyksen?
Tässä on tilanne, voit rakentaa monivuokraajasovelluksen, mutta et voi sanoa saavuttaneesi ja ottaneesi käyttöön vuokralaisen eristysstrategioita parhaana käytäntönä. Emme yleensä suosittele sitä, koska
Havainnollistamiseksi harkitse tilannetta, jossa olet asentanut todennuksen ja valtuutuksen SaaS-järjestelmääsi. Kun käyttäjät kirjautuvat sisään, he saavat tunnuksen, joka sisältää tietoja heidän roolistaan, joka sanelee, mitä he voivat tehdä sovelluksessa. Tämä lähestymistapa lisää turvallisuutta, mutta ei takaa eristystä.
Käytä "organisaatiota" edustamaan SaaS-tuotteen vuokralaista vuokralaisen eristyksen saavuttamiseksi
Pelkkään todennukseen ja valtuutukseen luottaminen ei estä käyttäjää, jolla on oikea rooli, pääsemästä toisen vuokralaisen resursseihin. Joten meidän on otettava käyttöön "vuokralaisen" konteksti, kuten vuokralaisen tunnisteen, resurssien käyttöoikeuden rajoittamiseksi.
Tässä vuokralaisen eristys astuu kuvaan. Se käyttää vuokralaiseen liittyviä tunnisteita rajojen luomiseen, aivan kuin seinät, ovet ja lukot, mikä takaa selkeän eron vuokralaisten välillä.
Identiteetin hallinta monivuokraajasovelluksissa
Keskustelimme vuokralaisen eristyksestä, mutta entä identiteetit? Kuinka päätät, jos identiteettisi tulisi olla "eristetty" vai ei?
Usein on epäselvyyttä "identiteetin eristyksen" käsitteestä. Se voi viitata tilanteisiin, joissa yksi tosielämän käyttäjä on kaksi identiteettiä ihmisten yleisessä ymmärryksessä.
- Molemmat identiteetit voivat olla olemassa yhdessä identiteettijärjestelmässä. Esimerkiksi Sarahilla voi olla henkilökohtainen sähköposti rekisteröitynä rinnakkain yrityksen sähköposti, joka on yhdistetty kertakirjautumisella (SSO).
- Käyttäjät ylläpitävät kahta erillistä identiteettiä erillisissä identiteettijärjestelmissä, jotka edustavat täysin erillisiä tuotteita. Nämä tuotteet eivät liity toisiinsa lainkaan.
Ajoittain näitä tilanteita kutsutaan "Identiteettieri". Kuitenkaan tämä merkintä ei välttämättä auta päätöksen tekemisessä.
Pikemminkin kuin päättämään, tarvitsetko "identiteettieristäytymistä", harkitse
Tämä vastaus voi ohjata järjestelmäsi suunnittelua. Lyhyt vastaus monivuokraajasovellukseen liittyen,
Monivuokraajasovelluksissa identiteetit, toisin kuin vuokralaiseen liittyvät erityiset resurssit ja tiedot, jaetaan useiden vuokralaisten kesken. Kuvittele itsesi rakennuksen valvojana; et haluaisi ylläpitää kahta erillistä nimilevyä hallitsemaan vuokralaisiesi identiteettejä.
Kun pyrit vuokralaisen eristykseen, olet saattanut havaita toistuvan painotuksen termillä "organisaatio", usein pidettävänä parhaana käytäntönä monivuokraajasovellusten rakentamisessa.
Käyttämällä "organisaation" käsitettä, voit saavuttaa vuokralaisen eristyksen monivuokraajasovelluksessasi samalla säilyttäen yhtenäisen identiteettijärjestelmän.
Kuinka valita ja suunnitella sopiva valtuutusmalli
Kun valitset oikeaa valtuutusmallia, mieti näitä kysymyksiä:
- Kehitätkö B2C-, B2B- tai molempien tyyppisiä tuotteita?
- Onko sovelluksellasi monivuokraaja-arkkitehtuuri?
- Onko sovelluksessasi tarvitse tietty eristyksen taso, kuten liiketoimintayksikön määrittelemä?
- Mitä käyttöoikeuksia ja rooleja on määritettävä organisaation kontekstissa ja mitkä eivät?
Mitä erilaisia valtuutusmalleja on saatavilla Logtossa?
Roolipohjainen pääsynhallinta
RBAC (Roolipohjainen pääsynhallinta) on menetelmä, jolla käyttäjäoikeudet myönnetään heidän rooliensa perusteella, mikä mahdollistaa resurssien käytön tehokkaan hallinnan.
Tämä yleinen tekniikka tukee käyttövalvontaa ja on Logton valtuutusominaisuuksien keskeinen osa. Kattavana identiteetin hallintaratkaisualustana Logto tarjoaa räätälöityjä ratkaisuja eri tasoille ja tahoille, palvellen kehittäjiä ja yrityksiä erilaisten tuotearkkitehtuurien osalta.
API: n roolipohjainen pääsynhallinta
Suojataksesi yleisiä API-resursseja, jotka eivät ole erityisiä millekään organisaatiolle eivätkä tarvitse kontekstirajoitteita, API RBAC -ominaisuus on ihanteellinen.
Rekisteröi vain API ja tallenna käyttöoikeudet kullekin resurssille. Sitten hallinnoi käyttöoikeuksia käyttäjien ja roolien välisen suhteen kautta.
API-resurssit, roolit ja käyttöoikeudet on täällä "demokratisoitu" yhtenäisen identiteettijärjestelmän alla. Tämä on melko yleistä B2C-tuotteessa, jossa on vähemmän hierarkiaa ja ei tarvita kovin syvää eristystasoa.
Organisaation roolipohjainen pääsynhallinta
B2B- ja monivuokraajaympäristössä vuokralaisen eristys on välttämätön. Tämän saavuttamiseksi organisaatioita käytetään eristyksen kontekstina, mikä tarkoittaa, että RBAC toimii vain, kun käyttäjä kuuluu tiettyyn organisaatioon.
Organisaation RBAC keskittyy pääsynhallintaan organisaatiotasolla eikä API-tasolla. Tämä tarjoaa merkittävää joustoa organisaatiotason itsehallintaan pitkällä aikavälillä, mutta kuitenkin yhtenäisessä identiteettijärjestelmässä.
Organisaation RBAC: n keskeinen ominaisuus on, että roolit ja käyttöoikeudet ovat yleensä samoja kaikissa organisaatioissa oletuksena, mikä tekee Logton "organisaatiomallista" äärimmäisen merkityksellisen kehityksen tehokkuuden parantamisessa. Tämä on linjassa monivuokraajasovellusten jakamisfilosofian kanssa, jossa käyttövalvontakäytännöt ja identiteetit ovat yhteisiä infrastruktuurin osia kaikissa vuokralaisissa (sovellusvuokralaiset), yleinen käytäntö SaaS-tuotteissa.
Loppusanat
Tämä artikkeli tarjoaa kaiken, mitä tarvitset monivuokraajasovellusten valmistautumiseen ja määrittämiseen. Kokeile Logtoa jo tänään ja aloita parhaiden käytäntöjen soveltaminen monivuokraajasovellusten kehityksessä organisaatioiden avulla.