Azure Key Vault

Azure Key Vault는 클라우드 애플리케이션에서 비밀값(Secrets), 암호화 키(Keys),

**인증서(Certificates)**를 안전하게 저장하고 중앙에서 관리할 수 있게 해주는 핵심 보안 서비스입니다.

Azure 관리자나 개발자 관점에서 자주 마주치는 핵심 주제 6가지를 정리하면 아래와 같습니다.

---

✅ 1. Key Vault의 구성 요소 요약

구성 요소	설명	예시
Secrets	문자열 기반 민감 데이터 저장	DB 비밀번호, API 키, SAS 토큰
Keys	암·복호화/서명에 사용되는 키	RSA 키, HSM 키
Certificates	인증서와 키를 함께 저장	SSL 인증서

---

✅ 2. 주요 사용 시나리오

상황	Key Vault 활용
환경 변수 보안 관리	앱 구성 값을 Secret으로 저장
Azure Function 비밀값 참조	코드에 직접 키 노출 없이 Key Vault에서 가져옴
SSL 인증서 자동 갱신	인증서를 저장하고 만료 전 자동 롤오버 설정
디스크/데이터 암호화	고객 제공 키(CMK)로 암호화 키 관리

 

---

✅ 3. Key Vault 액세스 제어 방식 2가지

방식	설명	사용 위치
Access Policy	Key Vault에 특화된 정책 (기존 방식)	전통적인 접근 방식
RBAC	Azure Role 기반 권한 설정 (신규 권장 방식)	조직적 권한 통합 필요 시

Tip: 신규 프로젝트는 가능하면 RBAC 방식 권장 (관리 일관성 ↑)

---

✅ 4. 애플리케이션에서 Key Vault 사용 방식

방법	기술
Azure SDK (Python, Node, etc.)	코드에서 직접 비밀값을 가져옴
Managed Identity 사용	인증 없이 안전하게 접근 가능 (추천)
App Service / Function 설정	@Microsoft.KeyVault(SecretUri=...) 문법으로 참조
Azure CLI / PowerShell	명령줄에서 비밀 조회 및 관리 가능

---

✅ 5. Key Vault + Managed Identity 연동

애플리케이션 코드에 Key Vault 이름, 클라이언트 ID, 비밀을 절대 하드코딩하지 않는다.

✅ 구성 흐름

App (Function/App Service) → Managed Identity → Key Vault → Secret 반환

 

🔒 설정 요약

1. 앱에 시스템 할당 Managed Identity 활성화
2. Key Vault에 해당 ID에게 Get Secret 권한 부여
3. 앱에서 SDK나 Azure.Identity 라이브러리로 Key Vault 요청

---

✅ 6. 자주 출제되거나 실무에서 필요한 사항 요약

항목	설명
Secret은 버전 관리됨	변경 시 자동으로 새 버전 생성됨
Soft-delete 기본 활성화	삭제 후 복구 가능 (30~90일)
Key Vault는 지역 기반 리소스	동일 Azure 리전에 배치하는 것이 성능상 유리
RBAC 전환 시 Access Policy는 무시됨	둘 다 설정하면 RBAC만 유효
Key Vault는 로깅/모니터링 가능	Azure Monitor + Diagnostic 설정 필수

---

📌 실무 Tip 요약

설명	최적 방식
인증 키 보안 유지	Key Vault + Managed Identity
비밀값 자동 참조	App Configuration과 통합
암호화 키 제어	Customer Managed Key(CMK) + Azure Disk Encryption
민감 로그 방지	Application Insights에 비밀 노출되지 않도록 마스킹 필요

 

 

---

 

✅ AZ-104: Azure Key Vault 관련 예상 질문 & 답변 30제

