نفوذ به OpenCode هزینه ساخت؛ حذف کلید از Console کافی نیست

طبق گزارش TechCrunch، OpenCode در ۱۷ اکتبر ۲۰۲۶ اعلام کرد رخنه به سامانه‌ای قدیمی، ۱٫۴ درصد از کاربران OpenCode Console را تحت‌تأثیر قرار داده است؛ هم‌زمان کاربران از هشدار مصرف و هزینه‌های غیرمجاز در حساب ارائه‌دهندگان مدل خبر دادند و داکس راد، هم‌بنیان‌گذار OpenCode، دربارهٔ کلیدهای عامل محلی گفت: «those keys never come to us». کلیدهایی که برخی کاربران در فضای کاری Console ثبت کرده بودند ممکن است در معرض افشا قرار گرفته باشند.

برای دارندهٔ کلید مشکوک، اقدام فوری لغو آن در حساب صادرکننده، مانند OpenAI، Anthropic یا Google، و بررسی مصرف و صورت‌حساب همان حساب است. حذف اتصال از Console رابطهٔ فضای کاری با ارائه‌دهنده را تغییر می‌دهد؛ اگر نسخه‌ای از کلید پیش‌تر کپی شده باشد، حذف نسخهٔ ذخیره‌شده دسترسی دارندهٔ آن را قطع نمی‌کند. تشخیص اینکه کلید به Console سپرده شده بود یا فقط در عامل محلی استفاده می‌شد، دامنهٔ واکنش را تعیین می‌کند.

مرز رخنه: فضای کاری Console و کلید محلی

محور حادثه فضای کاری میزبانی‌شدهٔ Console است؛ کاربران می‌توانند اعتبار حساب ارائه‌دهنده را به آن بسپارند تا اعضای فضای کاری از مدل‌ها استفاده کنند. گزارش AI Primer میان این اعتبارهای ذخیره‌شده و کلیدهایی که کاربر مستقیماً با فرمان /connect در عامل محلی OpenCode وارد کرده است فرق می‌گذارد و به نقل از نگه‌دارندهٔ پروژه از آغاز بازپرداخت‌ها خبر می‌دهد. آغاز بازپرداخت‌ها به معنی تعیین تکلیف هزینهٔ همهٔ حساب‌ها نیست.

برای بررسی دامنه، محل ثبت کلید مهم‌تر از نام برنامه‌ای است که درخواست API را فرستاده است. کسی ممکن است عامل OpenCode را روی رایانه اجرا کرده باشد، اما کلید ارائه‌دهنده را در Console ذخیره نکرده باشد. در مقابل، اتصال عامل به فضای کاری Console که اعتبار ارائه‌دهنده در آن ثبت است، به معنای استفاده از همان اعتبار میزبانی‌شده است. اعلان رخنه یا سابقهٔ اتصال ارائه‌دهنده در فضای کاری، سرنخ مشخصی برای شناسایی کلیدهای نیازمند لغو است.

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

چرا Remove در Console جلوی صورت‌حساب را نمی‌گیرد؟

مستندات ارائه‌دهندگان Console می‌گوید این سرویس اعتبار ارائه‌دهنده را نگه می‌دارد و درخواست‌ها را از درگاه خود عبور می‌دهد، اما هزینهٔ توکن‌ها را ارائه‌دهنده از صاحب حساب می‌گیرد. در تنظیمات Console، گزینهٔ Disable ارائه‌دهنده و مدل‌هایش را از دسترس اعضا پنهان می‌کند و تنظیمات اتصال را نگه می‌دارد؛ گزینهٔ Remove اتصال و مدل‌هایش را از فضای کاری پاک می‌کند. این دو عمل در محدودهٔ Console انجام می‌شوند و دستور لغو کلید در حساب صادرکننده نیستند.

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

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

ترتیب واکنش برای کلیدهای در معرض خطر

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

1. کلید مشکوک را نزد ارائه‌دهنده لغو کنید. در پنل OpenAI، Anthropic یا Google وضعیت همان اعتبار را بررسی و آن را باطل یا غیرفعال کنید. اگر ارائه‌دهنده پیش‌تر کلید را مسدود کرده است، وضعیت را در حساب خود تأیید کنید. پاک‌کردن اتصال Console را جای این اقدام نگذارید.
2. وابستگی‌ها را با اعتبار تازه برقرار کنید. پس از لغو، برای سرویس‌هایی که هنوز به دسترسی نیاز دارند کلید تازه بسازید و تنظیماتشان را به‌روزرسانی کنید. اگر اعتبار قدیمی در برنامه‌ای بیرون از Console هم استفاده می‌شد، توقف آن برنامه تا زمان جایگزینی کلید قابل انتظار است.
3. مصرف و صورت‌حساب ارائه‌دهنده را مرور کنید. بازهٔ پیش از اخطار تا پس از لغو را با الگوی معمول درخواست‌های حساب مقایسه کنید. به زمان درخواست‌ها، پروژهٔ مرتبط، جهش مصرف و ردیف‌های هزینه توجه کنید؛ افزایش هزینه به‌تنهایی ثابت نمی‌کند کدام درخواست را چه کسی فرستاده است.
4. برای هزینهٔ مشکوک پروندهٔ قابل پیگیری بسازید. زمان‌ها، شناسهٔ پروژه یا کلید، جزئیات مصرف و ردیف‌های صورت‌حساب را حفظ کنید و از پشتیبانی ارائه‌دهنده بررسی بخواهید. همان اطلاعات را می‌توان برای پیگیری با OpenCode آماده کرد، اما خود کلید نباید در پیام یا تصویر ارسالی دیده شود.

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

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

• گفتار فارسی را دقیق‌تر متن کنید؛ WER به‌تنهایی کافی نیست
• حفرهٔ رمزنگاری S3 کلید پاکت را فاش می‌کند؛ راه میان‌بُر ندارد
• آمریکا و چین کانال بحران AI می‌سازند؛ هنوز تعریف «حادثه» روشن نیست