Разрешение внутренним командам публиковать сообщения только в SQS

Question

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

Один из способов сделать это - создать пользователя без доступа к консоли aws (только программный доступ к API) и со встроенной политикой (пример политики ниже), разрешающей только «SendMessage» для ресурса. Есть ли какие-либо проблемы безопасности при этом? Каков наилучший способ решения этого варианта использования?

{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:*:123456789012:MyAppQueue"
   }]
}

Answer 1

Рекомендуется использовать Роль AWS с соответствующими разрешениями для вашего приложения при доступе к сервисам AWS. Чтобы использовать роли, ваше приложение должно быть развернуто в AWS.

Что касается реализации, лучшим вариантом (на мой взгляд) было бы создание API, который будет заниматься отправкой сообщений в SQS:

• Создание REST API с использованием API Gateway и Lambda (например, с использованием Безсерверная структура )

• Добавить разрешения для функции Lambda , чтобы разрешить отправку сообщений в SQS

• Настройка аутентификации для API (рекомендуется). Варианты APIKEY, Cognito или пользовательский авторизатор.

При таком сценарии ваше приложение будет вызывать REST API, передавая всю информацию, необходимую для отправки в SQS.

Другой вариант - запустить пользовательское приложение в AWS под ролью службы, которая имеет разрешение на запись в SQS.

Answer 2

Вы можете использовать пользователей IAM для контроля доступа к SQS. Но Вы также можете написать API, который пользователи вызывают со своим сообщением, а ваш API помещает сообщение в SQS. Это облегчит вам включение / отключение доступа для потребителей, добавление ограничения скорости, проверку содержимого сообщения перед его отправкой в ​​SQS.

Вы также можете использовать AWS API Gateway (и дополнительно AWS Lambda ) вместо создания и размещения своей собственной конечной точки API. (см. это и это )