No.	질문	정답	해설
1	Key Vault에서 앱 비밀번호 저장 시 사용할 항목은?	Secret	비밀번호, 연결 문자열 등은 Secret으로 저장
2	VM에서 Key Vault Secret 접근 설정은?	Managed Identity	VM에 시스템 할당 ID 설정 후 권한 부여
3	Azure Function에서 Key Vault 접근 권장 인증 방식은?	Managed Identity	앱 코드 내 자격 증명 저장 없이 안전하게 접근
4	Key Vault 삭제 후 복구하려면 필요한 기능은?	Soft-delete	기본 활성화됨, 복원 가능
5	Key Vault 로그 수집 시 사용되는 서비스는?	Azure Monitor(Log Analytics)	진단 설정 통해 로그 흐름 설정
6	사용자에게 Secret 읽기 전용 권한만 줄 때 사용하는 역할은?	Key Vault Secrets User (RBAC)	Secret read만 허용
7	사용자 직접 키 제어 방식은?	Customer-managed key (CMK)	사용자가 Key Vault에 키를 관리
8	Key Vault의 리전 간 복제에 사용하는 기능은?	Geo-replication	고가용성 목적의 백업 리전
9	Access Policy 방식에서 Secret 읽기 권한 이름은?	get	get, list 권한 설정 필요
10	Reader 역할은 Secret 읽기 가능 여부?	불가	Key Vault 메타 정보만 읽기 가능
11	Soft-delete 된 Key Vault 완전 삭제는 어떻게 하나요?	Purge	az keyvault purge 또는 포털에서 수행
12	CLI로 Secret 등록 명령어는?	az keyvault secret set	--vault-name, --name, --value 필수
13	인증서 자동 갱신을 위한 설정은?	Key Vault 인증서 등록 + CA 연동	Key Vault에서 CA 연결 설정
14	@Microsoft.KeyVault(SecretUri=...) 사용 시 필요한 조건은?	Managed Identity + 권한 설정	웹앱에 MI 부여 및 Secret get 권한
15	Key Vault로 Storage 암호화 키 제공 방식은?	CMK (Customer Managed Key)	Storage 계정에 CMK 설정 필요
16	기본 네트워크 접근 설정은?	Public (기본 허용)	필요 시 프라이빗 엔드포인트 적용
17	az keyvault set-policy 필수 인수는?	Vault name, Object ID, Permissions	세 가지 모두 필요
18	Purge Protection 기능은 어떤 역할을 하나요?	영구 삭제 방지	Soft-delete 후도 복원 가능하게 보호
19	여러 앱에서 하나의 Key Vault를 사용할 경우 권한 부여 방법은?	RBAC 사용 + 각각 MI 할당	앱 단위 보안 제어
20	Secret 접근 실패 시 확인할 리소스는?	Activity Log, 진단 로그	접근 거부 사유 분석에 사용
21	Secret 버전 관리가 필요한 이유는?	롤백 및 추적	각 변경 시 버전이 자동 생성됨
22	Key Vault를 사전 승인된 IP에서만 접근하려면?	방화벽 + 가상 네트워크 제한 설정	NSG + VNet 통합
23	RBAC 기반 Key Vault 관리 시 전체 권한 역할은?	Key Vault Administrator	Secret, Key, Cert 전체 권한
24	인증서 저장 시 실제 저장되는 항목은?	Secret + Key + Cert 메타	Key Vault 내부에 분리 저장됨
25	RBAC 방식과 Access Policy 방식의 차이점은?	관리 대상과 범위의 차이	RBAC는 Azure Role, AP는 Key Vault 고유
26	Key Vault의 Name 중복이 발생할 수 있는 경우는?	전역 고유 이름, 삭제 후 Soft-delete 기간 중 재사용 불가	Name은 global namespace
27	CLI로 Secret 값 JSON 파일에서 주입 시 사용하는 옵션은?	--value "$(cat file.json)"	Bash 처리 필요
28	Secret 값에 암호화된 텍스트를 저장하고 싶을 때 사용하는 Key Vault 기능은?	암호화 Key 활용 (wrap/unwrap)	Key를 통한 암호화/복호화 수행
29	Key Vault의 특정 Secret을 URI 형태로 참조할 때 쓰는 속성은?	Secret Identifier (URL)	앱에서 직접 참조 가능
30	Terraform 등 Infra as Code로 Key Vault 구성 시 필수적으로 지정해야 하는 항목은?	Access policy 또는 RBAC + soft-delete 설정	자동화 시 보안 및 복구 설정 고려 필수

---

🔍 학습 포인트 요약

• 권한 부여 방식: RBAC vs Access Policy 이해
• Managed Identity 활용: 앱과 Key Vault 연결의 핵심
• 실행 명령어: az keyvault, az keyvault secret set, az keyvault set-policy 등 CLI 명령어 익숙해지기
• 보안 설정: Soft-delete, Purge protection, 방화벽, VNet 통합 이해
• 활용 시나리오: App Service, Azure Function, Logic App 등에서의 통합 사용 흐름

---

 

---

Q1: Key Vault를 Private Endpoint와 함께 사용하는 경우, DNS 구성을 어떻게 해야 앱에서 정상적으로 접근할 수 있나요? 

Key Vault를 Private Endpoint와 함께 사용하는 경우, Azure 내부 또는 온프레미스 네트워크에서 Key Vault의 전용 사설 IP를 사용하여 접근하게 됩니다. 이때 가장 중요한 요소는 DNS 구성이며, 다음과 같은 단계로 정확히 설정해야 앱에서 정상적으로 Secret 등에 접근할 수 있습니다.

---

✅ Private Endpoint 사용 시 Key Vault DNS 구성 방법

🎯 목표

Key Vault의 vault.azure.net 도메인이 사설 IP로 올바르게 매핑되어야 함.

---

