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.
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!
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?#
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.
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#
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.
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.
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ä.
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ä.
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?#
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.
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.
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.
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.
