Я работаю с postgre (AWS RDS) для своей базы данных и использую узел (AWS EC2) на стороне сервера. Я только начинаю, поэтому у меня мало контекста. Я всегда использовал другое стороннее программное обеспечение, такое как Parse for DB, поэтому мои приложения получали доступ к базе данных через Parse API. Поэтому я подумал, что сделаю то же самое для Postgres. Чем больше я читаю об этом, тем больше людей говорят, что мне нужен промежуточный сервер, чтобы предотвратить прямую ссылку из клиентского приложения на БД по соображениям безопасности. Я понимаю эту точку, отсюда и сервер узла.
Но затем, когда я использовал библиотеки узлов, я понял, что установить соединение от сервера к БД было сложно. В стабильном мире я могу установить только 20 подключений одновременно. Так что, если бы я использовал прямое подключение клиентского приложения к БД, это было бы слишком интенсивно для БД.
Помимо соображений безопасности, является ли это основной причиной, по которой люди рекомендуют использовать промежуточный серверный уровень между клиентским приложением и БД?
Или есть другие технические причины, о которых я не знаю?
Причина, по которой приложение не должно напрямую подключаться к базе данных, проста: приложение - это код, который вы выпустили, который работает в месте, которое вы не контролируете, и, следовательно, нельзя доверять учетным данным базы данных.
Код может быть реконструирован, а учетные данные обнаружены, и теперь злоумышленник имеет полный доступ к вашей базе данных и может делать все, на что у приложения было разрешение.
Промежуточный уровень создает и обеспечивает критическую границу: объекту, общающемуся с базой данных, можно доверять доступ к базе данных, поскольку, исключая недостатки проектирования, он не будет добровольно делать с базой данных ничего, чего не должен, и никому не позволит попросить.
Все остальные соображения по сути второстепенны, в том смысле, что даже если вы их решите, это все равно останется, вырисовывается.
Возможно, это недоразумение. Сегодняшние веб-приложения - это НЕ простая двухуровневая установка. Даже старый добрый XAMPP, WAMPP - это контроллер (модель-представление-контроллер).
Пользователь не взаимодействует напрямую с серверной частью БД ваших приложений, они видят пользовательский интерфейс, слой просмотра. Логика внутреннего рабочего процесса - это ваш код, Контроллер. Пока вы подключаетесь к своей модели БД через контроллер.
Однако, если вы вводите в представление некоторые функции запросов к БД, вы должны их очистить. Неважно, сколько «средних слоев» вы вводите.
Если вам не нужна высокая доступность, которая позволяет прозрачно переключать сервер базы данных, ИЛИ сервер приложений балансировки нагрузки, ИЛИ службы очередей функций, ИЛИ горизонтальное масштабирование сервера и т. Д. Нет причин вводить ненужный уровень промежуточного программного обеспечения. Каждое промежуточное ПО представляет дополнительную единую точку отказа.
Вы вводите промежуточное ПО только в том случае, если они вам НУЖНЫ, а не потому, что кто-то говорит, что вы их ХОТИТЕ.
Пример 1 промежуточного программного обеспечения: когда у вас есть сложная логика, которая должна взаимодействовать с другим источником данных, использование промежуточного программного обеспечения с его логикой правил, запускающей логический поток, лучше, чем писать логику внутри вашего приложения.
Пример 2 промежуточного программного обеспечения: используйте систему очереди сообщений, которая объединяет и распределяет задачи, сообщения, информацию для стека сервера для многопроцессорной или распределенной обработки. Поэтому, если это конкретное приложение поддерживает MQ, вам даже не нужно подключаться к базе данных, вы просто подключаетесь к серверу MQ. Скажем, после завершения ваши приложения отправляют информацию в другую очередь, чтобы уведомить о результатах, а другое приложение позаботится о логике.
Перенести модель базы данных подальше от логики контроллера приложений звучит круто, но есть золотая середина. Вы должны знать свои бизнес-требования.
БД может находиться на любом внутреннем сервере, включая веб-сервер или любые другие онлайн-сервисы.
поскольку Parse не поддерживает PostGres, вам придется найти другую систему для управления серверной частью, которая также может оказать значительное влияние на взаимодействие с клиентской частью.
Чего вам не следует делать, так это пытаться найти способ для внешнего интерфейса напрямую подключаться к базе данных. Это вызывает огромную нагрузку на БД, а также влечет за собой важные проблемы с безопасностью.