요약
- 인증은 비밀번호, 패스키, 다중 인증 프롬프트 등 개인의 자격 증명을 식별하여 사용자가 누구인지 확인하고, 이를 통해 신원을 검증하는 과정입니다.
- 권한 부여는 검증된 각 사용자/워크로드에 어떤 역할/속성/정책이 적용되는지 평가하여 무엇을 할 수 있는지 결정합니다. 즉, 인증 이후 어떤 리소스/작업에 대한 접근이 허용되는지를 판단합니다.
- OpenID Connect (OIDC)는 인증에 사용되며, OAuth 2.0은 API/서비스 위임 기반 권한 부여에 사용됩니다.
- 인증과 권한 부여를 혼동하면 심각한 설계 오류로 이어질 수 있습니다. 예를 들어, 유효한 로그인에 갑자기 가능한 모든 작업 수행 권한을 부여하거나(해당 권한이 없어도), 사용자에게 과도한 권한의 역할을 할당하거나, 추적·관리·감사가 어려운 하드코딩된 권한 검사에 의존하게 될 수 있습니다.
소개
현재 인터넷은 그리 좋은 상태가 아니며 흔들리고 있습니다. cPanel 및 WHM 인증 우회 CVE-2026-41940은 얼마나 많은 호스팅 제공업체가 여전히 구버전에 머물러 있는지, 그리고 그 잠재적 피해 범위가 실제로 어느 정도인지 보여주었습니다. 그리고 이 익스플로잇은 모든 버전에 영향을 미칩니다.
침해를 당한 경우를 생각하면, 이는 강력한 네트워크 세분화 뒤에 인프라를 보호해야 한다는 점을 다시 상기시켜 줍니다.
Microsoft 역시 최근 13k+ 조직 전반에 걸쳐 35k명이 넘는 사용자를 표적으로 한 대규모 다단계 피싱 캠페인에 직면했습니다. 해커들은 MFA를 우회하고 세션 쿠키를 탈취하기 위해 Adversary-in-the-Middle (AiTM) 기법을 사용했습니다.
이 내용이 혼란스럽고 인증 공격과 권한 부여 공격의 차이를 잘 모르겠다면 계속 읽어보세요. 아래에서 설명하겠습니다.
인증이란 무엇인가?
인증은 사용자가 자신이 누구인지 증명하게 하며, 민감한 데이터를 무단 접근으로부터 보호합니다. 이는 불법적인 접근을 차단하고, 시스템에 로그인하기 위해 사용자 이름과 비밀번호 같은 자격 증명을 제공하도록 요구합니다.
디지털이 아닌 경우에는 공증된 문서를 검증해야 합니다. 예방적 보안에서 인증은 민감한 데이터를 보호하는 데 사용됩니다.
일반적인 인증 방법
인증은 신원을 확인하기 위해 다음 요소 중 하나 이상에 의존합니다:
- 비밀번호, PIN, 그리고 본인만 알고 있는 일반적인 보안 질문에 대한 답변
- 스마트 카드, 하드웨어 토큰, OTP
- 지문 스캔, 얼굴 인식, 홍채 스캔과 같은 생체 인식
인증 공격의 유형
다음은 알아두어야 할 일반적인 인증 공격 유형입니다:
- Credential stuffing 및 brute force. 이전 침해에서 유출된 사용자 이름 또는 비밀번호 쌍을 재사용하거나, 속도 제한이 미흡할 때 취약한 로그인을 반복적으로 시도하는 방식입니다.
- 피싱 및 MFA 피로 공격. 주로 신뢰할 수 있는 브랜드를 모방하는 사회공학 기법을 통해 사용자가 자격 증명을 노출하거나 프롬프트를 승인하도록 속이는 방식입니다.
- 세션 하이재킹. 브라우저, 디바이스 또는 메모리에서 토큰을 탈취하여 공격자가 로그인 양식을 완전히 건너뛸 수 있게 하는 방식입니다.
- 디바이스 침해. 이미 검사를 통과한 신뢰된 디바이스를 장악한 뒤, 그와 함께 제공된 세션 컨텍스트를 악용하는 방식입니다.
권한 부여란 무엇인가?
권한 부여는 로그인한 사용자가 네트워크 또는 시스템 내에서 무엇을 할 수 있는지 확인하는 보안 프로세스입니다. 기본적으로 사용자가 무엇을 할 수 있는지, 또는 허용된 권한 범위 내에서 무엇이 허용되는지를 알려줍니다.
권한 부여는 인증이 성공한 이후에만 수행되며, 그 이전에는 수행되지 않습니다. 이는 사용자 신원을 일련의 규칙 또는 정책과 비교 평가한 뒤, 그에 따라 특정 리소스에 대한 접근을 허용하거나 거부합니다.
권한 부여 모델 및 프로토콜의 유형
다음은 알아두어야 할 일반적인 권한 부여 역할 모델 유형입니다:
- 역할 기반 접근 제어(RBAC): 권한은 개별 사용자보다 관리자, 편집자, 뷰어와 같은 특정 역할에 부여됩니다. 이는 기업 환경에서 가장 일반적으로 사용되는 모델 중 하나입니다.
- 속성 기반 접근 제어(ABAC): 이는 의사결정을 위해 속성을 사용하는 매우 유연한 권한 부여 모델입니다. 사용자 및 부서 세부 정보, 리소스 유형 정보, 환경 컨텍스트(예: 디바이스 보안, 위치, 시간대 등)가 포함될 수 있습니다.
- 임의 접근 제어: 리소스 소유자가 누가 무엇에 접근할 수 있는지, 그리고 누가 접근 가능한지를 전적으로 제어합니다. Google drive 또는 Windows 폴더의 파일 공유와 유사합니다.
- 강제 접근 제어(MAC): 엄격하게 정의된 보안 레이블을 기반으로 접근이 결정되는 가장 제한적인 권한 부여 모델 중 하나입니다. 중앙에서 기밀 정보를 관리하며, 군사 및 고등급 보안 정부 시스템에서 매우 일반적으로 사용됩니다.
- 관계 기반 접근 제어(ReBAC): 사용자와 리소스 간의 관계를 기반으로 접근이 결정됩니다. 이는 좀 더 개인화된 방식으로, 리소스의 소유자이거나 특정 폴더의 구성원인 경우와 유사합니다.
그리고 최신 권한 부여 유형 및 프로토콜에 대해 알아야 할 내용은 다음과 같습니다:
- OAuth 2.0: 위임된 권한 부여를 위한 업계 표준입니다. 비밀번호를 노출하지 않고도 서드파티 앱이 사용자 데이터에 접근할 수 있게 합니다.
- JSON Web Tokens (JWT): 두 당사자 간의 클레임을 표현하는 간결하고 URL 안전한 방식입니다. 서버는 누군가 로그인하면 JWT를 발급하며, 이는 기본적으로 "사용자는 X에 대해 권한이 있다"는 의미를 담고 있고, 이후 요청을 확인할 때도 제시할 수 있습니다.
- Access Control Lists (ACLs): 이는 리소스에 연결되는 간단한 목록으로, 사용자와 그룹의 이름을 명시합니다. 또한 이들이 어떤 권한을 갖는지도 알려줍니다. 단점은 기업 규모가 커질수록 대규모 환경에서 관리가 훨씬 어려워진다는 점입니다.
인증과 권한 부여의 핵심 차이점
인증과 권한 부여의 차이는 종종 한 문장으로 요약되지만, 설계 작업에는 더 많은 세부 사항이 필요합니다. 다음은 인증과 권한 부여가 갈라지는 영역입니다.
1. 접근 흐름에서의 순서
인증은 권한 부여보다 먼저 발생합니다. 인증 단계에서는 Identity Context가 생성됩니다. 이후 권한 부여 단계에서는 특정 작업을 허용할지 결정할 때 이 Identity Context를 고려합니다.
즉, 이러한 단계를 독립적으로 실행되도록 하고(하나의 단일 프로세스로 취급하지 않음), "사용자가 이미 인증했다"는 이유로 넘기지 않으면, 이후 각 단계가 보안 측면에서 검증되도록 보장할 수 있습니다. 건전한 시스템에서는 모든 민감한 작업이 두 계층을 모두 거칩니다.
2. 사용되는 데이터
인증은 비밀번호, PIN, 보안 질문-답변, 소유 요소(예: 이메일 및 SMS를 통한 OTP, 하드웨어 토큰 일련번호, 디지털 인증서), 고유성 요소(지문 템플릿, 얼굴 기하학 스캔, 홍채 패턴), 그리고 엔터티 ID(이메일, 직원 ID, 사용자 이름과 같은 고유 식별자)를 사용합니다.
권한 부여는 권한 규칙과 관련된 데이터, 예를 들어 신원에 할당된 레이블(사용자 역할), 사용자 및 리소스 속성(접근 대상인 사람과 객체에 대한 특정 메타데이터), 환경 컨텍스트(IP 주소, 디바이스 상태, 시간, 위치)를 사용합니다.
3. 실패 모드 및 오류 처리
인증 실패 오류는 일반적으로 잘못된 자격 증명 메시지 또는 CAPTCHA/MFA 챌린지로 이어지며, 반복 시도는 대개 사용자 계정을 잠급니다. 반면 권한 부여 실패 오류는 금지 메시지를 표시하거나, 리소스 정보를 숨기거나, 접근 제어 권한에 대해 추가 권한 부여를 요구합니다.
인증 및 권한 부여 실패 오류를 일반 오류 또는 무음 실패 오류로 처리하면 사고 대응이 복잡해집니다. 적절한 로깅과 인증 오류 및 권한 부여 오류의 구분은 대응 담당자가 공격자가 문 앞에 도달했는지, 아니면 내부를 탐색하고 있는지를 판단하는 데 도움이 됩니다.
4. 소유권 및 책임
인증의 소유권은 일반적으로 ID 팀 또는 single sign-on (SSO), MFA, ID 공급자를 다루는 플랫폼 팀에 있습니다. 반면 권한 부여의 소유권은 애플리케이션 팀, 보안 팀, 그리고 각 작업에 무엇이 요구되어야 하는지 아는 데이터 소유자 사이에 걸쳐 있습니다.
한 팀이 전권을 행사하고 비즈니스 소유자와 협의하지 않았다면, 권한에 변화가 생길 가능성이 높습니다.
인증 vs 권한 부여: 주요 차이점
인증과 권한 부여를 한눈에 비교하거나 개요를 보고 싶으신가요? 다음은 빠른 참조용 표입니다:
| 기능 | 인증 | 권한 부여 | 예시 |
| 핵심 질문 | 사용자 또는 워크로드가 누구인지 검증합니다. | 해당 신원이 무엇에 접근할 수 있는지 결정합니다. | 직원이 MFA로 로그인한 후, 정책이 어떤 HR 기록을 볼 수 있는지 결정합니다. |
| 일반적인 데이터 | 자격 증명, 생체 정보, 디바이스 또는 워크로드 신원. | 역할, 속성, 리소스 레이블, 위험 점수. | API 호출은 ID 토큰과 역할 클레임 및 프로젝트 태그를 함께 전달합니다. |
| 주요 표준 | OIDC, SAML, 플랫폼 로그인 프로토콜. | OAuth 2.0, 정책 엔진, ABAC 및 RBAC 규칙. | OIDC는 사용자를 로그인시키고, OAuth 범위는 호출 가능한 API를 정의합니다. |
| 실행 시점 | 보호된 리소스에 접근하기 전에 실행됩니다. | 인증 이후 모든 접근 결정 시점마다 실행됩니다. | 사용자 세션은 유효하지만, 고위험 송금은 여전히 추가 검사를 트리거합니다. |
| 실패 시 동작 | 로그인을 차단하거나 추가 증명을 요구합니다. | 특정 작업을 거부하고, 리소스를 숨기거나, 검토를 위해 상향 처리합니다. | 비밀번호 재설정 실패와 “허용되지 않음”이 표시되는 결제 승인 화면의 차이. |
기업이 흔히 저지르는 인증 vs 권한 부여 실수
다음은 모든 기업이 피해야 할 일반적인 인증 및 권한 부여 실수 목록입니다:
로그인을 유일한 관문으로 취급
다른 팀은 사용자가 이미 로그인했다면 애플리케이션 내에서 수행하는 모든 작업이 허용된다고 생각할 수 있습니다. 따라서 모든 데이터를 한 번에 내보내기, 구성 변경, 토큰 생성과 같은 고위험 프로세스가 그 단 하나의 로그인 프로세스에만 의존하게 됩니다.
중요한 작업은 권한 부여, 위험 평가, 심지어 인증까지 자체적으로 수행하는 독립적인 통제 게이트로 간주되어야 합니다. 예를 들어 송금 작업에 대해 MFA 요구 수준을 높이는 것을 의미할 수 있습니다.
과도한 권한의 역할과 “만일을 대비한” 권한
팀 구성원이 “빠르게 움직일” 수 있도록 폭넓은 권한을 부여하고 나중에 정리하자는 것은 자연스러운 본능입니다. 권한 부여 오류에 대한 연구에 따르면, 그 “나중”은 결코 오지 않으며 시간이 지날수록 계정에는 공격자가 악용할 수 있는 불필요한 권한이 축적됩니다.
처음부터 범위가 좁은 역할을 설계하고 실제 업무에 맞게 정렬하면 더 나은 성과를 얻을 수 있습니다. 검토 프로세스는 불필요한 권한 제거와 마찬가지로 모든 접근 재인증 노력의 핵심 요소입니다.
애플리케이션 코드에 하드코딩된 검사
권한 부여 로직이 여러 서비스에 분산되어 있는 경우, 새로운 제품이 출시될 때마다 권한 접근 회귀의 새로운 위험이 발생합니다. 개발자가 “if user.is_admin”과 같은 복사-붙여넣기 방식의 기법을 사용하면 일부 예외 사례를 놓치고 감사 담당자의 업무를 더 어렵게 만들 수 있습니다.
이 문제는 권한 로직을 정책 또는 보안 및 컴플라이언스 팀이 접근할 수 있는 전문 서비스에 중앙화함으로써 완화할 수 있습니다. 제품은 여전히 어떤 정책을 사용해야 하는지 결정하되, 권한 자체는 중앙에서 관리됩니다.
Zero Trust 및 최신 아키텍처에서의 인증 vs. 권한 부여
Zero Trust 아키텍처에서는 ID가 새로운 보안 경계가 되고 있습니다. 시스템은 세션 전반에 걸쳐 사용자 신원과 디바이스 상태를 지속적으로 검증합니다. 권한은 더 이상 정적이지 않으며, 광범위한 실시간 신호를 기반으로 각 요청 시점에 평가됩니다.
최신 권한 부여 엔진은 접근을 허용하기 전에 이러한 신호를 평가하기 위해 Policy Decision Points (PDPs)를 사용합니다. 이들은 리소스 민감도, 디바이스 상태, 사용자 신원, 위치/네트워크를 고려합니다.
클라우드 네이티브 환경에서는 권한 부여가 사람만을 위한 것이 아니기 때문에 Machine-to-Machine (M2M) 보안도 고려되고 있습니다. 서비스 ID(비인간 사용자) 역시 인증 및 권한 부여를 거친 후에야 SPIFFE 및 MTLS와 같은 최신 프로토콜을 사용할 수 있으며, 이를 통해 자동화된 시스템이 네트워크를 가로질러 측면 이동하는 것을 방지하고 후속 침해를 예방합니다(하나가 침해된 경우에도).
더 안전한 인증 및 권한 부여 흐름을 설계하는 방법: 인증 vs 권한 부여 모범 사례
최상의 인증 및 권한 부여 설계는 미래를 내다봅니다. 이는 레거시 위협 모델이 아니라, 공격자가 2026년에 ID를 악용하는 방식에 대비해 조직을 준비시킵니다. 다음은 지금부터 도입할 수 있는 최고의 인증 및 권한 부여 모범 사례입니다:
- 로그인에는 OIDC를, API 접근에는 OAuth를 사용하십시오. 신원 증명과 위임된 접근을 분리하면, 각 책임을 혼동하지 않고 인증에는 ID 토큰을, 권한 부여에는 범위를 검증할 수 있습니다.
- 최소 권한 원칙을 정리 작업이 아니라 설계 단계에서 적용하십시오. 실제 업무에 매핑되는 역할과 정책을 구축하고, 강력한 권한에는 정당성을 요구하며, 공격자가 발견하기 전에 사용되지 않는 권한을 제거할 수 있도록 정기적인 접근 검토를 일정에 포함하십시오.
- 분산된 검사보다 정책 기반 권한 부여를 우선하십시오. 접근 규칙을 전용 정책 엔진 또는 서비스로 옮기고, 모든 민감한 작업마다 애플리케이션이 이를 호출하도록 하십시오. 이렇게 하면 감사, 변경, 테스트를 한 곳에서 관리할 수 있습니다.
- 지속적이고 위험 인지형 인증을 활성화하십시오. 자격 증명 노출, 디바이스 상태, 지리적 위치, 행동 분석과 같은 신호를 결합하여, 단일 로그인 이벤트에 의존하는 대신 고위험 작업에서 단계적 MFA 또는 토큰 폐기를 트리거하도록 하십시오.
- 토큰 수명을 단축하고 적시 권한 상승을 사용하십시오. 범위가 좁고 수명이 짧은 토큰을 발급한 뒤, 누군가 요청하고 추가 검사를 통과한 경우에만 임시 관리자 접근을 부여하십시오. 작업이 완료되면 해당 접근은 자동으로 만료되도록 하십시오.
- ID 로그를 엔드포인트 및 워크로드 텔레메트리와 통합하십시오. 인증 및 권한 부여 이벤트를 EDR 및 클라우드 워크로드 신호를 수집하는 동일한 데이터 레이크로 스트리밍하면, ID, 디바이스, 워크로드 경계를 넘나드는 공격을 추적할 수 있습니다.
- 성공 경로만큼 실패 경로도 신중하게 테스트하십시오. 인증 및 권한 부여 조건이 의도적으로 실패하도록 자동화 테스트와 카오스 스타일 연습을 추가하여, 오류, 경고, 로깅이 예상대로 동작하는지 확인하십시오.
이러한 관행을 일관되게 따르면, “정체불명의 관리자” 계정은 줄어들고, 사고 시 귀속은 더 명확해지며, 공격자가 탈취한 신원을 통제가 대응하기 전에 악용할 수 있는 시간 창도 훨씬 작아집니다.
SentinelOne이 ID 보안을 강화하는 방법
SentinelOne의 Singularity Platform은 Autonomous Security Intelligence (ASI)로 구동됩니다. 이는 플랫폼의 기반에 내장된 인텔리전스 패브릭으로, 악성 행위를 식별하고, 중요한 작업을 자동화하며, 머신 속도로 위협에 대응합니다. ID 공급자가 누가 로그인할 수 있고 무엇에 접근할 수 있는지를 관리하는 반면, Singularity Identity는 보안 집행 계층을 추가하여 자격 증명 악용을 탐지하고, 측면 이동을 차단하며, 표준 접근 제어를 우회하는 위협으로부터 인증 및 권한 부여 정책을 보호합니다.
Singularity™ Identity를 사용하면 접근 시도를 모니터링하고 차단할 수 있으며, 위협 행위자가 엔드포인트에서 사용자 자격 증명을 수집하는 것을 방지할 수 있습니다.
Singularity Identity의 조건부 접근 정책은 사용자 또는 디바이스에서 의심스러운 행위가 감지될 때 추가 MFA 프롬프트와 같은 단계적 인증을 자율적으로 트리거할 수 있습니다. 또한 MFA 피로 공격을 방지하고, 로그인 이벤트를 디바이스 상태 및 행동 신호와 연관 분석하여 우회 공격을 허용하지 않습니다.
Singularity Identity는 노출된 서비스 계정, 취약한 비밀번호 구성, Active Directory 오구성 등을 포함하여 인증 인프라 전반의 약점을 공격자가 악용하기 전에 지속적으로 식별합니다. 자세한 내용은 Singularity Identity 제품 페이지에서 확인할 수 있습니다. 또한 SentinelOne을 사용하면 권한 상승을 방지하고, 이미 인증되었지만 관리자 또는 루트 권한을 획득하려는 공격자를 차단할 수 있습니다. 이를 통해 측면 이동 공격을 방지하고 초기에 차단할 수 있습니다.
SentinelOne은 기만 기술과 미끼를 사용하여, 권한이 없는 사용자가 접근해서는 안 되는 데이터에 접근하려 할 때 스스로 드러나도록 유도합니다. Zero Trust 아키텍처에서 Singularity Identity는 의도를 지속적으로 검증하며, 사용자의 행동이 허용된 기능에서 벗어날 경우 머신 속도로 접근을 철회할 수 있습니다. 또한 Access Control List (ACL) 오구성을 식별하고 이를 해결할 수 있습니다.
하이브리드 환경 전반에 걸쳐 실시간 아이덴티티 보호와 엔드투엔드 가시성을 확보하여 노출을 탐지하고, 자격 증명 오용을 차단하며, 아이덴티티 위험을 감소시킵니다.
결론
인증과 권한 부여는 모두 클라우드 및 사이버보안의 일부입니다. 사람과 비인간 사용자를 모두 다루는 한, 둘 다 필요합니다. 이는 환경 내부에서 모든 계정, 서비스, 에이전트가 어떻게 동작하는지를 형성하는 설계 결정입니다. 이를 별도의 계층으로 취급하고 지속적 검증 워크플로와 연결하면, 오용된 신원을 훨씬 더 쉽게 식별하고 억제할 수 있습니다.
ID 공격이 계속 증가하는 가운데, ID, 엔드포인트, 클라우드 워크로드 보호를 아우르는 SentinelOne의 Singularity Platform은 보안 팀이 런타임에서 사람 및 비인간 ID를 모두 보호하는 데 필요한 통합 컨텍스트를 제공합니다. 실제 동작을 확인하려면 라이브 데모 예약을 진행해 보세요.
FAQ
아니요, 인증 없이는 권한 부여가 불가능합니다. 권한 부여는 인증된 ID가 무엇을 할 수 있는지 확인합니다. 먼저 누군지 확인하지 않았다면 권한을 적용할 사용자가 없습니다. 일부 사이트는 로그인 없이 게스트로 탐색할 수 있게 하지만, 그것은 실제 권한 부여가 아니라 단지 개방된 비인증 접근일 뿐입니다. 좋은 원칙은 역할이나 접근 제어를 시행하기 전에 항상 먼저 인증해야 한다는 것입니다.
OAuth 2.0은 권한 부여를 위한 것입니다. 비밀번호를 공유하지 않고도 앱에 사용자의 리소스에 대한 제한된 접근 권한을 제공합니다. OIDC는 OAuth를 기반으로 하며 ID 토큰에 ID 클레임을 추가해 인증을 처리합니다. 따라서 누군지 확인해야 한다면 OIDC를 사용합니다. 위임된 접근만 필요하다면 OAuth만으로 충분합니다. 둘은 함께 작동하지만 서로 다른 역할을 수행합니다.
역할은 “admin” 또는 “viewer”처럼 사용자에게 할당하는 권한의 집합입니다. 속성은 사용자, 디바이스 또는 세션에 대한 사실로, 부서, 보안 등급 또는 위치 같은 항목입니다. 권한 부여는 역할만 확인할 수도 있고, 더 세밀한 결정을 위해 속성을 결합할 수도 있습니다. 예를 들어 역할이 manager이고 속성이 department=sales인 경우에만 접근을 허용할 수 있습니다. 이러한 정책을 설정하는 방법은 다양합니다.
SSO는 한 번 인증한 ID를 여러 앱에 공유하지만, 각 앱은 여전히 자체 권한 부여 검사를 수행합니다. MFA는 사용자가 누구인지 얼마나 강하게 증명하는지를 높입니다. 민감한 데이터에 대한 접근을 권한 부여하기 전에 MFA를 요구하는 정책을 구축할 수 있습니다. MFA에 실패하면 권한 부여는 진행될 기회조차 얻지 못합니다. 따라서 MFA 자체가 권한을 부여하지는 않지만, 로그인 강도에 따라 권한을 제한하는 게이트 역할을 할 수 있습니다.
인증의 경우 로그인 성공, 실패, 잠금, MFA 프롬프트 및 소스 IP를 수집하세요. 권한 부여의 경우 접근 거부, 권한 변경, 역할 할당 및 권한 상승을 확보하세요. 이러한 로그는 ID 공급자, 앱 및 보안 도구에서 가져와야 합니다. 이러한 로그가 있으면 사고가 탈취된 자격 증명으로 시작되었는지, 아니면 부여된 권한의 오용으로 시작되었는지 추적할 수 있습니다. 이는 명확한 타임라인을 구축하는 데 도움이 됩니다.
