이 예제 시나리오에서 주 애플리케이션에는 다음과 같은 세 가지 고유 인증 요구 사항이 있습니다.
Azure Key Vault (애저 키 볼트)
애플리케이션은 Azure Key Vault 인증하여 타사 서비스를 호출하는 데 필요한 안전하게 저장된 API 키를 검색해야 합니다.
타사 API
애플리케이션이 API 키를 검색하면 이 키를 사용하여 외부 타사 API로 인증합니다.
Azure Queue Storage (Azure 대기열 저장소)
요청을 처리한 후 애플리케이션은 비동기 또는 지연된 처리를 위해 메시지를 큐에 넣기 위해 Azure Queue Storage로 인증해야 합니다.
이러한 작업을 수행하려면 앱에서 다음 세 가지 자격 증명 집합을 관리해야 합니다.
Azure 리소스(Key Vault 및 Storage)에 대한 두 집합
외부 서비스에 대한 하나의 집합(타사 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 우선 인증
클라우드 애플리케이션이 복잡해지고 더 많은 서비스와 통합됨에 따라 안전하고 간소화된 인증이 필수적입니다. 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 모델을 활용할 수 있습니다. Azure SDK DefaultAzureCredential 환경에 따라 적절한 ID 메서드를 자동으로 선택하여 이러한 일관성을 제공합니다.
Azure 환경
Azure 애플리케이션을 배포하는 경우:
- 애플리케이션은 자동으로 관리 ID를 가져옵니다.
- Azure 토큰 발급 및 자격 증명 수명 주기를 내부적으로 관리하므로 비밀을 처리할 필요가 없습니다.
- 애플리케이션은 RBAC(Role-Based 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 서비스에 안전하게 액세스할 수 있습니다. 또한 인증 논리를 변경하지 않고도 로컬 개발과 클라우드 배포 간에 원활하게 전환할 수 있습니다.