Azure Files를 안전하게 하세요

이 글은 Microsoft.Storage를 사용해 만든 클래식 파일 공유와 Microsoft.FileShares를 사용해 만든 파일 공유를 포함하여 Azure Files에 대한 보안 지침을 제공합니다. 이는 귀하의 주식을 보유하는 계좌, 고객 접근, 데이터 보호, 운영 통제를 포함합니다.

보안 통제는 자원 제공자와 프로토콜에 따라 달라집니다. 지원되는 기능 비교는 Azure Files 관리 개념을 참조하세요.

리소스 격리

  • 스토리지 계정을 신뢰 경계로 간주하세요: 같은 스토리지 계정 내에서 별도의 클래식 파일 공유를 생성해도 네트워크 규칙, SMB 신원 소스, 암호화 키 구성을 분리하지 못합니다. 이러한 계정 수준 설정의 변경은 해당 계정의 모든 공유 항목에 영향을 미칩니다. 클래식 공유는 이러한 컨트롤을 공유할 수 있는 경우에만 함께 그룹화됩니다. Microsoft. FileShares는 각 공유에 대해 독립적인 네트워크 및 보안 구성을 제공하여 이러한 공유 계정 수준의 경계를 피합니다.

  • 클라이언트 시스템 보호: 쓰기 권한이 있는 클라이언트는 파일 데이터를 수정하거나 삭제할 수 있습니다. 클라이언트 운영체제를 최신 상태로 유지하고 로컬 관리자 접근을 제한하세요. 클라이언트 환경에 적합한 엔드포인트 보호를 사용하세요. 네트워크 격리와 암호화는 권한이 있는 클라이언트가 파괴적인 변경을 하는 것을 막지 못합니다.

네트워크 보안

인바운드 접속 및 아웃바운드 필터링

  • 필요한 클라이언트에 대한 인바운드 접근 제한: 두 자원 제공자 모두 가상 네트워크 제한이 있는 개인 엔드포인트와 서비스 엔드포인트를 지원합니다. NFS Azure 파일 공유에 접근하려면 이러한 경로 중 하나가 필요합니다. 클래식 SMB와 FileREST 클라이언트도 IP 주소 규칙이 있는 공개 엔드포인트를 사용할 수 있습니다. 설정 절차는 Azure 파일 공유용 네트워크 엔드포인트 구성을(를) 참조하세요.

  • 필요하지 않을 경우 공개 접근 차단: 공개 엔드포인트는 프로토콜에 적합한 네트워크 접근 제어, 인증, 암호화를 통해 안전하게 사용할 수 있습니다. 워크로드에 필요하고 보안 모델이 허용할 때, 서비스 엔드포인트를 통한 연결을 포함해 공개 접근 권한을 유지하세요. 개인 엔드포인트를 생성한다고 해서 공개 접근이 자동으로 비활성화되는 것은 아닙니다. 클래식 공유의 경우, 공개 접근이 비활성화된 후에도 유효할 수 있는 신뢰할 수 있는 서비스 또는 리소스 인스턴스 예외를 검토하세요. 자세한 내용은 공개 엔드포인트 접근 제한을 참조하세요.

  • 신뢰할 수 있는 서비스 접근 권한은 필요할 때만 활성화하세요: 클래식 파일 공유에만 사용할 수 있는 신뢰 서비스 설정은 지원되는 Azure 서비스가 스토리지 계정의 네트워크 규칙을 우회할 수 있게 합니다. 통합이 이 액세스 권한이 필요할 때만 활성화하세요. 이 서비스들은 여전히 파일 데이터에 접근하도록 승인되어 있어야 합니다.

  • 서비스 엔드포인트 트래픽에 대한 선택적 필터링: 클라이언트가 클래식 파일 공유에 접근하기 위해 서비스 엔드포인트를 사용할 때, 선택적으로 서비스 엔드포인트 정책을 해당 서브넷에 적용할 수 있습니다. 이 정책은 클라이언트가 서비스 엔드포인트를 통해 액세스할 수 있는 스토리지 계정을 제한하며, 이때 트래픽은 Azure Firewall 및 네트워크 가상 장치를 우회합니다. 서비스 엔드포인트 트래픽에만 적용되며, 프라이빗 엔드포인트 트래픽이나 다른 아웃바운드 경로는 필터링하지 않습니다. 목적지의 네트워크 규칙과 인가 요구 사항은 여전히 적용됩니다. Microsoft. FileShares는 현재 이 정책을 지원하지 않습니다. 정책이 있는 서브넷 내 클라이언트는 Microsoft.FileShares 공유에 접근하기 위해 반드시 사설 엔드포인트를 사용해야 합니다. 자세한 내용은 서비스 엔드포인트 정책을 참조하세요.

  • 네트워크 보안 경계를 사용하기 전에 프로토콜 지원을 확인하세요: 클래식 공유의 경우 경계 지원은 프로토콜과 인증 방식에 따라 다릅니다. 강제 모드에서는 경계가 공용 엔드포인트를 통한 NFS 액세스를 차단하며, 서비스 엔드포인트 트래픽도 포함됩니다. 프라이빗 엔드포인트 트래픽은 경계 적용 범위 밖에 있습니다. 경계를 적용하기 전에 Azure Backup과 Azure 파일 동기화의 제한 사항을 확인하세요. 자세한 내용은 Azure Files의 네트워크 보안 경계를 참조하세요.

