Microsoft AZ-204: Azure 인증, 권한 부여 및 보안 — 학습 가이드

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Developer Associate AZ-204 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure 인증 및 권한 부여는 Microsoft Identity Platform을 중심으로 이루어지며, 이 플랫폼은 ID(사용자, 앱, 워크로드)에 토큰을 발급하고 API 및 리소스에 대한 액세스를 강제합니다. 애플리케이션은 OAuth 2.0 및 OpenID Connect를 통해 통합하고, MSAL을 사용하여 토큰을 획득하며, Azure AD 앱 등록에 선언된 권한을 요청합니다. Azure에서 실행되는 워크로드는 관리 ID를 사용하여 자격 증명을 완전히 제거하고, Azure RBAC에 의존하여 Key Vault, Storage, Microsoft Graph와 같은 서비스에 접근할 수 있습니다. 비밀 관리는 Azure Key Vault를 중심으로 이루어지며, 볼트 데이터 평면 액세스와 관리 평면 제어가 명확히 분리되고, 일시 삭제(soft delete) 및 제거 방지(purge protection)를 통해 강력한 복구 기능이 보장됩니다. 스토리지의 경우, SAS(공유 액세스 서명)는 계정 키를 노출하지 않고 클라이언트에게 범위가 지정되고 시간 제한이 있는 위임을 제공합니다.

Microsoft Identity Platform, OAuth 2.0, MSAL, 및 앱 등록

Microsoft Identity Platform은 다양한 애플리케이션 유형에 최적화된 여러 OAuth 2.0 흐름을 지원합니다:

• 권한 부여 코드 흐름(Authorization code flow): 웹 앱, SPA, 네이티브 앱의 표준 방식입니다. 퍼블릭 클라이언트는 PKCE를 사용하여 권한 부여 코드를 보호해야 합니다. 앱은 사용자를 authorize 엔드포인트로 리디렉션하고, 리디렉션 URI에서 권한 부여 코드를 받은 다음, token 엔드포인트에서 이를 액세스 토큰(및 선택적으로 리프레시 토큰)으로 교환합니다. SPA의 경우, 권한 부여 코드 + PKCE는 기존의 암시적 흐름(implicit flow)을 대체하고 토큰 유출을 완화합니다.
• 클라이언트 자격 증명 흐름(Client credentials flow): 사용자가 없는 데몬 및 서버 간 서비스에서 사용됩니다. 애플리케이션은 클라이언트 어설션(인증서) 또는 클라이언트 암호를 사용하여 토큰을 요청합니다. 여기서는 애플리케이션 권한(앱 역할)만 사용할 수 있으며, 대부분은 관리자 동의가 필요합니다. 이 흐름은 /.default 범위를 사용하여 정적으로 구성된 애플리케이션 권한 집합을 요청합니다.
• 디바이스 코드 흐름(Device code flow): 내장 브라우저가 없는 디바이스나 환경을 위해 설계되었습니다. 앱은 ID 플랫폼에서 사용자 코드와 확인 URL을 받고, 사용자는 별도의 디바이스에서 인증하며, 앱은 token 엔드포인트를 폴링합니다. 사용자가 로그인하기 때문에 위임된 권한이 적용됩니다.
• 암시적 부여 흐름(Implicit grant flow): 과거에 SPA가 authorize 엔드포인트에서 직접 토큰을 받기 위해 사용되었습니다. 현재는 PKCE를 사용하는 권한 부여 코드 방식이 권장되어 사용이 권장되지 않습니다. 만약 사용한다면, 앱 등록 시 여전히 리디렉션 URI가 필요합니다.

MSAL(Microsoft Authentication Library)은 여러 언어와 플랫폼에서 일관된 토큰 획득 방법을 제공합니다. 퍼블릭 클라이언트 애플리케이션(데스크톱, 모바일, SPA)은 AcquireTokenInteractive와 AcquireTokenSilent를 사용하여 토큰을 획득하고 캐시합니다. 네이티브 앱은 디바이스 코드 흐름을 위해 AcquireTokenByDeviceCode를, 기밀 클라이언트 컨텍스트에서 권한 부여 코드를 교환하기 위해 AcquireTokenByAuthorizationCode를 사용하기도 합니다. 기밀 클라이언트(웹 앱/API/데몬)는 클라이언트 자격 증명을 사용할 때 AcquireTokenForClient로 토큰을 획득하고, API가 사용자의 위임된 컨텍스트를 사용하여 다운스트림 API를 호출하는 OBO 시나리오에서는 AcquireTokenOnBehalfOf를 사용합니다.

