След като приключите с инсталационния процес на вашия PostgreSQL сървър на база данни, е необходимо да го защитите, преди да влезете в производство. В тази публикация ще ви покажем как да подобрите сигурността около вашата база данни, за да запазите данните си безопасни и защитени.
1. Контрол за удостоверяване на клиента
При инсталиране на PostgreSQL файл с име pg_hba.conf се създава в директорията с данни на клъстера на базата данни. Този файл контролира удостоверяването на клиента.
От официалната документация на postgresql можем да дефинираме файла pg_hba.conf като набор от записи, по един на ред, където всеки запис определя тип връзка, диапазон на клиентски IP адрес (ако е подходящ за типа на връзката), име на база данни, потребителско име и метода за удостоверяване, който да се използва за връзки, съответстващи на тези параметри. Първият запис със съвпадащ тип връзка, клиентски адрес, заявена база данни и потребителско име се използва за извършване на удостоверяване.
Така че общият формат ще бъде нещо подобно:
# TYPE DATABASE USER ADDRESS METHODПример за конфигурация може да бъде както следва:
# Allow any user from any host with IP address 192.168.93.x to connect
# to database "postgres" as the same user name that ident reports for
# the connection (typically the operating system user name).
#
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.93.0/24 ident
# Reject any user from any host with IP address 192.168.94.x to connect
# to database "postgres
# TYPE DATABASE USER ADDRESS METHOD
host postgres all 192.168.94.0/24 rejectИма много комбинации, които можете да направите, за да прецизирате правилата (официалната документация описва подробно всяка опция и има няколко страхотни примера), но не забравяйте да избягвате правила, които са твърде разрешителни, като например разрешаване на достъп за линии, използващи БАЗА ДАННИ всички или АДРЕС 0.0.0.0/0.
За да осигурите сигурност, дори ако забравите да добавите правило, можете да добавите следния ред в долната част:
# TYPE DATABASE USER ADDRESS METHOD
host all all 0.0.0.0/0 rejectТъй като файлът се чете отгоре надолу, за да се намерят съответстващи правила, по този начин гарантирате, че за да разрешите разрешение, ще трябва изрично да добавите правилото за съответствие по-горе.
2. Конфигурация на сървъра
Има някои параметри в postgresql.conf, които можем да променим, за да подобрим сигурността.
Можете да използвате параметъра listen_address, за да контролирате кои IP адреси ще имат право да се свързват със сървъра. Ето една добра практика да разрешавате връзки само от известни IP адреси или вашата мрежа и да избягвате общи стойности като “*”,”0.0.0.0:0” или “::”, което ще каже на PostgreSQL да приеме връзка от всеки IP.
Промяната на порта, който postgresql ще слуша (по подразбиране 5432) също е опция. Можете да направите това, като промените стойността на параметъра на порта.
Параметри като work_mem, maintenance_work_mem, temp_buffer, max_prepared_transactions, temp_file_limit са важни, които трябва да имате предвид, в случай че имате атака с отказ на услуга. Това са параметри на изявление/сесия, които могат да се задават на различни нива (db, потребител, сесия), така че тяхното разумно управление може да ни помогне да сведем до минимум въздействието на атаката.
3. Управление на потребители и роли
Златното правило за сигурност по отношение на управлението на потребителите е да предоставите на потребителите минималното количество достъп, от което се нуждаят.
Управлението на това не винаги е лесно и може да стане наистина объркано, ако не се направи добре от самото начало.
Добър начин да държите привилегиите под контрол е да използвате стратегията за роля, група, потребител.
В postgresql всичко се счита за роля, но ние ще направим някои промени в това.
В тази стратегия ще създадете три различни типа или роли:
- ролева роля (идентифицирана с префикс r_)
- групова роля (идентифицирана с префикс g_)
- роля на потребител (обикновено лични имена или имена на приложения)
Ролите (r_ roles) ще бъдат тези, които имат привилегии над обектите. Груповите роли ( g_ roles ) ще бъдат предоставени с r_ roles , така че те ще бъдат колекция от r_ роли. И накрая, ролите на потребителите ще бъдат предоставени с една или повече групови роли и ще бъдат тези с привилегия за влизане.
Нека покажем пример за това. Ще създадем група само за четене за example_schema и след това ще я предоставим на потребител:
Създаваме роля само за четене и й предоставяме привилегии на обект
CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT USAGE ON SCHEMA example to r_example_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;Създаваме група само за четене и предоставяме ролята на тази група
CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';
GRANT r_example_ro to g_example_ro;Създаваме ролята app_user и я караме да се „присъединява“ към групата само за четене
CREATE ROLE app_user WITH LOGIN ;
ALTER ROLE app_user WITH PASSWORD 'somePassword' ;
ALTER ROLE app_user VALID UNTIL 'infinity' ;
GRANT g_example_ro TO app_user;Използвайки този метод, можете да управлявате детайлността на привилегиите и лесно да предоставяте и отменяте групи за достъп на потребителите. Не забравяйте да предоставяте привилегии за обекти само на ролите, вместо да го правите директно за потребителите и да предоставяте привилегия за влизане само на потребителите.
Това е добра практика за изрично отнемане на публични привилегии върху обектите, като например отмяна на публичния достъп до конкретна база данни и предоставяне само чрез роля.
REVOKE CONNECT ON my_database FROM PUBLIC;
GRANT CONNECT ON my_database TO r_example_ro;Ограничете достъпа на SUPERUSER, позволете връзки на суперпотребител само от localhost/unix домейн.
Използвайте конкретни потребители за различни цели, като конкретни потребители на приложения или резервни потребители, и ограничете връзките за този потребител само от необходимите ips.
4. Управление на супер потребители
Поддържането на силна политика за пароли е задължително за запазване на вашите бази данни в безопасност и избягване на хакове на пароли. За силна политика използвайте за предпочитане специални знаци, цифри, главни и малки букви и имайте поне 10 знака.
Има и външни инструменти за удостоверяване, като LDAP или PAM, които могат да ви помогнат да гарантирате изтичане на паролата и политика за повторно използване, както и да се справят със заключването на акаунта при грешки при удостоверяване.
5. Шифроване на данни (при връзка ssl)
PostgreSQL има вградена поддръжка за използване на SSL връзки за криптиране на комуникациите клиент/сървър за повишена сигурност. SSL (Secure Sockets Layer) е стандартната технология за сигурност за установяване на криптирана връзка между уеб сървър и браузър. Тази връзка гарантира, че всички данни, предавани между уеб сървъра и браузърите, остават частни и неразделни.
Тъй като клиентите на postgresql изпращат заявки в обикновен текст и данните също се изпращат нешифровани, те са уязвими за мрежово фалшифициране.
Можете да активирате SSL, като зададете ssl параметъра на on в postgresql.conf.
Сървърът ще слуша както за нормални, така и за SSL връзки на един и същ TCP порт и ще преговаря с всеки свързващ се клиент дали да използва SSL. По подразбиране това е по избор на клиента, но имате възможност да настроите сървъра да изисква използването на SSL за някои или всички връзки, като използвате конфигурационния файл pg_hba, описан по-горе.
6. Шифроване на данни в покой (pg_crypto)
Има два основни вида криптиране, еднопосочно и двупосочно. По един начин никога не се интересувате от дешифрирането на данните в четима форма, но просто искате да проверите, че потребителят знае какъв е основният таен текст. Това обикновено се използва за пароли. При двупосочно криптиране вие искате възможността да криптирате данни, както и да позволите на оторизирани потребители да ги декриптират в смислена форма. Данни като кредитни карти и SSN ще попаднат в тази категория.
За еднопосочно криптиране, функцията crypt, пакетирана в pgcrypto, осигурява допълнително ниво на сигурност над начина md5. Причината е, че с md5 можете да разберете кой има същата парола, защото няма сол (В криптографията солта е произволна информация, която се използва като допълнителен вход към еднопосочна функция, която "хешира" данни, парола или парола), така че всички хора с една и съща парола ще имат един и същ кодиран md5 низ. С крипта те ще бъдат различни.
За данни, които искате да извлечете, не искате да знаете дали двете части от информация са еднакви, но не знаете тази информация и искате само оторизирани потребители да могат да я извличат. Pgcrypto предоставя няколко начина за постигане на това, така че за допълнително четене как да го използвате можете да проверите официалната документация на postgresql на https://www.postgresql.org/docs/current/static/pgcrypto.html.
7. Регистриране
Postgresql предоставя голямо разнообразие от конфигурационни параметри за контролиране какво, кога и къде да се регистрира.
Можете да активирате сесия връзка/прекъсвания, продължителни заявки, размери на временни файлове и така нататък. Това може да ви помогне да получите по-добри познания за вашето работно натоварване, за да идентифицирате странни поведения. Можете да получите всички опции за влизане на следния линк https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html
За по-подробна информация относно вашето работно натоварване можете да активирате модула pg_stat_statements, който предоставя средство за проследяване на статистически данни за изпълнението на всички SQL оператори, изпълнявани от сървър. Има някои инструменти за сигурност, които могат да приемат данните от тази таблица и ще генерират бял списък на sql, за да ви помогнат да идентифицирате заявки, които не следват очакваните модели.
За повече информация https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.
Изтеглете Бялата книга днес Управление и автоматизация на PostgreSQL с ClusterControl Научете какво трябва да знаете, за да внедрите, наблюдавате, управлявате и мащабирате PostgreSQLD Изтеглете Бялата книга8. Одит
Разширението за одит на PostgreSQL (pgAudit) предоставя подробно регистриране на сесия и/или обект чрез стандартното средство за регистриране на PostgreSQL.
Регистрирането на основни изявления може да бъде предоставено от стандартното средство за регистриране с log_statement =all. Това е приемливо за наблюдение и други употреби, но не осигурява нивото на детайлност, което обикновено се изисква за одит. Не е достатъчно да имате списък с всички операции, извършени срещу базата данни. Трябва също така да е възможно да се намерят конкретни изявления, които представляват интерес за одитор. Стандартното средство за регистриране показва какво е поискал потребителят, докато pgAudit се фокусира върху подробностите за случилото се, докато базата данни е удовлетворявала заявката.
9. Поправка
Проверявайте редовно и често страницата с информация за сигурността на PostgreSQL за критични актуализации и корекции на сигурността.
Имайте предвид, че грешките в сигурността на ОС или библиотеки също могат да доведат до изтичане на база данни, така че се уверете, че поддържате корекцията за тях актуална.
ClusterControl предоставя оперативен отчет, който ви дава тази информация и ще изпълни корекциите и надстройките вместо вас.
10. Защита на ниво ред
В допълнение към стандартната SQL система за привилегии, достъпна чрез GRANT, таблиците могат да имат политики за защита на редове, които ограничават, на база на потребител, кои редове могат да бъдат върнати чрез нормални заявки или вмъкнати, актуализирани или изтрити чрез команди за промяна на данни. Тази функция е известна още като защита на ниво ред.
Когато защитата на редове е активирана в таблица, целият нормален достъп до таблицата за избор на редове или промяна на редове трябва да бъде разрешен от политика за защита на редове.
Ето прост пример как да създадете политика за връзката на акаунта, за да позволите само на членовете на ролята на мениджъри да имат достъп до редове и само до редове от техните акаунти:
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);Можете да получите повече информация за тази функция в официалната документация на postgresql https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
Ако искате да научите повече, ето някои ресурси, които могат да ви помогнат да подобрите сигурността на вашата база данни...
- https://www.postgresql.org/docs/9.6/static/auth-pg-hba-conf.html
- https://www.postgresql.org/docs/9.6/static/ssl-tcp.html
- https://www.postgresql.org/docs/current/static/pgcrypto.html
- http://www.postgresonline.com/journal/archives/165-Encrypting-data-with-pgcrypto.html
- https://github.com/pgaudit/pgaudit
- https://www.postgresql.org/docs/9.6/static/pgstatstatements.html
Заключение
Ако следвате съветите по-горе, сървърът ви ще бъде по-безопасен, но това не означава, че ще бъде нечуплив.
За вашата собствена сигурност ви препоръчваме да използвате инструмент за тестване на сигурността като Nessus, за да разберете кои са основните ви уязвимости и да се опитате да ги разрешите.
Можете също да наблюдавате вашата база данни с ClusterControl. С това можете да видите в реално време какво се случва във вашата база данни и да го анализирате.
