다음을 통해 공유


공유 ACL 설정

Set Share ACL 작업은 공유 액세스 서명과 함께 사용할 저장된 액세스 정책을 설정합니다. 액세스 정책 설정에 대한 자세한 내용은 공유 액세스 서명을 사용하여 Azure Storage 리소스에 대한 제한된 액세스 권한 부여를 참조하세요.

프로토콜 가용성

파일 공유 프로토콜 사용 사용 가능
SMB Yes
NFS 아니요

요청

다음과 같이 요청을 생성할 Set Share ACL 수 있습니다. HTTPS를 사용하는 것이 좋습니다. myaccount를 스토리지 계정 이름으로 바꿉니다.

메서드 요청 URI HTTP 버전
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1

URI 매개 변수

요청 URI에 다음과 같은 추가 매개 변수를 지정할 수 있습니다.

매개 변수 설명
timeout 선택 사항입니다. timeout 매개 변수는 초 단위로 표시됩니다. 자세한 내용은 Azure Files 작업에 대한 시간 제한 설정을 참조하세요.

요청 헤더

다음 표에서는 필수 및 선택적 요청 헤더에 대해 설명합니다.

요청 헤더 Description
Authorization 필수 요소. 권한 부여 체계, 계정 이름 및 서명을 지정합니다. 자세한 내용은 Azure Storage에 대한 요청 권한 부여를 참조하세요.
Date 또는 x-ms-date 필수 요소. 요청에 대한 UTC(협정 세계시)를 지정합니다. 자세한 내용은 Azure Storage에 대한 요청 권한 부여를 참조하세요.
x-ms-version 모든 권한 있는 요청에 필요합니다. 이 요청에 사용할 작업의 버전을 지정합니다. 이 작업은 버전 2015-02-21 이상에서만 사용할 수 있습니다.

자세한 내용은 Azure Storage 서비스에 대한 버전 관리를 참조하세요.
x-ms-client-request-id 선택 사항입니다. 로깅이 구성될 때 스토리지 분석 로그에 기록되는 1키비바이트(KiB) 문자 제한으로 클라이언트에서 생성된 불투명 값을 제공합니다. 이 헤더를 사용하여 클라이언트 쪽 활동과 서버가 수신하는 요청의 상관 관계를 지정하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage 모니터링을 참조하세요.
x-ms-lease-id:<ID> 대상 파일 공유에 활성 임대가 있는 경우 필요합니다. 버전 2020-02-10 이상에 사용할 수 있습니다. 요청에 임대 ID가 포함되지 않거나 유효하지 않으면 상태 코드 412(사전 조건 실패)로 인해 작업이 실패합니다.

이 헤더를 지정하고 대상 파일 공유에 현재 활성 임대가 없는 경우 상태 코드 412(사전 조건 실패)로 인해 작업이 실패합니다.

요청 본문

저장된 액세스 정책을 지정하려면 Set Share ACL 작업에 대한 요청 본문에 고유 식별자와 액세스 정책을 제공합니다.

요소에는 SignedIdentifier 요소에 지정된 고유 식별자가 포함됩니다 Id . SignedIdentifier 에는 요소에 지정된 대로 액세스 정책의 세부 정보도 포함됩니다 AccessPolicy . 고유 식별자의 최대 길이는 64자입니다.

StartExpiry 필드는 UTC 시간으로 표현되어야 하며 유효한 ISO 8061 형식을 준수해야 합니다. 지원되는 ISO 8061 형식은 다음과 같습니다.

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.fffffffTZD

이러한 형식의 날짜 부분에서 YYYY는 4자리 숫자 연도, MM은 2자리 숫자 월, DD는 2자리 숫자 일을 나타냅니다. 시간 부분에서 hh는 24시간 형식의 시간, mm은 2자리 숫자 분, ss는 2자리 숫자 초, fffffff는 7자리 숫자 밀리초를 나타냅니다. 시간 지정자는 T 문자열의 날짜 및 시간 부분을 구분합니다. 표준 시간대 지정자는 TZD 표준 시간대를 지정합니다.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  

샘플 요청

Request Syntax:  
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2015-07-01T08:49:37.0000000Z</Start>  
      <Expiry>2015-07-02T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  

응답

응답에는 HTTP 상태 코드 및 응답 헤더 집합이 포함되어 있습니다.

상태 코드

작업에 성공하면 상태 코드 200(정상)이 반환됩니다.

응답 헤더

이 작업의 응답에는 다음과 같은 헤더가 포함됩니다. 응답에는 추가 표준 HTTP 헤더도 포함될 수 있습니다. 모든 표준 헤더는 HTTP/1.1 프로토콜 사양을 준수합니다.

