17.10. Безопасные TCP/IP соединения при помощи SSHTunnels

Возможно использовать SSH для шифрования сетевых соединений между клиентом и сервером PostgreSQL. Если это сделано правильно, что мы поучаем адекватный уровень сетевой безопасности даже для клиентов, не поддерживающих SSL.

17.9. Безопасные TCP/IP соединения посредством SSL

PostgreSQL поддерживает использование SSL соединений для шифрования общения клиент/сервер, обеспечивая более высокий уровень безопасности. Для этого требуется, чтобы OpenSSL был установлен как на клиенте, так и на сервере и чтобы поддержка SSL была включена в момент сборки PostgreSQL (см главу 15).

17.8. Опции шифрования

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

17.7. Предотвращение спуфинга сервера

Всё то время, что сервер запущен, никто не может занять его место в качестве сервера-злоумышленника БД. Однако, пока сервер выключен, локальный пользователь может занять его место, запустив свой сервер. Такой сервер может читать пароли пользователей и их запросы, но не может возвращать данные, так как каталог PGDATA недоступен ему из-за разрешений ФС. Спуфинг возможен, так как любой пользователь может запустить свой сервер БД; клиент не может отличить настоящий сервер от злоумышленника, если он не сконфигурирован должным образом.

Самый простой способ предотвратить спуфинг для локальных подключений - использовать каталог Unix domain socket (unix_socket_directory), который имеет права на запись только для доверенного локального пользователя. Это не позволит злоумышленнику создать свой собственный сокет в этой директории. Если Вы обеспокоены тем, что некоторые приложения могут всё ещё ссылаться на /tmp в поисках файла сокета и потому быть уязвимы для спуфинга, создайте при запуске ОС символическую ссылку /tmp/.s.PGSQL.5432, которая будет вести к файлу сокета в другом месте. Кроме того, возможно, Вам потребуется изменить скрипт отчистки /tmp, чтобы он не удалял эту ссылку.

Для того, чтобы предотвратить спуфинг через TCP соединения, лучше всего использовать SSL сертификаты и убедиться, что клиент проверяет сертификат сервера. Для этого сервер должен быть настроен на приём только hostssl соединений (раздел 19.1) и иметь SSL файлы server.key (ключ) и server.crt (сертификат) (раздел 17.9). TCP клиенты должны подключаться при помощи sslmode=verify-ca или verify-full и иметь установленные соответствующие корневые сертификаты (раздел 31.1)

17.6. Обновление PostgreSQL кластера

В этом разделе будет рассказано о том, как перевести вашу БД с одного PostgreSQL релиза на более новый.

17.5. Остановка сервера

Есть несколько способов выключить сервер БД. Вы можете определить способ остановки сервера, посылая разные сигналы главному процессу postgres.

SIGTERM

Это режим "умного выключения" (smart shutdown). После получения сигнала SIGTERM сервер запрещает создание новых подключений, но уже существующие работают нормально. Выключение происходит только после того, как разорваны все соединения. Если сервер находится в режиме online backup, то новые подключения всё ещё можно создать, но только для суперпользователя (это позволит суперпользователю подлкючиться и остановить процесс создания резервной копии). Если сервер находится в режиме восстановления, то восстановление и потоковая репликация останавливаются только после того, как завершаются все сессии

SIGINT

Это режим "быстрого выключения" (fast shutdown). Сервер запрещает создание новых подключений и посылает всем существующим процессам сервера сигнал SIGTERM, что завершает их работу. После того, как все процессы завершат свою работу, останавливается и главный процесс. Если сервер находится в режиме online backup, то оно тут же прерывается.

SIGQUIT

Это режим "немедленного выключения" (immediate shutdown). Главный процесс postgres посылает сигнал SIGQUIT всем дочерним процессам и завершается сам, не дожидаясь их завершения. Дочерние процессы так же завершаются сразу же по получении сигнала. Это приведёт к восстановлению (воспроизведению WAL логов) при следующем запуске. Рекомендуется только в крайних случаях.

Программа pg_ctl предоставляет удобный способ посылки сигналов для остановки сервера. Кроме того Вы можете послать сигнал напрямую при помощи команды kill, если Вы не используете Windows. PID процесса postgres может быть найден при помощи программы ps, или его можно узнать из файла postmaster.pid в директории с данными. Вот пример быстрого выключения:

$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`

Важно: Лучше не использовать SIGKILL для выключения сервера. Такой способ не позволяет серверу освободить память и семафоры, так что это должно будет сделано вручную перед запуском нового процесса сервера. Более того, SIGKILL убивает процесс postgres не позволяя переслать сигнал дочерним процессам, так что каждый из них придётся убивать вручную.

Для того, чтобы прервать индивидуальную сессию, оставив остальные рабочими, используйте pg_terminate_backend() (см таблицу 9-55) или пошлите SIGTERN дочернему процессу, связанному с этой сессией.

17.4. Управление ресурсами ядра

Большая установка PostgreSQL может быстро исчерпать ресурсы вашей системы (на некоторых системах объём доступных ресурсов так мал, что для этого даже не нужна "большая" установка). Если и Вы столкнулись с этой проблемой - читайте дальше.

17.3. Запуск сервера БД

Перед тем, как кто-нибудь сможет получить доступ к БД, Вы должны запустить сервер БД. Программа сервер называется postgres. Эта программа должна знать где найти необходимые ей для работы данные. Для этого используется опция -D. Так что самый простой способ запуска сервера:

17.2. Создание кластера БД

17.1. PostgreSQL аккаунты пользователей

Как и любой серверный демон, доступный снаружи, рекомендуется запускать PostgreSQL под отдельным пользователем. Этот аккаунт должен владеть только теми данными, которые управляются серверами и не должен использоваться другими демонами (поэтому, например, использовать пользователя nobody - плохая идея.) Не рекомендуется устанавливать исполняемые файлы под этим пользователем, так как на скомпрометированной системе они могут быть изменены.

Для того чтобы добавить пользователя на свою систему используйте команды useradd или adduser. Чаще всего используется имя postgres и его мы и будем использовать в этом руководстве. Но Вы можете использовать любое имя на свой вкус.