PostgreSQL е една от най-сигурните бази данни в света. Сигурността на базата данни играе наложителна роля в критичните за мисии среди в реалния свят. Важно е да се гарантира, че базите данни са винаги защитени и не са подложени на неоторизиран достъп, като по този начин се компрометира сигурността на данните. Докато PostgreSQL предоставя различни механизми и методи за потребителите за достъп до базата данни по защитен начин, той може също така да бъде интегриран с различни външни системи за удостоверяване, за да се гарантира, че изискванията за сигурност на базата данни са изпълнени.
Освен че предоставя защитени механизми за удостоверяване чрез SSL, MD5, pgpass и pg_ident и т.н., PostgreSQL може да бъде интегриран с различни други популярни външни системи за автентификация от корпоративен клас. Моят фокус в този блог ще бъде върху LDAP, Kerberos и RADIUS със SSL и pg_ident.
LDAP
LDAP се отнася до Lightweight Directory Access Protocol, който е популярно използвана централизирана система за удостоверяване. Това е хранилище за данни, което съхранява потребителските идентификационни данни и различни други подробности, свързани с потребителя, като имена, домейни, бизнес единици и т.н. под формата на йерархия в табличен формат. Крайните потребители, които се свързват към целевите системи (например база данни), трябва първо да се свържат с LDAP сървър, за да преминат успешно удостоверяване. LDAP е една от популярните системи за удостоверяване, използвани в момента в организации, изискващи високи стандарти за сигурност.
LDAP + PostgreSQL
PostgreSQL може да бъде интегриран с LDAP. В моя опит с консултации с клиенти това се счита за една от ключовите възможности на PostgreSQL. Тъй като удостоверяването на потребителското име и паролата се извършва на LDAP сървъра, за да се гарантира, че потребителите могат да се свързват с базата данни чрез LDAP, потребителският акаунт трябва да съществува в базата данни. С други думи, това означава, че потребителите, когато се опитват да се свържат с PostgreSQL, се насочват първо към LDAP сървъра и след това към базата данни на Postgres при успешно удостоверяване. Може да се направи конфигурация във файла pg_hba.conf, за да се гарантира, че връзките се насочват към LDAP сървъра. По-долу е даден примерен запис pg_hba.conf -
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", dc=example, dc=com"По-долу е даден пример за LDAP запис в pg_hba.conf:
host all pguser 0.0.0.0/0 ldap ldapserver=ldapserver.example.com ldapprefix="cn=" ldapsuffix=", ou=finance, dc=example, dc=com"Когато използвате ldap порт и TLS, които не са по подразбиране:
ldap ldapserver=ldapserver.example.com ldaptls=1 ldapport=5128 ldapprefix="uid=" ldapsuffix=",ou=finance,dc=apix,dc=com"Разбиране на горния LDAP запис
- LDAP използва различни атрибути и терминологии, за да съхранява/търси потребителски запис в своето хранилище за данни. Също така, както бе споменато по-горе, потребителските записи се съхраняват в йерархия.
- Горещите записи в pg_hba.conf ldap се състоят от атрибути, наречени CN (общо име), OU (организационна единица) и DC (компонент на домейн), които, наречени относителни отличителни имена (RDN), тези последователности от RDN заедно се превръщат в нещо наречен DN (отличително име). DN е LDAP обектът, базиран на който търсенето се извършва в LDAP хранилището за данни.
- Стойностите на атрибутите на LDAP като CN, DC, OU и т.н. са дефинирани в класовете на обектите на LDAP, които могат да бъдат предоставени от системните експерти, изградили LDAP средата.
Това ще направи ли LDAP достатъчно защитен?
Може би не. Паролите, предавани по мрежата в LDAP среда, не са криптирани, което може да представлява риск за сигурността, тъй като криптираните пароли могат да бъдат хакнати. Има опции за по-сигурна комуникация с идентификационните данни.
- Помислете за конфигуриране на LDAP на TLS (Transport Layer Security)
- LDAP може да бъде конфигуриран с SSL, което е друга опция
Съвети за постигане на LDAP интеграция с PostgreSQL
(за базирани на Linux системи)
- Инсталирайте подходящи модули openLDAP въз основа на версията на операционната система
- Уверете се, че софтуерът PostgreSQL е инсталиран с LDAP библиотеки
- Уверете се, че LDAP е добре интегриран с Active Directory
- Запознайте се с всички съществуващи грешки в модулите на openLDAP, които се използват. Това може да бъде катастрофално и да компрометира стандартите за сигурност.
- Windows Active Directory също може да се интегрира с LDAP
- Помислете за конфигуриране на LDAP със SSL, който е по-сигурен. Инсталирайте подходящи модули openSSL и имайте предвид грешки като сърдечни проблеми, които могат да разкрият идентификационните данни, предавани по мрежата.
Kerberos
Kerberos е стандартизирана за индустрията централизирана система за удостоверяване, популярно използвана в организациите и предоставя механизъм за удостоверяване, базиран на криптиране. Паролите се удостоверяват от сървър за удостоверяване на трета страна, наречен KDC (Център за разпределение на ключове). Паролите могат да бъдат криптирани въз основа на различни алгоритми и могат да бъдат декриптирани само с помощта на споделени частни ключове. Това също означава, че паролите, предавани по мрежата, са криптирани.
PostgreSQL + Kerberos
PostgreSQL поддържа GSSAPI базирано удостоверяване с Kerberos. Потребителите, които се опитват да се свържат с базата данни Postgres, ще бъдат насочени към KDC сървър за удостоверяване. Това удостоверяване между клиенти и база данни KDC се извършва въз основа на споделени частни ключове и при успешно удостоверяване клиентите вече ще притежават базирани на Kerberos идентификационни данни. Същите идентификационни данни се подлагат на валидиране между сървъра на Postgres и KDC, което ще бъде направено въз основа на файла keytab, генериран от Kerberos. Този файл keytab трябва да съществува на сървъра на базата данни с подходящи разрешения за потребителя, притежаващ процеса на Postgres.
Процесът на конфигуриране и свързване на Kerberos -
-
Потребителските акаунти, базирани на Kerberos, трябва да генерират билет (заявка за връзка) с помощта на команда „kinit“.
-
Файл с keytab трябва да бъде генериран с помощта на команда „kadmin“ за напълно квалифициран потребителски акаунт (принципал), базиран на Kerberos, и след това Postgres ще използва същия файл keytab, за да потвърди идентификационните данни. Принципите могат да бъдат криптирани и добавени към съществуващ файл keytab с помощта на командата „ktadd“. Шифроването с Kerberos поддържа различни индустриални стандартни алгоритми за криптиране.
Генерираният файл keytab трябва да бъде копиран на сървъра на Postgres, той трябва да бъде четим от процеса на Postgres. Параметърът postgresql.conf по-долу трябва да бъде конфигуриран:
krb_server_keyfile = '/database/postgres/keytab.example.com'Ако сте особени по отношение на чувствителността към малки и малки букви, тогава използвайте параметъра по-долу
krb_caseins_users which is by default “off” (case sensitive) -
Трябва да се направи запис в pg_hba.conf, за да се гарантира, че връзките са насочени към KDC сървър
Примерен запис в pg_hba.conf
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COMПример pg_hba.conf запис с запис на карта
# TYPE DATABASE USER CIDR-ADDRESS METHOD host all all 192.168.1.6/32 gss include_realm=1 krb_realm=EXAMPLE.COM map=krb -
Потребителски акаунт, който се опитва да се свърже, трябва да бъде добавен към базата данни на KDC, която се нарича принципал и същия потребителски акаунт или потребителски акаунт за съпоставяне трябва да съществува и в базата данни
По-долу е даден пример за принципал на Kerberos
pguser е потребителското име, а „example.com“ е името на сферата, конфигурирано в конфигурацията на Kerberos (/etc/krb5.conf) в KDC сървъра.
В света на kerberos, директорите са във формат като имейл ([email protected]) и потребителите на базата данни не могат да бъдат създадени в същия формат. Това кара администраторите на база данни да мислят вместо това да създадат съпоставяне на потребителски имена на база данни и да гарантират, че принципалите се свързват с картографирани имена с помощта на pg_ident.conf.
По-долу е даден пример за запис на име на карта в pg_ident.conf
# MAPNAME SYSTEM-USERNAME GP-USERNAME mapuser /^(.*)EXAMPLE\.DOMAIN$ admin
Това ще направи ли Kerberos достатъчно защитен?
Може би не. Потребителските идентификационни данни, комуникирани през мрежата, могат да бъдат разкрити, хакнати. Въпреки че Kerberos криптира принципите, те могат да бъдат откраднати, хакнати. Това води до необходимостта от прилагане на сигурност на мрежовия слой. Да, SSL или TLS е правилният начин. Системата за удостоверяване на Kerberos може да бъде интегрирана със SSL или TLS. TLS е наследник на SSL. Препоръчително е Kerberos да е конфигуриран със SSL или TLS, така че комуникацията през мрежата да е защитена.
СЪВЕТИ
- Уверете се, че библиотеките krb* са инсталирани
- Библиотеките OpenSSL трябва да бъдат инсталирани, за да конфигурирате SSL
- Уверете се, че Postgres е инсталиран със следните опции
./configure --with-gssapi --with-krb-srvnam --with-openssl
РАДИУС
RADIUS е мрежов протокол за услуга за отдалечено удостоверяване, който осигурява централизирано
Удостоверяване, оторизация и счетоводство (AAA). Двойките потребителско име/парола се удостоверяват на RADIUS сървъра. Този начин на централизирано удостоверяване е много прав или по-опростен в сравнение с други системи за удостоверяване като LDAP и Kerberos, което включва малко сложност.
RADIUS + PostgreSQL
PostgreSQL може да бъде интегриран с механизъм за удостоверяване на RADIUS. Счетоводството все още не се поддържа в Postgres. Това изисква в базата данни да съществуват потребителски акаунти на базата данни. Връзките към базата данни са разрешени въз основа на споделената тайна, наречена „radiussecret“.
Запис в конфигурацията pg_hba.conf е от съществено значение за насочване на връзките към радиус сървър за удостоверяване.
Примерен запис в pg_hba.conf
hostssl all all 0.0.0.0/0 radius radiusserver=127.0.0.1 radiussecret=secretr radiusport=3128За да разберете горния запис -
„radiusserver“ е IP адресът на хоста на RADIUS сървъра, където потребителите се насочват за удостоверяване. Този параметър е конфигуриран в /etc/radiusd.conf в RADIUS сървъра.
Стойността „radiussecret“ се извлича от clients.conf. Това е секретният код, който уникално идентифицира радиус клиентската връзка.
„radiusport“ може да се намери във файла /etc/radiusd.conf. Това е порт, на който радиусните връзки ще слушат.
Значение на SSL
SSL (Secure Socket Layer) играе наложителна роля с външни системи за удостоверяване. Силно препоръчително е да конфигурирате SSL с външна система за удостоверяване, тъй като ще има комуникация на чувствителна информация между клиентите и сървърите по мрежата и SSL може допълнително да засили сигурността.
Влияние върху производителността от използването на външни системи за удостоверяване
Ефективната и ефикасна система за сигурност идва за сметка на производителността. Тъй като клиентите/потребителите, които се опитват да се свържат с базата данни, се насочват към системите за удостоверяване, за да установят връзка, може да има влошаване на производителността. Има начини за преодоляване на препятствията в производителността.
- При наличие на външен механизъм за удостоверяване може да има забавяне при установяване на връзка с базата данни. Това може да бъде истински проблем, когато има огромен брой връзки, които се установяват към базата данни.
- Разработчиците трябва да гарантират, че не се правят ненужно голям брой връзки към базата данни. Обслужването на множество заявки за приложения чрез една връзка би било от полза.
- Освен това, колко време отнема всяка заявка в края на базата данни, играе важна роля. Ако завършването на заявката отнема повече време, следващите заявки ще се наредят на опашка. Настройването на производителността на процесите и щателното проектиране на инфраструктурата ще бъдат от ключово значение!
- База данни и инфраструктура трябва да бъдат ефективно проектирани и с подходящ капацитет, за да се гарантира добра производителност.
- Когато правите сравнителен анализ на производителността, уверете се, че SSL е активиран и след това трябва да се оцени средното време за установяване на връзката.
Интегриране на външни системи за удостоверяване с ClusterControl - PostgreSQL
Инстанциите на PostgreSQL могат да бъдат изградени и конфигурирани автоматично чрез ClusterControl GUI. Интегрирането на външни системи за удостоверяване с PostgreSQL екземпляри, разгърнати чрез ClusterControl, е почти подобно в сравнение с интеграцията с традиционните PostgreSQL екземпляри и всъщност е малко по-просто. По-долу е даден преглед на същото -
- ClusterControl инсталира PostgreSQL библиотеки, активирани с LDAP, KRB, GSSAPI и OpenSSL възможности
- Интеграцията с външни системи за удостоверяване изисква различни промени в конфигурацията на параметрите на сървъра на базата данни на postgresql, които могат да бъдат направени с помощта на ClusterControl GUI.
