OWASP NHI4:2025 불안전한 인증

‍인간을 넘어선 비인간 신원의 시대

오늘날 IT 인프라, 자동화, 클라우드 환경은 더 이상 인간만이 운영하는 것이 아닙니다. 서비스 계정, API, 마이크로서비스, IoT 기기, 봇과 같은 비인간 신원(Non-Human Identities, NHIs)이 현대 기술 생태계의 핵심적인 역할을 수행하고 있습니다. 이들은 인간의 직접적인 개입 없이 시스템과 데이터에 접근하고 작업을 자동화합니다.

NHI의 수는 기하급수적으로 증가하고 있습니다. 최근 연구에 따르면 NHI는 이미 인간의 수를 훨씬 넘어섰으며, 한 보고서는 인간 한 명당 평균 46개의 NHI가 존재한다고 추정합니다. 2025년에는 그 수가 450억 개를 넘을 것으로 예측되며, 특히 DevOps 환경에서는 인간보다 NHI가 최소 45배 많다고 합니다.

이러한 NHI의 폭발적인 증가는 공격 표면을 근본적으로 변화시켰습니다. 더 이상 인간 계정 보안에만 집중하는 방식으로는 충분하지 않습니다. NHI의 방대한 규모는 보안 관리 방식의 변화를 요구합니다. 수동 관리는 불가능하며, 대부분의 NHI가 보안 사각지대에 놓여 심각한 위험을 초래할 수 있습니다. 따라서 NHI를 자동으로 탐지, 관리, 보호하는 전문 도구가 필수적입니다. 저희 Cremit 역시 이러한 NHI 보안 문제, 특히 비밀번호 유출(Secret Sprawl)과 숨겨진 NHI 탐지의 어려움에 주목하고 있습니다.

OWASP NHI Top 10

이러한 배경 속에서 OWASP(Open Web Application Security Project)는 NHI 관련 주요 보안 위협을 식별하고 개발자와 보안 전문가에게 실질적인 지침을 제공하기 위해 OWASP NHI Top 10 리스트를 발표했습니다. 이 목록은 NHI 보안에 대한 인식을 높이고 효과적인 대응 전략을 수립하는 데 중요한 기준점을 제공합니다. 저희 Cremit 블로그에서도 이전에 NHI1(부적절한 오프보딩), NHI2(비밀 유출), NHI3(서드파티 공급망 위험) 등 다른 NHI 위협들을 다룬 바 있습니다.

NHI4:2025 불안전한 인증 집중 탐구 – 공격자의 첫 번째 문

이번 글에서는 OWASP NHI Top 10의 네 번째 항목인 **NHI4:2025 불안전한 인증(Insecure Authentication)**을 심층적으로 분석합니다. 불안전한 인증은 NHI가 자신의 신원을 증명하고 보호된 자원에 접근하는 과정에서 발생할 수 있는 모든 보안 취약점을 포괄합니다. 이는 공격자가 시스템에 침투하여 데이터를 탈취하는 첫 번째 관문으로 자주 악용되므로 매우 중요한 위협 요소입니다.

왜 이게 중요할까요?

개발자, 보안 전문가, DevOps 엔지니어 등 여러분에게 NHI4를 이해하고 대비하는 것은 안전한 애플리케이션, API, 인프라를 구축하고 보호하는 데 필수적입니다. 특히 클라우드 및 자동화 환경에서는 그 중요성이 더욱 커집니다. 저희 Cremit은 이러한 과제에 대한 통찰력과 해결책을 제공하고자 노력하고 있습니다. 이 글을 통해 NHI4의 복잡성을 파악하고 효과적인 방어 전략을 수립하는 데 도움을 드리고자 합니다.

NHI4 분석하기: 불안전한 인증의 여러 얼굴

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

NHI 환경에서 불안전한 인증은 단순히 잘못된 비밀번호 사용 이상의 의미를 갖습니다. NHI의 신원을 확인하고 접근 권한을 부여하는 전체 프로세스에 내재된 취약점을 모두 포함합니다. 여기에는 자격 증명 관리의 허점, 안전하지 않은 통신 프로토콜 사용, 잘못된 권한 부여 로직 등이 포함됩니다.

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

