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'

اگر انسٹنس سے کنکشن کامیاب ہو اور آپ کی میز سے ناکام، تو ایپلیکیشن کا راستہ درست ہے اور آپ کی رسائی کو ٹھیک کرنا ہے۔ اگر دونوں جگہ سے ناکام ہو، تو اسناد کے بجائے اوپر دی گئی گروپ اور راستہ جانچوں سے شروع کریں۔ یہی ایک موازنہ ان ٹکٹوں سے پیدا ہونے والی بیشتر کشمکش روکتا ہے۔