발레 키 패턴

애플리케이션으로부터 데이터 전송을 오프로드하기 위해서 클라이언트에 특정 리소스에 대한 제한적 직접 액세스 권한을 제공하는 토큰을 사용합니다. 클라우드 호스티드 스토리지 시스템이나 큐를 사용하는 애플리케이션에 특히 유용하며, 비용을 최소화하고 확장성과 성능을 최대화할 수 있습니다.

컨텍스트 및 문제점

클라이언트 프로그램과 웹 브라우저는 종종 파일이나 데이터 스트림을 애플리케이션의 스토리지에서 읽고, 스토리지에 쓰는 작업이 필요합니다. 일반적으로 애플리케이션은 스토리지에서 데이터를 가져오거나 클라이언트에 데이터를 스트리밍하거나 업로드된 스트림을 클라이언트에서 읽고 데이터 스토리지에 저장하는 방법으로 데이터 이동을 처리합니다. 그러나, 이 접근 방식은 컴퓨팅, 메모리, 대역과 같은 소중한 리소스를 소비합니다.

데이터 저장소는 애플리케이션에 데이터의 이동 처리를 수행할 것을 요구하지 않고, 데이터를 직접 업로드하고 다운로드할 수 있는 능력이 있습니다. 그러나, 일반적으로 클라이언트가 저장소에 대한 보안 자격 증명을 액세스할 것을 요구합니다. 이는 데이터 전송 비용을 최소화하는 데 유용한 기법이며, 애플리케이션을 확장하고 성능을 최대화하기 위한 요구 사항일 수 있습니다. 그렇다 해도, 애플리케이션이 더 이상 데이터 보안을 관리할 수 없음을 의미합니다. 클라이언트가 직접 액세스를 위해 데이터 저장소에 접속한 이후에는, 애플리케이션이 게이터키퍼 역할을 할 수 없습니다. 더 이상 프로세스를 제어하지 못하고, 데이터 저장소의 후속 업로드나 다운로드를 막을 수 없습니다.

신뢰되지 않는 클라이언트에 서비스를 제공해야 하는 분산 시스템에는 현실적인 접근 방식이 아닙니다. 대신, 애플리케이션은 데이터 액세스를 자세히 안전하게 제어할 수 있어야 하며, 이렇게 연결을 설정한 다음 클라이언트가 직접 데이터 스토리지와 통신하면서 필요한 읽기 또는 쓰기 작업을 수행하게 허용함으로써 서버에 대한 부하를 계속해서 줄여야 합니다.

해결 방법

저장소가 클라이언트의 인증과 권한 부여를 관리할 수 없는 데이터 저장소에 대한 액세스를 제어하는 문제를 해결해야 합니다. 일반적인 해결 방법은 데이터 저장소의 공용 연결에 대한 액세스를 제한하고 클라이언트에 데이터 저장소가 확인할 수 있는 키 또는 토큰을 제공하는 것입니다.

이것이 일반적으로 발레 키라고 부르는 키 또는 토큰입니다. 발레 키는 특정 리소스에 대한 시간 제한된 액세스를 제공하고, 스토리지나 큐에 읽기와 쓰기 또는 웹 브라우저에 업로드 및 다운로드와 같은 미리 정의된 작업 하나만 허용합니다. 애플리케이션은 클라이언트 디바이스와 웹 브라우저에 대한 발레 키를 빠르고 쉽게 만들고 발급할 수 있습니다. 이 키로 클라이언트는 애플리케이션이 직접 데이터 전송을 처리할 것을 요구하지 않고 필요한 작업을 자신이 수행합니다. 이 경우, 애플리케이션과 서버에서 일어나는 처리 오버헤드, 성능과 확장성에 미치는 영향이 제거됩니다.

그림과 같이, 클라이언트는 이 토큰을 사용하여 특정 기간에만, 액세스 사용 권한에 제한하여, 데이터 저장소에서 특정 리소스를 액세스합니다. 지정된 기간 후에 키는 무효화되며 리소스 액세스를 허용하지 않습니다.