NHI 환경에서 불안전한 인증은 다음과 같은 다양한 형태로 나타납니다.

1. 약하거나, 기본값이거나, 코드에 박힌 자격 증명:

• 많은 NHI가 'admin'/'password'와 같이 추측하기 쉬운 비밀번호를 사용하거나, 기본 제공 API 키/토큰을 변경하지 않고 그대로 사용하는 경우가 많습니다.
• 코드에 박힌 자격 증명(하드코딩)은 특히 심각한 문제입니다. API 키, 비밀 토큰, 암호화 키 등의 민감 정보를 소스 코드, 설정 파일, 환경 변수 파일(.env) 등에 직접 포함시키는 것은 매우 위험합니다. 코드 저장소 해킹 (New York Times, Emerald Whale 사례), CI/CD 파이프라인 노출, Docker Hub 등 공개 저장소에 실수로 업로드 (10만 개 이상의 유효한 비밀 정보 발견 사례)될 경우, 하드코딩된 정보는 즉각적인 보안 사고로 이어질 수 있습니다. Slack, Jira, Confluence와 같은 협업 도구 역시 비밀 정보 유출 경로가 될 수 있습니다.
• 하드코딩은 개발 편의성을 높이지만, 코드 노출 시 공격자에게 시스템 접근 권한을 제공하는 것과 같습니다. GitGuardian 분석에 따르면 매년 수백만 개의 비밀 정보가 GitHub에서 유출됩니다. 흥미롭게도 GitHub Copilot과 같은 AI 코딩 도우미는 생산성을 높이는 동시에 비밀 정보 유출 가능성을 40% 증가시킬 수 있다는 연구 결과도 있습니다. 따라서 개발 프로세스 초기에 비밀 정보를 자동으로 탐지하는 도구(SAST/탐지 도구)의 중요성이 커지고 있습니다. 저희 Cremit도 이러한 비밀 정보 탐지와 숨겨진 비밀 식별의 중요성을 강조하며 관련 솔루션을 제공합니다.

2. 비밀번호 유출(Secret Sprawl)과 관리 부실의 위험:

• 비밀번호 유출(Secret Sprawl)은 API 키, 토큰, 인증서, 비밀번호 등의 비밀 정보가 코드, 설정 파일, 여러 저장소(Vault), 클라우드 스토리지(예: S3) 등 다양한 위치에 통제 없이 분산되는 현상을 의미합니다.
• 이렇게 흩어진 비밀 정보는 중앙에서 관리되지 않으면 추적, 주기적 교체, 폐기가 거의 불가능해집니다. 많은 기업이 비밀 정보를 여러 곳에 분산 저장하여 보안팀의 통합적인 관리 및 파악을 어렵게 만듭니다. 비밀 정보의 분산은 공격 표면의 증가를 의미하며, 유출된 각 비밀 정보는 시스템 침투의 발판이 될 수 있습니다. 저희 Cremit의 AWS S3 NHI 탐지 기능은 이러한 유출 문제를 해결하기 위한 노력의 일환입니다.

3. 라이프사이클 관리 소홀: 버려진 키와 너무 오래 쓰는 비밀 정보:

• NHI 자격 증명의 생성, 저장, 사용, 교체, 폐기(오프보딩) 전 과정에 대한 적절한 관리가 이루어지지 않으면 심각한 보안 문제가 발생할 수 있습니다.
• 특히 오래 쓰는 비밀 정보(Long-Lived Secrets), 즉 유효 기간이 없거나 매우 길어 주기적으로 교체되지 않는 고정 API 키나 비밀번호는 매우 위험합니다. 한 연구에 따르면 NHI의 70% 이상이 권장 기간 내에 교체되지 않으며, 평균 교체 주기는 627일에 달합니다. 더욱 놀라운 사실은 2022년 공개 저장소에서 처음 발견된 비밀 정보의 70%가 몇 년 후에도 여전히 유효했다는 점입니다.
• 유출된 자격 증명이 계속 유효하다는 것은 비밀 정보의 주기적인 교체 및 폐기 시스템이 제대로 작동하지 않음을 의미합니다. 이는 유출 방지뿐만 아니라 유출 후 피해를 신속하게 완화하는 것의 중요성을 강조합니다. 공격자는 오래전에 유출된 키를 발견하더라도 여전히 시스템 접근에 사용할 가능성이 높습니다. 따라서 자동화된 강제 비밀 정보 교체와 확실한 오프보딩(NHI1 관련)은 단순한 권장 사항이 아닌 필수적인 보안 조치입니다.
• 이 문제는 NHI1: 부적절한 오프보딩(Improper Offboarding) 문제와 직접적으로 연결됩니다. 더 이상 사용되지 않는 서비스나 퇴사한 직원의 접근 권한을 즉시 제거하지 않으면, 유효한 자격 증명이 공격자에게 악용될 수 있습니다.