🔹 1단계: Key Vault에 Private Endpoint 연결 생성

• Key Vault 리소스 → Networking → Private endpoint connections
• 신규 Private Endpoint 생성
  • 대상 VNet, Subnet 지정
  • DNS 통합 필요 여부 확인

---

🔹 2단계: Private DNS Zone 연결 확인

• Azure는 기본적으로 다음과 같은 Private DNS Zone을 사용합니다:
• privatelink.vaultcore.azure.net
• 이 DNS Zone이 자동 생성되었는지 확인하고, 연결된 VNet이 포함되었는지 점검합니다.

---

🔹 3단계: DNS 레코드 확인 및 테스트

• 해당 DNS Zone 내에 다음과 같은 A 레코드가 자동으로 등록되어야 합니다:
• <your-keyvault-name>.vault.azure.net → Private IP
• Azure 내부에서 nslookup 또는 dig 명령어로 확인:결과가 Private IP여야 정상 구성됨.
• nslookup <your-keyvault-name>.vault.azure.net

---

🔹 4단계: Azure 외부/온프레미스 DNS 포워딩 구성 (필요 시)

• 온프레미스 또는 자체 DNS 서버가 있다면 다음 구성 필요:
  • vault.azure.net 도메인 요청을 Azure DNS Forwarder로 전달
  • 또는 privatelink.vaultcore.azure.net 존에 대해 Conditional Forwarding 설정

---

🔹 5단계: App 또는 리소스에서 정상 접근 테스트

• App Service / Function / VM에서 Key Vault Secret을 불러오는 테스트 수행
• Key Vault에 대한 방화벽 설정은 Private endpoint만 허용되어 있어야 함

---

💡 참고: Key Vault 네트워크 설정 팁

설정 항목	추천값
Public Access	Disabled
Private Endpoint	Enabled
DNS Zone	privatelink.vaultcore.azure.net
Azure DNS 통합	자동 등록 확인 (혹은 수동 등록)
Name Resolution	App이 있는 VNet에서 사설 DNS 적용되어야 함

---

✳️ 문제 예시 (시험 스타일)

Azure VM이 Key Vault에서 Secret을 읽지 못하고 있습니다. VM과 Key Vault는 동일한 VNet에 있고 Private Endpoint는 구성되었습니다. 가장 먼저 확인해야 할 것은 무엇인가요?

정답:
→ vault.azure.net 도메인이 사설 IP로 매핑되었는지 DNS 레코드를 확인

---

 

---

 

Q2: Key Vault의 Secret을 GitHub Actions 또는 Azure DevOps 파이프라인에서 안전하게 가져오려면 어떤 인증 방식이 가장 효율적일까요?

 

GitHub Actions 또는 Azure DevOps 파이프라인에서 Key Vault의 Secret을 안전하게 가져오는 가장 효율적인 인증 방식은 Azure AD 애플리케이션 등록을 통한 서비스 주체 (Service Principal) 인증 방식입니다. 필요 시 **Federated Identity Credential (OIDC 방식)**을 함께 사용하면 비밀 키 저장 없이 안전한 인증이 가능합니다.

---

✅ Key Vault Secret 안전 접근 방식 (CI/CD 환경)

🎯 목표

파이프라인에서 비밀 저장 없이, Key Vault에 인증된 접근을 허용

---

🔹 1. 기본 구조 선택

옵션	설명	보안성	비고
Service Principal + Client Secret	SP 등록 후 Client ID/Secret 사용	보통	비밀 저장 필요
Service Principal + Certificate	SP에 인증서 등록 후 인증	높음	운영 복잡
Federated Identity Credential (OIDC) ✅ 추천	Client secret 없이 GitHub Token → Azure 인증	매우 높음	비밀 저장 필요 없음

---

🔹 2. GitHub Actions 에서의 구현 예시 (OIDC 방식)

1. Azure AD App 등록 + Federated Credential 설정
   • Azure AD에서 앱 등록
   • Federated credentials 메뉴에서 GitHub repo와 branch 정보 추가
2. Key Vault RBAC 권한 부여
   • 등록된 App에 Key Vault Secrets User 또는 Key Vault Reader 역할 할당
3. GitHub Actions 워크플로우 구성

permissions:
  id-token: write
  contents: read

jobs:
  keyvault:
    runs-on: ubuntu-latest
    steps:
      - name: Azure 로그인 (OIDC)
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          enable-AzPSSession: true

      - name: Key Vault에서 Secret 가져오기
        uses: azure/get-keyvault-secrets@v1
        with:
          keyvault: 'my-keyvault-name'
          secrets: 'MY-SECRET-NAME'

---

🔹 3. Azure DevOps 에서의 구현 (Service Connection 방식)

