Azure 서비스에 대한 암호 없는 연결

2025-06-22

비고

암호 없는 연결은 여러 Azure 서비스에 걸쳐 언어에 구애받지 않는 기능입니다. 현재 설명서는 몇 가지 언어 및 서비스에 중점을 두고 있지만 현재 다른 언어 및 서비스에 대한 추가 설명서를 만드는 과정에 있습니다.

이 문서에서는 암호와 관련된 보안 문제에 대해 설명하고 Azure 서비스에 대한 암호 없는 연결을 소개합니다.

암호 및 비밀과 관련된 보안 문제

암호와 비밀 키는 주의해서 사용해야 하며 개발자는 안전하지 않은 위치에 두어서는 안 됩니다. 많은 앱이 사용자 이름, 암호 및 액세스 키를 사용하여 백 엔드 데이터베이스, 캐시, 메시징 및 이벤트 서비스에 연결합니다. 노출되는 경우 이러한 자격 증명을 사용하여 예정된 캠페인을 위해 빌드한 판매 카탈로그 또는 비공개여야 하는 고객 데이터와 같은 중요한 정보에 무단으로 액세스할 수 있습니다.

애플리케이션 자체에 암호를 포함하면 코드 리포지토리를 통한 검색을 비롯한 여러 가지 이유로 엄청난 보안 위험이 발생합니다. 많은 개발자가 환경 변수를 사용하여 이러한 암호를 외부화하여 애플리케이션이 다른 환경에서 로드할 수 있도록 합니다. 그러나 이는 코드 자체에서 실행 환경으로만 위험을 이동합니다. 환경에 대한 액세스 권한을 얻는 사람은 누구나 암호를 도용할 수 있으며, 이로 인해 데이터 반출 위험이 증가합니다.

다음 코드 예제에서는 저장소 계정 키를 사용하여 Azure 저장소에 연결하는 방법을 보여 줍니다. 많은 개발자들이 이상적인 솔루션은 아님에도 불구하고 과거에 작업했던 옵션에 익숙하게 느껴지기 때문에 이 솔루션에 끌립니다. 애플리케이션에서 현재 액세스 키를 사용하는 경우 암호 없는 연결로 마이그레이션하는 것이 좋습니다.

// Connection using secret access keys
BlobServiceClient blobServiceClient = new(
    new Uri("https://<storage-account-name>.blob.core.windows.net"),
    new StorageSharedKeyCredential("<storage-account-name>", "<your-access-key>"));

개발자는 안전하지 않은 위치에서 이러한 유형의 키 또는 비밀을 노출하지 않도록 부지런히 노력해야 합니다. 많은 회사에는 개발자, 운영자 또는 다른 사람에게 암호를 노출하지 않고 Azure 서비스에 연결하기 위한 엄격한 보안 요구 사항이 있습니다. 그들은 종종 볼트를 사용하여 암호를 저장하고 애플리케이션에 로드하며, 암호 순환 요구 사항 및 절차를 추가하여 위험을 더욱 줄입니다. 이러한 접근 방식은 운영 복잡성을 증가시키고 경우에 따라 애플리케이션 연결 중단으로 이어집니다.

암호 없는 연결 및 제로 트러스트

이제 앱에서 암호 없는 연결을 사용하여 암호를 회전할 필요 없이 Azure 기반 서비스에 연결할 수 있습니다. 경우에 따라 구성만 하면 새 코드가 필요하지 않습니다. 제로 트러스트는 "절대 신뢰하지 않고, 항상 확인하고, 자격 증명이 없다"는 원칙을 사용합니다. 즉, 신원을 확인한 후 백 엔드 서비스에 대한 액세스 권한을 부여하기 전에만 컴퓨터 또는 사용자를 신뢰하여 모든 통신을 보호합니다.

안전한 암호 없는 연결에 권장되는 인증 옵션은 관리 ID와 Azure RBAC(역할 기반 액세스 제어)를 함께 사용하는 것입니다. 이 방법을 사용하면 관리 ID에 대한 다양한 비밀을 수동으로 추적하고 관리할 필요가 없으므로 이러한 작업은 Azure에서 내부적으로 안전하게 처리됩니다.