4. 안전하지 않은 통신 채널과 약한 프로토콜:

• NHI(API, 서비스 등) 간 데이터 통신 시 암호화되지 않은 채널을 사용하면 중간자 공격(Man-in-the-Middle, MitM)에 취약해집니다. 공격자는 통신 내용을 도청하거나 NHI 자체를 탈취할 수 있습니다.
• 단순 고정 API 키에만 의존하고 상호 인증(Mutual TLS, mTLS)과 같은 더 강력한 메커니즘을 사용하지 않는 것이 대표적인 약점입니다. 단순 API 키 인증은 널리 사용되지만, 상호 검증 기능이 부족하고 가로채기에 취약하여 본질적으로 mTLS나 동적 자격 증명 방식보다 약합니다. API 키는 사용자 로그인과 달리 2단계 인증(2FA)으로 보호되지 않는 경우가 많아 유출 시 더 큰 위험을 초래할 수 있습니다. SPIFFE/SPIRE와 같은 기술은 이러한 고정 키의 한계를 극복하고, 네트워크 기반 신뢰 대신 신원 기반 상호 인증을 가능하게 하는 짧은 유효 기간의 SVID를 사용하여 mTLS를 구현합니다. 이는 기본적인 API 키 인증에서 벗어나 민감한 NHI 통신에는 더 강력하고 신원 기반의 상호 인증 방식으로 전환해야 함을 시사합니다.

5. 과도한 권한의 위험 (최소 권한 원칙 위반):

• NHI는 종종 실제 필요한 것보다 훨씬 많은 권한을 부여받습니다. 유출된 GitHub 토큰의 96%가 쓰기 권한을, 95%가 전체 저장소 접근 권한을 가졌으며, GitLab API 키의 99%가 전체 또는 읽기 전용 접근 권한을 가졌다는 연구 결과는 충격적입니다.
• 이렇게 과도한 권한은 공격자가 NHI 하나를 탈취한 후, 그 권한을 이용해 시스템 내부를 자유롭게 이동하거나(Lateral Movement) 더 높은 권한을 탈취(Privilege Escalation)하는 것을 용이하게 만듭니다. New York Times 해킹 사건에서는 과도한 권한을 가진 GitHub 토큰 하나로 인해 모든 저장소에 접근할 수 있게 되었습니다. Dropbox Sign 침해 사고에서도 높은 권한을 가진 서비스 계정이 탈취되어 고객 데이터베이스 접근으로 이어졌습니다.
• 과도한 권한은 침해 사고의 피해 규모를 확대하는 역할을 합니다. 너무 넓은 접근 권한을 가진 NHI 하나가 탈취되면 다른 방어 체계를 무력화시키고 치명적인 데이터 손실이나 시스템 장악으로 이어질 수 있습니다. 따라서 NHI에게 최소한의 필요한 권한만 부여하는 원칙(Principle of Least Privilege)을 적용하는 것은 자격 증명 자체를 보호하는 것만큼이나 중요합니다. 이는 단순히 더 나은 인증뿐만 아니라, 더 나은 권한 부여 관리가 필요함을 의미합니다.

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

이론적인 위험을 넘어, NHI의 불안전한 인증은 실제로 다음과 같이 심각하고 현실적인 결과를 초래할 수 있습니다.

