EC2-оос хувийн RDS: ижил VPC, peering эсвэл өөр зүйл үү?

Хөгжүүлэгчийн зөөврийн компьютер хувийн RDS инстанц руу ажилтны VPN-ээр хүрдэг боловч EC2 дээрх аппликейшн огт холбогдож чадахгүй. Энэ нь эвдэрсэн байршуулалт биш. Зөөврийн компьютерт EC2 инстанц хэзээ ч өвлөдөггүй туннель байдаг ба RDS дахь «хувийн» гэдэг нь мэдээллийн санд нийтийн төгсгөлийн цэг байхгүй гэсэн үг, хүний VPN хэрэглэгчид л зөвшөөрөгдсөн дуудагчид гэсэн үг биш. Аппликейшнд өөрийн зөвшөөрөгдсөн зам, аюулгүйн бүлэгтэй өөрийн харилцаа, мэдээллийн сан дахь өөрийн таних тэмдэг хэрэгтэй бөгөөд эдгээр гурвыг сонгох дараалал нь алдааг засах ихэнх хэсгийг хэмнэдэг. Эхлээд маршрутыг, дараа нь зөвшөөрлүүдийг шийдэж, дараа нь ширээнээсээ биш, байршуулсан орчноос шалгана уу.

Зөөврийн компьютерын VPN нь аппликейшны зам биш

Ажилтны VPN хүмүүст юу ч хийсэн, тухайн инстанц ижил сүлжээний замын тодорхой хэсэг биш л бол инстанцад юу ч хийдэггүй. Хувийн дэд сүлжээний EC2 инстанц VPC чиглүүлэлт, аюулгүйн бүлэг, сүлжээний ACL-ээр RDS-д хүрдэг. Энэ нь хүний туннель, хүний сесс эсвэл хүний нэвтрэх мэдээллийг өвлөдөггүй бөгөөд өвлөх ёсгүй: хяналтгүй аппликейшн холболт болон ажилтны алсын хандалт бие даан ажиллах ёстой.

Энэ бие даасан байдал нь давуу тал юм. 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'

Хэрэв холболт инстанцаас амжилттай болж, ширээнээс чинь бүтэлгүйтвэл аппликейшны зам зөв бөгөөд засах зүйл нь таны хандалт юм. Хэрэв хоёулангаас бүтэлгүйтвэл нэвтрэх мэдээллээс биш, дээрх бүлэг болон замын шалгалтаас эхэл. Энэ нэг харьцуулалт эдгээр тасалбараас үүсдэг ихэнх бухимдлыг сэргийлдэг.