암호 및 보안 키는 수십 년 동안 디지털 보안의 기초였지만 더 이상 최신 위협을 따라갈 수 없습니다. 제로 트러스트 모델과 일치하는 비밀 없는 인증은 액세스 제어 및 사용자 확인을 자격 증명 없는 접근 방법으로 전환합니다. 비밀 없는 인증에는 암호, 인증서, 비밀 또는 보안 키와 같은 기존의 공유 자격 증명을 사용하지 않고 클라우드에서 보안 애플리케이션을 디자인하는 작업이 포함됩니다. 비밀 없는 인증은 다음과 같은 이점을 제공합니다.
- 자격 증명 위험 감소: 암호를 제거하면 비밀 인증은 자격 증명 도난, 피싱 공격 및 무차별 암호 대입 공격과 관련된 위험을 완화합니다. 이 방법은 생체 인식, 디지털 인증서 및 하드웨어 토큰과 같은 검증 가능한 ID 요소를 사용합니다.
- 간소화된 액세스 제어: 공유 비밀이 아닌 진정한 ID를 확인하는 메커니즘을 사용하여 보안을 강화하고 사용자 환경을 간소화합니다. 이는 실제 ID를 기반으로 모든 액세스 요청을 확인하여 제로 트러스트의 원칙에 부합합니다.
- 향상된 최종 사용자 환경: 사용자는 보다 원활하고 안전한 인증 프로세스를 통해 암호 재설정의 필요성을 줄이고 전반적인 사용자 만족도를 향상시킵니다.
이 문서에서는 Azure의 비밀 없는 인증, 이점 및 클라이언트 애플리케이션, Azure 서비스 간 통신 및 외부 워크로드를 비롯한 다양한 시나리오에서 이를 구현하는 방법을 살펴봅니다.
암호 및 비밀의 보안 문제
암호 및 기타 비밀은 주의해서 사용해야 하며 개발자는 암호 및 기타 비밀을 안전하지 않은 위치에 배치해서는 안 됩니다. 많은 앱이 사용자 이름, 암호 및 액세스 키를 사용하여 백 엔드 데이터베이스, 캐시, 메시징 및 이벤트 서비스에 연결합니다. 노출되는 경우 이러한 자격 증명을 사용하여 예정된 캠페인을 위해 빌드한 판매 카탈로그 또는 비공개여야 하는 고객 데이터와 같은 중요한 정보에 무단으로 액세스할 수 있습니다.
애플리케이션 자체에 암호를 포함하면 코드 리포지토리를 통한 검색을 비롯한 여러 가지 이유로 엄청난 보안 위험이 발생합니다. 많은 개발자가 환경 변수를 사용하여 이러한 암호를 외부화하여 애플리케이션이 다른 환경에서 로드할 수 있도록 합니다. 그러나 이는 코드 자체에서 실행 환경으로만 위험을 이동합니다. 환경에 대한 액세스 권한을 얻는 사람은 누구나 암호를 도용할 수 있으며, 이로 인해 데이터 반출 위험이 증가합니다.
키의 보안 문제
Azure 애플리케이션 개발에서 암호화 키를 사용하면 보안 및 운영 효율성을 모두 복잡하게 만들 수 있는 몇 가지 과제가 있습니다. 주요 문제 중 하나는 다양한 서비스 및 환경에서 키를 회전, 배포 및 안전하게 저장하는 번거로운 작업을 포함하는 주요 관리 복잡성입니다. 이 진행 중인 프로세스에는 전용 리소스가 필요하며 정기적인 유지 관리 및 모니터링이 필요하기 때문에 운영 비용이 크게 증가할 수 있습니다. 또한 키 유출로 인한 무단 액세스가 중요한 데이터를 손상시킬 수 있으므로 키 노출 또는 오용과 관련된 상당한 보안 위험이 있습니다. 또한 키 기반 인증 방법에는 동적 환경에 필요한 확장성 및 유연성이 부족하여 변화하는 요구 사항에 맞게 조정하고 작업을 효과적으로 확장하기가 어렵습니다. 이러한 과제는 위험을 완화하고 작업을 간소화하기 위해 관리 ID와 같은 보다 안전하고 효율적인 인증 방법을 채택하는 것의 중요성을 강조합니다.
클라이언트 애플리케이션(사용자 연결)이 Microsoft Entra로 보호된 리소스에 액세스합니다.
MFA(다단계 인증) 같은 기능은 조직을 보호하는 좋은 방법이지만, 암호를 기억해야 하는 데다가 추가 보안 계층까지 있어 사용자가 답답함을 느끼게 됩니다. 암호 없는 인증 방법은 암호가 제거되고 사용자가 가지고 있거나 알고 있는 항목으로 대체되기 때문에 더 편리합니다.
각 조직에는 인증과 관련하여 서로 다른 요구 사항이 있습니다. Microsoft Entra ID와 Azure Government는 다음 암호 없는 인증 옵션을 통합합니다.
- 비즈니스용 Windows Hello
- macOS용 플랫폼 자격 증명
- 스마트 카드 인증을 사용하는 macOS용 PSSO(플랫폼 Single Sign-On)
- Microsoft Authenticator
- 패스키 (FIDO2)
- 인증서 기반 인증
자세한 내용은 Microsoft Entra 암호 없는 로그인을 참조하세요.
Azure 서비스 간 서비스(Azure 내)
Azure 리소스(서비스 간 인증) 간에 인증할 때 권장되는 방법은 Azure 리소스에 관리 ID를 사용하는 것입니다. 그러나 테넌트 간에 리소스를 인증하고 액세스할 때는 관리 ID를 애플리케이션에서 페더레이션 ID 자격 증명으로 설정해야 합니다.
Microsoft Entra로 보호된 리소스에 액세스(동일한 테넌트)
시나리오 중 Azure 리소스들 간에 동일한 테넌트 내에서 서비스 간 인증이 필요할 경우, 관리형 ID와 Azure Identity 클라이언트 라이브러리의 DefaultAzureCredential 클래스가 권장되는 옵션입니다.
관리 ID는 Azure 컴퓨팅 리소스(예: Azure Virtual Machines, Azure Functions 또는 Azure Kubernetes) 또는 관리 ID를 지원하는 모든 Azure 서비스에 할당할 수 있는 ID입니다. 관리 ID가 컴퓨팅 리소스에 할당되면 스토리지 계정, SQL 데이터베이스, Cosmos DB 등과 같은 다운스트림 종속성 리소스에 액세스할 수 있는 권한을 부여받을 수 있습니다. 관리 ID는 서비스 대 서비스 종속성에 대한 액세스 키, 암호, 인증서 또는 다른 형태의 인증과 같은 비밀을 대체합니다.
자세한 내용은 Azure 리소스에 대한 관리 ID란?을 참조하세요.
애플리케이션에서 DefaultAzureCredential 및 관리 ID를 구현하여 Microsoft Entra ID 및 역할 기반 액세스 제어(RBAC)를 통해 Azure 서비스에 대한 비밀번호 없는 연결을 만듭니다.
DefaultAzureCredential 여러 인증 방법을 지원하고 런타임에 사용해야 하는 방법을 자동으로 결정합니다. 이 방법을 사용하면 앱이 환경별 코드를 구현하지 않고도 다양한 환경(로컬 개발 및 프로덕션)에서 다양한 인증 방법을 사용할 수 있습니다.
애플리케이션의 사용 DefaultAzureCredential 및 관리 ID에 대한 자세한 내용은 Azure 앱과 서비스 간의 비밀 없는 연결 구성을 참조하세요.
Microsoft Entra로 보호된 리소스에 액세스(테넌트 전체)
관리 ID는 Azure 리소스 간에 서비스 간 인증이 필요한 시나리오에 권장됩니다. 그러나 관리 ID는 테넌트(다중 테넌트 앱)에서 리소스에 액세스할 때 지원되지 않습니다. 이전에는 클라이언트 암호 또는 인증서를 자격 증명으로 사용하여 다중 테넌트 애플리케이션을 만들어 여러 테넌트의 리소스를 인증하고 액세스했습니다. 이렇게 하면 비밀 노출에 대한 상당한 위험이 발생하며 인증서 수명 주기를 저장, 회전 및 유지 관리해야 하는 부담이 추가됩니다.
이제 Azure 워크로드는 관리 ID를 페더레이션 ID 자격 증명으로 사용하여 비밀 또는 인증서를 사용하지 않고도 테넌트 전체에서 Microsoft Entra로 보호된 리소스에 안전하게 액세스할 수 있습니다.
자세한 내용은 관리 ID를 신뢰하도록 애플리케이션 구성을 참조하세요.
Azure 서비스는 외부 또는 비 Microsoft Entra로 보호되는 리소스에 액세스합니다.
액세스를 위해 암호, 비밀, 키 또는 인증서가 필요한 Microsoft Entra 또는 Azure 서비스에서 보호되지 않는 리소스를 인증하고 액세스하는 Azure 워크로드의 경우 관리 ID를 직접 사용할 수 없습니다. 이 경우 Azure Key Vault를 사용하여 대상 리소스에 대한 자격 증명을 저장합니다. 워크로드의 관리 ID를 사용하여 키 자격 증명 모음에서 자격 증명을 검색하고 자격 증명을 사용하여 대상 리소스에 액세스합니다.
자세한 내용은 코드에서 Key Vault에 대한 인증을 참조하세요.
외부 워크로드(Azure 외부)가 Microsoft Entra로 보호된 리소스에 액세스합니다.
소프트웨어 워크로드가 Azure 외부에서 실행되고(예: 온-프레미스 데이터 센터, 개발자 컴퓨터 또는 다른 클라우드에서) Azure 리소스에 액세스해야 하는 경우 Azure 관리 ID를 직접 사용할 수 없습니다. 과거에는 Microsoft ID 플랫폼에 애플리케이션을 등록하고 외부 앱에 대한 클라이언트 암호 또는 인증서를 사용하여 로그인했습니다. 이러한 자격 증명은 보안 위험을 초래하며 안전하게 저장되고 정기적으로 회전해야 합니다. 또한 자격 증명이 만료될 경우 서비스 가동 중지 시간이 발생할 위험이 있습니다.
워크로드 ID 페더레이션을 사용하여 Microsoft Entra ID에서 사용자 할당 관리 ID 또는 앱 등록을 구성하여 GitHub 또는 Google과 같은 IdP(외부 ID 공급자)의 토큰을 신뢰합니다. 신뢰 관계가 만들어지면 외부 소프트웨어 워크로드는 외부 IdP의 신뢰할 수 있는 토큰을 Microsoft ID 플랫폼의 액세스 토큰으로 교환합니다. 그러면 소프트웨어 워크로드가 해당 액세스 토큰을 사용하여 워크로드에 액세스 권한이 부여된 Microsoft Entra 보호 리소스에 액세스합니다. 사용자는 자격 증명을 수동으로 관리하는 유지 관리 부담이 제거되고 비밀이 유출되거나 인증서가 만료될 위험이 없습니다.
자세한 내용은 워크로드 ID 페더레이션을 읽어보세요.