SMB 프로토콜 강화

이 권고사항은 클래식 SMB 파일 공유에도 적용됩니다.

  • SMB 채널 암호화 요구: 암호화된 SMB 3.x 연결을 사용하세요. SMB 2.1은 채널 암호화를 지원하지 않습니다. FileRest의 HTTPS 요구사항은 SMB 암호화 구성을 대체하지 않습니다. 자세한 내용은 SMB 암호화 및 보안 설정을 참조하세요.

  • 프로토콜 버전과 알고리즘을 고객이 필요로 하는 것으로 제한하세요: 귀하의 워크로드와 호환되는 가장 안전한 SMB 프로필을 사용하세요. SMB 3.1.1이나 AES-256-GCM을 요구하기 전에 클라이언트 지원 여부를 꼭 확인하세요. 그렇지 않으면 호환되지 않는 클라이언트는 연결하지 못할 수 있습니다. SMB 채널 암호화와 Kerberos 티켓 암호화는 별도의 제어입니다. 자세한 내용은 SMB 보안 설정을 참조하세요.

  • SMB 인증 방법 제한: 신원 기반 접근을 위해 Kerberos를 사용하세요. SMB를 통한 스토리지 계정 키 인증이 필요한 클라이언트가 없다면, 테스트 후 허용된 SMB 인증 방법에서 NTLMv2를 제거하세요. 이 제어는 SMB에 적용됩니다; 키 기반 FileREST 접근을 비활성화하지 않습니다.

  • AD DS 자격 증명을 유지하세요(해당 시): AD DS 인증의 경우, 디렉터리 정책에 따라 스토리지 계정을 나타내는 디렉터리 프린시펄의 비밀번호를 관리하세요. 디렉터리 비밀번호와 저장 계정 Kerberos 키를 동기화하기 위해 문서화된 회전 절차를 따르세요. 자세한 내용은 AD DS의 스토리지 계정 ID 암호 업데이트를 참조하세요.

NFS 4.1 파일 공유

이 권고사항은 NFS 파일 공유에 대해 두 리소스 제공자 중 어느 쪽에도 적용됩니다. NFS는 SMB 신원 기반 인증이 아닌 네트워크 기반 인증과 POSIX 권한을 사용합니다.

  • 신뢰할 수 있는 네트워크 접근 제한: 워크로드에 필요한 서브넷과 개인 연결만 허용합니다. NFS는 클라이언트가 제시하는 신원에 의존하므로, 해당 연결을 사용할 수 있는 시스템과 관리자를 제어해야 합니다.

  • POSIX 권한과 클라이언트 식별 관리: 클라이언트 간에 일관된 사용자 ID와 그룹 ID를 사용하세요. 접근 권한이 필요한 사용자와 그룹에 대해 파일 및 디렉터리 권한을 제한하세요. Azure 리소스 관리를 위한 Azure RBAC 권한은 NFS 파일 접근 권한을 부여하지 않습니다. 자세한 내용은 NFS 인증 및 네트워크 접근을 참조하세요.

  • 워크로드와 호환되는 곳에서 루트 스쿼시를 구성하세요: 루트 스쿼시는 UID/GID 0의 요청을 익명 신원으로 매핑합니다. 다른 사용자를 제한하거나 공유를 읽기 전용으로 만들지 않습니다. 두 리소스 제공자의 설정 및 구성 절차에 대해서는 NFS Azure 파일 공유에 대한 루트 스쿼싱을 참조하세요.

  • 전송 시 암호화 요구: 두 자원 제공자 모두 AZNFS 마운트 헬퍼를 통해 TLS를 지원합니다. Microsoft. FileShares는 기본적으로 전송 시 암호화가 필요합니다. 클래식 쉐어는 스토리지 계정 수준의 NFS 암호화 설정이 있습니다. 기본값과 구성 링크에 대해서는 NFS 암호화를 참조하세요.

