Добављачи описују овај уређај као виртуелан и способан за два фактора, а ниједна од тих речи не одговара на питања која одлучују о куповини. Која је слика хипервизора подржана, који се клијенти могу уписати, шта други фактор заиста доказује и шта се дешава кад провајдер идентитета падне — све је то још отворено. Претворите то у етапе прихватања које можете извести на проби, и одлука престаје да зависи од тога колико је технички лист уверљив. Лист испод је структура за те доказе, а не рангирање производа.

Шта добављач мора потврдити о овом распоређивању

Почните тако што ћете распоређивање свести на једну страницу: хипервизор или облак, архитектура госта, подржана слика и интерфејси које уређај очекује. Додајте кориснике, њихове оперативне системе, да ли се уређајима управља и како упис и пријава треба да раде. Затим приватни приступ: апликације и префикси, уређење DNS-а, повратне путање и да ли је јавни интернет излаз део понуде.

Операције припадају истој страници: ко одржава кутију, одакле долазе ажурирања, куда иду записи, како је конфигурација заштићена и који је циљ враћања пословање заиста договорило. Тражите од добављача да потврди управо ту комбинацију, а не да софтвер ради у виртуелној машини. Држите видљивим спољне зависности, попут провајдера идентитета или услуге лиценцирања, јер су део распоређивања без обзира на то да ли се испоручују с њим. Страница распоређивања без именоване зависности обично је страница распоређивања с непознатом зависношћу.

Докажите да је други фактор други фактор

Именујте аутентификатор и ток провере и реците који идентитет сваки корак успоставља. Два узастопна захтева за лозинку нису други фактор, а лозинка плус једнократни код другачија је тврдња од криптографског аутентификатора везаног за услугу. Запишите ток који купујете, а не етикету на кутији.

Отпорност на фишинг је засебно својство, и NIST-ове смернице за аутентификаторе га третирају управо тако: код који корисник може бити преварен да проследи још увек задовољава вишефакторску аутентификацију, али не испуњава тај додатни услов. Тражите то својство изричито ако вам је важно. Затим захтевајте демонстрацију на типу клијента који ваши корисници заиста користе, обухватајући упис, одбијени или истекли изазов, опоравак након изгубљеног аутентификатора и опозив једног корисника док остали остају повезани. Држите проверу идентитета гејтвеја у обухвату, јер је клијент који верује било ком гејтвеју преместио проблем уместо да га реши.

Напишите услов пролаза пре него што било шта покварите

Табела испод је део листа који преживи сусрет с добављачем, јер сваки ред тражи доказ уместо уверавања. Попуните услов пролаза пре пробе и третирајте ред без доказа као неуспешан ред. Пет етапа покрива оно што гејтвеј мора да ради.

Acceptance stageEvidence to keepPass condition
EnrolmentEnrolment record with the device type and the identity usedA new device enrols once, and nobody else can enrol it afterwards
Sign-in with the second factorSession record naming both factors and the gateway identity that was checkedThe session carries the expected identity and the gateway certificate validated
Denial of an unapproved destinationLog line from the control that refused the flow, with the policy nameThe flow is refused and the refusal is attributable to one control
Revocation of one userRevocation timestamp and the sessions that survived itThe named user is out and unaffected users keep working
Restore from configuration backupRestored version plus a probe of a revoked identityThe revision matches the backup and revoked identities stay revoked

Упис је први јер све низводно од њега зависи: уређај који не може да се упише не може се тестирати. Пријава је засебна етапа од уписа, а одбијање је етапа коју већина листова заборави, јер гејтвеј који пушта све није доказао да икоме одбија. Опозив и враћање носе већину оперативног ризика, и оба се јефтино увежбавају на копији.

Вежбајте на копији, не на живом гејтвеју

Изведите ометајуће етапе на копији платформе, следећи подржани поступак распоређивања, и чувајте сваки доказ с његовим датумом и верзијом конфигурације. Ред о поновном покретању не одговара се поновним покретањем из конзоле, а ред о враћању не одговара се извозом конфигурације. Забележите које се стање враћа само и шта мора поново да се повеже, јер ту разлику наслеђује оперативни тим. Проба је и једина прилика да измерите време враћања без објашњавања испада.

Забележите стање провајдера идентитета у тренутку сваког теста, јер ред о испаду тестиран уз здравог провајдера доказује супротно од онога што лист тврди. Два рецензента на истој проби хватају различите ствари, а други обично нађе ред чији је доказ снимак екрана контролне табле. Држите тај доказ прикачен уз ред којем припада, а не у фасцикли названој по пројекту.

Измерите оптерећење које ће ваш тим изводити

Договорите оптерећење слично нормалној недељи, па га измерите тамо где намеравате да распоредите: паралелност, мешавина саобраћаја и прозор одржавања који тим заиста има. Оглашена бројка пропусности описује лабораторијски услов и ништа не говори о вашим корисницима. Мерите враћање према циљу враћања, а не према плану.

Лист је готов кад свака етапа има доказ и сваки доказ има датум. Уређај који неко одржава, с доказом за сваки ред, другачија је куповина од најдуже листе означених поља.

Повезани чланци