Azure에서 관리 ID로 하드코딩된 암호를 없애는 방법

By Mirko Peters · 2026-08-13

팟캐스트 동반 블로그에 다시 오신 것을 환영합니다! 애플리케이션을 어느 정도 오래 개발해 오셨다면, 코드를 데이터베이스, API 또는 클라우드 스토리지 계정에 연결하는 오래된 문제를 한 번쯤 겪어 보셨을 것입니다.

Automatically translated with AI from the original post. Read the English original

Cover: Entra Workload Identities - Simply Explained

팟캐스트 동반 블로그에 다시 오신 것을 환영합니다! 애플리케이션을 어느 정도 오래 개발해 오셨다면, 코드를 데이터베이스, API 또는 클라우드 스토리지 계정에 연결하는 오래된 문제를 한 번쯤 겪어 보셨을 것입니다. 전통적으로 개발자들은 연결 문자열, 데이터베이스 암호 또는 클라이언트 암호를 구성 파일이나 환경 변수에 직접 넣거나, 더 나쁘게는 소스 코드 저장소에 그대로 하드코딩하는 방식으로 이 문제를 해결해 왔습니다. 애플리케이션이 해당 비밀 값을 읽을 수만 있다면 인증을 수행하고 작업을 처리할 수 있었습니다. 하지만 그 코드가 실수로 공개 GitHub 저장소에 푸시되면 어떻게 될까요? 불만을 품은 직원이 퇴사하거나 공격자가 애플리케이션 설정에 대한 읽기 권한을 얻으면 어떻게 될까요? 인프라 전체가 즉시 침해될 수 있습니다. 현대 클라우드 아키텍처에서 이는 용납할 수 없는 위험입니다. 오늘은 Microsoft Azure의 관리 ID가 정적 비밀 값을 동적이고 수명이 짧은 액세스 토큰으로 대체하여 하드코딩된 암호의 필요성을 어떻게 완전히 없애는지 자세히 살펴보겠습니다.

클라우드 보안과 하드코딩된 비밀 값 소개

전통적인 경계 기반 보안 모델은 일단 회사 네트워크 안에 들어오면 신뢰할 수 있다는 전제에 크게 의존했습니다. 이 경계 안에서 애플리케이션은 정적 서비스 계정, 하드코딩된 암호, 그리고 만료되는 일이 거의 없는 장기 토큰을 사용해 통신했습니다. 공격자가 경계를 뚫는 데 성공하면 무기한 재사용할 수 있는 정적 자격 증명을 한가득 손에 넣게 되었습니다.

클라우드 컴퓨팅은 이러한 경계를 완전히 무너뜨렸습니다. 이제 워크로드는 다중 클라우드 환경, 온프레미스 데이터 센터, SaaS 플랫폼, 그리고 분산된 서버리스 함수에 걸쳐 존재합니다. 이런 새로운 환경에서는 보안이 워크로드 자체의 ID를 따라야 합니다. 하드코딩된 비밀 값은 시한폭탄과 같습니다. 자동으로 교체되지 않고, 감사하기도 매우 어려우며, 노출되면 실수의 여지가 전혀 없습니다. 진정한 제로 트러스트 보안을 달성하려면 자격 증명을 소스 코드에서 완전히 분리해야 합니다. 애플리케이션이 암호를 알거나 저장할 필요 없이 자신이 누구인지 증명할 수 있는 인증 메커니즘이 필요합니다.

Microsoft Entra ID의 사용자 ID와 워크로드 ID 이해하기

클라우드 보안이 어떻게 발전해 왔는지 이해하려면, 먼저 Microsoft Entra ID가 시스템에 접근하는 주체를 어떻게 관리하는지 살펴볼 필요가 있습니다. 대체로 Microsoft Entra ID는 ID를 사용자 ID와 워크로드 ID라는 두 가지 주요 범주로 분류합니다.

사용자 ID는 직원, 파트너, 계약자, 고객 등 사람을 나타냅니다. 사람은 시스템과 동적으로 상호 작용하며, 암호, Windows Hello for Business, FIDO2 보안 키, 다단계 인증 등 사람에게 맞춘 방식으로 인증합니다. 사람은 암호를 잊어버리고, 피싱 공격에 속아 넘어가며, 관리자의 암호 재설정이 필요하기도 합니다.

