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 застаецца правільным для людзей і інструментаў, чыя ўзгодненая праца гэтага патрабуе. Умовуйце гэты дызайн ролямі, сеткавым ахопам і аперацыйнымі абмежаваннямі, а іншым кліентам пакіньце больш вузкі інтэрфейс. Змешванне дзвюх груп у адной ролі — гэта месца, дзе пачынаюцца спрэчкі.