Service Connector를 사용하여 Azure 서비스에 대한 암호 없는 연결을 구성하거나 수동으로 구성할 수 있습니다. 서비스 커넥터를 사용하면 Azure Spring Apps, Azure App Service 및 Azure Container Apps와 같은 앱 호스팅 서비스에서 관리 ID를 사용할 수 있습니다. 또한 서비스 커넥터는 관리 ID 및 Azure RBAC를 사용하여 암호 없는 연결로 백 엔드 서비스를 구성하고 필요한 연결 정보로 애플리케이션을 하이드레이션합니다.

암호 없는 연결을 위해 구성된 애플리케이션의 실행 환경을 검사하면 전체 연결 문자열을 볼 수 있습니다. 연결 문자열은 예를 들어 데이터베이스 서버 주소, 데이터베이스 이름 및 Azure 인증 플러그 인에 인증을 위임하는 지침을 전달하지만 암호나 비밀은 포함하지 않습니다.

다음 비디오에서는 Java 애플리케이션을 예로 사용하여 앱에서 Azure 서비스로의 암호 없는 연결을 보여 줍니다. 다른 언어에 대해서도 유사한 적용 범위가 곧 제공될 예정입니다.

DefaultAzureCredential 소개

Microsoft Entra ID 및 RBAC(역할 기반 액세스 제어)를 통한 Azure 서비스에 대한 암호 없는 연결은 Azure ID 클라이언트 라이브러리에서 사용하여 구현할 DefaultAzureCredential 수 있습니다.

중요합니다

일부 언어는 코드에서 명시적으로 DefaultAzureCredential을 구현해야 하지만, 다른 언어는 기본 플러그 인 또는 드라이버를 통해 내부적으로 DefaultAzureCredential을 활용합니다.

DefaultAzureCredential 여러 인증 방법을 지원하고 런타임에 사용해야 하는 방법을 자동으로 결정합니다. 이 방법을 사용하면 앱이 환경별 코드를 구현하지 않고도 다양한 환경(로컬 개발 및 프로덕션)에서 다양한 인증 방법을 사용할 수 있습니다.

자격 증명을 검색하는 순서와 위치는 DefaultAzureCredential 언어에 따라 다릅니다.

예를 들어 .NET에서 로컬로 사용하는 경우 일반적으로 DefaultAzureCredential에서 개발자가 Visual Studio, Azure CLI 또는 Azure PowerShell에 로그인하는 데 사용한 계정을 사용하여 인증합니다. 앱이 Azure에 배포되면 DefaultAzureCredential에서 자동으로 Azure App Service와 같은 연결된 호스팅 서비스의 관리 ID를 검색하고 사용합니다. 이 전환에는 코드 변경이 필요하지 않습니다.

비고

관리 ID는 앱 또는 서비스를 나타내는 보안 ID를 제공합니다. ID는 Azure 플랫폼에서 관리되며 비밀을 프로비전하거나 회전할 필요가 없습니다. 개요 설명서에서 관리 ID에 대해 자세히 확인할 수 있습니다.

다음 코드 예제에서는 암호 없는 연결을 사용하여 Service Bus에 연결하는 방법을 보여줍니다. 다른 설명서에서는 특정 서비스에 대해 이 설정으로 마이그레이션하는 방법을 자세히 설명합니다. .NET 앱은 of DefaultAzureCredential 인스턴스를 서비스 클라이언트 클래스의 생성자에 전달할 수 있습니다. DefaultAzureCredential은 해당 환경에서 사용 가능한 자격 증명을 자동으로 검색합니다.

ServiceBusClient serviceBusClient = new(
    new Uri("https://<your-service-bus-namespace>.blob.core.windows.net"),
    new DefaultAzureCredential());

참고하십시오

암호 없는 연결에 대한 자세한 설명은 개발자 가이드 여러 Azure 앱 및 서비스 간의 암호 없는 연결 구성을 참조하세요.