• 무단 접근 및 데이터 유출: 민감한 고객 정보, 개인 식별 정보(PII), 금융 정보, 기업의 핵심 기술 등이 공격자에게 유출될 수 있습니다.
• 시스템 침해 및 장악: 공격자는 탈취한 NHI를 발판 삼아 시스템 내부를 이동하거나(Lateral Movement) 권한을 상승시켜(Privilege Escalation) 전체 환경을 장악할 수 있습니다 (CI/CD 파이프라인 공격 사례).
• 서비스 중단 및 다운타임: 핵심 서비스 운영에 차질이 생겨 비즈니스 연속성에 심각한 타격을 줄 수 있습니다 (인증서 관련 중단 보고).
• 랜섬웨어 배포: 탈취된 NHI는 랜섬웨어 공격의 초기 침투 경로로 악용될 수 있습니다 (랜섬웨어 및 이중 갈취 증가 보고).
• 금전적 손실: 사고 대응 및 복구 비용, 법규 위반 벌금, 매출 감소 등 직접적인 금전적 피해가 발생합니다 (데이터 유출 비용 증가 언급).
• 평판 손상 및 신뢰 상실: 고객의 신뢰를 잃고 브랜드 이미지가 훼손되어 장기적인 사업에 부정적인 영향을 미칩니다.
• 공급망 공격: 한 시스템에서 탈취된 NHI가 연쇄 반응을 일으켜 협력사나 고객에게까지 피해를 주는 공격으로 이어질 수 있습니다 (NHI3 언급)(BeyondTrust/미 재무부 등 공급망 사례).

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍

실제 침해 사례에서 배우기: NHI 인증 실패 이야기

실제 침해 사례를 살펴보는 것은 이론적인 위험이 얼마나 현실적인지 깨닫고 대응의 시급성을 느끼는 데 중요합니다. 아래 표는 최근 NHI의 불안전한 인증을 악용한 주요 침해 사례들을 요약한 것입니다.

상세 분석 (예시 - Dropbox Sign 침해 사고)

Dropbox Sign 침해 사고는 NHI4 실패가 어떻게 연쇄적인 위험으로 번지는지 잘 보여줍니다. 공격은 자동화된 설정 도구가 사용하는 백엔드 서비스 계정(NHI)을 탈취하면서 시작되었습니다. 여기서 핵심적인 NHI4 실패는 서비스 계정 자체의 보안이 약했거나(예: 보호 조치 미흡) 너무 많은 권한을 가지고 있었다는 점입니다.

이 첫 번째 침해의 결과는 광범위했습니다. 공격자는 사용자의 이메일, 사용자 이름, 전화번호, 암호화된 비밀번호뿐만 아니라 API 키와 OAuth 토큰 같은 중요한 인증 정보까지 손에 넣을 수 있었습니다. 심지어 계정을 만들지 않은 서명 참여자의 정보까지 노출되었습니다.

여기서 주목할 점은, 권한 있는 NHI 하나가 탈취되면서 다른 인증 정보(API 키, OAuth 토큰)까지 대량으로 노출되었다는 사실입니다. 이는 초기의 NHI4 실패(안전하지 않은 서비스 계정 인증/권한)가 다른 NHI 인증에 필요한 자격 증명 탈취로 바로 이어져 공격 표면을 기하급수적으로 넓히고, 모든 키와 토큰을 교체하는 등 대대적인 복구 작업을 필요하게 만들 수 있음을 보여줍니다. Dropbox는 이 사고 후 비밀번호 재설정, 모든 사용자 세션 강제 로그아웃, 그리고 모든 API 키와 OAuth 토큰을 전면 교체해야 했습니다. 이 사건은 NHI 보안의 여러 측면이 얼마나 긴밀하게 연결되어 있는지를 명확히 보여주는 사례입니다.

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

NHI 환경에서 불안전한 인증 위협에 효과적으로 맞서려면 제로 트러스트(Zero Trust) 보안 모델을 NHI에도 엄격하게 적용하는 것이 핵심입니다. "절대 믿지 말고, 항상 검증하라(Never Trust, Always Verify)"는 원칙에 따라 모든 NHI의 접근 요청을 다뤄야 합니다. 네트워크 위치에 상관없이 모든 상호 작용에 대해 명확한 인증과 권한 부여가 필요하며, 이는 지속적인 인증 및 권한 부여(Continuous Authentication and Authorization)를 통해 이루어져야 합니다.