ID 및 액세스 관리

Azure 리소스 관리

  • 관리 접근에 최소 권한 사용: 리소스 생성, 구성 또는 삭제에 필요한 가장 작은 범위에서 Azure RBAC 권한을 부여합니다. 클래식 공유의 경우, 계정 수준의 권한이 계정 내 모든 공유에 영향을 미칠 수 있습니다. Microsoft.FileShares 리소스를 독립적으로 관리할 수 있습니다. 관리 역할과 데이터 접근 권한은 서로 다른 목적을 가집니다. 자세한 내용은 Azure 컨트롤 플레인 및 데이터 평면 참조하세요.

  • 상시 관리자 액세스 제한: 특권 Azure 역할에 적합한 경우 Microsoft Entra Privileged Identity Management을 사용하세요. 조직 정책에 따라 관리자 활성화를 위해 승인과 다중인증을 요구하세요. 자세한 내용은 Privileged Identity Management를 참조하세요.

SMB 파일 공유에 대한 신원 기반 인증

SMB ID 기반 액세스는 클래식 파일 공유 리소스에 대해 제공됩니다. 스토리지 계정 키는 계정 내 공유 전반에 걸쳐 광범위한 데이터 접근을 부여하며 개별 사용자를 식별하지 않습니다.

  • 클라이언트에서 지원되는 신원 소스를 사용하세요: Azure Files는 AD DS, Microsoft Entra Domain Services, Microsoft Entra Kerberos를 지원합니다. 그들의 고객 및 신원 요구사항은 다릅니다. 지원되는 시나리오와 설정 가이드는 Azure Files용 ID 기반 인증을 참조하세요.

  • 지원되는 애플리케이션 워크로드에 관리 ID를 사용하세요: 관리 ID는 스토리지 계정 키를 배포하지 않고도 SMB 접근을 제공할 수 있습니다. 배포를 위한 컴퓨트, 클라이언트, 인증 전제 조건을 확인하세요. 자세한 내용은 관리 ID를 사용하여 SMB 공유에 액세스를 참조하세요.

  • 필요할 때 계정 키를 보호하기: 키 조회 또는 재생성 권한을 제한합니다. 필요한 키는 Azure Key Vault에 저장하고, 노출 후 또는 자격 증명 정책에 따라 교체하세요. 키를 여전히 사용하는 클라이언트와 통합을 기준으로 교체를 계획하세요. 자세한 내용은 스토리지 계정 액세스 키 관리를 참조하세요.

공유 수준 및 NTFS 권한

이러한 권한은 클래식 SMB 파일 공유에 적용됩니다.

  • 필요한 범위에 공유 수준 역할을 할당하세요: 읽기, 쓰기 또는 관리자 권한을 필요한 ID에만 부여합니다. 공유 단위 역할 할당은 같은 스토리지 계정 내 관련 없는 공유에 대한 액세스 권한 부여를 방지합니다. 자세한 내용은 공유 수준 권한 할당을 참조하세요.

  • 디렉터리 및 파일 권한 적용: 공유 내 접근 권한을 제어하기 위해 공유 폴더의 루트 디렉터리를 포함한 Windows ACL을 사용합니다. 상속을 사용해 권한을 관리하기 쉽게 유지하세요. 공유 수준 권한과 Windows ACL이 모두 적용됩니다. 자세한 내용은 디렉터리 수준 및 파일 수준 권한 구성을 참조하세요.

  • 권한 관리 제한: 권한 관리 책임자에게만 상위 역할과 ACL 수정 권한을 부여합니다. 접근 요건이 변경될 때 역할 할당과 상속된 ACL을 모두 검토하세요.

FileREST 접근과 SAS

