Azure Storage 계정 보안

Azure Storage는 단일 스토리지 계정 내에서 블롭, 파일, 큐, 테이블을 위한 확장 가능하고 내구성 있는 클라우드 저장소를 제공합니다. 스토리지 계정은 매우 다양한 민감도를 가진 데이터를 보유할 수 있으며, 종종 탈출 및 랜섬웨어 공격의 표적이 되기 때문에, 계정과 그 안에 저장된 데이터, 그리고 접근하는 신원을 보호하기 위해 신중한 조치를 취해야 합니다.

이 글은 Azure Storage 계정을 보호하는 데 도움이 될 보안 권고사항을 제공합니다. 이 권고사항은 계정 내 모든 데이터 서비스(블롭, 파일, 큐, 테이블)에 적용됩니다. 각 데이터 서비스에 대한 구체적인 지침은 이 글 끝의 관련 보안 문서를 참조하십시오.

이 문서의 보안 권장 사항은 제로 트러스트 원칙인 "명시적으로 확인", "최소 권한 액세스 사용" 및 "위반 가정"을 구현합니다. 포괄적인 제로 트러스트 지침은 제로 트러스트 지침 센터를 참조하세요.

서비스별 보안

Azure Storage는 안전하게 배포하는 방식을 결정하는 아키텍처적 특성을 가지고 있습니다. 계정을 생성할 때 내리는 선택 — 배포 모델, 종류, 중복성, 엔드포인트 구성 — 은 나중에 변경하기 어렵고, 계정을 사용하는 모든 워크로드의 보안 태세에 영향을 미칩니다.

스토리지 계정 아키텍처

  • Azure Resource Manager 배포 모델을 사용하세요: Azure Resource Manager 배포 모델을 사용하여 새 스토리지 계정을 생성합니다. Resource Manager 계정은 Azure 역할 기반 접근 제어(RBAC), 관리 신원, Microsoft Entra ID 데이터 권한, 리소스 락, 태그, 정책을 지원하지만, 이 모든 기능은 클래식 배포 모델에서는 제공되지 않습니다. 남아 있는 클래식 계정을 마이그레이션하세요. 자세한 내용은 Migrate a classic storage account to Azure Resource Manager를 참조하세요.

  • 워크로드, 환경, 민감도별로 스토리지 계정을 분리: 개발, 사전 제작, 운영 계정과 민감도 분류가 다른 데이터별로 별도의 계정을 생성합니다. 스토리지 계정은 공유 키 신뢰 경계이자 정책 경계입니다 - 한 계정에 워크로드를 혼합하면 침해의 폭발 반경이 커지고 최소 권한 접근을 모델링하기 어렵게 만듭니다.

  • 지역별 고립을 위해 지역별 계정을 하나 사용하기: 사용 중인 워크로드가 발생하는 지역에 계정을 배치하면 지역 간 데이터 이동을 줄이고 준수 경계를 단순화할 수 있습니다. 다중 지역 설계의 경우, 단일 계정에서 모든 지역을 서비스하는 대신 지역 계정을 지리적 중복 저장소나 객체 복제와 결합하세요. 자세한 내용은 Azure Storage 중복성을 참조하세요.

Azure Storage의 적절한 사용법

  • Azure Storage 계정 키를 장기 애플리케이션 자격 증명으로 사용하지 마세요: Storage 계정 키는 계정에 대한 완전한 제어권을 부여하며 범위를 지정할 수 없습니다. 애플리케이션은 관리 신원과 함께 Microsoft Entra ID를 사용해야 하며, Entra ID가 옵션이 불가능할 경우 단명한 사용자 위임 공유 액세스 서명(SAS) 토큰을 사용해야 합니다. 자세한 내용은 Azure Storage의 데이터에 대한 액세스 권한 부여를 참조하세요.

  • Azure Storage를 범용 비밀 저장소로 사용하지 마세요: 비밀, 연결 문자열, 인증서는 회전, 접근 정책, 하드웨어 보안 모듈(HSM) 보호, 감사 추적을 제공하는 Azure Key Vault에 속합니다. 자세한 내용은 Azure Key Vault 개요를 참조하세요.

