Реалізація найкращих практик постгресів


21

Люди,

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

Є один сервер з одним встановленням Postgres v9.2. Ця установка розміщує декілька баз даних, кожна з яких повністю обслуговує іншого "замовника". Іншими словами, customer1 не буде, не повинен використовувати базу даних2 тощо. Під час звичайних операцій, до баз даних ви можете скористатися відповідним екземпляром CakePHP, всі розташовані на тому ж сервері, що і Postgres. Хоча для цього розгортання можливі оптимізації, мене найбільше цікавлять ролі Psql.

Виходячи з того, що я прочитав, здається, три типи ролей мали б сенс:

  • Суперусерські постгреси з паролем, що не використовується за замовчуванням
  • Роль адміністратора, що не має привілеїв суперпользователя для рутинного обслуговування, створення БД, резервного копіювання, відновлення. Потрібно вміти робити що-небудь із усіма базами даних клієнтів.
  • Ролі користувачів з просто можливістю CRUD у відповідній базі даних. Більше прав на власну БД можна допустити, якщо вона очистить реалізацію.

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

     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
На мій досвід, найкращим розділенням, яке також приносить величезну кількість інших переваг, є запуск окремих кластерів PostGreSQL (наприклад, послуги) для кожного клієнта. Це те, що ми зараз робимо для великого виробничого середовища, і я би не робив цього інакше, якщо б кількість БД не стала дійсно великою і кожна з них була б дійсно невеликою. Звичайно, додаток також повинен знати, як підключитися до іншого джерела даних для кожного орендаря (замовника).
Флорін Асевойе

Крім @ FlorinAsăvoaie його зауваження. Чи не повинна кожна база даних мати власного власника та запитувати користувача? Це полегшить розміщення певних користувачів у сховищі паролів для обслуговування.
hspaans

Відповіді:


5

Я знаю, що це давнє питання, але я спробую відповісти на нього навіть зараз, оскільки мені довелося провести деякі дослідження, пов’язані з цим.

Те, що ви намагаєтеся зробити, називається багатоквартирною орендою на рівні бази даних. Цього можна досягти двома способами:

  1. В одному кластері баз даних, дещо як описано ОП, однак, мій особистий вибір був би таким:

    • користувач postgres використовує аутентифікацію одноранців і не допускається з'єднання паролем. Аутентифікація MD5, на мою думку, є поганою практикою. Якщо у вас виникнуть проблеми з узгодженістю баз даних або подібними речами, ви все одно зможете увійти в систему, якщо дозволите postgres використовувати peer auth.
    • Кожен клієнт повинен отримати власну схему, а не базу даних. Для цього є кілька причин:
      • Володіння цілою базою даних дозволило б отримати багато привілеїв.
      • Володіння лише конкретними таблицями створюватиме проблеми для розробників і завжди вимагатиме від адміністраторів додати дозволи та ін.
      • Таким чином, у звичайних умовах кожен із них отримає доступ для створення речей всередині своєї схеми, включаючи таблиці, представлення, тригери тощо.
      • Усі вони використовують один і той же рядок з'єднання, крім імені користувача. У postgres за замовчуванням, якщо у вас є схема з іменем вашого користувача, вона автоматично знаходиться у вашому search_path.
    • Я б вирішив не мати адміністратора, який може отримати доступ до кожної схеми, як захід безпеки. Ви повинні робити резервні копії, завантажуючи кожну схему з власним користувачем або використовуючи техніку PITR PostgreSQL. Вам все-таки потрібно використовувати користувач postgres для створення нових схем, я б пішов на правило sudo і сценарій для цього.
    • Багато належних практик безпеки рекомендують скинути схему за замовчуванням так - ось ми підемо.
    • Це рішення надзвичайно підходить, якщо БД для кожного клієнта невелика і у вас є багато клієнтів.
    • Якщо у вашій програмі працює багатожитлова система, вона може використовувати єдиний пул підключення для всіх клієнтів. Звичайно, це виключає багато з вищезазначених покращень безпеки, але може мати переваги щодо продуктивності, особливо якщо у вас є велика кількість клієнтів (якщо вам подобається 500-1000 окремих джерел даних і ви використовуєте об'єднання з'єднань, це буде досить непосильним).
  2. Кожен клієнт отримує власний кластер бази даних. Це моє вподобане рішення, особливо тому, що я зазвичай працюю з додатками, які мають великі бази даних для кожного клієнта.

    • Цей приносить дуже хороший поділ даних. Ви можете використовувати окремі обсяги пам’яті для кожного клієнта, розподіляти обмеження процесора та пам’яті (використовуючи докер?).
    • Дійсно хороша гнучкість у тому, що потребує кожен клієнт у своєму випадку. Вони можуть бути або схожими, або мати виразні риси.
    • Дуже легко масштабувати в обох напрямках (вгору і назовні).
    • Я також використовую окремі віртуальні IP-адреси, де кожен кластер прослуховує з'єднання, роблячи масштаб, щоб не потребувати перенастроювання джерел даних.
    • Резервні копії PITR розраховані на кожного клієнта, тому буде легше відновити одного клієнта порівняно з багатосторонньою схемою оренди.
    • У складних налаштуваннях кожному клієнту може знадобитися декілька баз даних, схем, користувачів та ролей тощо. Отже, це є кращим рішенням у цих випадках.

Ви також можете використовувати комбінацію перерахованих вище та використовувати pgBouncer як маршрутизатор.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.