Прыватны RDS з EC2: той жа VPC, пірынг ці нешта іншае?

Ноўтбук распрацоўшчыка дасягае прыватнага экзэмпляра RDS праз VPN супрацоўнікаў, а праграма на EC2 увогуле не можа падключыцца. Гэта не зламанае разгортванне. У ноўтбука ёсць тунель, які экзэмпляр EC2 ніколі не атрымлівае ў спадчыну, а «прыватны» ў RDS азначае, што база даных не мае публічнай канчатковай кропкі, а не тое, што людзі-карыстальнікі VPN — адзіныя дазволеныя выклікальнікі. Праграме патрэбны ўласны дазволены шлях, уласная сувязь з групай бяспекі і ўласная ідэнтычнасць у базе даных, і парадак, у якім вы выбіраеце гэтыя тры рэчы, зэканоміць большую частку адладкі. Спачатку вызначце маршрут, потым дазволы, потым праверце з разгорнутага асяроддзя, а не са свайго стала.

VPN ноўтбука — не шлях праграмы

Што б ні рабіў VPN супрацоўнікаў для людзей, ён нічога не робіць для экзэмпляра, калі гэты экзэмпляр відавочна не ўваходзіць у той жа сеткавы шлях. Экзэмпляр EC2 у прыватнай падсетцы дасягае RDS праз маршрутызацыю VPC, групы бяспекі і сеткавыя ACL. Ён не атрымлівае ў спадчыну чалавечы тунель, чалавечую сесію ці чалавечыя ўліковыя дадзеныя, і не павінен: беспілотнае падключэнне праграм і аддалены доступ супрацоўнікаў павінны працаваць незалежна.

Гэтая незалежнасць — перавага. Калі VPN не працуе, праграма працягвае працаваць. Калі праграма паводзіць сябе няправільна, ніхто не губляе аддалены доступ. Дызайны, якія зліваюць абодва ў адзін шлях, звычайна выяўляюцца падчас інцыдэнту, у найгоршы магчымы момант.

Рашэнне 1: той жа VPC, прамы шлях

Калі праграма і база даных знаходзяцца ў адным VPC з прамой маршрутызацыяй і без прамежкавага прыстасавання для інспекцыі, шлях просты, а спасылка на групу бяспекі — самы моцны даступны інструмент. Дайце праграме ўласную групу, затым дазвольце порт базы даных з гэтай групы, а не з дыяпазону адрасоў:

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

Порт прыведзены для прыкладу і павінен адпавядаць рухавіку. Спасылка на групу дазваляе трафік з экзэмпляраў праграмы; яна не капіюе іх правілы і не стварае ўваход у базу даных. Дзве асобныя праблемы, два асобныя рашэнні.

Затым праверце астатнюю частку шляху, а не спыняйцеся на правіле, якое вы толькі што дадалі. Выходная палітыка праграмы, поўны набор прымацаваных да базы даных груп, табліцы маршрутаў падсетак і любыя сеткавыя ACL павінны ўзгадняцца. Правілы груп бяспекі маюць стан, а карыстальніцкі сеткавы ACL павінен дазваляць запыт і зваротны трафік асобнымі правіламі, уключаючы эфемерныя парты. Вузкае новае правіла базы даных таксама не адмяняе ранейшае шырокае дазвол, якое ўжо было прымацавана.

Рашэнне 2: іншы VPC або іншы ўліковы запіс

Калі праграма ў іншым VPC, уладальнікі сеткі выбіраюць падтрыманае прыватнае злучэнне: пірынг, транзітны дызайн або схему агульнага VPC. Тады павінны існаваць абодва кірункі маршрутызацыі, развязанне імёнаў павінна працаваць для канчатковай кропкі RDS, а крыніца, якую ацэньвае палітыка базы даных, павінна адпавядаць таму, што фактычна прыходзіць. Супадзенне назваў уліковых запісаў або агульныя білінгавыя адносіны нічога з гэтага не даюць.

Спасылка на групу бяспекі — гэта частка, якая змяняецца. Яна працуе ў некалькіх дызайнах прыватнага злучэння, але перастае працаваць у той момант, калі прамежкавае прыстасаванне перапісвае крыніцу або завяршае злучэнне, бо база даных тады бачыць прамежкавае прыстасаванне, а не вашу групу праграмы. Сцэнарыі VPC для RDS аддзяляюць доступ у адным VPC ад іншых схем, і варта праверыць вашу канкрэтную тапалогію па іх, перш чым меркаваць, што стыль правіла перанясецца.

Не вырашайце адсутны маршрут, робячы базу даных публічна даступнай. Гэта іншае рашэнне пра ўздзеянне з іншым уладальнікам, і звычайна яго прапануе той, хто далей за ўсіх ад наступстваў.

Рашэнне 3: якую ідэнтычнасць прымае база даных

Сеткавы доступ і аўтэнтыфікацыя ў базе даных — асобныя ўзроўні, і іх змешванне стварае самыя памылковыя паведамленні. Роля экзэмпляра — гэта ідэнтычнасць AWS для выкліку API AWS. Яна не з'яўляецца карыстальнікам базы даных. Аўтэнтыфікацыя ў базе даных праз IAM — падтрымліваемая функцыя там, дзе гэта дазваляюць рухавік і канфігурацыя, і яна ўсё яшчэ з'яўляецца адлюстраваннем на карыстальніка базы даных, а не заменай яго.

Выкарыстоўвайце імя канчатковай кропкі RDS у канфігурацыі праграмы замест адраса, узятага з аднаго пошуку. Пераключэнне Multi-AZ змяняе адрас за гэтым імем, і праграма, прывязаная да IP, адмовіць менавіта ў той момант, калі яна патрэбна. Трымайце праверку TLS рухавіка ўключанай, а не выключайце яе, каб пазбавіцца ад памылкі, бо збой праверкі кажа вам нешта пра канчатковую кропку, якую вы дасягнулі.

Затым дайце ўліковаму запісу базы даных мінімум, патрэбны праграме, у схеме, якую яна фактычна выкарыстоўвае. Гэтая праца нудная, яе можна аўдытаваць, і менавіта пра яе спытае разбор інцыдэнту.

Праверце з разгорнутага асяроддзя

Тэстуйце з экзэмпляра або з задачы, якая працуе з той жа групай, падсеткай і роляй. Чатыры збоі выглядаюць падобна з ноўтбука і лёгка адрозніваюцца адтуль: імя, якое не развязваецца, злучэнне, якое сканчаецца па тайм-аўце, збой праверкі TLS і адхілены ўваход у базу даных. Кожны паказвае на розную мяжу, і змяняць уздзеянне базы даных, не ведаючы, які з іх у вас, — гэта здагадкі.

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

Калі злучэнне паспяховае з экзэмпляра і няўдалае з вашага стала, шлях праграмы ў парадку, і выпраўляць трэба ваш доступ. Калі яно няўдалае з абодвух, пачніце з праверак групы і маршруту вышэй, а не з уліковых дадзеных. Гэтае адно параўнанне прадухіляе большую частку мітусні, якую ствараюць гэтыя заяўкі.