네트워크 보안

스토리지 계정은 기본적으로 인터넷에 접근할 수 있습니다. 네트워크 공격 표면을 줄이는 것이 무단 접근, 데이터 유출, 정찰로부터 계정을 보호하는 가장 효과적인 변화입니다.

  • 스토리지 계정에 대한 공용 네트워크 접근 권한을 비활성화하세요: 클라이언트가 완전히 Azure에 있거나 Private Link를 통해 접근 가능할 때, 계정의 공용 네트워크 접근 권한을 비활성화로 설정하여 사설 엔드포인트를 통한 요청만 허용되도록 하세요. 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.

  • 가상 네트워크에서 접근하기 위해 프라이빗 엔드포인트를 사용하세요: 프라이버시 엔드포인트는 가상 네트워크에서 스토리지 계정에 사설 IP 주소를 할당하고 Microsoft 백본을 통해 트래픽을 라우팅합니다. 공용 네트워크 접속이 비활성화된 것과 결합되면, 프라이빗 엔드포인트는 인터넷 노출을 제거합니다. 자세한 내용은 Azure Storage에 프라이빗 엔드포인트 사용을 참조하세요.

  • 개인 엔드포인트가 실용적이지 않을 때 스토리지 방화벽으로 공인 접근을 제한하세요: 클라이언트가 공용 네트워킹을 통해 계정에 접근해야 한다면, 방화벽의 기본 동작을 '거부 '로 설정하고, 특정 IP 범위, 가상 네트워크 서브넷(서비스 엔드포인트를 통해), 또는 접근이 필요한 리소스 인스턴스만 허용하세요. 자세한 내용은 Azure Storage 방화벽 및 가상 네트워크 구성을 참조하세요.

    • 신뢰할 수 있는 Microsoft 서비스가 계정에 액세스해야 할 때 허용: 기본 거부 방화벽 규칙은 다른 Azure 서비스(예: Azure Backup, Log Analytics, Microsoft Defender for Storage)의 요청뿐만 아니라 Azure Portal 및 진단 파이프라인의 요청도 차단합니다. 신뢰 서비스 목록에 'Allow Azure 서비스'를 추가하여 이 스토리지 계정 예외에 접근하세요. 그래야 신뢰하는 1자 서비스가 공용 인터넷에 개방하지 않고도 계정에 접근할 수 있습니다. 자세한 내용은 신뢰할 수 있는 Azure 서비스에 대한 액세스 참조하세요.

    • 신뢰할 수 있는 서비스 대신 특정 리소스 인스턴스에 대한 접근 권한을 널리 부여하세요: 일반적인 "Allow Microsoft 서비스" 예외보다 이름 있는 Azure 리소스와 그 관리 신원을 권한 있는 자원 인스턴스 규칙을 선호하세요. 리소스 인스턴스 규칙은 신뢰 표면을 더 작게 만듭니다. 자세한 내용은 Azure 리소스 인스턴스에서 액세스 권한 부여를 참조하세요.

  • 스토리지 계정을 네트워크 보안 경계와 연계: 네트워크 보안 경계는 플랫폼과 서비스 자원 간의 논리적 경계를 정의하고, 기본적으로 경계 외부의 트래픽을 차단하여 계정별 방화벽 규칙을 넘어서는 심층 방어를 제공합니다. 자세한 내용은 Azure Storage의 Network security perimeter를 참조하세요.

  • 최소 TLS 버전 1.2 이상을 강제하세요: 스토리지 계정의 최소 TLS 버전을 설정하여 구버전, 폐기된 버전을 협상하는 클라이언트를 거부하도록 설정하세요. 자세한 내용은 스토리지 계정의 최소 요구 전송 계층 보안(TLS) 버전 구성을 참조하세요.

  • 안전한 전송 요구(HTTPS): HTTP를 통한 모든 요청을 거부하도록 보안 전송 요구(Secure transfer required ) 속성을 활성화합니다. 이 요구사항은 REST 엔드포인트뿐만 아니라 SMB의 Azure Files 접근에도 적용됩니다. 자세한 내용은 '스토리지 계좌에 대한 안전한 전송 요구'를 참조하세요.

    • 일부 시나리오, 예를 들어 구형 SMB 클라이언트나 레거시 도구는 HTTP가 필요합니다. 이런 경우에는 해당 클라이언트들을 통제된 네트워크 세그먼트에서 격리하고 가능한 한 빨리 HTTP에서 이전하세요.

  • 테넌트 간 객체 복제 및 복사 작업 제한: 스토리지 계정을 동일 테넌트 내 소스 계정에서만 복사 및 객체 복제 작업을 허용하도록 설정하거나, 허용된 소스 계정에서만 허용합니다. 이 구성은 데이터 플레인 권한을 가진 사용자가 테넌트 경계를 넘어 데이터를 이동하는 것을 방지합니다. 자세한 내용은 복사 작업의 허용 범위와 Microsoft Entra 테넌트 간 객체 복제 방지를 참조하세요.

  • Azure Storage로 보내는 아웃바운드 규칙에 VNet 서비스 태그를 사용하세요: 가상 네트워크에서 Azure Storage로 아웃바운드 트래픽을 제한할 때는 하드 코딩된 IP 범위 대신 서비스 태그(또는 지역별 변형)를 사용 Storage 하세요. Microsoft는 IP 공간이 진화함에 따라 서비스 태그를 유지합니다. 자세한 내용은 Azure 서비스 태그 개요를 참조하세요.

  • 인바운드 라우팅에 Microsoft 글로벌 네트워크를 선호하세요: 스토리지 계정의 네트워크 라우팅 선호도를 Microsoft 네트워크 라우팅으로 설정하여 인바운드 트래픽이 클라이언트에 가장 가까운 포스오브 프레즌스에서 Microsoft 백본으로 진입하고 Microsoft 네트워크 종단 간에 머무르도록 하세요. 인터넷 라우팅은 Microsoft 네트워크에서 더 일찍 빠져나가면서 공용 인터넷 경로에 대한 노출을 증가시킵니다. 자세한 내용은 Azure Storage에 대한 네트워크 라우팅 기본 설정 구성을 참조하세요.

