Azure Storage 보안 모범 사례 적용
SAS(공유 액세스 서명)를 만들고 사용하는 방법과 이것이 스토리지 보안 솔루션에 제공할 수 있는 이점을 검토했습니다.
애플리케이션에서 SAS를 사용할 때 잠재적인 위험이 생길 수 있음을 이해하는 것이 중요합니다.
SAS가 손상되면 악의적인 사용자를 포함하여 SAS를 획득하는 누군가가 사용할 수 있습니다.
클라이언트 애플리케이션에 제공된 SAS가 만료되어 애플리케이션이 서비스에서 새 SAS를 검색할 수 없는 경우 애플리케이션의 기능이 저하될지도 모릅니다.
스토리지를 보호하는 방법에 대한 자세한 내용은 이 비디오를 시청하세요. 이 비디오는 Azure 팁 및 요령 #272 Azure 보안 모범 사례를 기반으로 합니다.
위험 관리를 위한 권장 사항
SAS로 작업할 때 위험을 완화하는 데 도움이 되는 몇 가지 권장 사항을 살펴보겠습니다.
| 권장 | Description |
|---|---|
| 생성 및 배포에 항상 HTTPS 사용 | SAS가 HTTP를 통해 전달되고 가로채기 되면 공격자가 SAS를 가로채서 사용할 수 있습니다. 이러한 중간자(man-in-the-middle) 공격은 중요한 데이터를 손상시키거나 악의적인 사용자에 의한 데이터 손상을 허용할 수 있습니다. |
| 가능한 경우 저장된 액세스 정책을 참조합니다. | 저장된 액세스 정책을 사용하면 Azure 스토리지 계정 키를 다시 생성할 필요 없이 사용 권한을 해지할 수 있습니다. 스토리지 계정 키 만료 날짜를 먼 미래로 설정합니다. |
| 계획되지 않은 SAS에 대한 단기 만료 시간 설정 | SAS가 손상된 경우 SAS 유효 기간을 짧은 시간으로 제한하여 공격을 완화할 수 있습니다. 이 방법은 저장된 액세스 정책을 참조할 수 없는 경우에 중요합니다. 또한 짧은 만료 시간은 업로드할 수 있는 시간을 제한하여 Blob에 쓸 수 있는 데이터의 양을 제한할 수 있습니다. |
| 클라이언트가 자동으로 SAS를 갱신하도록 요구 | 클라이언트가 만료 날짜 전에 SAS를 갱신하도록 요구합니다. 일찍 갱신하면 SAS를 제공하는 서비스를 사용할 수 없는 경우 재시도를 위한 시간을 허용합니다. |
| SAS 시작 시간을 신중하게 계획 | SAS 시작 시간을 지금으로 설정한 경우 클럭 오차(컴퓨터의 차이에 따른 현재 시간의 차이)로 인해 처음 몇 분 동안 간헐적으로 오류가 발생할 수 있습니다. 일반적으로 시작 시간을 최소 15분 이전으로 설정하거나 또는 특정 시작 시간을 설정하지 않아서 SAS가 모든 경우에 즉시 유효하여지도록 합니다. 일반적으로 만료 시간에 동일한 조건이 적용됩니다. 모든 요청에 대해 어떤 방향이든 최대 15분의 클록 스큐가 발생할 수 있습니다. 2012-02-12 이전의 REST API 버전을 사용하는 클라이언트의 경우, 저장된 액세스 정책을 참조하지 않는 SAS에 대한 최대 기간은 1시간입니다. 더 긴 기간을 지정하는 정책은 실패합니다. |
| 리소스에 대한 최소 액세스 권한 정의 | 보안을 위한 최적의 방법은 사용자에게 필요한 최소 권한을 제공하는 것입니다. 사용자가 단일 엔터티에 대한 읽기 권한만 필요한 경우 해당 엔터티에 대한 읽기 권한만 부여하고 모든 엔터티에 대한 읽기/쓰기/삭제 권한은 부여하지 않습니다. 이러한 방법은 또한 SAS가 공격자의 수중에 넘어갈 가능성이 낮아지므로 SAS가 손상될 경우 손해를 줄이는 데도 도움이 됩니다. |
| SAS를 포함하여 사용량에 대한 계정 청구 이해 | Blob에 대해 쓰기 권한을 제공하는 경우 사용자는 200GB Blob을 업로드하도록 선택할 수 있습니다. 읽기 권한도 제공했다면 Blob을 10회 다운로드할 수도 있으며 이 경우 2TB의 수신 비용이 발생합니다. 또한 제한된 권한을 제공하여 악의적인 사용자의 작업 가능성을 낮추세요. 단기 실행 SAS를 사용하여 이러한 위협을 줄이되, 이때 종료 시간의 클럭 스큐에 유의하세요. |
| SAS를 사용하여 작성된 데이터의 유효성 검사 | 클라이언트 애플리케이션이 Azure 스토리지 계정에 데이터를 쓸 경우 해당 데이터에 문제가 있을 수 있음을 기억해야 합니다. 애플리케이션에 유효성이 검사되거나 권한이 부여된 데이터가 필요한 경우 데이터가 작성된 후, 사용되기 전에 데이터의 유효성을 검사합니다. 그러면 SAS를 적절한 방법으로 습득한 사용자나 누설된 SAS를 악용하는 사용자로 인해 계정이 손상되거나 데이터에 악의적인 데이터가 기록되는 것을 방지할 수 있습니다. |
| SAS가 항상 올바른 선택이라고 가정하지 않기. | 일부 시나리오에서는 Azure 스토리지 계정에 대한 특정 작업과 관련된 위험이 SAS 사용의 이점을 능가하는 경우도 있습니다. 그런 작업에 대해서는 비즈니스 규칙 유효성 검사, 인증 및 감사를 수행한 이후에 스토리지 계정에 쓰는 중간 계층 서비스를 만듭니다. 또한 다른 방법으로 액세스를 관리하기 더 쉬운 경우도 있습니다. 컨테이너의 모든 Blob을 공개적으로 읽기 가능하도록 설정하려면 모든 클라이언트가 액세스하도록 SAS를 제공하는 대신에 컨테이너를 공용으로 설정할 수 있습니다. |
| Azure 스토리지 분석을 사용하여 애플리케이션 모니터링 | 로깅 및 메트릭을 사용하여 인증 실패의 급증을 관찰할 수 있습니다. SAS 공급자 서비스의 중단으로 인한 급증 또는 저장된 액세스 정책의 우발적 제거로 인한 급증을 보게 될 수도 있습니다. |