پاسخ کوتاه
کلید API و Secret را در کد منبع، Git، فایل قابل دانلود، برنامه سمت کاربر یا Log نگه ندارید. آنها را در Secret Manager یا Vault متمرکز، هنگام اجرا تزریق، برای هر سرویس و محیط جدا، با کمترین Scope و مدت لازم صادر کنید. Inventory، مالک و زمان انقضا داشته باشید؛ Rotation را با همپوشانی کوتاه کلید قدیم و جدید آزمایش کنید و برای رخداد، مسیر ابطال فوری، جایگزینی، جستوجوی محل افشا و بررسی Log تعریف کنید.
اول بدانید چه Secretهایی دارید و چه کسی مالک آنهاست
نوع و شناسه
- پرسش لازم
- API Key، Token، Client Secret یا Certificate؟
- ریسک نبودن
- رفتار یکسان با اعتبارنامههای متفاوت
مالک
- پرسش لازم
- چه تیمی میتواند تمدید یا ابطال کند؟
- ریسک نبودن
- توقف هنگام خروج فرد یا رخداد
مصرفکننده
- پرسش لازم
- کدام سرویس و محیط از آن استفاده میکند؟
- ریسک نبودن
- تعویض کور و خرابی وابستگی
Scope
- پرسش لازم
- به کدام عملیات و منبع دسترسی دارد؟
- ریسک نبودن
- دسترسی بیش از نیاز
چرخه عمر
- پرسش لازم
- چه زمانی ساخته، منقضی و چرخانده میشود؟
- ریسک نبودن
- اعتبارنامه فراموششده و بلندعمر
Secret را کجا ذخیره و چگونه مصرف کنیم؟
- در Production از Vault یا Secret Manager با کنترل دسترسی و Audit استفاده کنید.
- Secret را هنگام اجرا یا استقرار تزریق کنید؛ آن را داخل Image، Artifact یا کد Build نکنید.
- کلیدهای محیط توسعه، آزمایش و Production را کاملاً جدا نگه دارید.
- دسترسی خواندن Secret را فقط به Workload و افراد ضروری بدهید.
- مقدار Secret را در Log، Trace، خطا، Analytics و Ticket ماسک کنید.
- برای موبایل و مرورگر فرض کنید هر مقدار جاسازیشده قابل استخراج است؛ عملیات حساس باید سمت سرور انجام شود.
- در صورت پشتیبانی سرویس، Workload Identity یا اعتبارنامه کوتاهعمر را به Secret ثابت ترجیح دهید.
نکته: فایل محیطی میتواند برای توسعه محلی کنترلشده مفید باشد، اما نباید Commit شود و بهتنهایی جای Secret Manager، سیاست دسترسی و Audit در Production را نمیگیرد.
کلید را محدود کنید تا اثر نشت کوچک بماند
Scope
- تصمیم مناسب
- فقط عملیات و منابع لازم
- مثال ریسک
- کلید انتشار به حذف یا مدیریت حساب هم دسترسی دارد
محیط
- تصمیم مناسب
- کلید جدا برای Dev، Test و Production
- مثال ریسک
- نشت لپتاپ به Production راه میدهد
هویت
- تصمیم مناسب
- کلید جدا برای هر سرویس یا Pipeline
- مثال ریسک
- مشخص نیست کدام مصرفکننده عامل رخداد است
زمان
- تصمیم مناسب
- انقضا و Rotation متناسب با ریسک
- مثال ریسک
- کلید سالها پس از پایان پروژه معتبر میماند
شبکه و منبع
- تصمیم مناسب
- محدودیت IP یا Origin در صورت امکان
- مثال ریسک
- کلید از هر محل قابل سوءاستفاده است
Rotation را بدون توقف سرویس طراحی کنید
تعویض امن فقط تولید یک کلید جدید نیست. سامانه باید بتواند کلید جدید را دریافت کند، سلامت اتصال را بسنجد و سپس کلید قبلی را در بازه کوتاه و کنترلشده باطل کند.
- همه مصرفکنندگان و وابستگیهای کلید فعلی را از Inventory استخراج کنید.
- کلید جدید را با همان Scope لازم و نه بیشتر صادر کنید.
- آن را در Vault ثبت و نسخه استقرار را بدون افشای مقدار بهروز کنید.
- Health Check و عملیات واقعی کمخطر را با کلید جدید آزمایش کنید.
- مصرف کلید قدیم را در Log و Audit بررسی کنید.
- پس از پایان بازه همپوشانی، کلید قبلی را باطل و نتیجه را ثبت کنید.
- در صورت شکست، مسیر Rollback کوتاه و مسئول تصمیم مشخص داشته باشید.
اگر Secret افشا شد، Rotation برنامهریزیشده کافی نیست
- کلید را فوراً باطل یا دسترسی آن را محدود کنید و جایگزین امن بسازید.
- Repository، تاریخچه Git، Artifact، Log، Ticket و پیامرسان را برای محل افشا بررسی کنید.
- Audit Log سرویس مقصد را برای زمان، IP، عملیات و دسترسی غیرعادی تحلیل کنید.
- دامنه داده و سامانههای در معرض خطر را مشخص و Incident را مستند کنید.
- فقط حذف مقدار از آخرین Commit کافی نیست؛ کلید افشاشده باید نامعتبر شود.
- کنترل پیشگیرانه مانند Secret Scanning، Hook و محدودیت Scope را اصلاح کنید.
چکلیست قرارداد و تحویل مدیریت Secrets
- حساب سرویس، Vault و دامنه تحت مالکیت کارفرما باشد.
- Inventory بدون نمایش مقدار Secret تحویل شود.
- ماتریس دسترسی، مسئول تأیید و فرایند خروج افراد ثبت شود.
- روش استقرار، Rotation، ابطال اضطراری و بازیابی مستند باشد.
- کلیدهای توسعهدهنده و مجری پیش از پایان همکاری حذف یا تعویض شوند.
- تاریخ آخرین Rotation و برنامه بعدی برای کلیدهای باقیمانده مشخص باشد.
- Secret Scanning و جلوگیری از چاپ مقدار در CI و Log فعال باشد.
پرسشهای متداول
آیا Base64 یا رمزکردن مقدار در فایل تنظیمات کافی است؟
خیر. Base64 محرمانگی ایجاد نمیکند و رمزنگاری بدون مدیریت امن کلید فقط مسئله را جابهجا میکند. محل امن، هویت مصرفکننده، دسترسی و Audit باید با هم طراحی شوند.
هر چند وقت یکبار API Key را بچرخانیم؟
یک عدد ثابت برای همه مناسب نیست. حساسیت دسترسی، پشتیبانی سرویس از انقضا، امکان Automation و الزامات قراردادی را در نظر بگیرید؛ در رخداد یا تغییر مالک باید فوراً اقدام شود.
آیا کلید API را میتوان داخل اپ موبایل یا JavaScript گذاشت؟
برای دسترسی محرمانه خیر؛ کاربر میتواند مقدار جاسازیشده را استخراج کند. عملیات حساس را به Backend منتقل و برای Client از سازوکار محدود و قابل ابطال استفاده کنید.
Trusted Publishing در NuGet چه تفاوتی دارد؟
بهجای نگهداری API Key بلندعمر در CI، هویت Pipeline تأیید و یک API Key کوتاهعمر هنگام انتشار درخواست میشود. طبق مستند NuGet این کلید موقت یک ساعت اعتبار دارد.
خدمت و راهنماهای مرتبط
برای ادامه مسیر، صفحه خدمت مرتبط، نمونهکار و راهنماهای مکمل را ببینید.
منابع و مبنای تدوین
این راهنما با استفاده از مستندات فنی و منابع تخصصی زیر تدوین شده است. تصمیم نهایی هر پروژه باید با دادهها، قرارداد و شرایط واقعی همان سازمان تطبیق داده شود.