مجله بلاگ
مدیریت Secret در DevOps؛ امن‌سازی کلیدها در CI/CD
مدیریت Secret در DevOps یعنی رمز عبور، API Key، Token، گواهی و کلید خصوصی از کد و تنظیمات عمومی جدا شوند و در تمام چرخه عمر تحت کنترل بمانند. قرارگرفتن یک کلید در Git حتی پس از حذف از آخرین Commit خطرناک است، زیرا نسخه آن در تاریخچه، Fork، کش Runner یا لاگ Pipeline باقی می‌ماند.
Secret کجا نشت می‌کند؟
- فایل‌های env و مخزن کد
- خروجی Debug و Artifactهای Pipeline
- Image کانتینر و لایه‌های Build
- متغیرهای مشترک میان چند محیط
- پیام‌رسان، تیکت یا مستندات تیمی
هدف فقط مخفی‌کردن مقدار نیست؛ باید بدانیم چه سرویس یا فردی، برای چه مدت و با چه مجوزی آن را مصرف می‌کند.
اصول معماری امن
خزانه مرکزی
Secretها را در سامانه‌ای با رمزنگاری، کنترل دسترسی، ثبت Audit و API مدیریت کنید. Pipeline باید مقدار را هنگام اجرا دریافت کند و آن را در فایل پایدار یا Image قرار ندهد.
هویت ماشین و دسترسی کوتاه‌عمر
به‌جای Token ثابت، Runner با هویت خودش احراز شود و Credential کوتاه‌عمر بگیرد. این الگو اثر سرقت کلید را کاهش می‌دهد و با رویکرد Zero Trust سازگار است.
تفکیک محیط‌ها
Development، Test و Production باید Secretهای جدا داشته باشند. دسترسی Pipeline تست به پایگاه داده تولید یک خطای معماری است. دامنه دسترسی هر کلید را به عملیات لازم محدود کنید.
چرخش و ابطال
هر Secret باید مالک، تاریخ ایجاد، تاریخ انقضا و روش چرخش داشته باشد. چرخش بدون قطعی معمولاً با هم‌پوشانی کوتاه دو کلید انجام می‌شود: کلید تازه توزیع، مصرف‌کننده‌ها منتقل و سپس کلید قبلی باطل می‌شود. فرایند را خودکار و قابل بازگشت طراحی کنید.
جلوگیری از نشت در Pipeline
- Secret Masking را فعال کنید، ولی آن را تنها لایه دفاع ندانید.
- دستورهای Shell پرجزئیات و چاپ متغیرها را محدود کنید.
- Runner تولید را اختصاصی و Ephemeral نگه دارید.
- Repository و Image را با Secret Scanner بررسی کنید.
- Artifactها و Cache را دوره‌ای پاک و دسترسی آن‌ها را محدود کنید.
مراحل پیاده‌سازی
- Secretهای موجود را در کد، سرورها و Pipeline کشف کنید.
- مالک و وابستگی هر مورد را ثبت کنید.
- خزانه مرکزی و سیاست دسترسی را راه‌اندازی کنید.
- ابتدا یک سرویس کم‌ریسک را مهاجرت دهید.
- چرخش خودکار و هشدار انقضا بسازید.
- اسکن پیش از Commit و در CI را اجباری کنید.
- Runbook نشت و ابطال اضطراری را تمرین کنید.
اگر کلید لو رفت چه کنیم؟
حذف Commit کافی نیست. کلید را فوری باطل یا Rotate کنید، لاگ مصرف را بررسی کنید، دسترسی‌های ایجادشده با آن را جست‌وجو کنید و تاریخچه مخزن و Artifactها را پاک‌سازی کنید. سپس علت ریشه‌ای و کنترل جلوگیری از تکرار را ثبت کنید.
مثال عملی
یک تیم برای Deploy از Token دائمی با دسترسی کامل استفاده می‌کرد. با انتقال Secret به Vault، تعریف هویت جدا برای هر Pipeline و صدور Token پانزده‌دقیقه‌ای، هم Audit دقیق شد و هم ریسک سوءاستفاده از Credential قدیمی کاهش یافت.
طبقه‌بندی Secretها پیش از مهاجرت
همه اطلاعات محرمانه ریسک یکسان ندارند. کلید امضای انتشار، Credential پایگاه داده تولید و Token مدیر زیرساخت باید در بالاترین سطح حفاظت باشند. رمز محیط آزمایش یا Token فقط‌خواندنی با دامنه محدود، سطح پایین‌تری دارد. طبقه‌بندی باعث می‌شود کنترل و هزینه متناسب باشد و تیم برای هر مقدار، فرایند پیچیده یکسانی نسازد.
| نوع Secret | نمونه | کنترل پیشنهادی |
|---|---|---|
| بحرانی | کلید امضا و حساب مدیر ابر | HSM یا Vault، تأیید چندنفره و Audit کامل |
| تولید | رمز پایگاه داده و API Key | دسترسی کوتاه‌عمر، چرخش خودکار و تفکیک محیط |
| غیرتولید | Credential آزمایش | Vault جدا، دامنه محدود و تاریخ انقضا |
| عمومی | شناسه بدون قابلیت احراز | ثبت در تنظیمات با بررسی عدم حساسیت |
انتخاب خزانه مناسب برای سازمان
خزانه Secret باید با زیرساخت، مهارت تیم و سطح دسترس‌پذیری هماهنگ باشد. سرویس‌های Cloud Provider برای محیط همان ابر یکپارچگی ساده‌ای دارند. سامانه‌های مستقل مانند Vault برای سازمان چندابری یا ترکیبی انعطاف بیشتری ایجاد می‌کنند. ابزارهای داخلی CI/CD نیز برای شروع مفیدند، اما ممکن است مدیریت متمرکز چند پلتفرم، چرخش پیچیده و صدور Credential پویا را کامل پوشش ندهند.
در ارزیابی راهکار، رمزنگاری در حالت ذخیره و انتقال، مدل احراز هویت ماشین، ثبت رخداد، نسخه پشتیبان، Replication، سیاست دسترسی، API، امکان Rotation و سناریوی بازیابی را بررسی کنید. خرابی Vault نباید تمام Deploymentهای ضروری را بدون برنامه جایگزین متوقف کند.
احراز هویت Pipeline بدون Secret ثابت
بهترین Secret آن است که اصلاً به‌صورت ثابت تولید نشود. در معماری‌های جدید، Runner با هویت Workload و یک Token کوتاه‌عمر به سرویس مقصد متصل می‌شود. نمونه‌ها شامل OIDC Federation، Managed Identity و نقش‌های موقت هستند. در این روش، یک کلید چندساله داخل تنظیمات CI باقی نمی‌ماند.
اعتماد میان CI و مقصد باید دقیق باشد: نام Repository، Branch مجاز، محیط Deployment و نوع Workflow محدود شوند. اعتماد گسترده به همه Repositoryهای یک سازمان، اثر آسیب‌دیدن یک پروژه را افزایش می‌دهد.
مدیریت Secret در Kubernetes
Secret داخلی Kubernetes به‌صورت پیش‌فرض راهکار کامل حفاظت نیست؛ مقدار Base64 رمزنگاری محسوب نمی‌شود. Encryption at Rest برای etcd، RBAC حداقلی، محدودیت دسترسی Service Account و Audit ضروری‌اند. برای محیط حساس می‌توان از External Secrets Operator یا CSI Driver استفاده کرد تا مقدار هنگام اجرا از Vault دریافت شود.
- Secret را داخل Manifest و Helm values عمومی قرار ندهید؛
- دسترسی خواندن همه Secretهای Namespace را به Service Account ندهید؛
- مقدار را در Environment Dump و صفحات عیب‌یابی نمایش ندهید؛
- Secretهای تولید و آزمایش را در Namespace و Vault جدا نگه دارید؛
- پس از خروج Pod، فایل یا Volume موقت را پاک‌سازی کنید.
Secret در کانتینر و فرایند Build
استفاده از ARG یا COPY برای ورود Secret به Dockerfile خطرناک است؛ مقدار ممکن است در History یا لایه Image باقی بماند. از قابلیت Secret Mount موتور Build استفاده کنید تا مقدار فقط در همان مرحله در دسترس باشد و در لایه خروجی ذخیره نشود. پس از ساخت نیز Image با Scanner بررسی شود.
Registry Credential باید فقط مجوز Push یا Pull لازم را داشته باشد. Runner ساخت نباید با همان حسابی کار کند که امکان حذف Image، تغییر Policy یا مدیریت کل Registry را دارد. مقاله Zero Trust در شبکه سازمانی اصل محدودسازی مداوم اعتماد را توضیح می‌دهد.
ثبت Audit بدون افشای مقدار
سامانه باید نشان دهد چه هویتی، در چه زمان، کدام Secret را برای چه عملیات دریافت کرده است؛ اما خود مقدار نباید وارد لاگ شود. لاگ‌ها را به مقصد مرکزی بفرستید و برای الگوهایی مانند درخواست خارج از ساعت، دریافت انبوه، خطای مکرر احراز هویت یا استفاده از موقعیت تازه هشدار بسازید.
دسترسی مدیر Vault نیز باید ثبت و بازبینی شود. داشتن نقش مدیریتی به معنی استفاده روزمره از آن نیست. برای عملیات حساس می‌توان تأیید دوم، نشست زمان‌دار و Break Glass ثبت‌شده تعریف کرد.
طراحی Rotation بدون قطعی سرویس
Rotation زمانی موفق است که سرویس بدون توقف به Credential تازه منتقل شود. الگوی معمول شامل ایجاد نسخه جدید، انتشار برای مصرف‌کننده‌ها، بررسی سلامت، غیرفعال‌سازی نسخه قبلی و حذف نهایی آن است. برنامه باید در برابر Rollback ناقص و مصرف‌کننده فراموش‌شده مقاوم باشد.
برای پایگاه داده می‌توان دو حساب یا دو Credential با دوره هم‌پوشانی کوتاه داشت. برای گواهی TLS باید تمدید، انتشار و Reload سرویس خودکار شود. تاریخ انقضا را پیش از بحران پایش کنید؛ هشدار روز آخر برای سامانه تولید دیر است.
مدیریت دسترسی انسان‌ها
توسعه‌دهنده معمولاً به مقدار Secret تولید نیاز ندارد. او باید بتواند Deployment را اجرا یا وضعیت آن را مشاهده کند، بدون اینکه کلید در اختیارش قرار گیرد. دسترسی اضطراری باید دلیل، تأیید، زمان انقضا و Audit داشته باشد. پس از پایان رخداد، Credential استفاده‌شده Rotate شود.
هنگام تغییر نقش یا پایان همکاری، عضویت گروه‌ها، Tokenهای شخصی، کلیدهای SSH و دسترسی به Vault باید فوری بازبینی شوند. اتصال مدیریت هویت و فرایند منابع انسانی، حساب‌های فراموش‌شده را کاهش می‌دهد.
نقشه راه ۳۰، ۶۰ و ۹۰ روزه
۳۰ روز اول: کشف و کاهش ریسک فوری
- Repositoryها، Pipelineها، فایل‌های تنظیمات و سرورها را اسکن کنید؛
- Secretهای افشاشده یا بدون مالک را Rotate کنید؛
- دسترسی تولید را از محیط‌های دیگر جدا کنید؛
- چاپ متغیرها و Artifactهای حساس را متوقف کنید؛
- مالک و تاریخ انقضا برای موارد بحرانی ثبت کنید.
روز ۳۱ تا ۶۰: استقرار خزانه و مهاجرت
- Vault یا سرویس مدیریت Secret را با HA و بکاپ راه‌اندازی کنید؛
- هویت Runnerها و سیاست دسترسی را تعریف کنید؛
- یک سرویس کم‌ریسک و سپس یک سرویس تولید را مهاجرت کنید؛
- Audit و هشدارهای اصلی را فعال کنید؛
- Runbook Rotation و ابطال اضطراری را بنویسید.
روز ۶۱ تا ۹۰: خودکارسازی و سنجش
- Credentialهای کوتاه‌عمر را جایگزین کلید ثابت کنید؛
- Rotation سرویس‌های پرتکرار را خودکار کنید؛
- اسکن Pre-commit، CI و Image را اجباری کنید؛
- سناریوی نشت را تمرین و زمان ابطال را اندازه بگیرید؛
- داشبورد KPI و بازبینی فصلی بسازید.
شاخص‌های سنجش بلوغ مدیریت Secret
- تعداد Secretهای بدون مالک یا تاریخ انقضا؛
- درصد Credentialهای تولیدشده به‌صورت کوتاه‌عمر؛
- میانگین زمان ابطال پس از گزارش نشت؛
- تعداد Secretهای یافت‌شده در Commit و Artifact؛
- درصد سرویس‌های دارای Rotation خودکار؛
- تعداد دسترسی‌های انسانی مستقیم به Secret تولید؛
- نرخ موفقیت آزمون بازیابی Vault.
مثال واقعی از اصلاح Pipeline
یک شرکت برای Deployment چند سرویس از فایل env مشترک استفاده می‌کرد. فایل در Runner دائمی ذخیره و Token آن دسترسی کامل به Registry و کلاستر تولید داشت. در طرح جدید، Runner به‌صورت Ephemeral ساخته شد، با OIDC یک نقش محدود پانزده‌دقیقه‌ای گرفت و Secret برنامه هنگام اجرا از Vault دریافت شد. دسترسی Pull و Push نیز از مدیریت Registry جدا شد.
در نتیجه، حذف یک Runner هیچ Credential ماندگاری باقی نگذاشت، هر درخواست در Audit به Repository و Job مشخص متصل شد و Rotation پایگاه داده بدون ویرایش دستی فایل‌ها انجام گرفت. تیم همچنین اسکن مخزن را به فرایند مدیریت آسیب‌پذیری و وصله متصل کرد.
پرسش‌های متداول
آیا متغیر محرمانه GitLab یا GitHub کافی است؟
برای محیط کوچک مفید است، اما سازمان‌های چندسامانه‌ای به چرخه عمر، چرخش و Audit متمرکز نیاز دارند.
Secret Scanner جایگزین Vault است؟
خیر. Scanner نشت را پیدا می‌کند؛ Vault نگهداری و دسترسی کنترل‌شده را فراهم می‌کند. هر دو لازم‌اند.
هر چند وقت یک‌بار Secretها Rotate شوند؟
بر اساس حساسیت، طول عمر و توان خودکارسازی تعیین می‌شود. Credential کوتاه‌عمر ممکن است در هر اجرا صادر شود؛ کلیدهای ثابت بحرانی باید برنامه چرخش و تاریخ انقضای روشن داشته باشند.
آیا حذف Secret از آخرین Commit مشکل را حل می‌کند؟
خیر. ابتدا آن را باطل کنید، زیرا ممکن است در تاریخچه Git، Fork، Cache یا Log باقی مانده باشد. سپس تاریخچه و نسخه‌های جانبی را پاک‌سازی کنید.
جمع‌بندی
مدیریت Secret در DevOps باید جزئی از طراحی Pipeline باشد. نصیر ارتباط می‌تواند خزانه، هویت ماشین، چرخش کلید و کنترل Pipeline را در چارچوب خدمات DevOps و برنامه مدیریت وصله و سخت‌سازی اجرا کند.