کلید API لو رفت؛ اول لغوش کنید، بعد تاریخچهٔ Git را پاک کنید

اگر کلید API افشا شده است، دسترسی کلید قدیمی را نزد سرویس صادرکننده هرچه زودتر قطع کنید. راهنمای secret scanning در GitHub چرخش فوری اعتبارنامهٔ افشاشده را توصیه می‌کند و می‌گوید حذف آن از تاریخچهٔ Git، پس از لغو کلید، کاری زمان‌بر و گاهی غیرضروری است. پاک‌کردن یک رشته از کد، نسخه‌ای را که دیگران دیده یا کپی کرده‌اند بی‌اعتبار نمی‌کند.

سپس کلید تازه را در محل امن استقرار قرار دهید، مسیرهای وابسته به آن را آزمایش کنید و مصرف و هزینه را از زمان احتمالی افشا بررسی کنید. اگر برای جلوگیری از وقفه باید کلید تازه پیش از لغو کلید قدیمی مستقر شود، فاصلهٔ فعال‌بودن کلید افشاشده را تا حد ممکن کوتاه نگه دارید. در افشای عمومی یا هنگام مشاهدهٔ مصرف مشکوک، قطع دسترسی قدیمی بر تداوم بی‌وقفهٔ سرویس اولویت دارد.

۱۵ دقیقهٔ نخست: کلید افشاشده را مهار کنید

هشدار را به اعتبارنامهٔ درست وصل کنید: نام سرویس صادرکننده، حساب یا پروژه، شناسهٔ کلید و برنامه‌هایی را که از آن استفاده می‌کنند مشخص کنید. مقدار کامل کلید را برای هماهنگی در پیام گروهی، تیکت یا گزارش حادثه کپی نکنید؛ شناسه و محل افشا برای ارجاع کافی است. اگر همان مقدار در چند محیط یا برنامه به کار رفته، همهٔ وابستگی‌ها را در فهرست جایگزینی بیاورید.

1. در پنل سرویس، کلید افشاشده را لغو یا غیرفعال کنید. اگر سرویس گزینه‌ای به نام «چرخش» دارد، بررسی کنید که مقدار قدیمی پس از اجرای آن دیگر درخواست مجاز ایجاد نکند.
2. به مسئول برنامه و استقرار اطلاع دهید کدام اعتبارنامه قطع شده است. خطاهای احراز هویتِ ناشی از لغو کلید باید سریع از نشانه‌های مصرف غیرمجاز جدا شوند.
3. زمان کشف، نخستین زمان محتمل افشا و زمان قطع دسترسی را ثبت کنید. این‌ها مرزهای بررسی گزارش درخواست‌ها و صورتحساب خواهند بود.

برای برنامه‌ای که امکان نگهداری هم‌زمان دو کلید دارد، می‌توان کلید جایگزین را ساخت و مسیر تولید را سریع به آن منتقل کرد، سپس کلید قدیمی را لغو کرد. این ترتیب فقط یک راه برای کاهش وقفه است و در طول جابه‌جایی، اعتبارنامهٔ لو‌رفته همچنان قابل استفاده می‌ماند. اگر نشانه‌ای از سوءاستفاده دیده‌اید یا کلید در دسترس عموم قرار گرفته، منتظر کامل‌شدن استقرار نمانید.

یک ساعت نخست: کلید تازه را مستقر کنید

کلید جایگزین را در حساب و پروژهٔ درست بسازید و فقط مجوزهای لازم برای همان برنامه را به آن بدهید، اگر صادرکننده چنین محدودیتی را پشتیبانی می‌کند. مقدار تازه را در سامانهٔ نگهداری اسرار یا تنظیمات امن استقرار وارد کنید؛ قراردادن آن در مخزن، تصویر برنامه، پیام‌رسان یا خروجی ثبت وقایع حادثهٔ دوم می‌سازد. اگر چند برنامه از کلید قبلی استفاده می‌کردند، برای هرکدام کلید جداگانه بسازید تا قطع دسترسی بعدی به همهٔ آن‌ها سرایت نکند.

پس از استقرار، از مسیر واقعی هر برنامه یک درخواست مجاز انجام دهید. کارگرهای پس‌زمینه، وظایف زمان‌بندی‌شده و نمونه‌هایی را که با تأخیر راه‌اندازی می‌شوند نیز در نظر بگیرید؛ موفقیت یک درخواست از یک نمونه نشان نمی‌دهد همهٔ مصرف‌کنندگان کلید تازه را گرفته‌اند. اگر پس از لغو کلید قدیمی خطای احراز هویت باقی ماند، محل مصرف مقدار قبلی را پیدا کنید و تنظیمات همان بخش را اصلاح کنید.

چرخش برنامه‌ریزی‌شده با پاسخ به افشای واقعی فرق دارد. در چرخش عادی می‌توان جایگزین را آزمایش کرد و بعد کلید پیشین را بست؛ در حادثه، هر دقیقهٔ فعال‌ماندن کلید قدیمی فرصتی برای استفاده از آن است. مدت هم‌پوشانی را بر پایهٔ دامنهٔ افشا و نشانه‌های مصرف تعیین کنید، نه صرفاً بر پایهٔ راحتی استقرار.

مصرف، گزارش درخواست‌ها و هزینه را بررسی کنید