원칙 1: 강력한 인증 방법 구현하기

1. 짧은 유효 기간의 동적 자격 증명 사용하기:

• 고정적이고 오랫동안 유효한 비밀 정보는 위험하므로, 짧은 유효 기간을 갖고 동적으로 생성되는 자격 증명으로 전환하는 것이 중요합니다.
• OAuth 2.0: 다른 서비스에 권한을 위임하고 짧은 유효 기간의 액세스 토큰을 얻는 데 널리 사용됩니다 (OAuth 남용 사례는 오히려 그 중요성을 보여줍니다).
• SPIFFE/SPIRE: 워크로드 신원을 위한 강력하고 현대적인 표준입니다. 이 기술은 워크로드에게 자동으로 갱신되고 암호학적으로 검증 가능한 짧은 유효 기간의 신원 증명서(SPIFFE Verifiable Identity Documents, SVIDs - 보통 X.509 인증서나 JWT 형식)를 발급합니다. SPIFFE/SPIRE는 초기 신뢰 설정 문제("맨 처음 자격 증명은 어디서 오는가?")를 해결하는 안전한 도입(secure introduction) 메커니즘을 제공하며, 고정된 비밀 정보 없이도 mTLS를 구현할 수 있게 해줍니다. CNCF(Cloud Native Computing Foundation)의 졸업 프로젝트라는 점도 신뢰도를 더합니다.
• SPIFFE/SPIRE와 같은 기술은 NHI 인증 방식의 근본적인 변화를 의미합니다. 고정된 비밀 정보 관리에서 검증 가능한 신원 관리로 초점을 옮기며, 이는 변화무쌍한 클라우드 네이티브 환경에 훨씬 더 적합하고 안전한 접근 방식입니다. 기존 방식은 고정 비밀 정보 관리의 어려움(유출, 교체 실패 등)을 겪습니다. SPIFFE/SPIRE는 미리 공유된 비밀 정보 대신 워크로드 자체를 증명(attestation)하여 짧은 유효 기간의, 자동으로 갱신되는 SVID를 발급함으로써 이 문제를 직접적으로 해결합니다. 이는 워크로드 간 인증을 위해 고정된 자격 증명이 필요 없게 만들고 초기 부트스트랩 문제를 해결하여, 제로 트러스트 원칙과 완벽하게 부합하며 핵심적인 NHI4 약점을 해결합니다.

2. 컨텍스트 기반 검증 실행하기:

• NHI 접근 요청 시 단순히 자격 증명만 확인하는 것이 아니라, 시간, 위치, 행동 패턴, 요청 환경 등 다양한 상황 정보를 종합적으로 판단하여 접근 허용 여부를 결정해야 합니다. 이는 추가적인 보안 계층을 제공합니다.

3. 안전한 서비스 간 통신을 위한 상호 TLS (mTLS):

• 서비스와 API 간 통신을 암호화하고 양쪽 모두 서로를 인증하는 mTLS의 중요성을 다시 한번 강조합니다. 단순 API 키 인증보다 훨씬 강력한 보안을 제공합니다.

4. 가능하다면 NHI에도 MFA 적용하기:

• 자동화된 시스템에 다중 인증(MFA)을 적용하는 것은 어려울 수 있지만, 위험도가 높은 작업을 수행하거나 특정 조건에서는 추가 인증 요소(예: 승인 단계)를 요구하는 시나리오를 고려할 수 있습니다. MFA 자체가 만능 해결책은 아니지만(한 연구에서는 MFA 관련 사고가 50%에 달한다고 보고), 여전히 중요한 보안 계층입니다. AWS나 Azure와 같은 클라우드 서비스는 권한 있는 사람 사용자에게 MFA 사용을 강력히 권장하는데, 이는 간접적으로 그들이 관리하는 NHI를 보호하는 데 도움이 됩니다.

원칙 2: 안전한 비밀 정보 관리 마스터하기

1. 유출되기 전에 비밀 정보 찾아내기 (Shift-Left):