데이터 범위와 같이 다른 종속성을 갖도록 키를 구성하는 것도 가능합니다. 예를 들면, 데이터 저장소 역량에 따라 키는 데이터 저장소에 완전한 표를 지정하거나 표에서 특정 행만 지정할 수 있습니다. 클라우드 스토리지 시스템에서 키는 컨테이너, 즉 컨테이너 내 특정 항목을 지정할 수 있습니다.

키는 애플리케이션에 의해 무효화될 수도 있습니다. 클라이언트가 서버에 데이터 전송 작업이 완료되었음을 알릴 경우, 이는 유용한 접근 방식입니다. 서버는 더 이상의 액세스를 막기 위해 키를 무효화시킬 수 있습니다.

이 패턴을 사용하면 사용자 생성 및 인증, 사용 권한 부여, 사용자 다시 제거에 대한 요구 사항이 없기 때문에 리소스에 대한 액세스 관리가 단순화될 수 있습니다. 장소 제한, 사용 권한, 유효 기간을 제한하는 것도 쉬워졌습니다. 이러한 모든 작업이 런타임에 키를 생성하여 가능해집니다. 유효 기간, 특히 리소스의 위치를, 수신자만 그 용도에 맞게 사용할 수 있도록 가능한 한 엄격히 제한하는 것은 중요한 요소입니다.

문제 및 고려 사항

이 패턴을 구현할 방법을 결정할 때 다음 사항을 고려하세요.

키의 유효 상태와 기간 관리. 키가 유출되거나 노출된 경우, 키는 효과적으로 대상 항목을 잠금 해제하고, 유효 기간 동안 악의적 사용에 사용할 수 있습니다. 일반적으로 키는 어떻게 발급되었는지에 따라 취소되거나 사용할 수 없게 됩니다. 서버 쪽 정책이 변경되거나 서명된 서버 키가 무효화될 수 있습니다. 데이터 저장소에 대해서 권한이 없는 작업이 발생하는 위험을 최소화하려면 유효 기간을 짧게 지정합니다. 하지만, 유효 기간이 너무 짧으면 키가 만료되기 전에 클라이언트가 작업을 완료할 수 없습니다. 보호된 리소스에 다중 액세스가 요구될 경우, 유효 기간이 만료되기 전에 권한 있는 사용자가 키를 검토하도록 허용합니다.

키가 제공하는 액세스 수준 제어. 일반적으로, 클라이언트가 데이터 저장소에 데이터를 업로드하면 안 될 경우, 키는 사용자에게 읽기 전용 액세스와 같은 작업을 완료하는 데 필요한 동작만 수행하도록 허용해야 합니다. 파일 업로드의 경우, 장소와 유효 기간뿐만 아니라 쓰기 전용 사용 권한을 제공하는 키를 지정하는 것이 보통입니다. 키가 적용되는 리소스나 리소스 집합을 정확하게 지정하는 것이 중요합니다.

사용자 동작에 대한 제어 방법 고려 이 패턴을 구현하는 것은 사용자가에게 액세스가 허용된 리소스에 대한 제어가 일정 정도 손실된다는 뜻입니다. 가해지는 제어 수준은 서비스 또는 대상 데이터 저장소에서 사용 가능한 정책과 사용 권한의 역량에 의해 제한됩니다. 예를 들면, 일반적으로 스토리지에 기록되는 데이터 크기와, 키가 파일 액세스에 사용될 수 있는 횟수를 제한하는 키를 만드는 것은 불가능합니다. 이는 데이터 전송에 예상치 않은 큰 비용을 발생시킬 수 있는데, 심지어 대상 고객에 의해 사용될 때, 그리고 반복된 업로드나 다운로드를 유발하는 코드 오류에 의해 야기될 수 있을 때도 마찬가지입니다. 파일이 업로드될 수 있는 횟수를 제한하려면, 가능한 한 클라이언트가 애플리케이션에 작업 하나가 언제 완료되었는지 알리도록 강제해야 합니다. 예를 들면, 어떤 데이터 저장소는 애플리케이션 코드가 작업을 모니터링하고 사용자 동작을 제어하는 데 사용할 수 있는 이벤트를 발생시킵니다. 그러나 한 테넌트의 모든 사용자가 동일한 키를 사용하는 다중 테넌트 시나리오에서 개별 사용자에 대한 할당량을 적용하기는 어렵습니다.