FileREST 데이터 접근은 클래식 공유에 대해 가능합니다. Microsoft. FileShares는 현재 FileREST 데이터 접근을 지원하지 않습니다.

  • 지원되는 관리자 데이터 접근을 위해 OAuth 사용: 관리 아이덴티티를 포함한 Microsoft Entra 아이덴티티는 FileREST를 통해 클래식 공유에 접근할 수 있습니다. 이 접근 방식에서 사용하는 특권 역할은 파일 및 디렉터리 권한을 우회할 수 있으므로, 해당 접근이 필요한 경우에만 권한을 부여하세요. 자세한 내용은 REST를 통한 Azure Files OAuth를 참조하세요.

  • SAS 권한 및 수명 제한: 지원되는 도구가 공유 액세스 서명(SAS)을 요구할 경우, 범위, 권한, 유효 기간을 제한하고 HTTPS를 요구합니다. SAS를 자격증명으로 보호하세요. SAS 토큰은 SMB나 NFS를 통해 공유를 마운트하는 데 사용되지 않습니다. 자세한 내용은 공유 접근 서명을 참조하세요.

  • FileREST에 HTTPS 요구: HTTPS는 전송 중인 REST 요청을 보호합니다. SMB 채널 암호화와 NFS TLS 터널링은 HTTPS 요구사항과는 별개입니다. 구성 단계에 대해서는 '보안 전송 요구'를 참조하세요.

데이터 보호

  • 저장 데이터 암호화 이해하기: 두 리소스 공급자 모두 기본적으로 Microsoft 관리 키를 사용하여 저장된 파일 데이터를 암호화합니다. 저장 데이터 암호화는 저장된 데이터를 보호합니다; 권한이 있는 클라이언트가 파일을 읽거나 변경하는 것을 막지 않습니다.

  • 필요 시 고객 관리 키를 사용하세요: 클래식 공유는 Azure Key Vault 또는 Managed HSM에서 고객 관리 키를 지원합니다. Microsoft. FileShares는 현재 고객 관리 키를 지원하지 않습니다. 키 저장소를 보호하고, 키 순환을 계획하며, 키 접근 권한이 상실되면 데이터가 사용 불가능해질 수 있음을 이해하세요. 자세한 내용은 Azure Files의 고객 관리 키를 참조하세요.

  • 적용 가능한 클래식 배포에 대한 인프라 암호화 평가: 준수 정책에 따라 클래식 스토리지 계정은 추가 암호화 계층을 가질 수 있습니다. 이 옵션은 계정 생성 시 선택되며 이후에는 변경할 수 없습니다. 지원되는 계정 유형에 대해서는 인프라 암호화를 참조하세요.

  • 관리 작업을 보호하기 위해 리소스 락을 사용하세요: 적절한 Azure 리소스나 부모 범위에 CanNotDelete 락을 적용하면 Azure Resource Manager를 통한 삭제를 방지할 수 있습니다. 잠금은 클라이언트가 파일 데이터를 수정하거나 삭제하는 것을 막지 않습니다. 클래식 공유의 경우, FileREST 데이터 플레인 API를 통한 삭제도 막지 못합니다. 잠금 동작과 운영 효과에 대해서는 Azure 리소스 잠금를 참조하세요.

백업 및 복구

  • 복구 필요에 따라 공유 스냅샷 작성: 두 리소스 제공자 모두 이전 파일 버전 복구를 위한 공유 스냅샷을 지원합니다. 회복 목표에 부합하는 일정과 유지 정책을 설정하세요. 공유 스냅샷은 원본 공유와 계속 연결되어 있어, 해당 공유가 영구적으로 삭제될 경우 독립적인 백업을 제공하지 않습니다. 자세한 내용은 Azure Files용 스냅샷 공유를 참조하세요.

  • 클래식 공유에 대해 소프트 삭제 활성화: 소프트 삭제는 지정된 기간 동안 삭제된 공유를 유지합니다. 개별 파일이나 개별적으로 삭제된 스냅샷을 복구하지 않습니다. Microsoft. FileShares는 현재 소프트 삭제를 지원하지 않습니다. 자세한 내용은 실수로 인한 Azure 파일 공유 삭제 방지를 참조하세요.

  • 프로토콜에서 지원하는 백업 솔루션을 선택하세요: Azure Backup은 클래식 SMB 공유를 지원하며, 스냅샷 및 볼트 백업 옵션을 제공합니다. 현재 두 리소스 제공자 중 어느 쪽과도 NFS 공유를 지원하지 않습니다. NFS의 경우, 프로토콜을 지원하고 보존 및 격리 요구사항을 충족하는 백업 솔루션을 선택하세요. Azure Backup 커버리지에 대해서는 Azure 파일 공유 백업 지원을 참조하세요.

  • 백업 관리와 테스트 복구를 분리: 복구 지점을 삭제하거나 보존 기간(정책)을 변경할 수 있는 사용자를 제한하세요. 파일, 권한 및 전체 워크로드의 테스트 복원. 프로덕션 자격 증명이나 소스 공유가 유출되었을 때 복구가 가능한지 확인하세요.

  • 인프라 장애에 대한 계획은 데이터 복구와 별도로 수립하세요: 중복성은 인프라 장애에 대한 회복력을 높이고 데이터 변경 사항을 복제합니다. 원치 않는 변경이나 삭제 시 백업을 대체하지 않습니다. 이용 가능한 중복 옵션은 미디어 계층과 리소스 제공자에 따라 다릅니다. 자세한 내용은 Azure Files 중복성을 참조하세요.

