Մասնավոր RDS-ը EC2-ից. նույն VPC-ն, peering, թե՞ այլ բան

Մշակողի նոութբուքը հասնում է մասնավոր 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-ում է, ցանցի սեփականատերերն ընտրում են աջակցվող մասնավոր միացում՝ peering, տրանզիտ նախագիծ կամ համօգտագործվող VPC կարգավորում։ Այդ դեպքում պետք է գոյություն ունենան երթուղավորման երկու ուղղությունները, անունների լուծումը պետք է աշխատի RDS վերջնակետի համար, և այն աղբյուրը, որը գնահատում է տվյալների բազայի քաղաքականությունը, պետք է համապատասխանի իրականում ժամանողին։ Հաշիվների անունների համընկնումը կամ ընդհանուր հաշվարկային հարաբերությունը դրանցից ոչինչ չեն տալիս։

Անվտանգության խմբի հղումը այն մասն է, որը տարբերվում է։ Այն աշխատում է մասնավոր միացման մի քանի նախագծերում, բայց դադարում է աշխատել այն պահին, երբ միջնորդ սարքը վերագրում է աղբյուրը կամ ավարտում է կապը, քանի որ այդ ժամանակ տվյալների բազան տեսնում է միջնորդ սարքը, այլ ոչ թե ձեր հավելվածի խումբը։ RDS-ի VPC սցենարները առանձնացնում են նույն VPC-ի ներսում մուտքը մյուս կարգավորումներից, և արժե ձեր կոնկրետ տոպոլոգիան ստուգել դրանց դեմ՝ նախքան ենթադրել, որ կանոնի ոճը փոխանցվում է։

Չլուծեք բացակայող երթուղին՝ տվյալների բազան հանրությանը հասանելի դարձնելով։ Դա այլ սեփականատիրոջով այլ բացահայտման որոշում է, և սովորաբար առաջարկում է նա, ով ամենահեռու է հետևանքից։

Որոշում 3. ինչ ինքնություն է ընդունում տվյալների բազան

Ցանցային մուտքն ու տվյալների բազայի նույնականացումը առանձին շերտեր են, և դրանց խառնումը ստեղծում է ամենամոլորիչ սխալները։ Օրինակի դերը AWS ինքնություն է AWS API-ները կանչելու համար։ Այն տվյալների բազայի օգտատեր չէ։ 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'

Եթե կապը հաջողվում է օրինակից և ձախողվում ձեր գրասեղանից, հավելվածի ուղին ճիշտ է, և ձեր մուտքն է այն, ինչ պետք է ուղղել։ Եթե այն ձախողվում է երկուսից էլ, սկսեք վերևի խմբի և երթուղու ստուգումներից, այլ ոչ թե հավատարմագրերից։ Այդ մեկ համեմատությունը կանխում է այս տոմսերի առաջացրած իրարանցման մեծ մասը։