• 소프트웨어 개발 생명주기(SDLC)의 초기 단계에서 비밀 정보를 탐지하는 것이 중요합니다.
• SAST/DAST: 정적 애플리케이션 보안 테스팅(SAST)은 코드 실행 없이 분석하며, 동적 애플리케이션 보안 테스팅(DAST)은 실행 중인 애플리케이션을 테스트합니다. SAST는 특히 코드에 박힌 비밀 정보나 안전하지 않은 코딩 관행을 찾는 데 효과적입니다. 반면 DAST는 실행 중 발생하는 문제를 찾지만, 코드 내 숨겨진 비밀 정보를 직접 찾아내지는 못합니다.
• SAST는 코드에 박힌 비밀 정보(NHI4의 주요 공격 경로 중 하나)를 찾는 데 매우 중요합니다. 하지만 SAST나 DAST만으로는 부족할 수 있습니다. 이들은 상호 보완적이며, 비밀 정보 스캔 전문 도구는 종종 더 집중적인 탐지 기능을 제공합니다. 또한, 도구 사용만으로는 부족하며 프로세스가 중요합니다. 한 연구에서는 비밀 정보 관리 솔루션을 사용하는 저장소에서도 여전히 유출이 발생한다고 지적했습니다. SAST는 때때로 너무 많은 결과를 생성하여 우선순위 결정에 어려움을 줄 수도 있습니다. 이는 SAST/DAST가 필요하지만 충분하지 않다는 것을 의미합니다. 저희 Cremit의 솔루션과 같은 전문 비밀 정보 탐지 도구를 CI/CD 파이프라인에 통합하면 일반적인 SAST/DAST를 보완하여 더 집중적이고 신속하게 문제를 식별할 수 있습니다.
• 저희 Cremit의 비밀 정보 탐지 기능(Probe 엔진, Nebula 저장소, SDLC 통합)은 이러한 초기 문제 발견에 도움을 드립니다.

2. 중앙 집중식 보안 저장소 (Vaults) 활용하기:

• API 키, 인증서, 비밀번호 등 모든 비밀 정보는 코드나 설정 파일이 아닌, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault와 같은 전용 보안 저장소(Vault)에 안전하게 보관해야 합니다. 이 저장소에 대한 접근 권한은 매우 엄격하게 관리되어야 합니다.

3. 자동화된 비밀 정보 교체: 선택이 아닌 필수:

• 유출된 자격 증명이 계속 사용될 수 있다는 문제 때문에 비밀 정보를 주기적으로 교체하는 것은 매우 중요합니다. 수동 교체는 오류 발생 가능성이 높고 대규모 환경에서는 관리하기 어려우므로, 자동화된 교체 프로세스를 구축해야 합니다. 이를 지원하는 도구나 플랫폼을 활용하는 것이 좋습니다.

4. 안전한 개발 습관으로 하드코딩 없애기:

• 안전한 코딩 표준을 수립하고, 개발자 교육을 제공하며, 개발 초기 단계부터 비밀 정보 관리 도구 사용을 장려해야 합니다.

원칙 3: 포괄적인 NHI 라이프사이클 관리 체계 구축하기

1. 가시성 확보: 모든 NHI 찾아내고 목록 만들기:

• 클라우드, 온프레미스, SaaS 등 모든 환경에 존재하는 NHI를 완전히 파악하는 것이 가장 중요합니다. 무엇이 있는지 모르면 보호할 수 없습니다. NHI를 자동으로 탐지하고 목록화하는 도구나 플랫폼을 활용해야 합니다. 저희 Cremit의 탐지 기능도 이러한 가시성 확보에 기여합니다.

2. 최소 권한 원칙 시행하기:

• 각 NHI에게는 해당 작업을 수행하는 데 필요한 최소한의 권한만 부여하는 원칙을 철저히 준수해야 합니다. 부여된 권한은 주기적으로 검토해야 합니다.

3. 자동화된 생성 및 안전한 오프보딩 (NHI1과 연결):

