Azure Blob Storage에서 정적 웹 사이트에 대한 직접 액세스를 차단하고 Azure Front Door만 허용합니다.

Azure Blob Storage에서 정적 웹 사이트에 대한 직접 액세스를 차단하고 Azure Front Door만 허용합니다.

URL이 공개된 Azure Blob Storage에 SPA 웹앱이 배포되어 있습니다. 예:https://example.z23.web.core.windows.net/

보안을 강화하기 위해 WAF와 함께 Azure Front Door를 사용하고 싶습니다. Blob URL에서 직접 액세스를 차단하는 방법이 있나요? Google에서 검색한 결과 많은 답변을 찾았습니다. 그 중 하나는 AzureFrontDoor.Backend스토리지 계정 네트워킹 구성에서 IP만 허용하는 것입니다. 나는 그것을 시도했고 효과가있었습니다.

그러나 누구든지 Front Door를 만들고 내 Blob URL을 가리킬 수 있기 때문에 이 방법에는 여전히 허점이 있습니다(어쨌든 발견한 경우).

(바보처럼 들릴 수도 있습니다.): 예를 들어 이 방법을 계속 사용하여 스토리지 계정 이름을 임의로 지정하는 경우에는 축소된 임의 GUID를 사용합니다. (https://6c4a89d5dba04b8fbe1ed7f.z23.web.core.windows.net/) 이렇게 하면 누군가가 내 URL을 발견하고 보안을 우회할 가능성을 줄일 수 있습니까?

또 다른 방법은Azure는 권장합니다X-Azure-FDID내 특정 Front Door 인스턴스의 ID를 포함하는 헤더와 이 헤더를 포함하지 않는 삭제 요청을 확인하는 것입니다 . 개발자에게 Vue 웹앱에서 이것이 가능한지 물었고 그는 클라이언트 측에서 실행되는 코드에 Front Door ID를 포함하여 어쨌든 ID를 공개해야 한다고 말했습니다. (이것은 스택 오버플로가 아니지만 누군가 이에 대해 제안할 수 있다면 좋을 것입니다.)

내가 찾은 또 다른 방법은 Azure Front Door Premium SKU를 사용하는 것입니다.지원하다Private Link를 사용하여 스토리지 계정에 연결합니다. 이것은 완벽하지만 한 달에 무려 $ 165의 비용이 듭니다. 기본적으로 Front Door에서만 액세스를 제한할 수 있으므로 대신 App Service에 내 코드를 배포하고 싶습니다.

누구든지 이것을 달성하는 방법에 대한 방법을 제안할 수 있습니까?

감사해요.

답변1

IP 제한과 함께 X-Azure-FDID 헤더를 확인하는 것이 현재 개인 링크 경로를 따르지 않고 이를 잠글 수 있는 유일한 방법입니다. 따라서 FD와 스토리지 계정 사이에 다른 것이 없다면 이를 검증하기 위해 애플리케이션 코드를 가져와야 합니다.

클라이언트 측 코드에 이를 포함하면 ID가 노출되지만 실제로는 중요하지 않습니다. IP 제한은 Front Door 인스턴스의 트래픽만 허용하며 공격자가 다른 FD 인스턴스에 해당 ID를 설정할 수 있는 방법이 없음을 의미합니다.

관련 정보