홈페이지 관리자 계정 2단계 인증 설정: 잠금과 복구까지 놓치지 않는 체크리스트

홈페이지 관리자 계정에는 2단계 인증을 먼저 적용하되, 도메인·호스팅·업무 이메일·CMS 관리자를 한 묶음으로 보고 설정해야 합니다. 가능하면 보안 키나 패스키처럼 피싱에 강한 방식을 쓰고, 여의치 않으면 인증 앱을 선택하세요. 복구 코드는 로그인 기기와 분리해 보관하고, 실제 복구 연습까지 끝내야 설정이 완료된 것입니다.

홈페이지 관리자 2단계 인증, 어디부터 켜야 할까

모든 계정을 하루에 바꾸려다 중단하는 것보다, 사업이 멈출 수 있는 계정부터 순서대로 처리하는 편이 낫습니다. CISA도 관리자 계정과 민감한 데이터를 다루는 직원부터 다중 인증(MFA)을 적용하고, 이메일·파일 저장소·원격 접속까지 넓히라고 권고합니다.[1]

우선순위는 다음처럼 잡을 수 있습니다.

계정마다 관리자, 편집자, 외주 작업자를 구분하세요. 공동 관리자 아이디 하나를 여러 사람이 쓰면 누가 로그인했는지 확인하기 어렵고, 한 사람이 퇴사할 때 인증 수단도 함께 꼬입니다. 사람별 계정을 만들고 필요한 권한만 주는 것이 먼저입니다.

문자 인증보다 인증 앱과 보안 키를 우선하는 이유

2단계 인증 방식은 보호 수준이 같지 않습니다. CISA는 보안 키를 가장 강한 선택으로 안내하고, 숫자 일치 방식의 인증 앱, 일회용 코드를 만드는 인증 앱, 문자·이메일 코드 순으로 제시합니다. 문자나 이메일 코드는 더 강한 수단을 쓸 수 없을 때 선택하라고 설명합니다.[1]

NIST의 디지털 신원 지침도 피싱에 강한 인증 수단을 별도로 다룹니다. NIST는 AAL2(인증 보증 수준 2)에 해당하는 서비스가 피싱 저항성 인증 옵션을 제공해야 한다고 규정하고, 이메일을 별도 채널 인증 수단으로 사용하지 못하도록 합니다.[2]

실무 선택은 복잡하지 않습니다.

1. 서비스가 패스키나 FIDO 보안 키를 지원하면 최고 관리자부터 등록합니다.
2. 지원하지 않으면 시간 기반 일회용 비밀번호(TOTP)를 만드는 인증 앱을 씁니다.
3. 문자 인증만 제공한다면 우선 켜되, 더 강한 방식의 지원 여부를 분기마다 다시 확인합니다.
4. 단순 승인 푸시를 쓴다면 화면에 표시된 숫자를 맞추는 방식이 있는지 확인합니다. 모르는 요청은 승인하지 않습니다.

비밀번호와 PIN처럼 같은 종류의 정보를 두 번 묻는 것은 MFA가 아닙니다. OWASP는 서로 독립적인 인증 요소를 조합해야 한다고 설명합니다.[3]

복구 코드는 어디에 보관해야 안전할까

휴대전화를 잃어버리거나 교체하면 정상 사용자도 계정에서 잠길 수 있습니다. OWASP는 MFA 설정 시 일회용 복구 코드를 제공하거나, 서로 다른 인증 수단을 둘 이상 등록하는 방식을 복구 대안으로 제시합니다. 복구 절차는 평소 로그인보다 약해서는 안 됩니다.[3]

다음 기준으로 보관하면 운영 중 혼란을 줄일 수 있습니다.

• 복구 코드를 로그인 중인 휴대전화의 사진첩이나 같은 이메일함에 저장하지 않습니다.
• 회사 비밀번호 관리자에 보관할 때는 해당 관리자 자체에도 MFA를 적용합니다.
• 최고 관리자용 보안 키는 두 개를 등록하고, 예비 키는 접근이 통제되는 다른 장소에 둡니다.
• 누가 복구 수단을 보관하는지, 마지막 확인일이 언제인지 내부 자산 목록에 남깁니다. 복구 코드 원문은 목록에 적지 않습니다.
• 외주사나 퇴사자의 개인 전화번호가 복구 수단으로 남아 있지 않은지 확인합니다.