• 적절한 (최소한의) 권한을 가진 NHI를 생성하는 프로세스를 자동화해야 합니다. 애플리케이션이나 서비스가 더 이상 사용되지 않거나 관련 담당자가 퇴사할 때, 해당 NHI를 자동으로 비활성화하거나 삭제하는 프로세스가 필수적입니다. 이는 NHI1: 부적절한 오프보딩 위험을 줄이는 데 직접적으로 도움이 됩니다.

4. 이상 행위 지속적으로 감시하기:

• NHI의 활동(API 호출, 자원 접근 등)을 실시간으로 모니터링하는 시스템을 구축해야 합니다. 이상 행위 탐지(Anomaly Detection) 기술을 사용하여 비정상적인 접근 시도(예: 비정상적인 위치에서의 접근, 과도한 로그인 실패, 권한 상승 시도)를 식별하고 대응해야 합니다.

원칙 4: 환경에 맞게 보안 조정하기

1. 클라우드 네이티브 모범 사례 활용하기:

• 주요 클라우드 제공업체들은 기존의 고정 자격 증명보다 NHI 인증 보안을 개선하기 위해 설계된 고유한 기능들을 제공합니다. 이러한 네이티브 기능을 활용하는 것이 중요하지만, 각 플랫폼의 미묘한 차이와 모범 사례를 이해해야 합니다.
• AWS: EC2 인스턴스나 다른 서비스에는 장기 액세스 키 대신 IAM 역할(인스턴스 프로파일)을 사용하세요. STS를 통해 임시 자격 증명을 사용하세요. AWS Secrets Manager를 활용하세요. 최소 권한 원칙을 적용하고 IAM 조건을 사용하세요. CloudTrail로 활동을 모니터링하세요. 사용하지 않는 자원은 정기적으로 정리하세요.
• Azure: 코드에 자격 증명을 포함하지 않도록 관리 ID(시스템 할당 또는 사용자 할당)를 활용하세요. 유연성과 관리 부담 감소를 위해 사용자 할당 ID가 종종 선호됩니다. 최소 권한으로 RBAC를 적용하세요. 라이프사이클 관리에 유의하세요(사용자 할당 ID와 역할 할당은 수동 삭제 필요). 다른 비밀 정보는 Azure Key Vault를 사용하세요.
• GCP: 외부 워크로드(예: GitHub Actions, AWS, Azure)가 서비스 계정 키 없이 GCP 자원에 접근할 수 있도록 워크로드 아이덴티티 제휴(Workload Identity Federation)를 사용하세요. 보안을 위해 풀, 공급자, 속성 매핑 및 조건을 신중하게 구성해야 합니다. 제휴 관리를 위해 전용 프로젝트를 사용하는 것이 좋습니다. 제휴된 ID나 가장된 서비스 계정에 대한 IAM 바인딩을 통해 최소 권한을 적용하세요.
• AWS, Azure, GCP는 각각 고유한 접근 방식(IAM 역할, 관리 ID, 워크로드 아이덴티티 제휴)을 제공합니다. 목표(안전하고 자격 증명 없는 인증)는 유사하지만 구현 방식은 상당히 다릅니다. 이는 멀티 클라우드 환경에서 각 플랫폼에 대한 전문 지식이 필요하거나, 여러 클라우드에 걸쳐 NHI를 일관되게 관리할 수 있는 추상화 계층 또는 플랫폼이 필요함을 시사합니다. 한 클라우드의 개념을 다른 클라우드에 그대로 적용하는 것은 효과적이지 않을 수 있습니다.

원칙 5: 전문 NHI 보안 플랫폼 고려하기

1. 전용 솔루션의 역할: NHI 보안의 복잡성을 해결하기 위해 전문 플랫폼들이 등장하고 있습니다. 이들은 NHI 보안에 대한 통합적인 접근 방식을 제공하는 것을 목표로 합니다.
2. 주요 기능: 여러 공급업체의 설명을 종합하면 공통적으로 다음과 같은 기능들을 제공합니다 (종종 중복되지만 전체적인 그림을 보여줍니다):

