DO NOT PUBLISH - OWASP NHI5:2025 불안전한 인가 분석

서론: 인증 다음의 관문, 인가

‍

IT 시스템과 클라우드 환경에서 비인간 신원(NHI)의 역할이 커지면서, 이들의 보안을 확보하는 것이 중요해졌습니다. OWASP NHI Top 10은 이러한 NHI 관련 주요 보안 위협을 식별하고 대응 방안을 제시합니다. 이전 글에서 다룬 NHI4: 불안전한 인증이 NHI가 '누구인지' 확인하는 과정의 취약점이었다면, 이번 글에서는 NHI5:2025 불안전한 인가(Insecure Authorization)에 초점을 맞춥니다.

불안전한 인가는 성공적으로 인증된 NHI가 **'무엇을 할 수 있는지'**를 결정하는 과정에서 발생하는 보안 허점을 의미합니다. 즉, 인증을 통과했더라도, 허용되지 않은 자원에 접근하거나 작업을 수행할 수 있게 되는 문제입니다. 이는 공격자가 시스템 내에서 권한을 남용하거나 상승시켜 심각한 피해를 유발하는 핵심 경로가 됩니다. 적절한 인가 관리는 제로 트러스트 아키텍처의 핵심 요소 중 하나입니다.

왜 NHI5가 중요한가?

NHI는 종종 민감한 데이터와 핵심 시스템 기능에 접근해야 합니다. 만약 인가 과정이 부실하다면, 최소한의 권한만 필요한 NHI가 과도한 접근권을 갖게 되거나, 공격자가 탈취한 NHI를 이용해 허용 범위를 넘어서는 작업을 수행할 수 있습니다. 예를 들어, CI/CD 파이프라인에서 사용되는 서비스 계정이 필요 이상으로 프로덕션 환경 전체에 대한 관리자 권한을 갖는 경우, 해당 계정이 탈취되면 전체 시스템이 위험에 처할 수 있습니다. 이는 데이터 유출, 시스템 변조, 서비스 중단 등 치명적인 결과로 이어질 수 있습니다. 따라서 개발자, 보안 전문가, 클라우드 엔지니어는 NHI의 인가 메커니즘을 안전하게 설계하고 관리하는 방법을 이해하는 것이 필수적입니다.

NHI5 해부하기: 불안전한 인가의 다양한 모습

위협 정의: NHI에게 '불안전한 인가'란?

NHI 환경에서 불안전한 인가는 인증된 NHI가 자신의 권한 범위를 넘어선 자원이나 기능에 접근할 수 있도록 허용하는 모든 종류의 결함을 의미합니다. 이는 단순히 권한 설정을 잘못하는 것뿐만 아니라, 인가 결정을 내리는 로직의 오류, 정책 시행 방식의 불일치, 권한 관리 프로세스(생성, 검토, 회수) 전반의 취약점을 포함합니다.

흔히 빠지는 함정과 나타나는 증상들

NHI 환경에서 불안전한 인가는 다음과 같은 형태로 나타날 수 있습니다.

1. 과도한 권한 부여 (최소 권한 원칙 위반):

• NHI5의 가장 흔하고 핵심적인 문제입니다. NHI에게 실제 필요한 작업 수행 범위를 훨씬 넘어서는 광범위한 권한(예: 전체 읽기/쓰기 권한, 관리자 수준 권한)을 부여하는 경우입니다. 이는 개발 편의성이나 관리의 단순함을 위해 종종 발생합니다.
• 예를 들어, 단순히 특정 데이터베이스 테이블을 읽기만 하면 되는 API가 해당 데이터베이스 전체에 대한 쓰기 권한까지 갖거나, 특정 클라우드 리소스만 관리하면 되는 서비스 계정이 구독 전체의 관리자 역할을 부여받는 경우입니다. 클라우드 환경에서는 미리 정의된 광범위한 역할(Built-in Role)을 그대로 사용하는 경향이 있어 이 문제가 더 심화될 수 있습니다.
• New York Times 해킹 사례에서 GitHub 토큰이 모든 저장소에 접근 가능한 과도한 권한을 가졌던 것은 NHI4(인증 실패 - 토큰 탈취) 문제인 동시에, NHI5(인가 실패 - 과도한 권한) 문제이기도 합니다. 탈취된 토큰이 최소한의 권한만 가졌다면 피해는 훨씬 적었을 것입니다.