반면 워크로드 ID는 소프트웨어를 나타냅니다. 여기에는 애플리케이션, 백그라운드 서비스, 자동화 스크립트, Azure Functions, Logic Apps, DevOps 배포 파이프라인, AI 에이전트가 포함됩니다. 워크로드는 커피를 마시지 않고, 피싱 이메일을 클릭하지 않으며, 스마트폰에서 대화형 다단계 인증 요청을 완료할 수도 없습니다. 워크로드는 대화형이 아니라 프로그래밍 방식으로, 그리고 지속적으로 비대화형 인증을 수행해야 합니다. 워크로드 ID에 정적 암호를 할당하여 사용자 ID처럼 취급하는 것은 클라우드 아키텍처에서 가장 흔한 함정 중 하나입니다. 워크로드 ID에는 별도의 전문적인 거버넌스 모델, 수명 주기 관리, 자동화된 인증 흐름이 필요합니다.

앱 등록, 서비스 주체, 관리 ID 이해하기

Microsoft Entra ID에서 애플리케이션을 구성해 본 적이 있다면, 혼란을 자주 일으키는 세 가지 용어인 애플리케이션 등록, 서비스 주체, 관리 ID를 분명 마주쳤을 것입니다. 간단히 하나씩 살펴보겠습니다.

애플리케이션 등록(Application Registration)은 애플리케이션의 전역 정의이자 설계도입니다. Microsoft Entra ID에 애플리케이션을 등록하면 다중 테넌트 생태계 전체에서 사용되는 전역 ID가 만들어집니다. 여기서 애플리케이션이 필요로 할 수 있는 권한, 사용하는 인증 엔드포인트, 그리고 연결된 URI를 정의합니다. 애플리케이션 등록은 여권의 양식이라고 생각하면 이해하기 쉽습니다.

서비스 주체(Service Principal)는 특정 테넌트 안에서 해당 애플리케이션의 로컬 인스턴스입니다. 애플리케이션이 다중 테넌트용이라면 게시자 테넌트에는 애플리케이션 등록이 하나 있지만, 배포되고 동의가 이루어진 고객 테넌트마다 별도의 서비스 주체가 생성됩니다. 관리자가 실제로 권한을 할당하고, 조건부 액세스 정책을 적용하며, 로컬에서 누가 애플리케이션에 접근할 수 있는지 제어하는 대상이 바로 서비스 주체입니다. 서비스 주체는 특정 국가에 입국할 때 실제로 찍히는 여권 도장이라고 생각하면 됩니다.

관리 ID(Managed Identity)는 Microsoft Azure 내에서 실행되는 리소스를 위해 이 개념을 한 단계 더 발전시킨 것입니다. 개발자가 애플리케이션 등록을 수동으로 만들고, 클라이언트 비밀을 생성하고, 그 비밀을 환경 변수에 저장한 뒤, 인증 수명 주기를 처리하는 코드를 작성할 필요가 없습니다. Azure가 이 전체 과정을 뒤에서 처리합니다. Azure가 기본 자격 증명을 생성하고, 관리하고, 자동으로 교체해 줍니다. 개발자는 Azure 리소스에 관리 ID를 사용하도록 지정하기만 하면 나머지는 Azure가 알아서 처리합니다.

관리 ID가 암호와 하드코딩된 자격 증명을 없애는 방법

관리 ID의 핵심은 인증 트랜잭션의 방식을 근본적으로 바꾼다는 데 있습니다. Azure App Service, 가상 머신, Azure Function과 같은 Azure 리소스에 관리 ID를 사용하면 코드나 구성 설정에 암호, 비밀, 인증서가 저장되지 않습니다. 말 그대로 아무것도 없습니다.

애플리케이션이 데이터베이스나 API처럼 보호된 리소스에 접근해야 할 때, 저장된 암호를 조회하지 않습니다. 대신 해당 Azure 리소스 내부에서만 안전하게 접근할 수 있는 Azure 인스턴스 메타데이터 서비스(IMDS) 엔드포인트에 로컬로 호출합니다. Azure 리소스의 기반 플랫폼은 애플리케이션을 대신해 Microsoft Entra ID에 수명이 짧은 JSON 웹 토큰(JWT)을 직접 요청합니다.

Microsoft Entra ID는 Azure 리소스의 ID를 확인한 뒤 수명이 매우 짧은(보통 약 1시간) 암호학적으로 서명된 액세스 토큰을 발급해 애플리케이션에 돌려줍니다. 애플리케이션은 이 토큰으로 대상 서비스에 인증합니다. 토큰의 만료 기간이 짧기 때문에 공격자가 토큰을 가로채더라도 악용할 수 있는 기간이 극히 좁습니다. 또한 코드에 고정된 암호가 없으므로 개발자가 실수로 공개 리포지토리에 유출할 것도 없습니다.

Azure Key Vault와 수명이 짧은 액세스 토큰 통합하기

관리 ID를 사용하면 애플리케이션 암호는 필요 없지만, Microsoft Entra 인증을 지원하지 않는 서드파티 서비스의 API 키처럼 실제로 외부에 있는 비밀은 어떻게 처리해야 할지 궁금할 수 있습니다. 이때 관리 ID와 긴밀하게 협력하는 Azure Key Vault가 필요합니다.

