Microsoft AZ-500: 애플리케이션 보안 및 DevSecOps — 학습 가이드

By Laurynas Brazys · 12 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

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

개요

Azure의 애플리케이션 보안 및 DevSecOps는 ID 오용 방지, 인그레스 및 API 보호, 파이프라인에서의 보안 조기 적용(shift-left), 저장 및 전송 중인 비밀 보호, 강력한 릴리스 거버넌스 적용에 중점을 둡니다. 효과적인 설계는 수명이 긴 비밀을 제거하고, 최소 권한을 사용하며, 모든 호출자를 검증하고, 코드, 종속성, 인프라 및 런타임 전반에 걸쳐 지속적인 탐지 및 수정을 제도화합니다.

보안 애플리케이션 ID, 인그레스 및 API 보호

Microsoft Entra ID(Azure AD)의 보안 애플리케이션 ID는 범위가 잘 지정된 앱 등록과 올바른 OAuth 2.0 흐름에서 시작됩니다.

• 위임된 권한은 사용자가 로그인했을 때 적용되며, 동의는 확인된 게시자 앱이나 관리자가 승인한 범위로만 제한될 수 있습니다. 애플리케이션 권한(앱 전용)은 사용자가 없는 상태에서 작동하는 백그라운드 데몬이나 서비스를 인증하므로 항상 관리자 동의가 필요합니다.
• 필요한 최소한의 범위나 애플리케이션 역할만 부여하고 동의 요청에 대한 관리자 검토를 요구하여 최소 권한을 적용합니다. 최종 사용자 동의를 비활성화하거나, 동의 피싱을 줄이기 위해 위험이 낮은 확인된 게시자에 대해서만 허용합니다.
• 클라이언트 비밀보다 인증서 자격 증명이나 페더레이션 ID를 선호합니다. 인증서는 더 강력한 보증과 예측 가능한 교체를 지원합니다. 짧은 수명을 구성하고 교체를 자동화합니다. 필요한 경우가 아니면 공용 클라이언트 흐름을 차단합니다.
• Azure 서비스의 경우 앱 비밀 대신 관리 ID를 사용합니다. Key Vault Secrets User 또는 Storage Blob Data Reader와 같은 데이터 평면 역할을 할당하고, 해당하는 경우 Private Endpoint를 사용하여 네트워크 액세스를 제한합니다.

Application Gateway WAF v2 및 Azure Front Door WAF는 OWASP Top 10 위협으로부터 공용 인그레스를 보호합니다.

• 최신 Microsoft 관리형 OWASP Core Rule Set을 활성화하고 튜닝 후 방지 모드(Prevention mode)에서 실행합니다. 학습 중 오탐(false positive)을 줄이기 위해 초기에는 이상 점수(anomaly scoring)를 사용합니다.
• 지역 제한(geofencing), IP 평판 기반 차단, 헤더 적용, 요청 크기 제한을 위한 사용자 지정 규칙을 구성합니다. Front Door의 경우, 클라이언트 IP별로 속도 제한(rate-limit) 규칙을 추가하여 크리덴셜 스터핑(credential stuffing) 및 기본적인 L7 DoS 공격을 완화합니다.
• 강력한 암호 그룹(cipher suite) 및 정책으로 TLS를 종료하고, 오리진까지 엔드투엔드 TLS를 사용합니다. mTLS가 필요한 시나리오의 경우, Application Gateway 리스너에서 클라이언트 인증서 유효성 검사를 구성합니다.
• WAF 정책을 리스너/경로에 정확하게 연결하고, 오탐을 완전히 이해한 경우에만 규칙 제외를 사용합니다. 탐지 엔지니어링 및 인시던트 대응을 위해 WAF 로그를 Log Analytics로 스트리밍합니다.

API Management(APIM)는 다계층 보안 태세를 적용합니다.

• 게이트웨이에서 엄격한 발급자(issuer), 대상(audience), 범위(scope) 검사를 통해 OAuth 토큰의 유효성을 검사합니다. 모든 곳에서 HTTPS를 요구하고 클라이언트 신뢰 경계에 필요할 경우 mTLS를 적용합니다.
• 심층 방어(defense-in-depth) 및 ID 제한(throttling)을 위해 구독 키를 OAuth와 결합합니다. 제품 수준 구독 키를 사용하여 소비자를 분할하고 다른 사용자에게 영향을 주지 않으면서 키를 교체합니다.
• 소비자별, 범위별 또는 구독별 세분성으로 속도 제한 및 할당량을 적용합니다. 적절한 경우 IP 필터링을 사용하여 파트너 네트워크를 허용 목록에 추가합니다.
• 상호 TLS(mutual TLS) 또는 관리 ID를 사용하여 백엔드 서비스를 보호합니다. 구성 내 일반 텍스트를 피하기 위해 비밀을 Key Vault 참조를 기반으로 하는 명명된 값(Named Values)으로 저장합니다.

