رمزگذاری سیم Firebird 3 و VPN دو مرز جداگانه‌اند

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

دو مرز که همپوشانی ندارند

مرز VPN بسته‌ها را میان کلاینت و دروازه محافظت می‌کند. رمزگذاری سیم Firebird پروتکل پایگاه داده را میان کتابخانه کلاینت و فرایند سرور محافظت می‌کند. هر دو می‌توانند همزمان باشند و هیچ‌یک جای دیگری را نمی‌گیرد.

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

مرز یکم: چه کسی می‌تواند شنونده را باز کند

نشانی واقعی سرور و درگاه تنظیم‌شده را شناسایی کنید، که اگر تغییر نکرده باشد 3050 است، سپس در دیوار آتش میزبان و شبکه تنها منابع تأییدشده VPN را مجاز کنید. هر ترجمه نشانی در دروازه VPN را در نظر بگیرید و اگر دروازه جداگانه است به میزبان پایگاه داده مسیر بازگشت به استخر کلاینت بدهید.

سپس نفی را اثبات کنید. مسیر بیرونی که باید رد شود باید همچنان رد شود، زیرا باز کردن تونل به‌خودی‌خود شنونده Firebird را محدود نمی‌کند.

مرز دوم: Firebird چه چیزی را مذاکره می‌کند

Firebird 3 چارچوبی برای رمزگذاری سیم معرفی کرد با سیاست سروری که می‌تواند غیرفعال، فعال یا اجباری باشد. سیاست کف را تعیین می‌کند. نشست واقعی همچنان به کتابخانه کلاینتی بستگی دارد که برنامه بارگذاری می‌کند و به افزونه‌هایی که دو طرف پشتیبانی می‌کنند.

در یادداشت‌های انتشار Firebird 3 آمده است که Arc4 افزونه پیش‌فرض رمزگذاری سیم برای آن انتشار است. Arc4 یک پیش‌فرض تاریخی است، نه توصیه‌ای برای رمز مدرن، و با حفاظت بیرونی VPN یکی نیست.

احراز هویت متغیر سوم در همان مذاکره است. سرور مجموعه‌ای از افزونه‌های احراز هویت را می‌پذیرد، کتابخانه کلاینت زیرمجموعه‌ای از آن را ارائه می‌دهد و این دو باید همپوشانی داشته باشند.

دام Legacy_Auth

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

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

پیوستی را که اهمیت دارد بررسی کنید

روی نسخه‌ای که متغیر زمینه را فراهم می‌کند، این پرس‌وجو وضعیت رمزگذاری پیوست فعلی را گزارش می‌کند:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

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

نسخه کتابخانه کلاینت، نسخه سرور و نتیجه را با هم ثبت کنید، زیرا هیچ‌یک از آن‌ها به‌تنهایی خوانا نیست.

مجوزها و مسیر ارتقا

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

در پایان، استقرار بلندمدت را یک مسئله نگهداری بدانید. تونل یک کتابخانه کلاینت قدیمی را برای همیشه ایمن نمی‌کند و مسیر ارتقای پشتیبانی‌شده ارزان‌تر از کشف این است که افزونه مورد نیازش حذف شده است.