ID 및 액세스 관리

스토리지 계정은 두 가지 권한 부여 모델을 지원합니다: Microsoft Entra ID(신원 기반, 감사 가능, 취소 가능)와 공유 키(전체 계정 접근 권한이 있는 대칭 비밀). 가능한 한 워크로드를 Microsoft Entra ID로 옮기고, 공유 키를 레거시 백업으로 활용하세요.

  • Microsoft Entra ID를 사용해 데이터 접근 권한을 부여하세요: Microsoft Entra ID 인증은 OAuth 2.0 토큰을 사용하며 조건부 접근, 관리 신원, RBAC 감사 트레일과 통합됩니다. 데이터 평면 접근 측면에서 Shared Key보다 모든 면에서 우수합니다. 자세한 내용은 Azure Storage의 데이터에 대한 액세스 권한 부여를 참조하세요.

  • 공유 키 권한 불허용: 계정 키로 서명된 요청을 거부하도록 속성을 설정 allowSharedKeyAccessfalse 하세요. Microsoft Entra ID와 해당되는 경우 사용자 위임 SAS 요청만 허용됩니다. 자세한 내용은 Azure Storage 계정에 대한 공유 키 권한 부여 방지를 참조하세요.

  • RBAC 역할은 가장 적은 범위에서 할당하세요: 내장된 스토리지 데이터 플레인 역할(예: 스토리지 블롭 데이터 리더, 스토리지 큐 데이터 기여자)은 가능하면 계정이나 구독 수준이 아닌 컨테이너, 공유, 큐, 테이블 수준에서 할당하세요. 자세한 내용은 Azure 역할 기반 접근 제어를 이용한 블롭 접근 권한 승인을 참조하세요.

  • SAS가 필요할 경우 서비스 또는 계정 SAS 대신 사용자 위임 SAS를 사용하세요: 사용자 위임 SAS는 계정 키 대신 Microsoft Entra 자격 증명으로 서명되므로, 사용자 위임 키를 취소하면 즉시 발송된 모든 SAS가 무효화됩니다. 계정 키로 서명된 서비스 및 계정 SAS 토큰은 개별적으로 취소할 수 없습니다. 자세한 내용은 SAS(공유 액세스 서명)를 사용하여 Azure Storage 리소스에 대한 제한된 액세스 권한 부여를 참조하세요.

  • 계정 키를 꼭 사용해야 한다면, 보호하고 교체하세요: Azure Key Vault에 계정 키를 저장하고, 구성에 내장하지 않고 런타임에 가져와서 정해진 주기에 맞춰 회전하세요. 롤오버 시 두 키를 모두 사용해 다운타임을 피하는 문서화된 회전 절차를 준비하세요. 자세한 내용은 스토리지 계정 액세스 키 관리를 참조하세요.

  • Microsoft Entra Privileged Identity Management(PIM)을 사용하여 권한 있는 스토리지 역할을 JIT(필요 시점)에 할당합니다: 스토리지에 대한 관리 평면 변경 권한을 부여하는 역할(예: 스토리지 계정 기여자 또는 소유자)의 경우 상시 할당 대신, 승인 및 다단계 인증을 거치는 PIM 활성화를 요구합니다. 자세한 내용은 Microsoft Entra Privileged Identity Management란?을 참조하세요.

