2단계 인증 · 2FA
Two-Factor Authentication
2단계 인증이란?
- 비밀번호+한 번 더 확인
- 문자·앱·지문 등
- 뚫려도 계정 지킴
2FA를 켜는 순간 달라지는 것은 사용자의 로그인 동작이 아니라 공격자의 손익 계산입니다. 어디선가 유출된 아이디·비밀번호 목록을 자동으로 대입하는 공격은 초당 수천 건을 시도해도 두 번째 요소 앞에서 전부 멈춥니다. 공격자는 계정 하나를 위해 피해자의 휴대폰이나 인증 앱을 따로 확보해야 하고, 그 수고를 들이느니 2FA가 꺼진 다른 회사로 넘어갑니다. 방어하는 쪽에는 비밀번호 유출을 '사고'가 아니라 '경보'로 다룰 시간이 생깁니다.
두 번째 요소는 안전도가 서로 다릅니다. SMS 코드는 통신사 회선을 가로채는 심 스와핑이나 문자 전달 앱에 취약하고, 인증 앱의 30초짜리 6자리 코드(TOTP)는 대입 공격은 막지만 가짜 로그인 화면에 코드를 그대로 옮겨 적게 만드는 실시간 피싱에는 뚫립니다. FIDO2 보안키와 패스키는 접속한 도메인이 다르면 서명 자체를 거부해 피싱에 구조적으로 견딥니다. 요소가 셋 이상이면 MFA라 부르고, 한 번 로그인으로 여러 서비스를 여는 SSO는 인증 횟수를 줄이는 편의 장치일 뿐 2FA를 대체하지 않습니다.
켜는 범위도 함께 봐야 합니다. 사람이 쓰는 로그인만 보호하고 API 토큰·서비스 계정·메일 발송 계정을 그대로 두면 뒷문이 열려 있는 셈입니다. 이런 계정은 2FA를 걸 수 없으니 토큰 수명을 90일로 끊고 접속 IP를 허용 목록으로 묶는 방식으로 대신합니다. 세션도 마찬가지여서, 2FA를 통과한 뒤 발급된 쿠키가 탈취되면 시스템은 두 번째 요소를 다시 묻지 않습니다. 결제 승인이나 권한 변경 같은 민감 작업에 재인증을 거는 이유가 여기 있습니다.
현장에서 실제로 터지는 사고는 해킹보다 잠김인 경우가 많습니다. 휴대폰을 바꾸며 인증 앱을 옮기지 않은 직원이 백업 코드도 없으면 계정에 못 들어가고, 급한 마음에 관리자가 2FA를 풀어 주는 순간 그 계정은 영구 예외로 남습니다. 복구 절차를 먼저 만들어 두는 것이 도입의 절반입니다. 푸시 승인도 한밤중에 알림이 스무 번 오면 누군가는 결국 누르기 때문에, 숫자 매칭이 없는 푸시는 피로 공격의 통로가 됩니다. '켜 두라고 공지했다'와 '전 계정이 켜져 있다'는 전혀 다른 말이므로, 분기마다 미적용 계정을 직접 뽑아 확인해야 합니다.
금융·기업 보안에서 쓰이던 다중요소 인증이 스마트폰 확산과 함께 대중화됐고, 계정 탈취 방지의 표준 보안 수단이 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 180명, 연매출 1,200억 원대 이커머스 A사의 이야기입니다. 개발자 24명이 쓰는 GitHub 조직 계정에 6주 사이 출처 불명의 로그인 시도가 40여 건 잡혔고, 그중 한 건은 퇴사자 계정으로 성공했습니다. 저장소에 결제 연동 키가 남아 있던 터라 CTO가 전사 2FA 적용을 지시했습니다.
- 보안담당 김 과장이 계정 목록을 뽑아 보니 개발팀 24명 중 2FA를 켠 사람은 7명뿐이었고, 나머지는 '코드 받는 게 번거롭다'며 미뤄 둔 상태였습니다.
- CTO는 SMS 대신 인증 앱을 표준으로 정하고, 저장소 관리자 권한을 가진 5명에게는 보안키를 1인당 2개씩 지급해 하나는 책상, 하나는 지갑에 두게 했습니다.
- 도입 첫 주에 휴대폰을 교체한 인턴이 로그인을 못 해 반나절을 날리자, 김 과장은 백업 코드 10개를 출력해 봉투째 금고에 보관하는 절차를 매뉴얼에 넣었습니다.
- 한 달 뒤 개발자 한 명이 '새벽 2시에 승인 알림이 여덟 번 왔다'고 신고했고, 팀은 당일 오후에 푸시 승인을 숫자 매칭 방식으로 바꿨습니다.
- 6주 뒤 조직 계정 2FA 적용률은 29%에서 100%로 올랐고, 외부의 로그인 성공 시도는 분기 3건에서 0건으로, 계정 잠김 문의는 첫 달 11건에서 이듬달 1건으로 줄었습니다.