토큰 캐싱은 MSAL의 핵심적인 부분입니다. 계정, 클라이언트, 범위를 키로 하여 액세스 토큰과 리프레시 토큰을 저장하므로, AcquireTokenSilent를 통해 불필요한 대화형 프롬프트를 피할 수 있습니다. 여러 인스턴스에서 실행되는 웹 앱과 API는 공유되고 암호화된 저장소(예: 저장 데이터 및 전송 중 데이터가 적절히 암호화된 분산 캐시)를 사용하여 토큰 캐시를 유지하고 보호해야 합니다. MSAL의 캐시 직렬화 후크(hook)를 통해 안전한 영속성을 구현할 수 있습니다. 범위(Scope)는 앱이 요청하는 권한을 식별합니다. 위임된 권한의 경우, 최소한의 리소스별 범위(예: https://graph.microsoft.com/User.Read)를 요청하세요. 클라이언트 자격 증명의 경우, 리소스 기반의 /.default를 요청하세요. 이는 앱에 정적으로 부여된 애플리케이션 권한에 매핑됩니다(예: scope = https://graph.microsoft.com/.default). 점진적 동의(incremental consent)를 사용하여 범위를 점진적으로 요청하고 사용자 마찰을 줄이세요.

Azure AD 앱 등록은 애플리케이션 ID, 자격 증명, 리디렉션 URI, 권한을 정의합니다. 위임된 권한은 로그인한 사용자가 필요하며, 종종 사용자가 자신의 데이터에 대해 직접 동의할 수 있습니다. 애플리케이션 권한은 앱 자체에 부여되며, 테넌트 전체 또는 광범위하게 적용되기 때문에 거의 항상 관리자 동의가 필요합니다. API를 노출하는 앱은 “API 노출(Expose an API)” 항목 아래에 범위(위임된 권한용)와 앱 역할(애플리케이션 권한용)을 선언합니다. 신뢰 경계에 따라 단일 테넌트 또는 다중 테넌트 액세스를 구성하고, 더 강력한 자격 증명과 쉬운 순환을 위해 클라이언트 암호 대신 인증서를 사용하세요.

Microsoft Graph는 동일한 토큰 발급 방식을 사용합니다. Graph 리소스를 대상으로 MSAL로 인증하고 최소 권한 범위를 요청하세요. 일반적인 엔드포인트는 다음과 같습니다:

• GET https://graph.microsoft.com/v1.0/me: 위임된 토큰(예: User.Read)을 사용하여 사용자 프로필 조회
• GET https://graph.microsoft.com/v1.0/users 및 /groups: 디렉터리 개체 조회 (User.Read.All 또는 Group.Read.All과 같은 적절한 위임된 권한 또는 애플리케이션 권한 필요)
• GET https://graph.microsoft.com/v1.0/sites 또는 /drives: SharePoint/OneDrive 작업 수행 클라이언트 자격 증명을 사용할 때는 /.default 범위를 요청하고, 필요한 애플리케이션 권한에 대한 관리자 동의가 있는지 확인하세요. 올바른 기관(authority)(테넌트 특정 대 common/organizations)을 선택하여 사용자가 로그인할 수 있는 위치와 토큰이 발급될 수 있는 위치를 제어하세요.

관리 ID와 Azure 리소스에 대한 보안 액세스, 그리고 Key Vault 참조

Azure 리소스용 관리 ID(Managed identity)는 Azure가 서비스 주체(service principal) 자격 증명을 관리하도록 허용하여 비밀(secret)을 제거합니다. 시스템 할당 관리 ID는 리소스(App Service, Function App, VM, VMSS, Logic App 등)와 1:1로 연결되며 해당 리소스의 수명 주기를 공유합니다. 리소스가 삭제되면 ID도 함께 삭제됩니다. 사용자 할당 관리 ID는 여러 컴퓨팅 리소스에 연결할 수 있는 독립적인 Azure 리소스로 생성되며, 특정 워크로드의 수명 주기와는 독립적으로 존재합니다. 이 모델은 ID 재사용 및 직무 분리(separation of duties)를 지원합니다.

관리 ID를 사용하여 Azure 리소스에 액세스하려면, 적절한 범위에서 적절한 Azure RBAC 역할을 부여해야 합니다.

• Azure AD를 사용하는 Azure Storage 데이터 평면(data plane)의 경우, 스토리지 계정, 컨테이너 또는 RG/구독 범위에서 Storage Blob 데이터 읽기 권한자/참여자(Storage Blob Data Reader/Contributor)와 같은 역할을 할당합니다.
• Key Vault(RBAC 데이터 평면 모델)의 경우, Key Vault 비밀 사용자(Key Vault Secrets User) 또는 Key Vault 암호화 책임자(Key Vault Crypto Officer)와 같은 역할을 할당합니다.
• 애플리케이션 권한을 통한 Microsoft Graph의 경우, 앱 등록이 연결된 후에만 관리 ID가 다운스트림 API를 호출할 수 있습니다. 워크로드 ID 페더레이션(workload identity federation)을 사용하거나 필요에 따라 엔터프라이즈 앱 권한 및 관리자 동의를 구성합니다.

런타임 시, VM의 인스턴스 메타데이터 서비스(Instance Metadata Service, IMDS) 또는 App Service 관리 엔드포인트를 사용하여 토큰을 얻습니다. Azure Identity의 DefaultAzureCredential과 같은 SDK는 관리 ID 엔드포인트를 사용할 수 있을 때 자동으로 사용합니다. 이를 통해 비밀을 저장할 필요가 없으며 플랫폼에 의한 순환(rotation)을 지원합니다.

App Service 및 Azure Functions의 Key Vault 참조를 사용하면 코드 변경 없이 애플리케이션 설정으로 비밀을 안전하게 가져올 수 있습니다. 앱 설정 값에 참조 구문 @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version})를 사용합니다. 플랫폼은 시작 시 앱의 관리 ID를 사용하여 이 참조를 확인하고 주기적으로 새로 고칩니다. Key Vault 액세스 정책을 통해 또는 RBAC 데이터 평면 모델을 사용할 때 Key Vault 비밀 사용자(Key Vault Secrets User) 역할을 통해 관리 ID가 비밀에 대한 Get 권한을 가지고 있는지 확인해야 합니다. Key Vault 참조는 앱 구성 저장소 내에 일반 텍스트로 저장되어서는 안 되는 구성 값에 이상적이며, 애플리케이션 코드에서 비밀 처리 로직을 제거합니다.

