Vertaa käyttövelvoitteita käyttöönottomerkintöjen sijaan
Itseisännöity ja SaaS kuvaa toimitusmalleja, eivät täydellisiä tietoturva- tai luotettavuustuloksia. Itseisännöity todennusalusta voi antaa organisaatiolle paremman hallinnan infrastruktuurista ja lisätä samalla ylläpitovelvoitteita. SaaS-palvelu voi siirtää osia ylläpidosta toimittajalle jättäen asiakkaan määritykset, käyttöoikeudet ja datapäätökset organisaatiolle. Hyödyllinen vertailu on näyttöön perustuva vastuumatriisi varsinaiselle palvelulle, ei väite, että yksi tarra on aina turvallisempi.
Microsoftin jaetun vastuun opas havainnollistaa, kuinka vastuut muuttuvat paikallisten, IaaS-, PaaS- ja SaaS-mallien välillä. Se myös tunnistaa asiakkaiden vastuut. Tämä lähde kuvaa Microsoftin pilvikehystä; se ei ole sopimukseen perustuva EmailAuth -jako tai todiste siitä, että EmailAuth tarjoaa itseisännöityä tuotetta. Tämä käsikirjoitus ehdottaa vertailumenetelmää ilman ohjelmiston käyttöönottoa tai infrastruktuurin käyttöä.
Määrittele, mitä kukin vaihtoehto todella sisältää
Tallenna tuettu tuoteversio, käyttöönottomalli, ympäristön raja, infrastruktuurin tarjoaja ja toimittajan tuki, joka on kuvattu nykyisessä dokumentaatiossa tai hyväksytyssä tarjouksessa. "itseisännöity" saattaa tarkoittaa ohjelmistoa, jota käytetään omistamalla laitteistolla tai pilviinfrastruktuurilla; näissä järjestelyissä voidaan jakaa fyysiset, käyttöjärjestelmä- ja sovellusvastuut eri tavalla. "Yksityinen" voi tarkoittaa verkkoyhteyksiä, omistettuja resursseja tai sopimusjärjestelyä. Mikään näistä termeistä ei saa korvata konkreettista arkkitehtuuria ja tukirajaa.
Kysy, mitä komponentteja on olemassa ja kuka niitä käyttää: sovelluksen ajonaika, tietovarastot, jonot, raporttien käsittely, todennus, varmuuskopiot, valvonta- ja hallintaliittymät. Käsittele tätä luetteloa kysymyksinä, älä väittämänä, että alusta käyttää näitä komponentteja. Jos toimittaja ei voi toimittaa todisteita väitetystä käyttöönottovaihtoehdosta, merkitse vaihtoehto vahvistamattomaksi sen sijaan, että täytät arkkitehtuuria toisen tuotteen dokumentaatiosta.
Määritä ylläpito ja vaihda omistajaa
Tunnista jokaiselle tuetulle komponentille, kuka sen korjaa, kuka hyväksyy muutokset, kuka ajoittaa huollon ja kuka varmistaa palautuksen. Toimittaja voi julkaista päivityksiä, kun asiakkaan on asennettava ne. Hallittu palvelu voi käyttää päivityksiä, kun taas asiakkaan on arvioitava muutoksia integraatioihin tai käyttöoikeuskäytäntöön. Vastuu korjauksen levittämisestä ei ole sama kuin velvollisuus varmistaa, että asiakkaan varsinainen työnkulku toimii edelleen sen jälkeen.
Microsoftin viitekehys erottaa taustalla olevan pilviinfrastruktuurin asiakastiedoista, identiteeteistä ja määrityksistä. Käytä tätä eroa vertailussa kopioimatta sen matriisia yleissopimukseksi. Varsinaisen toimittajan tulee ilmoittaa vastuunsa ja poissulkemisensa. Asiakkaan tulee tunnistaa nimetty sisäinen omistaja säilytetyille velvoitteille sen sijaan, että määrittäisi ne epämääräisesti "IT". Tuntemattomat vastuut ovat aukko, vaikka käyttöönottomalli muuten olisi sopiva.
Kartoita ulkoiset riippuvuudet selkeästi
Todennustoiminto voi riippua DNS isännöinnistä, lähetyspalveluntarjoajista, identiteettijärjestelmistä, raporttilähteistä ja ulkoisesta valvonnasta. Alustan siirtäminen ei siirrä automaattisesti näiden riippuvuuksien hallintaa. Itseisännöity sovellus ei voi muuttaa toimittajan lähetyskäyttäytymistä ilman asianmukaista valtuutusta, eikä SaaS-hallintapaneeli voi taata, että jokainen vastaanottaja toimittaa raportteja. Kirjaa muistiin riippuvuuden omistaja, tuettu käyttöliittymä, vikatila ja sen tilan tarkistamiseen käytetyt todisteet.
RFC 9990 määrittelee DMARC kokonaisraportointi erillisenä raportointiprosessina. Sen saatavuutta ja kattavuutta ei pitäisi päätellä pelkästään alustan käytettävyyden perusteella. RFC 9989 määrittää toimialueen todennussuhteet, jotka riippuvat myös todellisesta lähetyskokoonpanosta. Toimintamatriisin tulisi erottaa alustan saatavuus havaintojen täydellisyydestä ja lähettäjän autentikoinnin oikeellisuudesta.
Arvioi käyttöoikeudet ja vuokralaisen vastuut
Azuren usean vuokralaisen identiteettiopastus erottaa henkilöllisyyden, valtuutuksen ja oikeudet. Käyttöönottovertailussa tulisi kysyä, kuka määrittää identiteetintarjoajan luottamuksen, käyttäjäroolit, palveluiden identiteetit, vuokraajan sidokset ja vientioikeudet. Erillinen käyttöönotto ei automaattisesti tarkoita, että jokaisen sen sisällä olevan käyttäjän pitäisi käyttää kaikkia tietoja. Jaettu palvelu ei automaattisesti tarkoita, että asiakastiedot paljastuvat vuokralaisten kesken.
Vaadi todellisia todisteita tuetuista ohjauksista ja hallinnollisista rajoista. Kirjaa toimittajan tuki-, hätäkäyttö- ja auditointivastuut tarvittaessa. Älä oleta, että asiakkaan omistus infrastruktuuriin eliminoi toimittajan pääsyn tai että SaaS-omistus eliminoi asiakkaan roolin käyttäjien syrjäyttämisessä. Tämän artikkelin käyttöoikeuksia, tilejä tai suojausasetuksia ei muutettu. nämä ovat valtuutetun tarkastelun kysymyksiä.
Vertaa takaisinperinnän näyttöä ja toimintakykyä
Kysy, mitä varmuuskopiointi-, palautus- ja katastrofipalautusvelvoitteita kukin vaihtoehto määrittää, mitkä komponentit kuuluvat ja mitkä todisteet osoittavat palautumisen. Varmuuskopiointi ei ole onnistunut palautustesti. Toimittajan saatavuusilmoitus ei ole todiste siitä, että yksittäisen asiakkaan tiedot ja integraatiot voidaan palauttaa ostajan vaatimusten mukaisesti. Tallenna todelliset tuetut sitoumukset ja asiakkaan jäljellä oleva varmennustyö ilman palautusaikojen keksimistä.
Arvioi työmäärä vain hyväksyttyjen organisaatiopanosten perusteella. Sisällytä käyttöjärjestelmän tai ajonaikaisen ylläpidon säilytys, sovelluspäivitykset, tapauksiin reagointi, käyttöoikeuksien tarkistus, integrointituki ja palautusharjoitukset. Älä oleta, että itseisännöinti on halvempaa, koska tilausmaksut vaihtelevat, tai SaaS on halvempaa, koska infrastruktuurityöt ovat vähemmän näkyviä. Tässä luonnoksessa ei lasketa henkilöstötarpeita, kokonaiskustannuksia tai säästöjä. Se tarjoaa luokkia läpinäkyvää vertailua varten.
Toiminta-vastuutaulukko
Luo yksi rivi kutakin velvoitetta kohden, jossa on komponentti, riippuvuus, asiakkaan omistaja, toimittajan omistaja, toteuttajaosapuoli, hyväksyntäosapuoli, todisteiden viittaus, tarkastelun laukaisin ja ratkaisematon aukko. Erota vastuu tehtävän suorittamisesta vastuullisuudesta sen tuloksesta. Lisää tuettu käyttöönottoversio ja sopimusviite, jotta varaus voidaan tarkistaa, kun jompikumpi muuttuu. Pidä valtuustiedot ja arkaluonteiset arkkitehtoniset yksityiskohdat poissa laajalti jaetuista kopioista.
Päätösosiossa tulee tunnistaa ei-hyväksyttävät puutteet, hyväksytyt korvaavat tarkastukset ja riippuvuudet, jotka vaativat lisätodisteita. Jaetuksi merkityn rivin tulee nimetä kanavanvaihto: mitä kukin osapuoli tekee, mikä signaali laukaisee seuraavan vaiheen ja kuka varmistaa valmistumisen. "Jaettu" ilman määriteltyä kanavanvaihtoa voi kätkeä tärkeimmän vikarajan. Tätä ehdotettua laskentataulukkoa ei ole täytetty todellisella toimittajasopimuksella tai toimintaympäristöllä.
Kuvitteellinen diagnoosi: päivitykset ilman asennuksen omistajaa
Kuvitteellinen tiimi vertaa hallittua palvelua itse isännöimään vaihtoehtoon. Itse isännöimä toimittaja lupaa toimittaa tietoturvapäivitykset, ja ostaja käsittelee korjauksia aluksi toimittajan omistamana. Yksityiskohtainen tarkastelu paljastaa, että toimittaja jakelee paketteja, kun taas asiakkaan on ajoitettava asennus, arvioitava yhteensopivuus ja tarkistettava tuloksena oleva palvelu. Mikään sisäinen tiimi ei ole hyväksynyt tätä työtä.
Ehdotettu vastaus on valtuutetun omistajan nimeäminen ja kapasiteetin arvioiminen ennen vaihtoehdon valintaa tai tuetun järjestelyn valitseminen eri vastuunjaolla. Tiimi ei saa julistaa tuotetta vaaralliseksi vain siksi, että velvoite on olemassa. Tämä skenaario on kuvitteellinen, eikä se kuvaa EmailAuth tarjouksia, todellista puuttuvaa korjaustiedostoa tai tämän työn aikana suoritettua käyttöönottoa.
Tee päätös niin, että aukot näkyvät
Perusteltava vertailu selittää, mitkä velvoitteet liikkuvat, mitkä säilyvät ja mitkä riippuvuudet ennallaan. Se ei pidä valvontaa todisteena pätevyydestä tai ulkoistamista todisteena täydellisestä kattavuudesta. Suositeltu malli riippuu tuetuista tuotevaihtoehdoista, organisaatiokapasiteetista, vaadituista ohjauksista ja todistetuista toimittajasitoumuksista.
Luettelo vaatii näyttöön perustuvan toiminta-vastuu- ja riippuvuusmatriisin. Alkuperäinen esine jää auki. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos tarjoaa puitteet ja kuvitteellisen harjoituksen, ei toteutettua arkkitehtuuria tai hyväksyttyä vastuusopimusta. Julkaiseminen edellyttää ajantasaista näyttöä todellisista vertailtavista vaihtoehdoista ja selkeän omistajuuden jakamista säilytettävälle teokselle.