TLS بومی، انتقال SSH یا VPN برای یک سرویس ابری

پرسش به‌ندرت این است که آیا باید چیزی میان دو ماشین ابری رمزگذاری شود؛ پرسش این است که کدام واسط را رمزگذاری می‌کنید و چه کسی هویت چه کسی را بررسی می‌کند. این گفتگوها را از سرویس آغاز می‌کنم نه از نمودار شبکه، چون سرویس از قبل می‌داند چه می‌خواهد. سه مرز بیشتر موارد را می‌پوشانند: TLS خود برنامه، یک درگاه TCP منتقل‌شده از طریق SSH، و یک لایه هم‌پوشان مسیریابی‌شده که به هر مشارکت‌کننده نشانی می‌دهد. آن‌ها بر اساس قدرت رتبه‌بندی نمی‌شوند، بلکه بر اساس اینکه چه مقدار از مشکل را می‌پوشانند.

با سرویس شروع کنید، نه با شبکه

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

یک API داخلی کوچک بردارید که از قبل HTTPS را روی درگاه 8443 با گواهی برای api.internal.example ارائه می‌دهد. ss -ltnp روی میزبان نشان می‌دهد به چه چیزی متصل است، و openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example نشان می‌دهد آیا گواهی برای نامی که مشتری واقعاً استفاده می‌کند معتبر است. اگر هر دو سالم باشند، سرویس می‌تواند جریان خود را محافظت کند و فقط دسترس‌پذیری می‌ماند. این مشکلی بسیار کوچک‌تر از ساختن یک شبکه است.

گام 1: آیا سرویس از خود محافظت می‌کند؟

این گزینه‌ای است که وقتی مناسب باشد انتخاب می‌شود، و بیشتر از آنچه تیم‌ها فرض می‌کنند مناسب است. رمزگذاری سرویس تمام مسیر میان مشتری و سرور را می‌پوشاند، از جمله هر جهش میان آن‌ها، که هیچ تونلی دور میانه آن را بهتر نمی‌کند. نام مورد انتظار و اعتماد را صریح تنظیم کنید، به‌جای تکیه بر آنچه به‌طور تصادفی در انبار پیش‌فرض مشتری وجود دارد.

رمزگذاری و دسترس‌پذیری کنترل‌های جداگانه‌ای می‌مانند، و ادغام آن‌ها همان جایی است که این گزینه اشتباه می‌شود. یک سرویس TLS روی شنونده عمومی نامحدود همچنان تلاش‌های اتصال را از هر کسی می‌پذیرد، پس شنونده و قواعد شبکه باید مستقل از محافظت‌شده بودن بار مفید محدود شوند. سپس وابستگی‌ها را بررسی کنید، چون یک API روی TLS چیزی درباره نقطه کشف، درگاه مدیریت یا کانال انتقال انبوه کنارش نمی‌گوید. هر یک از آن‌ها پاسخ خودش را می‌خواهد، و یک هم‌زاد محافظت‌نشده کافی است تا کل مرز به افسانه تبدیل شود.

گام 2: آیا یک درگاه TCP کل نیاز است؟

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

شکل ssh -N -L 8443:127.0.0.1:8443 [email protected] است، و جزئیات مهم نشانی هدف است: 127.0.0.1 در سمت دور حل می‌شود، پس اتصال به سرویس از باستیون باز می‌شود نه از لپ‌تاپ شما. شنونده محلی را به‌صورت باریک -L 127.0.0.1:8443:... ببندید تا به‌طور تصادفی سرویس را در شبکه محلی خود منتشر نکنید. در سمت سرور، محدود کنید که حساب چه چیزی را می‌تواند منتقل کند، به‌جای اعتماد به رفتار درست مشتری. PermitOpen، AllowTcpForwarding local و GatewayPorts no پیش‌فرض سه تنظیمی هستند که یک رله همه‌کاره را به کانالی مشخص تبدیل می‌کنند.

قرارداد در هر دو جهت باریک است. SSH کانال خودش را محافظت می‌کند، و جهش بیشتر از باستیون به برنامه دیگر محافظت خودش را می‌خواهد. سرویسی که فقط روی loopback باستیون گوش می‌دهد، مواجهه‌ای کاملاً متفاوت از سرویسی دارد که از شبکه دیگری می‌رسد، و انتقال این را تغییر نمی‌دهد. احراز هویت و بررسی‌های TLS برنامه را سر جایشان نگه دارید، به‌جای اینکه تونل را جایگزین آن‌ها بدانید.

این برای یک اتصال با یک مالک خوب کار می‌کند. در مقیاس به یک سامانه تبدیل می‌شود: تعارض درگاه‌های محلی، نظارت، چرخش کلیدها و این پرسش که چه کسی انتقال را پس از راه‌اندازی مجدد دوباره شروع می‌کند.

گام 3: آیا مسیریابی نیاز واقعی است؟

آن فهرست هزینه صادقانه کوچک‌ترین گزینه است، و به همین دلیل تیم‌ها در نهایت مشتی فرمان پس‌زمینه فراموش‌شده را با چیزی مدیریت‌شده جایگزین می‌کنند. جایگزین به‌طور خودکار VPN نیست. اگر نیاز هنوز یک درگاه TCP است، یک انتقال تحت نظارت با مالک مستند ارزان‌تر از یک لایه هم‌پوشان اجرا می‌شود و به روش‌هایی شکست می‌خورد که می‌بینید. مالکیت عملیاتی را پیش از سنجش زیبایی بسنجید.

مسیریابی زمانی پاسخ درست می‌شود که مسیریابی نیاز باشد. چندین برنامه که به اتصال IP معمولی نیاز دارند، پروتکل‌هایی که انتقال TCP نمی‌تواند حمل کند، یا سرویس‌هایی که میان میزبان‌ها جابه‌جا می‌شوند، همه به یک سو اشاره می‌کنند.

یک لایه هم‌پوشان به مشارکت‌کنندگان نشانی و مسیر می‌دهد، و سپس کار واقعی آغاز می‌شود: بازه‌های بدون هم‌پوشانی، مالکیت مسیر، DNS، ثبت‌نام، لغو و آنچه هنگام ناپدید شدن یک همتا رخ می‌دهد. هیچ‌کدام از این‌ها با نشانی نمی‌آید. همتای پذیرفته‌شده در لایه هم‌پوشان نیز به‌طور خودکار برای هر عملیات روی مقصد مجاز نیست، پس احراز هویت در سطح سرویس می‌ماند.

آنچه پس از آن مالکش هستید

دو چیز به سندی که به جا می‌گذارید تعلق دارد. نخست هویتی که انتظار می‌رود مشتری آن را بررسی کند، چون هر یک از این مرزها به‌آرامی تنزل می‌یابد وقتی بررسی نام شل شود تا چیزی کار کند. دوم گام حذف است: کدام کلید، کدام قاعده یا کدام مسیر هنگام پایان دسترسی ناپدید می‌شود، و چه کسی آن را انجام می‌دهد.

این راهنما همان‌جا که آغاز شد پایان می‌یابد، با سرویس. مرزی را انتخاب کنید که ترافیک واقعی را می‌پوشاند و همتایانی را که قصد بررسی‌شان را داشتید بررسی می‌کند، سپس بنویسید دسترسی چگونه به‌روزرسانی، پایش و حذف می‌شود. مرجع OpenSSH جایی است که پیش از وعده دادن یک قرارداد باریک، گزینه‌های انتقال را تأیید کنید. اگر نمی‌توانید گام حذف را در یک جمله توصیف کنید، مرز بزرگ‌تر از مشکل است.