نگهداری گزارش‌های VPN: آن را به حادثه گره بزنید، نه به یک عدد
نگهداری از حادثه، محتوا و خط‌مشی پیروی می‌کند، نه از یک مهلت جهانی. هر نسخه را پیدا کنید، جمع‌آوری مفصل را متوقف کنید و یک سابقه کوتاه نگه دارید.
هیچ‌کس واقعاً نمی‌پرسد یک گزارش VPN را چقدر باید نگه داشت؛ می‌پرسند گزارش به چه کار می‌آید، و پاسخ همان تاریخ را تعیین می‌کند. از یک حادثه می‌تواند دو فایل با عمرهای متفاوت بیرون بیاید، و برخورد با آن‌ها به‌عنوان یک خط‌مشی هم‌زمان نگهداری بیش‌ازحد و از دست رفتن شواهد را تولید می‌کند. یک برون‌بری اشکال‌زدایی که وقتی علت ناشناخته بود گرفته شده، همان اثری نیست که یک سطر در مخزن پایش است. از هدف شروع کنید، سپس تاریخ را انتخاب کنید.
پیش از انتخاب تاریخ به چهار پرسش پاسخ دهید
چهار پرسش تعیین می‌کند فایل می‌ماند یا نه: آیا حادثه هنوز باز است، فایل چه دارد، چه کسی باید آن را بخواند، و خط‌مشی قابل اعمال چه می‌خواهد. به همین ترتیب پاسخ دهید و تاریخ نگهداری خودبه‌خود به دست می‌آید. استدلال در یک جدول جا می‌شود:
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
تا وقتی حادثه باز است، یک نسخه اصل محافظت‌شده نگه دارید تا بعداً بتوانید رویدادها را مقایسه کنید یا به پرسش پشتیبانی پاسخ دهید، و به آن کتباً مالک و هدفی بدهید. برای هر کس بیرون از تیم واکنش، یک گزیده کوتاه پاک‌سازی‌شده معمولاً کافی است و دفاع از آن بسیار آسان‌تر از برون‌بری کامل است. اصل و گزیده دو اثر جدا با مخاطبان جدا هستند، و ادغام آن‌ها همان چیزی است که هم نگهداری بیش‌ازحد و هم از دست رفتن شواهد را می‌سازد. خط‌مشی یک کف تعیین می‌کند، پس اگر مدت بیشتری از استدلال شما بخواهد، خط‌مشی برنده است.
حادثه را با یک سابقه ببندید، نه با یک برون‌بری
در تیکت یک سابقه چهارسطری بنویسید: نشانه، کارخواه و نسخه، تنها سطر خطایی که آن را شناسایی کرد، و اصلاح. چیز دیگری پیوست نکنید، چون برون‌بری برای شما بود و سابقه برای نفر بعدی است.
احتمال خوانده شدن سابقه هم بیشتر است: برون‌بری کامل بیشتر به کار کسی می‌آید که آن را گرفته، و او از پیش می‌داند چه شده است. سابقه را جایی نگه دارید که حادثه بعدی در آن جست‌وجو می‌شود، که معمولاً یعنی تیکت و نه پوشه‌ای به نام یک تاریخ. شماره پرونده می‌تواند ارجاع را حمل کند اگر سابقه باید بدون افشای شناسه اتصال قابل ردیابی باشد. اگر پرسشی هنوز باز است، اصل تحت قاعده نسخه محافظت‌شده بالا می‌ماند؛ وقتی سابقه وجود دارد، بقیه چیزها می‌توانند بروند.
پیش از حذف یکی، هر نسخه را پیدا کنید
پوشه برون‌بری را ببینید، سپس دفتر رویداد پنجره حادثه، سپس پیوست‌های تیکت، سپس فهرست پشتیبان، سپس مخزن پایش. اگر همان شناسه اتصال در جای پنجم پیدا شود، فهرست‌برداری اشتباه بوده است. دفتر رویداد همان غافلگیری معمول است، چون وقتی برون‌بری را می‌خواندید همچنان جمع می‌کرد.
از مسیر چرخش و حذف پشتیبانی‌شده استفاده کنید، نه از جدا کردن دستی فایل‌ها. فایلی که هنوز باز است پس از ناپدید شدن ورودی دایرکتوری فضایش را نگه می‌دارد، پس حذف کامل به نظر می‌رسد و چیزی آزاد نمی‌کند. این یک اشکال ذخیره‌سازی با برچسب حریم خصوصی است و هیچ‌یک از دو هدف را برآورده نمی‌کند.
پیش از تأیید حذف، جمع‌آوری را متوقف کنید
جمع‌آوری موقت و مفصل را از طریق برنامه‌ای که صاحب آن است متوقف کنید، نه با ویرایش فایل خروجی آن. یک تنظیم اشکال‌زدایی فراموش‌شده پس از حذف سابقه‌های قدیمی همچنان سابقه جدید می‌نویسد، که بی‌صدا کاری را که همین حالا کردید باطل می‌کند. سطح واقعی ثبت وقایع را بررسی کنید، نه مقداری که به یاد دارید تنظیم کرده‌اید. سپس تأیید کنید که آنچه باقی مانده محافظت‌شده است و فقط افراد موردنظر می‌توانند آن را بازیابی کنند.
اصل، کمینه‌سازی داده است: آنچه را هدفی اعلام‌شده لازم دارد، تا زمانی که لازم دارد، و نه بیشتر نگه دارید، همان‌گونه که راهنمای حریم خصوصی RFC 6973 بیان می‌کند. فایلی که بدون هدف نگه داشته شود باری با برچسب زمان است. تصمیم زمانی تمام است که بتوانید فایل، هدفش، مالکش و تاریخ پایانش را نام ببرید.