업로드된 모든 데이터의 유효성 검사 및 선택적 삭제. 키를 액세스하는 악의적 사용자가 시스템을 손상할 수 있게 설계된 데이터를 업로드할 수 있습니다. 또는, 권한 있는 사용자가 유효하지 않은 데이터를 업로드할 수 있는데, 이 작업이 처리되면 오류 또는 시스템 실패로 이어질 수 있습니다. 이를 막기 위해서, 업로드된 모든 데이터는 사용 전에 유효한지 검사받고 악의적인 콘텐츠가 없는지 확인받아야 합니다.

모든 작업 감사. 많은 키 기반 메커니즘은 업로드, 다운로드, 실패와 같은 작업을 기록할 수 있습니다. 일반적으로 이러한 로그는 감사 프로세스에 포함될 수 있고, 사용자에게 파일 크기나 데이터 볼륨에 근거한 요금이 부과된 경우 대금 청구에도 사용될 수 있습니다. 로그를 사용하여 키 공급 기업과의 불화 또는 실수로 저장된 액세스 정책 삭제 등으로 발생할 수 있는 인증 오류를 검색합니다.

안전한 키 전달. 웹 페이지에서 사용자가 활성화하는 URL에 포함되거나, 다운로드가 자동으로 일어날 수 있도록 서버 리디렉션 작업에 사용될 수 있습니다. 안전한 채널을 통해서 키를 전달하려면 항상 HTTP를 사용합니다.

전송 중인 중요한 데이터 보호. 일반적으로 애플리케이션을 통해서 전달된 중요한 정보는 TLS를 사용하여 발생하는데, 이는 데이터 저장소에 직접 액세스하는 클라이언트에 적용되어야 합니다.

이 패턴을 구현할 때 알아야 할 다른 문제점은 다음과 같습니다.

• 클라이언트가 서버에 작업 완료를 알리지 않거나 알리지 못하고, 유일한 제한이 키의 만료 기간인 경우, 애플리케이션은 업로드나 다운로드 횟수 집계, 다중 업로드나 다운로드 예방과 같은 감사 작업을 수행할 수 없습니다.

• 키 정책의 유연성이 제한될 수 있습니다. 예를 들면, 일부 메커니즘만 만료 기간의 사용을 허용합니다. 다른 메커니즘은 읽기/쓰기 사용 권한을 아주 자세하게 지정할 수 없습니다.

• 키 또는 토큰 유효 기간의 시작 시간이 지정된 경우, 동기화에서 약간 벗어나 있을 수 있는 클라이언트 시계를 고려하여 시간이 현재의 서버 시간보다 조금 이른지 확인합니다. 지정되지 않은 경우, 일반적으로 기본 값은 현재의 서버 시간입니다.

• 키를 포함한 URL은 서버 로그 파일에 기록됩니다. 일반적으로 분석에 로그 파일이 사용되기 전에 키가 만료되는 동안, 키에 대한 액세스를 제한하는지 확인합니다. 로그 데이터가 모니터링 시스템에 전송되거나 다른 장소에 저장된 경우, 유효 기간이 만료된 후까지 키 누출을 막기 위해 지연을 구현할 것을 고려합니다.

• 클라이언트 코드가 웹 브라우저에서 실행될 경우, 브라우저는 웹 브라우저에서 실행되는 코드가 그 페이지를 제공한 곳에서 다른 도메인에 있는 데이터를 액세스할 수 있도록 CORS(원본 간 리소스 공유)를 지원해야할 수 있습니다. 일부 오래된 브라우저와 일부 데이터 스토리지는 CORS를 지원하지 않으며, 이 브라우저에서 실행되는 코드는 클라우드 스토리지 계정과 같은 다른 도메인에 있는 데이터에 대한 액세스 권한을 제공하기 위해서 발레 키를 사용하지 못할 수도 있습니다.

이 패턴을 사용해야 하는 경우

이 패턴은 다음 상황에서 유용합니다.

