Osta todistettu ohjausraja
Todennusalusta voi mainostaa rooleja, tarkastuslokeja ja vuokralaisen eristämistä, mutta nämä tunnisteet eivät kerro, kuinka hallintalaitteet toimivat ostajan suunnittelemissa työnkulkuissa. Hankinnan arvioinnissa tulee kysyä, kuka voi lukea, viedä, muuttaa ja hallinnoida minkäkin asiakkaan tietoja, miten elinkaarimuutokset vaikuttavat pääsyyn ja mitä todisteita nämä toimet tallentavat. Järjestelmänvalvojan onnistunut esittely ei ole negatiivinen testi luvattomalle käytölle.
Azuren usean vuokralaisen identiteettiopastus erottaa todennuksen, valtuutuksen ja kaupalliset oikeudet. Käytä näitä erotteluja ostajan kysymysten jäsentämiseen sen sijaan, että olettaisit, että kirjautumisrooli kattaa kaikki resurssit ja toiminnot. Tämä artikkeli on vaatimuskehys, ei väite, että EmailAuth tai muu nimetty alusta toteuttaa ehdotetut hallintalaitteet. Vuokralaista ei ole käsitelty, lupaa muutettu tai tuotetta ostettu.
Määritä ensin ostajan pääsymatriisi
Luettele odotetut käyttäjä- ja palveluroolit, vuokralaissuhteet ja resurssit ennen kuin tarkistat toimittajan roolien nimet. Sisällytä tarvittaessa verkkotunnuksen määritykset, todennusraportit, raakatiedot, viennit, integraatiot, käyttäjien hallinta ja kaupalliset asetukset. Ilmoita jokaiselle yhdistelmälle, sallitaanko lukeminen, luominen, muokkaaminen, poistaminen tai vienti. Ostajan suunnittelema raja on viite, jota vasten tuotteen käyttäytymistä voidaan arvioida.
Älä oleta, että "vain luku" sulkee pois viennin tai että "vuokralaisen ylläpitäjä" on rajoitettu yhteen vuokraajaan ilman todisteita. Jaetun palvelun tiimit voivat oikeutetusti tarvita useita asiakkaita, kun taas yksittäisten asiakaskäyttäjien pitäisi nähdä vain heidän hyväksytty laajuutensa. Kirjaa nämä poikkeukset selkeästi muistiin. Kokeilulle hyväksytty laaja rooli ei saa hiljaa tulla tuotannon pääsyn suunnitteluksi. Vaadi toimittajaa kartoittamaan todelliset roolit ostajan matriisiin ja tunnistamaan ei-tuetut erot.
Tarkista vuokralaisen sitoutuminen käyttöliittymän ulkopuolella
Vuokralainen valitsin tai piilotettu navigointikohde ei ole riittävä todiste eristäytymisestä. Todennettu henkilöllisyys on valtuutettava pyydettyä resurssia varten palvelinpuolen rajalla. Vaatimusten tulee kattaa suorat luennot, haut, vienti-, kirjoitus- ja taustatyöt, mukaan lukien viittaukset toisen vuokralaisen omistamiin resursseihin. Käytä synteettisiä valaisimia, joissa on näkyvästi erilaisia tietoja, jotta vahingossa tapahtuva vuokralaisten välinen tulos on havaittavissa.
Azuren ohjeissa varoitetaan, että liiton virheellinen määritys voi antaa käyttöoikeuden tahattomille vuokralaisille. Tarkastuksessa tulisi siksi käydä ilmi, kuinka identiteetit liitetään vuokralaisiin, kuka voi muuttaa kyseistä yhteyttä ja kuinka useisiin vuokralaisiin kuuluva käyttäjä valitsee laajuuden. Älä päättele omistajuutta pelkästään sähköpostin päätteestä tai oleta, että asiakkaan toimittama vuokralaisen tunniste valtuuttaa sen käytön. Varsinaisen toimittajan on selitettävä ja esitettävä tukemansa malli.
Kysy, mitä tarkastusloki todella kirjaa
Microsoft Entran auditointilokin dokumentaatio kuvaa aktiviteettitietueita kyseisessä identiteettiympäristössä tapahtuville muutoksille. Se on hyödyllinen esimerkki virallisesta auditointilokimallista, ei todiste siitä, että toinen alusta tallentaa samat tapahtumat. Ostajan tulee pyytää tarkka tuotetapahtumaluettelo, kenttämääritykset, pääsynvalvonta, säilytyskäyttäytyminen ja omiin tarpeisiinsa liittyvät vientivaihtoehdot.
Kysy, tunnistavatko tietueet toimijan, kohteen, toiminnan, ajan, tuloksen ja vuokralaisen kontekstin riittävästi muutoksen tutkimiseksi. Erota käyttäjän toiminta palveluidentiteettitoiminnasta ja onnistuneet toiminnot evätyistä yrityksistä. Älä oleta, että jokainen epäonnistunut valtuutusyritys kirjataan lokiin vain hallinnollisten muutosten vuoksi. Samoin loki, joka osoittaa, että pyyntö on lähetetty, ei välttämättä näytä, onko tuloksena oleva muutos suoritettu. Vaadi todellisia esimerkkejä, joissa arkaluonteiset tiedot on poistettu ja rajoitukset ilmoitettu.
Tarkista lokin käyttöoikeudet ja eheys ohjaimina
Tarkastusloki voi itsessään sisältää arkaluontoisia asiakas- ja henkilötietoja. Määritä, kuka voi katsella sitä, etsiä vuokralaisista, viedä se ja määrittää sen säilytys. Järjestelmänvalvoja, joka voi muuttaa asetusta ja poistaa ainoat todisteet, esittää erilaisen vastuullisuusmallin kuin malli, jossa on itsenäisesti säilytetyt tietueet. Kysy toimittajalta, kuinka nämä ohjaimet toimivat, mutta älä väitä muuttumattomuutta tai peukalointikestävyyttä ilman nykyistä näyttöä.
Säilytys tulee määritellä tuotteen todellisten tuettujen ehtojen ja ostajan velvollisuuksien mukaan, ei keksitty universaali ajanjakso. Selvitä, mitkä tapahtumat ovat saatavilla käyttöliittymässä, API:ssa ja viedyssä arkistossa ja ovatko näillä näkymillä sama kattavuus. Tarkista aikavyöhykkeen käsittely ja tunnisteet, jotta tietueita voidaan korreloida ilman, että sinun tarvitsee luottaa nimiin, jotka voivat muuttua. Tästä käsikirjoituksesta ei haettu tarkastuspöytäkirjoja.
Testaa elinkaarimuutokset ja palvelun saatavuus
Roolin vähentäminen, käyttäjän poistaminen käytöstä ja valtuustietojen peruuttaminen ovat erillisiä tapahtumia. RFC 7643 kuvaa SCIM-aktiivista attribuuttia jättäen sen lopullisen merkityksen palveluntarjoajalle. Tämä osoittaa, miksi ostaja ei voi olettaa, että hallintapäivitys kumoaa kaikki olemassa olevat istunnot tai integrointivaltuudet. Vaadi ajantasainen selitys tuotteen istunnosta ja ei-interaktiivisen pääsyn käyttäytymisestä.
Hyväksymissuunnitelmaan tulee sisältyä käyttäjä, jonka roolia on rajoitettu istunnon aikana, käytöstä poistettu identiteetti, rajoitettu integrointi ja valtuutettu järjestelmänvalvoja. Tarkista aiottu käyttötulos kussakin tapauksessa, mukaan lukien vienti ja suorat resurssitoiminnot. Nämä ovat ehdotettuja tarkastuksia valtuutetulle eristetylle ympäristölle, eivät lupaa testata toimittajan tuotantopalvelua tai toisen asiakkaan vuokralaista. Tällaista toimenpidettä ei ole tehty täällä.
Ostajan hyväksymistaulukko
Luo laskentataulukko, jossa on vaatimus, liiketoimintasyy, toimittajavaatimus, tuettu kokoonpano, kalusteiden identiteetti, vuokralainen, toiminta, odotettu tulos, todelliset todisteet ja ratkaisemattomat rajoitukset. Pidä todisteet sallituista toimista erillään todisteista kielletyistä toimista. Liitä mukaan tuotteen versio, testipäivämäärä ja ympäristö, jotta tulos pysyy tulkittavissa julkaisun jälkeen. Jos ominaisuus on suunniteltu sen sijaan, että se on otettu käyttöön, kirjaa se tilalle käsittelemättä sitä nykyisenä kattavuudena.
Lisää tarkastuslokeja varten odotettu tapahtuma ja havaittu tietueviite jokaiselle toiminnolle, jossa kirjaaminen vaaditaan. Testillä, joka kieltää pääsyn oikein, mutta joka ei tuota odotettua tarkastustodistusaineistoa, on erilainen kuin testillä, joka täyttää molemmat kriteerit. Kirjaa ylös, kuka hyväksyy rajoitukset ja onko kompensoiva ohjaus hyväksytty. Älä tee hankinnan tarkistuslistan pisteistä tulevan turvallisuuden takuita.
Kuvitteellinen diagnoosi: katsoja, joka voi viedä
Kuvitteellinen ostaja näkee toimittajaesittelyn, jossa katsoja ei voi muokata verkkotunnuksen asetuksia. Ostaja merkitsee aluksi vain luku -roolin tyydyttäväksi. Tarkoitettu matriisi kuitenkin kieltää myös asiakasraakatietojen joukkoviennin. Esittelyssä ei koskaan testattu vientiä, suoria resurssipyyntöjä tai pääsyä toisen vuokralaisen raporttiin. Havaittu rajoitus kattaa vain yhden toimenpiteen.
Ehdotettu vastaus on pyytää valtuutettua kalustepohjaista näyttöä puuttuvista toiminnoista ja tarkistaa tuloksena olevat tarkastustietueet. Jos tuote ei voi erottaa katselua viennistä, ostajan on päätettävä, onko tämä rajoitus hyväksyttävä, sen sijaan että nimeäisi rooli uudelleen ja oletettava, että riski on kadonnut. Tämä on kuvitteellinen hankintaharjoitus, ei havainto EmailAuth tai mistään nimetystä toimittajasta.
Pidä ostopäätös rajallisena
Hyödyllinen johtopäätös tunnistaa todisteiden täyttämät vaatimukset, täyttämättömät vaatimukset, omistajan hyväksymät rajoitukset ja vielä avoinna olevat testit. Se erottaa konfigurointivalinnat tuotteen luontaisesta käyttäytymisestä eikä lupaa täydellistä eristystä rajallisesta testijoukosta. Päätös voidaan ilmoittaa väittämättä, että jokainen tuleva versio tai kokoonpano on katettu.
Luettelo vaatii pääsymatriisin ja negatiiviset testit vuokralaisten välisille luku-, vienti-, kirjoitus- ja elinkaarimuutoksille. Ne alkuperäiset testit jäävät auki. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos sisältää arviointimenetelmän, ei toteutettuihin todisteisiin perustuvaa ostosuositusta, eikä kaupallista sitoumusta tai käyttölupaa ole tehty.