TLS، ورود شبکه و امتیازهای SQL به پرسش‌های متفاوتی پاسخ می‌دهند
رمزگذاری یک اتصال، پذیرش یک منبع و دادن یک جدول سه تصمیم است. پیش از پرسیدن اینکه آیا TLS می‌تواند جای VPN را بگیرد، آن‌ها را به ترتیب بگذرانید.
کسی پیشنهاد می‌دهد به یک مشتری ورود PostgreSQL داده شود تا یک درخواست هزینه به‌صورت رمزگذاری‌شده از ابتدا تا انتها منتقل شود. مدیر پایگاه داده به یک نشست واقعی SQL نیاز دارد و شخص دیگری در عوض یک فرم وب پیشنهاد می‌دهد. هر دو پیشنهاد مشکل نادرست را حل می‌کنند، زیرا هیچ‌کدام از عملیاتی که مشتری واقعاً انجام می‌دهد آغاز نشده است. سه تصمیم را به ترتیب بگذرانید و پرسش درباره اینکه آیا TLS می‌تواند جای VPN را بگیرد خودش پاسخ می‌گیرد.
از عملیاتی که مشتری به آن نیاز دارد آغاز کنید
بنویسید مشتری باید به چه چیزی برسد. ارسال یک درخواست، خواندن یک ردیف از یک گزارش و اجرای یک پرس‌وجوی موردی سه عملیات متفاوت با سه نمای ریسک متفاوت هستند.
سپس بنویسید چه کسی درخواست را می‌دهد. مشتری، نماینده پشتیبانی و مدیر حتی وقتی به یک جدول دست می‌زنند قابل جانشینی نیستند. این تفاوت تعیین می‌کند مشتری اصلاً چه مقدار از زبان پرس‌وجو را باید ببیند.
جفت پاسخ‌ها رابط را تعیین می‌کند. هر چیزی پس از آن پیاده‌سازی است و بیشتر بحث‌ها درباره رمزگذاری در واقع بحث درباره این است که کدام رابط انتخاب شده است.
سه کنترل، سه تصمیم
TLS احرازشده اتصال را محافظت می‌کند و تعیین می‌کند کدام هویت‌های TLS پذیرفته می‌شوند. ورود شبکه تعیین می‌کند کدام منابع اصلاً می‌توانند به شنونده برسند. مجوز پایگاه داده تعیین می‌کند یک نقش می‌تواند از کدام اشیا و کنش‌ها استفاده کند.
هیچ‌یک از این سه جای دیگری را نمی‌گیرد، که جدول آن را صریح نشان می‌دهد.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
پیش از حذف یک ردیف دیگر، ردیفی را که به آن تکیه می‌کنید بخوانید. بیشتر این طرح‌ها شکست می‌خورند چون کنترلی فرض شده است نه پیکربندی.
SQL مستقیم سیاست پایگاه داده را مسئول نگه می‌دارد
با یک اتصال مستقیم تأییدشده، هم تأیید هویت سرویس و هم سیاست دسترسی موردنظر را نگه دارید. روشن کردن TLS اتصال‌های رمزگذاری‌شده را فراهم می‌کند؛ اتصال‌های رمزگذاری‌نشده را رد نمی‌کند مگر اینکه پیکربندی دسترسی از طریق ورودی‌های hostssl آن را بخواهد.
این تفاوت را باید در پیکربندی در حال اجرا بررسی کرد نه در یک الگو. سروری که TLS ارائه می‌دهد و متن ساده را می‌پذیرد همان طرحی نیست که بیشتر مردم فکر می‌کنند مستقر کرده‌اند. قواعد دسترسی را بخوانید و ببینید کدام ورودی‌ها واقعاً آن را الزامی می‌کنند. همین یک بررسی سرور توانمند به رمزگذاری را از سرور فقط رمزگذاری‌شده جدا می‌کند.
از نقش‌هایی استفاده کنید که فقط امتیازهای لازم برای کار را دارند و مالکیت، عضویت ارثی و مجوزهای گسترده‌داده‌شده را بازبینی کنید. مدل امتیازهای PostgreSQL مرز اختیار برای اشیای پایگاه داده است.
VPN می‌تواند محدود کند کدام دستگاه‌ها پیش از احراز هویت پایگاه داده به سرویس می‌رسند و یک دروازه دسترسی می‌تواند کار مشابهی بکند. هیچ‌یک نیاز به نگهداری مؤلفه درمعرض‌قرار، مدیریت اعتبارنامه‌ها و محدود کردن مصرف منابع را برنمی‌دارد.
گواهی‌های مشتری یک اعتبارنامه است، نه ACL
یک گواهی مشتری می‌تواند در زمان اتصال شرطی بیفزاید. تنظیم clientcert می‌تواند گواهی مورداعتماد و در حالت سخت‌گیرانه‌تر رابطه میان نام گواهی و کاربر پایگاه داده را الزامی کند.
این اعتبارنامه قوی‌تری است. این یک فهرست مجوز نیست و سرور را نامرئی نمی‌کند، چون مؤلفه‌ای که اتصال را می‌پذیرد هنوز ترافیک شبکه و یک دست‌دادن را پردازش می‌کند. برخورد با گواهی به‌عنوان فهرست دسترسی مجوزهای واقعی را دست‌نخورده می‌گذارد. همچنین معمولاً توزیع گواهی را گسترده‌تر می‌کند که مشکل بعدی را می‌سازد.
گواهی قوی متصل به نقشی با امتیاز بیش‌ازحد مدیر خوب‌احرازشده‌ای تولید می‌کند. پیش از جشن گرفتن گواهی، نقش را بررسی کنید.
وقتی مناسب است رابط تنگ‌تر را انتخاب کنید
برای یک درخواست هزینه، یک نقطه پایانی برنامه‌ای که درخواست را می‌پذیرد، قواعد کسب‌وکار را اعمال می‌کند و نتیجه مجاز همان کاربر را برمی‌گرداند، عملیات را بهتر از یک حساب SQL عمومی نمایندگی می‌کند.
سپس برنامه از هویت محدود خود در پایگاه داده استفاده می‌کند و مشتری هرگز زبان پرس‌وجو را به‌عنوان یک ویژگی دریافت نمی‌کند. این سطحی کوچک‌تر با راه‌های کمتر برای اشتباه است.
این یک گزینه طراحی است نه ادعای اینکه کد برنامه به‌طور خودکار امن‌تر است. آن کد باید فراخوانندگان خود را احراز کند، هر کنش را مجاز کند و ورودی‌اش را اعتبارسنجی کند و مجوزهای خودش در پایگاه داده هنوز مهم‌اند.
SQL مستقیم برای کسانی که کار تأییدشده‌شان آن را می‌طلبد درست می‌ماند. آن طرح را با نقش‌ها، دامنه شبکه و محدودیت‌های عملیاتی مقید کنید و بگذارید دیگر مشتریان رابط تنگ‌تر را نگه دارند. آمیختن این دو جمعیت در یک نقش جایی است که بحث‌ها آغاز می‌شود.