• 리소스 부하를 최소화하고 성능과 확장성을 최대화하기 위해서. 발레 키 사용은 리소스 잠김을 요구하지 않고, 원격 서버 호출을 요구하지 않으며, 발급될 수 있는 발레 키의 개수를 제한하지 않습니다. 그래서 애플리케이션 코드를 통한 데이터 전송을 수행함으로써 발생되는 단일 실패 지점을 방지합니다. 발레 키 생성은 키로 문자열을 서명하는 간단한 암호화 작업입니다.

• 업무비를 최소화하기 위해서. 저장소와 큐에 대한 직접 액세스 사용은 리소스와 비용 효율적이고, 네트워크 왕복을 줄일 수 있으며, 필요한 컴퓨팅 리소스 수의 감소를 고려할 수 있습니다.

• 클라이언트가 규칙적으로 데이터를 업로드하거나 다운로드할 때, 특히 대용량이거나 작업이 큰 파일을 포함할 때

• 호스팅 제한이나 비용 고려 때문에 애플리케이션에 사용 가능한 컴퓨팅 리소스가 제한된 경우 이 시나리오에서, 이 패턴은 훨씬 더 유용한데, 데이터의 업로드나 다운로드가 동시에 많은 경우, 데이터 전송으로 생기는 애플리케이션의 부담을 덜어주기 때문입니다.

• 데이터가 원격 데이터 저장소나 다른 데이터센터에 저장될 때. 애플리케이션이 게이트키퍼 역할을 해야 할 경우, 데이터센터 또는 클라이언트와 애플리케이션 간, 그 다음 애플리케이션과 데이터 저장소 간의 공용 또는 프라이빗 네트워크에서 데이터를 전송하는 추가 대역에 대한 요금이 발생할 수 있습니다.

이 패턴은 다음과 같은 경우에 유용하지 않을 수 있습니다.

• 애플리케이션이 데이터가 저장되기 전 또는 데이터가 클라이언트에 전송되기 전에, 그 데이터에서 어떤 태스크를 수행해야 할 경우. 예를 들면, 애플리케이션이 유효성 검사를 수행하거나, 액세스 성공 기록하거나, 그 데이터에서 변환을 실행할 필요가 있는 경우가 여기에 해당합니다. 그러나 일부 데이터 저장소와 클라이언트는 압축과 압축 풀기와 같은 간단한 변환을 협상하고 수행할 수 있습니다(예를 들어 일반적으로 웹 브라우저는 gzip 형식을 처리할 수 있음).

• 기존의 애플리케이션의 설계가 패턴을 포함하기 어려운 경우. 일반적으로 이 패턴은 데이터를 주고 받을 때 다른 아키텍처적 접근 방식을 요구합니다.

• 감사 내역을 유지 관리하거나 데이터 전송 작업의 실행 횟수를 제어할 필요가 있는 경우, 또 사용되는 발레 키 메커니즘이 서버가 이 작업을 유지하는 데 사용할 수 있는 알림을 지원하지 않는 경우

• 특히 업로드 작업 시 데이터 크기 제한이 필요한 경우. 이를 위한 유일한 해결 방법은 애플리케이션이 작업이 완료된 후 데이터 크기를 확인하거나, 특정 기간 이후 또는 예약된 일정에 따라 업로드 크기를 확인하는 것입니다.

워크로드 디자인

설계자는 발렛 키 패턴을 워크로드 디자인에 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

예시

Azure는 Blob, 테이블, 큐에 있는 데이터에 대한 세분화된 액세스 제어를 위해서, 그리고 Service Bus 큐 및 토픽을 위해서 Azure Storage의 공유 액세스 서명을 지원합니다. 공유 액세스 서명 토큰은 특정 테이블, 테이블 내 키 범위, 큐, Blob, Blob 컨테이너에 대한 읽기, 쓰기, 업데이트, 삭제와 같은 특정 액세스 권한을 제공하도록 구성될 수 있습니다. 유효 기간은 지정된 기간일 수 있습니다. 이 기능은 액세스에 발레 키를 사용하는 데 적합합니다.

