Esitä kysymyksiä, joihin voidaan vastata todisteilla
Yrityksen todennuskyselylomakkeen tulisi yhdistää liiketoiminnan vaatimukset tuettuun toimintaan, toimintavastuuseen ja hyväksyntätodisteisiin. Pitkä lista kyllä-tai ei-ominaisuuskysymyksiä voi kätkeä tärkeitä rajoituksia: toimittaja voi tukea laajaa luokkaa, mutta ei tue ostajan tarvitsemaa tiettyä vuokralaista, elinkaari- tai käyttöönottokäyttäytymistä. Kyselylomakkeessa tulee siksi kysyä, mitä tuetaan, missä kokoonpanossa, kuka sitä käyttää ja miten vastaus voidaan varmistaa.
Tässä artikkelissa ehdotetaan kyselylomakerakennetta, eikä siinä mainita, että EmailAuth toteuttaa mitään lueteltuja ominaisuuksia. Yhtään toimittajaa ei otettu yhteyttä eikä kyselyyn saatu vastausta. Microsoftin jaetun vastuun opas ja Azuren usean vuokralaisen identiteettiopastus antaa virallisia esimerkkejä eroista, joilla on merkitystä, mutta ne eivät voi korvata arvioitavan tuotteen nykyistä näyttöä.
Aloita laajuudesta ja päätöksen omistajuudesta
Tallenna ehdotettu asiakaspopulaatio, toimialueet, lähetystyönkulut, käyttöönottovaihtoehto, vaaditut integraatiot ja aiotut järjestelmänvalvojat. Tunnista, mitkä vaatimukset ovat pakollisia, mitkä ovat mieltymyksiä ja mitkä tarvitsevat pätevän laki-, turvallisuus- tai kaupallisen arvioijan. Kysely, jolla ei ole määriteltyä laajuutta, voi tuottaa vastauksia, jotka ovat teknisesti totta toiselle painokselle tai ympäristölle. Säilytä tuoteversio ja tarjoa viite jokaisen vastauksen yhteydessä.
Pyydä toimittajaa erottamaan toteutettu tuki, kokoonpanosta riippuvainen tuki, suunniteltu työ ja ei-tuetut vaatimukset. Älä muuta tiekartan päivämäärää nykyiseksi valmiudeksi. Jos vastaus riippuu toisesta palvelusta, tunnista tämä riippuvuus ja vastuullinen osapuoli. Ostajan tulee myös dokumentoida omat velvoitteensa; toimittaja ei voi osoittaa täydellistä työnkulkua, jos vaaditut asiakkaan DNS , identiteetti- tai käyttöpäätökset jäävät määrittelemättömiksi.
Peitä identiteetti, roolit ja vuokralaisen rajat
Kysy, kuinka käyttäjät todentavat, kuinka identiteetit sidotaan vuokralaisiin ja kuinka käyttöoikeudet myönnetään verkkotunnuksille, raporteille, viennille ja hallinnollisille toiminnoille. Azuren identiteettiohjeet erottavat todennuksen rooli- tai resurssipohjaisesta valtuutuksesta ja kaupallisista oikeuksista. Pohdi näitä eroja erillisissä kysymyksissä. Sanonta, että SSO on tuettu, ei tarkoita asiakkaan eristäytymistä tai roolien vähentämisen vaikutusta olemassa olevaan istuntoon.
Sisällytä kysymyksiä palveluiden identiteetistä, käyttäjien elinkaarista, toimittajan tuen saatavuudesta ja auditointitodisteista. Vaadi nykyinen selitys käytöstäpoisto- ja peruutuskäyttäytymisestä sen sijaan, että olettaisi, että hallintaintegraatio käsittelee jokaisen pääsypolun. Pyydä valtuutettuja synteettisiä negatiivisia testejä, jotka osoittavat, että yksi vuokralainen ei voi lukea, viedä tai muuttaa toisen vuokralaisen resursseja. Pelkästään tuotteen kuvakaappaus tai rooliluettelo ei tarjoa tätä näyttöä.
Kysy, kuinka autentikointihavainnot saadaan
Dokumentoi, mistä lähteistä alusta kerää, miten niiden kattavuus on kuvattu ja miten tuettomia tai puuttuvia havaintoja esitetään. RFC 9990 määrittelee DMARC kokonaisraportointi, jolla on oma raportointi- ja toimitusprosessinsa. Alustan kyky jäsentää raportteja ei takaa, että jokainen vastaanottaja lähettää ne tai että jokainen laillinen lähettäjä on edustettuna tietyn ajanjakson aikana.
Kysy, kuinka tuote säilyttää alkuperäisen raportin alkuperän, käsittelee kaksoiskappaleita ja selittää tulkintarajat. Jos se yhdistää palveluntarjoajan toimitustapahtumat todennusraportteihin, kysy, mitkä tunnisteet sallivat linkityksen ja ovatko päätelmät viestitason vai stream-tason. Älä pyydä yleistä toimitustakuuta todennustiedoista. Kyselylomakkeen tulee tehdä tuotteen havainnointirajat näkyviksi sen sijaan, että se rohkaisee perusteettomiin väitteisiin täydellisestä kattavuudesta.
Selvitä käyttöönotto- ja operatiiviset vastuut
Kysy, mitä käyttöönottovaihtoehtoja tuetaan tällä hetkellä ja mitä kukin sisältää. Määritä, kuka korjaa infrastruktuurin, päivittää sovelluksen, hallitsee identiteettejä, valvoo tiedonkeruuta, suorittaa palautuksen ja käsittelee tapauksia. Microsoftin jaetun vastuun viitekehys havainnollistaa, miksi velvoitteet vaihtelevat palvelumalleittain, mutta varsinaisen toimittajan on tarjottava oma tuettu allokaationsa. Jaettuna merkityn vastauksen tulee kuvata kanavanvaihdon ja vahvistuksen omistajaa, ei vain jakaa valintaruutua kahden osapuolen välillä.
Yksityisiä tai omistettuja vaihtoehtoja varten kysy erikseen verkkopoluista, tiedonkäsittelystä, tukikäytöstä ja ulkoisista riippuvuuksista. Älä päättele eristystä arkkitehtuurimerkinnästä. Vaadi todisteita asianmukaisista rajoista ja läpinäkyvistä työmääräoletuksista mitoitusta varten. Itse kyselylomakkeen ei pitäisi sallia käyttöönottoa, palomuurimuutosta tai tiedonsiirtoa; nämä toimet edellyttävät erillistä hyväksyttyä täytäntöönpanotyötä.
Sisällytä tietojen käsittely- ja auditointivaatimukset
Kysy, mitä tietoja säilytetään, mihin tuetut kokoonpanot sijoittavat ne, kuka voi käyttää niitä ja miten säilyttäminen, poistaminen ja vienti toimivat. Erottele ensisijaiset tiedot, lokit, varmuuskopiot ja tukiartefaktit. Tässä artikkelissa ei määritetä lainmukaisuutta eikä vahvisteta toimittajan asuinpaikkakäyttäytymistä. Asianmukaisen pätevän omistajan tulee tarkistaa sopimus- ja säädösvaatimukset käyttämällä nykyistä näyttöä.
Tarkastettavuuden varmistamiseksi kysy, mitkä toiminnot tallennetaan, sisällytetäänkö evätyt yritykset, miten toimijan ja vuokraajan konteksti esitetään ja kuka voi viedä tai muuttaa säilytysasetuksia. Microsoft Entran auditointilokin dokumentaatio on esimerkki virallisesta toimintalokin kuvauksesta, ei todiste toisen tuotteen kattavuudesta. Vaadi tuotekohtaisia näytteitä ja rajoja sen sijaan, että hyväksyisi sanan audit täydellisenä vastauksena.
Tee työmäärästä ja kaupallisista oletuksista läpinäkyviä
Ilmoita odotetut verkkotunnukset, vuokralaiset, käyttäjät, raporttien määrä, säilytys- ja integrointitaajuus käyttämällä hyväksyttyjä organisaation syötteitä. Merkitse arviot ja tuntemattomat selkeästi. Osittainen kuukausi havaintoja ei välttämättä tue tarkkaa vuotuista työmäärän ennustetta. Kysy toimittajalta, mitkä muuttujat vaikuttavat tarjoukseen ja miten muutokset lasketaan, mutta älä päättele hintoja tai pakettien sisällyttämistä teknisestä dokumentaatiosta.
Pidä kaupallinen sisällyttäminen erillään teknisestä hyväksynnästä. Ominaisuus voi sisältyä tarjoukseen, mutta se vaatii silti määrityksiä ja todisteita; esitelty ominaisuus voi olla ehdotetun paketin ulkopuolella. Kirjaa tarjouksen voimassaolo, laajuus ja poissulkemiset vain, kun hyväksytty tarjous on olemassa. Tämä käsikirjoitus ei sisällä hintaa, alennusta, kustannusmallia tai hankintasuositusta.
Vaatimusten ja todisteiden laskentataulukko
Luo sarakkeita vaatimuksille, liiketoiminnallisille syille, prioriteeteille, tuetuille määrityksille, toimittajan vastaukselle, todisteiden lähteelle, arvioijalle, hyväksymistestille, rajoitukselle ja päätökselle. Lisää olettamusrekisteri syötteellä, lähteellä, päivämäärällä, luotettavuudella ja vaikutuksella, jos se on väärin. Linkitä jokainen pakollinen vaatimus konkreettiseen todisteeseen laajan markkinointisivun sijaan. Säilytä vastaamattomat kysymykset aukkoina sen sijaan, että tulkitset hiljaisuutta tukena.
Testattavien kontrollien osalta kuvaile valtuutettu kiinnitys ja odotettu tulos. Sopimussitoumuksia varten tunnista asiaankuuluva hyväksytty sopimus. Toiminnallisia vastuita varten tunnista nimetty omistaja ja luovuta. Nämä todisteet voivat täydentää toisiaan, mutta niitä ei pidä korvata umpimähkäisesti. Sopimuksessa voidaan jakaa vastuu ilman teknistä testiä; onnistunut testi voi osoittaa käyttäytymistä luomatta tukisitoumusta.
Kuvitteellinen diagnoosi: täydellisen näköinen kyselylomake
Kuvitteellinen ostaja saa myöntäviä vastauksia kertakirjautumista, vientiä, yksityistä käyttöönottoa ja tarkastuslokeja koskeviin kysymyksiin. Arviointi merkitsee aluksi kyselyn täytetyksi. Toinen arvioija kysyy, mikä versio tukee näitä ominaisuuksia, säilyttääkö viennin vuokralaisen rajat ja mitä tapahtuu aktiiviselle istunnolle käytöstä poistamisen jälkeen. Alkuperäiset vastaukset eivät ratkaise näitä kysymyksiä, koska ne kuvaavat luokkia eikä tuloksia.
Ehdotettu vastaus on pyytää kattavaa näyttöä ja jättää asiaan liittyvät vaatimukset auki, kunnes ne tarkistetaan. Ostajan ei tarvitse syyttää toimittajaa harhaanjohtamisesta; Kyselylomake saattoi yksinkertaisesti olla liian epämääräinen. Tämä skenaario on kuvitteellinen, eikä se kuvaa todellista toimittajan vastausta tai tuotevajetta. Ulkoista viestintää tai testiä ei tehty.
Julkaise aukot suosituksen kanssa
Hyödyllinen arviointi tunnistaa tuetut vaatimukset, hyväksytyt rajoitukset, ratkaisemattomat todisteet ja työmääräoletukset, jotka voivat muuttaa päätöstä. Sen pitäisi olla sekä teknisten että yritysten omistajien luettavissa ilman, että heidän erilaiset velvollisuutensa romahtaa. Vältä numeerista pisteytystä, joka merkitsee todisteiden ylittävää tarkkuutta, ellei sen menetelmää ja rajoituksia ole nimenomaisesti hyväksytty.
Luettelo vaatii vaatimus- ja todistematriisin ja läpinäkyvän työmäärän tai kustannusoletukset. Ne alkuperäiset esineet pysyvät avoimina. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos sisältää kehyksen ja kuvitteellisen harjoituksen, ei suoritettua toimittajan due diligence -tutkimusta tai väitettä EmailAuth -ominaisuuksista.