응답 헤더 Description
ETag 컨테이너가 마지막으로 수정된 날짜와 시간을 반환합니다. 날짜 형식은 RFC 1123을 따릅니다. 자세한 내용은 헤더의 날짜/시간 값 표현을 참조하세요.
Last-Modified 공유 또는 해당 속성 또는 메타데이터를 수정하는 모든 작업은 파일의 사용 권한 설정을 포함하여 마지막으로 수정된 시간을 업데이트합니다. 파일에 대한 작업은 공유의 마지막으로 수정된 시간에 영향을 주지 않습니다.
x-ms-request-id 만들어진 요청을 고유하게 식별하며 요청 문제 해결에 사용할 수 있습니다. 자세한 내용은 API 작업 문제 해결을 참조하세요.
x-ms-version 요청을 실행하는 데 사용된 Azure Files 버전을 나타냅니다.
Date 또는 x-ms-date 서비스에서 응답을 보낸 시간을 나타내는 UTC 날짜/시간 값입니다.
x-ms-client-request-id 요청 및 해당 응답 문제를 해결하는 데 사용할 수 있습니다. 이 헤더의 값은 헤더 값 x-ms-client-request-id 과 같으며, 요청에 있고 값이 최대 1,024자 표시 ASCII 문자인 경우 입니다. 헤더가 x-ms-client-request-id 요청에 없는 경우 이 헤더는 응답에 존재하지 않습니다.

샘플 응답

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: <date>  
ETag: "0x8CB171613397EAB"  
Last-Modified: <date>  
x-ms-version: 2015-02-21  
Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0  

권한 부여

계정 소유자만 이 작업을 호출할 수 있습니다.

설명

다음 조건 중 하나가 충족되지 않는 한 계정 소유자만 특정 공유의 리소스에 액세스할 수 있습니다.

  • 소유자는 공유에 대한 권한을 설정하여 공유 리소스를 공용 액세스에 사용할 수 있도록 지정했습니다.
  • 소유자가 공유 내의 리소스에 대한 공유 액세스 서명을 발급했습니다.

컨테이너에 대한 권한을 설정하면 기존 권한이 바뀝니다. 컨테이너의 권한을 업데이트하려면 공유 가져오기 ACL 을 호출하여 컨테이너와 연결된 모든 액세스 정책을 가져옵니다. 변경하려는 액세스 정책을 수정한 다음 전체 데이터 집합을 사용하여 를 호출 Set Share ACL 하여 업데이트를 수행합니다.

공유 수준 액세스 정책 설정

저장된 액세스 정책은 연결된 공유 액세스 서명에 대한 시작 시간, 만료 시간 및 권한을 지정할 수 있습니다. 공유 또는 파일 리소스에 대한 액세스를 제어하는 방법에 따라 다음을 수행할 수 있습니다.

  • 저장된 액세스 정책 내에서 이러한 매개 변수를 모두 지정하고 공유 액세스 서명의 URL에서 생략합니다. 이렇게 하면 연결된 서명의 동작을 수정하거나 언제든지 해지할 수 있습니다.
  • 저장된 액세스 정책 내에서 하나 이상의 액세스 정책 매개 변수를 지정하고 URL에 다른 매개 변수를 지정합니다.
  • URL에서 모든 매개 변수를 지정합니다. 이 경우 저장된 액세스 정책을 사용하여 서명을 취소할 수 있지만 해당 동작을 수정할 수는 없습니다.

액세스 정책 설정에 대한 자세한 내용은 공유 액세스 서명을 사용하여 Azure Storage 리소스에 대한 제한된 액세스 권한 부여를 참조하세요.

공유 액세스 서명과 저장된 액세스 정책에는 서명에 권한을 부여하는 데 필요한 모든 필드가 포함되어야 합니다. 필수 필드가 하나라도 누락될 경우 요청에 실패합니다. 마찬가지로 필드가 공유 액세스 서명 URL 및 저장된 액세스 정책에서 모두 지정될 경우, 요청은 상태 코드 400(잘못된 요청)의 오류가 발생합니다. 공유 액세스 서명을 구성하는 필드에 대한 자세한 내용은 공유 액세스 서명 사용을 참조하세요.

언제든지 공유에 대해 최대 5개의 별도 액세스 정책을 설정할 수 있습니다. 요청 본문에 5개 이상의 액세스 정책이 전달되면 서비스는 상태 코드 400(잘못된 요청)을 반환합니다.

공유 액세스 서명은 컨테이너 데이터를 익명 읽기 액세스에 사용할 수 있는지 여부에 관계없이 공유 또는 파일에서 발급할 수 있습니다. 공유 액세스 서명은 리소스에 액세스할 수 있는 방법, 시기 및 대상을 보다 자세히 제어할 수 있습니다.

공유 스냅샷 대한 액세스 정책을 설정하거나 검색할 수 없습니다. 액세스 정책을 설정하려고 하면 서비스는 상태 코드 400(InvalidQueryParameterValue)을 반환합니다.

참고

컨테이너에 저장된 액세스 정책을 설정하는 경우 적용되는 데 최대 30초가 걸릴 수 있습니다. 이 간격 동안 저장된 액세스 정책과 연결된 공유 액세스 서명은 액세스 정책이 활성화될 때까지 상태 코드 403(사용할 수 없음)과 함께 실패합니다.

추가 정보

FileShare 리소스에 대한 작업(Azure Files)