수백 개의 모바일 또는 데스크톱 클라이언트가 대용량 이진 파일을 자주 업로드하는 워크로드를 고려합니다. 이 패턴이 없으면 워크로드에는 기본적으로 두 가지 옵션이 있습니다. 첫 번째는 스토리지 계정에 직접 업로드를 수행할 수 있도록 모든 클라이언트에 대기 액세스 및 구성을 제공하는 것입니다. 다른 하나는 게이트웨이 라우팅 패턴을 구현하여 클라이언트가 스토리지에 프록시된 액세스를 사용하는 엔드포인트를 설정하는 것이지만 트랜잭션에 추가 값을 추가하지 않을 수 있습니다. 두 방법 모두 패턴 컨텍스트에서 해결되는 문제를 겪습니다.

• 오래 살았고 미리 공유된 비밀. 잠재적으로 다른 클라이언트에 다른 키를 제공할 방법이 없습니다.
• 현재 대용량 파일을 수신하는 데 충분한 리소스가 있는 컴퓨팅 서비스를 실행하는 데 드는 비용이 추가되었습니다.
• 업로드 프로세스에 컴퓨팅 및 네트워크 홉의 추가 계층을 추가하여 클라이언트 상호 작용 속도가 느려질 수 있습니다.

Valet 키 패턴을 사용하면 보안, 비용 최적화 및 성능 문제를 해결할 수 있습니다.

1. 마지막으로 책임 있는 순간에 클라이언트는 액세스를 요청하기 위해 경량의 0으로 확장 가능한 Azure Function 호스팅 API에 인증합니다.

2. API는 요청의 유효성을 검사한 다음 시간 및 범위가 제한된 SaS 토큰을 가져오고 반환합니다.

   API에서 생성된 토큰은 클라이언트를 다음 제한으로 제한합니다.

   • 사용할 스토리지 계정입니다. 즉, 클라이언트는 이 정보를 미리 알 필요가 없습니다.
   • 사용할 특정 컨테이너 및 파일 이름입니다. 토큰을 최대 하나의 파일과 함께 사용할 수 있는지 확인합니다.
   • 3분과 같은 짧은 작업 창입니다. 이 짧은 기간은 토큰에 해당 유틸리티를 지나서 확장되지 않는 TTL이 있는지 확인합니다.
   • Blob만 만들 수 있는 권한으로 다운로드, 업데이트 또는 삭제할 수 없습니다.

3. 그런 다음, 클라이언트가 좁은 시간 범위 내에서 해당 토큰을 사용하여 파일을 스토리지 계정에 직접 업로드합니다.

API는 API의 자체 Microsoft Entra ID 관리 ID를 기반으로 사용자 위임 키를 사용하여 권한 있는 클라이언트에 이러한 토큰을 생성합니다. 로깅은 스토리지 계정과 토큰 생성 API 모두에서 활성화되어 토큰 요청과 토큰 사용량 간의 상관 관계를 허용합니다. API는 클라이언트 인증 정보 또는 사용할 수 있는 다른 데이터를 사용하여 다중 테넌트 상황과 같이 사용할 스토리지 계정 또는 컨테이너를 결정할 수 있습니다.

전체 샘플은 발렛 키 패턴 예제의 GitHub에서 사용할 수 있습니다. 다음 코드 조각은 해당 예제에서 조정됩니다. 첫 번째는 Azure Function(ValetKey.Web에 있는)이 Azure Function의 자체 관리 ID를 사용하여 사용자 위임 공유 액세스 서명 토큰을 생성하는 방법을 보여 줍니다.

[Function("FileServices")]
public async Task<StorageEntitySas> GenerateTokenAsync([HttpTrigger(...)] HttpRequestData req, ..., 
                                                        CancellationToken cancellationToken)
{
  // Authorize the caller, select a blob storage account, container, and file name.
  // Authenticate to the storage account with the Azure Function's managed identity.
  ...

  return await GetSharedAccessReferenceForUploadAsync(blobContainerClient, blobName, cancellationToken);
}