• Azure DevOps에서는 Service Connection을 생성하여 SP를 연결
• 해당 SP에 Key Vault 접근 권한 부여
• 파이프라인 내에서는 AzureKeyVault@2 Task 사용:

- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'MyServiceConnection'
    KeyVaultName: 'my-keyvault-name'
    SecretsFilter: 'MY-SECRET-NAME'
    RunAsPreJob: true

---

🔐 보안 Best Practice 요약

방법	장점	위험
OIDC (Federated Identity) ✅	키 없이 인증, 보안성 최상	구현 복잡도 약간 있음
SP + Secret	구현 쉬움	키 유출 위험
SP + Certificate	높은 보안	운영 복잡
환경 변수 내 Secret 저장	간편	취약점 많음, 지양

---

💡 팁: RBAC 권한

역할	권한
Key Vault Reader	전체 읽기 (Key 포함)
Key Vault Secrets User ✅	Secret만 읽기
Key Vault Administrator	전체 제어 (쓰기 포함)

---

 

---

Q3: 여러 리소스가 한 Key Vault를 공유할 경우, Secret 이름 충돌이나 보안 이슈를 방지하는 설계 전략은 어떻게 해야 하나요?

 

여러 Azure 리소스(예: Web App, Function, Logic App 등)가 하나의 Key Vault를 공유할 경우, 가장 흔히 발생하는 두 가지 문제는 다음과 같습니다:

1. Secret 이름 충돌: 서로 다른 리소스가 동일한 이름의 Secret을 사용하려 할 때 충돌 발생
2. 권한 범위 과다: 하나의 리소스가 모든 Secret을 볼 수 있게 되는 과도한 권한 설정

이를 방지하기 위한 설계 전략은 다음과 같습니다.

---

✅ Key Vault 공유 시 안전한 설계 전략

🔹 1. Secret 네이밍 규칙 전략화

전략	예시	설명
접두사 방식	app1-db-password, app2-db-password	리소스 또는 앱 이름을 Secret 접두사로 사용
디렉터리 스타일 구분	app1/env/db-pass	Secret 이름에 논리적 경로 표현
기능 기반 네이밍	invoice-api-sql, auth-api-key	마이크로서비스/기능 단위 명명

🎯 비슷한 이름끼리 그룹핑되며 관리도 쉬워짐

---

🔹 2. Key Vault를 RBAC 기반으로 운영 (Access Policy는 지양)

• Access Policy는 Secret 단위 제어 불가 → RBAC를 사용할 것
• 리소스별로 Secret 이름 패턴 기반 접근만 허용

역할	범위 설정
Key Vault Secrets User	특정 리소스 그룹 또는 리소스 수준
Scoped Role Assignment	리소스당 최소 권한 설정 가능

---

🔹 3. Key Vault를 논리적으로 분할 또는 계층화

설계 방식	설명	사용 예
단일 Key Vault + 네이밍 규칙	간단한 소규모 프로젝트	소규모 개발팀
서비스별 Key Vault 분리	마이크로서비스 또는 프로젝트별 분리	다수 팀 협업 시
환경별 분리 (dev/test/prod)	각 환경마다 Key Vault 별도 사용	보안 영역 분리 목적

---

🔹 4. 관리 정책 수립

• Secret 이름 예약 규칙 문서화
• 생성/수정 권한은 보안 관리자 또는 자동화 시스템에만 부여
• Rotation 주기와 만료 정책도 명확히 수립

---

🔹 5. 실시간 감사 및 경고 구성

기능	설정
Azure Monitor Diagnostic Settings	Key Vault → Log Analytics
Activity Log Alerts	Secret 읽기/쓰기/삭제 감지
Key Vault Access Logs	누가 무엇을 언제 조회했는지 기록

---

🧠 예시: WebApp, Function, API 각각이 공유하는 구조

KeyVault: shared-prod-vault

Secrets:
  webapp-db-password
  function-db-password
  api-key-authservice

RBAC:
  WebApp → "webapp-*" prefix만 접근 가능
  Function → "function-*" prefix만 접근 가능
  API → "api-*" prefix만 접근 가능

---

🧯 안티패턴 (지양해야 할 방식)

방식	이유
모든 리소스에 Key Vault Secrets User 역할 전체 부여	과도한 권한 노출
Secret 이름 단순 공통 키 사용 (ex. db-password)	충돌 위험 매우 높음
Access Policy만으로 제어	단일 Vault에서 사용자/리소스 별로 세분화 어렵고 관리 복잡

---

📌 결론 요약

핵심 요소	권장 설계
네이밍 규칙	리소스 기반 Prefix 적용 (webapp-*, api-*)
권한 분리	RBAC로 리소스 단위 최소 권한
구조 분할	환경/기능/팀 기준으로 Vault 분리 고려
감시 기능	로그 + 알림 + Key Vault Diagnostic 필수 설정

---