서드파티 API 키를 소스 코드에 하드코딩하는 대신, 해당 비밀을 Azure Key Vault 안에 안전하게 저장합니다. 그런 다음 Azure RBAC(역할 기반 액세스 제어) 또는 Key Vault 액세스 정책을 사용해 Azure 리소스의 관리 ID에 이 Key Vault의 비밀을 읽을 수 있는 권한을 부여합니다.

애플리케이션이 시작되면 관리 ID를 사용해 Azure Key Vault에 인증하고, 필요한 서드파티 API 키를 메모리에서 동적으로 가져와 사용합니다. 이 과정에서 자격 증명이 소스 코드에 노출되는 일은 전혀 없습니다. 애플리케이션은 구성 파일에 포함된 고정 문자열에 의존하지 않고, ID 기반의 안전한 방식으로 비밀을 가져옵니다.

최소 권한과 거버넌스로 워크로드 ID 보호하기

하드코딩된 암호를 없애는 것은 보안 측면에서 엄청난 성과이지만, 관리 ID를 배포했다고 해서 한 번 설정하고 잊어버려도 되는 운영 모델이 되는 것은 아닙니다. 워크로드 ID도 사람 사용자 계정과 마찬가지로 탄탄한 거버넌스가 필요합니다.

무엇보다 최소 권한 원칙을 엄격히 지켜야 합니다. 일을 빨리 끝내려고 워크로드 ID에 광범위한 기여자 역할이나 과도한 Microsoft Graph 권한을 부여하지 마십시오. 백그라운드 자동화 스크립트가 특定 Azure Storage 컨테이너의 항목만 읽으면 된다면, 정확히 그 컨테이너에 대한 Storage Blob Data Reader 액세스 권한만 부여하고 그 이상은 주지 마십시오. 해당 워크로드 ID가 침해되더라도 영향 범위를 최소화할 수 있습니다.

다음으로, 워크로드 ID를 지속적으로 모니터링하고 감사해야 합니다. 조직은 개념 증명(PoC) 프로젝트, 자동화 스크립트, 임시 통합을 위해 서비스 주체와 관리 ID를 자주 만들지만, 그중 상당수가 높은 권한을 가진 채로 무기한 방치됩니다. 정기적인 보안 검토를 구현하여 고아 서비스 주체, 사용되지 않는 자동화 계정, 오래된 자격 증명을 찾아내십시오. Microsoft Entra ID Protection 같은 기능을 활용하고 Azure Monitor를 통해 견고한 로깅을 설정하면, 워크로드 ID가 언제, 어떻게 환경에 액세스하는지 완전히 파악할 수 있습니다.

모든 클라우드 워크로드에 맞는 ID 전략 선택하기

Microsoft ID 생태계에는 선택지가 매우 많습니다. 그렇다면 특정 워크로드에 맞는 인증 전략은 어떻게 선택해야 할까요? 결정은 일반적으로 애플리케이션이 실행되는 위치와 아키텍처 방식에 따라 달라집니다.

코드가 Azure App Services, Azure Functions, Virtual Machines, Container Instances, Azure Kubernetes Service 등 Microsoft Azure 안에서 실행된다면, 첫 번째 선택은 항상 관리 ID여야 합니다. 시스템 할당 관리 ID(Azure 리소스와 1:1로 수명이 연결됨)와 사용자 할당 관리 ID(독립적으로 만들어 여러 Azure 리소스에 할당할 수 있어 관리가 더 쉬움) 중에서 선택할 수 있습니다.

애플리케이션이 온프레미스 서버, AWS, 또는 GitHub Actions의 CI/CD 파이프라인처럼 Azure 외부에서 실행된다면, Azure 인프라가 호스팅하는 관리 ID는 사용할 수 없습니다. 이런 경우에는 워크로드 ID 페더레이션을 활용해야 합니다. 외부 플랫폼이 OpenID Connect(OIDC) 신뢰를 사용해 Microsoft Entra ID와 직접 토큰을 교환할 수 있으며, 장기 실행 클라이언트 암호를 관리, 교체, 저장할 필요가 완전히 없어집니다.

마지막으로, 관리 ID도 페더레이션도 적용할 수 없고 클라이언트 인증이 필요한 전통적인 사용자 지정 엔터프라이즈 애플리케이션이라면, 장기 실행 클라이언트 암호보다 세심하게 관리되는 인증서를 항상 우선해야 합니다. Microsoft Entra Workload Identities, Azure Key Vault, 제로 트러스트 원칙, 최소 권한 액세스를 함께 적용하면 조직은 하드코딩된 암호를 완전히 없애고 매우 탄력적인 클라우드 아키텍처를 구축할 수 있습니다.