آنچه باید بدانید
- OIDC بدون سیاست اعتماد دقیق و نقش محدود کافی نیست.
- کد تأییدنشده نباید با اختیار محیط اصلی اجرا شود.
- ورود مجاز و رد هویت غیرمجاز را پیش از حذف کلید قدیمی آزمایش کنید.
مرز امنیتی انتشار را بشناسید
کاری که سایت را منتشر می‌کند می‌تواند محیط اصلی را تغییر دهد، حتی اگر هیچ درخواست عمومی دریافت نکند. بنابراین خط انتشار بخشی از امنیت سرور است. این راهنما برای بررسی استقرارهای ۲۰۲۶ تهیه شده و ادعا نمی‌کند OIDC فناوری تازهٔ امسال است. ابتدا بنویسید کدام کار به مخزن بسته، زیرساخت، فایل‌های تولید یا اطلاعات مشتری دسترسی دارد.
جایگزینی محتاطانهٔ کلید دائمی
در سرویس‌های سازگار، OIDC گیت‌هاب هویت کار را با دسترسی کوتاه‌عمر ارائه‌دهندهٔ ابری مبادله می‌کند. بخش مهم، سیاست اعتماد سمت ارائه‌دهنده است: مخزن و زمینهٔ انتشار مشخص، مخاطب مورد انتظار و نقشی با عملیات ضروری. سیاستی با دامنهٔ بسیار باز می‌تواند فایدهٔ حذف کلید دائمی را از بین ببرد.
پیش از تغییر، یک آزمون مجاز و یک آزمون غیرمجاز تعریف کنید. مثلاً کار تأییدشده باید نقش انتشار آزمایشی را بگیرد و مخزن نامرتبط باید رد شود. این بررسی را با نقش و محیط آزمایشی انجام دهید. شکست بررسی اعتماد نباید باعث استفادهٔ خودکار از یک کلید دائمی با اختیار گسترده شود.
بررسی کد را از اجرای دارای اختیار جدا کنید
دسترسی پایهٔ گردش‌کار را فقط خواندنی بگذارید و اختیار بیشتر را فقط به کار لازم بدهید. انتشار اصلی به زمینهٔ محافظت‌شده و تأیید مشخص نیاز دارد. تغییر فایل‌های گردش‌کار نیز باید بررسی شود. مستندات گیت‌هاب و OWASP دربارهٔ اجرای کد غیرقابل‌اعتماد در کار دارای مجوز هشدار می‌دهند؛ مخصوصاً محرک‌های مرتبط با درخواست تغییر را دقیق بررسی کنید.
محیط Runner را جدا نگه دارید
Runner روی خود سرور تولید، مرز اعتماد دشواری ایجاد می‌کند. محیط ساخت جدا نباید فایل‌ها، سوکت‌ها یا اطلاعات ورود برنامهٔ اصلی را ببیند. اگر Runner شخصی ضروری است، گروه‌های اعتماد را جدا و پاک‌سازی یا جایگزینی بین اجراها را قابل اتکا کنید. کلید و خروجی کامل متغیرهای محیط را در لاگ ننویسید. نسخهٔ Action بیرونی را به شناسهٔ کامل کامیت بررسی‌شده متصل کنید و برای ارتقای بعدی فرآیند داشته باشید.
انتشار مرحله‌ای با مسیر بازگشت
- روش فعلی انتشار و بازیابی را همراه با مسئول انتشار اضطراری مستند کنید.
- هویت آزمایشی محدود بسازید و پذیرفته شدن و رد شدن موارد مورد انتظار را بررسی کنید.
- تغییر بی‌خطر را در محیط آزمایشی منتشر و بازگشت را تمرین کنید؛ لاگ باید مخزن و نقش درست را نشان دهد.
- در انتشار برنامه‌ریزی‌شده، سیاست اعتماد و تأیید محیط اصلی را فعال کنید.
- بعد از انتشار موفق، کلید جایگزین‌شده و نسخه‌های ذخیره‌شدهٔ آن را لغو کنید؛ مسیر بازیابی کنترل‌شده باقی بماند.
مدرک نتیجهٔ کار
کامیت گردش‌کار، تأییدکننده، شناسهٔ نقش و نتیجهٔ انتشار را نگه دارید. جابه‌جایی مخزن یا تغییر سیاست شاخه نیاز به بررسی دوباره دارد. ادامهٔ مسیر را در اولویت‌بندی هشدار وابستگی، تعویض اطلاعات محرمانه و خصوصی کردن پورت‌های Docker بخوانید.
منابع و مطالعهٔ بیشتر
گزارش این مطلب بر پایهٔ منابع اصلی زیر است. توصیه‌های اجرایی، راهنمای عمومی کیاوا هستند و باید با شرایط پروژه تطبیق داده شوند.
تجربهٔ شما، ادامهٔ این مطلب.
پرسشی دارید یا این راهنما را امتحان کرده‌اید؟ تجربه‌تان را بنویسید.
این گفت‌وگو با شما شروع می‌شود.
پرسش خوب یا تجربهٔ کوتاه شما می‌تواند به خوانندهٔ بعدی کمک کند.
گفت‌وگو 0
تازه‌ترین دیدگاه‌ها