مدیریت اسرار: ثبت نام، نه مقدار

تیم آرادتیم مهندسی

هر سامانه‌ای ده‌ها راز دارد: رشتهٔ اتصال پایگاه داده، کلید درگاه پرداخت، توکن سرویس پیامک، گواهی امضا، کلید دسترسی به سرویس‌های بیرونی.

سؤال این نیست که این‌ها را داشته باشید یا نه. این است که کجا زندگی می‌کنند و چه کسی می‌تواند ببیندشان.

کجا نباید باشند

فهرستی که بدیهی به نظر می‌رسد و در بازبینی‌های واقعی مدام نقض شده دیده می‌شود:

در مخزن کد. حتی در شاخهٔ قدیمی، حتی در کامیتی که بعداً برگشته. گیت فراموش نمی‌کند — رازی که یک بار کامیت شد، باید عوض شود نه اینکه کامیت بعدی حذفش کند.

در بستهٔ ساخت یا تصویر. رازی که در باینری یا تصویر باشد، به هر جایی که آن بسته می‌رود سفر می‌کند.

در مستندات. حتی به‌عنوان «نمونه». نمونه‌ها کپی می‌شوند.

در تیکت، ایمیل و پیام‌رسان. جایی که برای همیشه می‌ماند و دسترسی‌اش قابل کنترل نیست.

در آرگومان خط فرمان. این یکی کمتر شناخته شده و مهم است: فهرست کامل آرگومان‌های یک فرایند، برای هر کاربر دیگری روی همان ماشین قابل دیدن است.

و در فرانت‌اند. هر چیزی که به مرورگر یا اپلیکیشن برسد، عمومی است — همان اصلی که در امنیت سمت کاربر و امنیت اپلیکیشن موبایل گفتیم.

دفتر اسرار: نام‌ها، نه مقادیر

رویه‌ای که خودمان استفاده می‌کنیم و پیشنهادش می‌کنیم:

یک دفتر که فهرست کند چه رازهایی وجود دارند — و فقط نامشان را نگه دارد.

برای هر کلید، سه چیز ثبت می‌شود:

  • نام — دقیقاً همان‌طور که سامانه صدایش می‌زند
  • دامنه — به چه چیزی مربوط است و کدام محیط
  • جای مقدار واقعی — سامانهٔ مدیریت رمز، متغیر محافظت‌شدهٔ خط لوله، یا محل امن دیگر

مقدار، هرگز.

سه اثری که این تفکیک دارد و در عمل بسیار مفید است:

تحویل مستندات به مشتری هیچ‌وقت به‌معنای تحویل دسترسی نیست. می‌توانید کل دفتر را به تیم مقابل بدهید بدون اینکه چیزی لو برود.

می‌دانید چه چیزی باید چرخانده شود. وقتی کسی از تیم می‌رود یا نشتی مشکوکی رخ می‌دهد، فهرست کامل در دسترس است — و بدون این فهرست، همیشه یکی فراموش می‌شود.

و کلیدهای بی‌صاحب پیدا می‌شوند. رازهایی که هیچ‌کس نمی‌داند برای چه‌اند و سال‌هاست معتبر مانده‌اند.

پیکربندی در زمان استقرار، نه در زمان ساخت

تصمیم معماری‌ای که بیشترین تفاوت عملی را می‌سازد:

همان باینری باید بین محیط‌ها ارتقا پیدا کند. آنچه عوض می‌شود، پیکربندی است نه بسته.

دو نتیجه:

چیزی که تست کرده‌اید، همان چیزی است که منتشر می‌شود. اگر برای هر محیط ساخت جداگانه‌ای انجام دهید، آنچه روی محیط اصلی می‌رود دقیقاً همانی نیست که آزمایش شده.

چرخش کلید نیازی به ساخت مجدد ندارد. مقدار عوض می‌شود، سرویس دوباره راه‌اندازی می‌شود، تمام. اگر کلید در بسته باشد، چرخشش یعنی ساخت و انتشار کامل — و همان است که باعث می‌شود کلیدها سال‌ها چرخانده نشوند.

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

اجازهٔ دسترسی

کمترین دسترسی لازم. هر سرویس فقط رازهای خودش را ببیند، نه رازهای بقیه.

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

دسترسی افراد را ثبت کنید — چه کسی به چه چیزی دسترسی دارد. و این فهرست باید بخشی از فرایند خروج کارمند باشد، وگرنه همان اتفاقی می‌افتد که در ورود یکپارچه گفتیم: همیشه یکی فراموش می‌شود.

هنگام عیب‌یابی، خطر بیشتر می‌شود

نکته‌ای که کمتر گفته می‌شود: بیشتر نشت‌های واقعی هنگام رفع اشکال اتفاق می‌افتند، نه در حالت عادی.

کسی برای بررسی یک مشکل، خروجی یک دستور را کپی می‌کند و در تیکت می‌گذارد — و در آن خروجی، مقداری هست که نباید باشد.

سه قاعده که در تیم خودمان اجرا می‌کنیم:

دستورهایی که خروجی‌شان انبوه رمز است، اصلاً اجرا نمی‌شوند. به‌جایشان معادل محدود استفاده می‌شود — مثلاً فهرست نام متغیرها به‌جای مقادیرشان.

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

و خروجی پاک‌نشده، رخداد حساب می‌شود — نه یک بی‌دقتی کوچک. یعنی حذف می‌شود و بررسی می‌شود که آیا آن کلید باید چرخانده شود.

چرخش

رازی که هیچ‌وقت عوض نمی‌شود، رازی است که با گذشت زمان بیشتر آدم دیده‌اندش.

آنچه باید فوراً چرخانده شود: هر کلیدی که در جایی نامناسب دیده شده، و هر کلیدی که کسی با دسترسی به آن سازمان را ترک کرده.

آنچه باید دوره‌ای چرخانده شود: گواهی‌ها — که تاریخ انقضا دارند و فراموش‌شدنشان یکی از شایع‌ترین علل قطعی سرویس است. برای اینها یادآور بگذارید، نه حافظه.

چک‌لیست

  • هیچ مقدار حساسی در مخزن کد نیست — شامل تاریخچه
  • دفتر اسرار وجود دارد و فقط نام‌ها را نگه می‌دارد
  • پیکربندی در زمان استقرار تزریق می‌شود، نه در بسته
  • همان باینری بین محیط‌ها ارتقا می‌یابد
  • هر سرویس فقط رازهای خودش را می‌بیند
  • فهرست دسترسی افراد ثبت شده و در فرایند خروج هست
  • گواهی‌ها یادآور انقضا دارند
  • در محیط آزمایش، مقادیر واقعی تولید استفاده نمی‌شوند

بند آخر را جدی بگیرید. محیط آزمایش معمولاً حفاظت کمتری دارد و دسترسی بیشتری — و رازی که در هر دو یکی باشد، امنیت محیط اصلی را به سطح محیط آزمایش پایین می‌آورد.

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.