Меню

Postgresql настройка прав доступа

Настройка удаленного доступа к БД PostgreSQL

По умолчанию база данных устанавливается:

host all all 127.0.0.1/32 md5

добавить строку по аналогии с примером

host ama ama-user all md5

Небольшая расшифровка этой строки:

host используется подключение по TCP/IP

ama– Удалённый пользователь сможет подключаться к базе данных «ama», название базы можно заменить на своё, например «mydb». Помимо этого можно написать слово all, тогда для пользователя будет открыт доступ ко всем базам данных сервера

amauser– пользователь с псевдонимом «ama-user» сможет подключаться к базе данных «ama», если указать слово all, то база данных будет доступна любому пользователю

all— Используется в качестве адреса удалённого рабочего места, в данном случае доступ открывается для любой удалённой машины, для пользователя с псевдонимом указанном в предыдущем столбце. Если требуется указать конкретный адрес, то его можно написать вот в такой форме: 192.168.0.2/32, а для нескольких пользователей придётся указывать несколько строк подключения, указывать каждого в новой строке, пример будет приведён ниже

md5 – пароль пользователя хешируется алгоритмом MD5, если соответствует, то можно зайти

Пример предоставления доступа нескольким рабочим местам через пользователя «ama-user» к базе данных «ama»:

host ama ama-user 192.168.0.2/32 md5
host ama ama-user 192.168.0.3/32 md5
host ama ama-user 192.168.0.4/32 md5

Для более подробной информации по настройке конфига pg_hba.conf, пройдите по ссылке.

По умолчанию база данных устанавливается:

listen_addresses = ‘*’ # what IP address(es) to listen on;

Настройка брандмауэра Windows

Данный пункт необходим, если с СУБД PostgreSQL работает несколько пользователей одновременно. Так же, следует уточнить, что в этом пункте рассматривается базовый сценарий по открытию порта для подключения и может не подойти Вам по параметрами безопасности.

2. Выбрать пункт Дополнительные параметры ;

5. Выбрать пункт Разрешить подключение и затем нажать Далее

6. Выбрать все пункты и нажать Далее

7. Задать имя правила, например ama-pg и нажать Готово

8. Настройка порта завершена

После выполнения всех пунктов данной инструкции, к БД Postgres можно подключаться с удаленного компьютера

Источник

PostgreSQL права пользователя

Для начала работы вам понадобится собственно PostgreSQL сервер и доступ в его консоль. Если вы хотите просто поработать в режиме лаборатории, то можно воспользоваться free tier (бесплатной пробной версией) в одном из клаудов, например AWS, или быстро поднять PostgreSQL на лэптопе, используя docker:

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

Чтобы в PostgreSQL создать роль введите в консоль

CREATE ROLE test WITH LOGIN PASSWORD ‘test’;

Давайте посмотрим, какие еще атрибуты мы можем передавать команде CREATE ROLE

И так у нас есть роль «test», а это значит, что время создать базу и дать нашей роли право чтения или записи в эту базу. Как было отмечено выше, мы можем дать право самой роли создавать базы, или создать ее от имени суперпользователя. Выбор за вами, если вы указали при создании роли атрибут CREATEDB, то можете смело переподключаться, используя роль «test». Если нет, то тут два пути: продолжить от имени суперпользователя или дать роли право создания баз. Сделать это можно командой ALTER ROLE как показано ниже

ALTER ROLE test CREATEDB;

Проверим наш сетап. В PostgreSQL список ролей можно получить командой ‘\du’

postgres=# \du
List of roles
Role name | Attributes | Member of
————+————+————
test | Create DB | <>
.

Теперь можно перейти к созланию базы. Сделать можно сделующим образом

CREATE DATABASE test WITH ENCODING UTF8;

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

