TruffleHog و تفاوت کشف با اعتبارسنجی
TruffleHog برای پیدا کردن اعتبارنامه‌های افشاشده در منابعی مانند مخزن کد و فایل طراحی شده است. امتیاز مهم آن تفکیک پیدا کردن یک رشته مشکوک از بررسی امکان استفاده از آن است. بسیاری از ابزارهای جست‌وجوی راز می‌گویند یک متن شبیه کلید دسترسی است؛ TruffleHog برای آشکارسازهای پشتیبانی‌شده می‌تواند با سرویس مربوط تماس بگیرد و وضعیت اعتبار را بررسی کند. این قابلیت کمک می‌کند تیم رسیدگی میان مثال آموزشی و اعتبارنامه زنده تمایز بهتری بگذارد، اما هم‌زمان نیاز به تعریف دقیق مجوز، محدوده شبکه و شیوه حفاظت از گزارش را بیشتر می‌کند.
مخزن رسمی پروژه منبع مناسب شناخت نسخه متن‌باز است. محصول تجاری TruffleHog Enterprise نیز وجود دارد و بعضی امکانات مدیریت سازمانی، رابط کاربری و اتصال‌ها به آن مربوط هستند. نباید فهرست تبلیغاتی محصول تجاری را بدون بررسی به ابزار خط فرمان نسبت داد. در انتخاب عملی، ابتدا نوع منابع مورد نیاز و دستورهای موجود در همان نسخه را تطبیق دهید. موضوع این راهنما طراحی استفاده از ابزار متن‌باز در بررسی مجاز دارایی‌های خود سازمان است، همراه با پیشنهادهای عملیاتی که باید متناسب با شرایط هر تیم تنظیم شوند.
سه وضعیت و یک خطای تفسیری مهم
مستندات پروژه برای نتیجه اعتبارسنجی سه وضعیت معرفی می‌کنند. وضعیت verified یعنی آزمایش پشتیبانی‌شده اعتبار را تأیید کرده است. وضعیت unverified یعنی اعتبار تأیید نشده؛ ممکن است مقدار نامعتبر یا منقضی باشد یا بررسی فعال خاموش بوده باشد. وضعیت unknown نشان می‌دهد تلاش برای بررسی به دلیل خطایی مانند مشکل شبکه یا سرویس نتیجه روشن نداده است. یک گزارش درست این سه گروه را جدا نگه می‌دارد. به‌خصوص unknown نباید به عنوان بی‌خطر کنار گذاشته شود، چون نبود پاسخ معتبر با نامعتبر بودن راز یکسان نیست.
اعتبارسنجی نیز ارزیابی کامل پیامد نیست. ممکن است یک کلید فعال باشد اما فقط به یک منبع کم‌اهمیت دسترسی داشته باشد؛ ممکن است اعتبارنامه‌ای غیرفعال شده باشد ولی در بازه گذشته برای دسترسی به داده حساس استفاده شده باشد. بنابراین ترتیب رسیدگی باید وضعیت اعتبار، سطح دسترسی، محل افشا و مدت در دسترس بودن را کنار هم ببیند. نتیجه ابزار یک ورودی مهم برای این تصمیم است، نه جایگزین بررسی مالک سرویس. در گزارش مدیریتی نیز بهتر است «راز فعال کشف‌شده» از «رخداد سوءاستفاده تأییدشده» جدا نوشته شود.
مرز مجوز و اثر بررسی فعال
بررسی فعال ممکن است درخواست واقعی به سامانه ارائه‌دهنده اعتبارنامه بفرستد. چنین درخواست‌هایی می‌توانند در گزارش‌های حساب ثبت شوند، محدودیت نرخ ایجاد کنند یا برای تیم دیگری هشدار بسازند. پیش از فعال کردن این حالت، مالک منبع و مالک حساب مقصد باید از محدوده کار آگاه باشند. داشتن اجازه خواندن یک مخزن به تنهایی همیشه به معنی اجازه آزمایش تمام اعتبارنامه‌های موجود در آن نیست؛ به‌ویژه وقتی مخزن شامل نمونه‌های مشتریان یا محتوای منتقل‌شده از شرکت دیگر است. برای این موارد ابتدا حالت بدون تأیید فعال و فرایند ارجاع مشخص مناسب‌تر است.
اگر سیاست سازمان خروجی شبکه را محدود می‌کند، این محدودیت باید در تفسیر گزارش منعکس شود. مسدود بودن اتصال ممکن است شمار وضعیت نامعلوم را بالا ببرد و این یک اشکال پوشش است، نه شاهد پاک بودن داده. پیشنهاد می‌شود اجرای کشف و اجرای تأیید در دو مرحله قابل کنترل طراحی شود. در مرحله اول سرنخ‌ها جمع‌آوری شوند و در مرحله دوم فقط موارد مجاز با دسترسی شبکه محدود بررسی شوند. این جداسازی امکان ثبت بهتر تصمیم و کاهش خروج ناخواسته داده را فراهم می‌کند، بدون آنکه کاربرد عملی ابزار از بین برود.
انتخاب منبع و دریافت داده
نسخه خط فرمان برای منابع مختلف زیردستورهای جدا دارد و گزینه‌های هر کدام در راهنمای همان دستور آمده است. بررسی یک پوشه محلی با بررسی یک مخزن گیت از نظر پوشش و زمینه نتیجه تفاوت دارد. در گیت می‌توان سابقه تغییر را دید؛ در پوشه فقط محتوای موجود قابل مشاهده است. اگر هدف بررسی بسته نهایی انتشار باشد، اسکن پوشه خروجی مفید است. اگر هدف رسیدگی به احتمال نشت قدیمی باشد، سابقه و شاخه‌های مرتبط اهمیت بیشتری دارند. نام منبع به تنهایی دامنه واقعی خوانده‌شده را توضیح نمی‌دهد.
برای سازمانی با مخازن متعدد، یک فهرست ورودی قابل حسابرسی بسازید. فهرست باید شامل مخزن، مالک، سطح محرمانگی، شاخه‌های مشمول و زمان آخرین بررسی موفق باشد. حسابی که داده را می‌خواند فقط مجوز لازم برای همین کار داشته باشد. خطای دسترسی به یک مخزن نباید بی‌صدا حذف شود و گزارش نهایی فقط منابع موفق را نشان دهد. بهتر است تعداد منابع درخواست‌شده، منابع بررسی‌شده و منابع ناموفق کنار تعداد یافته‌ها دیده شود. این اعداد تصویر روشنی از پوشش می‌دهند و مانع برداشت خوش‌بینانه از یک خروجی کم‌حجم می‌شوند.
نصب قابل تکرار و حفاظت از محیط
نسخه ابزار را از انتشارهای رسمی انتخاب کنید و روش نصب را در مستندات تیم ثبت کنید. ثابت نگه داشتن نسخه در خط ساخت کمک می‌کند تغییر رفتار آشکارسازها قابل توضیح باشد. محیط اجرا باید فضای موقت کنترل‌شده داشته باشد، زیرا برای تحلیل داده ممکن است محتوا دریافت یا استخراج شود. دسترسی کاربران دیگر به این فضا، ماندگاری فایل‌ها پس از پایان کار و نسخه‌های پشتیبان میزبان باید بررسی شوند. اسکنر اسرار معمولاً محتوایی را می‌بیند که نباید در یک ماشین عمومی یا مشترک بدون کنترل نگهداری شود.
در آزمایش اولیه از نمونه‌های ساختگی و محیط مخصوص آزمایش استفاده کنید. یک یافته قابل تشخیص، یک متن شبیه راز اما بی‌خطر و یک خطای شبکه عمدی به فهم رفتار ابزار کمک می‌کنند. همچنین بررسی کنید خروجی ساختاریافته چه فیلدهایی دارد و آیا مقدار خام در آن ثبت می‌شود. تنظیمات پوشاندن یا حذف داده باید پیش از اتصال گزارش به سامانه تیکت آزمایش شود. بسیاری از تیم‌ها روی حفاظت از مخزن تمرکز می‌کنند اما خروجی ابزار را در مسیر عمومی خط ساخت قرار می‌دهند؛ در آن حالت کنترل امنیتی به محل تازه انتشار اسرار تبدیل می‌شود.
رسیدگی مرحله‌ای به یافته‌ها
اولین اقدام پس از مشاهده یک اعتبارنامه فعال، پیدا کردن مسئول حساب و تعیین راه مهار است. در بعضی سرویس‌ها می‌توان کلید جایگزین ساخت، مصرف‌کنندگان را منتقل کرد و سپس کلید قبلی را لغو کرد. در موارد پرخطر ممکن است لغو فوری لازم باشد و توقف کوتاه سرویس پذیرفته شود. این تصمیم باید از قبل در برنامه پاسخ تعریف شده باشد تا تیم هنگام حادثه درباره مسئولیت‌ها بحث نکند. گزارش ابزار را به یک شناسه پیگیری متصل کنید و زمان مشاهده، اطلاع‌رسانی، تعویض و لغو را ثبت کنید.
بعد از مهار، بررسی استفاده غیرمنتظره اهمیت دارد. فعال بودن کلید هنگام اسکن ثابت نمی‌کند که مهاجم از آن استفاده کرده و نبود هشدار در گزارش سرویس نیز همیشه سوءاستفاده را رد نمی‌کند. بازه نگهداری گزارش، نوع رویداد ثبت‌شده و سطح دسترسی حساب تعیین می‌کنند چه نتیجه‌ای قابل دفاع است. اگر کلید امکان ساخت اعتبارنامه دیگر داشته، صرف لغو همان کلید ممکن است کافی نباشد. مالک سامانه باید تغییرهای حساس و دسترسی‌های وابسته را نیز بررسی کند. TruffleHog سرنخ شروع این فرایند است و جای تحلیل رخداد را پر نمی‌کند.
حذف تکرار بدون حذف شواهد
یک راز ممکن است در چند ثبت، چند شاخه یا چند فایل تکرار شده باشد. نمایش هر نمونه به صورت حادثه مستقل حجم کار را بیش از واقع نشان می‌دهد؛ ادغام همه موارد بدون نگه داشتن مکان‌ها نیز پاک‌سازی را ناقص می‌کند. طراحی مناسب آن است که یک پرونده برای اعتبارنامه یا مالک مربوط ایجاد شود و مکان‌های افشا به عنوان شواهد زیر آن نگهداری شوند. برای این کار از شناسه‌های امن استفاده کنید و مقدار کامل را در نام فایل یا عنوان تیکت نگذارید. حتی شناسه خلاصه‌شده باید متناسب با حساسیت داده انتخاب شود.
استثناهای دائمی برای فایل‌های آزمایشی باید با احتیاط استفاده شوند. یک پوشه که امروز فقط نمونه ساختگی دارد ممکن است فردا محل قرار گرفتن کلید واقعی شود. بهتر است استثنا تا جای ممکن به نمونه مشخص و دلیل قابل بررسی محدود باشد. در بازبینی دوره‌ای، تعدادی از موارد کنارگذاشته‌شده را دوباره بررسی کنید و مطمئن شوید تغییر ساختار مخزن پوشش را از بین نبرده است. همچنین باید راهی برای بازنگری یافته‌های قبلی وجود داشته باشد، چون اعتبارنامه‌ای که در یک زمان تأیید نشده ممکن است به علت محدودیت شبکه یا تنظیمات اشتباه درست بررسی نشده باشد.
اتصال به جریان توسعه
برای جلوگیری از ورود راز تازه، اجرای محدود روی تغییرهای پیشنهادی بازخورد سریع‌تری از اسکن کامل همه تاریخچه دارد. با این حال بررسی کامل اولیه و اجرای دوره‌ای باید باقی بمانند. ممکن است یک شاخه قدیمی دوباره فعال شود، یک منبع تازه به سازمان اضافه شود یا آشکارساز جدیدی اطلاعات قبلاً نادیده را پیدا کند. زمان‌بندی پیشنهادی باید بر اساس حجم داده و ظرفیت رسیدگی انتخاب شود. اجرای مداوم بدون مالک پاسخ فقط صف هشدار می‌سازد؛ اجرای کمتر اما با رسیدگی روشن در بسیاری از تیم‌های کوچک نتیجه بهتری دارد.
در سامانه ساخت، اعتبارنامه دسترسی خود اسکنر را از اعتبارنامه‌های برنامه جدا کنید. ابزار خواندن مخزن نباید به طور پیش‌فرض اجازه تغییر تولید داشته باشد. گزارش کامل را در محل محدود ذخیره کنید و برای توسعه‌دهنده فقط اطلاعات لازم برای اصلاح ارائه دهید. اگر یافته مانع ادغام می‌شود، پیام باید بگوید چگونه با مالک امنیت تماس بگیرد و از چه مسیر امنی جزئیات را ببیند. نشان دادن یک خطای مبهم یا مقدار خام در پیام عمومی هر دو انتخاب نامناسبی هستند. هدف، اصلاح سریع و قابل فهم با کمترین انتشار دوباره داده حساس است.
سنجش اثربخشی در سازمان
سه شاخص عملی برای دوره آزمایشی پیشنهاد می‌شود: پوشش منابع، زمان مهار اعتبارنامه فعال و سهم یافته‌های منجر به اقدام. تغییر هر شاخص باید توضیح داده شود. افزایش تعداد یافته ممکن است نتیجه اضافه شدن مخزن تازه باشد، نه بدتر شدن رفتار تیم. کاهش تعداد نیز ممکن است به دلیل خرابی اتصال یا حذف منبع باشد. کنار این شاخص‌ها، میزان موارد نامعلوم را جدا ببینید؛ اگر بخش بزرگی از بررسی‌ها نامعلوم است، نخست مشکل دسترسی یا شبکه را حل کنید و سپس درباره کیفیت تشخیص قضاوت کنید.
TruffleHog زمانی بیشترین ارزش را دارد که کشف، اعتبارسنجی مجاز و پاسخ به هم متصل باشند. برای تیمی که فقط جست‌وجوی کاملاً آفلاین می‌خواهد نیز باید گزینه‌ها و محدودیت‌های همان حالت بررسی شود. انتخاب بین نسخه متن‌باز و محصول سازمانی به نیاز مدیریت منابع، دسترسی کاربران و نگهداری عملیات بستگی دارد؛ نام مشترک به معنی یکسان بودن همه قابلیت‌ها نیست. نتیجه مطلوب یک فهرست طولانی راز نیست، بلکه کاهش زمان در معرض بودن اعتبارنامه و اصلاح روشی است که راز را وارد کد، گزارش یا فایل اشتراکی کرده است.