Azure Key Vault: 비밀, 키, 인증서 및 액세스 제어

Azure Key Vault는 세 가지 유형의 객체를 저장합니다.

• 비밀(Secrets): 암호, 연결 문자열 또는 API 키와 같은 불투명한(opaque) 문자열입니다. 버전이 관리되며, 클라이언트는 일반적으로 Get 및 Set 작업을 수행합니다.
• 키(Keys): 서명/검증, 암호화/복호화, 래핑/언래핑 작업에 사용되는 암호화 키(RSA, EC)입니다. 키 물질은 HSM 기반 서비스에 의해 보호됩니다. 클라이언트는 개인 키 물질을 내보내는 대신 서비스를 통해 암호화 작업을 호출합니다.
• 인증서(Certificates): 수명 주기 관리가 포함된 X.509 객체로, 선택적으로 파트너 CA와 통합될 수 있습니다. 인증서는 인증서와 해당 비밀(PFX), 그리고 선택적으로 관리형 키로 구체화됩니다.

일시 삭제(Soft delete)는 기본적으로 활성화되어 있어 삭제된 객체를 보존 기간 동안 보존합니다. 제거 방지(purge protection)를 활성화하여 보존 기간 내에 되돌릴 수 없는 삭제를 방지하고 복구 보장을 강제합니다(종종 90일 보존 요구 사항). 엄격한 복구 정책을 충족하려면 일시 삭제와 제거 방지를 함께 사용합니다. 또한, 프라이빗 엔드포인트(private endpoint)로 자격 증명 모음 네트워크 액세스를 보호하고 가능한 경우 공용 네트워크 액세스를 비활성화합니다.