بازهٔ بررسی از نخستین زمان محتمل افشا آغاز می‌شود، نه از لحظهٔ رسیدن هشدار. راهنمای ایمنی کلید API در OpenAI برای کلید مشکوک چرخش فوری، به‌روزرسانی برنامه‌های تولیدی و بازبینی مصرف حساب را توصیه می‌کند. چرخش، درخواست‌های بعدی با مقدار قدیمی را متوقف می‌کند؛ برای فهمیدن آنچه پیش از لغو رخ داده، باید داده‌های مصرف را جداگانه دید.

گزارش‌های موجود را بر اساس شناسهٔ کلید یا پروژه، زمان، حجم درخواست، مسیر API و خطاها با رفتار معمول برنامه مقایسه کنید. اگر سرویس مبدأ درخواست یا شناسهٔ درخواست را نشان می‌دهد، موارد ناآشنا را ثبت کنید و با استقرارها و بار کاری همان بازه تطبیق دهید. نبود جزئیات در گزارش، به‌تنهایی نشانهٔ نبود سوءاستفاده نیست؛ فقط دامنهٔ نتیجه‌گیری شما را محدود می‌کند.

مصرف ثبت‌شده را با صورتحساب، سهمیه و محدودیت هزینه مقایسه کنید. افزایش هزینه یا کاهش غیرعادی سهمیه نیاز به بررسی دارد، اما ممکن است با تغییر واقعی بار برنامه نیز توضیح داده شود. اگر کلید به داده یا عملیات حساس دسترسی داشته، تنها مبلغ را نسنجید: ببینید کدام مسیرها با مجوز آن قابل فراخوانی بوده‌اند و گزارش‌ها دربارهٔ استفاده از آن‌ها چه نشان می‌دهند. برای پیگیری با پشتیبانی سرویس، بازه و شناسه‌های درخواست را نگه دارید؛ خود کلید را ارسال نکنید.

پس از قطع دسترسی: رد کلید را در Git پیدا کنید

حذف کلید از نسخهٔ کنونی فایل، commitهای قدیمی را تغییر نمی‌دهد. شاخه‌ها و تاریخچهٔ مخزن را برای همان اعتبارنامه و اسرار مشابه بگردید و محل افشا را در کد کنونی اصلاح کنید. توضیح درخواست‌های ادغام، issueها و gistها نیز می‌توانند نسخه‌ای از مقدار محرمانه را نگه داشته باشند؛ هنگام ثبت یافته‌ها، مقدار کامل را دوباره منتشر نکنید.

بازنویسی تاریخچه را پس از لغو کلید و با هماهنگی مسئولان مخزن انجام دهید، اگر سیاست تیم، تعهدات نگهداری داده یا وجود اسرار فعال دیگر آن را لازم می‌کند. این کار می‌تواند کار همکارانی را که نسخهٔ قدیمی مخزن را دارند مختل کند و کپی‌های بیرون از مخزن اصلی را نیز به‌خودی‌خود پاک نمی‌کند. برای همان کلید، معیار فوری مهار حادثه بی‌اعتبارشدن مقدار قدیمی است؛ پاک‌سازی تاریخچه رسیدگی به رد باقی‌ماندهٔ افشاست.

روز بعد: مسیر افشا را ببندید

مشخص کنید کلید چگونه بیرون رفته است: کد برنامه، فایل تنظیمات، خروجی ثبت وقایع، برنامهٔ سمت کاربر یا URL. همان مسیر را اصلاح کنید و اسکن اسرار را روی شاخه‌ها و تغییرات بعدی فعال کنید. اگر اعتبارنامه در مرورگر یا برنامهٔ موبایل قرار گرفته بود، درخواست وابسته به آن را به بک‌اندی منتقل کنید که می‌تواند کلید را دور از کد قابل دریافت کاربر نگه دارد.

برای کلیدهای تازه، محدودیت‌های قابل پشتیبانی صادرکننده را اعمال کنید. راهنمای مدیریت کلید در Google Cloud محدودکردن کاربرد کلید، جداسازی کلیدها، چرخش دوره‌ای و پرهیز از فرستادن کلید Google API در پارامتر URL را توصیه می‌کند؛ برای آن سرویس، سربرگ HTTP یا کتابخانهٔ رسمی جایگزین معرفی شده است. محدودیت و روش انتقال را مطابق امکانات و قواعد همان ارائه‌دهنده انتخاب کنید.

در گزارش حادثه ثبت کنید کلید قدیمی چه زمانی لغو شد، جایگزین آن کجا مستقر شد و کدام بازهٔ مصرف و هزینه بررسی شد. اگر مورد مشکوکی باقی مانده، مسئول پیگیری و دادهٔ لازم برای بررسی بعدی را مشخص کنید. این ثبت کمک می‌کند خطای استقرار، هزینهٔ احتمالی و دسترسی احتمالی به داده هرکدام مسیر رسیدگی روشنی داشته باشند.

بیشتر بخوانید:

• Burn Multiple را درست حساب کنید؛ هر دلار رشد هزینهٔ یکسانی ندارد
• Turnstile را کامل نصب کنید؛ ویجت بدون Siteverify محافظت نمی‌کند
• نسخه‌بندی S3 بکاپ را مصون نمی‌کند؛ Object Lock را درست فعال کنید