Опция Значение по-умолчанию Описание
NOSUPERUSER Название говорит само за себя, т.е. хотим ли мы сделать новую роль суперпользователем
CREATEDB
NOCREATEDB
NOCREATEDB Дает возможность ролям создавать базы
Опция Значение по-умолчанию Описание
(имя текущего пользователя) Позволяет переопределить владельца базы данных
template1 Позволяет переопределить шаблон для новой базы
-1 (не ограничено) Указывает сколько возможно одновременных подключений к базе данных

Начнем с OWNER. Мы тем самым плавно подошли к концепции владения. В PostgreSQL действует правило: тот, кто объект создает, будь-то база, схема, таблица или что-либо еще, получает неограниченные права на этот оъект. Т.е., если вы создавали базы от имени суперпользователя, то он будет владеть этой базой и всеми правами на нее, если от имени роли, то роль. И никакие другие непривелегированные роли к этим объектам доступ иметь не будут.

Начать пожалуй стоит с концепции наймспэйсинга

Этот рисунок говорит о том, что ваши таблицы, вьюзы и прочие элементы базы данных должны иметь уникальные имена только в пределах схемы. Схема в PostgreSQL это такой аналог нэймспэйсов. Т.е. как сервер баз данных может хранить некоторое колличетво собственно баз данных, так и каждая база данных внутри это сервера может содержать некоторое количество схем.

На заметку: PostgreSQL не предоставляет возможность работать со схемой одной базы будучи подключенным к другой. Для того, чтобы поработать со схемой другой базы необходимо переподключиться, указав нужое имя базы

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

Как решить эту проблему, если вас не устраивает такое положение дел? Что ж, решать-то надо на самом деле две проблемы. Во-первых, отнять у PUBLIC возможность поключаться к базе данных:

REVOKE ALL PRIVILEGES ON DATABASE test FROM PUBLIC;
GRANT CONNECT ON DATABASE test to test;

Данный сет комманд снимает все привилегии с PUBLIC относительно базы данных «test», а их мы напомним всего 4: CREATE, CONNECT, TEMPORARY и TEMP, и выдает роли «test» возможность только подключаться к базе данных

REVOKE ALL PRIVILEGES ON SCHEMA public FROM PUBLIC;

GRANT USAGE ON SCHEMA public TO PUBLIC

Давайте подытожим знания о правах по-умолчаю PUBLIC (заметьте, мы специально не называем это ролью) в таблице

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

Предположим, вы работаете в схеме public, то в командах PostgreSQL это будет выглядеть следующим образом

CREATE ROLE ro_user WITH LOGIN NOINHERIT PASSWORD ‘changeme’;
GRANT CONNECT ON DATABASE test TO ro_user;
GRANT USAGE ON SCHEMA public TO ro_user;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO ro_user;

И вот, казалось бы момент счастья, но PostgreSQL и здесь свинью подложил. Если после такой операции вы создали новую таблицу, то внимание, ваш ro_user не будет иметь к ней доступа! Решить проблему можно выполнив команды выше еще раз, или же поработать над такой штукой, как привилегии по-умолчанию. Соответственно, чтобы ro_user мог радостно читать данные даже из вновь созданных таблиц, вам следует выполнить

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ro_user;

Если структура базы чуть более сложная, чем обычно, возможно вам понадобится дать права также на последовательности и процедуры

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT USAGE,SELECT ON SEQUENCES TO ro_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT EXECUTE ON ROUTINES TO ro_user;

Источник

Настройка пользователей только для чтения в PostgreSQL

В этой инструкции показывается как настроить пользователей только для чтения в PostgreSQL для Redash.

Первое, что вы видите в нашей документации, — это совет по настройке источников данных для пользователей только для чтения. Мы рекомендуем это, потому что мы имели в виду Redash для визуализации данных. Он не построен на действиях INSERT, UPDATE или DELETE.

Поскольку Redash поддерживает более 40 источников данных и неограниченное количество API-интерфейсов на основе JSON, приложение не может напрямую запретить пользователям запускать запросы, отличные от SELECT. Благодаря этому вы можете обезопасить себя от того, что пользователи Redash смогут запускать вредоносных операторов DDL, настроив пользователей только для чтения на уровне базы данных.

