برنامه و دسترسی مدیریتی آن را ایمن کنید، شنونده بک‌اند را محدود کنید، کلیدهای سرویس onion را محافظت کنید و انتشار را از طریق یک کلاینت سازگار آزمایش کنید. مسیریابی onion یک لایه از طراحی است. این کار آسیب‌پذیری‌های برنامه، اشتباهات در محتوای منتشرشده یا نیاز به تعریف اینکه چه کسی باید دسترسی داشته باشد را از بین نمی‌برد.
انتشار و مخاطب آن را تعریف کنید
با یک هدف انتشار قانونی و توصیف مخاطب آغاز کنید. یک انتشار پژوهشی عمومی و یک درگاه پروژه محدود، الزامات دسترسی متفاوتی دارند. تصمیم بگیرید کدام محتوا قرار است عمومی باشد، کدام به احراز هویت برنامه نیاز دارد و کدام هرگز نباید به ریشه وب برسد. این تصمیم‌ها را از روش انتقالی که برای رسیدن به سایت استفاده می‌شود جدا نگه دارید.
پیش از استقرار، یک فهرست داده کوچک بنویسید: صفحات، بارگذاری‌ها، محتوای پایگاه داده، حساب‌های مدیر و پیکربندی سرویس. برای به‌روزرسانی‌ها و رسیدگی به رخدادها مسئولی تعیین کنید. اینکه یک سایت از نشانی onion استفاده می‌کند، تکلیف نگهداری، حقوق محتوا یا مسئولیت‌های امنیتی را روشن نمی‌کند. این‌ها تصمیم‌های عملی برنامه باقی می‌مانند که به یک برنامه عملیاتی صریح نیاز دارند.
شنونده بک‌اند را عامدانه نگه دارید
یک سرویس onion اتصال را به یک نقطه پایانی برنامه محلی نگاشت می‌کند. بررسی کنید که آن نقطه پایانی به کدام آدرس گوش می‌دهد و چه شبکه‌های دیگری می‌توانند به آن دسترسی داشته باشند. راهنمای راه‌اندازی پروژه Tor، سوکت‌های Unix را روشی مفید برای پرهیز از افشای بک‌اند به شبکه محلی معرفی می‌کند. رویکردی را انتخاب کنید که سرور شما از آن پشتیبانی می‌کند و دسترسی‌پذیری واقعی آن را بررسی کنید.
اتصالی که از طریق Tor کار می‌کند می‌تواند در کنار یک شنونده عمومی ناخواسته وجود داشته باشد. هم مسیر دسترسی مورد نظر و هم مرزهای پیرامون بک‌اند را آزمایش کنید. از فرض‌های پیکربندی عمومی بپرهیزید؛ تنظیمات شنود برنامه و مسیریابی میزبان مجازی وب‌سرور را بخوانید. رابط‌های مدیریتی را از سرویس عمومی مورد نظر جدا نگه دارید و محدود کنید چه کسی می‌تواند آن تنظیمات را تغییر دهد.
بررسی کنید برنامه چه چیزی منتشر می‌کند
صفحات، فایل‌های بارگذاری‌شده، خروجی خطا و منابع جاسازی‌شده را همان‌گونه که یک خواننده با آن‌ها روبه‌رو می‌شود بررسی کنید. یک برنامه می‌تواند از طریق پیام‌های اشکال‌زدایی جزئیات عملیاتی را آشکار کند یا بدون آنکه در طراحی اصلی‌اش آشکار باشد، به دارایی‌های خارجی پیوند دهد. نشانی‌های تولیدشده و فراداده محتوا را بررسی کنید. تنها منابعی را ارائه دهید که انتشار به آن‌ها نیاز دارد و هر درخواست شخص ثالثی را که آغاز می‌کند بشناسید.
برای یک سایت پژوهشی نمونه، پیش از راه‌اندازی یک مقاله، پیوست و صفحه تماس نمونه را بررسی کنید. تأیید کنید که یک سند تحریریه خصوصی و یک فایل محیطی بیرون از پوشه عمومی قرار دارند. هنگام بررسی بارگذاری‌ها از مواد آزمایشی غیرحساس استفاده کنید. یک اتصال موفق onion دسترسی‌پذیری را اثبات می‌کند؛ این بررسی محتوا مشخص می‌کند که سرویس واقعاً چه چیزی را به مخاطب خود افشا می‌کند.
هویت سرویس را به‌عنوان ماده محافظت‌شده در نظر بگیرید
پیکربندی سرویس onion شامل مواد کلیدی است که باید خصوصی بماند. آن را بیرون از فایل‌های عمومی وب‌سایت نگه دارید و دسترسی را به اپراتورهایی که به آن نیاز دارند محدود کنید. برنامه‌ریزی کنید که یک بازیابی مشروع چگونه هویت مورد نظر سرویس را حفظ می‌کند و در صورت نفوذ چگونه برخورد خواهد شد. کلیدهای سرویس را در یک آرشیو عمومی، پیام پشتیبانی یا مخزن پروژه اشتراکی قرار ندهید.
برنامه بازیابی را شامل برنامه، داده و پیکربندی سرویس مورد نیاز کنید و برای هر یک حفاظت مناسب در نظر بگیرید. پشتیبان‌گیری تنها از محتوای سایت ممکن است نشانی مورد نظر را بازیابی نکند، در حالی که نسخه‌ای حاوی کلیدهای خصوصی یک پشتیبان حساس ایجاد می‌کند. مستند کنید چه کسی می‌تواند آن را رمزگشایی و بازیابی کند و آن دسترسی را بدون افشای کلیدها در گزارش‌های تمرین آزمایش کنید.
دسترسی عمومی یا محدود را صریحاً انتخاب کنید
ورود به برنامه و مجوزدهی کلاینت Tor دو لایه متفاوت هستند. پروژه Tor مجوزدهی کلاینت را برای وابسته کردن دسترسی به یک سرویس onion v3 به یک اعتبارنامه کلاینت مستند می‌کند. تصمیم بگیرید که آیا این مدل با مخاطب و فرایند عملیاتی سازگار است. این برای یک انتشار عمومی به‌طور خودکار لازم نیست و پس از اتصال کلاینت، جایگزین مجوزهای برنامه نمی‌شود.
یک درگاه پروژه با یک گروه کوچک تأییدشده را در نظر بگیرید. به روشی برای توزیع، جایگزینی و لغو مواد دسترسی به‌صورت خصوصی نیاز دارید، و همچنین به مدیریت حساب‌های برنامه. حذف یک کلاینت مجاز و یک کاربر برنامه را جداگانه آزمایش کنید. جدول زیر این کنترل‌ها را متمایز نگه می‌دارد، به‌جای اینکه وعده دهد یک تنظیم همه مشکلات دسترسی را حل می‌کند.
| کنترل | پرسشی که پاسخ می‌دهد | مسئولیت جداگانه |
|---|---|---|
| شنونده بک‌اند | چه کسی می‌تواند به نقطه پایانی برنامه محلی دسترسی داشته باشد؟ | پیکربندی وب‌سرور و شبکه |
| مجوزدهی کلاینت | کدام کلاینت‌ها می‌توانند به سرویس onion متصل شوند؟ | توزیع و لغو اعتبارنامه خصوصی |
| مجوزهای برنامه | کاربر متصل چه کاری می‌تواند انجام دهد؟ | نقش‌های حساب و دسترسی به داده |
| بررسی انتشار | سایت چه چیزی را افشا می‌کند؟ | محتوا، بارگذاری‌ها و مدیریت خطا |
از طریق اتصال خواننده آزمایش کنید
با یک کلاینت سازگار، صفحات، پیمایش، فرم‌ها و دانلودها را از مسیر دسترسی onion مورد نظر آزمایش کنید. خطاها و مصرف منابع برنامه را با ترافیک آزمایشی بی‌خطر مشاهده کنید. از اندازه‌گیری تنها یک درخواست بک‌اند محلی بپرهیزید، زیرا اتصال کامل خواننده را تمرین نمی‌دهد. حساب‌های آزمایشی و هر اعتبارنامه دسترسی محدود را خصوصی نگه دارید.
رویه‌های بازیابی و نگهداری را نیز بررسی کنید. یک به‌روزرسانی برنامه باید نقطه بازگردانی و روشی برای اعتبارسنجی مسیر onion پس از آن داشته باشد. گزارش‌های عملیاتی مفید و مدت نگهداری را تعریف کنید، بدون آنکه فرض کنید یک برچسب توزیع یا انتقال، سیاست بدون گزارش ایجاد می‌کند. شواهد کافی برای تشخیص خطاها را حفظ کنید و در همان حال از جمع‌آوری غیرضروری بپرهیزید.
گزینه‌های میزبانی را به‌عنوان بخش‌هایی از طراحی بخوانید
SwissOctet Veil گزینه‌های پشته برنامه، نشانی onion و پشتیبان‌گیری را فهرست می‌کند. پشته‌ای را انتخاب کنید که نرم‌افزار شما انتظار دارد و CPU، حافظه و فضای ذخیره‌سازی کافی برای بار کاری را در نظر بگیرید. پیش از وابستگی به آن، تأیید کنید که سرویس واقعی چگونه استقرار، هویت سرویس و بازیابی را مدیریت می‌کند. موقعیت سوئیسی این فهرست از رفتار حریم خصوصی برنامه شما جداست.
سرویس را برای انتشار مشروع و کاربران مجاز نگه دارید. به‌روزرسانی‌های مدیر، بازبینی دسترسی‌ها و پاسخ به اعتبارنامه‌های برنامه در معرض خطر را برنامه‌ریزی کنید. یک انتشار onion زمانی بهتر کار می‌کند که محتوا، افشای بک‌اند و بازیابی قابل درک باشند؛ انتقال باید از آن برنامه پشتیبانی کند، نه اینکه بهانه‌ای برای نادیده گرفتن امنیت معمول نرم‌افزار شود.
چک‌لیست عملی شما.
- محتوای عمومی و محدود را پیش از استقرار تعریف کنید.
- افشای واقعی شنونده بک‌اند را بررسی کنید.
- صفحات، بارگذاری‌ها و درخواست‌های منابع خارجی را بررسی کنید.
- مواد کلید سرویس را محافظت و بازیابی آن را آزمایش کنید.
- مجوزدهی کلاینت را از نقش‌های برنامه جدا کنید.
- نگهداری و مسیرهای خواننده را از طریق مسیر onion آزمایش کنید.
جزئیاتی که اهمیت دارند.
آیا میزبانی onion به‌خودی‌خود یک برنامه را ناشناس می‌کند؟+
خیر. محتوای منتشرشده، پیکربندی، حساب‌ها و رویه‌های عملیاتی می‌توانند اطلاعات را آشکار کنند. کل سرویس را بررسی کنید، نه اینکه تنها به روش اتصال تکیه کنید.
آیا هر سایت onion باید از مجوزدهی کلاینت استفاده کند؟+
خیر. بر اساس مخاطب مورد نظر تصمیم بگیرید. مجوزدهی کلاینت دسترسی اتصال را محدود می‌کند و یک چرخه عمر اعتبارنامه اضافه می‌کند؛ مجوزهای برنامه جدا باقی می‌مانند.
در یک نسخه بازیابی باید از چه چیزی محافظت کنم؟+
داده‌های سایت و پیکربندی به کنترل‌های دسترسی مناسب نیاز دارند. هر ماده کلید سرویس موجود به‌ویژه حساس است و باید در طول ذخیره‌سازی و بازیابی خصوصی بماند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- پروژه Tor: سرویس onion خود را راه‌اندازی کنید community.torproject.org
- پروژه Tor: تنظیمات پیشرفته سرویس onion community.torproject.org
- پروژه Tor: مجوزدهی کلاینت community.torproject.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.