Политика AWS S3 IAM для разрешений на чтение и запись для одного ведра

Question

В главе 11.4.4 'Image upload in production' учебника Rails Майкла Хартла предлагается использовать Amazon Web Services S3 в качестве службы облачного хранилища. В примечании в нижней части страницы автор сам определяет этот раздел книги как «сложный», а также предполагает, что он «может быть пропущен без потери непрерывности».

Действительно, одной из самых сложных частей этого раздела является поиск подходящей политики IAM, которую можно подключить к пользователю IAM в AWS, чтобы предоставить пользователям права доступа на чтение и запись IAM для ведомого устройства S3.

Я обнаружил, что это в Stackoverflow является общей проблемой: см., Например, «Trying to set up Amazon's S3 bucket: 403 Forbidden error & setting permissions».

Фактически, Amazon Web Services's solution для приложений, которым необходимы права на чтение и запись на одном ведро S3, не работает, и пользователь, который пытается загрузить изображения, получает статус запрета на 403 с сервера AWS в Heroku.

Предопределенная политика «AmazonS3FullAccess» действительно работает, однако ее нельзя рассматривать как окончательное решение, поскольку предоставление слишком большого количества разрешений для пользователя IAM и, следовательно, для приложения не требуется, а также, я полагаю, может быть ошибкой безопасности.

В чем же правильная политика IAM?

Answer 1

Если политика «AmazonS3FullAccess» работает, в ней обязательно должно быть какое-то действие, необходимое для работы приложения.

Помимо действий ListBucket, PutObject, GetObject и DeleteObject, чье присутствие кажется логичным, я обнаружил, что PutObjectAcl также необходимо.

От Access Control List (ACL) Overview АМС в:

«списки Amazon S3 управления доступом (ACL) позволяет управлять доступом к ведрам и объектам Каждого ведра и объект имеет ACL, прикрепленное к нему как subresource Он определяет, какой AWS.. учетным записям или группам предоставляется доступ и тип доступа. Когда запрос получен от ресурса, Amazon S3 проверяет соответствующий ACL, чтобы проверить, что запрашивающий имеет необходимые разрешения доступа. Когда вы создаете ведро или объект, Amazon S3 создает ACL по умолчанию, который предоставляет владельцу ресурса полный контроль над ресурсом «

Кроме того, из documentation on 'PutObjectAcl':

«Эта реализация операции PUT использует подресурс acl для установки разрешений списка управления доступом (ACL) для объекта, который уже существует в ведре ... ACL объекта устанавливается на уровне версии объекта. По умолчанию, PUT устанавливает ACL текущей версии объекта «.

Я не мог найти объяснение в my request of support от форумов Amazon о том, почему PutObjectAcl необходимо, но из моего понимания, вероятно, операция создания ACL из объект выполняется в первый раз, когда объект загружается в ведро и должен быть явно запрошен приложением (или пользователем IAM), которое делает загрузку. Вы можете найти копию моей политики в вышеупомянутом обсуждении форума Amazon и ниже:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
    { 
     "Action": [ 
     "s3:ListBucket" 
     ], 
     "Effect": "Allow", 
     "Resource": "arn:aws:s3:::<bucket-name>" 
    }, 
    { 
     "Action": [ 
     "s3:DeleteObject", 
     "s3:GetObject", 
     "s3:PutObject", 
     "s3:PutObjectAcl" 
     ], 
     "Effect": "Allow", 
     "Resource": "arn:aws:s3:::<bucket-name>/*" 
    } 
    ] 
} 

Рассмотрите также Heroku's suggestions по выбору вашего имени ведра: избегайте, например, пунктуации.