데이터 보호

Azure Storage는 기본적으로 Microsoft가 관리하는 키로 모든 데이터를 암호화합니다. 이 섹션의 권고사항은 고객 통제를 추가하고, 우발적이거나 악의적인 수정으로부터 보호하며, 전송 및 정지 중인 데이터의 노출을 줄입니다.

  • 고객 관리 키(CMK)를 정지 시 암호화 설정하기: Azure Key Vault 또는 Managed HSM에서 관리하는 키를 계정 암호화 키로 사용하세요. CMK는 암호화 키를 Microsoft 관리 키와 독립적으로 회전, 감사, 취소할 수 있게 해줍니다. 고객 키 제어를 의무화하는 컴플라이언스 요구사항을 지원합니다. 자세한 내용은 Azure Storage 암호화용 고객 관리형 키를 참조하세요.

  • 방어 심층 이중 암호화를 위한 인프라 암호화 활성화: 인프라 암호화는 주 암호화 계층 위에 두 번째 서비스 관리 암호화 계층을 적용합니다. 계정 생성 시 반드시 활성화해야 합니다. 자세한 내용은 ' 데이터 이중 암호화를 위한 인프라 암호화 활성화'를 참조하세요.

  • 암호화 범위 사용으로 특정 컨테이너나 블롭에 대한 암호화를 분리하세요: 암호화 범위는 단일 계정 내에서 컨테이너 수준 또는 블롭 단위로 서로 다른 키나 키 순환 정책을 적용할 수 있게 해줍니다. 이 기능은 계정을 공유하지만 테넌트별 키 제어가 필요한 다중 테넌트 워크로드에 유용합니다. 자세한 내용은 Blob Storage의 암호화 범위 항목을 참조하세요.

  • 전송 중인 모든 데이터에 대해 Azure Storage 암호화를 활성화하세요: 최소 TLS 버전 1.2 이상과 결합 Secure transfer required = enabled 하세요(네트워크 보안 참조). 둘을 함께 사용하면 계정이 암호화되지 않은 연결과 약하게 암호화된 연결을 모두 거부하도록 할 수 있습니다.

  • 가장 민감한 데이터는 클라이언트 측 암호화를 사용하세요: 서버에 절대 나타나지 말아야 하는 평문이 있는 데이터는 업로드 전에 클라이언트에서 암호화하세요. 클라이언트 측 암호화는 서비스 측 암호화를 보완하며, 계층 보호를 위해 CMK와 함께 사용할 수 있습니다. 서비스별 SDK 지원과 패턴에 대해서는 관련 보안 문서를 참조하세요.

  • 스토리지 계정을 리소스 락으로 보호하세요: CanNotDelete 또는 ReadOnly 락을 적용하여 계정 자체의 우발적 또는 악의적인 삭제 또는 재구성을 방지하세요. 잠금은 계정 자원에 적용되지, 그 안의 데이터에는 적용되지 않기 때문에, 소프트 삭제와 불변성을 대체하는 것이 아니라 보완합니다. 자세한 내용은 스토리지 계정에 Azure Resource Manager 잠금 적용을 참조하세요.

