Являются ли передовые методы повторного использования дескриптора подключения и проектирования пользователей базы данных взаимоисключающими?

SO говорит, что это может быть субъективно. Я надеюсь, что нет - я просто не могу понять, как это работает на практике, и это похоже на достаточно конкретный технический вопрос с, надеюсь, окончательным ответом.

Контекст: стек LAPP.

  1. Я читал, что использование одного пользователя базы данных в качестве логина для всех подключений к базе данных и самостоятельное обеспечение безопасности оттуда - плохая идея. Базы данных имеют достаточные модели безопасности и есть смысл их использовать.

  2. Дескрипторы базы данных связаны с некоторыми затратами ресурсов, поэтому существуют Apache::DBI, DBIx::Connector и DBI::connect_cached() для повторного использования недавнего подключения к базе данных. Их использование должно ускорить работу веб-приложения, избегая затрат на подключение к базе данных.

Причина, по которой эти рекомендации кажутся взаимоисключающими, заключается в том, что, насколько я понимаю, № 1 подразумевает, что любое соединение с базой данных будет выполняться с отдельными учетными данными для каждого пользователя, что подразумевает (как Документы Apache::DBI), что повторное использование таких подключений, скорее всего, быстро приведет к истощению серверной части базы данных. соединений.

По умолчанию максимальное количество соединений для PostgreSQL равно 100.

Количество серверов по умолчанию, умноженное на подпроцессы, разрешенные для каждого, для Apache 2, работающего с prefork MPM, намного превышает это, поэтому кажется, что документы Apache:: DBI верны.

Поэтому возникает вопрос: что люди делают на практике?

Означает ли это, что люди, использующие стек LAPP, обычно подключаются, используя одного пользователя базы данных, и реализуют свою собственную модель безопасности/разрешений? Или это означает, что они не объединяют соединения? Или они выбирают между этими двумя стратегиями, основываясь на требованиях к скорости и безопасности, если они используют стек LAPP, а если им нужно и то, и другое, выбирают настольное приложение или какую-либо другую модель подключения?

Или, если это на самом деле не взаимоисключающие стратегии, что я здесь упускаю в своем понимании?


postgresql database connection-pooling
person Kev    schedule 16.12.2013    source источник
comment
Я думаю, вы путаете идентификаторы приложений и пользователей. Например, приложение может иметь другие ограничения безопасности, которые нельзя смоделировать в базе данных. Я бы создал идентификатор приложения, для которого я могу применять разрешения, связанные с SQL, а также использовать в своей пользовательской схеме, если это необходимо. Затем я бы создал идентификатор пользователя для пользователей, которым требуется прямой доступ к базе данных, таких как ETL, администратор и другие работники. Наличие единого идентификатора приложения упрощает аудит и гарантирует использование правильных разрешений. Использование одного суперидентификатора — плохая идея.   -  person Namphibian    schedule 17.12.2013
comment
Звучит вероятно. Таким образом, пользователь базы данных на самом деле является приложением, а реальный пользователь, использующий мое приложение, не должен быть пользователем базы данных, даже если у меня есть только одно приложение? Если это так, то это прискорбно: мне показалось очень удобным иметь разрешения пользователей и групп, встроенные в таблицы, представления и функции. Это казалось естественным.   -  person Kev    schedule 17.12.2013
comment
@Kev: это кажется естественным, пока вам не понадобится управлять необычным сценарием, например: предоставить этому человеку доступ к моим материалам 1-го числа каждого месяца, если это условие выполнено.   -  person Denis de Bernardy    schedule 17.12.2013
comment
@Denis, подход к представлению с postgres тоже хорошо справляется с этим сценарием.   -  person Kev    schedule 17.12.2013

Ответы (1)


arrow_upward
3
arrow_downward

Я читал, что использование одного пользователя базы данных в качестве логина для всех подключений к базе данных и самостоятельное обеспечение безопасности оттуда - плохая идея. Базы данных имеют достаточные модели безопасности и есть смысл их использовать.

