식별(Identification) / 인증(Authentication)
정보보호 접근통제에서 주체가 누구인지 주장하는 절차와, 그 주장이 참인지 검증하는 절차를 분리하여 계정관리, 인증요소, 세션, 권한부여, 감사추적의 출발점으로 삼는 보안 개념이다.
Ⅰ. 개요 및 등장배경
가. 식별과 인증의 개념
식별(Identification)은 시스템 접근 주체가 자신이 누구인지 주장하는 단계다. 사용자가 ID, 이메일, 사번, 계정명, 인증서 식별자, 디바이스 ID, API Client ID를 제시하는 행위가 식별에 해당한다. 식별은 “나는 누구다”라는 주장에 가깝고, 아직 그 주장의 진위가 확인된 상태는 아니다. 따라서 식별 값은 고유성, 추적성, 관리 가능성이 중요하지만, 식별 값 자체만으로 사용자 신뢰를 부여하면 안 된다.
인증(Authentication)은 식별된 주체가 실제 그 주체인지 검증하는 단계다. 비밀번호, OTP, 생체정보, 인증서, FIDO 보안키, 디바이스 인증, 지식 기반 질문, 위치·행위 기반 신호 등을 활용해 주체의 정당성을 확인한다. 인증이 완료되면 시스템은 인증된 사용자에게 세션, 토큰, 쿠키, 인증 컨텍스트를 부여하고, 이후 권한부여와 감사추적 단계로 연결한다. 즉, 식별은 주체 선언이고, 인증은 선언 검증이며, 권한부여는 검증된 주체에게 어떤 자원 접근을 허용할지 결정하는 절차다.
나. 등장배경
초기 정보시스템은 사내망과 물리적 통제에 의존하는 경우가 많아 단순 ID와 비밀번호만으로도 기본 접근통제가 가능했다. 그러나 인터넷 서비스, 모바일 앱, 클라우드, API, 원격근무, SaaS, 마이크로서비스가 확산되면서 접근 주체와 접속 위치가 다양해졌다. 공격자는 탈취된 계정, 피싱, 크리덴셜 스터핑, 세션 탈취, API 키 유출, 디바이스 위조를 통해 정상 사용자처럼 접근할 수 있다. 이에 따라 단순 식별과 단일 비밀번호 인증만으로는 충분하지 않게 되었다.
현대 보안 아키텍처에서는 IAM, MFA, SSO, Zero Trust, Risk-Based Authentication이 중요해졌다. 사용자가 누구인지, 어떤 디바이스에서 접근하는지, 접속 위치와 행위가 정상인지, 접근 대상 자원이 민감한지, 현재 세션 위험도가 어떤지 지속적으로 평가해야 한다. 식별과 인증은 접근통제의 첫 관문이자 계정 생애주기, 권한관리, 감사추적, 사고대응의 기준점이다.
다. 접근통제 흐름에서 위치
식별 → 인증 → 권한부여 → 책임추적
- 식별: 주체가 사용자 ID, 계정명, 인증서 주체명, Client ID를 제시한다.
- 인증: 비밀번호, OTP, 인증서, 생체정보, FIDO 등으로 식별 주체를 검증한다.
- 권한부여: 인증된 주체에게 역할, 속성, 정책 기반으로 자원 접근을 허용한다.
- 책임추적: 누가 언제 어떤 자원에 접근했는지 로그와 감사 기록으로 남긴다.
- 지속 검증: Zero Trust 환경에서는 로그인 이후에도 세션 위험과 디바이스 상태를 지속 확인한다.
식별은 주체가 자신을 주장하는 절차이고, 인증은 그 주장이 참인지 검증하는 절차다.
두 개념을 구분해야 권한부여, 세션관리, 감사추적, Zero Trust 보안 정책을 정확히 설계할 수 있다.
Ⅱ. 구성도 및 구성요소
가. 구성도
Identity 축
식별자, 계정 저장소, 계정 생애주기를 통해 주체의 고유성과 추적성을 관리한다.
Authentication 축
MFA, FIDO, 인증서, 위험기반 인증으로 식별 주장의 신뢰도를 검증한다.
나. 구성요소
| 구분 | 요소 | 설명 |
|---|---|---|
| 주체 | Subject | 사용자, 관리자, 서비스 계정, API 클라이언트, 디바이스, 워크로드처럼 자원 접근을 요청하는 대상이다. |
| 식별 | Identifier | ID, 이메일, 사번, 인증서 주체명, Client ID, 디바이스 ID처럼 주체를 구분하는 값이다. |
| 저장소 | Identity Repository | 사용자 계정, 속성, 그룹, 역할, 상태, 인증수단 정보를 관리하는 AD, LDAP, IAM, 사용자 DB다. |
| 인증요소 | Credential | 비밀번호, OTP, 인증서 개인키, FIDO 보안키, 생체정보 템플릿 등 주체 검증에 사용하는 정보다. |
| 인증서버 | Authentication Server | 인증요소를 검증하고 인증 결과, 토큰, 세션, 인증 컨텍스트를 생성하는 서버다. |
| 세션 | Session / Token | 인증 성공 후 지속 접근을 위해 발급되는 쿠키, JWT, SAML Assertion, Access Token이다. |
| 정책 | Access Policy | 인증 강도, MFA 요구, 위치 제한, 디바이스 상태, 자원 민감도, 역할 기반 접근 조건을 정의한다. |
| 권한 | Authorization | 인증된 주체에게 어떤 자원과 기능을 허용할지 RBAC, ABAC, 정책 기반으로 판단한다. |
| 감사 | Audit Log | 로그인 성공·실패, MFA 결과, 토큰 발급, 권한 변경, 접근 시도 이력을 기록한다. |
| 운영 | Lifecycle Management | 계정 생성, 변경, 휴면, 잠금, 퇴사자 제거, 권한 회수, 인증수단 재등록을 관리한다. |
다. 식별과 인증 비교
| 구분 | 식별(Identification) | 인증(Authentication) |
|---|---|---|
| 의미 | 주체가 자신이 누구인지 주장하는 절차 | 그 주장이 실제로 맞는지 검증하는 절차 |
| 입력값 | ID, 이메일, 사번, 계정명, Client ID | 비밀번호, OTP, 인증서, FIDO, 생체정보 |
| 보안성 | 값 노출 자체가 곧 인증 성공을 의미하지 않아야 함 | 도용·재사용·탈취에 견디는 검증 강도가 필요함 |
| 실패 영향 | 존재하지 않는 사용자, 중복 계정, 추적 불가 문제 | 계정 탈취, 권한 오남용, 데이터 유출 문제 |
| 주요 통제 | 고유 ID 정책, 계정 생애주기, 중복 방지, 휴면 관리 | MFA, 패스워드 정책, 인증서 검증, 위험기반 인증 |
| 후속 단계 | 인증 서버가 해당 주체의 인증수단을 조회 | 토큰·세션 발급 후 권한부여와 감사추적으로 연결 |
구성요소는 주체, 식별자, 계정 저장소, 인증요소, 인증서버, 세션·토큰, 접근정책, 감사로그로 구성된다.
식별은 주체 선언이고 인증은 선언 검증이므로, 두 단계를 혼동하면 접근통제 설계가 약해진다.
Ⅲ. 동작방식 및 아키텍처
가. 일반 로그인 인증 흐름
일반 로그인 절차에서는 사용자가 먼저 ID 또는 이메일을 입력해 자신을 식별한다. 시스템은 해당 식별자를 계정 저장소에서 조회하고, 계정 상태, 잠금 여부, 휴면 여부, MFA 등록 여부를 확인한다. 이후 사용자는 비밀번호, OTP, FIDO 보안키, 생체정보 같은 인증요소를 제시한다. 인증서버는 저장된 검증정보와 사용자가 제출한 정보를 비교하거나 암호학적 Challenge-Response를 수행해 인증 성공 여부를 결정한다.
인증이 성공하면 서버는 세션 ID, 쿠키, JWT, Access Token, Refresh Token 같은 인증 상태 정보를 발급한다. 이후 사용자의 요청마다 서버는 세션 또는 토큰을 확인하고, 해당 사용자와 권한 정보를 바탕으로 자원 접근 여부를 결정한다. 인증 실패가 반복되면 계정 잠금, 지연 응답, CAPTCHA, 추가 인증, 관리자 알림 같은 방어 조치가 적용될 수 있다.
나. 다중요소 인증 동작방식
MFA는 서로 다른 범주의 인증요소를 조합하여 계정 탈취 위험을 낮춘다. 인증요소는 사용자가 아는 것, 사용자가 가진 것, 사용자 자체 속성, 사용자 행위 또는 위치 신호로 구분할 수 있다. 비밀번호가 유출되어도 OTP나 FIDO 보안키가 필요하면 공격 난이도가 크게 높아진다.
MFA는 모든 상황에 동일하게 적용할 수도 있고, 위험기반 인증 방식으로 필요한 상황에만 추가 요구할 수도 있다. 평소 사용하던 기기와 위치에서 일반 업무 시스템에 접근할 때는 기본 인증만 요구하고, 해외 접속, 새 디바이스, 관리자 기능 접근, 대량 다운로드, 비정상 행위가 탐지될 때 추가 인증을 요구할 수 있다.
다. SSO와 연합 인증 구조
SSO는 사용자가 한 번 인증하면 여러 서비스에 반복 로그인 없이 접근할 수 있게 하는 구조다. 조직은 IdP를 통해 중앙 인증을 수행하고, 개별 서비스는 IdP가 발급한 SAML Assertion, OIDC ID Token, Access Token을 신뢰한다. 이 구조는 사용자 편의성을 높이고, 계정 관리와 MFA 정책을 중앙화하며, 퇴사자 권한 회수와 감사 추적을 단순화한다.
연합 인증에서는 서로 다른 조직이나 서비스 간 신뢰 관계가 중요하다. SAML, OAuth 2.0, OpenID Connect 같은 표준을 활용해 인증 결과와 사용자 속성을 전달한다. 다만 토큰 탈취, 잘못된 Redirect URI, Client Secret 유출, 과도한 Scope 부여, 서명 검증 오류가 발생하면 공격자가 정상 사용자처럼 접근할 수 있다.
라. Zero Trust 인증 아키텍처
Zero Trust 환경에서는 한 번 로그인했다고 계속 신뢰하지 않는다. 사용자의 신원, 디바이스 보안 상태, 네트워크 위치, 접속 시간, 행위 패턴, 자원 민감도, 세션 위험도를 지속적으로 평가한다. 같은 사용자가 로그인했더라도 관리 콘솔 접근, 개인정보 다운로드, 대량 API 호출처럼 위험도 높은 행위에서는 재인증이나 추가 승인이 필요할 수 있다.
Zero Trust 인증 아키텍처는 IAM, MFA, 디바이스 관리, 네트워크 세분화, 정책 엔진, 로그 분석, SIEM, UEBA와 결합된다. 인증은 단순 로그인 절차가 아니라 접근 요청마다 동적으로 평가되는 신뢰 결정 과정이 된다.
식별·인증은 ID 제시, 계정 조회, 인증요소 검증, 세션·토큰 발급, 권한부여 흐름으로 동작한다.
현대 환경에서는 MFA, SSO, 연합 인증, Zero Trust, 위험기반 인증을 조합해 지속 검증 구조를 만든다.
Ⅳ. 실무적용 및 사례
가. 기업 IAM 적용 사례
기업 환경에서는 임직원, 협력사, 관리자, 서비스 계정이 다양한 업무 시스템에 접근한다. IAM을 구축하면 HR 시스템의 입사·부서이동·퇴사 정보를 기준으로 계정을 자동 생성·변경·비활성화하고, AD 또는 LDAP과 연동해 식별 정보를 중앙 관리할 수 있다. 사용자는 SSO를 통해 여러 업무 시스템에 접근하고, 관리자 권한이나 민감 시스템 접근 시 MFA를 요구받는다.
중요한 점은 계정 생애주기와 권한 회수다. 퇴사자가 계정 저장소에는 비활성화되었지만 SaaS나 클라우드 콘솔에는 권한이 남아 있으면 보안 사고로 이어질 수 있다. 따라서 식별자는 HR 기준정보와 연결하고, 인증 정책은 중앙 IdP에서 통제하며, 권한 부여 내역은 주기적으로 검토해야 한다.
나. 금융 서비스 인증 사례
금융 서비스에서는 로그인뿐 아니라 이체, 대출 신청, 개인정보 변경, 인증수단 재등록처럼 위험도가 높은 행위에 강한 인증이 요구된다. 사용자는 ID와 비밀번호로 1차 인증을 수행하고, 이후 OTP, FIDO, 공동인증서, 생체인증, 기기 인증을 추가로 수행할 수 있다. 비정상 위치나 새로운 기기에서 접근하면 위험기반 인증이 작동해 추가 검증을 요구한다.
금융 인증 설계에서는 인증수단 등록 절차도 매우 중요하다. 공격자가 피해자의 계정을 탈취한 뒤 자신의 기기를 인증수단으로 등록하면 이후 강한 인증을 우회할 수 있다. 따라서 인증수단 등록·해지·재발급 단계에는 기존 인증수단 확인, 본인확인, 지연 적용, 알림, 이상탐지, 고객센터 승인 절차가 필요하다.
다. API와 서비스 계정 인증 사례
시스템 간 API 호출에서도 식별과 인증이 필요하다. 서비스는 Client ID로 자신을 식별하고, Client Secret, mTLS 인증서, JWT Assertion, API Key, OAuth Client Credentials로 인증한다. 사용자가 직접 로그인하지 않는 서버 간 통신에서는 사람 계정과 다른 생애주기와 권한 관리가 필요하다. API Key가 소스코드나 로그에 노출되면 공격자가 정상 서비스처럼 API를 호출할 수 있으므로 안전한 비밀정보 관리가 중요하다.
실무에서는 API Gateway가 클라이언트 식별, 토큰 검증, Rate Limit, Scope 검증, mTLS 검증, 감사로그 생성을 담당한다. 서비스 계정 권한은 최소권한 원칙으로 제한하고, 비밀정보는 Vault, KMS, Secret Manager에 저장하며, 주기적 회전과 사용 이력 모니터링을 적용한다.
라. 적용 분야별 정리
| 분야 | 식별 대상 | 인증 방식 | 설계 고려사항 |
|---|---|---|---|
| 기업 업무시스템 | 임직원, 협력사, 관리자 | SSO, MFA, AD/LDAP 연동 | 입퇴사 연동, 권한 회수, 관리자 접근 통제 |
| 금융 서비스 | 고객, 금융 앱, 등록 기기 | 비밀번호, OTP, FIDO, 생체인증, 기기인증 | 위험기반 인증, 인증수단 재등록 통제, 거래 단계 재인증 |
| 클라우드 | 사용자, Role, 워크로드, 서비스 계정 | IAM Role, STS, MFA, Federation | Root 계정 보호, 임시자격증명, 최소권한, Access Key 관리 |
| API 서비스 | Client ID, 서비스 계정, 애플리케이션 | OAuth, mTLS, API Key, JWT | Secret 보호, Scope 제한, Rate Limit, 토큰 만료시간 |
| IoT | 디바이스, 게이트웨이, 센서 | 디바이스 인증서, Secure Element, mTLS | 대량 등록, 인증서 갱신, 분실·탈취 디바이스 폐기 |
| Zero Trust | 사용자, 기기, 세션, 애플리케이션 | MFA, 디바이스 상태검증, 위험기반 인증 | 지속 검증, 정책 엔진, 행위 분석, 세션 재평가 |
마. 실무 점검사항
고유성·변경관리·중복 방지
업무위험별 MFA·FIDO 적용
만료·갱신·폐기·재인증
입사·이동·퇴사·휴면 자동화
API Key·Client Secret·인증서 보호
실패·성공·권한변경·토큰발급 추적
실무에서는 사용자 계정뿐 아니라 서비스 계정, API 클라이언트, 디바이스까지 식별·인증 대상으로 관리해야 한다.
인증수단 등록, 토큰 발급, 세션 갱신, 권한 회수, 감사로그까지 전체 생애주기 관점으로 설계해야 한다.
Ⅴ. 비교분석 및 발전전망
가. 식별·인증·인가·감사 비교
| 구분 | 질문 | 대표 수단 | 보안 목적 |
|---|---|---|---|
| 식별 | 누구라고 주장하는가? | ID, 이메일, Client ID, 인증서 주체명 | 주체 구분, 계정 조회, 추적성 확보 |
| 인증 | 정말 그 주체가 맞는가? | Password, OTP, FIDO, 인증서, 생체정보 | 계정 도용 방지, 신원 검증 |
| 인가 | 무엇을 할 수 있는가? | RBAC, ABAC, ACL, Policy Engine | 최소권한, 자원 접근 통제 |
| 감사 | 누가 무엇을 했는가? | Access Log, Audit Log, SIEM | 책임추적, 사고분석, 규제 대응 |
나. 인증 방식 비교
| 방식 | 장점 | 한계 | 적용 방향 |
|---|---|---|---|
| Password | 구현이 쉽고 사용자 친숙도 높음 | 피싱, 재사용, 사전공격, 유출 위험 | MFA와 패스워드 해시 보호 병행 |
| OTP | 일회성 코드로 비밀번호 유출 보완 | 피싱 프록시, SIM Swap, 사용자 불편 | 고위험 거래나 관리자 접근에 적용 |
| 인증서 | 공개키 기반 강한 인증 가능 | 발급·갱신·폐기·저장매체 관리 부담 | 기업, API, 디바이스, mTLS에 적합 |
| 생체인증 | 사용자 편의성과 소유자 결합성 우수 | 변경 어려움, 프라이버시, 센서 품질 이슈 | 로컬 매칭과 FIDO 결합이 적합 |
| FIDO | 피싱 저항성, 공개키 기반, 패스워드리스 가능 | 디바이스 등록·분실 대응 설계 필요 | 고위험 서비스와 패스워드리스 전환에 적합 |
| Risk-Based | 상황별 인증강도 조절 가능 | 위험평가 모델과 로그 품질 의존 | Zero Trust와 사용자 편의성 균형에 적합 |
다. 장점과 한계
식별·인증 체계를 명확히 설계하면 사용자와 시스템 주체를 추적할 수 있고, 권한부여와 감사추적의 기준을 안정적으로 제공할 수 있다. MFA와 SSO를 결합하면 사용자 편의성과 보안성을 동시에 높일 수 있으며, 중앙 IAM을 통해 계정 생성과 권한 회수를 자동화할 수 있다. 또한 위험기반 인증과 Zero Trust를 적용하면 로그인 이후에도 세션 위험을 지속적으로 평가할 수 있다.
한계도 존재한다. 인증이 강해도 권한부여가 과도하면 데이터 유출이 발생할 수 있고, 식별자 관리가 부실하면 퇴사자 계정이나 공유 계정이 남을 수 있다. 비밀번호 기반 인증은 피싱과 재사용 공격에 취약하며, OTP도 실시간 피싱 프록시에 노출될 수 있다. 생체정보는 편리하지만 유출 시 변경이 어렵고, 인증서와 키 기반 방식은 발급·폐기·키 보호 운영이 중요하다.
라. 발전전망
식별·인증 기술은 패스워드 중심에서 패스워드리스, FIDO2, WebAuthn, 분산 신원, 지속 인증 방향으로 발전하고 있다. 패스워드리스 인증은 사용자가 기억해야 하는 비밀번호를 줄이고, 공개키 기반 Challenge-Response를 통해 피싱 저항성을 높인다.
클라우드와 마이크로서비스 환경에서는 사람 사용자뿐 아니라 워크로드와 서비스 계정의 인증이 중요해진다. 단기 자격증명, 워크로드 아이덴티티, mTLS, 서비스 메시, SPIFFE/SPIRE 같은 기술은 서비스 간 상호 인증과 최소권한 적용을 지원한다. 향후 인증 체계는 “로그인 한 번”보다 사용자의 행위, 디바이스 상태, 네트워크 위험, 자원 민감도를 지속 평가하는 적응형 보안 모델로 발전한다.
마. 시험 답안 정리
- 정의는 식별이 주체 선언, 인증이 주체 검증이라는 차이로 정리한다.
- 구성도는 Subject, Identification, Authentication, Identity Repository, Authentication Server, Token/Session, Authorization, Audit 흐름으로 표현한다.
- 인증요소는 지식, 소유, 생체, 위치, 행위 기반으로 구분한다.
- 관련 기술은 IAM, MFA, SSO, OAuth, OIDC, SAML, FIDO, Zero Trust를 제시한다.
- 보안 이슈는 계정 탈취, 피싱, 세션 탈취, 인증수단 재등록 공격, 공유 계정, 서비스 계정 Secret 유출로 설명한다.
식별과 인증은 접근통제의 출발점이며, 인증 이후 권한부여와 감사추적으로 이어져야 보안 통제가 완성된다.
향후 인증체계는 MFA와 SSO를 넘어 FIDO 기반 패스워드리스, Zero Trust, 지속 인증, 워크로드 아이덴티티 중심으로 발전한다.
'네트워크보안' 카테고리의 다른 글
| XDR 핵심 요약: 엔드포인트(EDR)와 네트워크(NDR)를 넘어선 차세대 위협 탐지 (0) | 2026.04.23 |
|---|---|
| 현대 전쟁의 제5영역, 사이버전(Cyberwarfare) 핵심 요약: 탈린 매뉴얼과 사이버 억지력 (0) | 2026.04.23 |
| 제로데이(Zero-Day) 공격 구조와 취약점 기반 침투 메커니즘 (0) | 2026.04.18 |
| 사이버 수사의 핵심 절차: 안티 포렌식(Anti-Forensics) 공격과 디스크 이미징 방어 전략 (0) | 2026.04.18 |
| 데이터 무결성과 인증의 완성: 디지털 서명의 해시+비대칭키 아키텍처 및 MAC 비교 (0) | 2026.04.17 |