액세스 제어는 레거시 자격 증명 모음 액세스 정책 또는 데이터 평면용 Azure RBAC를 사용할 수 있습니다. 액세스 정책은 자격 증명 모음별로 구성되며 주체(principal)에게 명시적으로 권한(Get, List, Set, Sign, Wrap)을 부여합니다. 이 정책은 상속되지 않으며 대규모 환경에서는 운영 부담이 커질 수 있습니다. RBAC 데이터 평면 모델은 Azure 역할(예: Key Vault 관리자, Key Vault 비밀 책임자, Key Vault 비밀 사용자, Key Vault 암호화 책임자)을 사용하며, 구독, 리소스 그룹 또는 자격 증명 모음 수준에서 범위 지정을 지원하고 Azure RBAC에 감사 기능이 통합되어 있습니다. 하나의 모델을 선택해야 합니다. 데이터 평면에 RBAC가 활성화되면 액세스 정책은 무시됩니다. 관리 평면(management-plane) 작업(자격 증명 모음 생성/업데이트)은 항상 Azure RBAC를 사용합니다.

Azure SDK(예: SecretClient, KeyClient, CertificateClient)와 DefaultAzureCredential을 사용하여 Key Vault를 애플리케이션과 통합합니다. 인증에는 관리 ID를 사용하는 것을 선호하고, 자격 증명을 포함하지 않으며, Vault API를 호출할 때 재시도 및 제한(throttling) 정책을 구현합니다.

Azure Storage SAS와 저장된 액세스 정책

공유 액세스 서명(Shared Access Signatures)은 계정 키를 노출하지 않고 Azure Storage에 대한 세분화되고 시간 제한적인 액세스 권한을 위임합니다:

• 사용자 위임 SAS (Blob 전용): Azure AD를 기반으로 합니다. 앱이 Azure AD 자격 증명을 사용하여 Blob 서비스에서 사용자 위임 키를 얻은 다음, 클라이언트를 위한 SAS 토큰을 생성합니다. 이는 계정 키 사용을 피하고 역할 기반 권한 부여와 일치하므로 사용자 중심 시나리오에서 가장 안전한 접근 방식입니다.
• 서비스 SAS: 특정 리소스(blob, 컨테이너, 큐 메시지, 테이블 엔터티, 파일)로 범위가 지정됩니다. 계정 키로 서명됩니다. 서비스에 따라 읽기, 쓰기, 추가, 생성, 삭제, 목록, 불변성 설정, 태그와 같은 권한을 지원합니다.
• 계정 SAS: 여러 서비스(Blob, Queue, Table, File) 및 리소스 유형에 걸쳐 가장 넓은 범위를 가집니다. 영향 반경이 넓으므로 신중하게 사용해야 합니다.

SAS 토큰에는 만료 시간(se), 시작 시간(st), 권한(sp), IP 범위(sip), 허용된 프로토콜(spr), 서명된 리소스(sr), 그리고 저장된 액세스 정책에 바인딩될 때 사용되는 서명된 식별자(si)와 같은 제약 조건이 포함됩니다. 필요한 권한만 부여하고, 만료 기간을 짧게 유지하며, HTTPS(spr=https)를 강제하여 최소 권한 원칙을 따르십시오. 가능하면 사용자 위임 SAS를 선호하고, 그렇지 않은 경우 해지를 위해 저장된 액세스 정책과 함께 서비스 SAS를 사용하십시오.

저장된 액세스 정책은 컨테이너, 파일 공유, 큐 또는 테이블에 존재하며 재사용 가능한 제약 조건(권한, 시작, 만료) 집합을 정의합니다. SAS를 생성할 때 해당 식별자로 정책을 참조합니다. 이를 통해 모든 SAS 토큰을 재발급할 필요 없이 중앙에서 해지하거나 범위를 좁힐 수 있습니다. 정책을 업데이트하거나 삭제하면 연결된 모든 SAS 토큰에 즉시 영향을 미칩니다. 서비스 또는 계정 SAS를 사용하는 경우 계정 키를 정기적으로 순환하고, 진단 설정 및 Azure Monitor 로그를 통해 사용량을 모니터링하십시오.

실제 문제 시나리오

Adobe는 Azure에서 다중 테넌트 미디어 처리 포털을 출시하고 있습니다. 고객은 자신의 Microsoft Entra ID 테넌트로 로그인하고, 대용량 미디어 파일을 Blob 스토리지에 직접 업로드하며, 처리 상태를 추적합니다. 이 솔루션은 비밀 정보를 저장하지 않고, 권한을 중앙에서 관리하며, 최소 90일 동안 비밀 정보의 복구 가능성을 보장해야 합니다.

