powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Проверка PostgreSQL с помощью RedCheck
2 сообщений из 2, страница 1 из 1
Проверка PostgreSQL с помощью RedCheck
    #39560796
Malatus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день!
Кто-нибудь проверял PostgreSQL с помощью RedCheck?

Кто-нибудь может пояснить следующие моменты:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
Отменить схему "public" по умолчанию для всех пользователей (роль PUBLIC)
Описание
По умолчанию PostgreSQL использует public схему для хранения информации о базах данных, таблицах, процедурах. Эта
схема по умолчанию доступна всем пользователям, поэтому все пользователи могут видеть все структуры и процедуры
таблиц.
Исправление
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
(Первое упоминание "public" - это схема, второе "PUBLIC" значит "каждый пользователь". В первом случае - это
идентификатор, во втором - ключевое слово, отсюда и разное написание)


Если отменить схему public на работающем сервере это же может повлять на существующие БД?

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Роль PUBLIC не должна иметь привилегий на объекты
Описание
Рекомендуемое действие: Роль PUBLIC не должна иметь привилегий на объекты
Ключевое слово PUBLIC означает, что права даются всем ролям, включая те, что могут быть созданы позже. PUBLIC
можно воспринимать как неявно определённую группу, в которую входят все роли. Любая конкретная роль получит в
сумме все права, данные непосредственно ей и ролям, членом которых она является, а также права, данные роли
PUBLIC.
Postgres по умолчанию назначает группе PUBLIC определённые права для некоторых типов объектов. Для таблиц,
столбцов, схем и табличных пространств PUBLIC по умолчанию никаких прав не имеет. Для других типов объектов
PUBLIC имеет следующие права: CONNECT и CREATE TEMP TABLE — для баз данных; EXECUTE — для функций;
USAGE — для языков. Владелец объекта, конечно же, может отозвать (с помощью REVOKE) как явно назначенные права,
так и права, назначаемые по умолчанию. (Для максимальной безопасности команду REVOKE нужно выполнять в
транзакции, создающей объект; тогда не образуется окно, в котором другой пользователь смог бы обратиться к объекту.)
Кроме того, эти изначально назначаемые права по умолчанию можно изменить, воспользовавшись командой ALTER
DEFAULT PRIVILEGES.
Исправление
REVOKE EXECUTE ON ALL FUNCTIONS FROM PUBLIC;


Если изменить назначаемые права по умолчанию на работающем сервере это же может повлять на существующие БД?


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Параметр ssl = on
Описание
Рекомендуемое действие: ssl = on
Разрешает SSL-подключения. Прежде чем включать SSL. По умолчанию он выключен (off). Этот параметр можно задать
только при запуске сервера. SSL-подключения поддерживаются только для соединений по TCP/IP.
В Postgres встроена поддержка SSL для шифрования трафика между клиентом и сервером, что повышает уровень
безопасности системы. Для использования этой возможности необходимо, чтобы и на сервере, и на клиенте был
установлен OpenSSL, и поддержка SSL была разрешена в Postgres при сборке.
Когда в установленном сервере Postgres разрешена поддержка SSL, его можно запустить с включённым механизмом SSL,
задав в postgresql.conf для параметра ssl значение on. Запущенный сервер будет принимать, как обычные, так и SSL-
подключения в одном порту TCP и будет согласовывать использование SSL с каждым клиентом. По умолчанию клиент
выбирает режим подключения сам; как настроить сервер, чтобы он требовал использовать только SSL для всех или
некоторых подключений.
Postgres читает системный файл конфигурации OpenSSL. По умолчанию этот файл называется openssl.cnf и находится в
каталоге, который сообщает команда openssl version -d. Если требуется указать другое расположение файла
конфигурации, его можно задать в переменной окружения OPENSSL_CONF.
OpenSSL предоставляет широкий выбор шифров и алгоритмов аутентификации разной защищённости. Хотя список
шифров может быть задан непосредственно в файле конфигурации OpenSSL, можно задать отдельные шифры именно
для сервера баз данных, указав их в параметре ssl_ciphers в postgresql.conf.


Если применить параметр ssl = on нужно ли переконфирурировать конфигурацию клиентов. Верно?

Код: sql
1.
2.
3.
4.
5.
Ограничить использование роли SUPERUSER
Описание
Статус суперпользователя несёт опасность и назначать его следует только в случае необходимости.
Исправление
ALTER ROLE {role_name} WITH NOSUPERUSER;


Не написано для какой роли это. Если для postgres, то как админить то, создавать БД?

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Использовать метод аутентификации по сертификату
Описание
Для аутентификации в рамках этого метода используется клиентский сертификат SSL, поэтому данный способ применим
только для SSL-подключений. Когда используется этот метод, сервер потребует от клиента предъявления
действительного и доверенного сертификата.
Параметр аутентификации clientcert можно использовать с любым методом проверки подлинности, но только в строках
pg_hba.conf типа hostssl. Когда clientcert не задан или равен 0, сервер, тем не менее, будет проверять все
представленные клиентские сертификаты по своему файлу со списком ЦС (если он настроен) — но позволит
подключаться клиентам без сертификата. При clientcert=1 от клиента в процессе установления SSL-подключения будет
затребован сертификат.
Исправление
Добавить параметр аутентификации clientcert=1 в соответствующие строки hostssl в pg_hba.conf.


Получается, что нужно на сервере приложений создать сертификат и указать его на сервере PostgreSQL?
...
Рейтинг: 0 / 0
Проверка PostgreSQL с помощью RedCheck
    #39560845
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Malatus,

Как-то так:
- если забрать права, на создание таблиц, то никто больше не сможет создавать таблицы. В работающей базе делать можно, но обдуманно, после тестов и под присмотром как за базой, так и за приложением(-ами)
- повлияет, если есть функции в свободном доступе
- не нужно. но если вы хотите, чтобы клиенты ходили через SSL — нужно запретить открытые соединения на стороне базы
- смысл в том, чтобы забрать SUPERUSER у всех-кому-ни-лень. у postgres'а тоже можно забрать, если делать это обдуманно в рамках специфической модели контроля доступа. но это будет крайне неудобно
- почитайте про сертификаты информации полно. а то писать много…
...
Рейтинг: 0 / 0
2 сообщений из 2, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Проверка PostgreSQL с помощью RedCheck
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]