PostgreSQL — один из наших самых популярных источников данных. В этой статье приводится пример настройки доступа только для чтения к любому источнику данных Postgres, включая Amazon Redshift и RDS.

Эта статья в значительной степени написана на основе отличного поста Amazon AWS в блоге О разрешениях Postgres.

Обзор

Перед началом я создал новую схему базы данных под названием myapp, принадлежащую пользователю с именем app-admin. Эта схема включает таблицы для Employees, Jobs и Customers, заполненные фиктивными данными. Я выполнил следующие шаги:

Помните, когда мы рассматриваем этот пример, Amazon рекомендует администраторам БД отозвать разрешения для всех схем у роли PUBLIC со следующим примечанием:

Отзыв разрешений у public роли влияет на всех существующих пользователей и ролей. Всем пользователям и ролям, которые должны иметь возможность подключаться к базе данных или создавать объекты в общедоступной схеме, должны быть явно предоставлены разрешения перед тем, как отозвать какие-либо разрешения от public роли в производственной среде.

Для простоты здесь я этого не делаю. В следующих шагах мы можем гарантировать, что роль myapp-readonly правильно ограничена. Но в вашей среде могут быть и другие роли с более изменчивыми разрешениями. Я рекомендую вам полностью проверить права доступа к вашей базе данных (независимо от того, используете ли вы Redash или нет ).

Шаг 1. Создайте роль только для чтения

Эти шаги взяты прямо из примера Amazon. Оператор GRANT USAGE важен, потому что без него другие разрешения не работают. Из документации PostgreSQL:

[USAGE] разрешает доступ к объектам, содержащимся в указанной схеме (при условии, что собственные требования к привилегиям объектов также выполняются). По сути, это позволяет получателю гранта «искать» объекты в схеме.

Шаг 2. Предоставьте разрешения новой роли

Второй оператор позволяет роли myapp_readonly просматривать только идентификаторы и имена клиентов. Все остальные поля в таблице скрыты. Сюда входят поля для номеров кредитных карт и контактной информации. Эти данные должны быть доступны только администраторам, а не пользователям Redash.

Это правило гарантирует, что мои пользователи Redash не увидят эти данные намеренно или нет. Если пользователь попытается сделать *SELECT FROM customers**, база данных вызовет ошибку разрешений. И в браузере схемы появятся только поля идентификатора и имени.

Шаг 3. Создайте пользователя Redash и назначьте ему роль только для чтения.

Пользователь redash — это то, что мы подключим к экрану настройки источника данных в Redash. Вы должны заменить secret надежным паролем.

Шаг 4. Подключитесь к Postgres с новым пользователем только для чтения

Подключить Redash просто. Просто укажите имя хоста, порт и исправление пользователя базы данных, которое я только что создал.

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

Возвращает данные, как ожидалось.

Вызывает ошибку разрешений из базы данных. Роль myapp_readonly не допускает INSERTS. И Redash в любом случае не предназначен для выполнения операторов INSERT!

Наконец, выбирая из таблицы customers:

Возвращает ошибку разрешений, поскольку роль только для чтения может обращаться только к определенным столбцам.

Возвращает полный список клиентов, поскольку мы запросили только те столбцы, к которым имеет доступ пользователь только для чтения.

Вывод

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

Источник

Читайте также:  Настройка антенны автомобильной радиостанции видео
Сервер баз данных Права подключения по-умолчанию нет. Каждой новой роли следует явно указать WITH LOGIN для выдачи разрешения на подключения к серверу баз данных
База данных Право на подключение к любой даже вновь созданной базе данных присутствует по-умолчанию. Требуется явный отзыв прав на подключение от PUBLIC для ограничения такой возможности
Схема PUBLIC Право читать и писать в схему PUBLIC присутствует по-умолчания. Требуется явный отзыв прав от PUBLIC для ограничения такой возможности
Элементы базы данных (таблицы, вьюзы. )