Доставчиците описват това устройство като виртуално и способно на двуфакторно удостоверяване, но нито една от тези думи не отговаря на въпросите, които решават покупката. Кой образ на хипервизор се поддържа, кои клиенти могат да се регистрират, какво всъщност доказва вторият фактор и какво се случва, когато доставчикът на идентичност спре да работи, все още е открито. Превърнете тези въпроси в етапи на приемане, които можете да изпълните на репетиция, и решението ще престане да зависи от това колко убедителен е техническият лист. Листът по-долу е структура за тези доказателства, а не класация на продукти.

Какво трябва да потвърди доставчикът за това внедряване

Започнете, като свиете внедряването до една страница: хипервизорът или облакът, архитектурата на госта, поддържаният образ и интерфейсите, които устройството очаква. Добавете потребителите с техните операционни системи, дали устройствата се управляват и как трябва да работят регистрацията и входът. След това частният достъп: приложения и префикси, организация на 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

Регистрацията е първа, защото всичко след нея зависи от нея: устройство, което не може да се регистрира, не може да бъде тествано. Входът е отделен етап от регистрацията, а отказът е етапът, който повечето листове забравят, защото шлюз, който пуска всички, не е доказал, че отказва на някого. Отнемането и възстановяването носят по-голямата част от оперативния риск и двете се репетират евтино върху копие.

Репетирайте върху копието, не върху живия шлюз

Изпълнете разрушителните етапи върху копие на платформата, следвайки поддържаната процедура за внедряване, и пазете всяко доказателство с датата и версията на конфигурацията му. Ред за рестартиране не се отговаря с рестарт от конзолата, а ред за възстановяване не се отговаря с експорт на конфигурацията. Отбележете кое състояние се връща само и какво трябва да се свърже отново, защото точно тази разлика наследява екипът по операции. Репетицията е и единственият шанс да измерите време за възстановяване, без да обяснявате прекъсване.

Записвайте състоянието на доставчика на идентичност в момента на всеки тест, защото ред за прекъсване, тестван срещу здрав доставчик, доказва обратното на това, което листът твърди. Двама рецензенти на една и съща репетиция хващат различни неща, а вторият обикновено намира реда, чието доказателство е снимка на табло. Дръжте това доказателство прикрепено към реда, на който принадлежи, а не в папка, кръстена на проекта.

Измерете натоварването, което екипът ви ще изпълнява

Спрете се на натоварване, подобно на нормална седмица, после го измерете там, където смятате да внедрявате: паралелност, смес от трафик и прозорецът за поддръжка, който екипът действително има. Обясената цифра за пропускателна способност описва лабораторно условие и не казва нищо за вашите потребители. Измерете възстановяването спрямо целта за възстановяване, а не спрямо плана.

Листът е готов, когато всеки етап има артефакт и всеки артефакт има дата. Устройство, което някой поддържа, с доказателство за всеки ред, е друга покупка от най-дългия списък с отметнати квадратчета.

Подобни статии