Назад | Перейти на главную страницу

Реализация передовой практики ролей Postgres

Ребята,

Мне не помешала бы ваша помощь, чтобы мой дизайн управления доступом пользователей Postgres был лучше и лучше соответствовал лучшим практикам. Я помогаю развернуть небольшой производственный сервер Postgres, но я не администратор БД, поэтому знаю достаточно, чтобы быть опасным.

Есть один сервер с одной установкой Postgres v9.2. В этой установке размещено несколько баз данных, каждая из которых полностью обслуживает своего «клиента». Другими словами, customer1 не будет, не должен использовать database2 и так далее. Во время обычных операций к базам данных обращается соответствующий экземпляр CakePHP, который находится на том же сервере, что и Postgres. Хотя в этом развертывании могут быть возможные оптимизации, меня больше всего интересуют роли Psql.

Исходя из того, что я прочитал, кажется, есть смысл использовать три типа ролей:

Я гораздо менее уверен в реализации этого дизайна. Право собственности на БД по сравнению с таблицей, а также то, кто должен наследовать, немного нечеткое. Ниже мои базы данных и мои пользователи. Достаточно ли этой информации для оценки реализации?

     Role name |                   Attributes                   |     Member of     
    -----------+------------------------------------------------+-------------------
     admin     | Create role, Create DB                         | {user1, user2}
     postgres  | Superuser, Create role, Create DB              | {}
     user1     |                                                | {}
     user2     |                                                | {}

    postgres=# \l
                                 List of databases
       Name    |  Owner   | Encoding | Collate | Ctype |   Access privileges   
    -----------+----------+----------+---------+-------+-----------------------
     admin     | postgres | UTF8     | en_US   | en_US | =Tc/postgres         +
               |          |          |         |       | postgres=CTc/postgres+
               |          |          |         |       | admin=CTc/postgres
     postgres  | postgres | UTF8     | en_US   | en_US | 
     template0 | postgres | UTF8     | en_US   | en_US | =c/postgres          +
               |          |          |         |       | postgres=CTc/postgres
     template1 | postgres | UTF8     | en_US   | en_US | =c/postgres          +
               |          |          |         |       | postgres=CTc/postgres
     user1     | admin    | UTF8     | en_US   | en_US | =Tc/admin            +
               |          |          |         |       | admin=CTc/admin      +
               |          |          |         |       | user1=CTc/admin
     user2     | admin    | UTF8     | en_US   | en_US | =Tc/admin            +
               |          |          |         |       | admin=CTc/admin      +
               |          |          |         |       | user2=CTc/admin

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

local   all             all                                     md5
host    all             all             127.0.0.1/32            md5
host    all             all             ::1/128                 md5

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

То, что вы пытаетесь сделать, называется мульти аренды на уровне базы данных. Этого можно добиться двумя способами:

  1. Однако в одном кластере базы данных, как описано в OP, мой личный выбор был бы следующим:

    • Пользователь postgres использует одноранговую аутентификацию и ему не разрешены парольные соединения. Аутентификация MD5, на мой взгляд, плохая практика. Если у вас возникнут какие-либо проблемы с согласованностью базы данных или подобные вещи, вы все равно сможете войти в систему, если позволите postgres использовать одноранговую аутентификацию.
    • У каждого покупателя должно быть свое схема а не базу данных. Для этого есть несколько причин:
      • Владение всей базой данных предоставит множество привилегий.
      • Владение только определенными таблицами может создать проблемы для разработчиков и всегда требует от администраторов добавления разрешений и прочего.
      • Таким образом, при нормальной настройке каждый из них получит доступ для создания вещей внутри своей схемы, включая таблицы, представления, триггеры и т. Д.
      • Все они используют одну и ту же строку подключения, кроме имени пользователя. В postgres по умолчанию, если у вас есть схема с именем вашего пользователя, она автоматически находится в вашем search_path.
    • Я бы предпочел не иметь пользователя-администратора, который может получить доступ к каждой схеме, в качестве меры безопасности. Вы должны делать резервные копии, сбрасывая каждую схему с собственным пользователем или используя технику PITR PostgreSQL. Вам все равно нужно будет использовать пользователя postgres для создания новых схем, я бы выбрал правило sudo и сценарий для этого.
    • Многие передовые практики безопасности рекомендуют отказаться от схемы по умолчанию, так что поехали.
    • Это решение идеально подходит, если база данных для каждого клиента небольшая, а у вас множество клиентов.
    • Если ваше приложение поддерживает мультитенантность, оно может использовать единый пул соединений для всех клиентов. Конечно, это устраняет многие из вышеупомянутых улучшений безопасности, но может иметь преимущества в производительности, особенно когда у вас большое количество клиентов (если у вас есть около 500-1000 отдельных источников данных и вы используете пул соединений, это будет довольно сложно).
  2. Каждый заказчик получает собственный кластер базы данных. Это мое предпочтительное решение, особенно потому, что я обычно работаю с приложениями, у которых есть большие базы данных для каждого клиента.

    • Это дает очень хорошее разделение данных. Вы можете использовать отдельные тома хранилища для каждого клиента, выделить ограничения ЦП и памяти (с помощью докера?).
    • Действительно хорошая гибкость в отношении того, что нужно каждому клиенту в его конкретном случае. Они могут быть похожими или иметь отличительные черты.
    • Очень легко масштабируется в обоих направлениях (вверх и вниз).
    • Я также использую отдельные виртуальные IP-адреса, где каждый кластер прослушивает соединения, что позволяет масштабировать систему без необходимости перенастройки источника данных.
    • Резервные копии PITR создаются для каждого клиента, поэтому будет проще восстановить одного клиента по сравнению с мультиарендностью на основе схемы.
    • В сложных настройках каждому клиенту может потребоваться несколько баз данных, схем, пользователей и ролей и т. Д., Поэтому в таких случаях это лучшее решение.

Вы также можете использовать комбинацию вышеперечисленного и использовать pgBouncer в качестве маршрутизатора.