공급업체는 이 어플라이언스를 가상이며 이중 인증이 가능하다고 설명하지만, 두 단어 모두 구매를 결정하는 질문에 답하지 않습니다. 어떤 하이퍼바이저 이미지가 지원되는지, 어떤 클라이언트가 등록할 수 있는지, 두 번째 요소가 실제로 무엇을 증명하는지, ID 공급자가 중단되면 무슨 일이 일어나는지는 여전히 열려 있습니다. 이를 리허설에서 실행할 수 있는 인수 단계로 바꾸면 결정은 데이터시트의 설득력에 의존하지 않게 됩니다. 아래 시트는 그 증거를 위한 구조이며 제품 순위가 아닙니다.

공급업체가 이 배포에 대해 확인해야 할 것

배포를 한 페이지로 압축하는 것부터 시작하며, 하이퍼바이저나 클라우드, 게스트 아키텍처, 지원 이미지, 어플라이언스가 기대하는 인터페이스를 적습니다. 사용자와 그 운영체제, 기기가 관리되는지, 등록과 로그인이 어떻게 동작해야 하는지를 더합니다. 다음은 사설 접근으로, 애플리케이션과 접두사, DNS 구성, 반환 경로, 그리고 공용 인터넷 출구가 제안에 포함되는지 여부입니다.

운영도 같은 페이지에 속하며, 장비를 누가 유지하는지, 업데이트가 어디서 오는지, 로그가 어디로 가는지, 구성이 어떻게 보호되는지, 그리고 비즈니스가 실제로 합의한 복구 목표가 무엇인지를 담습니다. 소프트웨어가 가상 머신에서 실행된다는 것이 아니라 바로 그 조합을 확인해 달라고 공급업체에 요청하십시오. ID 공급자나 라이선스 서비스 같은 외부 의존성은 함께 제공되든 아니든 배포의 일부이므로 보이게 유지하십시오. 이름 붙은 의존성이 없는 배포 페이지는 대개 알 수 없는 의존성을 가진 배포 페이지입니다.

두 번째 요소가 정말 두 번째 요소임을 증명하십시오

인증기와 검증 흐름을 지목하고 각 단계가 어떤 신원을 확립하는지 말하십시오. 연속된 두 번의 비밀번호 요구는 두 번째 요소가 아니며, 비밀번호와 일회용 코드의 조합은 서비스에 묶인 암호학적 인증기와 다른 주장입니다. 상자의 라벨이 아니라 구매하는 흐름을 적으십시오.

피싱 저항성은 별개의 속성이며, 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

등록이 먼저인 이유는 그 뒤의 모든 것이 등록에 의존하며, 등록할 수 없는 기기는 시험할 수 없기 때문입니다. 로그인은 등록과 별개의 단계이고, 거부는 대부분의 시트가 잊는 단계인데, 모두를 받아들이는 게이트웨이는 누군가를 거부한다는 것을 보여준 적이 없기 때문입니다. 철회와 복원은 운영 위험의 대부분을 지며, 둘 다 사본에서 값싸게 연습할 수 있습니다.

운영 중인 게이트웨이가 아니라 사본에서 연습하십시오

방해가 되는 단계는 지원되는 배포 절차를 따라 플랫폼 사본에서 실행하고, 각 증거를 날짜와 구성 버전과 함께 보관하십시오. 재부팅 행은 콘솔에서의 재시작으로 답할 수 없고, 복원 행은 구성을 내보내는 것으로 답할 수 없습니다. 그 차이가 바로 운영 팀이 물려받는 것이므로, 어떤 상태가 스스로 돌아오고 무엇이 다시 연결되어야 하는지 기록하십시오. 리허설은 장애를 설명하지 않고 복원 시간을 잴 수 있는 유일한 기회이기도 합니다.

건강한 공급자를 상대로 시험한 장애 행은 시트의 주장과 반대를 증명하므로, 각 시험 시점의 ID 공급자 상태를 기록하십시오. 같은 리허설의 두 검토자는 서로 다른 것을 잡아내며, 두 번째는 대개 증거가 대시보드 화면 캡처인 행을 찾습니다. 그 증거는 해당 행에 붙여 두고, 프로젝트 이름의 폴더에 두지 마십시오.

팀이 실행할 작업 부하를 측정하십시오

평범한 한 주와 비슷한 부하를 정하고, 배포하려는 곳에서 동시성, 트래픽 구성, 팀이 실제로 가진 유지보수 창을 측정하십시오. 광고된 처리량 수치는 실험실 조건을 서술할 뿐 사용자에 대해서는 아무것도 말하지 않습니다. 복원은 계획이 아니라 복구 목표에 대고 측정하십시오.

모든 단계에 산출물이 있고 모든 산출물에 날짜가 있으면 시트는 완성됩니다. 누군가 유지하는 어플라이언스에 각 행의 증거가 붙어 있는 것은 체크된 상자의 가장 긴 목록과는 다른 구매입니다.

관련 글