Написать в техподдержку Позвонить нам
Админпанель Выход

Содержание статьи:

    Список управления доступом

    Общая информация

    ACL (Access Control List) позволяет контроллировать, какие операции разрешены каким пользователям. ACL может стоять как и на уровне всего бакета, так и на уровне конкретного объекта. Установить и прочесть ACL можно через приведенные методы ниже. По умолчанию, создаваемый бакет или объект максимально ограничен в доступе -- только владелец бакета/объекта может работать с ним. У остальных пользователей - запрет доступа. ACL указывается в XML формате. Где в поле Owner ID нужно указать свой канонический идентификатор в системе MCS. Получить его можно разными способами. Один из них:

    $ aws s3api list-buckets --query Owner.ID --output text --endpoint-url https://hb.bizmrg.com

    Пример ACL, который дает те же права, что и по умолчанию (только владелец имеет полный доступ, никто больше):

    <?xml version="1.0" encoding="UTF-8"?>
    <AccessControlPolicy xmlns="http://<имя_бакета>.hb.bizmrg.com/images/01.jpg/">
      <Owner>
        <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
        <DisplayName>owner-display-name</DisplayName>
      </Owner>
      <AccessControlList>
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:type="Canonical User">
            <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
            <DisplayName>display-name</DisplayName>
          </Grantee>
          <Permission>FULL_CONTROL</Permission>
        </Grant>
      </AccessControlList>
    </AccessControlPolicy>


    • Элемент <Owner> производит идентификацию владельца по каноническому идентификатору пользователя учетной записи MCS.
    • Элемент <Grant> определяет идентификатор получателя для предоставляет разрешение.
    • Элемент <Permission> внутри <Grant> определяет тип доступа для получателя.

    Базовый ACL, показанный выше в качестве примера, имеет один элемент <Grant>. Чтобы описать несколько получателей, то для каждого надо добавить свой элемент <Grant>.

    Примечание

    ACL может содержать не более 100 разрешений

    При установку через HTTP заголовки, нужно использовать заголовки для выдачи специфичных для заголовка прав:

    • x-amz-grant-read — Список получателей прав для READ.
    • x-amz-grant-write — Список получателей прав для WRITE.
    • x-amz-grant-read-acp — Список получателей прав для READ_ACP.
    • x-amz-grant-write-acp — Список получателей прав для WRITE_ACP.
    • x-amz-grant-full-control — Список получателей прав для FULL_CONTROL.
    • x-amz-acl — Использование шаблонного ACL.

    Ниже даны описания каждого из прав и что указывать в значениях заголовков.

    Выдача прав

    Идентификатор для выдачи прав может быть несколько типов:

    • Конкретный пользователь в MCS. Для этого нужно знать его уникальный индентификатор.
    • Проект в MCS. Для этого нужно знать уникальный идентификатор проекта.
    • Предварительно определенные группы. Списк указан ниже.
    • Весь мир. Включая анонимный доступ. Любой, знающий полный адрес до объекта, имеет доступ.

    Выданное право для идентификатора выше может быть одним или составлено из нескольких типов:

    • READ — только чтение, какие-либо изменения не разрешены.
    • WRITE — только запись, какие-либо чтения не разрешены. Включая удаление.
    • READ_ACP — чтение ACL, какие-либо изменения не разрешены.
    • WRITE_ACP — запись ACL, какие-либо чтения не разрешены. Включая удаление.
    • FULL_CONTROL — все, что перечислено выше, сразу.


    Выдача прав по идентификатору пользователя

    Идентификатор пользователя (он же известен как канонический ID/Canonical ID) -- это уникальный идентификатор, состоящий из набора символов. Пример - fcd68908-6c76-42d1-968b-82ae2a5a251d. Формат не фиксирован, при работе с идентификатором пользователя какие-либо преобразования и привязки к формату индентификатора не рекомендуются.

    • Если используется установка через XML, то внутри <Grantee> надо указать тег <ID>.
      Пример: <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
    • Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.
      Пример: id="fcd68908-6c76-42d1-968b-82ae2a5a251d".
    Канонический ID пользователя учетной записи MCS можно получить, прочитав ACL бакета или объекта, к которому учетная запись MCS имеет права доступа. Когда отдельная учетная запись MCS получает разрешения по запросу на Grant, в ACL добавляется запись гранта с каноническим ID пользователя учетной записи MCS.


    Примечание

    Если сделать свой бакет общедоступным (не рекомендуется), любой неаутентифицированный пользователь может загружать объекты в бакет. У этих анонимных пользователей нет учетной записи MCS. Когда анонимный пользователь загружает объект в бакет, MCS S3 добавляет специальный канонический ID пользователя (65a011a29cdf8ec533ec3d1ccaae921c) в качестве владельца объекта в ACL.

    Выдача прав по идентификатору проекта

    Если идентификатор пользователя неизвестен, но известен идентификатор проекта, то можно указать проект. При обработке запроса на установку ACL, система ищет идентификатор пользователя и сохраняет его в ACL. В результате ACL всегда будут содержать канонический ID пользователя для проекта, а не идентификатор проекта.

    • Если используется установка через XML, то внутри <Grantee> надо указать тег <EmailAddress>.
      Пример: <EmailAddress>mcs2400549523</EmailAddress>
    • Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.
      Пример: emailAddress="mcs2400549523".

    Получить свой идентификатор проекта можно в личном кабинете в области информации об учетной записи. Кнопка, расположенная рядом с идентификатором проекта позволяет скопировать параметр для удобства:


    Внимание

    При предоставлении другим учетным записям MCS доступ к своим ресурсам, следует учитывать, что учетные записи MCS могут делегировать свои разрешения пользователям под своими учетными записями. Это известно как доступ к нескольким аккаунтам.

    Выдача предварительно определенным метагруппам

    Hotbox имеет набор предопределенных групп. Указывая специальный идентификатор "пользователя", система автоматически подставляет права по правилам, указанным ниже. То, что идентификатор выглядит как ссылка на AWS, не означает, что используются ресурсы AWS S3. Эти идентификаторы обрабатываются только как набор символов и используются для обратной совместимости с программами, которые созданы для AWS S3.

    • Authenticated Usersгруппа авторизованных пользователей. Эта метагруппа содержит все существующие учетные записи в системе MCS, включая те, которыми вы не можете управлять. Разрешение на доступ к этой группе позволяет любой учетной записи MCS получить доступ к ресурсу. Однако все запросы должны быть подписаны (аутентифицированы). Нужно указывать http://acs.amazonaws.com/groups/global/AuthenticatedUsers в поле URI. Авторизированным пользователям надо подписывать свои запросы для доступа к ресурсу.

    Внимание

    При предоставлении доступа группе пользователей Authenticated Users, любой авторизованный пользователь MCS из Интернет может получить доступ к ресурсу.

    • All Users — группа «Все пользователи». Эта метагруппа снимает какие-либо ограничения на указанное право. Например, если сделать открытый доступ на READ, то любой пользователь может считывать содержимое, если он знает только имя бакета и имя объекта. А WRITE для всех позволяет любому пользователю все, что это право даёт. Нужно указывать http://acs.amazonaws.com/groups/global/AllUsers в поле URI.

    Осторожно!

    Убедительно просим взвесить все аргументы в пользу использования метагрупп!

    Открывая доступ неопределенному кругу лиц, Вы теряете контроль, кто сможет совершать операции с Вашими ресурсами. Оплата за их действия совершается владельцем бакета. Самый неблагоприятный сценарий - анонимный пользователь с WRITE-доступом удаляет нужные для хранения объекты и размещает терабайты нежелательных файлов другому владельцу бакета.

    Анонимные неавторизированные пользователи, если им предоставлен доступ, совершают действия под каноническим ID пользователя 65a011a29cdf8ec533ec3d1ccaae921c, так как у них нет учетной записи в MCS.

    • Если используется установка через XML, то внутри <Grantee> надо указать тег <URI>.
      Пример: <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI>
    • Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.
      Пример: uri="http://acs.amazonaws.com/groups/global/AllUsers"
     


    Виды разрешений

    В таблице перечислены наборы разрешений, которые MCS S3 поддерживает в ACL. Набор разрешений ACL одинаков для ACL объекта и ACL бакета. Эти ACL предоставляют разрешения для определенных бакетов или операций с объектами. В таблице перечислены разрешения и описано, что они означают в контексте объектов и бакетов.

    Разрешение Применение к бакету Применение к объекту
    READ
    • HeadBucket
    • GetBucketLifecycle
    • GetBucketNotification
    • ListObjects
    • ListParts
    • ListMultiparts

    Позволяет получить содержимое объекта и его метаданные:

    • GetObject
    • HeadObject
    • GetObjectRange

    WRITE

    Позволяет создавать, удалять, перезаписывать любые объекты в бакете:

    • DeleteBucketNotification
    • PutBucketNotification
    • PutBucketLifecycle
    • DeleteBucketLifecycle
    • DeleteObject
    • DeletMultipleObjects
    • AbortMultipart
    • InitMultipart
    • UploadPart
    • CompliteMultipart
    • PutObject
    • PutObjectCopy
    Не применимо
    READ_ACP

    Позволяет читать ACL бакета: 

    • GetBucketAcl
    • GetBucketCors

    Позволяет читать ACL объекта: 

    GetObjectAcl


    WRITE_ACP

    Позволяет изменять ACL бакета:

    • CreatePrefixKey
    • DeletePrefixKey
    • ListPrefixKeys
    • PutBucketCors
    • DeleteBucketCors
    • PutBucketAcl

    Позволяет изменять ACL объекта 

    PutObjectAcl


    FULL_CONTROL Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для бакета Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для объекта

    Сопоставление разрешений ACL и разрешений политики доступа

    ACL допускает только конечный набор разрешений по сравнению с количеством разрешений, которые можно установить в политике доступа. Каждое из этих разрешений позволяет выполнять одну или несколько операций MCS S3.

    В следующей таблице показано, как каждое разрешение ACL сопоставляется с соответствующими разрешениями политики доступа. Как видно, политика доступа допускает больше разрешений, чем ACL. ACL используется в основном для предоставления базовых разрешений на чтение и запись, аналогично разрешениям файловой системы.

    Разрешение ACL Политика доступа для бакета Политика доступа для объекта
    READ ListBucket,
    ListBucketMultipartUploads
    GetObject
    WRITE PutObject,
    DeleteObject
    Не применимо
    READ_ACP GetBucketAcl GetObjectAcl
    WRITE_ACP PutBucketAcl PutObjectAcl
    FULL_CONTROL Эквивалент предоставлению READ, WRITE,
    READ_ACP, и WRITE_ACP ACL разрешений
    Эквивалент предоставлению READ, READ_ACP и WRITE_ACP ACL разрешений

    Ключи состояния

    При предоставлении разрешения политики доступа, можно использовать условные ключи, чтобы ограничить значение ACL для объекта с помощью политики бакета. Приведенные ниже контекстные ключи соответствуют спискам ACL. Эти контекстные ключи предназначены для указания использования определенного ACL в запросе:

    • s3:x-amz-grant-read - Доступ на чтение
    • s3:x-amz-grant-write - Права записи
    • s3:x-amz-grant-read-acp - Доступ на чтение ACL бакета
    • s3:x-amz-grant-write-acp - Права на запись ACL бакета
    • s3:x-amz-grant-full-control - Полный контроль
    • s3:x-amz-acl - Использование шаблонного ACL

    Пример ACL

    <?xml version="1.0" encoding="UTF-8"?>
    <AccessControlPolicy xmlns="http://<имя_бакета>.hb.bizmrg.com/images/01.jpg/">
      <Owner>
        <ID>Owner-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Owner>
      <AccessControlList>
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <ID>Owner-canonical-user-ID</ID>
            <DisplayName>display-name</DisplayName>
          </Grantee>
          <Permission>FULL_CONTROL</Permission>
        </Grant>
        
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <ID>user1-canonical-user-ID</ID>
            <DisplayName>display-name</DisplayName>
          </Grantee>
          <Permission>WRITE</Permission>
        </Grant>
    
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
            <ID>user2-canonical-user-ID</ID>
            <DisplayName>display-name</DisplayName>
          </Grantee>
          <Permission>READ</Permission>
        </Grant>
    
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
            <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> 
          </Grantee>
          <Permission>READ</Permission>
        </Grant>
    
        <Grant>
          <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
            <EmailAddress>project-ID</EmailAddress>
          </Grantee>
          <Permission>READ</Permission>
        </Grant>
    
     </AccessControlList>
    </AccessControlPolicy>

    Фиксированный ACL

    MCS S3 поддерживает набор предопределенных разрешений, известных как стандартные списки ACL. Каждый фиксированный ACL имеет предопределенный набор получателей и разрешений. В следующей таблице перечислены стандартные списки ACL и связанные с ними предопределенные разрешения.

    Фиксированный ACL Относится к Разрешения добавлены в ACL
    private Бакет и объект Владелец получает FULL_CONTROL. Больше ни у кого нет прав доступа (по умолчанию).
    public-read Бакет и объект Владелец получает FULL_CONTROL. Группа AllUsers получает READ доступ.
    public-read-write Бакет и объект Владелец получает FULL_CONTROL. Группа AllUsers получает READ и WRITE доступ.
    aws-exec-read Бакет и объект Владелец получает FULL_CONTROL.
    authenticated-read Бакет и объект Владелец получает FULL_CONTROL. Группа AuthenticatedUsers получает READ доступ.
    bucket-owner-read Объект Владелец объекта получает FULL_CONTROL. Владелец бакета получает READ доступ. Если указать этот шаблонный ACL при создании бакета, MCS S3 проигнорирует его.
    bucket-owner-full-control Объект И владелец объекта, и владелец бакета получают FULL_CONTROL над объектом. Если указать этот фиксированный ACL при создании бакета, MCS S3 проигнорирует его.


    Примечание

    В запросе можно указать только один из этих фиксированных списков ACL.

    В запросе указывается фиксированный ACL, используя заголовок запроса x-amz-acl. Когда MCS S3 получает запрос со стандартным списком управления доступом в запросе, он добавляет предопределенные разрешения в список управления доступом ресурса.

    Полезна ли была эта статья?