2. 부적절한 권한 라이프사이클 관리:

• NHI의 역할이나 필요성이 변경되었음에도 불구하고 기존에 부여된 권한이 적절히 회수되거나 조정되지 않는 경우입니다. 이는 '권한 부풀리기(Permission Creep)' 현상으로 이어질 수 있습니다.
• 예를 들어, 특정 프로젝트가 종료된 후에도 해당 프로젝트에 사용된 NHI의 접근 권한이 그대로 남아있거나, 임시 작업을 위해 부여된 높은 권한이 작업 완료 후에도 회수되지 않는 경우입니다. 이는 NHI1(부적절한 인벤토리 및 관리) 및 NHI7(비활성 및 고아 NHI)과도 연결됩니다. 권한 회수 프로세스가 자동화되지 않고 수동으로 관리될 때 자주 발생합니다.

3. 인가 검사 누락 또는 우회:

• 특정 API 엔드포인트나 시스템 기능에서 NHI의 권한을 제대로 확인하지 않거나, 공격자가 인가 검사 로직을 우회할 수 있는 경로가 존재하는 경우입니다.
• 예를 들어, 특정 작업 요청 시 파라미터 값을 조작하여 권한 검사를 건너뛰거나(Parameter Tampering), 내부 통신이라는 이유로 API 간 호출 시 인가 검사를 생략하거나, 오류 처리 로직의 허점을 이용해 인가 단계를 건너뛰는 경우 발생할 수 있습니다.

4. 수평적 및 수직적 권한 상승 취약점:

• 수평적 권한 상승: 동일한 수준의 권한을 가진 다른 NHI의 자원에 접근할 수 있는 취약점입니다. 예를 들어, API A가 사용자 A의 데이터만 접근해야 하는데, 인가 로직의 허점으로 인해 동일한 권한 수준의 사용자 B의 데이터까지 접근할 수 있는 경우입니다. 멀티테넌트 환경에서 특히 주의해야 합니다.
• 수직적 권한 상승: 낮은 권한을 가진 NHI가 인가 시스템의 결함을 이용하여 더 높은 권한(예: 관리자 권한)을 획득하는 취약점입니다. 시스템 설정 변경 API 등 민감한 기능에 대한 인가 검사가 부실할 때 발생할 수 있습니다.

5. 클라우드 환경에서의 IAM 정책 및 역할 오설정:

• AWS IAM, Azure RBAC, GCP IAM 등 클라우드 환경에서 제공하는 복잡한 권한 관리 시스템을 잘못 설정하는 경우입니다. 이는 클라우드 보안에서 가장 흔한 실수 중 하나입니다.
• 예를 들어, 와일드카드(*)를 과도하게 사용한 정책 (Resource: *, Action: *), 너무 광범위한 리소스 그룹에 적용된 역할, 잘못된 조건(condition) 키 또는 값 사용, 상속 관계 오해, 외부 ID(External ID) 검증 누락 등으로 인해 의도치 않게 과도한 권한이 부여될 수 있습니다. AWS의 서비스 제어 정책(SCP), Azure의 관리 그룹 정책, GCP의 조직 정책과 같은 상위 레벨의 통제 수단을 적절히 활용하지 않는 것도 문제가 될 수 있습니다.

파급 효과: NHI5 취약점이 불러오는 실제 결과

불안전한 인가는 시스템에 다음과 같은 심각한 결과를 초래할 수 있습니다.

• 데이터의 기밀성, 무결성, 가용성 침해: 권한 없는 NHI가 민감 데이터를 읽거나(기밀성), 금융 거래 기록을 조작하거나(무결성), 중요한 시스템 로그를 삭제(가용성)할 수 있습니다.
• 시스템 기능 오용 및 서비스 중단: 공격자가 탈취한 NHI의 권한을 남용하여 시스템 설정을 변경(예: 보안 설정 비활성화)하거나, 리소스를 과도하게 사용하여 비용 폭탄을 유발하거나, 핵심 서비스를 중단시킬 수 있습니다.
• 공격자의 내부망 이동(Lateral Movement) 촉진: 과도한 권한을 가진 NHI(예: 네트워크 전체 스캔 권한)를 발판 삼아 공격자가 시스템 내 다른 취약한 서버나 데이터 저장소로 쉽게 이동하고 접근 범위를 넓힐 수 있습니다.
• 권한 상승(Privilege Escalation) 경로 제공: 낮은 권한으로 침투한 공격자가 인가 취약점(예: 특정 시스템 명령어 실행 가능 권한 오용)을 이용해 루트 또는 관리자 권한을 획득하여 시스템 전체를 장악할 수 있습니다.
• 규정 준수 위반 및 법적 책임: GDPR, CCPA, HIPAA, SOX 등 데이터 보호 및 재무 관련 규정에서 요구하는 엄격한 접근 통제 원칙(특히 최소 권한)을 위반하여 막대한 벌금이나 법적 소송에 직면할 수 있습니다.