로깅 및 모니터링

  • 두 리소스 제공자 모두의 관리 변경 사항 감사: Azure 활동 로그를 사용해 리소스 삭제, 구성 변경, 역할 할당을 모니터링하세요. 공공 접근, 네트워크 규칙, 암호화 요구사항 및 복구 통제 변경 사항을 검토하세요. 자세한 내용은 Azure 활동 로그를 참조하세요.

  • 지원되는 데이터 접근 로그 수집: 클래식 SMB 및 FileREST 접근의 경우, 파일 서비스 리소스 로그를 사용하여 호출자, 권한 부여 방법, 실패한 요청, 삭제 활동을 검토합니다. 유지 정책에 따라 요구되는 로그는 Log Analytics나 다른 지원 대상에서 수집하세요. NFS 또는 Microsoft.FileShares에 대해 동일한 요청 로깅 범위라고 가정하지 마세요. 지원되는 연산과 필드에 대해서는 Azure Files 모니터링 데이터 참조를 참조하세요.

  • 알림을 클라이언트 및 신원 로그와 연관시키기: 예상치 못한 키 사용, 인증 실패, 공유 삭제, 보안 구성 변경 등을 조사하세요. 요청이 Azure Files에 도달하기 전에 인증 실패가 발생하면 클라이언트 및 디렉터리 로그를 사용하세요. 알림을 업무 담당 팀에 전달하세요.

  • 클래식 배포를 위한 Defender for Storage 평가: Defender for Storage는 지원되는 스토리지 계정에 대한 위협 탐지를 제공합니다. 배포에 맞는 기능과 프로토콜 커버리지를 확인하세요; 계정 보호가 모든 파일 작업이 악성코드 검사의 대상이 되는 것을 의미하지는 않습니다. 자세한 내용은 Microsoft Defender for Storage를 참조하세요.

규정 준수 및 거버넌스

  • 리소스 공급자에 맞는 정책을 적용하세요: Azure Policy를 사용하여 리소스 유형 및 속성이 지원되는 경우 조직의 요구 사항을 감사하거나 적용하세요. 각 정의의 범위와 효과를 확인하세요. Microsoft.Storage 스토리지 계정을 대상으로 하는 정책은 Microsoft.FileShares 리소스를 자동으로 평가하지 않습니다. 자세한 내용은 Azure Policy 정의를 참조하세요.

  • 기록 소유권 및 데이터 요구사항: 자원 태그를 사용하여 책임 팀, 환경, 데이터 분류를 식별합니다. 클래식 공유의 경우, 계정 수준의 제어가 계정 내 모든 공유에 영향을 미칩니다. 예외 사항을 기록하고 작업 책임이 바뀔 때 검토하세요.

  • 배포 시 준수 여부를 검증하세요: 선택한 서비스, 지역, 프로토콜 및 보호 기능이 요구사항을 충족하는지 확인하세요. Microsoft 클라우드 보안 벤치마크를 활용해 통제 검토를 정리하세요. 인증 정보는 Azure Storage 컴플라이언스 제공 항목을 참조하세요.

Azure 파일 동기화

Azure 파일 동기화는 클래식 SMB 공유를 지원합니다. NFS나 Microsoft.FileShares를 지원하지 않습니다. 클라우드 공유와 Windows Server 엔드포인트 모두를 보호하세요.

  • 지원되는 파일 동기화 배포에 관리되는 ID 사용: 스토리지 동기화 서비스와 등록된 서버의 관리되는 ID 구성을 따라 공유 키에 대한 의존성을 제거하세요. 자세한 내용은 Azure 파일 동기화에서 관리 된 아이덴티티 사용하기를 참조하세요.

  • 동기화 리소스 및 서버에 대한 관리자 액세스를 제한하세요: 필요한 스토리지 동기화 역할을 적절한 범위에서 사용하세요. 로컬 파일 권한과 서버 관리를 보호하세요. 서버 엔드포인트를 통한 변경 사항이 클라우드 공유와 동기화될 수 있기 때문입니다. 자세한 내용은 Azure 파일 동기화 배포 계획을 참조하세요.

다음 단계