Fórum Root.cz
Hlavní témata => Server => Téma založeno: scientific 18. 02. 2019, 20:22:13
-
Ahoj, mám rychlý velmi základní amatérský dotaz a prosím si o radu.
Jaký prosím navrhujete postup, abych mohl defaultním uživatelem postgresql "postgres" vrtat v adresáři /srv? Myšleno např. vytvářet tam adresáře a nahrávat tam dumpy PostgreSQL databází?
Napadají mě samé nesmysly, jak bych to jakožto amatér řešil:
- Nastavil CHMOD na 777
- Nastavil chown na něco jako postgres:root a změnil vlastníka z roota na postgres, což by možná systém ani nepřekousnul
- Nějakým způsobem přidal uživatele postgres do sudoers file, což se asi dělá nějak pomocí příkazu "usermod -a sudo", jen hádám.
- Přidal uživatele postgres do skupiny "root"
- Možná do scriptu na začátek přidat něco jako export $PATH=$PATH:/srv/
Nejsem si jist, zda se hodí uživatele PostgreSQL databáze "postgres" (jestli to náhodou není potenciálně nebezpečné) přidávat do sudoers, ale vím, že u běžných uživatelů se to řeší nějak takhle sudo mkdir /srv/bla/bla/bla/.
Co mi prosím doporučíte? Děkuji moc za radu, jak se to správně řeší.
Jsem si vědom, že můj dotaz patří do naprostých základů jakýchkoliv systémů. Nicméně u sebe ve Windows jsem nikdy neměl potřebu se v oprávněních vrtat a na serveru jsem vždy používal roota. Momentálně ale roota vyloženě používat nechci (údajně to může vést k narušení bezpečnosti systému, pokud budu aplikace spouštět uživatelem s právy posvátné krávy).
-
Úplně nejbezpečněji:
1. založit nového neprivilegovaného uživatele (např. pgmaint)
2. chown pgmaint:wheel /srv (evt. pgmaint:pgmaint)
3. chmod 0750 /srv
4. su - postgres -c "createuser -s -P pgmaint"
(nebo můžete rovnou založit uživatele pgmaint s home /srv, ale pak musíte stejně pohlídat ty práva).
V tu chvíli bude mít k adresáři přístup uživatel pgmaint, a pro postgres bude superuser (takže dokáže jakoukoliv operaci s postgresem, včetně pg_dump).
Bylo by lepší, kdyby nemusel být superuserem, ale to z Vašeho dotazu není poznat.
Neumím taky posoudit, jak máte nastavený pg_hba.conf.
-
Použít ACL a přidat uživateli postgres právo zápisu do /srv – příkaz setfacl.
-
Použít ACL a přidat uživateli postgres právo zápisu do /srv – příkaz setfacl.
To nepovažuji za dobrý nápad. Není žádný důvod, aby pg_dump volal přímo uživatel postgres. Uživatel postgres je vlastník procesu serveru a chybný krok může shodit server. Klidně práva nastavit přes ACL (i když to také nepovažuji za šťastné, protože to není univerzální postup pro různé OS a pro různé filesystémy), ale určitě užit jiného uživatele.
-
vola sa to extended access lists..
setfacl a getfacl...
-
Použít ACL a přidat uživateli postgres právo zápisu do /srv – příkaz setfacl.
To nepovažuji za dobrý nápad. Není žádný důvod, aby pg_dump volal přímo uživatel postgres. Uživatel postgres je vlastník procesu serveru a chybný krok může shodit server. Klidně práva nastavit přes ACL (i když to také nepovažuji za šťastné, protože to není univerzální postup pro různé OS a pro různé filesystémy), ale určitě užit jiného uživatele.
S tim zase nesouhlasim ja. Jakkykoli jiny uzivatel nemusi mit prava do vsech objektu v DB. Takze rozhodne at to dumpuje postgres.
Co se tyce /srv, tak doporucuji udelat tam podadresar a na nem nastavit prava pro postgres. Proc? Protoze to umoznuje mit manevrovaci prostor pro dalsi veci v /srv.
-
Použít ACL a přidat uživateli postgres právo zápisu do /srv – příkaz setfacl.
To nepovažuji za dobrý nápad. Není žádný důvod, aby pg_dump volal přímo uživatel postgres. Uživatel postgres je vlastník procesu serveru a chybný krok může shodit server. Klidně práva nastavit přes ACL (i když to také nepovažuji za šťastné, protože to není univerzální postup pro různé OS a pro různé filesystémy), ale určitě užit jiného uživatele.
S tim zase nesouhlasim ja. Jakkykoli jiny uzivatel nemusi mit prava do vsech objektu v DB. Takze rozhodne at to dumpuje postgres.
Co se tyce /srv, tak doporucuji udelat tam podadresar a na nem nastavit prava pro postgres. Proc? Protoze to umoznuje mit manevrovaci prostor pro dalsi veci v /srv.
Postgres = vlastník procesu, i právo dump
Pgmaint = pouze právo dump
Obyč user = právo ostatních prací (klidně přes ACL), např. práci s dumpy.
Co mi na tom vadí je zneužívat proces serveru k pracem, to se prostě nemá dělat.
-
Pgmaint = pouze právo dump
Jenže scientific tam nechce ty databáze dumpovat (což by ostatně bylo rozumné dělat do jiného adresáře než /srv), ale chce je naopak obnovovat.
Co mi na tom vadí je zneužívat proces serveru k pracem, to se prostě nemá dělat.
Jenže to, že postgres je uživatel pouze pro proces serveru, jste si vymyslel vy – samotnými autory PostgreSQL tak chápán není. Já s vámi souhlasím, že principiálně čisté řešení je takové, kdy server běží pod uživatelským účtem, který se k ničemu jinému nepoužívá. Ovšem neradil bych to, že má prokopávat tuto perfektně čistou cestu, někomu, kdo se potřebuje na takovéhle věci ptát na diskusním fóru. V tomto případě bych upřednostnil řešení, které sice není principiálně úplně čisté, ale je standardní.
-
Ano, chci vytvářet dumpy. /srv/path/to/zalohovani/ je nezbytné.
Chápu správně, že tedy nejlepší až moc přehnaně dokonalé řešení navrhuje @Miroslav Šilhavý , zatímco uživatel @Filip Jirsák doporučuje standardní řešení, které je z hlediska bezpečnosti v pořádku a zcela běžné. A klidně můžu zálohovací skript spouštět uživatelem postgres a mohu ho nastavit vlastníkem /srv/path/to/zalohovani/ .
Chápu vás správně?
-
Chápu správně, že tedy nejlepší až moc přehnaně dokonalé řešení navrhuje @Miroslav Šilhavý , zatímco uživatel @Filip Jirsák doporučuje standardní řešení, které je z hlediska bezpečnosti v pořádku a zcela běžné.
Běžné určitě není, protože ACL je něco, co nemusíte mít k dispozici, co není zajištěno, že bude za všech okolností a na všech systémech a na všech filesystémech fungovat. Stačí chybně provedené kopírování nebo přesunutí dat a máte po ACL.
Moje řešení je dalek jednodušší na správu - jednou nastavíte a můžete na to zapomenout. Kdyby došlo k nějaké chybě, výsledkem bude odepření přístupu (nikdo se k datům nedostane).
Filipovo řešení má problém v tom, že může nastat několik situací, kdy selže, a výsledkem nebude odepření přístupu, ale naopak to, že se k datům dostane i někdo cizí. Výsledkem také může být to, že se někomu podaří Vám podstrčit script nebo data, které spustíte pod uživatelem postgres a tím shodíte celý databázový server.
Založit uživatele, založit roli v postgresu = odhadem dvě minuty práce? Toto je celé, co potřebujete udělat:
adduser --disabled-password pgmaint
chown pgmaint:pgmaint /srv
chmod 0750 /srv
su - posgres -c "createuser -s -P pgmaint"
echo "localhost:*:*:pgmaint:<heslo>" > ~pgmaint/.pgpass
chown pgmaint:pgmaint ~pgmaint/.pgpass
chmod 0600 ~pgmaint/.pgpass
Uživatel pgmaint pak bude moci zakládat v postgresu role, zakládat databáze, rušit je, dělat dumpy, natahovat dumpy. Ale neohrozí samotný proces posgresu, neohrozí datové soubory postgresu.
-
Ano, chci vytvářet dumpy. /srv/path/to/zalohovani/ je nezbytné.
Chápu správně, že tedy nejlepší až moc přehnaně dokonalé řešení navrhuje @Miroslav Šilhavý , zatímco uživatel @Filip Jirsák doporučuje standardní řešení, které je z hlediska bezpečnosti v pořádku a zcela běžné. A klidně můžu zálohovací skript spouštět uživatelem postgres a mohu ho nastavit vlastníkem /srv/path/to/zalohovani/ .
Chápu vás správně?
To bezpečné/standardní se vztahuje k tomu, jestli použít uživatele postgres nebo jiného uživatele. To, zda použijete řešení přes skupinu nebo ACL s tím nesouvisí – obojí můžete udělat jak s uživatelem postgres tak s jiným uživatelem.
-
Reseni popsane Silhavym mi funguje uz mnoho let na ruznych serverech a nevidim v tom zadny problem
Casto ani nevytvarim specialniho uzivatele, pokud je server dedikovany jen pro DB a nikdo jiny na nej nema pristup
Nekdy ta jednoducha reseni jsou dostatecna
-
To bezpečné/standardní se vztahuje k tomu, jestli použít uživatele postgres nebo jiného uživatele. To, zda použijete řešení přes skupinu nebo ACL s tím nesouvisí – obojí můžete udělat jak s uživatelem postgres tak s jiným uživatelem.
Ještě jsem chtěl doplnit, že to řešení Miroslava Šilhavého bych nenazýval přehnaně dokonalým – používat dedikované uživatele pro jednu konkrétní činnost je dobré řešení a často je to relativně snadné, jako v tomto případě. Abych to nazýval „přehnané“, musela by tam být ještě spousta dalších opatření. Jenom jsem upozorňoval na to, že to použití jiného uživatele jde nad rámec toho, s čím počítá např. oficiální dokumentace PostgreSQL, protože tam se počítá s jedním uživatelem postgres, který slouží jak k běhu serveru, tak pro jeho správu. Takže pokud použijete uživatele dva (nebo více), musíte na to myslet i v budoucnosti a používat toho správného uživatele pro konkrétní činnosti.
-
Běžné určitě není, protože ACL je něco, co nemusíte mít k dispozici, co není zajištěno, že bude za všech okolností a na všech systémech a na všech filesystémech fungovat. Stačí chybně provedené kopírování nebo přesunutí dat a máte po ACL.
Pokud se bavíme o Linuxu, tam, už je ACL standardem hezkých pár let. A v tomto případě se ACL nastavuje na jeden jediný adresář /srv, takže nějaké kopírování nebo přesouvání tohoto adresáře bude mít stejný problém i s řešením přes skupinu – pokud ten adresář vytvoříte znova, budete muset znova ta práva nastavit.
Mimochodem ta ACL se do Linuxu zavedla právě proto, aby se obešlo omezení na jednoho vlastníka a jednu skupinu. Pokud potřebujete přidat oprávnění jednomu dalšímu uživateli, dá se to přes skupinu obejít. Pokud by těch uživatelů bylo víc a některým potřebujete povolit zápis a jiným jenom čtení, s klasickými oprávněními pro uživatele, skupinu a ostatní jste v koncích.
Filipovo řešení má problém v tom, že může nastat několik situací, kdy selže, a výsledkem nebude odepření přístupu, ale naopak to, že se k datům dostane i někdo cizí. Výsledkem také může být to, že se někomu podaří Vám podstrčit script nebo data, které spustíte pod uživatelem postgres a tím shodíte celý databázový server.
Nikoli, ACL přidávají oprávnění dalším uživatelům na úrovni jádra operačního systému. Pokud byste ten disk vyndal a přimontoval do 15 let starého systému, kde nebude podpora ACL, neznamená to, že by k datům dostal přístup někdo další – ACL tam nebudou, tím pádem nebudou mít k datům přístup ti uživatelé, kteří jej měli pomocí ACL a přístup zůstane omezeným pouze na ty uživatele, kteří jsou přímo vlastníky nebo ve skupině. Okruh uživatelů by se tedy zúžil.
-
https://wiki.postgresql.org/wiki/Automated_Backup_on_Linux pro inspiraci
-
Jenom jsem upozorňoval na to, že to použití jiného uživatele jde nad rámec toho, s čím počítá např. oficiální dokumentace PostgreSQL, protože tam se počítá s jedním uživatelem postgres, který slouží jak k běhu serveru, tak pro jeho správu. Takže pokud použijete uživatele dva (nebo více), musíte na to myslet i v budoucnosti a používat toho správného uživatele pro konkrétní činnosti.
Toto bych ale považoval za samozřejmost správy. Na systému nepracujete stále s uživatelem root, ale povyšujete práva podle potřeby. Na postgresu nepracujete s uživatelem postgres, ale taky jen povyšujete práva jiného uživatele. To je základní koncept bezpečnosti, o kterém se nemusí psát. (Podobně není v dokumentaci napsáno, že nemáte zakládat uživatele s právy superusera zbytečně, nebo že si nemáte psát hesla na papírek na monitoru.)
Před užíváním uživatele posgtgres na binárky (tj. rozšířeně i na scripty) se v dokumentaci varuje - právě kvůli přepisu jich samých (a potažmo i dat, samozřejmě): https://www.postgresql.org/docs/11/postgres-user.html.
Zde https://www.postgresql.org/docs/11/backup-dump.html se popisuje zálohování, s tím, že jsou potřeba práva superusera. O tom, že by se tato operace měla dělat uživatelem postgres (vlastníkem procesu), zde není ani zmínka, byť by to bylo to nejjednodušší, co by mohli doporučit.
-
Na postgresu nepracujete s uživatelem postgres, ale taky jen povyšujete práva jiného uživatele.
Mícháte dohromady systémové uživatele a databázové uživatele. PostgreSQL umožňuje systémové uživatele použít pro zjednodušené přihlášení ke stejnojmennému databázovému uživateli, ale zejména pro začátečníky je potřeba v tom důsledně rozlišovat.
Zálohovat data z PostgreSQL pomocí dumpu je možné i po síti, můžete třeba databázový server běžící na Linuxu zálohovat z Windows, takže z hlediska přístupových práv k databázi je podstatné jenom to, pod jakým uživatelem se při zálohování hlásíte do databáze – lokální systémový uživatel je pro databázový server nezajímavý.
To je základní koncept bezpečnosti, o kterém se nemusí psát. (Podobně není v dokumentaci napsáno, že nemáte zakládat uživatele s právy superusera zbytečně, nebo že si nemáte psát hesla na papírek na monitoru.)
Vy se na to ovšem díváte z opačné strany. Systémový uživatel postgres je jediný způsob, jak se (na Linuxu) do čerstvě nainstalované databáze můžete přihlásit. Nebo-li systémový účet postgres je ten účet, který je určený pro administraci databáze. Můžete použít mapování systémových uživatelů na databázové uživatele, ale opět je to nestandardní konfigurace. Běžné distribuce ale tenhle účet postgres „zneužívají“ i k tomu, že pod ním spouští databázový server.
Já s vámi souhlasím, že principiálně správně je mít dva účty – jeden pro správu databáze a druhý, pod kterým poběží databázový server. A ideálně ještě další, třeba samostatný účet pro zálohování. Běžné linuxové distribuce to ale pokud vím nerozlišují a pro vše používají účet postgres. Podobné to je s různými návody na internetu. Takže pokud někdo ty účty (z hlediska bezpečnosti správně) rozdělí, musí si např. při čtení různých návodů správně převést, o kterém z účtů je v kterém případě řeč.
-
Vy se na to ovšem díváte z opačné strany. Systémový uživatel postgres je jediný způsob, jak se (na Linuxu) do čerstvě nainstalované databáze můžete přihlásit. Nebo-li systémový účet postgres je ten účet, který je určený pro administraci databáze. Můžete použít mapování systémových uživatelů na databázové uživatele, ale opět je to nestandardní konfigurace. Běžné distribuce ale tenhle účet postgres „zneužívají“ i k tomu, že pod ním spouští databázový server.
Ono je to ale přesně naopak. Základem bezpečnosti je, že musíte mít dedikovaný účet pro běh serveru. Tím bývá uživatel posgres, někdy třeba psql. Vůbec ale neplatí, že by "role" postgres musela existovat a být superuserem.
https://www.postgresql.org/docs/11/app-initdb.html - viz parametr --username=:
-U username
--username=usernameSelects the user name of the database superuser. This defaults to the name of the effective user running initdb. It is really not important what the superuser's name is, but one might choose to keep the customary name postgres, even if the operating system user's name is different.
Poté je běžné provést su - postgres -c "createuser -s -P jmeno_spravce"
Podle situace se pak v pg_hba.conf (https://www.postgresql.org/docs/11/auth-pg-hba-conf.html) nastaví mechanismus autentikace. Je možné zvolit peer, kdy lokální uživatel téhož usernamu nebude tázán na heslo. Já raději (právě i kvůli tomu, že často se využívá externí připojení) doporučuji i na lokální připojení využívat scram-sha-256 (případně md5 kvůli kompatibilitě se staršími klienty) a heslo ukládat v .pgpass. Je to lepší návyk, předejde se tím možnostem oponinutí bezpečnosti.
Já s vámi souhlasím, že principiálně správně je mít dva účty – jeden pro správu databáze a druhý, pod kterým poběží databázový server. A ideálně ještě další, třeba samostatný účet pro zálohování. Běžné linuxové distribuce to ale pokud vím nerozlišují a pro vše používají účet postgres.
Dívám se na Debian, dívám se na FreeBSD, ale nevidím tam, že by distribuce dělala cokoliv. V minulosti (v době dřevěné, pre-autovacuum) se volala údržba databáze (a debian měl heslo uložené v souboru). Dnes už tam není žádný task:
root:~# crontab -u postgres -l
no crontab for postgres
root:~# find /etc/cron* -type f -exec grep "postgres" {} \;
root:~#
-
Fíha, vy jste se ale rozdebatovali. nečekal sem, že se tu strhne taková debata, děkuji Vám z toho jak mezi sebou debatujete, trochu začínám chápat další souvislosti.
Automatické zálohování mám již hotové, funguje tak, že adresář s cílem záloh je vlastníka postgres, který spouští skript pro vytváření záloh. Ten automatický skript jsem viděl, ale přijde mi moc složitý a namísto toho, abych se snažil takový skript pochopit, sem si napsal svůj.
Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?
-
Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?
Vůbec ne. Pgmaint bude superuser databáze - bude mít k databázím stejný přístup, jako uživatel postgres.
(Od toho je parametr "-s" ve volání createuser).
Rozdíl mezi uživatelem postgres a pgmaint bude "jen" v tom, že pgmaint nebude mít oprávnění upravovat konfiguraci postgresu, nebude mít možnost poškodit datové soubory posgresu, nebude moci shodit proces postgresu.
-
Vůbec ale neplatí, že by "role" postgres musela existovat a být superuserem.
Polemizujete s něčím, co jsem nenapsal. Psal jsem o běžných distribucích. Vy jste uváděl Debian, tam se volá
/usr/bin/pg_createcluster -u postgres $VERSION main
A server samozřejmě také běží pod uživatelem postgres. Ostatně i vy ve svém příkladu jste jako systémového uživatele – správce databáze uvedl účet postgres.
Když bych vytvořil pgmaint, mohl bych zálohovat jen ty databáze, kterých je owner pgmaint ne? Tím pádem přístup k databázím vytvořeným jiným uživatelem by neměl přístup ne? Nebo by pgmaint převzal všechno co umí i postgres výjimkou samotného běhu postgresql procesu?
Mícháte dohromady systémové uživatele (uživatele v operačním systému zapsané v /etc/passwd) a databázové uživatele (přesně to, před čím jsem varoval).
Klidně můžete pod systémovým uživatelem pg_backup spustit zálohování, které s ek serveru připojí databázovým uživatelem backup_database_1. Je to parametr -U/--username programu pg_dump.
Použít jiný systémový účet pro zálohování (jiný než účet, pod kterým běží server), je vhodné z hlediska bezpečnosti databázového serveru. Kdybyste pro zálohování použil stejný účet, jako ten, pod kterým běží databázový server, může zálohovací skript omylem např. zabít proces databázového serveru, přepsat konfiguraci nebo data, nebo třeba zaplnit disk (aniž by se mohly uplatnit kvóty, které by mohly diskový prostor pro databázi ochránit).
Něco jiného je zase databázový uživatel – ten rozhoduje o tom, k jakým databázovým objektům bude mít zálohovací skript přístup. Zde je zase z hlediska bezpečnosti nevhodný postup, pokud zálohování spouštíte pod uživatelem, který má v databázi práva superuživatele – je to jako kdybyste v systému spouštěl zálohovací skript s právy roota. Je to jednoduché – nemusíte nastavovat oprávnění, ale zároveň máte mnohem silnější oprávnění, než k zálohování potřebujete. Pro zálohování není potřeba umět žádné objekty v databázi zapisovat, mazat nebo je spouštět, ke všemu potřebujete jen práva pro čtení.
Takže pokud to chcete mít opravdu bezpečné, můžete mít v systému jiného uživatele pro běh serveru a jiného pro zálohování (můžete mít dokonce různé uživatele pro zálohování různých databází), a v databázi také speciální uživatele pro zálohování, kteří budou mít jen potřebná práva pro čtení.
Nebo můžete jít cestou nejmenšího odporu, použít systémového uživatele postgres, pod kterým běží i server, tím se přihlásit k databázi jako superuživatel, který může cokoli změnit nebo smazat. A samozřejmě je možné to různě kombinovat, např. mít dva uživatele v systému ale v databázi zálohovacího uživatele pro každou databázi zvlášť.
Z hlediska bezpečnosti je o něco důležitější ten uživatel v databázi – protože chyba ve skriptu pro zálohování by mohla odstřelit databázový server nebo smazat jeho data, ale bylo by obtížné tak nepozorovaně pozměnit data. Databázový uživatel, který má práva ke všemu, může nepozorovaně změnit data, aniž byste to zjistil. Na druhou stranu u toho databázového uživatele potřebujete spolupráci vlastníka databáze – např. když se přidá další tabulka, musí se jí nastavit oprávnění, aby ji zálohovací uživatel mohl přečíst.
Ale pokud chcete pro bezpečnost vašich dat udělat něco důležitého, začněte tím, že zálohy budete hned na místě šifrovat veřejným klíčem a privátní klíč budete mít někde off-line. To je mnohem důležitější, než jaké účty pro zálohování použijete.
-
Něco jiného je zase databázový uživatel – ten rozhoduje o tom, k jakým databázovým objektům bude mít zálohovací skript přístup. Zde je zase z hlediska bezpečnosti nevhodný postup, pokud zálohování spouštíte pod uživatelem, který má v databázi práva superuživatele – je to jako kdybyste v systému spouštěl zálohovací skript s právy roota. Je to jednoduché – nemusíte nastavovat oprávnění, ale zároveň máte mnohem silnější oprávnění, než k zálohování potřebujete. Pro zálohování není potřeba umět žádné objekty v databázi zapisovat, mazat nebo je spouštět, ke všemu potřebujete jen práva pro čtení.
1. Databázový uživatel = "role". Bylo by lepší držet se tohoto pojmenování.
2. Bez superusera nezazálohujete systémové databáze (globalobjects). Běžný uživatel může zálohovat pouze databáze, ke kterým má přístup. I tak to ale nebude dokonalé, protože např. zcela běžný CREATE EXTENSION bez superusera neuděláte.
3. OS je zvykem zálohovat jako root, jinak se Vám může lehce stát, že se zálohovací proces nedostane k některým souborům.
Ale pokud chcete pro bezpečnost vašich dat udělat něco důležitého, začněte tím, že zálohy budete hned na místě šifrovat veřejným klíčem a privátní klíč budete mít někde off-line. To je mnohem důležitější, než jaké účty pro zálohování použijete.
Uff, šifrování ochrání data před zneužitím, ale nezvyšují bezpečnost ve smyslu "neztratím data". Naopak šifrování (pokud uděláte chybu) riziko ztráty dat zvyšuje.
====
Kdybychom šli do důsledku, tak ideální způsob zálohy dat je kopírování souboru databáze + WAL (write ahead logs). Na to už zase je naopak potřeba mít práva číst datové soubory - a zde bych naopak ACL jako řešení doporučoval. Odpadá tím potřeba mít v databázi jakoukoliv roli (natož superusera), databázi to neblokuje v provozu. Popis je zde: https://www.postgresql.org/docs/11/continuous-archiving.html
Jako systém na zálohování a zároveň šifrování (a zároveň ne moc složitý) je podle mě Borg Backup https://borgbackup.readthedocs.io/en/stable/, plně šifrované repo se vytvoří "borg init --encryption=keyfile-blake2". Jedinou nevýhodou je, že nepodporuje pull backup, takže když zálohování selže, jediný způsob jak to zjistit je všimnout si, že nechodí logy, nebo během pravidelných údržeb. (Na pull backup existují scripty přes ssh, ale přímo podporovaná cesta to není).
-
2. Bez superusera nezazálohujete systémové databáze (globalobjects). Běžný uživatel může zálohovat pouze databáze, ke kterým má přístup. I tak to ale nebude dokonalé, protože např. zcela běžný CREATE EXTENSION bez superusera neuděláte.
Nemyslím si, že by se v rámci zálohování databáze měl volat příkaz CREATE EXTENSION, ani žádný jiný příkaz CREATE.
Při zálohování databáze je podle mne lepší zálohovat jenom data, struktura by měla být zálohována zvlášť. Struktura bývá stejná na více prostředích nebo třeba na replikačním serveru. Pokud mám zazálohovaná jenom data, mohu je snadno obnovit i na jiném prostředí a nepřekáží mi tam DDL příkazy.
3. OS je zvykem zálohovat jako root, jinak se Vám může lehce stát, že se zálohovací proces nedostane k některým souborům.
Ano, to je to jednoduché řešení. Akorát mi připadá zvláštní oddělovat uživatele pro zálohování, aby omylem neodstřelil databázový proces nebo nepřepsal konfiguraci, a zároveň při zálohování používat oprávnění superuživatele.
Uff, šifrování ochrání data před zneužitím, ale nezvyšují bezpečnost ve smyslu "neztratím data". Naopak šifrování (pokud uděláte chybu) riziko ztráty dat zvyšuje.
Já jsem ale nepsal, že by to zvyšovalo bezpečnost ve smyslu „neztratím data“. Jenom uvádím, že riziko úniku dat ze záloh je mnohem závažnější, než riziko, že mi zálohovací skript omylem smaže databázové soubory. I kdyby se ten zálohovací skript zbláznil a začal mazat soubory, pořád přijdu maximálně o data od poslední zálohy. Pokud by to byl problém, je stejně zálohování „jednou za čas“ nedostatečné a musím řešit průběžnou replikaci dat. Replikace ale nenahrazuje zálohování, protože když smažete/přepíšete data v primárním zdroji, jsou velice rychle smazaná/přepsaná i v replice.
-
Ano, to je to jednoduché řešení. Akorát mi připadá zvláštní oddělovat uživatele pro zálohování, aby omylem neodstřelil databázový proces nebo nepřepsal konfiguraci, a zároveň při zálohování používat oprávnění superuživatele.
Na to není nic zas tak zvláštního. Cokoliv, co jde provozovat s oprávněními < root, je vhodné tak činit.
Na druhou stranu, samotný zálohovací proces už nemá na výběr, ten musí být co nejrobustnější. Nechcete riskovat, že se Vám nezazálohuje část dat nebo část nastavení jen kvůli tomu, že Vám nedošlo (nezkontroloval jste, rozpadlo se po updatu), kde je potřeba oprávnění nastavit. Tam už zkrátka není vyhnutí. (Fungují tak všechny zálohovací systémy, ať už pasivní, nebo s agentem, ať už na Linuxu, Unixech či Windows).
Ze stejného důvodu se vždy zálohování dělá systémem "Zálohovat VŠE" mínus "vyjmenované exclusions", protože opačný postup (zálohovat jen vybraná umístění) vede dřív či později k neštěstí.
Omezit zálohovací proces lze např. pomocí SElinux.
-
Šifrování záloh v momentu, kdy je vytvářím není potřeba, na tom mám zakoupenou službu enterprise zálohovací řešení, které to zálohuje (tedy nejspíš i šifruje). Já dělám jen to, že uživatelem postgres dělám dump všech databází do /srv/bla/bla/zalohy/ odkud si to ten zálohovací systém už zálohuje do nějaké storage nebo tak něco. Funguje mi to zatím dobře, s tím, že používám něco jako: su - postgres -c /path/to/pgbackup.sh, který udělá dumpy do /srv/bla/bla/zalohy/ kde vlastník je uživatel postgres a skupina root.
Každopádně Vám oběma děkuji. Zvažujete různé možnosti. Ale já z toho o čem se bavíte furt nechápu jestli se mám tedy pokoušet vytvářet pgmaint odděleného uživatele pro tvoření pgdumpů, či to stačí tak jednoduše, jak jsem udělal. Nemyslím si, že by se tím mohla databáze nějak "odstřelit", používám vzhledem k databázi jen dvě věci:
- Vypsání si pomocí uživatele postgres jaké databáze existují.
- Na základě toho výpisu z jednotlivých databází udělat dumpy a uložit je do /srv/bla/bla/zalohovani/.
-
Můžete to klidně dál dělat pod uživatelem postgres. :)
Moje poznámka byla spíš ke "zdravým návykům", prostě jsem zvyklý to oddělovat a není to žádná práce navíc a střípek bezpečnosti navíc to je.
-
tedy nejspíš i šifruje
V tom případě je důležité jenom to, jestli na to od nich máte papír. :-) Aby kdyby ta data ze záloh unikla, nebylo to na vás…
Ale já z toho o čem se bavíte furt nechápu jestli se mám tedy pokoušet vytvářet pgmaint odděleného uživatele pro tvoření pgdumpů, či to stačí tak jednoduše, jak jsem udělal.
Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.
-
Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.
Já bych možná jen doporučil ten script volat přímo z crontabu uživatele postgres, nikoliv přes su. Tj. crontab -u postgres -e.
-
Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.
Já bych možná jen doporučil ten script volat přímo z crontabu uživatele postgres, nikoliv přes su. Tj. crontab -u postgres -e.
0 22 * * * /var/lib/postgresql/pg_backup_rotated.sh
a pouzivam ten script z wiki