• 모든 환경(멀티 클라우드/하이브리드)에서 NHI 탐지 및 목록화
• 상태 관리 (위험 요소, 잘못된 설정 식별)
• 맥락 파악 (소유자, 사용 방식, 권한 파악)
• 라이프사이클 관리 (자동 생성, 교체, 폐기)
• 비밀 정보 관리 도구와 통합 또는 자체 저장 기능 제공
• 위협 및 이상 행위 탐지 (NHI-DR)
• 자동화된 문제 해결
• 안전한 접근 제어
• 분류

3. Cremit이 NHI4 문제 해결에 기여하는 방법: 저희 Cremit은 특히 노출된 비밀 정보를 조기에 탐지하고, NHI 유출 현황을 파악하며, 안전한 개발을 위한 도구를 제공하는(DevSecOps 초점) 측면에서 강점을 가지고 있습니다. Cremit은 더 넓은 범위의 NHIM 플랫폼과 통합되거나 이를 보완하는 역할을 할 수 있습니다.

미래 내다보기: 규제 준수, 혁신, 그리고 경계

규제 압력: EO 14144 같은 명령 이해하기

미국의 행정 명령 14144(Executive Order 14144)와 같은 규제들은 NHI 보안을 강화하는 중요한 동력이 되고 있습니다. 이 명령은 특히 연방 정부 기관과 계약업체에 영향을 미치지만, 업계 전반의 모범 사례에도 영향을 줍니다.

주요 관련 요구 사항은 다음과 같습니다:

• 강화된 신원 관리: 피싱 방지 인증 표준(예: WebAuthn) 도입 요구.
• 개선된 비밀 정보 관리: 키 관리 및 교체 강화 강조.
• 소프트웨어 증명 요구: 소프트웨어 공급업체가 안전한 개발 관행(비밀 정보 처리 포함)을 증명하도록 요구.
• 제로 트러스트 아키텍처 추진: 제로 트러스트 원칙 구현 강조.
• AI와 사이버 보안: 사이버 보안에서 AI 활용 연구 및 개발 가속화.

EO 14144와 같은 규제 명령은 NHI4와 싸우는 데 필요한 많은 모범 사례들을 법제화하고 있습니다. 이는 특히 연방 계약업체와 같은 특정 분야에서 NHI 보안 수준을 높여야 한다는 압박을 가하며, NHI 보안을 '하면 좋은 것'에서 '반드시 해야 하는 것'으로 변화시키고 있습니다.

끊임없는 적응과 개선의 필요성

NHI 보안은 일회성 작업이 아니라 지속적인 과정입니다. 위협은 끊임없이 진화하고 환경은 계속 변화합니다. 따라서 수립된 전략을 꾸준히 모니터링하고, 정기적으로 검토하며, 필요에 따라 지속적으로 개선해 나가야 합니다.

결론

NHI4:2025 불안전한 인증은 현대 시스템에서 가장 중요하고 널리 퍼져있는 위협 중 하나입니다. 공격자가 시스템에 침투하는 주요 통로 역할을 하며, 그 결과는 치명적일 수 있습니다.

NHI 보안 태세를 강화하기 위한 핵심 방어 전략은 다음과 같습니다:

• 강력한 인증: 동적 자격 증명, mTLS, 상황 기반 검증을 도입하십시오.
• 엄격한 비밀 정보 관리: 조기에 탐지하고, 안전한 저장소를 사용하며, 자동 교체를 습관화하십시오.
• 포괄적인 라이프사이클 관리: 모든 NHI를 파악하고, 최소 권한 원칙을 적용하며, 지속적으로 모니터링하고, 안전하게 오프보딩하십시오.
• 클라우드 네이티브 기능을 활용하고 전문 도구를 고려하십시오.
• 그리고 이 모든 것의 바탕에는 제로 트러스트 사고방식이 있어야 합니다.

저희 Cremit은 기업들이 이러한 복잡한 과제, 특히 비밀 정보 탐지와 가시성 확보 측면에서 어려움을 극복할 수 있도록 돕는 데 최선을 다하고 있습니다. 계속 증가하는 NHI 관련 보안 위협으로부터 소중한 자산을 보호하기 위해서는 선제적이고 꾸준한 노력이 필수적입니다. 이 글이 여러분의 NHI 보안 인식을 높이고 실질적인 보안 강화에 도움이 되기를 바랍니다.