JWT 범위 적용 및 제한을 위한 APIM 정책 예시:

<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://your-api-app-id</audience>
      </audiences>
      <required-claims>
        <claim name="scp">
          <value>read.items</value>
        </claim>
      </required-claims>
    </validate-jwt>
    <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription?.Key ?? context.Request.IpAddress)" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

DevSecOps 파이프라인 강화 및 Defender for DevOps

Azure DevOps 및 GitHub Actions는 수명이 긴 비밀 없이 Azure에 인증해야 합니다.

• 서비스 연결에 워크로드 ID 페더레이션(OIDC)을 사용합니다. Entra ID에서 앱 등록/서비스 주체를 생성한 다음, 리포지토리, 브랜치, 워크플로/환경을 ID에 바인딩하는 페더레이션 자격 증명을 추가합니다. 이를 통해 저장된 비밀 없이 수명이 짧은 토큰을 얻을 수 있으며 Azure RBAC를 통한 최소 권한 범위 지정을 지원합니다.
• 파이프라인 권한을 잠급니다: 서비스 연결 사용에 승인을 요구하고, 파이프라인을 보호된 브랜치로 제한하며, 필요한 경우가 아니면 “스크립트가 OAuth 토큰에 액세스하도록 허용"을 비활성화합니다. 마스킹 기능이 있는 변수 그룹과 비밀을 사용하고, 로깅 명령을 통한 비밀 에코를 허용하지 않습니다. GitHub에서는 중앙 집중식 제어를 위해 리포지토리 비밀보다 환경 및 조직 비밀을 선호하고, 해당하는 경우 호스팅된 러너에서 “로그에 비밀 방지” 설정을 사용합니다.
• 환경 보호 규칙을 적용합니다: 필수 검토자, 검사(예: 변경 관리 티켓, 테스트 통과), 시간 기반 승인.

Azure CLI로 페더레이션 자격 증명 생성 (GitHub OIDC 예시):

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"github-oidc-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:org/repo:ref:refs/heads/main",
    "audiences":["api://AzureADTokenExchange"]
  }'

Microsoft Defender for DevOps는 Azure Repos 및 GitHub와 통합되어 다음을 표시합니다.

• 일반적인 언어의 코드 보안 결과(SAST); 풀 리퀘스트 주석은 회귀(regression)를 방지하기 위해 새로운 문제를 강조 표시합니다.
• OSS 라이브러리에 대한 취약점 인텔리전스를 사용한 종속성 위험(SCA)과 해결 지침 및 수정된 버전.
• 유출된 토큰/키에 대한 비밀 노출 탐지 및 권장 교체.
• 정책 기반 거버넌스 및 드리프트 추적을 통한 ARM/Bicep/Terraform 전반의 코드형 인프라(Infrastructure-as-Code)의 잘못된 구성(예: 공용 스토리지, 허용 범위가 넓은 NSG). 결과는 리포지토리 및 파이프라인 컨텍스트와 함께 Defender for Cloud로 롤업되어 우선순위를 지정하는 데 사용됩니다. 심각도 임계값을 기반으로 릴리스를 제어하여 안전하지 않은 배포를 중지합니다.

비밀 관리 및 플랫폼 통합

Key Vault는 포괄적인 제어 기능을 통해 중앙에서 비밀, 키, 인증서를 관리합니다:

• 파괴적인 손실을 방지하기 위해 제거 방지(purge protection) 및 일시 삭제(soft delete)를 적용합니다. 통합된 권한 부여를 위해 액세스 정책보다 RBAC를 선호하고, 가능한 경우 Private Endpoint를 활성화하고 공용 네트워크 액세스를 비활성화하며, 보안 작업 영역으로 로깅을 활성화합니다.
• App Service와 Functions는 관리형 ID를 사용하여 앱 설정에서 Key Vault 참조를 사용하며, 재배포 없이 투명하게 비밀을 순환시킵니다.
• AKS는 Azure AD Workload Identity(권장)로 인증된 Azure Key Vault 공급자와 함께 Secrets Store CSI Driver를 통해 런타임에 비밀을 검색합니다. Kubernetes Secret 개체에 평문 비밀을 저장하지 마십시오.

App Service Key Vault 참조 예시:

Name: DbConn
Value: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnString/23a1...)

AKS SecretProviderClass (요약):

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    useWorkloadIdentity: "true"
    keyvaultName: kv-prod
    tenantId: <tenant-id>
    objects: |
      array:
        - | 
          objectName: api-key
          objectType: secret

파이프라인은 작업 런타임에 비밀을 가져와야 합니다:

