Cassandra روی VPN: دسترسی جداگانه برای کلاینت‌ها و گره‌ها

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

هر یک از این سه گروه پاسخ خود را می‌گیرد، و بخش‌های زیر به ترتیب میزان در معرض بودن به آن‌ها می‌پردازند.

سه گروه، سه تصمیم

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

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

آنچه کلاینت‌ها نیاز دارند، و نه بیشتر

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

به همین دلیل یک ناسازگاری در نشانی خصوصی الگوی آشنا را می‌سازد: نخستین اتصال موفق و سپس پایان مهلت‌ها. نشانی‌های اعلام‌شده و مسیریابی کلاینت را آگاهانه پیکربندی کنید؛ انتشار کل خوشه در اینترنت برای رفع یک ناسازگاری، یک اشکال مسیریابی را با در معرض قرار گرفتی عوض می‌کند که نمی‌توانید پس بگیرید.

احراز هویت پایگاه دادهٔ برنامه و مجوزهای نقش را هم در جای خود نگه دارید. یک نشانی VPN ترجمه‌شدهٔ مشترک می‌تواند نمایندهٔ بسیاری از کاربران یا سرویس‌ها باشد، پس هرگز جانشین هویت‌های متمایز پایگاه داده نیست.

رمزنگاری کلاینت-به-گره و بین‌گرهی را جداگانه انجام دهید

مستندات امنیتی Apache رمزنگاری کلاینت-به-گره و بین‌گرهی را پیکربندی‌های جداگانه می‌داند، و فعال کردن یکی دیگری را فعال نمی‌کند. این تمایز درون VPN هم برقرار است، زیرا تونل قطعهٔ خودش را محافظت می‌کند و به‌طور خودکار از فرایند برنامه به فرایند پایگاه داده یا میان هر جفت از اعضای خوشه گسترش نمی‌یابد.

پیکربندی‌ای که هر دو را به‌صراحت روشن می‌کند، به‌جای به ارث بردن پیش‌فرض یک الگو، تقریباً چنین است:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

در پیکربندی‌های سروری که رمزنگاری اختیاری کلاینت را مجاز می‌کنند، پذیرش TLS می‌تواند در کنار پذیرش اتصال‌های رمزنگاری‌نشده وجود داشته باشد، پس سیاست مؤثر را بخوانید نه نیت را. نام گواهی‌ها، توزیع اعتماد و تمدید را برای نقاط پایانی که هر کلاینت واقعاً با آن‌ها تماس می‌گیرد برنامه‌ریزی کنید؛ جایگزینی نام میزبان با یک نشانی IP بررسی هویت کلاینت را تغییر می‌دهد، نه فقط مسیرش را.

مدیریت را روی مسیر خودش نگه دارید

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

قواعد مؤثر ابر، قواعد میزبان و پیکربندی شنونده را هم‌راستا نگه دارید. یک شنوندهٔ خصوصی می‌تواند همچنان از طریق یک ترجمه یا پروکسی ناخواسته در معرض باشد، و یک قاعدهٔ عمومی گسترده می‌تواند بی‌صدا در کنار یک قاعدهٔ تنگ VPN بنشیند تا کسی هر دو را همزمان بررسی کند.

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

آنچه طراحی وعده می‌دهد

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

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