RDS خصوصی از EC2: همان 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 کار کند، و منبعی که سیاست پایگاه داده ارزیابی می‌کند باید با آنچه واقعاً می‌رسد مطابقت داشته باشد. تطابق نام حساب‌ها یا رابطه صورت‌حساب مشترک هیچ‌یک از این‌ها را فراهم نمی‌کند.

ارجاع به گروه امنیتی بخشی است که متفاوت می‌شود. در چند طرح اتصال خصوصی کار می‌کند، اما در لحظه‌ای که یک جعبه میانی منبع را بازنویسی کند یا اتصال را خاتمه دهد از کار می‌افتد، زیرا پایگاه داده آنگاه جعبه میانی را می‌بیند نه گروه برنامه شما را. سناریوهای VPC در RDS دسترسی درون همان 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'

اگر اتصال از نمونه موفق و از میز کار شما ناموفق باشد، مسیر برنامه درست است و دسترسی شماست که باید اصلاح شود. اگر از هر دو ناموفق باشد، به‌جای اعتبارنامه‌ها با بررسی‌های گروه و مسیر بالا شروع کنید. همین یک مقایسه بیشتر آشفتگی‌ای را که این تیکت‌ها ایجاد می‌کنند جلوگیری می‌کند.