/// <summary>
/// Return an access key that allows the caller to upload a blob to this
/// specific destination for about three minutes.
/// </summary>
private async Task<StorageEntitySas> GetSharedAccessReferenceForUploadAsync(BlobContainerClient blobContainerClient, 
                                                                            string blobName,
                                                                            CancellationToken cancellationToken)
{
  var blobServiceClient = blobContainerClient.GetParentBlobServiceClient();
  var blobClient = blobContainerClient.GetBlockBlobClient(blobName);

  // Allows generating a SaS token that is evaluated as the union of the RBAC permissions on the managed identity
  // (for example, Blob Data Contributor) and then narrowed further by the specific permissions in the SaS token.
  var userDelegationKey = await blobServiceClient.GetUserDelegationKeyAsync(DateTimeOffset.UtcNow.AddMinutes(-3),
                                                                            DateTimeOffset.UtcNow.AddMinutes(3),
                                                                            cancellationToken);

  // Limit the scope of this SaS token to the following:
  var blobSasBuilder = new BlobSasBuilder
  {
      BlobContainerName = blobContainerClient.Name,     // - Specific container
      BlobName = blobClient.Name,                       // - Specific filename
      Resource = "b",                                   // - Blob only
      StartsOn = DateTimeOffset.UtcNow.AddMinutes(-3),  // - For about three minutes (+/- for clock drift)
      ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(3),  // - For about three minutes (+/- for clock drift)
      Protocol = SasProtocol.Https                      // - Over HTTPS
  };
  blobSasBuilder.SetPermissions(BlobSasPermissions.Create);

  return new StorageEntitySas
  {
      BlobUri = blobClient.Uri,
      Signature = blobSasBuilder.ToSasQueryParameters(userDelegationKey, blobServiceClient.AccountName).ToString();
  };
}

다음 코드 조각은 API와 클라이언트 모두에서 사용하는 DTO(데이터 전송 개체)입니다.

public class StorageEntitySas
{
  public Uri? BlobUri { get; internal set; }
  public string? Signature { get; internal set; }
}

그런 다음 클라이언트(ValetKey.Client에 있는)는 API에서 반환된 URI 및 토큰을 사용하여 추가 리소스를 요구하지 않고 전체 클라이언트-스토리지 성능에서 업로드를 수행합니다.

...

// Get the SaS token (valet key)
var blobSas = await httpClient.GetFromJsonAsync<StorageEntitySas>(tokenServiceEndpoint);
var sasUri = new UriBuilder(blobSas.BlobUri)
{
    Query = blobSas.Signature
};

// Create a blob client using the SaS token as credentials
var blob = new BlobClient(sasUri.Uri);

// Upload the file directly to blob storage
using (var stream = await GetFileToUploadAsync(cancellationToken))
{
    await blob.UploadAsync(stream, cancellationToken);
}

...

다음 단계

이 패턴을 구현할 때 다음 지침이 관련이 있을 수 있습니다.

• 이 예제의 구현은 발레 키 패턴 예제의 GitHub에서 사용할 수 있습니다.
• SAS(공유 액세스 서명)를 사용하여 Azure Storage 리소스에 대한 제한된 액세스 권한 부여
• Service Bus를 사용한 공유 액세스 서명 인증

관련 참고 자료

이 패턴을 구현할 때 다음 패턴도 관련이 있을 수 있습니다.

• 게이트키퍼 패턴 이 패턴은 클라이언트와 애플리케이션 또는 서비스 간 브로커 역할을 하는 전용 호스트 인스턴스를 사용하여 애플리케이션 및 서비스를 보호하는 데 발레 키 패턴과 함께 사용될 수 있습니다. 게이트키퍼는 요청의 유효성을 검사하고 삭제하고, 클라이언트와 애플리케이션 간에 요청 및 데이터를 전달합니다. 보안의 추가적인 계층을 제공하고 공격에 노출되는 시스템 부분을 줄일 수 있습니다.
• 정적 콘텐츠 호스팅 패턴. 정적 리소스를 클라이언트에 직접 전달할 수 있는 클라우드 기반 스토리지 서비스에 배포하여 비용이 많이 드는 컴퓨팅 인스턴스에 대한 요구를 줄이는 방법을 설명합니다. 리소스를 공개적으로 사용하려는 경우가 아니면 발레 키 패턴을 사용하여 보안을 유지할 수 있습니다.