데이터 서비스별 데이터 보호 기능(블롭 불변성 및 WORM 정책, 블롭 암호화 범위)에 대해서는 관련 보안 문서의 해당 하위 문서를 참조하세요.

로깅 및 모니터링

스토리지 계정은 자격 증명 도난, 유출 시도, 오수의 자주 표적이 됩니다. 공격을 신속하게 감지하고 대응하려면 지속적인 로깅과 위협 탐지가 필요합니다.

  • Microsoft Defender for Storage 활성화: Defender for Storage는 위협 감지, 업로드 시 블롭 감지 악성코드 검사, 민감한 데이터 검색 기능을 제공합니다. 이 프로토콜은 이상 접근 패턴, 알려진 악성 IP 및 Tor 종료 경로, 그리고 비정상적인 인증 활동을 표시합니다. 구독 또는 저장 계정 수준에서 활성화하세요. 자세한 내용은 Microsoft Defender for Storage 개요를 참조하세요.

    • 신뢰할 수 없는 콘텐츠를 허용하는 계정에서 블롭 업로드에 대한 악성코드 검사를 사용하도록 설정: 악성코드 검사는 업로드된 블롭을 검사하고, 악성 콘텐츠가 다운스트림 소비자에게 제공되기 전에 이를 표시하거나 제거합니다. 자세한 내용은 Defender의 Malware Scanning for Storage를 참조하세요.

    • 민감한 데이터 위협 탐지 활성화: 민감한 데이터 발견은 계정 내 데이터를 분류하고 민감한 정보를 담은 컨테이너에 대한 경고 우선순위를 부여합니다. 자세한 내용은 Defender for Storage의 민감 데이터 발견을 참조하세요.

  • 진단 설정을 Log Analytics 작업 공간에 전송하세요: 계정과 각 데이터 서비스(블롭, 파일, 큐, 테이블)에서 진단 설정을 설정하여 , 로그StorageWriteStorageDelete, 모든 지표를 Log Analytics로 전송StorageRead하도록 설정하세요. 준수 의무에 따라 요구되는 기간 동안 로그를 보관하세요. 자세한 내용은 Azure Storage 모니터링을 참조하세요.

  • 각 요청이 어떻게 승인되었는지 감사하세요: 스토리지 로그는 각 요청이 Microsoft Entra ID, 공유 키, SAS, 또는 익명으로 승인되었는지 기록합니다. 로그를 정기적으로 조회하여 예기치 않은 권한 부여 방법을 감지하세요. 특히 공유 키 사용 또는 비활성화 후 익명 접근 같은 권한이 발생하는지 확인하세요. 자세한 내용은 Azure Storage에 대한 요청 모니터링을 참조하세요.

  • 보안 신호가 높은 이벤트에 대한 경고: 키 생성, 방화벽 규칙 변경, 공용 네트워크 접근 변경, 비활성화해야 할 계정의 공유 키 사용, 스토리지 알림 Defender 등 이벤트에 대해 Azure Monitor 알림을 설정하세요. 자세한 내용은 Azure Monitor의 로그 경고를 참조하세요.

  • 로그 중앙 SIEM으로 전달: 기업 규모 대응을 위해 Log Analytics에서 스토리지 로그를 Microsoft Sentinel 또는 다른 SIEM으로 전달하여 스토리지 이벤트가 신원, 네트워크, 엔드포인트 신호와 연관되도록 합니다. 자세한 내용은 Connect Azure Storage to Microsoft Sentinel을 참조하세요.