Вы, вероятно, неправильно прочитали это или прочитали в крайне предвзятом месте. Более сбалансированный взгляд (надеюсь) таков:

  • Управление разрешениями (ACL, RBAC или другими) в базе данных представляет собой кровавый беспорядок, и его трудно сделать правильно. Это также может снизить производительность, если сделано неправильно (подумайте: «выберите * из разрешений на соединение с таблицей, где convoluted_permission_scenario».) В зависимости от того, кого вы спросите, вы получите более или менее крайние точки зрения, например. вот (очень спорный) Зед Шоу: http://vimeo.com/2723800.

  • Управление разрешениями на уровне БД — такая же кровавая неразбериха. Не все движки реализуют разрешения на уровне строк, и даже в этом случае иногда случаются утечки. Например, вызов функции в предложении where может (может ли?) привести к утечке строк в Postgres (до последней версии?), если будет вызван raise. И, честно говоря, если отойти от поверхностного анализа происходящего, то это в основном сводится к первому — просто стандартизированному и (обычно) на C.

  • Управление разрешениями на уровне приложения без базы данных — это тоже кровавый беспорядок. Это снизит производительность независимо от того, что вы делаете, с того момента, когда вам нужно присоединиться за пределами SQL, если только вы не имеете дело с тривиальными объемами данных. Если вы попробуете это сделать, у вас все будет хорошо… пока ваша база данных не станет слишком большой, а вы, по сути, этого не сделаете.

Итак, вкратце: это кровавое месиво, где бы вы его ни устроили. Потому что с разрешениями это беспорядок. В дополнение к обычному и идеалистическому «Джоу нужен доступ для записи к этому набору узлов», вам также нужно справиться с более приземленными сценариями, такими как «Джон уезжает в отпуск на Рождество и ему нужно временно делегировать свои права на запись на этот набор узлов своему помощнику Джейн». Более того, какой бы сценарий вы ни выбрали, вам необходимо управлять доступом для чтения (обычно наиболее частым) таким образом, чтобы он был быстрым и имел возможность масштабирования. Нет серебряной пули.

Более того, даже в первом и последнем из приведенных выше сценариев идеально иметь трех пользователей БД. Один для чтения, один для чтения/записи и один для изменений схемы. Большинство приложений этого не делают, потому что это еще один кровавый беспорядок, чтобы настроить ваш ORM таким образом, следовательно, типичный один пользователь БД для каждого приложения.

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

person Denis de Bernardy    schedule 16.12.2013
comment
Спасибо, это информативно. Я работал над разрешениями на уровне строк, используя представления с простыми предложениями where — большинство таблиц имеют представление my_tablename, которое показывает только строки, созданные пользователем (created_by_column = current_user::text::integer). Я предполагаю, что такой подход, который я считал умным в то время, не предназначен для использования в стране LAPP. - person Kev; 17.12.2013
comment
Это умный сценарий, но он не продвинет вас далеко в приложении для продаж, где каждый получатель платежа, получатель, торговый персонал, менеджеры по продажам, вспомогательный персонал, менеджеры по поддержке, старшие руководители и иногда их секретари, а также их кошки, собаки , пони и единороги, как вы их называете, нуждаются в потенциально отдельном наборе разрешений на конкретном узле. - person Denis de Bernardy; 17.12.2013
comment
Денис точно описал публичный веб-сценарий. Базы данных, которые имеют относительно небольшой веб-доступ (возможно, только к удаленным офисам той же компании), обычно используют больше разрешений на уровне базы данных и меньше разрешений на уровне приложений. - person Mike Sherrill 'Cat Recall'; 17.12.2013
comment
@MikeSherrill'Catcall', это важное отличие. Это для интранет-приложения, но даже при относительно небольшом количестве задействованных соединений у нас закончились соединения с базой данных, что и привело меня к этому соображению дизайна. - person Kev; 17.12.2013
comment
@ Денис, я полагаю, что нет. Хотя, кажется, я припоминаю некий проект с использованием Postgres, который обещал разрешения на уровне строк в относительно вменяемой настройке. Хотя я уверен, что там тоже были бы подводные камни. - person Kev; 17.12.2013
comment
@DenisdeBernardy Кстати, Postgres теперь имеет встроенные разрешения на уровне строк. postgresql.org/docs/current/static/ddl-rowsecurity.html< /а> - person Kev; 20.02.2017