نام کاربری VPN کجا از خط لوله گزارش ناپدید می‌شود؟
پیش از تغییر یک کنترل حریم خصوصی گزارش، رویداد دروازه، نسخه خام جمع‌آورنده، رویداد نمایه‌شده و فیلد هنگام جستجو را مقایسه کنید.
نشست‌ها در داشبورد نمایش داده می‌شوند در حالی که ستون نام کاربری خالی می‌ماند، و نخستین واکنش سرزنش تحلیلگر است. این واکنش سه مرحله پیشین را نادیده می‌گیرد که ممکن است مقدار در آن‌ها از دست رفته باشد. یک دروازه می‌تواند هویتی را بر پایه سیاست پنهان کند، یک قاعده ورود می‌تواند آن را پیش از نمایه‌سازی حذف کند، و یک استخراج هنگام جستجو می‌تواند به سادگی از نام بردن آن باز بماند. اصلاح به این بستگی دارد که کدام مرز را بتوانید مسئول اثبات کنید، پس کار سودمند مقایسه است نه پیکربندی.
از یک رویداد شروع کنید، نه از داشبورد
یک رویداد احراز هویت انتخاب کنید و بنویسید چه چیزی آن را مشخص می‌کند: مدل و نسخه دروازه، روش احراز هویت، شناسه رویداد، مهر زمانی و نشانی مبدأ. نام کاربری را دقیقاً همان‌گونه که شخص تایپ کرده است اضافه کنید، با حروف بزرگ و کوچک، زیرا جستجوی حساس به حروف می‌تواند فیلدی را که وجود دارد پنهان کند. آن رویداد را مرجع هر مقایسه بعدی بگیرید.
انواع رویداد یک طرح‌واره مشترک ندارند. یک تلاش ناموفق، یک ورود موفق بدون کارخواه و یک اتصال دوباره تونل می‌توانند هر یک فیلدهای متفاوتی تولید کنند، و برخی دروازه‌ها وقتی تلاش هرگز به احراز هویت کاربر نرسیده است هویت را حذف می‌کنند. بنابراین ستون خالی در یک نوع رویداد شواهد ضعیفی بر مشکل خط لوله است.
با یک هویت آزمون تأییدشده کار کنید نه با حساب واقعی کارمند، و مقایسه را درون قواعد دسترسی که از پیش بر داده‌های گزارش حاکم است نگه دارید. فعال کردن گسترده گزارش احراز هویت مفصل فقط برای گرفتن نمونه، سامانه‌ای را که می‌کوشید اندازه بگیرید تغییر می‌دهد.
چهار مرز را به ترتیب مقایسه کنید
مقدار می‌تواند در یکی از چهار نقطه ناپدید شود. هر نقطه صاحب متفاوتی و اصلاح متفاوتی دارد.
| Boundary | What to compare | A gap means |
|---|---|---|
| Gateway event view | The device's own event display and logging policy | The identity was masked or never emitted |
| Collector receive | The raw event as received, before parsing | Transport, filter or source selection dropped it |
| Index-time pipeline | Transforms applied before storage | Redaction or rewriting removed the value |
| Search-time extraction | The field name and regex used by the query | The label does not match the stored key |
در نخستین مرزی که مقدار ناپدید می‌شود توقف کنید. ناسازگاری میان نمای دستگاه و نسخه خام به انتقال یا پیکربندی جمع‌آورنده اشاره دارد؛ همخوانی در آنجا اما نبود مقدار در رویداد نمایه‌شده به یک تبدیل اشاره دارد؛ مقداری که در رویداد نمایه‌شده هست اما در داشبورد نیست به استخراج یا پرس‌وجو اشاره دارد.
این ترتیب اهمیت دارد زیرا هر مرحله بعدی تنها می‌تواند اطلاعات را از دست بدهد و هرگز آن را بازنمی‌گرداند. یک عبارت منظم نمی‌تواند رشته‌ای را که مرحله پیشین با یک نگهدارنده جایگزین کرده است بازیابد، و یک تنظیم حریم خصوصی نمی‌تواند مقداری را که هرگز فرستاده نشده توضیح دهد.
پنهان‌سازی در مبدأ سیاست است، نه اشکال تحلیلگر
مستندات گزارش‌گیری ASA از Cisco پنهان کردن نام کاربری را رفتاری قابل پیکربندی توصیف می‌کند، از جمله اینکه نام‌های کاربری نامعتبر یا ناشناخته چگونه نمایش داده می‌شوند. بنابراین هویت پنهان‌شده در رویداد مبدأ می‌تواند دقیقاً همان چیزی باشد که سیاست حریم خصوصی می‌خواهد، و برخورد با آن به عنوان خطای تجزیه به درخواستی می‌انجامد که کنترل را تضعیف می‌کند.
نمایش دقیق به نسخه و نوع پیام بستگی دارد. یک رویداد می‌تواند نگهدارنده داشته باشد، رویدادی دیگر می‌تواند فیلد را کاملاً حذف کند، و یک شکست احراز هویت ممکن است هرگز نامی نداشته باشد. رفتار مستندشده برای رویداد مشخص را بررسی کنید، نه اینکه یک گزارش اشکال قدیمی را به هر هویت گمشده تعمیم دهید.
وقتی پنهان‌سازی عمدی است، پرسش از چگونگی بازگرداندن فیلد به این تغییر می‌کند که آیا می‌توان الزام حسابرسی را به راه دیگری برآورد. شناسه‌های نشست، یک نگاشت هویت کنترل‌شده در دست گروهی کوچک‌تر، یا جریان رویداد مجاز محدودتر اغلب نیاز را برآورده می‌کنند بدون آنکه هر نام کاربری آزموده‌شده را پیش روی هر خواننده گزارش بگذارند.
ناشناس‌سازی پیش از نمایه‌سازی بازگشت‌ناپذیر است
مستندات Splunk درباره پردازش رویداد، ناشناس‌سازی را از طریق عبارت‌های sed و تبدیل‌هایی توصیف می‌کند که داده را پیش از نمایه‌سازی بازنویسی یا حذف می‌کنند. همین جایگاه نکته اصلی است: رویداد خام در مسیر ورود تغییر می‌کند، پس استخراج هنگام جستجو چیزی برای یافتن ندارد.
حذف هنگام نمایه‌سازی و استخراج فیلد هنگام جستجو دو مسئله متفاوت را حل می‌کنند. حذف محدود می‌کند که چه کسی هرگز مقدار را ببیند؛ استخراج فقط تعیین می‌کند پرس‌وجو از کدام نام استفاده کند. درهم‌سازی گزینه‌ای میانی است که همبستگی را حفظ می‌کند، اما یک درهم‌سازی پایدار روی فضای کوچک نام کاربری هنوز زمانی که کسی بتواند نام‌های نامزد را با آن بیازماید شناسایی‌کننده است.
اگر رویداد ذخیره‌شده هنوز هویت را دارد، مشکل در پایین‌دست است: نوع مبدأ، شکستن خط، مدیریت جداکننده، نام‌های مستعار فیلد یا خود پرس‌وجو. این‌ها اصلاح‌های عادی تجزیه‌اند و به مرز حریم خصوصی دست نمی‌زنند.
اصلاحی را برگزینید که با مرز هم‌خوان است
سه شرط پاسخ را تعیین می‌کند. نخست، آیا سیاست حریم خصوصی در پی کنار گذاشتن هویت است؟ دوم، آیا فرایند حسابرسی یا بررسی به هویت، به یک نام مستعار، یا فقط به نشست نیاز دارد؟ سوم، مقدار در کدام مرز لازم است — گردآوری، ذخیره‌سازی یا نمایش؟
اگر سیاست در پی کنار گذاشتن است، الزام یا نمایش را تغییر دهید، نه کنترل را. اگر سیاست هویت را مجاز می‌داند اما گردآوری آن را می‌اندازد، جمع‌آورنده را اصلاح کنید و رویداد خام را تأیید کنید. اگر ذخیره‌سازی سالم است، استخراج را اصلاح کنید و آن را با رویداد تأییدشده‌ای که در آغاز ثبت کردید بیازمایید.
بررسی را با نام بردن مرز در سابقه تغییر ببندید: پنهان‌شده در مبدأ، حذف‌شده هنگام ورود، یا از دست رفته در استخراج. همان یک جمله به مهندس بعدی می‌گوید نخست کجا را ببیند، و مانع می‌شود شکایت از داشبورد به یک ویژگی حریم خصوصی خاموش‌شده در سکوت تبدیل شود.