Дочерние учетные записи в Amazon S3 (например, Nirvanix) (дополнительные учетные записи, учетные записи клиентов) - PullRequest
Новая
       24

Дочерние учетные записи в Amazon S3 (например, Nirvanix) (дополнительные учетные записи, учетные записи клиентов)

2 голосов
/ 10 марта 2011

Мы переходим от Nirvanix к Amazon S3.

Мне нужно смоделировать стиль Nirvanix дочерние учетные записи для хранилища S3.

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

У нас будет более 100 пользователей, поэтому корзина на пользователя не будет работать (это по-прежнему ограничено 100, верно?).

Хранилище используется непосредственно из настольного приложения (а не, например, через наши серверы, хотя есть центральный сервер, если это помогает).

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

Nirvanix предоставляет это из коробки (http://developer.nirvanix.com/sitefiles/1000/API.html#_TocCreatingChildAccounts) - это, по сути, то, что я пытаюсь воспроизвести с помощью S3.

Я понимаю, как сегментировать объекты для каждого субпользователя, например, используя «префиксную» нотацию объектов (например, «USER1 / object1», «USER2 / something_else).

Что я не могу понять:

1) Как настроить разрешения, чтобы каждый клиент мог получить доступ только к своим файлам?

Если я предоставлю «приложению» доступ к хранилищу S3, то это, очевидно, означает, что каждый пользователь приложения сможет получить доступ к любым файлам.

Кажется, вы можете установить расширенные ACL, но я не могу понять, "кому" вы можете устанавливать разрешения. Это только пользователи AWS? Означает ли это, что единственный способ сделать это состоит в том, чтобы каждый из моих клиентов имел учетную запись AWS?

Если так, могу ли я создавать учетные записи от их имени? Например. через вызов API?

То, что мы, безусловно, не можем допустить, - это чтобы каждый пользователь создавал учетную запись через веб-сайт AWS (чёрт!).

2) Есть идеи о том, как лучше управлять квотами для каждого клиента?

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

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

Спасибо всем!

John

1 Ответ

2 голосов
/ 11 марта 2011

У Amazon есть новая бета-служба под названием Управление идентификацией и доступом AWS (IAM) , которая позволит вам сегментировать сегменты.

В разделе с использованием S3 документации есть примеры, описывающие ваш вариант использования:

Пример 1 : разрешить каждому пользователю иметь домашний каталог в Amazon S3

В этом примере мы создаем политику что мы прикрепим к имени пользователя Боб. Политика дает Бобу доступ к следующий домашний каталог в Amazon S3: my_corporate_bucket/home/bob. Бобу разрешен доступ только к конкретные действия Amazon S3, показанные в политика, и только с объектами в его домашнем каталоге. 

{
   "Statement":[{
      "Effect":"Allow",
      "Action":["s3:PutObject","s3:GetObject","s3:GetObjectVersion",
      "s3:DeleteObject","s3:DeleteObjectVersion"],
      "Resource":"arn:aws:s3:::my_corporate_bucket/home/bob/*"
   }
   ]
}

К сожалению, я не думаю, что в настоящее время вы можете применять квоты с использованием IAM.

Кроме того, в зависимости от вашей платформы вы, вероятно, захотите использовать один из SDK , доступный для упрощения взаимодействия с этими службами.

Вы абсолютно не хотите распространять свой стандартный secret key в настольном приложении без принятия каких-либо серьезных мер предосторожности. Любой пользователь с вашим секретным ключом может иметь полный доступ ко всем вашим сервисам AWS.

...