آیا گزارش VPN می‌تواند تاریخچه مرور را نشان دهد؟ شواهد چه چیزی را اثبات می‌کند
گزارش نشست، پرس‌وجوی مفسر و رکورد جریان چیزهای متفاوتی را اثبات می‌کنند. پرسش را انتخاب کنید، هویت و زمان را به هم بپیوندید و تنها آنچه نشان داده شده را بگویید.
دو پرسش ممیزی شبیه هم به نظر می‌رسند و به شواهدی از نوع متفاوت نیاز دارند. اینکه کدام نشست با این نشانی تماس گرفته است از رکوردهای اتصال و جریان پاسخ‌پذیر است. اینکه کدام شخص این صفحه را باز کرده است معمولاً نه، دست‌کم نه از آن رکوردها. انتخاب جمع‌آورنده پیش از انتخاب پرسش، همان راهی است که یک تیم شبکه در نهایت نام میزبان را به‌عنوان تاریخچه مرور ارائه می‌کند.
با رویدادی شروع کنید که ممیزی باید آن را اثبات کند
پرسش را به‌صورت جمله‌ای با فاعل، فعل و زمان بنویسید. همین نظم به‌تنهایی شکاف میان رکورد نشست و مشاهده صفحه را آشکار می‌کند. گزارش نشست اثبات می‌کند که هویتی برای بازه‌ای زمانی با نشانی تخصیص‌یافته تحت سیاستی ثبت‌شده پذیرفته شده است، و نمی‌تواند اثبات کند کدام صفحه را چه کسی خوانده، زیرا هرگز درخواست را ندیده است.
پیش از طراحی جمع‌آوری، مشاهده را نام‌گذاری کنید. فیلدی که به نام سایتی بازدیدشده نام گرفته اما در واقع نامی حل‌شده را ذخیره می‌کند، خطایی آینده است نه یک سهولت. نام فیلدها بیشتر از افرادی که آن‌ها را انتخاب کرده‌اند عمر می‌کنند، پس نام‌هایی برگزینید که شاهد را توصیف کنند نه نتیجه را.
هر رکورد چه چیزی را می‌تواند پشتیبانی کند و چه چیزی را نه
چهار نوع رکورد تقریباً در هر طراحی ممیزی دیده می‌شود و هر یک به پرسشی متفاوت پاسخ می‌دهد. آن‌ها را هم در گزارش و هم در خط پردازش جدا نگه دارید، زیرا آمیختنشان همان چیزی است که یافته‌ای قابل دفاع را شرم‌آور می‌کند.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
ستون آخر را به همان دقت ستون میانی بخوانید. رکورد جریان نشانی‌ها و درگاه‌ها را توصیف می‌کند، و جست‌وجوی معکوس یک نشانی نامی را که مرورگر به کار برده بازسازی نمی‌کند، زیرا یک نشانی می‌تواند میزبان سایت‌های بی‌ارتباط بسیاری باشد. پرس‌وجوی مفسر اثبات می‌کند که پرسشی پرسیده شده، نه اینکه صفحه‌ای نمایش داده شده است. نام میزبان قابل مشاهده در مذاکره TLS نیز مسیر رمزنگاری‌شده درخواست نیست.
هر یک از این‌ها مشاهده‌ای واقعی است و هیچ‌کدام آن مشاهده‌ای نیست که مردم فرض می‌کنند. مرورگری که بر مفسر رمزنگاری‌شده خودش پافشاری می‌کند بیرون از دامنه پایش‌شده می‌ایستد و تحلیل نمی‌تواند آنچه را ثبت هرگز ندیده بازیابی کند. این شکاف به‌عنوان محدودیتی اعلام‌شده به گزارش تعلق دارد، نه به‌عنوان پانویس.
جست‌وجوهای پیش‌دستانه و پاسخ‌های ذخیره‌شده
مرورگرها نام‌ها را پیش‌دستانه حل می‌کنند، گاهی بدون بارکردن هیچ چیز. آن‌ها همچنین از حافظه نهان پاسخ می‌دهند بدون فرستادن پرس‌وجوی تازه به مفسری که پایش می‌کنید، یعنی نبود پرس‌وجو نبود بازدید نیست. هر دو رفتار معادله ساده‌لوحانه میان گزارش DNS و تاریخچه مرور را می‌شکنند.
DNS روی HTTPS مرز دومی می‌افزاید: مرورگر یا برنامه مهمانی که مفسر خودش را دارد هرگز چیزی از ثبت‌کننده سازمان نمی‌پرسد. تراکنش‌های دقیق فقط از رویدادهای خود برنامه یا از پروکسی‌ای می‌آید که ثبت آن را صریحاً پشتیبانی می‌کنید. تونل ساده HTTPS CONNECT پروکسی را بدون هیچ دیدی به مسیرهای صفحه درونش رها می‌کند. مالک بودن شبکه اجازه جایگزینی خاموش مدل اعتماد برنامه نیست.
نشانی به یک نشست تعلق دارد، نه به یک شخص
رکورد جریانی که نشانی‌ای از محدوده تونل دارد نقطه آغاز است نه پاسخ. آن نشانی و برچسب زمان را با تخصیص نشستی که در آن لحظه فعال بود پیوند دهید، زیرا آن نشانی ممکن است یک ساعت بعد به نشست دیگری تخصیص یابد. نشانی‌دهی ایستا یکی از راه‌های حفظ این پیوند است و نه تنها راه.
جایی که گام ترجمه چند دستگاه را در بالادست حسگر به یک نشانی مبدأ فرو می‌کاهد، پیوند فقط می‌تواند نشست دروازه مشترک را نام ببرد. حساب مشترک یا گواهی‌ای که چند نفر از آن استفاده می‌کنند انتساب را محدود می‌کند، هرچند داده‌های شبکه کامل به نظر برسند. هر دو به‌عنوان محدودیت به گزارش تعلق دارند، نه به‌عنوان ملاحظات بعدی.
منطقه زمانی، منبع ساعت، نقطه مشاهده و هر مرز ترجمه در میان آن‌ها را ثبت کنید. غیاب همان توجهی را می‌طلبد که حضور، زیرا رکوردی که نیست می‌تواند یعنی یک ورودی جریان منقضی شده، حسگری هرگز بسته را ندیده یا گزارش برنامه‌ای خاموش بوده است.
برای هدف اعلام‌شده طراحی کنید، سپس خط پردازش را اثبات کنید
پس از تثبیت پرسش، تعریف کنید کدام فیلدها لازم است، چه کسی می‌تواند آن‌ها را بخواند و چه مدت نگه داشته می‌شوند. جمع‌آوری بیشتر به این دلیل که ذخیره‌سازی ارزان است، مسئولیتی می‌سازد که از تحقیق عمر بیشتری دارد. مدل حریم خصوصی در RFC 6973 همبستگی، انتساب نادرست و جمع‌آوری غیرضروری را مسئله طراحی می‌داند نه اندیشه پس از واقعه.
نگاشت و رکوردها را همچون یک شیء محافظت کنید، زیرا هر یک به‌تنهایی بسیار کم‌حساس‌تر از جفت است. سپس طراحی را در برابر فعالیتی که مجاز به تولیدش هستید و پیش‌تر می‌فهمید اعتبارسنجی کنید، با کوچک‌ترین پرس‌وجویی که گزارش بر آن تکیه خواهد کرد. خط پردازشی که نمی‌تواند رویدادی شناخته‌شده را بازتولید کند، رویدادی ناشناخته را هم بازتولید نخواهد کرد. رویدادی را که شواهد پشتیبانی می‌کند با واژه‌هایی که شواهد اجازه می‌دهد گزارش کنید و بگذارید خواننده خودش به نتیجه بزرگ‌تر برسد.
محدودیت‌ها را کنار یافته بنویسید: چه چیزی پیوند خورد، چه چیزی ترجمه شد و کدام گزارش خاموش ماند. یافته‌ای که مرزهای خود را اعلام می‌کند از بازبینی‌ای جان سالم به در می‌برد که خلاصه‌ای مطمئن از آن جان سالم به در نمی‌برد. تفاوت شاهد و داستانی درباره شاهد همین است.