Лучшая практика для безопасной выборки данных с Mongodb Atlas - PullRequest
Новая
       15

Лучшая практика для безопасной выборки данных с Mongodb Atlas

0 голосов
/ 26 июня 2019

У меня есть клиентское приложение реагирования, которое мне нужно для получения информации из коллекции MongoDB Atlas, которая заполняется непосредственно в источнике другим человеком.Когда я пошел, чтобы проверить строку подключения, я заметил, что пароль пользователя для доступа к базе данных должен присутствовать в коде:

(Недостаточно повторений для публикации изображений, извините) https://i.imgur.com/5Vs23WJ.png

Теперь, очевидно, если я включу это право в мой код переднего плана, кто-нибудь сможет увидеть мой пароль, и это не хорошо.Но мне нужно, чтобы это приложение было автономным, и я не хочу размещать сервер только для перенаправления одного запроса Get, который вызывается при загрузке сайта.

Если я создаю нового пользователя спривилегии только для чтения, безопасно ли хранить пароль этого пользователя (очевидно, супер универсальный) в коде переднего плана для доступа к БД?Есть ли в этом вред?Правильно ли я полагаю, что не включенные в белый список IP-адреса не могут отправлять запросы в базу данных Atlas?Единственный адрес, который будет занесен в белый список, - это IP-адрес, на котором будет размещено веб-приложение, так что я думаю, мне не нужно беспокоиться о том, что кто-то рассылает спам-запросы, чтобы собрать обвинения в моей учетной записи Atlas или совершать какие-либо другие вредоносные действия.?

Я недавно поступил в аспирантуру, поэтому у меня нет большого опыта безопасного развертывания, но я надеюсь, что смогу это изменить этим летом.

Спасибо:)

1 Ответ

1 голос
/ 26 июня 2019

Я не уверен насчет «лучших» практик, но постараюсь ответить в соответствии с тем, что я бы сделал:

Безопасно ли хранить пароль этого пользователя (очевидно, универсальный) в коде переднего плана для доступа к БД?

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

Правильно ли я считаю, что IP-адреса, не занесенные в белый список, не могут отправлять запросы к базе данных Atlas?

Правильно. Только IP-адреса из белого списка смогут подключаться к экземпляру Atlas.

Отвечая на это, я лично сказал бы:

  • создать слой API поверх базы данных, чтобы предотвратить прямой доступ к базе данных клиентским приложением, или
  • (Если применимо) создайте Stitch Webhook , который предоставляет основанный на Stitch уровень REST API поверх развертывания Atlas.

Идея заключается в том, чтобы обеспечить безопасность путем ограничения доступа к базе данных из внешнего мира. Использование белого списка - это один уровень безопасности. Использование REST API - это еще один уровень безопасности, который, по сути, заставляет все, что требует доступа к базе данных, проходить через защищенные ворота, которые находятся под вашим контролем.

Некоторые дополнительные преимущества шлюза REST API:

  • Если ваш URI Atlas изменится в будущем, вам не нужно повторно развертывать клиентские приложения везде снова. Вы просто переконфигурируете шлюз REST API, чтобы он указывал на новый URI Atlas, в то время как ваше клиентское приложение все еще может использовать существующий адрес API REST без изменений.
  • Ограничение клиентских подключений к самой базе данных. Поскольку только ваш API-шлюз может напрямую подключаться к базе данных, маловероятно, что база данных может случайно получить DDOS, если у вас одновременно активно много клиентов.

Обратите внимание, что я не считаю вышеизложенное "наилучшей" практикой каким-либо образом. Это просто, как я бы это сделал.

...