• Azure DevOps: 관리형 ID 기반 서비스 연결과 함께 Key Vault 작업을 사용하고, 비밀 다운로드를 최소한의 스테이지로 제한합니다.
• GitHub Actions: OIDC를 위한 azure/login 및 필요한 이름만 가져오기 위한 azure/keyvault를 사용합니다.

보안 SDLC, 컨테이너, 로깅 및 릴리스

보안 SDLC 관행은 배포 전에 위험을 줄입니다:

• STRIDE 또는 동등한 방법을 사용하여 초기에 위협 모델링을 수행하면 인증, 권한 부여 및 데이터 흐름을 명시적으로 검증할 수 있습니다. 아키텍처가 발전함에 따라 모델을 업데이트합니다.
• SAST는 모든 PR에서 실행하고, 심각도가 높은 문제 발생 시 명확한 담당자와 함께 빌드를 중단시킵니다. DAST는 안전한 테스트 데이터가 있는 스테이징 슬롯/환경에 배포 후 실행됩니다.
• SCA는 패키지를 지속적으로 모니터링하고, 고정된 버전 사용 및 라이선스 준수를 의무화합니다.
• 분기 정책을 통한 엄격한 코드 검토: 필수 검토자, 연결된 작업 항목, 빌드 유효성 검사 및 서명된 커밋.

컨테이너 이미지 보안은 공급망 무결성의 기초입니다:

• 빌드 중에 SBOM(SPDX 또는 CycloneDX)을 생성 및 저장하고, 추적 가능성을 위해 OCI 아티팩트로 이미지와 함께 게시합니다.
• Defender for Cloud의 컨테이너 스캐닝을 사용하여 푸시 전 및 레지스트리에 저장된 이미지를 스캔하고, 치명적인 발견 사항이 있을 경우 승격을 차단합니다.
• cosign을 사용하여 Notary v2/OCI 아티팩트로 이미지와 증명을 서명합니다. 어드미션 시(예: Kubernetes용 Gatekeeper/OPA 또는 AKS Policy) 서명 확인을 강제합니다.
• Azure Container Registry(ACR)의 레지스트리 제어: 관리자 사용자를 비활성화하고, Private Endpoints를 통해 네트워크를 제한하며, 고객 관리형 키를 활성화하고, 세분화된 액세스를 위해 리포지토리 범위 토큰을 사용하며, 보존 및 격리 패턴을 적용합니다. 런타임에는 AcrPull 권한만 부여하고 CI에는 AcrPush 권한만 부여합니다. AKS의 경우, 수동 역할 구성 대신 지원되는 명령으로 ACR을 연결하여 올바른 할당을 생성합니다.
• 컨테이너가 VM 호스트에서 VNet 서비스 엔드포인트를 사용해야 하는 경우, 지원되는 CNI 플러그인을 설치하여 컨테이너별 트래픽이 서브넷에서 발생하도록 합니다.

애플리케이션 로깅은 비밀이나 개인 식별 정보(PII)를 유출해서는 안 됩니다:

• Telemetry Processors를 사용하여 민감한 필드를 수정하거나 삭제하도록 Application Insights를 구성하고, 비밀이나 PII가 포함된 원시 헤더, 토큰 또는 페이로드를 로깅하지 마십시오. 데이터 필드를 비즈니스 요구 사항으로 제한하고 샘플링을 활성화하여 노출을 줄입니다.
• 진단 데이터를 엄격한 RBAC(최소 권한으로 Log Analytics Reader)가 적용된 전용 Log Analytics 작업 영역으로 라우팅하고, Storage로 내보낼 때 불변 스토리지(시간 기반 보존 잠금)를 사용합니다.
• 사용 가능한 경우 Private Link로 원격 분석 수집 및 쿼리 엔드포인트를 보호합니다. 계측 연결 문자열을 Key Vault에 저장하고 정기적으로 순환시킵니다.

안전한 릴리스 관행은 통제된 승격을 강제합니다:

• Azure DevOps Environments 또는 GitHub Environments의 승인 게이트는 지정된 검토자, 품질 검사 통과 및 변경 티켓을 요구합니다. 고위험 배포에 대한 보류 기간(hold-back windows)을 자동화합니다.
• 서비스 연결 및 에이전트에 최소 권한 원칙을 적용하고, 환경별로 리소스 그룹 또는 구독으로 범위를 지정합니다. 좁은 범위의 역할을 가진 관리 ID를 사용합니다.
• 개발, 테스트, 프로덕션 환경을 별도의 구독, VNet, Key Vault 및 ACR로 분리하고, 환경 간 측면 이동을 허용하지 않으며 각 환경에서 다른 비밀/키를 사용합니다.

실용적인 문제 시나리오