실제 침해 사례에서 배우기 (또는 예시 시나리오)

NHI5(불안전한 인가)는 종종 다른 취약점(예: NHI4 - 불안전한 인증)과 결합되어 실제 침해로 이어집니다. 명확하게 NHI5만이 원인이라고 밝혀진 대규모 침해 사례를 특정하기는 어려울 수 있으나, 다음과 같은 시나리오를 통해 위험성을 이해할 수 있습니다.

• 시나리오 1: 클라우드 스토리지 권한 오설정 (상세)

• 상황: 이미지 처리 마이크로서비스 A에게 S3 버킷 'user-uploads'에 대한 접근 권한을 부여합니다. 개발 초기 단계에서 편의상 s3:* 권한을 가진 IAM 정책을 연결했습니다.
• NHI5 실패: 최소 권한 원칙 위반. 실제로는 s3:GetObject, s3:PutObject, s3:DeleteObject 액션만 arn:aws:s3:::user-uploads/* 리소스에 대해 필요했습니다. 버킷 자체 관리 권한 (s3:DeleteBucket, s3:PutBucketPolicy 등)은 불필요했습니다.
• 결과: 만약 마이크로서비스 A가 Log4Shell 같은 라이브러리 취약점으로 침해당하면, 공격자는 획득한 서비스 계정 자격 증명을 이용해 단순히 객체를 읽고 쓰는 것을 넘어, 버킷 정책을 변경하여 데이터를 외부에 공개하거나, 버킷 자체를 삭제하여 서비스 가용성을 침해하는 등 훨씬 파괴적인 작업을 수행할 수 있습니다.

• 시나리오 2: API 인가 로직 오류 (상세)

• 상황: 여러 고객사(테넌트)의 데이터를 관리하는 SaaS 애플리케이션이 있습니다. 고객사 A의 관리자용 API /api/tenantA/settings를 호출하는 서비스 계정 NHI-A가 있습니다.
• NHI5 실패: API 백엔드 로직에서 경로의 tenantA 부분만 보고 인증된 NHI-A가 실제로 tenantA에 대한 관리 권한이 있는지 확인하는 인가 검사를 누락했습니다. 또는, 경로 변수 대신 요청 본문에 있는 tenantId 파라미터를 신뢰했는데, 이 파라미터가 조작 가능한 경우입니다 (Broken Object Level Authorization - BOLA, OWASP API Security Top 10의 #1).
• 결과: NHI-A를 탈취한 공격자가 API 경로를 /api/tenantB/settings로 변경하거나 요청 본문의 tenantId를 tenantB로 조작하여 다른 고객사인 tenantB의 설정을 무단으로 변경할 수 있습니다 (수평적 권한 상승).

• 시나리오 3: 임시 권한 회수 실패 (상세)

• 상황: 대규모 데이터베이스 마이그레이션 작업을 위해 임시 CI/CD 파이프라인 NHI에게 24시간 동안만 유효한 프로덕션 데이터베이스 쓰기 권한을 부여했습니다 (예: Azure PIM 역할 할당).
• NHI5 실패: 마이그레이션이 예상보다 일찍 완료되었지만, 할당된 역할이 만료 시간까지 자동으로 회수되도록 설정하지 않았거나, 수동 회수 프로세스를 잊었습니다. 또는, JIT(Just-In-Time) 방식이 아닌 일반적인 역할 할당 방식을 사용했습니다.
• 결과: 해당 NHI의 자격 증명이 남은 유효 시간 내에 유출될 경우 (예: CI/CD 로그 유출), 공격자는 불필요하게 연장된 시간 동안 프로덕션 데이터베이스에 접근하여 데이터를 조작하거나 탈취할 수 있습니다.

방어 강화: 제로 트러스트 기반의 NHI 인가 보안 접근법

NHI5 위협에 대응하기 위해서는 인증과 마찬가지로 제로 트러스트 원칙에 기반한 다층적인 인가 보안 전략이 필요합니다. "절대 신뢰하지 않고, 항상 검증하며, 최소한의 권한만 부여한다"는 접근 방식이 핵심입니다.

원칙 1: 최소 권한 원칙(PoLP)의 철저한 적용

1. 필요한 최소한의 권한만 부여: NHI에게 작업을 수행하는 데 필요한 딱 그만큼의 권한만 부여합니다. '만약을 대비해서' 또는 '관리의 편의성' 때문에 과도한 권한을 부여하는 것을 절대 피해야 합니다. 권한 부여 시 '거부 우선(Deny by Default)' 정책을 기본으로 합니다.
2. 역할 기반 접근 통제(RBAC) 및 속성 기반 접근 통제(ABAC) 활용: NHI의 역할(예: '데이터 처리 서비스', '모니터링 에이전트')이나 속성(예: 환경='production', 데이터 민감도='high')에 따라 권한을 정의하고 부여하여 보다 세분화되고 동적인 접근 제어를 구현합니다. ABAC는 RBAC보다 더 유연하고 상황에 맞는 제어가 가능합니다.
3. 클라우드 IAM 정책 정교화: 클라우드 환경에서는 IAM 정책을 최대한 구체적으로 작성합니다. 특정 리소스 ARN(Amazon Resource Name)이나 Azure 리소스 ID, GCP 리소스 이름을 명시하고, 필요한 작업(Action)만 명시적으로 허용하며(Allow), 가능하다면 조건(Condition) 키(예: aws:SourceIp, azure:ResourceGroup, gcp:RequestTime)를 사용하여 접근 가능한 IP 범위, 특정 태그가 있는 리소스, 시간대 등을 엄격하게 제한합니다. 와일드카드(*) 사용은 최소화하고 불가피할 경우 범위를 최대한 좁힙니다.

원칙 2: 지속적인 권한 검토 및 관리

1. 정기적인 권한 검토 및 감사: NHI에 부여된 권한이 여전히 최소한의 필요한 수준인지, 역할 변경이나 환경 변화에 따라 적절히 조정되었는지 주기적으로(예: 분기별) 검토하고 감사하는 프로세스를 갖춥니다. 클라우드 제공 업체의 Access Analyzer(AWS), Access Review(Azure) 같은 도구나 서드파티 CIEM(Cloud Infrastructure Entitlement Management) 솔루션을 활용하여 사용되지 않는 권한, 과도한 권한 등을 식별하는 것이 효과적입니다.
2. 자동화된 권한 라이프사이클 관리: NHI 생성 시 역할에 따라 필요한 최소 권한을 IaC(Infrastructure as Code) 도구(예: Terraform, CloudFormation)를 통해 자동으로 부여하고, 역할 변경이나 서비스 종료 시 관련 권한을 자동으로 회수하거나 조정하는 시스템을 구축합니다. Just-In-Time(JIT) 접근 방식을 적극 고려하여, NHI가 특정 작업을 수행해야 할 때만 필요한 권한을 임시로(예: 몇 시간 동안) 부여하고 작업 완료 또는 시간 만료 시 자동으로 회수하는 모델(예: Azure PIM for Service Principals, HashiCorp Vault)을 구현하면 상시적인 과도한 권한 노출 위험을 크게 줄일 수 있습니다.

원칙 3: 강력하고 일관된 인가 메커니즘 구현

1. 모든 접근 지점에서 인가 검사 시행: 모든 API 엔드포인트, 데이터 저장소 접근, 시스템 기능 호출 시 예외 없이 명시적인 인가 검사를 수행합니다. 마이크로서비스 아키텍처에서 내부 서비스 간 통신(East-West traffic)이라도 상호 인증(mTLS 등) 및 인가 검사를 수행하는 것이 제로 트러스트 원칙에 부합합니다.
2. 중앙 집중식 인가 정책 관리 고려: 가능하면 인가 정책(Policy Decision Point, PDP)을 애플리케이션 로직과 분리하여 중앙에서 관리하고, 각 서비스(Policy Enforcement Point, PEP)는 중앙 정책 저장소를 참조하여 일관된 인가 결정을 내리도록 합니다. Open Policy Agent (OPA) 와 같은 표준화된 정책 엔진을 활용하면 다양한 환경에서 일관된 정책 기반 인가 제어를 구현하는 데 도움이 될 수 있습니다.
3. 인가 로직의 안전한 설계 및 테스트: 권한 상승, 인가 우회(예: IDOR - Insecure Direct Object References), BOLA 등의 취약점이 발생하지 않도록 인가 로직을 신중하게 설계하고, 코드 리뷰 및 충분한 보안 테스트(SAST, DAST, 퍼징, 침투 테스트)를 통해 검증합니다. OWASP의 ASVS(Application Security Verification Standard)나 API Security Top 10 등을 참고하여 안전한 인가 패턴을 적용합니다.

원칙 4: 지속적인 모니터링 및 이상 행위 탐지

1. 인가 실패 및 권한 남용 시도 모니터링: NHI의 자원 접근 시도 중 발생하는 인가 실패(Access Denied) 로그를 철저히 모니터링하고 분석합니다. 비정상적인 패턴(예: 특정 NHI의 반복적인 접근 실패, 평소 사용하지 않던 민감한 API 호출 시도, 권한 없는 작업 시도)이 탐지될 경우 즉시 경고하고 조사할 수 있는 SIEM 또는 위협 탐지 시스템을 갖춥니다.
2. 권한 변경 사항 추적 및 감사: NHI에게 부여된 역할이나 정책이 변경될 때마다 이를 추적하고 기록하여(예: CloudTrail, Azure Activity Log), 예상치 못한 권한 변경이나 승인되지 않은 과도한 권한 부여를 신속하게 탐지하고 대응합니다.

미래 내다보기: 진화하는 위협과 규제 환경

클라우드 네이티브 환경과 자동화, IaC(Infrastructure as Code)가 확산되면서 NHI의 역할과 수는 계속 증가할 것이며, 이에 따라 이들의 권한을 관리하는 복잡성과 중요성도 커질 것입니다. 공격자들은 더욱 정교한 방식으로 인가 취약점을 찾아 악용하려 할 것입니다. 또한, GDPR, SOX, PCI-DSS 등 다양한 규제 및 컴플라이언스 요구사항은 데이터 및 시스템 접근에 대한 엄격한 통제(특히 최소 권한 및 접근 검토)를 요구하며, 이는 NHI의 인가 관리 중요성을 더욱 부각시킵니다. 기업들은 이러한 변화에 발맞춰 지속적으로 NHI 인가 전략을 검토하고, 자동화된 도구와 프로세스를 도입하여 개선해야 합니다.

결론

NHI5: 불안전한 인가는 인증된 NHI가 허용된 범위를 넘어 시스템과 데이터에 접근하거나 조작할 수 있게 만드는 심각한 보안 위협입니다. 이는 최소 권한 원칙 위반, 부적절한 권한 라이프사이클 관리, 인가 로직 오류, 클라우드 IAM 설정 오류 등 다양한 형태로 나타날 수 있으며, 데이터 유출, 시스템 장악, 규정 준수 실패 등 치명적인 결과를 초래할 수 있습니다.

효과적인 방어를 위해서는 제로 트러스트 원칙에 기반하여 다음과 같은 전략을 실행해야 합니다.

• 최소 권한 원칙(PoLP) 철저히 준수 및 정교한 정책 관리
• 지속적인 권한 검토 및 자동화된 라이프사이클 관리 (JIT 접근 고려)
• 모든 접근 지점에서 강력하고 일관된 인가 검사 시행 (중앙 정책 관리 고려)
• 지속적인 모니터링을 통한 이상 행위 및 권한 남용 탐지 및 감사

NHI의 활동 범위와 영향력이 커짐에 따라, 이들의 권한을 정확하고 안전하게 관리하는 것은 현대 IT 환경 보안의 핵심 과제입니다. 불안전한 인가 위협에 대한 깊은 이해와 체계적인 대응을 통해 조직의 자산을 보호하고 신뢰를 유지해야 합니다. NHI 보안 및 관리에 대한 추가적인 정보는 Cremit 블로그에서도 찾아보실 수 있습니다.