식별·인증·인가와 MFA: 로그인 성공과 접근 권한의 차이

1장 개념과 보호 목표#

식별은 사용자를 구분하고, 인증은 그 신원을 확인하며, 인가는 특정 자원에 대한 행위를 허용할지 결정합니다. 로그인에 성공한 사용자도 다른 고객의 주문이나 관리자 기능에는 접근할 수 없어야 합니다.

2장 원리와 구분#

MFA는 서로 다른 유형의 인증 요소를 결합합니다. 비밀번호와 보안 질문처럼 모두 지식에 속하는 요소 두 개를 요구하는 것은 같은 의미의 다중 요소가 아닙니다. 생체인증에는 타인을 잘못 허용하는 FAR과 본인을 잘못 거부하는 FRR의 균형이 있습니다. 위치와 행위는 위험 판단 신호로 사용할 수 있지만 독립적인 인증 요소인지 별도로 평가해야 합니다.

사용자 계정의 가입·인증 수단 등록·권한 변경·탈퇴는 같은 수명주기로 연결해야 합니다. 공유 계정은 행위의 책임 추적을 어렵게 하므로 가능한 한 개인별 계정과 역할을 사용합니다. 로그인 성공 직후 세션 ID를 새로 발급하고 민감 작업의 재인증 정책을 정하면 인증과 세션 관리가 연결됩니다.

3장 비교와 판단 기준#

단계·요소	질문·기능	예시
식별	어떤 주체인가?	계정 ID
인증	그 주체임을 증명했는가?	비밀번호·패스키
인가	이 행위를 허용하는가?	주문 소유권·관리자 기능
MFA	다른 유형의 증거 결합	지식·소유·생체 요소

4장 사용자 이름은 신원 주장이지 신원 확인이 아니다#

요청에 사용자 ID가 들어 있다는 사실은 공격자가 그 ID를 쓸 수 없다는 보장이 아닙니다. 인증은 비밀번호·인증기·서명 등 정해진 절차로 주장을 확인합니다. 인가는 확인된 신원과 대상 자원·행위를 연결해 허용 여부를 판단합니다. 클라이언트가 보내는 userId를 그대로 신뢰하는 경로를 특히 점검합니다.

flowchart LR
 I["식별: 누구라고 주장하는가"] --> A["인증: 근거를 검증하는가"]
 A --> Z["인가: 해당 자원과 행위를 허용하는가"]
 Z --> L["수행 결과와 기록"]

5장 인증 요소의 종류와 독립성#

지식 요소에는 비밀번호, 소유 요소에는 인증기나 키, 생체 요소에는 기기에서 확인하는 생체 특성 등이 있습니다. 비밀번호와 보안 질문을 추가하는 것은 같은 지식 요소가 반복될 수 있습니다. 요소가 다르더라도 하나의 탈취 경로에서 함께 노출되는지 확인해야 합니다.

MFA는 단순히 인증 화면을 두 번 보여 주는 기능이 아닙니다. 인증 방식의 피싱 저항성·복구·분실·지원 환경과 공격자의 중계 가능성도 검토합니다. 관리자와 민감 작업에는 위험에 맞는 조건을 적용합니다.

6장 로그인 성공 뒤 타인 주문을 읽는 사례#

일반 사용자가 자신의 계정으로 로그인한 뒤 URL의 주문 ID를 바꿉니다. 인증은 성공하지만 타인의 주문 소유권을 확인하지 않으면 데이터가 노출됩니다. 로그인 미들웨어의 존재만으로 인가가 끝났다고 판단하면 이런 문제를 놓칩니다.

신뢰하는 세션에서 현재 사용자 확인
서버 저장소에서 실제 주문과 조직 확인
대상 자원과 사용자의 관계 검증
허용된 필드와 기능만 처리

7장 세션이 새로운 공격 대상이 된다#

인증에 성공하면 세션이나 토큰이 이후 요청의 근거가 됩니다. 로그인 자체가 강해도 토큰이 URL·로그·단말·XSS로 노출되면 인증을 다시 하지 않고 악용될 수 있습니다. 발급·저장·전달·만료·회수의 수명주기를 관리해야 합니다.

권한 변경이나 비밀번호 재설정 뒤 기존 세션이 계속 같은 권한으로 작동하는지 시험합니다. 토큰 내용이 오래된 역할을 담는다면 서버의 현재 권한과 연결하는 정책이 필요할 수 있습니다.

8장 재인증은 어떤 행위에 적용할까#

새 인증 수단 등록, 이메일 변경, 대량 내보내기와 중요한 승인처럼 계정이나 데이터에 큰 영향을 주는 행위는 추가 확인을 검토합니다. 단순 조회와 같은 조건으로 처리하면 탈취 세션으로 복구 수단까지 바꾸는 위험이 생길 수 있습니다.

재인증의 유효시간·실패·취소·상태 변경을 정합니다. 확인한 뒤 실행 전에 대상이나 인자가 바뀌는 경로도 시험해야 사용자 의도와 실제 조치가 연결됩니다.

9장 복구 경로가 인증보다 약해질 수 있다#

분실한 기기·변경된 전화번호·퇴사 계정을 고려해 복구 근거를 정합니다. 쉽게 알 수 있는 개인정보 질문만으로 MFA를 해제하면 강한 로그인 경로를 우회할 수 있습니다. 고객지원의 관리자 권한과 복구 승인도 감사 대상입니다.

