Как развернуть в производство внешний интерфейс, использующий AWS Amplify в качестве внутреннего интерфейса - PullRequest
3 голосов
/ 01 мая 2020

Мой пример использования довольно прост: я хочу развернуть веб-интерфейс для производства, использующего бэкэнд Amplify, без предоставления конфиденциальной конфигурации, такой как ключ API.

У меня есть веб-интерфейс, который использует Github Actions для CI и CD и развертывается в Zeit Now (так как это проект Next. js и нуждается в поддержке SSR, которую в настоящее время Amplify не предоставляет). На данный момент к нему не подключен бэкэнд, поэтому он без проблем разворачивается на производстве.

В том же проекте я настроил AWS Усиление для бэкэнда и подключил его к веб-интерфейсу. Все это работает успешно, как и ожидалось от локальной среды.

Теперь я хочу развернуть интерфейс в производство, однако конфигурация AWS для подключения его к серверу сохраняется в автоматически сгенерированном файле с именем aws-exports.js который содержит среди прочего конечную точку GraphQL и его ключ API. Этот файл был добавлен в .gitignore с помощью Amplify CLI.

Если я удаляю файлы aws-exports.js из .gitignore и фиксирую его в хранилище, я думаю, что он, вероятно, будет работать после развертывания в производство, однако я предполагаю, что это не очень хорошая идея, поскольку я буду показывать конфиденциальные данные конфигурации.

Я не хочу использовать AWS для развертывания моего интерфейса, что и предлагается в качестве решения в документацию, которую я прочитал об этом. Есть ли какой-нибудь рекомендуемый способ сделать это, разделяя среду интерфейса и бэкэнда? (имеется в виду, что внешний интерфейс все еще развернут в Zeit Now, который будет использовать внутренний интерфейс, развернутый в AWS).

1 Ответ

3 голосов
/ 09 мая 2020

Насколько я понимаю, концепция безопасности AWS AppSyn c обозначает модель аутентификации API_KEY для использования в publi c приложениях или средах разработки .

Неаутентифицированные API требуют более строгого регулирования, чем аутентифицированные API. Один из способов контроля регулирования для неаутентифицированных конечных точек GraphQL - использование ключей API.

Ключ API - это жестко заданное значение в вашем приложении, которое генерируется службой AWS AppSyn c при создании конечной точки GraphQL без аутентификации.

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

В документации описано больше моделей аутентификации , [1]
Если вы планируете разработать приложение с частными конечными точками и общедоступным c внешним интерфейсом / клиентом, вам определенно следует использовать другую модель аутентификации - скорее всего, OPENID_CONNECT или AMAZON_COGNITO_USER_POOLS .

Я думаю, что вы должны сначала прочитать сообщение в блоге AWS под названием GraphQL API Security с AWS AppSyn c и Amplify [2], а затем изложить свой вопрос подробнее Точно, если какое-либо отсутствие ясности должно остаться.

Ссылки

[1] https://docs.aws.amazon.com/appsync/latest/devguide/security.html#api ключ-авторизация
[2] https://aws.amazon.com/de/blogs/mobile/graphql-security-appsync-amplify/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...