[Системное администрирование, PostgreSQL, Серверное администрирование, Администрирование баз данных] Настройка пользователей только для чтения в PostgreSQL (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
03-Дек-2020 13:34

Цитировать

В этой инструкции показывается как настроить пользователей только для чтения в 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, заполненные фиктивными данными. Я выполнил следующие шаги:

Создал новую роль с именем myapp-readonly.
Предоставил ей разрешение SELECT для таблиц Employees и Jobs. Предоставил ему привилегии SELECT в таблице customers, чтобы сохранить конфиденциальность клиентов.
Создал пользователя с именем redash и добавил его в роль myapp-readonly.
Добавил в Redash источник данных с новым именем пользователя и паролем redash.

Помните, когда мы рассматриваем этот пример, Amazon рекомендует администраторам БД отозвать разрешения для всех схем у роли PUBLIC со следующим примечанием:
Отзыв разрешений у public роли влияет на всех существующих пользователей и ролей. Всем пользователям и ролям, которые должны иметь возможность подключаться к базе данных или создавать объекты в общедоступной схеме, должны быть явно предоставлены разрешения перед тем, как отозвать какие-либо разрешения от public роли в производственной среде.
Для простоты здесь я этого не делаю. В следующих шагах мы можем гарантировать, что роль myapp-readonly правильно ограничена. Но в вашей среде могут быть и другие роли с более изменчивыми разрешениями. Я рекомендую вам полностью проверить права доступа к вашей базе данных (независимо от того, используете ли вы Redash или нет ).
Шаг 1. Создайте роль только для чтения

CREATE ROLE myapp_readonly;
GRANT CONNECT ON DATABASE defaultdb TO myapp_readonly;
GRANT USAGE ON SCHEMA myapp TO myapp_readonly;

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

GRANT SELECT ON TABLE "myapp"."employees" TO myapp_readonly;
GRANT SELECT ON TABLE "myapp"."jobs" TO myapp_readonly;
GRANT SELECT (id, name) ON TABLE myapp.customers TO myapp_readonly;

Первый оператор дает полное разрешение на чтение таблиц employee и jobs .
Второй оператор позволяет роли myapp_readonly просматривать только идентификаторы и имена клиентов. Все остальные поля в таблице скрыты. Сюда входят поля для номеров кредитных карт и контактной информации. Эти данные должны быть доступны только администраторам, а не пользователям Redash.
Это правило гарантирует, что мои пользователи Redash не увидят эти данные намеренно или нет. Если пользователь попытается сделать *SELECT FROM customers**, база данных вызовет ошибку разрешений. И в браузере схемы появятся только поля идентификатора и имени.
Шаг 3. Создайте пользователя Redash и назначьте ему роль только для чтения.

CREATE USER redash WITH PASSWORD 'secret';
GRANT myapp_readonly TO redash;

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

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

SELECT * FROM myapp.employees

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

INSERT INTO myapp.employees (name) VALUES ('Hal')

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

SELECT * FROM myapp.customers;

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

SELECT id, name FROM myapp.customers;

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

Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_postgresql, #_servernoe_administrirovanie (Серверное администрирование), #_administrirovanie_baz_dannyh (Администрирование баз данных), #_postgresql, #_sistemnoe_administrirovanie (
Системное администрирование
), #_postgresql, #_servernoe_administrirovanie (
Серверное администрирование
), #_administrirovanie_baz_dannyh (
Администрирование баз данных
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 12:36
Часовой пояс: UTC + 5