규정 준수 및 거버넌스

거버넌스 제어는 안전한 구성을 기본값으로 만들고 자동으로 드리프트를 감지합니다. 계정이 몇 개 수준을 넘는 모든 스토리지 환경에서는 기준선의 일관성을 유지할 수 있는 지속 가능한 유일한 방법은 정책 기반 강제 적용입니다.

  • Azure Policy를 적용해 기본 스토리지 보안을 강화하세요: 배포 시 보안이 취약한 구성을 차단하는 내장 정책을 할당하고 기존 계정을 감사하세요. 고가치 내장 기능에는 보안 전송 요구, 최소 TLS 1.2 요구, 공용 네트워크 접근 거부, 공용 블롭 접근 거부, 인프라 암호화 요구, CMK 요구 등이 포함됩니다. 전체 목록은 Azure Storage용 Azure Policy 기본 제공 정의와 Azure Storage용 Azure Policy 규정 준수 제어를 참조하세요.

  • Microsoft 클라우드 보안 벤치마크(MCSB)를 기준으로 삼으세요: 스토리지 제어를 MCSB v2 도메인과 정렬하여 서비스 전반에 일관된 보안 태세를 유지하세요. 자세한 내용은 Microsoft 클라우드 보안 벤치마크 개요를 참조하세요.

  • 소유자, 데이터 분류, 환경이 포함된 스토리지 계정 태그: 거버넌스 정책, 비용 관리, 사고 대응 모두 일관된 태깅에 의존합니다. 태그를 생성 시 생략하지 않도록 Azure Policy를 통해 적용하세요.

  • 규제 대상 데이터를 저장하기 전에 준수 상품을 검토하세요: Azure Storage는 HIPAA, PCI DSS, FedRAMP, ISO 27001 등 공통 규제 프레임워크에 대한 인증을 보유하고 있습니다. 배치 전에 업무량에 대한 보장을 확인하세요. 자세한 내용은 Azure Storage 컴플라이언스 제공 상품을 참조하세요.

백업 및 복구

지역 간 중복성과 검증된 장애 전환 절차는 스토리지 계정 자체에 지역적 복원력을 제공합니다. 데이터 서비스 특화 삭제 방지(블롭 소프트 삭제, 블롭 버전 관리, 변경 피드, 시점 복원, 파일 공유 소프트 삭제 및 스냅샷)에 대해서는 관련 보안 문서의 해당 하위 문서를 참조하세요.

  • 복구 요구사항에 맞는 적절한 중복 옵션을 선택하세요: 지리중복 저장소(GRS/RA-GRS/GZRS/RA-GZRS)는 데이터를 쌍으로 복제하며, 지역 복원력을 위해 고객이 주도하는 장애 전환을 지원합니다. 존 중복 저장장치(ZRS/GZRS)는 지역 내 존 수준 장애로부터 보호합니다. 자세한 내용은 Azure Storage 중복성을 참조하세요.

  • 랜섬웨어 보호를 위해 지역 중복성에 의존하지 마세요: 지역 중복 복제는 데이터뿐 아니라 모든 손상이나 악의적 삭제까지 페어링된 지역에 그대로 복제합니다. 랜섬웨어 및 변조 방지에 대비하기 위해 GRS를 불변성 정책, 소프트 삭제 및 버전 관리와 함께 사용하세요. 자세한 내용은 Azure Storage의 데이터 보호 기능을 참조하세요.

  • 고객 주도 장애 조치 및 장애 복구 연습: RA-GRS 또는 RA-GZRS 계정의 경우, 복구 절차가 실제로 필요해지기 전에 이를 검증할 수 있도록 계획된 장애 조치 연습을 수행하세요. 자세한 내용은 재해 복구 및 저장소 계정 장애 조치(failover)를 참조하세요.

각 Azure Storage 데이터 서비스에 특화된 보안 지침은 다음을 참조하세요:

다음 단계

  • 에 마지막으로 업데이트됨