Doconut Viewer به بخشی از مرز امنیتی برنامه شما تبدیل میشود به محض اینکه قراردادها، فاکتورها، نقشههای مهندسی یا سوابق مشتریان را نمایش دهد. Doconut لایه نمایش را فراهم میکند؛ اما برنامهٔ اطراف باید همچنان تصمیم بگیرد چه کسی میتواند فایلی را باز کند، منبع کجا ذخیره شده است، دادههای مشتقشده تا چه مدت در دسترس میمانند و چه چیزی برای بررسی ثبت میشود.
مقالهٔ Doconut دربارهٔ روشهای امن مشاهده سند رندر سمت سرور را به عنوان یک لایه در طراحی دفاع در عمق توصیف میکند. بنابراین این مقاله بر مسئولیتهای برنامه در رابطه با Doconut تمرکز دارد و جزئیات پیادهسازی را به مستندات محصول نگهداریشده ارجاع میدهد.
شروع با یک مدل تهدید
«خصوصی» و «امن» تنظیمات نیستند. قبل از انتخاب کنترلها، رویدادهایی را که باید از آنها جلوگیری یا شناسایی کنید، تعریف کنید.
| ریسک | مثال | کنترل برنامه |
|---|---|---|
| دسترسی غیرمجاز | کاربری شناسه سند را در URL تغییر میدهد | مجوزدهی سطح شیء در هر درخواست |
| عبور از میان مستأجران | کاربر معتبر فایلی از مشتری دیگر درخواست میکند | دامنه مستأجر در تصمیمگیری مجوزدهی گنجانده میشود |
| آشکار شدن منبع | مسیر ذخیرهسازی یا فایل اصلی بهصورت مستقیم برگردانده میشود | جستجوی کنترلشده توسط سرور و جریان رندر |
| دسترسی منقضیشده | یک لینک پس از تغییر نقش یا پرونده همچنان قابل استفاده است | عمر کوتاه جلسه بههمراه بازنگری مجوزدهی |
| نگهداری بیش از حد | ورودی یا خروجی موقت انباشته میشود | کارهای چرخهحیات صریح با نتایج قابل مشاهده |
| ثبتلاگ حساس | توکنها یا مکانهای فایل در لاگها ظاهر میشوند | حذف ساختاری و تلمتری فقط شامل شناسهها |
ریسکها را بر اساس اسناد و کاربران سیستم خود اولویتبندی کنید. یک کتابخانهٔ بروشور عمومی و یک پورتال شواهد قانونی نباید بهدلیل استفاده از یک نمایشگر یکسان، همان سیاست را به اشتراک بگذارند.
مورد استفادهٔ بررسی اسناد قانونی Doconut مرجع مفیدی برای نقش محصول در جریانهای کاری احراز هویتشدهٔ پرونده، قرارداد، شواهد و انطباق است. همچنین مرز معماری را تقویت میکند: مجوزها، ذخیرهسازی، سوابق مشتری و قوانین کسبوکار نزدیک به برنامهٔ میزبان میمانند.
قبل از باز کردن سند، مجوزدهی کنید
قبل از باز کردن سند با Doconut، احراز هویت و مجوزدهی سطح شیء را انجام دهید. راهنمای رسمی تنظیم .NET 6 یا بالاتر نشان میدهد که نمایشگر چگونه پیکربندی میشود و سند سمت سرور چگونه باز میشود؛ بررسیهای هویت برنامه، مستأجر و مجوز سند خود را قبل از آن گام محصول قرار دهید.
قانون مجوزدهی یکسان را برای هر عملیات مرتبطی که برنامه شما ارائه میدهد، از جمله صفحات، تصویرهای کوچک، جستجو، حاشیهنویسی، تبدیل، دانلود و چاپ تکرار کنید. مخفی کردن یک دکمه درخواست پایه را محافظت نمیکند.
از پذیرش مستقیم مسیر فایلسیستم، کلید ذخیرهسازی یا URL دور از مرورگر خودداری کنید. یک شناسه سند تحت مالکیت برنامه را به مکان ذخیرهسازی آن در سرور تبدیل کنید، سپس تأیید کنید که شیء حلشده به مستأجر و جریان کاری مجاز تعلق دارد.
جدا کردن نمایشگر از سیاست ذخیرهسازی
نمایشگر نباید دوره نگهداری شما را تعریف کند. هر کلاس ذخیرهسازی و مالک آن را مستند کنید:
- سند منبع — تحت کنترل سیاست اصلی محتوا یا سوابق شما.
- فایلهای کاری موقت — برای پردازش ایجاد میشوند و توسط یک چرخهحیات زمانبندیشده و قابل مشاهده حذف میشوند.
- صفحات یا کشهای رندر شده — به حداقل زمان مفید محدود شده و مانند منبع محافظت میشوند.
- خروجیها و فایلهای آماده چاپ — فقط زمانی ایجاد میشوند که کاربر مجوز مربوطه را داشته باشد.
- لاگها و رویدادهای حسابرسی — شامل شناسهها و نتایج هستند، نه محتوای سند یا اعتبارنامهها.
رمزنگاری در انتقال و در حالت استراحت به سرور وب، ارائهدهندهٔ ذخیرهسازی، مدیریت کلید و تنظیمات استقرار شما بستگی دارد. این کنترلها را در محیط واقعی تأیید کنید؛ از وجود یک کتابخانهٔ نمایشگر برای استنتاج آنها استفاده نکنید.
با دقت از مراجع کوتاهمدت استفاده کنید
یک مرجع کوتاهمدت میتواند زمان موجود برای بازپخش را کاهش دهد، اما جایگزین مجوزدهی نمیشود. اگر طراحی شما از مسیر امضاشده یا توکن جلسه استفاده میکند:
- آن را به یک سند و عملیات موردنظر متصل کنید.
- عمر محدودی بر اساس جریان کاری به آن بدهید.
- از قرار دادن ادعاهای حساس یا مکانهای ذخیرهسازی بهصورت متن واضح خودداری کنید.
- برای عملیاتهای ویژه، مجوزدهی را دوباره تأیید کنید.
- قبل از زمان انقضای طبیعی، تعریف کنید لغو به چه معناست.
- توکنها را از تجزیه و تحلیلها، ارجاعدهندگان، پیامهای استثنا و اسکرینشاتها دور نگه دارید.
زمانی که جلسه مرورگر منقضی شد، پیام خنثی نشان دهید و راهی امن برای احراز هویت مجدد ارائه کنید. فاش نکنید که آیا مستأجر دیگری مالک سند است یا نه.
درک کنید کنترلهای سمتکلاینت چه میتوانند و چه نمیتوانند انجام دهند
حذف کنترلهای دانلود یا چاپ میتواند جریان کاری موردنظر را بهبود بخشد، اما تضمین محرمانگی نیست. کاربری که میتواند محتوا را ببیند هنوز میتواند صفحه را ضبط کند، عکاسی کند یا از قابلیتهای مرورگر خارج از نمایشگر استفاده کند.
محدودیتهای سمتکلاینت را بهعنوان اقدامات قابلیت استفاده و بازدارندگی در نظر بگیرید. کنترلهای قویتر از نگه داشتن فایلهای منبع پشت سرور، اعمال مجوزدهی بر هر درخواست مرتبط، محدود کردن خروجیها و استفاده از واترمارکهای قابل مشاهده زمانی که سیاست شما اینرا میطلبد، حاصل میشوند.
ویژگیهای محصول را به ادعاهای انطباق تبدیل نکنید
انطباق مقرراتی به هدف، دستهبندیهای داده، پایه قانونی، قراردادها، پردازش منطقهای، نگهداری، پاسخ به حادثه و رویههای سازمانی بستگی دارد. یک نمایشگر میتواند از یک طراحی منطبق پشتیبانی کند، اما بهتنهایی برنامه را منطبق نمیسازد.
برای ارزیابی GDPR، حداقل موارد زیر را مستند کنید:
- مکان پردازش و ذخیرهسازی فایلهای منبع و مشتقشده
- چه کسی بهعنوان کنترلکننده و پردازشگر برای هر سرویس عمل میکند
- چه زیرپردازشگرها و انتقالهایی درگیر هستند
- چگونگی رسیدن درخواستهای حذف به هر کلاس ذخیرهسازی و سیاست پشتیبانگیری
- چه رویدادهایی لاگ میشوند و لاگها تا چه مدت در دسترس میمانند
- چگونگی انجام بازبینیهای دسترسی و پاسخ به حوادث
از ذینفعان حریمخصوصی و حقوقی بخواهید این تصمیمات را برای استقرار شما تأیید کنند.
افزودن هدرهای امنیتی و قوانین کش
برای مسیرهای پیشنمایش احراز هویتشده، یک سیاست امنیت محتوا (CSP) محدود، سیاست فریم، حفاظت در برابر تشخیص MIME و سیاست ارجاعدهنده را ارزیابی کنید. اگر پیشنمایش داخل یک iframe ظاهر میشود، مبدأهای والد موردنظر را بهصورت صریح مشخص کنید.
هدرهای کش را بر اساس حساسیت و مسیر رندر انتخاب کنید. no-store ممکن است برای برخی پاسخها مناسب باشد، اما میتواند بر عملکرد تأثیر بگذارد و محتوای قبلاً ضبطشده را پاک نمیکند. رفتار مرورگر، پراکسی و CDN را تست کنید بهجای تکیه بر یک هدر بهتنهایی.
تصمیمات را لاگ کنید، نه رازها
یک رویداد حسابرسی مفید ممکن است شامل موارد زیر باشد:
- شناسههای کاربر و مستأجر
- شناسه سند
- عملیات درخواستشده
- نتیجهٔ مجوزدهی
- زمانسنجی و شناسهٔ همبستگی
- نتیجهٔ نگهداری یا پاکسازی
از لاگ کردن توکنهای خام، رشتههای پرسوجو، URLهای ذخیرهسازی، نامهای سند حاوی دادههای شخصی یا متن استخراجشده خودداری کنید. لاگهای حسابرسی را از تغییر محافظت کنید و دسترسی را به تیمهایی که به آنها نیاز دارند محدود کنید.
جریان کامل را تأیید کنید
آزمونهای امنیتی باید شامل موارد منفی باشد:
- تغییر شناسه سند در حالی که احراز هویت باقی میماند.
- استفاده مجدد از URL پیشنمایش کاربر یا مستأجر دیگر.
- فراخوانی مستقیم نقاط انتهایی صفحه، تصویر کوچک، چاپ و خروجی.
- منقضی شدن جلسه در طول پیشنمایش طولانی.
- حذف مجوز کاربر در حالی که سند باز است.
- ارسال ورودیهای پشتیبانینشده، بزرگحجم، خراب یا دارای رمز عبور.
- تأیید اینکه کارهای پاکسازی دادههای واجد شرایط را حذف میکنند و خطاها را گزارش میدهند.
- بررسی لاگها، تجزیه و تحلیلها و صفحات خطا برای مقادیر حساس.
موارد پایدار را خودکار کنید و برای پیکربندی ذخیرهسازی، سیاست مرورگر و تغییرات نسخهٔ نمایشگر، بازبینی دستی را حفظ کنید.
نتیجهگیری
یک ادغام با امنیتمحور مالکیت واضحی دارد. Doconut قابلیت مشاهده سند را که در مستندات رسمی آن توصیف شده است، فراهم میکند؛ برنامهٔ شما احراز هویت، مجوزدهی، کنترلهای ذخیرهسازی، نگهداری، نظارت و پاسخ به حوادث را فراهم میکند. حفظ این مسئولیتها بهصورت صریح، کنترلهای قویتر و ادعاهای حریمخصوصی صادقانهتری ایجاد میکند.