BLOB 데이터에 대한 익명 읽기 권한 문제 수정(Azure Resource Manager 배포)
Azure Blob Storage는 컨테이너 및 BLOB에 대한 선택적 익명 읽기 권한을 지원합니다. 그러나 익명 액세스는 보안 위험을 초래할 수 있습니다. 최적의 보안을 위해 익명 액세스를 사용하지 않도록 설정하는 것이 좋습니다. 익명 액세스를 허용하지 않으면 원치 않는 익명 액세스로 인한 데이터 위반을 방지할 수 있습니다.
기본적으로 BLOB 데이터에 대한 공용 액세스는 항상 금지됩니다. Azure Resource Manager 스토리지 계정에 대한 기본 구성은 사용자가 스토리지 계정의 컨테이너 및 BLOB에 대해 익명 액세스를 구성하는 것을 금지합니다. 이 기본 구성은 개별 컨테이너에 대한 액세스 설정에 관계없이 Azure Resource Manager 스토리지 계정에 대한 모든 익명 액세스를 허용하지 않습니다.
스토리지 계정에 대한 익명 액세스가 허용되지 않으면 Azure Storage는 BLOB 데이터에 대한 모든 익명 읽기 요청을 거부합니다. 사용자는 나중에 해당 계정의 컨테이너에 대한 익명 액세스를 구성할 수 없습니다. 이미 익명 액세스가 가능하도록 구성된 컨테이너가 있으면 더 이상 익명 요청을 수락하지 않습니다.
Warning
컨테이너가 익명 액세스용으로 구성된 경우 모든 클라이언트가 해당 컨테이너의 데이터를 읽을 수 있습니다. 익명 액세스를 사용하면 보안 위험이 발생할 수 있으므로 시나리오에 필요하지 않다면 스토리지 계정에 익명 액세스를 허용하지 않는 것이 좋습니다.
Azure Resource Manager 및 클래식 스토리지 계정에 대한 수정
이 문서에서는 DRAG(Detection-Remediation-Audit-Governance) 프레임워크를 사용하여 Azure Resource Manager 배포 모델을 사용하는 스토리지 계정의 익명 액세스를 지속적으로 관리하는 방법을 설명합니다. 모든 범용 v2 스토리지 계정, 프리미엄 블록 Blob Storage 계정, 프리미엄 파일 공유 계정, Blob Storage 계정은 Azure Resource Manager 배포 모델을 사용합니다. 일부 이전 범용 v1 계정 및 프리미엄 페이지 Blob 계정은 클래식 배포 모델을 사용할 수 있습니다.
스토리지 계정이 클래식 배포 모델을 사용하는 경우 가능한 한 빨리 Azure Resource Manager 배포 모델로 마이그레이션하는 것이 좋습니다. 클래식 배포 모델을 사용하는 Azure Storage 계정은 2024년 8월 31일에 만료됩니다. 자세한 내용은 Azure 클래식 스토리지 계정이 2024년 8월 31일에 사용 중지됨을 참조하세요.
현재 클래식 스토리지 계정을 마이그레이션할 수 없는 경우 지금 해당 계정에 대한 익명 액세스를 수정해야 합니다. 클래식 스토리지 계정에 대한 익명 액세스 문제를 수정하는 방법을 알아보려면 Blob 데이터에 대한 익명 읽기 권한 문제 수정(클래식 배포)을 참조하세요. Azure 배포 모델에 대한 자세한 내용은 Resource Manager 및 클래식 배포를 참조하세요.
익명 읽기 권한 정보
기본값으로 데이터에 대한 익명 액세스는 항상 금지됩니다. 익명 액세스에 영향을 주는 두 가지 개별 설정이 있습니다.
스토리지 계정에 대한 익명 액세스 설정. Azure Resource Manager 스토리지 계정은 계정에 대한 익명 액세스를 허용 또는 불허하는 설정을 제공합니다. 최적의 보안을 위해 스토리지 계정에 대한 익명 액세스를 허용하지 않는 것이 좋습니다.
계정 수준에서 익명 액세스가 허용되는 경우 사용자가 컨테이너의 익명 액세스 설정을 명시적으로 구성하는 추가 단계를 수행하지 않은 한 익명 읽기 권한에 BLOB 데이터를 사용할 수 없습니다.
컨테이너의 익명 액세스 설정을 구성합니다. 기본값으로 컨테이너의 익명 액세스 설정은 사용하지 않도록 설정됩니다. 즉, 컨테이너 또는 해당 데이터에 대한 모든 요청에 대한 권한 부여가 필요합니다. 적절한 권한이 있는 사용자는 컨테이너의 익명 액세스 설정을 수정하여 스토리지 계정에 대한 익명 액세스가 허용되는 경우에만 익명 액세스를 사용하도록 설정할 수 있습니다.
다음 표에는 두 설정이 컨테이너에 대한 익명 액세스에 어떻게 영향을 주는지 요약되어 있습니다.
| 컨테이너에 대한 익명 액세스 수준이 프라이빗(기본 설정)으로 설정됨 | 컨테이너에 대한 익명 액세스 수준이 컨테이너로 설정됨 | 컨테이너에 대한 익명 액세스 수준이 BLOB로 설정됨 | |
|---|---|---|---|
| 스토리지 계정에 대한 익명 액세스가 허용되지 않음 | 스토리지 계정의 모든 컨테이너에 대한 익명 액세스 권한이 없습니다. | 스토리지 계정의 모든 컨테이너에 대한 익명 액세스 권한이 없습니다. 스토리지 계정 설정은 컨테이너 설정을 재정의합니다. | 스토리지 계정의 모든 컨테이너에 대한 익명 액세스 권한이 없습니다. 스토리지 계정 설정은 컨테이너 설정을 재정의합니다. |
| 스토리지 계정에 대한 익명 액세스가 허용됨 | 이 컨테이너에 대한 익명 액세스 권한이 없습니다(기본 구성). | 이 컨테이너 및 해당 BLOB에 대한 익명 액세스가 허용됩니다. | 이 컨테이너의 Blob에는 익명 액세스가 허용되지만 컨테이너 자체에는 허용되지 않습니다. |
스토리지 계정에 대해 익명 액세스가 허용되고 특정 컨테이너에 대해 구성된 경우 ‘Authorization’ 헤더 없이 전달된 해당 컨테이너의 Blob 읽기 요청이 서비스에서 수락되고 Blob의 데이터 응답으로 반환됩니다.
클라이언트 애플리케이션의 익명 요청 감지
스토리지 계정에 대한 익명 읽기 권한을 허용하지 않으면 현재 익명 액세스용으로 구성된 컨테이너 및 Blob에 대한 요청이 거부될 위험이 있습니다. 스토리지 계정에 대한 익명 액세스를 불허하면 해당 스토리지 계정의 개별 컨테이너에 대한 액세스 설정이 재정의됩니다. 스토리지 계정에 대한 익명 액세스가 허용되지 않는 경우 해당 계정에 대한 모든 익명 요청은 실패합니다.
익명 액세스를 허용하지 않을 경우 클라이언트 애플리케이션에 미치는 영향을 파악하려면 해당 계정에 대한 로깅 및 메트릭을 사용하도록 설정하고 일정 시간 간격에 따른 익명 요청 패턴을 분석하는 것이 좋습니다. 메트릭을 사용하여 스토리지 계정에 대한 익명 요청 수를 확인하고 로그를 사용하여 익명으로 액세스되는 컨테이너를 확인합니다.
메트릭 탐색기를 사용하여 익명 요청 모니터링
스토리지 계정에 대한 익명 요청을 추적하려면 Azure Portal에서 Azure 메트릭 탐색기를 사용합니다. 메트릭 탐색기에 대한 자세한 내용은 Azure Monitor 메트릭 탐색기로 메트릭 분석을 참조하세요.
익명 요청을 추적하는 메트릭을 만들려면 다음 단계를 수행합니다.
Azure Portal의 스토리지 계정으로 이동합니다. 모니터링 섹션에서 메트릭을 선택합니다.
메트릭 추가를 선택합니다. 메트릭 대화 상자에서 다음 값을 지정합니다.
- 범위 필드는 스토리지 계정의 이름으로 설정된 상태로 둡니다.
- 메트릭 네임스페이스를 Blob으로 설정합니다. 이 메트릭은 Blob Storage에 대한 요청만 보고합니다.
- 메트릭 필드를 Transactions로 설정합니다.
- 집계 필드는 Sum으로 설정합니다.
새 메트릭은 지정된 시간 간격 동안 Blob Storage에 대한 트랜잭션 수의 합계를 표시합니다. 결과 메트릭은 다음 이미지와 같이 나타납니다.
다음으로 필터 추가 버튼을 선택하여 익명 요청에 대한 메트릭에 필터를 만듭니다.
필터 대화 상자에서 다음 값을 지정합니다.
- 속성 값을 Authentication으로 설정합니다.
- 연산자 필드를 등호(=)로 설정합니다.
- 드롭다운에서 값 필드를 선택하거나 입력하여 값 필드를 익명으로 설정합니다.
오른쪽 위 모서리에서 메트릭을 보려는 시간 간격을 선택합니다. 간격을 1분에서 1개월 사이로 지정하여 요청 집계의 세분화 정도를 나타낼 수도 있습니다.
메트릭을 구성하면 익명 요청이 그래프에 나타나기 시작합니다. 다음 이미지는 지난 30분 동안 집계된 익명 요청을 보여 줍니다.
스토리지 계정에 대해 특정 수의 익명 요청이 있을 때 알려주도록 경고 규칙을 구성할 수도 있습니다. 자세한 내용은 Azure Monitor를 사용하여 메트릭 경고 만들기, 보기 및 관리를 참조하세요.
로그를 분석하여 익명 요청을 받는 컨테이너 식별
Azure Storage 로그는 스토리지 계정에 대한 요청의 세부 정보(요청에 권한이 부여된 방법 포함)를 캡처합니다. 로그를 분석하여 익명 요청을 받은 컨테이너를 확인할 수 있습니다.
익명 요청을 평가하기 위해 Azure Storage 계정에 요청을 로그하려면 Azure Monitor에서 Azure Storage 로깅을 사용하면 됩니다. 자세한 내용은 Azure Storage 모니터링을 참조하세요.
Azure Monitor의 Azure Storage 로깅은 로그 쿼리를 사용하여 로그 데이터를 분석하도록 지원합니다. 로그를 쿼리하려면 Azure Log Analytics 작업 영역을 사용사면 됩니다. 로그 쿼리에 대해 자세히 알아보려면 자습서: Log Analytics 쿼리 시작하기를 참조하세요.
Azure Portal에서 진단 설정 만들기
Azure Monitor를 사용하여 Azure Storage 데이터를 기록하고 Azure Log Analytics를 사용하여 분석하려면 먼저 어떤 유형의 요청과 데이터를 기록하려는 스토리지 서비스를 나타내는 진단 설정을 생성해야 합니다. Azure Portal에서 진단 설정을 만들려면 다음 단계를 수행합니다.
Azure Storage 계정을 포함하는 구독의 새 로그 분석 작업 영역을 생성합니다. 스토리지 계정에 대한 로깅을 구성하면 Log Analytics 작업 영역에서 로그를 사용할 수 있습니다. 자세한 내용은 Azure Portal에서 Log Analytics 작업 영역 만들기를 참조하세요.
Azure Portal의 스토리지 계정으로 이동합니다.
모니터링 섹션에서 진단 설정을 선택합니다..
Blob Storage에 대한 요청을 기록하려면 Blob을 선택합니다.
진단 설정 추가를 선택합니다.
진단 설정의 이름을 제공합니다.
범주 세부 정보의 로그 섹션에서 로깅할 요청 유형을 선택합니다. 모든 익명 요청은 읽기 요청이므로 익명 요청을 캡처하려면 StorageRead를 선택합니다.
대상 세부 정보에서 Log Analytics에 보내기를 선택합니다. 다음 이미지와 같이, 구독 및 이전에 만든 Log Analytics 작업 영역을 선택합니다.
진단 설정을 만든 후에는 이 설정에 따라 스토리지 계정에 대한 요청이 로그됩니다. 자세한 내용은 Azure에서 리소스 로그 및 메트릭을 수집하기 위한 진단 설정 만들기를 참조하세요.
Azure Monitor의 Azure Storage 로그에서 사용할 수 있는 필드 참조는 리소스 로그를 참조하세요.
익명 요청에 대한 로그 쿼리
Azure Monitor의 Azure Storage 로그에는 스토리지 계정에 요청하는 데 사용된 권한 부여 유형이 포함됩니다. 로그 쿼리에서 AuthenticationType 속성을 필터링하여 익명 요청을 볼 수 있습니다.
Blob Storage에 대한 익명 요청의 지난 7일간 로그를 검색하려면 Log Analytics 작업 영역을 엽니다. 그 후 다음 쿼리를 새 로그 쿼리에 붙여넣고 실행합니다.
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
이 쿼리를 기반으로 익명 요청에 대해 알리도록 경고 규칙을 구성할 수도 있습니다. 자세한 내용은 Azure Monitor를 사용하여 로그 경고 만들기, 보기 및 관리를 참조하세요.
익명 요청에 대한 응답
Blob Storage가 익명 요청을 받을 때 다음 조건이 모두 충족되면 요청이 성공합니다.
- 스토리지 계정에 익명 액세스가 허용됩니다.
- 대상 컨테이너가 익명 액세스를 허용하도록 구성됩니다.
- 읽기 권한에 대한 요청입니다.
이러한 조건 중 하나라도 충족되지 않으면 요청이 실패합니다. 실패 시 응답 코드는 전달자 챌린지를 지원하는 서비스 버전으로 익명 요청이 이루어졌는지 여부에 따라 달라집니다. 전달자 챌린지는 서비스 버전 2019-12-12 이상에서 지원됩니다.
- 전달자 챌린지를 지원하는 서비스 버전으로 익명 요청을 수행한 경우 서비스는 오류 코드 401(권한 없음)을 반환합니다.
- 전달자 챌린지를 지원하지 않는 서비스 버전으로 익명 요청이 수행되고 스토리지 계정에 대한 익명 액세스가 허용되지 않는 경우 서비스는 오류 코드 409(충돌)를 반환합니다.
- 전달자 챌린지를 지원하지 않는 서비스 버전으로 익명 요청이 수행되고 스토리지 계정에 대한 익명 액세스가 허용되는 경우 서비스는 오류 코드 404(찾을 수 없음)를 반환합니다.
전달자 챌린지에 대한 자세한 내용은 전달자 챌린지를 참조하세요.
스토리지 계정에 대한 익명 액세스 수정
스토리지 계정의 컨테이너 및 Blob에 대한 익명 요청을 평가한 후에는 계정의 AllowBlobPublicAccess 속성을 False로 설정하여 전체 계정에 대한 익명 액세스를 수정하는 작업을 수행할 수 있습니다.
스토리지 계정에 대한 익명 액세스 설정은 해당 계정의 컨테이너에 대한 개별 설정을 재정의합니다. 스토리지 계정에 대한 익명 액세스를 허용하지 않으면 익명 액세스를 허용하도록 구성된 모든 컨테이너에 더 이상 익명으로 액세스할 수 없습니다. 계정에 대한 익명 액세스를 허용하지 않은 경우 개별 컨테이너에 대해 익명 액세스를 사용하지 않도록 설정할 필요가 없습니다.
시나리오에서 특정 컨테이너를 익명 액세스에 사용할 수 있어야 하는 경우 해당 컨테이너와 해당 Blob을 익명 액세스용으로 예약된 별도의 스토리지 계정으로 이동해야 합니다. 그런 다음, 다른 스토리지 계정에 대한 익명 액세스를 허용하지 않으면 됩니다.
익명 액세스를 수정하려면 Azure Storage 리소스 공급자 2019-04-01 이상 버전이 필요합니다. 자세한 내용은 Azure Storage 리소스 공급자 REST API를 참조하세요.
익명 액세스를 불허하기 위한 권한
스토리지 계정에 대한 AllowBlobPublicAccess 속성을 설정하려면 사용자에게 스토리지 계정을 만들고 관리할 수 있는 권한이 있어야 합니다. 이러한 권한을 제공하는 Azure RBAC(Azure 역할 기반 액세스 제어) 역할에는 Microsoft.Storage/storageAccounts/write 작업이 포함됩니다. 이 작업이 포함된 기본 제공 역할은 다음과 같습니다.
- Azure Resource Manager Owner 역할
- Azure Resource Manager 기여자 역할
- 스토리지 계정 기여자 역할
스토리지 계정에 대한 익명 액세스를 사용자가 허용하지 않도록 하려면 역할 할당의 범위를 스토리지 계정 수준 이상으로 지정해야 합니다. 역할 범위에 대한 자세한 내용은 Azure RBAC의 범위 이해를 참조하세요.
이러한 역할은 스토리지 계정을 만들거나 해당 속성을 업데이트하는 기능이 필요한 관리자에게만 제한적으로 할당해야 합니다. 최소 권한의 원칙을 사용하여 사용자에게 작업을 수행하는 데 필요한 최소 권한을 부여합니다. Azure RBAC를 사용하여 액세스를 관리하는 방법에 대한 자세한 내용은 Azure RBAC 모범 사례를 참조하세요.
이러한 역할은 Microsoft Entra ID를 통해 스토리지 계정의 데이터에 대한 액세스 권한을 제공하지 않습니다. 그러나 계정 액세스 키에 대한 액세스 권한을 부여하는 Microsoft.Storage/storageAccounts/listkeys/action이 포함되어 있습니다. 이 권한이 있는 사용자는 계정 액세스 키를 사용하여 스토리지 계정의 모든 데이터에 액세스할 수 있습니다.
Microsoft.Storage/storageAccounts/listkeys/action 자체는 계정 키를 통해 데이터 액세스 권한을 부여하지만 사용자에게 스토리지 계정의 AllowBlobPublicAccess 속성을 변경할 수 있는 기능을 부여하지는 않습니다. 스토리지 계정의 데이터에 액세스해야 하지만 스토리지 계정의 구성을 변경할 수 없는 사용자의 경우 Storage Blob 데이터 기여자, Storage Blob 데이터 읽기 권한자 또는 읽기 권한자 및 데이터 액세스와 같은 역할을 할당하는 것이 좋습니다.
참고 항목
클래식 구독 관리자 역할인 서비스 관리자 및 공동 관리자에는 Azure Resource Manager 소유자 역할에 해당하는 항목이 포함됩니다. 소유자 역할에는 모든 작업이 포함되므로 이러한 관리 역할 중 하나가 있는 사용자는 스토리지 계정을 만들고 계정 구성을 관리할 수도 있습니다. 자세한 내용은 Azure 역할, Microsoft Entra 역할 및 클래식 구독 관리자 역할을 참조하세요.
스토리지 계정의 AllowBlobPublicAccess 속성을 False로 설정
스토리지 계정에 대한 익명 액세스를 허용하지 않으려면 계정의 AllowBlobPublicAccess 속성을 False로 설정합니다.
Important
스토리지 계정에 대한 익명 액세스를 불허하면 해당 스토리지 계정의 모든 컨테이너에 대한 액세스 설정이 재정의됩니다. 스토리지 계정에 대한 익명 액세스가 허용되지 않는 경우 해당 계정에 대한 모든 익명 요청은 실패합니다. 이 설정을 변경하기 전에 클라이언트 애플리케이션에서 익명 요청 검색에 설명된 단계에 따라 익명으로 스토리지 계정의 데이터에 액세스할 수 있는 클라이언트 애플리케이션에 미치는 영향을 이해해야 합니다.
Azure Portal에서 스토리지 계정에 대한 익명 액세스를 허용하지 않으려면 다음 단계를 수행합니다.
Azure Portal의 스토리지 계정으로 이동합니다.
설정에서 구성 설정을 찾습니다.
BLOB 익명 액세스 허용을 사용 안 함으로 설정합니다.
참고 항목
스토리지 계정에 대한 익명 액세스를 허용하지 않으면 해당 스토리지 계정에서 호스트되는 고정적인 웹 사이트에 영향을 주지 않습니다. $web 컨테이너는 항상 퍼블릭으로 액세스할 수 있습니다.
스토리지 계정에 대한 익명 액세스 설정을 업데이트한 후 변경이 완전히 전파되기까지 최대 30초가 걸릴 수 있습니다.
대량 수정을 위한 샘플 스크립트
다음 샘플 PowerShell 스크립트는 구독의 모든 Azure Resource Manager 스토리지 계정에서 실행되며 해당 계정의 AllowBlobPublicAccess 설정을 False로 설정합니다.
<#
.SYNOPSIS
Finds storage accounts in a subscription where AllowBlobPublicAccess is True or null.
.DESCRIPTION
This script runs against all Azure Resource Manager storage accounts in a subscription
and sets the "AllowBlobPublicAccess" property to False.
Standard operation will enumerate all accounts where the setting is enabled and allow the
user to decide whether or not to disable the setting.
Classic storage accounts will require individual adjustment of containers to remove public
access, and will not be affected by this script.
Run with BypassConfirmation=$true if you wish to disallow public access on all Azure Resource Manager
storage accounts without individual confirmation.
You will need access to the subscription to run the script.
.PARAMETER BypassConformation
Set this to $true to skip confirmation of changes. Not recommended.
.PARAMETER SubscriptionId
The subscription ID of the subscription to check.
.PARAMETER ReadOnly
Set this parameter so that the script makes no changes to any subscriptions and only reports affect accounts.
.PARAMETER NoSignin
Set this parameter so that no sign-in occurs -- you must sign in first. Use this if you're invoking this script repeatedly for multiple subscriptions and want to avoid being prompted to sign-in for each subscription.
.OUTPUTS
This command produces only STDOUT output (not standard PowerShell) with information about affect accounts.
#>
param(
[boolean]$BypassConfirmation=$false,
[Parameter(Mandatory=$true, ValueFromPipelineByPropertyName='SubscriptionId')]
[String] $SubscriptionId,
[switch] $ReadOnly, # Use this if you don't want to make changes, but want to get information about affected accounts
[switch] $NoSignin # Use this if you are already signed in and don't want to be prompted again
)
begin {
if ( ! $NoSignin.IsPresent ) {
login-azaccount | out-null
}
}
process {
try {
select-azsubscription -subscriptionid $SubscriptionId -erroraction stop | out-null
} catch {
write-error "Unable to access select subscription '$SubscriptionId' as the signed in user -- ensure that you have access to this subscription." -erroraction stop
}
foreach ($account in Get-AzStorageAccount)
{
if($account.AllowBlobPublicAccess -eq $null -or $account.AllowBlobPublicAccess -eq $true)
{
Write-host "Account:" $account.StorageAccountName " isn't disallowing public access."
if ( ! $ReadOnly.IsPresent ) {
if(!$BypassConfirmation)
{
$confirmation = Read-Host "Do you wish to disallow public access? [y/n]"
}
if($BypassConfirmation -or $confirmation -eq 'y')
{
try
{
set-AzStorageAccount -Name $account.StorageAccountName -ResourceGroupName $account.ResourceGroupName -AllowBlobPublicAccess $false
Write-Host "Success!"
}
catch
{
Write-output $_
}
}
}
}
elseif($account.AllowBlobPublicAccess -eq $false)
{
Write-Host "Account:" $account.StorageAccountName " has public access disabled, no action required."
}
else
{
Write-Host "Account:" $account.StorageAccountName ". Error, please manually investigate."
}
}
}
end {
Write-Host "Script complete"
}
익명 액세스가 수정되었는지 확인
스토리지 계정에 대한 익명 액세스를 수정했는지 확인하려면 Blob에 대한 익명 액세스가 허용되지 않는지, 컨테이너의 액세스 설정 수정이 허용되지 않는지, 익명 액세스가 사용하도록 설정된 컨테이너를 만들 수 없는지 테스트할 수 있습니다.
BLOB에 대한 익명 액세스가 허용되지 않는지 확인
특정 Blob에 대한 익명 액세스가 허용되지 않는지 확인하려면 해당 URL을 통해 Blob 다운로드를 시도하면 됩니다. 다운로드가 성공하면 Blob은 아직 공개적으로 사용이 가능한 것입니다. 스토리지 계정에 대한 익명 액세스가 허용되지 않아서 BLOB에 공개적으로 액세스할 수 없는 경우에는 해당 스토리지 계정에 대한 익명 액세스가 허용되지 않는다는 오류 메시지가 표시됩니다.
다음 예제에서는 PowerShell을 사용하여 URL을 통해 Blob을 다운로드하는 방법을 보여줍니다. 대괄호의 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.
$url = "<absolute-url-to-blob>"
$downloadTo = "<file-path-for-download>"
Invoke-WebRequest -Uri $url -OutFile $downloadTo -ErrorAction Stop
컨테이너의 익명 액세스 설정 수정이 허용되지 않는지 확인
스토리지 계정에 대한 익명 액세스를 불허한 후 컨테이너의 액세스 설정을 수정할 수 없는지 확인하려면 설정을 수정해 볼 수 있습니다. 스토리지 계정에 대해 익명 액세스가 허용되지 않는 경우 컨테이너의 액세스 설정을 변경하면 실패합니다.
다음 예제는 PowerShell을 사용하여 컨테이너의 액세스 설정을 변경하려고 시도하는 방법을 보여줍니다. 대괄호의 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.
$rgName = "<resource-group>"
$accountName = "<storage-account>"
$containerName = "<container-name>"
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context
Set-AzStorageContainerAcl -Context $ctx -Container $containerName -Permission Blob
익명 액세스를 사용하도록 설정하여 컨테이너를 만들 수 없는지 확인
스토리지 계정에 대한 익명 액세스가 허용되지 않으면 익명 액세스를 사용하도록 설정된 새 컨테이너를 만들 수 없습니다. 확인하려면 익명 액세스를 사용하도록 설정된 컨테이너 만들기를 시도해보면 됩니다.
다음 예제는 PowerShell을 사용하여 익명 액세스를 사용하도록 설정된 컨테이너 만들기를 시도하는 방법을 보여줍니다. 대괄호의 자리 표시자 값을 사용자 고유의 값으로 바꿔야 합니다.
$rgName = "<resource-group>"
$accountName = "<storage-account>"
$containerName = "<container-name>"
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context
New-AzStorageContainer -Name $containerName -Permission Blob -Context $ctx
여러 계정에 대한 익명 액세스 설정 확인
최적의 성능을 가진 일련의 스토리지 계정에서 익명 액세스 설정을 확인하려면 Azure Portal에서 Azure Resource Graph Explorer를 사용하면 됩니다. Resource Graph Explorer를 사용하는 방법에 대해 자세히 알아보려면 빠른 시작: Azure Resource Graph Explorer를 사용하여 첫 번째 Resource Graph 쿼리 실행을 참조하세요.
Resource Graph Explorer에서 다음 쿼리를 실행하면 스토리지 계정 목록이 반환되고 각 계정에 대한 익명 액세스 설정이 표시됩니다.
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
다음 이미지는 구독에 대한 쿼리 결과를 보여줍니다. AllowBlobPublicAccess 속성이 명시적으로 설정된 스토리지 계정의 경우 결과에 true 또는 false로 나타납니다. 스토리지 계정에 대해 AllowBlobPublicAccess 속성이 설정되지 않은 경우 쿼리 결과에 공백(또는 null)으로 나타납니다.
Azure Policy를 사용하여 규정 준수 감사
스토리지 계정이 많은 경우, 감사를 수행하여 해당 계정이 익명 액세스를 차단하도록 구성되었는지 확인하는 것이 좋습니다. 일련의 스토리지 계정에서 규정 준수 여부를 감사하려면 Azure Policy를 사용합니다. Azure Policy는 Azure 리소스에 규칙을 적용하는 정책을 만들고, 할당하고, 관리하는 데 사용할 수 있는 서비스입니다. Azure Policy는 해당 리소스 가 회사 표준 및 서비스 수준 계약을 준수하도록 유지하는 데 도움이 됩니다. 자세한 내용은 Azure Policy 개요를 참조하세요.
감사 효과를 사용하여 정책 만들기
Azure Policy는 리소스에 대해 정책 규칙을 평가할 때 발생하는 작업을 결정하는 효과를 지원합니다. 감사 효과는 리소스가 정책을 준수하지 않는 경우 경고를 생성하지만 요청을 중지하지는 않습니다. 효과에 대한 자세한 내용은 Azure Policy 효과 이해를 참조하세요.
Azure Portal에서 스토리지 계정의 익명 액세스 설정에 대해 감사 효과가 있는 정책을 만들려면 다음 단계를 수행합니다.
Azure Portal에서 Azure Policy 서비스로 이동합니다.
작성 섹션에서 정의를 선택합니다.
정책 정의 추가를 선택하여 새 정책 정의를 만듭니다.
정의 위치 필드의 경우 자세히 단추를 선택하여 감사 정책 리소스가 있는 위치를 지정합니다.
정책에 대한 이름을 지정합니다. 필요에 따라 설명 및 범주를 지정할 수 있습니다.
정책 규칙에서 다음 정책 정의를 policyRule 섹션에 추가합니다.
{ "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } }정책을 저장합니다.
정책 할당
다음으로 리소스에 정책을 할당합니다. 정책의 범위는 해당 리소스 및 그 아래에 있는 모든 리소스에 해당합니다. 정책 할당에 대한 자세한 내용은 Azure Policy 할당 구조를 참조하세요.
Azure Portal에서 정책을 할당하려면 다음 단계를 수행합니다.
- Azure Portal에서 Azure Policy 서비스로 이동합니다.
- 작성 섹션에서 할당을 선택합니다.
- 정책 할당을 선택하여 새 정책 할당을 만듭니다.
- 범위 필드에서 정책 할당의 범위를 선택합니다.
- 정책 정의 필드에서 자세히 단추를 선택한 다음, 이전 섹션에서 정의한 정책을 목록에서 선택합니다.
- 정책 할당의 이름을 제공합니다. 설명은 생략할 수 있습니다.
- 정책 적용을 사용 가능으로 유지합니다. 이 설정은 감사 정책에 영향을 주지 않습니다.
- 검토 + 만들기를 선택하여 할당을 만듭니다.
규정 준수 보고서 보기
정책을 할당한 후에는 규정 준수 보고서를 볼 수 있습니다. 감사 정책에 대한 규정 준수 보고서는 정책을 준수하지 않는 스토리지 계정에 대한 정보를 제공합니다. 자세한 내용은 정책 규정 준수 데이터 가져오기를 참조하세요.
정책 할당을 만든 후 규정 준수 보고서를 사용할 수 있게 되는 데 몇 분 정도 걸릴 수 있습니다.
Azure Portal에서 규정 준수 보고서를 보려면 다음 단계를 수행합니다.
Azure Portal에서 Azure Policy 서비스로 이동합니다.
준수를 선택합니다.
이전 단계에서 만든 정책 할당의 이름에 대한 결과를 필터링합니다. 이 보고서에는 정책을 준수하지 않는 리소스의 수가 표시됩니다.
정책을 준수하지 않는 스토리지 계정 목록을 포함하여 추가 세부 정보에 대해 보고서를 드릴다운할 수 있습니다.
Azure Policy를 사용하여 권한 있는 액세스 적용
Azure Policy는 Azure 리소스가 요구 사항 및 표준을 준수하도록 하여 클라우드 거버넌스를 지원합니다. 조직의 스토리지 계정이 권한 있는 요청만 허용하도록 하려면 익명 요청을 허용하는 익명 액세스 설정을 사용하여 새 스토리지 계정을 만들 수 없도록 하는 정책을 만들면 됩니다. 또한 이 정책은 해당 계정의 익명 액세스 설정이 정책을 준수하지 않는 경우 기존 계정에 대한 모든 구성 변경을 방지합니다.
적용 정책은 거부 효과를 사용하여 익명 액세스를 허용하기 위해 스토리지 계정을 만들거나 수정하는 요청을 방지합니다. 효과에 대한 자세한 내용은 Azure Policy 효과 이해를 참조하세요.
익명 요청을 허용하는 익명 액세스 설정에 대해 거부 효과가 적용된 정책을 만들려면 Azure Policy를 사용하여 규정 준수 감사에 설명된 것과 동일한 단계를 수행하지만 정책 정의의 policyRule 섹션에는 다음 JSON을 제공합니다.
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "deny"
}
}
거부 효과가 있는 정책을 만들어서 범위에 할당한 후에는 익명 액세스를 허용하는 스토리지 계정을 사용자가 만들 수 없습니다. 또한, 현재 익명 액세스를 허용하는 기존 스토리지 계정의 구성을 사용자가 변경할 수 없습니다. 그렇게 하려고 하면 오류가 발생합니다. 계정 만들기 또는 구성을 계속하려면 스토리지 계정에 대한 익명 액세스 설정을 false로 설정해야 합니다.
다음 이미지는 거부 효과가 있는 정책에 따라 익명 액세스를 허용하지 않아야 하는데, 익명 액세스를 허용하는 스토리지 계정을 만들려고 시도할 때 발생하는 오류를 보여줍니다.
