له EC2 څخه خصوصي RDS: ورته VPC، peering یا بل څه؟

د پراختیاکوونکي لپ ټاپ د کارکوونکو VPN له لارې خصوصي RDS انسټنس ته رسېږي، خو په 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'

که اړیکه له انسټنس څخه بریالۍ او ستاسو له مېز څخه ناکامه شي، د اپلیکیشن لاره سمه ده او ستاسو لاسرسی باید سم شي. که له دواړو ناکامه شي، د اسنادو پرځای پورتنیو ډله او لاره ګنډلو څخه پیل وکړئ. هماغه یوه پرتله د دې ټیکټونو ډېره برخه ګډوډي مخه نیسي.