WORM(Write Once, Read Many) 상태로 변경이 불가능한 스토리지를 사용하여 비즈니스에 중요한 Blob 데이터를 저장합니다.
Azure Blob Storage용 변경이 불가능한 스토리지를 사용하면 사용자가 중요 비즈니스용 데이터를 WORM(Write Once, Read Many) 상태로 저장할 수 있습니다. WORM 상태인 데이터는 사용자가 지정한 시간 동안 수정하거나 삭제할 수 없습니다. Blob 데이터에 대한 불변성 정책을 구성하면 데이터를 덮어쓰거나 삭제하지 못하도록 방지할 수 있습니다.
Azure Blob Storage에 대한 변경이 불가능한 스토리지는 다음과 같은 두 가지 유형의 불변성 정책을 지원합니다.
시간 기반 보존 정책: 시간 기반 보존 정책을 사용하면 사용자는 지정한 간격 동안 데이터를 저장하는 정책을 설정할 수 있습니다. 시간 기반 보존 정책을 설정하면 개체를 만들고 읽을 수 있지만, 수정하거나 삭제할 수는 없습니다. 보존 기간이 만료된 후에는 개체를 삭제할 수는 있지만 덮어쓸 수는 없습니다.
법적 보존 정책: 법적 보존은 명시적으로 제거될 때까지 변경이 불가능한 데이터를 저장합니다. 법적 보존을 설정하면 개체를 만들고 읽을 수 있지만, 수정하거나 삭제할 수는 없습니다.
이러한 정책은 서로 동시에 설정할 수 있습니다. 예를 들어, 사용자는 시간 기반 보존 정책과 법적 보존을 동일한 수준에서 동시에 설정할 수 있습니다. 쓰기가 성공하려면 버전 관리를 사용하도록 설정하거나 데이터에 대한 법적 보존 또는 시간 기반 보존 정책이 없어야 합니다. 삭제가 성공하려면 데이터에 대한 법적 보존 또는 시간 기반 보존 정책도 없어야 합니다.
다음 다이어그램은 시간 기반 보존 정책 및 법적 보존이 적용되는 동안 쓰기 및 삭제 작업을 방지하는 방법을 보여 줍니다.
변경이 불가능한 스토리지에는 컨테이너 수준 WORM과 버전 수준 WORM이라는 두 가지 기능이 있습니다. 컨테이너 수준 WORM을 사용하면 컨테이너 수준에서만 정책을 설정할 수 있는 반면, 버전 수준 WORM을 사용하면 계정, 컨테이너 또는 버전 수준에서 정책을 설정할 수 있습니다.
Blob에 대한 변경이 불가능한 스토리지
변경이 불가능한 스토리지는 의료 기관, 금융 기관 및 관련 산업, 특히 중개인 및 딜러 조직이 데이터를 안전하게 저장하는 데 도움이 됩니다. 수정 또는 삭제로부터 중요한 데이터를 보호하기 위해 변경이 불가능한 스토리지는 모든 시나리오에서 사용할 수 있습니다.
일반적인 적용 분야는 다음과 같습니다.
규정 준수: Azure Blob Storage에 대한 변경 불가능한 스토리지를 사용하면 SEC 17a-4(f), CFTC 1.31(d), FINRA 및 기타 규정을 처리할 수 있습니다.
보안 문서 보존: Blob에 대한 변경이 불가능한 스토리지를 사용하면 계정 관리 권한이 있는 사용자를 포함하여 그 어떤 사용자도 데이터를 수정하거나 삭제할 수 없습니다.
법적 보존: Blob에 대한 변경이 불가능한 스토리지를 사용하면 사용자는 법적 보존이 제거되기 전에는 소송 또는 비즈니스 사용에 중요한 정보를 원하는 기간 동안 변조가 불가능한 상태로 저장할 수 있습니다. 이 기능은 법률 사용 사례로 국한되지 않지만 이벤트 트리거 또는 엔터프라이즈 정책을 기반으로 데이터를 보호해야 하는 이벤트 기반 보존 또는 엔터프라이즈 잠금으로 간주할 수도 있습니다.
규정 준수
Microsoft는 레코드 관리 및 정보 거버넌스를 전문으로 하는 선도적인 독립 평가 회사인 Cohasset Associates를 유지하여 변경이 불가능한 Blob Storage와 금융 서비스 산업에 특정한 요구 사항을 준수하는지 평가했습니다. Cohasset에서는 Blob을 WORM 상태로 유지하는 데 사용되는 변경이 불가능한 스토리지가 CFTC Rule 1.31(c)-(d), FINRA Rule 4511 및 SEC Rule 17a-4의 관련 스토리지 요구 사항을 충족하는 것을 확인했습니다. Microsoft는 금융 기관의 기록 보존과 관련하여 전 세계적으로 가장 규범적인 지침을 제시하는 이 규칙 세트를 목표로 삼았습니다.
Cohasset 보고서는 Microsoft 서비스 보안 센터에서 확인할 수 있습니다. Azure 보안 센터에는 Microsoft의 규정 준수 인증에 대한 자세한 정보가 포함되어 있습니다. WORM 불변성 준수와 관련하여 Microsoft로부터 증명 서신을 요청하려면 Azure 지원에 문의하세요.
시간 기반 보존 정책
시간 기반 보존 정책은 지정된 간격 동안 WORM 형식으로 Blob 데이터를 저장합니다. 시간 기반 보존 정책이 설정되면 클라이언트에서 Blob을 만들고 읽을 수 있지만 수정하거나 삭제할 수는 없습니다. 보존 간격이 만료되면 Blob을 삭제할 수 있지만 덮어쓸 수는 없습니다.
범위
시간 기반 보존 정책은 다음 범위에서 구성할 수 있습니다.
- 버전 수준 WORM 정책: 시간 기반 보존 정책은 계정, 컨테이너 또는 버전 수준에서 구성할 수 있습니다. 계정 또는 컨테이너 수준에서 구성된 경우 해당 계정 또는 컨테이너의 모든 Blob에서 상속됩니다. 컨테이너에 법적 보존이 있는 경우 동일한 컨테이너에 대한 버전 수준 WORM을 만들 수 없습니다. 이는 법적 보존으로 인해 버전을 생성할 수 없기 때문입니다.
- 컨테이너 수준 WORM 정책: 컨테이너 수준에서 구성된 시간 기반 보존 정책은 해당 컨테이너의 모든 Blob에 적용됩니다. 개별 Blob은 자체 불변성 정책으로 구성할 수 없습니다.
시간 기반 정책의 보존 간격
시간 기반 보존 정책의 최소 보존 간격은 1일이고, 최댓값은 146,000일(400년)입니다. 시간 기반 보존 정책을 구성하면 영향을 받는 개체가 유효 보존 기간 동안 변경할 수 없는 상태로 유지됩니다. 개체의 유효 보존 기간은 Blob을 만든 시간과 사용자가 지정 보존 간격의 차이와 같습니다. 정책의 보존 간격을 연장할 수 있으므로 변경이 불가능한 스토리지는 사용자가 지정한 보존 간격의 가장 최근 값을 사용하여 유효 보존 기간을 계산합니다.
예를 들어 사용자가 보존 기간 5년의 시간 기반 보존 정책을 만든다고 가정합니다. 해당 컨테이너의 기존 testblob1 Blob이 1년 전에 만들어졌으므로 testblob1의 유효 보존 기간은 4년입니다. 새 testblob2 Blob이 컨테이너에 업로드되면 testblob2의 유효 보존 기간은 만든 시점으로부터 5년입니다.
잠긴 정책 및 잠금 해제된 정책
시간 기반 보존 정책을 처음 구성하면 테스트 목적으로 정책이 잠금 해제됩니다. 테스트가 끝나면 정책이 SEC 17a-4(f) 및 기타 규정 준수를 완전히 규정 준수하도록 정책을 잠글 수 있습니다.
잠긴 정책 및 잠금 해제된 정책은 모두 삭제 및 덮어쓰기로부터 보호합니다. 그러나 잠금 해제된 정책은 보존 기간을 줄이거나 늘려서 수정할 수 있습니다. 잠금 해제된 정책을 삭제할 수도 있습니다. 잠긴 시간 기반 보존 정책은 삭제할 수 없습니다. 보존 기간은 연장할 수 있지만 단축할 수는 없습니다. 컨테이너 수준에서 정의된 잠긴 정책의 수명 동안 유효 보존 기간을 최대 5회 늘릴 수 있습니다. Blob 버전에 대해 구성된 정책의 경우 유효 기간 증가 횟수에 제한이 없습니다.
Important
SEC 17a-4(f) 및 기타 규정을 준수하도록 Blob을 규격을 준수하고 변경할 수 없는 상태(쓰기 및 삭제 금지)로 유지하려면 시간 기반 보존 정책을 잠가야 합니다. 적절한 시간(일반적으로 24시간 이내)에 정책을 잠그는 것이 좋습니다. 잠금 해제된 상태는 불변성 보호를 제공하지만, 단기 테스트 이외의 용도로 잠금 해제된 상태를 사용하지 않는 것이 좋습니다.
보존 정책 감사 로깅
시간 기반 보존 정책이 사용하도록 설정된 각 컨테이너는 정책 감사 로그를 제공합니다. 감사 로그에는 잠긴 시간 기반 보존 정책에 대한 최대 7개의 시간 기반 보존 명령이 포함됩니다. 일반적으로 정책을 잠그면 로깅이 시작됩니다. 로그 항목에는 사용자 ID, 명령 유형, 타임스탬프 및 보존 간격이 포함됩니다. 감사 로그는 SEC 17a-4(f) 규정 지침에 따라 정책의 수명 동안 보존됩니다.
Azure 활동 로그는 모든 관리 서비스 활동에 대한 더 포괄적인 로그를 제공합니다. Azure 리소스 로그는 데이터 작업에 대한 정보를 유지합니다. 이러한 로그는 규정 또는 다른 목적으로 필요할 수 있으므로 사용자가 이러한 로그를 영구적으로 저장할 책임이 있습니다.
버전 수준에서 시간 기반 보존 정책에 대한 변경 내용은 감사되지 않습니다.
법적 보존
법적 보존은 법적 조사 목적 또는 일반 보호 정책에 적용할 수 있는 일시적인 불변성 정책입니다. 법적 보존은 보존이 명시적으로 지워질 때까지 WORM(Write-Once, Read-Many) 형식으로 Blob 데이터를 저장합니다. 법적 보존을 적용하면 BLOB를 만들고 읽을 수 있지만, 수정하거나 삭제할 수는 없습니다. 데이터를 WORM 상태로 유지해야 하는 기간을 알 수 없는 경우 법적 보존을 사용합니다.
범위
법적 보존 정책은 다음 범위 중 하나에서 구성할 수 있습니다.
버전 수준 WORM 정책: 중요한 데이터의 세부적 관리를 위해 개별 BLOB 버전 수준에 대해 법적 보존을 구성할 수 있습니다.
컨테이너 수준 WORM 정책: 컨테이너 수준에서 구성된 법적 보존은 해당 컨테이너의 모든 BLOB에 적용됩니다. 개별 Blob은 자체 불변성 정책으로 구성할 수 없습니다.
태그
컨테이너 수준 법적 보존은 식별자 문자열 역할을 하는 하나 이상의 사용자 정의 영숫자 태그와 연결되어야 합니다. 예를 들어, 태그에는 사례 ID 또는 이벤트 이름이 포함될 수 있습니다.
감사 로깅
법적 보존이 적용된 각각의 컨테이너는 정책 감사 로그를 제공합니다. 로그에는 사용자 ID, 명령 유형, 타임스탬프 및 법적 보존 태그가 포함됩니다. 감사 로그는 SEC 17a-4(f) 규정 지침에 따라 정책의 수명 동안 보존됩니다.
Azure 활동 로그는 모든 관리 서비스 활동에 대한 더 포괄적인 로그를 제공합니다. Azure 리소스 로그는 데이터 작업에 대한 정보를 유지합니다. 이러한 로그는 규정 또는 다른 목적으로 필요할 수 있으므로 사용자가 이러한 로그를 영구적으로 저장할 책임이 있습니다.
버전 수준의 법적 보존에 대한 변경 내용은 감사되지 않습니다.
변경이 불가능한 스토리지 기능 옵션
다음 표에는 컨테이너 수준 WORM과 버전 수준 WORM 간의 차이점이 자세히 나와 있습니다.
| 범주 | 컨테이너 수준 WORM | 버전 수준 WORM |
|---|---|---|
| 정책 세분성 수준 | 정책은 컨테이너 수준에서만 구성할 수 있습니다. 컨테이너에 업로드된 각 개체는 변경이 불가능한 정책 집합을 상속합니다. | 정책은 계정, 컨테이너 또는 Blob 수준에서 구성할 수 있습니다. 정책이 계정 수준에서 설정된 경우 해당 계정에 업로드된 모든 Blob은 정책을 상속합니다. 컨테이너에도 동일한 논리가 적용됩니다. 정책이 여러 수준으로 설정된 경우 우선 순위는 항상 Blob -> 컨테이너 -> 계정입니다. |
| 사용 가능한 정책 형식 | 컨테이너 수준에서는 시간 기반 보존 정책과 법적 보존이라는 두 가지 형식의 정책을 설정할 수 있습니다. | 계정 및 컨테이너 수준에서는 시간 기반 보존 정책만 설정할 수 있습니다. Blob 수준에서는 시간 기반 보존 정책과 법적 보존을 모두 설정할 수 있습니다. |
| 기능 종속성 | 다른 함수는 이 함수가 작동하기 위한 필수 조건이나 요구 사항이 아닙니다. | 버전 관리는 이 기능을 사용하기 위한 필수 조건입니다. |
| 기존 계정/컨테이너 사용 | 이 기능은 기존 컨테이너에 대해 언제든지 사용하도록 설정할 수 있습니다. | 세분성 수준에 따라 이 기능은 모든 기존 계정/컨테이너에 대해 사용하도록 설정되지 않을 수 있습니다. |
| 계정/컨테이너 삭제 | 시간 기반 보존 정책이 컨테이너에 잠기면 컨테이너는 비어 있는 경우에만 삭제할 수 있습니다. | 버전 수준 WORM이 계정 또는 컨테이너 수준에서 사용하도록 설정되면 비어 있는 경우에만 삭제할 수 있습니다. |
| Azure Data Lake Storage 지원(계층 구조 네임스페이스가 사용하도록 설정된 스토리지 계정) | 컨테이너 수준 WORM 정책은 계층 구조 네임스페이스가 있는 계정에서 지원됩니다. | 버전 수준 WORM 정책은 계층 구조 네임스페이스가 있는 계정에서는 아직 지원되지 않습니다. |
컨테이너 수준 WORM에 대해 자세히 알아보려면 컨테이너 수준 WORM 정책을 참조하세요. 버전 수준 WORM에 대해 자세히 알아보려면 버전 수준 WORM 정책을 참조하세요.
컨테이너 수준과 버전 수준 WORM
다음 표는 사용할 WORM 정책 형식을 결정하는 데 도움이 됩니다.
| 기준 | 컨테이너 수준 WORM 사용 | 버전 수준 WORM 사용법 |
|---|---|---|
| 데이터의 구성 | 컨테이너별로 분류할 수 있는 특정 데이터 세트에 대한 정책을 설정하려고 합니다. 해당 컨테이너의 모든 데이터는 동일한 시간 동안 WORM 상태로 유지되어야 합니다. | 보존 기간별로 개체를 그룹화할 수 없습니다. 모든 Blob은 해당 Blob의 시나리오에 따라 개별 보존 시간으로 저장되어야 합니다. 그렇지 않으면 사용자의 워크로드가 혼합되어 있어 일부 데이터 그룹은 컨테이너로 클러스터링될 수 있지만 다른 Blob은 클러스터링될 수 없습니다. 동일한 계정 내에서 컨테이너 수준 정책과 Blob 수준 정책을 설정할 수도 있습니다. |
| 변경이 불가능한 정책이 필요한 데이터의 양 | 계정당 10,000개가 넘는 컨테이너에 정책을 설정할 필요는 없습니다. | 계정별로 구분할 수 있는 모든 데이터 또는 대량의 데이터에 대해 정책을 설정하려고 합니다. 컨테이너 수준 WORM을 사용하는 경우 10,000개 컨테이너 제한을 초과해야 한다는 것을 알고 있습니다. |
| 버전 관리 사용 설정에 대한 관심 | 비용 때문에 또는 워크로드로 인해 처리할 추가 버전 관리가 많이 만들어지기 때문에 버전 관리를 사용하도록 설정하고 싶지 않습니다. | 버전 관리를 사용하고 싶거나 사용하지 않아도 됩니다. 버전 관리를 사용하도록 설정하지 않으면 변경 불가능한 Blob에 대한 편집 내용이나 덮어쓰기를 별도의 버전 관리로 유지할 수 없다는 것을 알고 있습니다. |
| 스토리지 위치(Blob Storage 및 Data Lake Storage) | 워크로드는 전적으로 Azure Data Lake Storage에 집중됩니다. 계층 구조 네임스페이스 기능이 사용하도록 설정되지 않은 계정을 사용하는 데 즉각적인 관심이 없거나 전환할 계획이 없습니다. | 워크로드가 계층 구조 네임스페이스 기능이 활성화되지 않은 계정의 Blob Storage에 있고 지금 버전 수준 WORM을 사용할 수 있습니다. 또는 계층 구조 네임스페이스가 활성화된 계정(Azure Data Lake Storage)에 대해 버전 관리를 사용할 수 있을 때까지 기다릴 의향이 있습니다. |
액세스 계층
모든 Blob 액세스 계층은 변경이 불가능한 스토리지를 지원합니다. Blob 계층 설정 작업을 사용하여 Blob의 액세스 계층을 변경할 수 있습니다. 자세한 내용은 Blob 데이터에 대한 액세스 계층을 참조하세요.
중복성 구성
모든 중복성 구성은 변경이 불가능한 스토리지를 지원합니다. 중복성 구성에 대한 자세한 내용은 Azure Storage 중복성을 참조하세요.
권장하는 Blob 유형
주로 블록 Blob 및 Blob 추가에 대해 불변성 정책을 구성하는 것이 좋습니다. 활성 가상 머신에 대한 VHD 디스크를 저장하는 페이지 Blob에 대한 불변성 정책을 구성하는 것은 디스크에 대한 쓰기가 차단되거나 버전 관리가 사용하도록 설정된 경우 각 쓰기가 새 버전 관리로 저장되므로 권장되지 않습니다. 시간 기반 정책을 잠그기 전에 설명서를 철저히 검토하고 시나리오를 테스트하는 것이 좋습니다.
Blob 일시 삭제를 사용하는 변경이 불가능한 스토리지
스토리지 계정에 대해 Blob 일시 삭제를 구성하면 법적 보존 또는 시간 기반 보존 정책이 적용되는지 여부와 관계없이 계정 내의 모든 Blob에 일시 삭제가 적용됩니다. 불변성 정책을 적용하기 전에 추가 보호를 위해 일시 삭제를 사용하도록 설정하는 것이 좋습니다.
Blob 일시 삭제를 사용하도록 설정한 후에 불변성 정책을 구성하면 일시 삭제 보존 정책이 만료된 후에도 일시 삭제된 Blob이 영구적으로 삭제됩니다. 일시 삭제된 Blob은 일시 삭제 보존 기간 동안 복원할 수 있습니다. 아직 일시 삭제되지 않은 Blob 또는 버전은 불변성 정책으로 보호되며 시간 기반 보존 정책이 만료되거나 법적 보존이 제거될 때까지 일시 삭제될 수 없습니다.
Blob 인벤토리를 사용하여 불변성 정책 추적
Azure Storage Blob 인벤토리는 스토리지 계정의 컨테이너와 그 안에 들어 있는 Blob, 스냅샷 및 Blob 버전의 개요를 제공합니다. Blob 인벤토리 보고서를 사용하여 리소스에 대한 불변성 정책이 구성되었는지 여부를 포함하여 Blob 및 컨테이너의 특성을 이해할 수 있습니다.
Blob 인벤토리를 사용하도록 설정하면 Azure Storage는 매일 인벤토리 보고서를 생성합니다. 이 보고서는 비즈니스 및 규정 준수 요구 사항에 대한 데이터 개요를 제공합니다.
Blob 인벤토리에 대한 자세한 내용은 Azure Storage Blob 인벤토리를 참조하세요.
참고 항목
해당 계정에서 버전 수준 불변성에 대한 지원이 사용하도록 설정되어 있거나 인벤토리 정책에 정의된 대상 컨테이너에서 버전 수준 불변성에 대한 지원이 사용하도록 설정된 경우 계정에서 인벤토리 정책을 구성할 수 없습니다.
대규모 정책 구성
스토리지 작업을 사용하면 정의한 조건 집합을 기반으로 여러 스토리지 계정에 걸쳐 대규모 불변성 정책을 구성할 수 있습니다. 스토리지 작업은 Azure 스토리지 작업에서 사용할 수 있는 리소스입니다. 여러 스토리지 계정에 걸쳐 수백만 개의 개체에 대해 일반적인 데이터 작업을 수행하는 데 사용할 수 있는 서버리스 프레임워크입니다. 자세히 알아보려면 Azure 스토리지 작업이란?을 참조하세요.
가격 책정
변경이 불가능한 스토리지 사용에 따른 추가 용량 요금은 없습니다. 변경할 수 없는 데이터는 변경할 수 있는 데이터와 동일한 방식으로 가격이 책정됩니다. 버전 관리 수준 WORM을 사용하는 경우 버전 관리를 사용하도록 설정했기 때문에 청구 금액이 더 높을 수 있으며 추가 버전 관리 저장과 관련된 비용이 있습니다. 자세한 내용은 버전 관리 가격 책정 정책을 검토합니다. Azure Blob Storage의 가격 책정에 대한 자세한 내용은 Azure Storage 가격 책정 페이지를 참조하세요.
Blob 버전에 대한 시간 기반 보존 정책 또는 법적 보존을 만들거나, 수정하거나, 삭제하면 쓰기 트랜잭션 요금이 발생합니다.
요금을 지불하지 않고 계정에서 활성 시간 기반 보존 정책이 적용되면 Microsoft와 맺은 계약조건에 규정된 대로 일반 데이터 보존 정책이 적용됩니다. 일반 정보는 Microsoft의 데이터 관리를 참조하세요.
기능 지원
이 기능은 특정 시점 복원 및 마지막 액세스 추적과 호환되지 않습니다. 이 기능은 고객이 관리하는 계획되지 않은 장애 조치(failover)와 호환되지만 마지막 동기화 시간 이후 변경할 수 없는 정책에 대한 모든 변경 사항(예: 시간 기반 보존 정책 잠금, 연장 등)은 보조 지역에 동기화되지 않습니다. 장애 조치(failover)가 완료되면 보조 지역에 대한 변경 내용을 다시 실행하여 불변성 요구 사항을 최신 상태로 유지할 수 있습니다. NFS(네트워크 파일 시스템) 3.0 프로토콜 또는 SFTP(SSH 파일 전송 프로토콜)가 사용하도록 설정된 계정에서는 불변성 정책이 지원되지 않습니다.
URL에 SQL 백업과 같은 일부 워크로드는 Blob을 만든 다음 추가합니다. 컨테이너에 활성 시간 기반 보존 정책이나 법적 보존이 있는 경우 이 패턴은 성공하지 못합니다. 자세한 내용은 보호된 추가 Blob 쓰기 허용을 참조하세요.
자세한 내용은 Azure Storage 계정의 Blob Storage 기능 지원을 참조하세요.