TLS, мрежовият достъп и правата на SQL отговарят на различни въпроси
Шифроването на връзка, допускането на източник и предоставянето на таблица са три решения. Прегледайте ги по ред, преди да питате дали TLS може да замени VPN.
Някой предлага да се даде на клиент вход за PostgreSQL, така че заявка за разход да пътува шифрована от край до край. Администраторът на базата данни се нуждае от истинска сесия SQL, а друг предлага вместо това уеб формуляр. И двете предложения решават грешния проблем, защото нито едно не започва от операцията, която клиентът действително извършва. Прегледайте трите решения по ред и въпросът дали TLS може да замени VPN ще си отговори сам.
Започнете от операцията, от която клиентът се нуждае
Запишете какво трябва да постигне клиентът. Подаването на заявка, четенето на един ред от отчет и изпълняването на импровизирана заявка са три различни операции с три различни профила на риск.
След това запишете кой прави заявката. Клиент, агент за поддръжка и администратор не са взаимозаменяеми, дори когато пипат една и съща таблица. Разликата определя колко от езика за заявки клиентът изобщо трябва да види.
Двойката отговори определя интерфейса. Всичко след това е реализация и повечето спорове за шифроването всъщност са спорове за това кой интерфейс е избран.
Три контрола, три решения
Удостовереният TLS защитава връзката и определя кои идентичности TLS се приемат. Мрежовият достъп определя кои източници изобщо могат да достигнат до слушателя. Оторизацията в базата данни определя кои обекти и действия може да използва една роля.
Нито един от трите не замества останалите, което таблицата показва явно.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Прочетете реда, на който разчитате, преди да премахнете друг. Повечето такива проекти се провалят, защото даден контрол е бил предположен, а не конфигуриран.
Директният SQL оставя политиката на базата данни начело
При одобрена директна връзка запазете както проверката на идентичността на услугата, така и предвидената политика за достъп. Включването на TLS прави шифрованите връзки достъпни; то не отхвърля нешифрованите, освен ако конфигурацията за достъп не го изисква чрез записи hostssl.
Тази разлика си струва да се провери в работещата конфигурация, а не в шаблон. Сървър, който предлага TLS и приема открит текст, не е архитектурата, която повечето хора мислят, че са внедрили. Прочетете правилата за достъп и вижте кои записи действително го изискват. Тази една проверка разделя сървър със способност за шифроване от сървър само с шифроване.
Използвайте роли само с привилегиите, които работата изисква, и преглеждайте собствеността, наследеното членство и широко предоставените разрешения. Моделът на привилегиите на PostgreSQL е границата на правомощията за обектите в базата данни.
VPN може да ограничи кои устройства достигат услугата преди удостоверяването в базата данни, а шлюзът за достъп може да направи нещо подобно. Нито едно от двете не премахва нуждата да поддържате изложения компонент, да управлявате идентификационни данни и да ограничавате използването на ресурси.
Клиентските сертификати са идентификационни данни, а не ACL
Клиентският сертификат може да добави изискване при свързване. Настройката clientcert може да изисква доверен сертификат и в по-строгия режим връзка между името на сертификата и потребителя на базата данни.
Това са по-силни идентификационни данни. Това не е списък за оторизация и не прави сървъра невидим, защото компонентът, който приема връзката, все още обработва мрежов трафик и ръкостискане. Третирането на сертификат като списък за достъп оставя действителните разрешения непокътнати. То също така е склонно да разширява разпространението на сертификати, което създава следващия проблем.
Силен сертификат, прикачен към роля с прекомерни права, произвежда добре удостоверен администратор. Проверете ролята, преди да празнувате сертификата.
Изберете по-тесния интерфейс, когато пасва
За заявка за разход приложна крайна точка, която приема заявката, налага бизнес правилата и връща разрешения резултат на този потребител, представлява операцията по-добре от общ профил SQL.
След това приложението използва собствената си ограничена идентичност в базата данни и клиентът никога не получава език за заявки като функция. Това е по-малка повърхност с по-малко начини да сгрешите.
Това е опция за дизайн, а не твърдение, че приложният код автоматично е по-безопасен. Този код трябва да удостовери своите извикващи, да оторизира всяко действие и да валидира входа си, а собствените му разрешения в базата данни все още имат значение.
Директният SQL остава правилен за хора и инструменти, чиято одобрена работа го изисква. Обвържете този дизайн с роли, мрежов обхват и оперативни граници и оставете другите клиенти с по-тесния интерфейс. Смесването на двете групи в една роля е мястото, където започват споровете.