EC2ден жеке RDS: бир VPC, peering же башка нерсеби?

Иштеп чыгуучунун ноутбугу персоналдын VPN аркылуу жеке RDS инстанциясына жетет, бирок 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де болсо, тармактын ээлери колдоого алынган жеке туташтырууну тандашат: peering, транзиттик долбоор же жалпы VPC келишими. Андан кийин маршруттоонун эки багыты тең болушу керек, аттарды чечүү RDS акыркы чекити үчүн иштеши керек, жана маалымат базасынын саясаты баалаган булак иш жүзүндө келгенге дал келиши керек. Эсептердин аттарынын дал келиши же жалпы эсеп айырышуу мамилеси булардын эч бирин бербейт.

Коопсуздук тобуна шилтеме — өзгөрүүчү бөлүк. Ал жеке туташтыруунун бир нече долбоорунда иштейт, бирок ортомчу түзмөк булакты кайра жазганда же байланышты токтоткондо иштебей калат, анткени ошондо маалымат базасы колдонмо тобуңузду эмес, ортомчуну көрөт. RDS VPC сценарийлери бир 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'

Эгер байланыш инстанциядан ийгиликтүү болуп, столуңуздан ийгиликсиз болсо, колдонмонун жолу туура жана оңдоо керек нерсе — сиздин кирүүңүз. Эгер ал экөөнүн тең жактан ийгиликсиз болсо, эсептик маалыматтардан эмес, жогорудагы топ жана маршрут текшерүүлөрүнөн баштаңыз. Ушул бир салыштыруу бул билеттер жараткан алаксактын көбүн алдын алат.