✔️ 적용 대상: 모든 Azure 파일 공유
Azure Files는 저장 상태에서 모든 파일 공유 데이터를 암호화합니다. 이 글에서는 정지 시 암호화가 어떻게 작동하는지, Azure Files를 배포하기 전에 내릴 결정 사항들, 즉 데이터를 암호화하는 키를 누가 관리하는지, 그리고 두 번째 암호화 계층이 필요한지 여부를 설명합니다. 사용자의 자체 키 사용 단계에 대해서는 Azure Files의 고객 관리 키를 사용한 미사용 시 저장 데이터 암호화 구성 문서를 참조하세요. 클라이언트와 Azure Files 사이를 이동하는 데이터를 보호하려면 Azure Files 전송 중 암호화 구성 항목을 참조하세요. 다른 배포 결정에 대해서는 'Azure Files 배포 계획'을 참조하세요.
사용 가능한 옵션은 파일 공유를 생성하는 리소스 제공자에 따라 다릅니다. 클래식 파일 공유(Microsoft.Storage)는 Microsoft가 관리하는 키, 고객이 관리하는 키, 그리고 인프라 암호화를 지원합니다. Microsoft.FileShares로 생성된 파일 공유는 Microsoft가 관리하는 키만 지원합니다. 리소스 제공자 간의 다른 차이점에 대해서는 Azure Files 관리 개념을 참조하세요.
| 암호화 옵션 | 클래식 파일 공유(Microsoft. 스토리지) | Microsoft.FileShares |
|---|---|---|
| Microsoft 관리형 키를 사용한 저장 데이터 암호화 | Supported | Supported |
| 고객 관리형 키 | Supported | 지원되지 않음 |
| 인프라 암호화 | Supported | 지원되지 않음 |
정지 시 암호화의 작동 원리
Azure Files는 데이터를 디스크에 기록할 때 암호화하고, 데이터를 읽을 때 복호화합니다. 암호화는 파일 공유의 파일 시스템 하위 계층에서 이루어지는데, 이는 Windows에서 BitLocker가 작동하는 방식과 유사합니다. 서비스가 암호화를 담당하기 때문에 클라이언트는 암호화 키에 접근할 필요가 없고, 애플리케이션이나 클라이언트 구성을 변경할 필요도 없습니다. 정지 시 암호화는 SMB, NFS, FileREST 중 어떤 클라이언트를 사용하든 파일 데이터와 메타데이터에 적용됩니다.
저장 데이터 암호화는 항상 켜져 있고 비활성화할 수 없습니다. 미디어 계층, 청구 모델, 중복성 여부와 관계없이 모든 파일 공유에 적용됩니다. 저장 계정이 지리적 중복 저장을 사용하는 경우, 보조 영역의 데이터도 암호화됩니다. 저장 데이터 암호화는 청구서에 추가 요금을 추가하지 않습니다.
Azure Files는 FIPS 140-2 준수 256비트 AES-GCM을 사용합니다. Azure Files가 사용하는 암호화 모듈에 대한 자세한 내용은 Cryptography API: Next Generation을 참조하세요.
저장 데이터 암호화는 데이터가 저장된 상태에서 이를 보호합니다. 누가 파일을 읽거나 변경할 수 있는지는 통제하지 않습니다; 파일 데이터 접근을 제어하려면 'Azure 파일 공유 보호'를 참조하세요.
암호화 키
Azure Files는 키를 사용해 데이터를 암호화하고, 누가 그 키를 관리할지 선택할 수 있습니다. 기본적으로 Microsoft가 이를 관리합니다. 전통적인 파일 공유의 경우, 직접 키를 관리할 수 있습니다. 두 경우 모두 Azure Files가 암호화와 복호화를 원활하게 처리합니다.
| Attribute | Microsoft 관리형 키 | 고객 관리형 키 |
|---|---|---|
| Default | Yes | No |
| 암호화 및 암호 해독 작업 | Azure | Azure |
| 키 스토리지 | Microsoft 키 저장소 | Azure Key Vault or Azure Key Vault Managed HSM |
| 키 회전 | Microsoft | 당신 |
| 키 제어 | Microsoft | 당신 |
Microsoft 관리형 키
Microsoft가 관리하는 키는 별도의 설정이 필요하지 않습니다. Microsoft는 키를 저장하고 관리하며, 준수 요구 사항에 따라 키를 교체합니다. Microsoft.FileShares로 생성된 파일 공유는 항상 Microsoft가 관리하는 키를 사용합니다. 키 교체나 감사에 대한 구체적인 요구사항이 있다면, 고객 관리형 키를 사용해 직접 키 교체를 관리하고 감사할 수 있습니다.
고객 관리형 키
고객 관리형 키를 사용하면 저장 계정의 데이터를 보호하는 키를 고객이 제어할 수 있습니다. 키를 Azure Key Vault 또는 Azure Key Vault Managed HSM에 저장하고, 스토리지 계정은 관리 신원을 사용해 접근합니다. 키 자격 증명 모음은 스토리지 계정과 다른 지역이나 구독에 있을 수 있습니다. 또한 예를 들어 서비스 제공자가 고객의 키로 보호되는 데이터를 저장할 때 다른 Microsoft Entra 테넌트에 포함될 수도 있습니다.
고객 관리 키는 전체 스토리지 계정에 적용됩니다. 하나의 키가 저장 계정 내 모든 클래식 파일 공유를 보호하며, 각 파일 공유마다 다른 키를 사용할 수 없습니다. 파일 공유에 다른 키가 필요하다면, 서로 다른 스토리지 계정에 넣으세요.
키를 관리하면 회전을 포함한 그 수명 주기도 함께 관리하게 됩니다. 스토리지 계정이 최신 버전의 키를 자동으로 사용하도록 구성할 수 있습니다. 이 옵션을 사용하면 저장 계정이 생성 후 24시간 이내에 새 키 버전을 사용하기 시작합니다. 또는 키 버전을 지정한 후 키를 순환할 때마다 스토리지 계정을 업데이트할 수도 있습니다.
스토리지 계정은 데이터를 읽고 쓰기 위해 키에 접근할 수 있어야 합니다. 키를 비활성화하거나 스토리지 계정의 해당 키에 대한 액세스 권한을 제거하면, 클라이언트는 액세스 권한을 복원하기 전까지 스토리지 계정의 데이터를 읽거나 쓸 수 없습니다. 이 동작을 이용해 의도적으로 접근 권한을 취소할 수 있지만, 키나 권한을 실수로 변경해도 같은 효과가 발생합니다. 실수로 변경되는 것을 방지하기 위해 키를 비활성화하거나 권한을 변경할 수 있는 권한을 제한하세요. 고객이 관리하는 키는 키 금고나 관리 HSM에서 퍼지 보호가 필요하므로, 삭제된 키는 보존 기간이 끝날 때까지 복구 가능한 상태를 유지합니다.
고객 관리 키 구성, 키 회전, 접근 권한 취소 단계에 대해서는 Azure Files의 고객 관리 키로 정지 암호화 구성 항목을 참조하세요.
인프라 암호화
인프라 암호화는 첫 번째 암호화 층 아래에 두 번째 암호화 계층을 추가합니다. 인프라 암호화를 통해 Azure Files는 데이터를 두 번 암호화합니다: 서비스 수준에서 선택한 키로, 그리고 인프라 수준에서 별도의 Microsoft 관리 키로 암호화합니다. 두 계층은 서로 다른 암호화 알고리즘과 다른 키를 사용합니다. 한 알고리즘이나 키가 해킹되면, 다른 계층은 계속해서 데이터를 보호합니다.
대부분의 워크로드는 인프라 암호화가 필요하지 않습니다. 서비스 수준 암호화만으로도 충분하기 때문입니다. 준수 요구사항에 이중 암호화가 요구되는 경우 인프라 암호화를 사용하세요.
인프라 암호화는 스토리지 계정을 생성할 때만 활성화할 수 있으니, 배포 전에 반드시 계획하세요. 기존 스토리지 계정에서는 활성화하거나 비활성화할 수 없습니다. 이미 보유한 데이터에 대해 인프라 암호화를 사용하려면 인프라 암호화가 적용된 새 스토리지 계정을 만들고 데이터를 새로운 파일 공유로 이전하세요. Microsoft. FileShares는 인프라 암호화를 지원하지 않습니다.
인프라 암호화가 적용된 스토리지 계정을 생성하려면 '클래식 파일 공유용 스토리지 계정 만들기' 단계를 따라가세요.