flowchart TB
 R["복구 요청"] --> I["독립적인 신원 근거 확인"]
 I --> P["허용한 복구 정책과 승인"]
 P --> C["새 인증 수단 연결"]
 C --> X["노출·분실 수단과 관련 세션 회수"]
 X --> N["변경 알림과 감사기록"]

10장 실패 제한과 계정 잠금의 균형#

비밀번호 추측을 줄이려면 시도 횟수와 맥락별 제한이 필요합니다. 그러나 계정 이름만 알면 타인의 계정을 잠글 수 있는 정책은 서비스 거부로 악용될 수 있습니다. 계정·IP·기기·위험 신호를 결합하고 정상 사용자의 복구 방법을 준비합니다.

실패 응답의 차이로 계정 존재가 드러나는지, 제한이 다른 엔드포인트나 구버전에서 우회되는지도 확인합니다. 로그인과 재설정·추가 인증의 실패 정책을 함께 봐야 합니다.

11장 서비스 계정은 사람과 다른 수명주기를 갖는다#

백엔드 작업과 자동화는 사람이 버튼을 누르는 MFA와 다른 신원 관리가 필요합니다. 짧은 수명의 자격증명, 업무별 서비스 계정, 최소 권한과 키 회수를 설계합니다. 여러 서비스가 하나의 관리자 키를 공유하면 영향과 추적 범위가 커집니다.

대상	필요한 검증	운영의 중요한 질문
일반 사용자	신원·세션·업무 인가	타인·다른 조직 접근 차단
관리자	강한 인증·민감 행위 확인	권한 변경·복구의 감사
서비스 계정	워크로드 신원·키 정책	최소 권한·교체·회수

12장 인증·인가를 각각 검증한다#

잘못된 비밀번호, 만료 토큰, 회수 계정은 인증·세션 시험에 넣습니다. 정상 로그인으로 타인 객체·관리자 기능·다른 조직을 요청하는 경우는 인가 시험에 넣습니다. 두 결과를 별도로 기록하면 어떤 경계가 실패했는지 설명하기 쉽습니다.

최종 확인은 화면에서 버튼을 숨긴 여부가 아니라 실제 요청이 서버에서 거부되는지입니다. 경로·메서드·API 버전·배치까지 같은 권한 정책이 적용되는지 확인합니다.

13장 적용 사례와 운영 방법#

계정 탈취에 대비해 주요 작업에서 재인증하고, 인증 수단을 분실했을 때 복구가 우회 경로가 되지 않도록 설계합니다. 생체 템플릿은 비밀번호처럼 쉽게 교체할 수 없으므로 수집 최소화, 저장 위치와 보호 방식을 검토합니다.

14장 로그인 이후에도 인가 판단은 계속된다#

식별은 누구라고 주장하는지, 인증은 그 주장을 어떻게 확인하는지, 인가는 어떤 행위를 허용하는지를 다룹니다. 로그인 성공은 타인의 주문이나 관리자 기능에 접근할 권리를 뜻하지 않습니다. 요청의 사용자·대상 자원·행위·조직 경계를 서버에서 연결해 판단해야 합니다.

MFA는 서로 다른 인증 요소를 결합합니다. 비밀번호와 PIN처럼 같은 지식 요소를 두 번 묻는 방식은 일반적인 다중 요소의 의미와 다릅니다. 추가 요소가 있어도 피싱·중계 공격의 저항성은 방식에 따라 다르므로 관리자와 고위험 작업은 강한 인증 및 재인증 조건을 따로 정합니다.

15장 계정 복구가 가장 약한 경로가 되지 않게 한다#

일상 로그인에 강한 인증을 넣고 복구를 단순한 개인정보 질문으로 허용하면 공격자가 복구 경로로 우회할 수 있습니다. 기기 분실·퇴사·전화번호 변경을 포함해 복구 신원 확인, 기존 세션 회수, 변경 알림과 감사기록을 설계합니다. 계정 잠금은 공격 억제뿐 아니라 타인의 계정을 고의로 잠그는 서비스 거부도 고려해야 합니다.

시험에서는 일반 사용자로 관리자 API 호출, 다른 조직의 자원 접근, 권한 회수 후 기존 토큰 사용을 확인합니다. 인증 실패 메시지로 계정의 존재가 과도하게 드러나지 않는지도 점검합니다. 서비스 계정은 사람의 MFA만으로 관리되지 않으므로 별도 신원과 키 수명주기가 필요합니다.

16장 적용 전 확인할 사항#

신원 확인과 자원별 인가를 별도로 검증한다
MFA 등록·변경·복구 경로까지 보호한다
생체정보의 보관·삭제와 오류율을 확인한다

17장 자주 묻는 질문#

MFA를 적용하면 인가 검사를 생략할 수 있나요?#

MFA는 계정의 신원 확인을 강화합니다. 자원 소유권과 역할·조건을 확인하는 서버 측 인가 검사는 계속 필요합니다.

MFA를 켜면 세션 토큰이 유출되어도 괜찮나요?#

이미 인증된 세션을 탈취하면 로그인 과정을 거치지 않을 수 있습니다. 토큰 저장·만료·회수와 고위험 작업의 추가 검증을 함께 적용해야 합니다.

인증과 인가는 같은 보안 미들웨어에서 처리해도 되나요?#

구현 위치를 공유할 수 있지만 판단 근거와 실패 처리는 구분해야 합니다. 각 기능의 대상 자원과 업무 권한까지 중앙 미들웨어가 이해하는지 확인해야 합니다.