[AZ-204] Azure Key Vault
Azure Key Vault
Azure Key Vault
Azure에서 민감한 정보를 저장하는 곳 → 열쇠 꾸러미
아키텍쳐
Azure Key Vault란?
Azure Key Vault는 서비스를 배포 및 운영하는데 있어 다양한 암호 및 인증서를 저장하도록 지원하는데 주로 서비스적으로 사용되는 Token, 인증서, API Key 등을 관리하고 엄격하게 엑세스 제어를 제공한다. 또한 이런 비밀들을 관리하는데 있어 암호화 키를 손쉽게 만들 수 있는 기능을 제공한다.
웹 서비스 등에서 사용되는 암호화 프로토콜(SSL/TLS) 인증서를 쉽게 프로비저닝 및 관리 및 배포 할 수 있도록 제공하는 기능을 제공한다.
Azure Key Vault를 사용해서 얻는 이점?
Application의 비밀 중앙 집중화
Key나 인증서를 중앙 집중화하여 배포를 제어함으로써 보안성을 높일 수 있다. 또한 이러한 저장소를 생성함으로써 그에 대한 엑세스 권한을 적절하게 설정할 수 있는데 Microsoft Entra ID가 사용 되며 권한 부여는 Azure RBAC(Azure 역할 기반 엑세스 제어)을 통해 수행한다.
또한 모니터링 활동을 제공함으로써 로그를 제어하고 로그에 대한 엑세를 제한하며 보호할 수 있다.
비밀 관리의 간소화
보안 정보는 보호 되면서 가용성은 높게 만들 수 있는데, 일반적으로 사내에서 사용되는 하드웨어 보안 모듈에 대한 지식 없이도 높은 추상화를 달성할 수 있으며, 조직의 사용량에 맞추어 조절이 가능하며 Azure의 여러 지역에서 복제하여 가용성을 높이며 장애 조치(failover)를 트리거하는 관리자의 작업을 간소화 할 수 있다.
또한 공용 CA가 발급하는 인증서(SSL)의 갱신 작업을 자동화 할 수 있다.
Key Vault의 인증 방법
Azure KeyVault로 작업을 수행하기 위해서 인증을 받는 법은 총 3가지가 있다. ex) 비밀과 인증서 키를 가져오기 위해 먼저 해야하는 인증
Azure 리소스 관리 ID (가장 권장됨)
App을 배포하는 경우 Key Vault에 엑세스 할 수 있는 가상 ID를 할당 할 수 있는데, 이러한 방법은 어플리케이션 코드 내에 자격 증명을 직접 포함할 필요가 없으며, RBAC을 통해 특정 리소스에 대한 권한 설정 또한 가능하다. 이러한 방식은 크게 두 가지로 나누어지는데
시스템 할당 관리 ID 같은 경우 특정 Azure 리소스에 종속적으로 생성되며 생성된 리소스와 생명 주기를 공유 한다. 이러한 관리 ID는 리소스간 공유가 불가능해 유출시 다른 가상 ID의 노출을 방지 할 수 있다.
사용자 할당 관리 ID의 경우 독립적인 Azure 리소스로 관리되며 다른 리소스에서 재사용이 가능하다. 이를 통해 AKS - VM - Functions등을 통해 연결이 가능다.
서비스 주체 및 인증서
서비스가 직접 Key Vailt에 연결된 인증서를 가져오는 방식으로 이러한 방식은 개발자가 직접 인증서를 관리햐야한다.
서비스 주체 및 비밀
서비스의 주체를 사용하여 Key Vault에 인증하며 어플리케이션 코드 내에 인증서를 명시적으로 관리한다.
Azure Key Vault는 서비스와 비밀을 통신할 때 TLS 프로토콜을 사용하여 강력한 보안성을 제공한다. 또한 PFS(Perfect Forward Secrecy)를 통해 클라이언트 시스템과 Microsoft와 연결을 보호하는데 이는 RSA기반 2,048비트 암호화 키 길이를 사용한다.
Key Vault의 참조
Key Vault에서 환경 변수처럼 값을 가져오는 인증 방식으로 기존 AP코드에서 Secret을 사용하는 방식을 변경할 필요가 없다.
오직 참조는 Azure 리소스 관리 ID 방식으로만 가능하다. 사용자 할당 관리 ID로는 참조가 불가능하다.
Azure Key Vault를 잘 사용하기 위해서는?
우선 환경적(PRD, DEV)으로 별도의 자격 증명 모음을 사용하는 것이 권장되는데 이는 하나의 환경에서 비밀이 유출될 경우의 위협으로 지키고 상대적으로 환경에 따른 다른 보안성을 제공해 적절하게 PRD 환경을 보호할 수 있다. 또한 환경과 동시에 사용자들끼리의 역할을 분리하는 RBAC을 사용해 민감한 정보에 대한 비정상적 엑세스를 보호한다. 또한 Key의 새 버전을 생성하는 작업은 키 회전(Key Rotation)으로 정의된다. 이러한 키 회전을 관리하기 위해서는 회전 정책을 사용한 자동 키 회전과 az keyvault key rotate
를 사용한 수동 키 회전이 있다. 만약 새 버전으로 생성되어 새로운 URI를 가진다 하여도 이전 버전의 Key는 삭제되지 않으며 필요시 참조가 가능하다.
Azure Key Vault에서 제공하는 로깅과 백업, 복구 옵션등을 적극적으로 사용하는 것도 올바른 방법이다.
Azure App Configuration
Azure Key를 그룹화 하는 방식에는 Azure App Configuration에서 접두사또는 레이블을 통해 Key를 그룹화 할 수 있다.
또한 Key 네임스페이스 계층구조를 만든다면 각각의 키이름은 :
로 구분이 가능하다. (*
,,
\
는 이미 예약된 예약어라서 사용할 수 없음)
Azure RBAC이란?
조직에 대해서 각자의 역할이 있고 각자의 역할에 맞는 권한은 크게 다를 수 있다. 다양한 시스템이 Azure로 연결된 서비스에서 높은 보안성을 유지하기 위해 각 사용자에 맞는 권한을 할당 해야하는데 이러한 역할을 세밀하게 관리 할 수 있는 메커니즘이 RBAC(Role-Based Access Control)이다
보안 주체
RBAC에서 관련하는 보안주체 (사용자, 그룹, 서비스 주체, 관리 ID)
가상머신(서비스 주체)을 관리하는 A(사용자)와 가상 네트워크(서비스 주체)를 관리하는B 그리고 데이터베이스를 관리하는 C는 각자 다른 역할(관리 ID)을 가지고 상대의 리소스에 읽기나 쓰기를 할 필요가 없다. 이러한 원리는 개발자 뿐만 아니라 리소스(사용자)에게도 적용된다!! (ex: Azure VM은 오직 DB만 읽을 수 있다..)
여기서 일어나는 개발자 집단은 그룹에 해당된다.
역할
역할 정의는 일반적으로 읽기 쓰기 권한이다. 기본 제공 역할 이외에도 조직의 관리자는 역할을 만들고 관리가 가능하다
범위
이러한 권한을 적용하기 위해서는 범위라는 리소스 집합을 설정할 필요가 있는데 Azure는 4개 수준의 범위를 제공한다.
이를 통해 조직의 관리자는 어떤 사용자 또는 그룹이 어떤 범위에서 권한을 할당할지 규정할 수 있다.
역할 할당
위에서 3가지 정의된걸 활용해 조직의 역할을 할당하는 방법
우선 1. 보안주체가 설정된다. 그리고 이러한 보안 주체에 대한 2. 역할을 설정한다. (ex) Owner, Contributor, Reader) 이러한 역할에 따라 권한을 부여할 3. 범위를 설정한다. 이러한 범위는 상속됨을 명심하자
요약
이 장에서 아래와 같은 것을 배웠다.
- Azure Key Vault와 사용 했을 때의 이점
- Azure Key Vault가 인증하는 방법
- Azure RBAC의 구조