Fabrikam, Inc.는 멀티테넌트 SaaS API를 인터넷에 게시하려고 합니다. 요구 사항: OWASP Top 10 공격 차단, 작업별 OAuth 범위 검증, 리포지토리 내 비밀 저장 방지, 악의적인 클라이언트 제한, 프로덕션 환경에서 서명된 컨테이너 이미지만 실행되도록 보장.

1. 프런트엔드 및 WAF

• 최신 OWASP 관리형 규칙 집합을 사용하는 WAF 정책을 방지(Prevention) 모드로 설정하고, 사용자 지정 속도 제한 규칙 및 지역 차단을 추가하여 Azure Front Door Standard를 배포합니다. 근거: 중앙 집중식 글로벌 에지 적용은 공격 표면을 줄이고 L7 공격이 오리진에 도달하기 전에 흡수합니다.

2. API 게이트웨이 정책

• Azure API Management를 Front Door 뒤에 배치하고, 작업별로 발급자/대상/범위 검사를 포함한 validate-jwt를 구현하며, 할당량이 있는 제품 수준 구독 키를 사용합니다. 근거: APIM은 ID 인식 적용 및 테넌트 격리를 제공하며, 키와 OAuth는 계층화된 방어와 정밀한 제한을 제공합니다.

3. ID 및 동의

• 사용자 흐름을 위한 위임된 범위와 데몬을 위한 애플리케이션 역할을 사용하여 SPA 및 데몬 앱을 Entra ID에 등록합니다. 사용자 동의를 확인된 게시자로 제한하고 앱 권한에 대해 관리자 동의를 요구합니다. 데몬에는 인증서 자격 증명을 사용합니다. 근거: 취약한 비밀을 제거하고, 최소 권한을 강제하며, 동의 피싱 노출을 줄입니다.

4. OIDC를 사용한 DevSecOps

• GitHub Actions가 OIDC 페더레이션을 사용하도록 구성하여, 빌드용으로는 비프로덕션 구독에 범위가 지정된 Azure 서비스 주체에, 릴리스용으로는 프로덕션 범위의 주체에 연결합니다. 각 주체에는 최소한의 역할(빌드용 AcrPush, 릴리스용 프로덕션 RG로 제한된 Contributor)을 부여합니다. 근거: 저장된 비밀이 없으며, 환경별로 폭발 반경이 최소화됩니다.

5. 컨테이너 공급망

• ACR Tasks를 통해 이미지를 빌드하고, SBOM(CycloneDX)을 생성하며, cosign으로 이미지에 서명합니다. 증명은 OCI 아티팩트로 저장합니다. 유효한 서명을 요구하도록 정책을 사용하여 AKS 어드미션을 구성합니다. 근거: 배포 시 출처와 무결성을 검증할 수 있어 변조된 이미지를 차단합니다.

6. 레지스트리 및 런타임 제어

• ACR 관리자 사용자를 비활성화하고, Private Endpoint를 활성화하며, 지원되는 attach-acr 흐름을 통해 AKS kubelet ID에 AcrPull을 할당하고, Defender for Cloud 이미지 스캐닝을 활성화합니다. 근거: 네트워크 및 ID 강화는 기본 백도어를 제거하고, 스캐닝은 런타임 전에 알려진 CVE를 탐지합니다.

7. 비밀 및 구성

• Private Endpoint 및 RBAC와 함께 Key Vault를 사용합니다. App Service 및 Functions는 Key Vault 참조를 사용하고, AKS는 Workload Identity와 함께 Secret Store CSI를 사용합니다. 근거: 비밀이 리포지토리나 앱 구성에 절대 저장되지 않으며, 순환이 중앙에서 관리되고 감사 가능합니다.

8. 릴리스 거버넌스

• 필수 검토 및 검사를 통해 GitHub main 브랜치를 보호합니다. 프로덕션 배포 전에 환경 승인 및 보안 게이트(치명적인 SAST/SCA/IaC 발견 사항 없음) 통과를 요구합니다. 근거: 검증되고 안전한 빌드만 진행되도록 보장하며, 고위험 변경에 대해서는 사람의 감독이 유지됩니다.

9. 관찰 가능성 위생

• 사용자 지정 Telemetry Processors로 PII를 수정하도록 Application Insights를 구성하고, WAF/APIM 진단 데이터를 최소 권한의 Reader 액세스가 적용된 보안 Log Analytics 작업 영역으로 라우팅합니다. 근거: 민감한 데이터를 노출하지 않고 포렌식 가치를 보존하며, 액세스는 감사 가능하고 제한됩니다.

← Microsoft Sentinel 및 보안 운영 · 모든 도메인 · 하이브리드 및 멀티 클라우드 보안 →

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

Microsoft 찾아보기 →