1. Microsoft Entra ID에 애플리케이션 등록:

   • 포털 UI용 SPA와 백엔드 API용 기밀 클라이언트를 생성합니다. 위임된 액세스를 위해 API 범위를 노출하고 백그라운드 작업을 위한 앱 역할을 정의합니다. 정확한 리디렉션 URI와 함께 권한 부여 코드 + PKCE를 사용하도록 SPA를 구성합니다. 이는 각 클라이언트를 올바른 OAuth 흐름에 맞추고 최소 권한 동의 경계를 강제합니다.

2. SPA와 백엔드에 MSAL 구현:

   • SPA는 증분 동의(incremental consent)와 함께 AcquireTokenInteractive/AcquireTokenSilent를 사용하여 백엔드 API용 토큰을 획득합니다. 백엔드는 AcquireTokenOnBehalfOf를 사용하여 Microsoft Graph를 호출하고 로그인한 사용자의 기본 프로필을 읽습니다. 이는 사용자 컨텍스트를 엔드투엔드로 유지하고 토큰 캐싱을 통해 프롬프트를 최소화합니다.

3. App Service(API) 및 Azure Functions(미디어 프로세서)에서 시스템 할당 관리 ID 활성화:

   • 미디어 컨테이너에는 Storage Blob 데이터 기여자 역할을, vault에는 Key Vault 비밀 사용자 역할을 할당합니다. 관리 ID는 비밀 정보의 무분별한 확산을 제거하고 플랫폼이 자격 증명을 자동으로 순환하도록 허용하는 동시에 Azure RBAC를 통해 Storage 및 Key Vault에 대한 보안 액세스를 가능하게 합니다.

4. RBAC 데이터 평면, 일시 삭제(soft delete), 제거 방지(purge protection) 기능으로 Azure Key Vault 구성:

   • 백엔드 어설션을 위한 서명 인증서, 타사 API 키 및 AAD로 대체할 수 없는 모든 연결 비밀 정보를 저장합니다. 90일 동안 복구를 보장하기 위해 일시 삭제와 함께 제거 방지를 강제합니다. RBAC는 감사를 단순화하고 vault별 액세스 정책에 비해 여러 환경에 걸쳐 확장하기 용이합니다.

5. 구성을 위해 Key Vault 참조 사용:

   • App Service 및 Functions 앱 설정에서 @Microsoft.KeyVault(SecretUri=…)를 사용하여 비밀 정보를 참조합니다. 플랫폼은 관리 ID를 사용하여 값을 확인하고 새로 고치므로 코드 변경이 필요 없고 비밀 정보가 일반 텍스트 구성에 저장되는 것을 방지합니다.

6. SAS를 사용하여 직접 브라우저 업로드 위임:

   • 백엔드는 IP 및 HTTPS로 범위가 지정된 특정 blob 경로에 대한 단기 쓰기 전용 액세스를 위해 사용자 위임 SAS 토큰을 발급합니다. 운영 배치 도구의 경우, 컨테이너의 저장된 액세스 정책에 연결된 서비스 SAS를 생성하여 정책을 업데이트하거나 삭제함으로써 토큰을 중앙에서 해지할 수 있도록 합니다. 이를 통해 계정 키를 노출하지 않고도 처리량이 높은 클라이언트 업로드가 가능하며 비상시 해지를 지원합니다.

7. Microsoft Graph 최소한으로 통합:

   • SPA에서는 프로필 표시를 위해 https://graph.microsoft.com/User.Read를 요청하고, 애플리케이션 권한이 필요한 경우(사전 관리자 동의 필요) 백엔드에서 https://graph.microsoft.com/.default를 사용합니다. /.default를 사용하면 백엔드가 중앙에서 부여된 애플리케이션 권한을 존중하고 런타임에 범위를 과도하게 요청하는 것을 방지할 수 있습니다.

이 설계는 권한 부여 코드 + PKCE를 사용하여 SPA를 보호하고, OBO를 사용하여 다운스트림에서 사용자 컨텍스트를 유지하며, 관리 ID와 RBAC를 사용하여 비밀 정보를 제거하고, 강력한 복구 보장 기능이 있는 Key Vault를 사용하고, 구성 위생을 위해 Key Vault 참조를 사용하고, 최소 권한 범위를 가진 Graph를 사용하며, 안전하고 해지 가능한 클라이언트 업로드를 위해 저장된 액세스 정책과 함께 SAS를 사용합니다.

← Azure 컨테이너 솔루션 · 모든 도메인 · Azure API 관리 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Microsoft 찾아보기 →