복구 코드를 인쇄해 금고에 두는 방식도 가능합니다. 중요한 점은 온라인 계정과 같은 사고로 동시에 노출되거나 사라지지 않게 분리하는 것입니다.

기기 분실과 담당자 퇴사 전에 복구 절차를 시험한다

설정 화면에서 사용 중 표시만 확인하면 부족합니다. 관리자 한 명이 휴대전화 없이도 정해진 절차에 따라 접근을 복구할 수 있는지 시험해야 합니다. 단, 실제 운영 계정에서 기존 인증 수단을 모두 지우는 위험한 시험은 피하세요.

분기별 점검 절차

1. 관리자 계정 목록과 각 계정의 MFA 적용 여부를 내보냅니다.
2. 예비 보안 키나 복구 코드 한 건으로 테스트 계정 복구를 실행합니다.
3. 사용한 일회용 코드는 다시 쓸 수 없는지 확인하고 새 코드 묶음을 발급합니다.
4. 인증 수단을 변경하면 기존 수단으로 재인증을 요구하는지 확인합니다. OWASP는 MFA 수단 변경을 고위험 동작으로 보고, 기존 등록 수단을 통한 재인증과 변경 알림을 권고합니다.[3]
5. 퇴사자·외주 작업자의 계정과 복구 전화번호를 제거하고, 최고 관리자 수가 필요한 만큼만 유지되는지 확인합니다.

점검 중 로그인 실패가 발생하면 무조건 잠금을 해제하지 마세요. OWASP는 비밀번호는 맞지만 두 번째 인증에 실패한 경우, 사용자가 기기를 잃었을 수도 있고 비밀번호가 노출됐을 수도 있다고 설명합니다. 다른 인증 수단을 제시하고, 본인이 모르는 시도라면 비밀번호 변경과 알림 확인으로 이어져야 합니다.[3]

서비스가 2단계 인증을 지원하지 않을 때의 대응

관리자 계정에 MFA가 없다면 비밀번호만 길게 바꾸는 것으로 끝내지 않습니다. CISA는 MFA를 지원하지 않는 시스템을 식별하고, 업그레이드나 다른 시스템으로의 이전 계획을 세우라고 권고합니다.[1]

당장 이전하기 어렵다면 아래 임시 통제를 함께 적용하세요.

• 관리자 화면의 접근 IP나 VPN을 제한합니다.
• 관리자 계정과 일반 편집 계정을 분리합니다.
• 로그인 실패와 권한 변경 알림을 켭니다.
• 비밀번호 관리자로 길고 고유한 비밀번호를 생성합니다.
• 이전 목표일과 책임자를 정하고, 지원 여부를 정기적으로 다시 확인합니다.

이 조치는 MFA를 대신하지 않습니다. 이전까지 노출 범위를 줄이는 임시 장치입니다. 홈페이지와 관리 도구의 로그인 구조를 함께 정리해야 한다면 웹사이트 구축·개선 범위에서 계정과 권한 설계를 먼저 확인할 수 있습니다.

적용 전 마지막 체크리스트

• [ ] 도메인, 이메일, 호스팅, CMS의 최고 관리자 계정을 모두 찾았다.
• [ ] 공동 계정 대신 사람별 계정과 최소 권한을 적용했다.
• [ ] 보안 키·패스키 또는 인증 앱을 우선 선택했다.
• [ ] 예비 인증 수단과 일회용 복구 코드를 분리 보관했다.
• [ ] 기기 분실, 담당자 퇴사, MFA 변경 절차를 문서화했다.
• [ ] 테스트 계정으로 복구 절차를 직접 실행했다.
• [ ] MFA 미지원 서비스의 이전 목표일과 임시 통제를 정했다.

첫날에는 최고 관리자와 업무 이메일만 끝내도 됩니다. 다음 점검일을 정하고 나머지 계정을 이어서 닫는 편이, 체크리스트만 만들어 두고 미루는 것보다 안전합니다.