Azure Managed Identity로 커넥션 스트링·시크릿 없애기

코드나 설정 파일에 박혀 있는 비밀번호는 언젠가 새어 나갑니다. Azure 관리 ID(Managed Identity)를 쓰면 앱이 비밀번호 없이 데이터베이스·스토리지·Key Vault에 접근할 수 있습니다. 개념과 적용 절차, 자주 하는 실수를 정리했습니다.

커넥션 스트링 유출은 클라우드 사고의 단골 원인입니다. Git에 실수로 커밋되거나, 로그에 찍히거나, 설정 파일이 복사되며 퍼집니다. Azure 관리 ID는 이 문제를 근본에서 없앱니다. 앱에 Microsoft Entra ID가 관리하는 신원을 부여하고, 대상 리소스에는 “이 신원에 접근을 허용한다”는 권한만 주면 됩니다. 비밀번호는 애초에 존재하지 않으니 유출될 것도 없습니다.

시스템 할당 vs 사용자 할당

기준	시스템 할당	사용자 할당
수명 주기	리소스와 함께 생성·삭제	독립적으로 관리
연결 범위	리소스 1개에 1:1	여러 리소스에 공유
적합 상황	단일 앱, 간단한 구성	여러 앱이 같은 권한을 공유
권한 재설정	리소스 재생성 시 다시 부여	한 번 부여하면 유지

단일 앱이라면 시스템 할당이 간단합니다. 반면 여러 함수 앱이 같은 스토리지에 접근하는 식이라면, 사용자 할당 하나를 만들어 공유하는 편이 권한 관리가 훨씬 수월합니다.

적용 절차(App Service → Azure SQL 예시)

순서는 언제나 같습니다. 신원 켜기 → 대상에 권한 주기 → 코드에서 토큰으로 연결.

# 1) App Service에 시스템 할당 관리 ID 켜기
az webapp identity assign \
  --resource-group rg-demo --name my-webapp

# 2) 대상 리소스에 역할 부여 (예: Storage Blob 데이터 읽기)
az role assignment create \
  --assignee <principalId> \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub>/resourceGroups/rg-demo/providers/Microsoft.Storage/storageAccounts/mydata

Azure SQL이라면 데이터베이스에서 관리 ID를 외부 사용자로 등록합니다.

-- Azure SQL에서 관리 ID를 사용자로 추가
CREATE USER [my-webapp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-webapp];
ALTER ROLE db_datawriter ADD MEMBER [my-webapp];

코드에서는 커넥션 스트링이 사라진다

애플리케이션 코드는 비밀번호 대신 DefaultAzureCredential로 토큰을 받아 연결합니다. 클라우드에서는 관리 ID가, 로컬에서는 개발자 로그인이 자동으로 쓰입니다.

// .NET 예시 (Blob 접근)
using Azure.Identity;
using Azure.Storage.Blobs;

var client = new BlobServiceClient(
    new Uri("https://mydata.blob.core.windows.net"),
    new DefaultAzureCredential());   // 비밀번호 없음

# Python 예시 (Key Vault 접근)
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

cred = DefaultAzureCredential()
client = SecretClient("https://myvault.vault.azure.net", cred)

어떤 서비스에 쓸 수 있나

Microsoft Entra 인증을 지원하는 서비스라면 대부분 비밀번호 없는 연결이 됩니다.

• 지원 : Azure SQL, Storage(Blob·Queue·Table), Key Vault, Service Bus, Event Hubs, Cosmos DB, App Configuration
• 부분/불가 : 토큰 인증을 지원하지 않는 외부 SaaS·서드파티 DB는 여전히 시크릿이 필요할 수 있습니다. 이때는 시크릿을 Key Vault에 넣고, Key Vault 접근만 관리 ID로 처리하는 방식이 차선입니다.

흔한 실수

• 신원만 켜고 권한을 안 준다 — 관리 ID를 assign만 하고 대상 리소스에 역할을 부여하지 않으면 403이 납니다. 가장 흔한 실수입니다.
• 역할 전파 지연을 못 기다린다 — 역할 부여가 반영되기까지 몇 분 걸릴 수 있습니다. 부여 직후 실패한다고 코드를 의심하지 마세요.
• 로컬에서 관리 ID를 기대한다 — 개발 PC엔 관리 ID가 없습니다. az login으로 개발자 계정에 로그인해 두어야 DefaultAzureCredential이 대체합니다.
• 사용자 할당 ID를 지정하지 않는다 — 리소스에 사용자 할당 ID가 여러 개면 어느 것을 쓸지 클라이언트 ID로 명시해야 모호함이 사라집니다.
• Key Vault에 다시 커넥션 스트링을 넣는다 — 지원되는 서비스는 아예 비밀번호 없이 붙일 수 있는데, 습관적으로 Key Vault에 커넥션 스트링을 저장하면 관리 지점만 늘어납니다.

도입 순서 정리

기존 앱을 옮길 때는 한 번에 다 바꾸지 말고, 위험이 낮은 리소스부터 하나씩 전환하세요. 예를 들어 읽기 전용 Blob 접근을 먼저 관리 ID로 바꿔 검증한 뒤, 데이터베이스 쓰기처럼 영향이 큰 연결로 확대합니다. 전환이 끝난 커넥션 스트링은 설정과 Key Vault 양쪽에서 반드시 제거해야 “없앴다”고 말할 수 있습니다.

자주 묻는 질문

• Q. 시스템 할당과 사용자 할당은 무엇이 다른가요?
  시스템 할당은 리소스에 종속돼 함께 생성·삭제되고 1:1로 연결됩니다. 사용자 할당은 독립적으로 만들어 여러 리소스에 공유할 수 있어, 여러 앱이 같은 권한을 써야 할 때 유리합니다.
• Q. 관리 ID로 커넥션 스트링을 완전히 없앨 수 있나요?
  Azure SQL·Storage·Key Vault·Service Bus처럼 Entra 인증을 지원하는 서비스는 비밀번호 없는 연결이 됩니다. 다만 토큰 인증을 지원하지 않는 외부 시스템은 여전히 시크릿이 필요할 수 있습니다.
• Q. 로컬 개발에서는 어떻게 동작하나요?
  로컬엔 관리 ID가 없으므로 DefaultAzureCredential이 개발자 로그인(Azure CLI·Visual Studio 계정)으로 대체합니다. 같은 코드가 클라우드에서는 관리 ID로, 로컬에서는 개발자 자격 증명으로 인증됩니다.
• Q. 추가 비용이 드나요?
  관리 ID 자체는 무료입니다. 인증 방식만 바뀔 뿐 별도 과금 리소스가 생기지 않으므로, 보안을 높이면서 비용 부담은 없습니다.

정리하면, 관리 ID의 핵심은 “관리할 비밀번호를 애초에 만들지 않는 것”입니다. 신원을 켜고, 대상에 권한을 주고, 코드에서 토큰으로 연결하는 세 단계만 익히면 대부분의 Azure 연결에서 시크릿을 걷어낼 수 있습니다.