분실한 VPN 인증기: MFA를 끄지 않고 교체하기
분실한 요소는 복구 작업이지 장애가 아닙니다. 실패한 경로 밖에서 확인하고, 대체 수단을 등록하고, 이전 방식을 폐기한 뒤 로그인이 작동함을 증명하십시오.
누군가 휴대폰을 잃어버리고 티켓은 VPN 고장으로 도착하지만, 이 프레임은 두 번 틀렸다. 계정은 여전히 존재하고 게이트웨이는 여전히 ID 공급자를 신뢰하므로, 고장 난 유일한 부분은 사용자가 더 이상 보유하지 않은 요소 하나다. 장애가 아니라 복구로 다루어 요청자를 확인하고, 대체 수단을 등록하고, 분실한 방식을 폐기한 뒤 계정이 작동함을 증명하라. 이 모든 것은 통화 중에 계획을 즉석에서 만드는 것이 바로 MFA가 모두에게 꺼지는 경로이기 때문에, 손실 전에 계획이 작성되었음을 전제한다.
1단계: 등록된 요소를 기억이 아니라 기록에서 읽으십시오
첫 질문은 어떤 기기가 분실되었느냐가 아니라 계정이 아직 무엇을 쓸 수 있느냐다. 계정에는 비밀번호와 푸시, 시간 기반 코드, 하드웨어 키, 인쇄된 복구 코드가 있을 수 있으며, 그중 하나를 잃는 것은 유일한 것을 잃는 것과 전혀 다른 사건이다. 사용자에게 기억해 달라고 요청하는 대신 ID 시스템에서 방식 목록을 읽으십시오, Microsoft Entra 테넌트에서는 쿼리가 한 줄이다:
Get-MgUserAuthenticationMethod -UserId [email protected]
그다음 계정이 아직 작동하는 동안 계정 식별자, 등록된 요소, 복구 코드가 있는 위치, 요청자를 독립적으로 확인할 수 있는 사람, 계정이 도달하는 시스템을 담은 복구 기록을 작성하라. 팀이 이미 사용하는 보호된 인벤토리에 보관하고, 활성 코드가 있는 메모에는 절대 두지 마라. 이 다섯 항목이 당황한 통화를 체크리스트로 바꾼다, NIST의 인증기 수명 주기 지침도 복구를 자격 증명의 예외가 아니라 일부로 본다.
사람들이 바로 이 부분을 건너뛰기 때문에, 확인 채널을 별도 항목으로 기록하라. 요청자 본인이 전화를 통제한다면 계정에 연결된 전화번호는 독립 채널이 아니다.
2단계: 실패한 경로 밖에서 요청자를 확인하십시오
신원 확인은 VPN, 사서함, 분실한 기기에 의존하지 않는 채널로 수행하라. 인사 기록의 번호로 회신 전화를 하거나, 이미 디렉터리에 있는 관리자와 대면 확인하는 것은 둘 다 작동하지만, 복구 중인 계정에서 보낸 채팅 메시지는 작동하지 않는다. 확인은 계정에 관한 질문에 답할 능력이 아니라 사람에 관한 것이다, 계정 세부 정보는 유출되기 때문이다. 누가 언제 요청을 확인했는지 기록하라, 다음 검토자가 둘 다 원할 것이다.
요청이 긴급함과 확인을 건너뛰라는 압박과 함께 온다면, 바로 그때가 속도를 늦출 순간이다. 복구 사기는 바쁜 친절한 동료와 똑같이 보인다.
3단계: 대체 수단을 등록한 뒤 이전 요소를 폐기하십시오
새 인증기는 정상 등록 흐름으로 등록하고, 관리자 우회로는 절대 쓰지 마라. 그런 다음 분실한 방식을 명시적으로 제거하라, 대체 수단을 등록해도 누군가 폐기할 때까지 이전 인증기는 승인된 상태로 남기 때문이다. 이전 기기가 다른 사람 손에 있을 수 있다면 제거를 긴급으로 다루고, 복구가 아니라 사고 절차를 따르라. 같은 작업에서 기존 세션을 취소하라, 변경 전에 만든 세션이 변경보다 오래 살 수 있기 때문이다:
Revoke-MgUserSignInSession -UserId [email protected]
다른 모든 사람에게서 요소를 제거하거나 게이트웨이의 인증서 검사를 완화하는 것은 한 사람의 복구를 전체 배포에 영향을 주는 장애와 맞바꾸는 일이다. 변경을 단일 계정으로 제한하고 증거가 더 넓은 침해를 가리키면 에스컬레이션하라. 어떤 요소가 폐기되었고 무엇이 그것을 대체했는지 티켓에 적어라.
4단계: 계정이 양방향으로 작동함을 증명하십시오
지원되는 클라이언트로 새 요소를 사용해 한 번 로그인하고, 계정이 손실 전에 도달했던 리소스에 여전히 도달하는지 확인하라. 터널이 필요한 리소스와 필요 없는 리소스를 각각 시험해 실패가 올바른 계층을 가리키게 하라. 폐기된 요소로 로그인을 시도하고 프롬프트가 아니라 거부를 기대하라, 제거가 효력을 발휘했다는 증거다. 기존 등록된 기기에서 실패하는 챌린지는 프롬프트 문제이지 모든 것을 다시 등록할 이유가 아니다.
그다음 사용자에게 같은 로그인을 안내 없이 완료해 달라고 요청하라. 당신의 성공한 시험은 구성을 증명하고, 사용자의 시도는 인계를 증명한다.
성공한 로그인의 타임스탬프와 현재 사용 중인 요소 이름으로 티켓을 닫아라. 같은 작업에서 복구 기록을 갱신해 다음 손실이 오래된 것이 아니라 정확한 인벤토리에서 시작되게 하라.
5단계: 이 일을 고통스럽게 만든 조건을 제거하십시오
모든 복구 통화는 등록 설계에 대한 증거다. 계정에 요소가 정확히 하나뿐이었다면 그 그룹의 모두에게 두 번째를 요구하라. 복구 코드가 분실한 노트북에 있었다면 보관 위치를 바꿔라. 확인에 휴가 중인 관리자가 필요했다면 대리인을 지정하라. 모든 수정은 반나절이 걸리고 다음 사고의 최악의 한 시간을 없앤다.
그런 다음 첫 단계의 기록을 현실과 대조해 다시 읽어라. 실제로 존재하는 요소를 나열하는가, 확인 채널이 여전히 사람에게 닿는가? 아무도 갱신하지 않는 런북은 그것이 쓰인 통화 도중 사람들이 무시하는 문서로 퇴화한다.