Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Политика безопасности восстановления бэкапов #583

Open
zelgo-dba opened this issue Jan 25, 2023 · 2 comments

Comments

@zelgo-dba
Copy link

Добрый день!
Мы тестируем поведение pg_probackup и на данном этапе используем удаленный режим с одним каталогом копий на хосте, где хранятся бэкапы и wal логи нескольких кластеров баз данных.
В описании pg_probackup указано, что "pg_probackup рассчитывает на то, что узлы будут взаимодействовать между собой с использованием SSH без пароля."
В связи с этим вопросы:

  1. возможно ли ограничить доступ до бэкапа, чтобы только конкретный хост мог восстановить конкретный бэкап?
  2. какие дополнительные меры можно предпринять от несанкционированного доступа к бэкапам на уровне pg_probackup?
@yosemity
Copy link

yosemity commented Jan 25, 2023

  1. Конкретный хост с ПГ, по сути ничего не восстанавливает, инициирует и бекап и восстановление сам сервер pg_probackup.
  2. pg_probackup не занимается безопасностью. Он работает через ssh + соединение к postgres и полностью на них полагается. Вы сами должны намутить фаерволлы, разные ssh-ключи, разных юзеров PG и разные конфиги pg_hba. А если речь вообще идёт про доступ к каталогу с бекапами, то я не знаю. Ну не давайте кому попало доступ по ssh, не выкладывайте на NFS и smb ))

@Burus
Copy link
Contributor

Burus commented Mar 24, 2023

@zelgo-dba

  1. Попробуйте схему с разграничениями директории/пользователь 1к1 к каждой СУБД.
  2. Мы проектируем замену SSH в удаленном режиме для более простой конфигурации политик безопасности бэкап/СУБД.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants