secret روی GitHub لو رفت: پاسخ به حادثه گام‌به‌گام

هشدار secret scanning آمده، همکار در چت نوشته «توکن را اشتباه push کردم»، یا رباتی از کلید شما سوءاستفاده کرده. در این لحظه اولویت «پاک کردن فایل از آخرین commit» نیست. اولویت قطع دسترسی مهاجم است. مستندات رسمی GitHub صریحاً می‌گوید اگر دادهٔ حساس یک secret است، اولین قدم revoke یا rotate است؛ بعد تازه دربارهٔ بازنویسی تاریخچه تصمیم بگیرید.

این مقاله runbook است: ترتیب کار، چه چیزی را ثبت کنید، کی تاریخچه را لمس کنید، و چرا force push تنها کافی نیست.

پاسخ کوتاه

۱) همان secret را فوراً باطل/چرخش دهید. ۲) دسترسی‌های وابسته و لاگ مصرف را بررسی کنید. ۳) دامنهٔ افشا را مشخص کنید (عمومی/خصوصی، fork، PR، Actions). ۴) از استفادهٔ مجدد همان مقدار جلوگیری کنید. ۵) فقط اگر سیاست و ریسک ایجاب کرد، با git-filter-repo تاریخچه را پاک و با هماهنگی force-push کنید و از Support برای پاک‌سازی کش/PR کمک بگیرید. ۶) کنترل پیشگیرانه را روشن کنید.

کلید زنده را بچرخانید؛ تاریخچهٔ تمیز بدون revoke امنیت نمی‌آورد.

دقیقهٔ صفر تا پانزده: مهار

1. نوع secret را شناسایی کنید: توکن GitHub، کلید ابر، DB password، webhook، private key.
2. در پنل صادرکننده revoke/rotate کنید؛ نسخهٔ جدید را فقط از کانال امن توزیع کنید.
3. اگر توکن GitHub بود، sessionها و SSH keyهای مشکوک را هم مرور کنید.
4. اگر کلید ابر بود، هزینه‌ها، ایجاد منبع جدید، و IAM را چک کنید.
5. کانال حادثه باز کنید: چه کسی، چه مخزن، چه SHA، چه زمان.

در همین مرحله، commit پاک‌سازی ظاهری بدون revoke فقط حس امنیت کاذب می‌دهد.

ارزیابی دامنه

طبق GitHub، حتی پس از بازنویسی محلی و push، داده ممکن است در کلون‌ها، forkها، مشاهدهٔ کش‌شده، و ارجاع PR باقی بماند.

اقدامات هم‌زمان روی مخزن

• دسترسی collaboratorها را مرور کنید؛ حساب مشکوک را حذف کنید.
• branch protection و قوانین force push را بشناسید قبل از هر rewrite.
• اگر workflow مخرب یا مشکوک اضافه شده، آن را متوقف و بررسی کنید.
• alertهای secret scanning را در تب Security دنبال و مستند کنید.

آیا باید تاریخچه را پاک کنید؟

GitHub تأکید می‌کند پس از revoke، بازنویسی تاریخچه ممکن است دیگر ارزش ریسک عملیاتی را نداشته باشد. بازنویسی side effect دارد:

• ریسک بازگشت secret با push کلون قدیمی.
• تغییر hash همهٔ commitهای بعدی و شکستن ابزار وابسته.
• نیاز به خاموش کردن موقت محدودیت force push.
• اثر روی PRها، امضای commit، و هماهنگی همهٔ کلون‌ها.

اگر secret هنوز در تاریخچه است ولی باطل شده، اولویت مستندسازی و پیشگیری است. اگر دادهٔ حساس غیرقابل‌چرخش (مثلاً دادهٔ شخصی مشتری) است، مسیر پاک‌سازی و هماهنگی با Support جدی‌تر می‌شود.

اگر تصمیم به پاک‌سازی تاریخچه گرفتید

مسیر توصیه‌شدهٔ فعلی GitHub استفاده از git-filter-repo با پرچم sensitive-data-removal است — نه دستورهای قدیمی filter-branch به‌عنوان پیش‌فرض آموزشی.

bash

# خلاصهٔ مفهومی مراحل رسمی — جزئیات را از Docs بخوانید git clone https://github.com/ORG/REPO cd REPO # حذف فایل از تمام تاریخچه: git-filter-repo --sensitive-data-removal --invert-paths --path PATH/TO/SECRET_FILE # یا جایگزینی متن‌ها از فایل passwords.txt: # git-filter-repo --sensitive-data-removal --replace-text ../passwords.txt git push --force --mirror origin

قبل از mirror push برگشت‌ناپذیر، تعداد PRهای متأثر را از خروجی filter-repo بررسی کنید. ممکن است موقتاً branch protection را شل کنید. سپس با همکاران هماهنگ کنید که کلون‌های آلوده را merge نکنند — merge می‌تواند تاریخچهٔ آلوده را برگرداند؛ باید rebase/بازکلون طبق راهنما انجام شود.

برای پاک شدن کامل از سمت GitHub (کش، ارجاع PR، GC)، طبق Docs باید از طریق GitHub Support درخواست دهید و اطلاعات مخزن، تعداد PR متأثر، و First Changed Commit را بفرستید. Support برای دادهٔ غیرحساس این کار را نمی‌کند و وقتی چرخش credential ریسک را کم کند ممکن است کمک حذف را لازم نداند.

چک‌لیست بعد از مهار

1. تأیید کنید secret قدیم هیچ‌جا کار نمی‌کند.
2. رمز جدید در همهٔ محیط‌ها (اپ، CI، همکاران) به‌روز شده.
3. علت ریشه‌ای: add بی‌دقت، نبود gitignore، نبود push protection، کپی در تست.
4. فعال‌سازی/بازبینی push protection و secret scanning.
5. آموزش کوتاه در تیم و به‌روزرسانی runbook.
6. ثبت زمان‌خط حادثه برای یادگیری.

آنچه نباید بکنید

• فقط delete کردن فایل در commit جدید و بستن تیکت.
• force push بدون هماهنگی روی شاخهٔ فعال تیم.
• fort کردن کلید جدید داخل همان PR عمومی با توضیح واضح مقدار.
• نادیده گرفتن forkها.
• فرض اینکه «مخزن خصوصی بود پس هیچ‌کس ندید».

نقش هشدارها و شریک‌های scanning

برای برخی انواع secret، GitHub با ارائه‌دهنده شریک است و ممکن است خود ارائه‌دهنده را مطلع کند. این کمک است نه جایگزین revoke توسط شما. validity checkها در طرح‌های پیشرفته کمک می‌کنند بفهمید کلید هنوز فعال است یا نه.

تمرین بدون بحران

در محیط آزمایشی یک‌بار سناریوی «توکن تست لو رفت» را با تیم مرور کنید: چه کسی revoke می‌کند، کانال اطلاع چیست، کی Security وارد می‌شود. اولین‌بار بودن این کار در production ساعت طلایی را می‌سوزاند.

خلاصه

پاسخ به نشت secret روی GitHub با مهار دسترسی شروع می‌شود، با ارزیابی دامنه ادامه می‌یابد، و فقط در صورت نیاز به پاک‌سازی تاریخچه با ابزار و هماهنگی رسمی می‌رسد. موفقیت یعنی کلید قدیم مرده، کلید جدید امن توزیع شده، و مسیر ورود دوباره بسته شده است.

سوالات متداول

commit را از تاریخچه پاک کردم؛ تمام شد؟

خیر تا revoke نشده و کپی‌ها و کش‌ها بررسی نشده‌اند.

آیا باید مخزن را خصوصی کنم؟

کاهش دید عمومی گاهی مفید است ولی جایگزین چرخش کلید نیست؛ پیامد تغییر visibility را از Docs بخوانید.

push protection بعد از حادثه چه کمکی می‌کند؟

از تکرار ورود secretهای شناخته‌شده جلوگیری می‌کند؛ برای گذشته کافی نیست.

منابع و مراجع

• GitHub Docs — Removing sensitive data from a repository: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
• GitHub Docs — About secret scanning: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
• GitHub Docs — Push protection: https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection
• GitHub Support portal: https://support.github.com/
• git-filter-repo project: https://github.com/newren/git-filter-repo