이 예제 시나리오에서 주 애플리케이션에는 다음과 같은 세 가지 고유 인증 요구 사항이 있습니다.
Azure Key Vault (애저 키 볼트)
타사 서비스를 호출하는 데 필요한 안전하게 저장된 API 키를 검색하려면 애플리케이션이 Azure Key Vault를 사용하여 인증해야 합니다.
타사 API
API 키가 검색되면 애플리케이션은 이 키를 사용하여 외부 타사 API로 인증합니다.
Azure Queue Storage (Azure 대기열 저장소)
요청을 처리한 후 애플리케이션은 비동기 또는 지연된 처리를 위해 메시지를 큐에 넣기 위해 Azure Queue Storage로 인증해야 합니다.
이러한 작업을 수행하려면 앱에서 다음 세 가지 자격 증명 집합을 관리해야 합니다.
Azure 리소스용 2개(Key Vault 및 스토리지)
외부 서비스용 1개(타사 API)
주요 인증 과제
보안 클라우드 애플리케이션을 빌드하려면 특히 여러 서비스가 관련된 경우 자격 증명을 신중하게 처리해야 합니다. 이 예제 시나리오는 다음과 같은 몇 가지 중요한 과제를 제시합니다.
Key Vault에 대한 순환 종속성
애플리케이션은 Azure Key Vault를 사용하여 타사 API 키 또는 Azure Storage 자격 증명과 같은 비밀을 안전하게 저장합니다. 그러나 이러한 비밀을 검색하려면 앱이 먼저 Key Vault를 사용하여 인증해야 합니다. 이로 인해 순환 문제가 발생합니다. 앱은 Key Vault에 액세스하기 위해 자격 증명이 필요하지만 해당 자격 증명은 안전하게 저장되어야 합니다. 보안 솔루션이 없으면 개발 환경에서 하드 코딩된 자격 증명 또는 안전하지 않은 구성으로 이어질 수 있습니다.
타사 API 키의 보안 처리
Key Vault에서 API 키를 검색한 후 애플리케이션은 이를 사용하여 외부 타사 서비스를 호출해야 합니다. 이 키는 매우 주의하여 처리해야 합니다.
- 소스 코드 또는 구성 파일에서 하드 코딩되지 않습니다.
- stdout, stderr 또는 애플리케이션 로그에 기록되지 않습니다.
- 메모리에만 보관되고 런타임에 액세스( 사용 직전)
- 요청이 완료된 후 즉시 삭제됨
이러한 사례를 따르지 않으면 자격 증명 누출 또는 무단 사용의 위험이 증가합니다.
Azure Queue Storage 자격 증명 보안
Azure Queue Storage에 메시지를 쓰려면 앱에 일반적으로 연결 문자열 또는 공유 액세스 토큰이 필요합니다. 다음 자격 증명:
- Key Vault와 같은 안전한 위치에 저장해야 합니다.
- 로그, 스택 추적 또는 개발자 도구에 표시되지 않아야 합니다.
- 보안 런타임 메커니즘을 통해서만 액세스해야 합니다.
- 관리 ID를 사용하는 경우 적절한 RBAC 구성 필요
환경 유연성
앱은 동일한 코드베이스와 최소한의 조건부 논리를 사용하여 로컬 개발 및 클라우드 프로덕션 환경 모두에서 안정적으로 실행되어야 합니다.
즉, 다음을 의미합니다.
- 코드에 환경별 비밀이 포함되지 않음
- 자격 증명 또는 논리 경로를 수동으로 전환할 필요가 없습니다.
- 환경 전체에서 ID 기반 인증의 일관된 사용
Microsoft Entra ID로 Azure-First 인증
클라우드 애플리케이션이 복잡해지고 더 많은 서비스와 통합됨에 따라 안전하고 간소화된 인증이 필수적입니다. Azure는 Microsoft Entra ID를 통해 "Azure 우선" ID 모델을 제공하여 통합 ID 관리 및 Azure 서비스와의 원활한 통합을 통해 안전하고 자격 증명 없는 인증을 지원합니다.
Microsoft Entra ID를 사용하면 보안 위험이 발생하기 쉬운 애플리케이션 코드에 암호를 수동으로 관리하거나 자격 증명을 포함하는 대신 앱에서 관리 ID를 사용하여 안전하게 인증할 수 있습니다.
Microsoft Entra 관리 ID의 주요 이점은 다음과 같습니다.
코드에 비밀 없음
애플리케이션에는 더 이상 하드 코딩된 연결 문자열, 클라이언트 비밀 또는 키가 필요하지 않습니다.
앱에 대한 기본 제공 ID
Azure는 앱에 관리 ID를 자동으로 할당하여 추가 자격 증명 없이 Key Vault, Storage 및 SQL과 같은 서비스에 대한 보안 액세스를 허용합니다.
환경 일관성
동일한 코드 및 ID 모델은 Azure SDK의 DefaultAzureCredential을 사용하여 로컬 개발 및 Azure 호스팅 환경에서 모두 작동합니다.
환경별 ID 흐름
인증에 Microsoft Entra ID를 사용하는 애플리케이션은 Azure 호스팅 및 로컬 개발 환경 모두에서 원활하게 작동하는 유연한 ID 모델을 활용할 수 있습니다. 이 일관성은 환경에 따라 적절한 ID 방법을 자동으로 선택하는 Azure SDK DefaultAzureCredential를 사용하여 수행됩니다.
Azure 환경
애플리케이션이 Azure에 배포되는 경우:
- 관리 ID는 애플리케이션에 자동으로 할당됩니다.
- Azure는 토큰 발급 및 자격 증명 수명 주기를 내부적으로 처리하며 수동 비밀은 필요하지 않습니다.
- 애플리케이션은 Role-Based RBAC(Access Control) 또는 Key Vault 액세스 정책을 사용하여 서비스에 액세스합니다.
로컬 개발 환경
로컬 개발 중:
- 서비스 주체는 앱의 ID 역할을 합니다.
- 개발자는 Azure CLI(az login), 환경 변수 또는 Visual Studio/VS Code 통합을 사용하여 인증합니다.
- 동일한 애플리케이션 코드는 수정 없이 실행되며 ID 원본만 변경됩니다.
두 환경 모두에서 Azure SDK는 ID 원본을 추상화하고 올바른 메서드를 자동으로 선택하는 를 사용합니다 DefaultAzureCredential.
안전한 개발을 위한 모범 사례
비밀을 환경 변수로 설정할 수 있지만(예: Azure 앱 설정을 통해) 이 방법에는 단점이 있습니다.
- 로컬 환경에서 비밀을 수동으로 복제해야 합니다.
- 비밀이 소스 제어로 유출될 위험이 있습니다.
- 환경을 구분하기 위해 추가 논리가 필요할 수 있습니다.
대신 권장되는 방법은 다음과 같습니다.
- Key Vault를 사용하여 타사 API 키 및 기타 비밀을 저장합니다.
- 배포된 앱에 관리 ID를 할당합니다.
- 로컬 개발에 서비스 주체를 사용하고 동일한 액세스 권한을 할당합니다.
- 코드에서
DefaultAzureCredential를 사용하여 인증 논리를 추상화합니다. - 자격 증명을 저장하거나 로깅하지 않습니다.
실제 인증 흐름 사례
런타임에 인증이 작동하는 방법은 다음과 같습니다.
- 코드가
DefaultAzureCredential인스턴스를 생성합니다. - 이 자격 증명을 사용하여 클라이언트를 인스턴스화합니다(예: SecretClient, QueueServiceClient).
- 앱이 메서드(예
get_secret(): )를 호출할 때 클라이언트는 자격 증명을 사용하여 요청을 인증합니다. - Azure는 ID를 확인하고 작업을 수행할 올바른 역할 또는 정책이 있는지 확인합니다.
이 흐름을 통해 앱은 코드 또는 구성 파일에 비밀을 포함하지 않고도 Azure 서비스에 안전하게 액세스할 수 있습니다. 또한 인증 논리를 변경하지 않고도 로컬 개발과 클라우드 배포 간에 원활하게 전환할 수 있습니다.