휴대전화를 바꾸거나 초기화했거나, 정리하다가 인증 앱을 지우는 일이 생깁니다. 비밀번호는 여전히 맞지만 두 번째 인증 수단이 사라졌으므로 메일에 로그인할 수 없습니다. 웹메일 2단계 인증으로 인한 접속 불가는 보안을 중요하게 여기는 조직에서 가장 흔한 지원 요청 중 하나이며, 충분히 예상할 수 있는 일입니다.
이 글에서는 문제를 해결하는 방법, 복구 절차를 자동화하지 않고 신중하게 처리해야 하는 이유, 그리고 반나절 걸릴 일을 2분 만에 끝내게 해 주는 간단한 준비 사항을 설명합니다.
이 문제가 자주 생기는 이유
2단계 인증은 보통 한 번, 한 장치에서 설정합니다. 그 순간 사용자는 장치를 잃었을 때의 상황보다 당장 메일에 로그인하는 데 집중합니다.
복구 코드를 제공해도 대부분은 따로 보관하지 않습니다. 그때는 번거로운 숙제처럼 느껴지기 때문입니다. 휴대전화는 대략 3년마다 교체되며, 인증 앱을 백업했거나 의식적으로 이전하지 않았다면 인증 정보는 새 기기로 넘어오지 않습니다. 따라서 웹메일 2단계 인증 잠금은 누군가의 실수가 아니라 장치 교체 주기에서 자연스럽게 생기는 결과입니다.
실제로 문제가 생겼을 때 이 점을 기억할 필요가 있습니다. 접속하지 못하는 당사자는 대개 자신이 어리석은 실수를 했다고 느끼지만, 그렇지 않습니다.
접속을 복구하는 두 가지 방법
방법은 정확히 두 가지이며, 사용자가 직접 처리할 수 있는 것은 첫 번째뿐입니다.
복구 코드 사용. 2단계 인증을 등록할 때 발급되는 복구 코드는 사용자가 직접 문제를 해결하는 수단입니다. 비밀번호로 로그인한 뒤 인증 앱의 코드 대신 복구 코드를 입력하면 됩니다. 이후 웹메일 설정에서 기존 두 번째 인증 수단을 제거하고 새 장치를 등록할 수 있습니다. 이 과정에는 관리자가 전혀 관여하지 않습니다.
지원팀에 문의. 복구 코드도 없다면 지원팀에서 두 번째 인증 수단을 해제해야 합니다. 고객 대시보드에서 직접 할 수 있는 작업이 아니라 지원팀이 처리하도록 의도적으로 설계되어 있습니다. 계정 소유자가 어떤 사서함에서든 2단계 인증을 몰래 제거할 수 있다면, 공격자에게는 개별 사서함보다 계정 소유자를 노리는 편이 훨씬 유리하기 때문입니다.
고객 대시보드에서 할 수 있는 일과 할 수 없는 일을 분명히 알아두는 것이 좋습니다. 언뜻 보면 대시보드에서 해결할 수 있을 것처럼 보이기 때문입니다. 사서함 보안 페이지에서는 2단계 인증이 활성화되어 있는지와 언제 확인되었는지를 볼 수 있고, 사서함 비밀번호도 변경할 수 있습니다. 그러나 두 번째 인증 수단은 해제할 수 없습니다. 비밀번호는 애초에 접속을 막은 원인이 아니므로 비밀번호를 바꿔도 웹메일 2단계 인증 잠금은 해결되지 않습니다.
어떤 방식으로 인증 수단을 해제했든 사용자는 "나중에"로 미루지 말고 즉시 다시 등록해야 합니다. 2단계 인증 문제를 겪은 뒤 비밀번호만으로 보호되는 사서함이야말로 그런 상태로 남겨 두어서는 안 됩니다.
요청자의 신원 확인
다른 사람을 대신해 웹메일 2단계 인증 잠금 문제를 지원팀에 전달하기 전에 요청이 진짜인지 확인해야 합니다. 사람들이 자주 생략하지만 가장 중요한 단계입니다.
공격자가 동료를 속여 대신 요청하게 만들 수 있는 것 중 가장 유용한 요청은 누군가의 두 번째 인증 수단을 제거해 달라는 요청입니다. 이메일이나 채팅으로 들어오고 일상적인 업무처럼 들리며, 요청자가 사정을 잘 아는 것처럼 보인다는 이유로 그대로 전달되기 쉽습니다.
따라서 요청이 들어온 경로와 별도의 수단으로 확인하세요. 이메일로 요청했다면 전화하고, 채팅으로 요청했다면 사칭한 사람이 알 수 없는 내용을 묻거나 직접 만나 확인하세요. 확인에는 1분이면 충분합니다. 최종 조치를 지원팀이 수행한다는 사실은 두 번째 방어선일 뿐, 첫 번째 확인을 생략해도 된다는 뜻이 아닙니다.
요청이 다급하고 미안해하며 다소 당황한 분위기라면 특히 주의해야 합니다. 실제 2단계 인증 잠금도 그런 모습이지만, 긴급함을 앞세워 확인 절차를 건너뛰게 만드는 사회공학 공격도 정확히 같은 방식으로 연출되기 때문입니다.
간단히 해결할 수 있도록 미리 준비하기
세 가지 작은 준비만으로 이 일을 보안 사고가 아니라 간단한 용무로 바꿀 수 있습니다.
복구 코드 보관을 등록 절차에 포함하세요. 나중에 선택적으로 하는 부가 작업이 아니라 같은 안내 과정에서 반드시 다루고, 구체적인 보관 장소까지 정해야 합니다. 비밀번호 관리자가 가장 적합하며, 종이에 인쇄해 보관하는 것도 충분히 합리적인 방법입니다.
적절한 경우 두 번째 장치도 등록하도록 권하세요. 태블릿이나 보조 휴대전화를 등록해 두면 장치 하나를 잃어도 접속 불가가 아니라 불편한 일로 끝납니다.
지원 요청 경로를 문서화하세요. 웹메일 2단계 인증 잠금이 생기면 사용자는 누구에게 알려야 하는지 알아야 하고, 담당자는 대시보드가 아니라 지원팀을 거쳐야 한다는 사실을 알아야 합니다. 문제가 생긴 뒤에야 이 경로를 찾으면 반나절을 허비하게 됩니다.
이런 준비가 잠금을 막아 주는 것은 아니며, 그럴 필요도 없습니다. 대신 복구에 드는 비용과 시간을 줄여 줍니다. 특히 복구 코드는 지원 요청을 2분짜리 사용자 직접 해결 절차로 바꾸는 유일한 수단이므로 보통보다 더 적극적으로 보관을 요구할 가치가 있습니다.
잠금처럼 보이지만 다른 문제인 두 가지 경우
사용자에게는 똑같이 보이지만 전혀 다른 대응이 필요한 상황이 두 가지 있습니다.
인증 앱은 작동하지만 코드가 거부되는 경우. 대개 장치 시계의 오차가 원인입니다. RFC 6238의 시간 기반 코드는 장치 시계가 대체로 정확해야 하며, 휴대전화 시간이 1분 넘게 어긋나면 코드가 유효하지 않습니다. 자동 시간 동기화를 켜면 해결되므로 인증 수단을 초기화할 필요가 없습니다.
다른 계정을 선택한 경우. 주소가 여러 개인 사용자는 한 계정에 2단계 인증을 등록해 놓고 다른 계정으로 로그인하려 하거나, 인증 앱에서 잘못된 항목을 선택하기도 합니다. 무엇이든 초기화하기 전에 먼저 확인하세요.
사용자가 완전히 잘못된 로그인 화면을 이용하는 경우도 있습니다. 사서함 사용자는 계정 대시보드가 아니라 웹메일 로그인 화면에서 접속합니다. 한쪽에서 사용하는 비밀번호는 다른 쪽에서 작동하지 않으므로, 원인이 분명한 오류가 아니라 이해하기 어려운 로그인 실패처럼 보입니다.
2단계 인증을 의무화할 가치가 있는가
접속 불가가 운영 비용이라면 보안상 이점이 그 비용만큼 가치가 있는지 묻는 것도 타당합니다.
다른 서비스의 비밀번호 재설정 메일을 받는 사서함이라면, 사실상 거의 모든 사서함이 이에 해당하며, 답은 분명히 그렇습니다. 이메일 계정은 다른 모든 계정의 복구 경로이므로 가장 우선해서 보호해야 합니다. 복구 코드로 해결할 수 있는 웹메일 2단계 인증 잠금은 사서함 탈취를 막기 위해 치를 만한 작은 비용입니다.
여러 사람이 사용하는 공용 운영 주소에서는 실제로 불편할 수 있습니다. 그렇다고 두 번째 인증 수단을 생략하는 것이 답은 아닙니다. 처음부터 로그인 정보를 공유하지 말고 각 사용자를 구성원으로 지정하는 공유 사서함을 사용하면 각자가 자신의 계정으로 인증할 수 있습니다.
같은 원칙은 전체 등록 과정에도 적용됩니다. 인증 정보는 개인에게 귀속되어야 합니다. 그래서 초대를 받은 사용자가 직접 인증 정보를 설정하며, 관리자는 이를 알 필요가 없습니다. 자세한 내용은 비밀번호를 공유하지 않고 사서함 설정하기에서 설명합니다.
