مسئله‌ای که SOPS حل می‌کند
SOPS ابزاری برای ویرایش فایل‌های رمز‌شده است و قالب‌هایی مانند YAML، JSON و فایل‌های متنی تنظیمات را پشتیبانی می‌کند. روش‌های مختلف حفاظت کلید، از age و PGP تا سرویس‌های مدیریت کلید، در مستندات آن آمده است. هدف این است که فایل قابل نگهداری باشد، درحالی‌که خواندن محتوای حساس به اختیار رمزگشایی نیاز داشته باشد.
مدیریت گیرنده‌ها و تعویض کلید داده، بخشی از چرخه استفاده از ابزار است. این عملیات را نباید با تعویض رمز پایگاه داده یا ابطال یک توکن افشاشده برابر دانست. رمز‌شدن دوباره یک فایل، اعتبار راز قدیمی نزد سرویس مقصد را خودکار تغییر نمی‌دهد.
تمرین کم‌خطر پیشنهادی
یک فایل آزمایشی با داده کاملاً ساختگی بسازید؛ هیچ رمز واقعی را برای یادگیری وارد مخزن نکنید. دو هویت آزمایشی را مجاز کنید و بررسی کنید هرکدام چه چیزی را می‌توانند بخوانند. سپس یک گیرنده را از نسخه جدید حذف و نتیجه را ثبت کنید.
پرسش مهم این است که چه نسخه‌هایی قبلاً در اختیار آن گیرنده بوده‌اند. پیشنهاد ما این است که تاریخچه مخزن، فایل‌های خروجی و لاگ اجرای کار خودکار را بخشی از دامنه بررسی بدانید. کنترل دسترسی آینده، به‌تنهایی دانسته‌های قبلی یک گیرنده را پاک نمی‌کند.
مسیر رمزگشایی در CI
برای یک گردش کار فرضی، روی کاغذ مشخص کنید کلید یا هویت اجرا از کجا می‌آید، کدام مرحله به متن آشکار نیاز دارد و خروجی آن مرحله کجا می‌رود. هویت بازکردن فایل را کنار همان فایل در Git قرار ندهید. در عوض، مسیر تأمین هویت و محدوده اختیار آن را جدا طراحی و حسابرسی کنید.
در آزمون منفی، یک کار فاقد مجوز باید در مرحله مورد انتظار متوقف شود و نباید محتوای حساس را در پیام خطا چاپ کند. همچنین خروجی موقت و اثر آن در بسته نهایی را بررسی کنید؛ نباید فایل رمزگشایی‌شده ناخواسته وارد ایمیج عمومی شود.
واکنش به افشا
پیشنهاد تحریریه، داشتن رویه‌ای مستقل برای افشای واقعی است: تعیین دامنه، ابطال یا تعویض راز نزد سامانه مقصد، اصلاح دسترسی و بررسی استفاده غیرمجاز. ابزار رمزکردن فایل یک جزء مفید این معماری است، اما جای موجودی‌برداری اسرار، تعیین مالک و برنامه بازیابی دسترسی را نمی‌گیرد.
سه نوع راز را از هم جدا کنید
در کار با SOPS، مقدار محرمانه برنامه، کلید داده فایل و ابزار حفاظت از آن کلید نقش‌های متفاوت دارند. برنامه در نهایت به مقدار محرمانه نیاز دارد. فایل رمز‌شده شامل داده‌ای است که بدون امکان رمزگشایی قابل استفاده نیست. دسترسی به کلید یا خدمت مدیریت کلید تعیین می‌کند چه کسی می‌تواند آن مقدار را بازیابی کند. این مدل کمک می‌کند بفهمیم رمز کردن فایل در مخزن فقط یکی از مراحل حفاظت است. رایانه ویرایش‌کننده، فرایند ساخت و محیط اجرا در لحظه استفاده همچنان داده آشکار را می‌بینند.
فرض کنید تیمی رمز اتصال پایگاه داده را در فایل تنظیمات نگه می‌دارد. قرار دادن نسخه رمز‌شده در Git باعث می‌شود تاریخچه تغییرات قابل بازبینی باشد، بدون آنکه مقدار مستقیماً در متن مخزن دیده شود. اما اگر همان تیم کلید خصوصی رمزگشایی را نیز کنار فایل ثبت کند، مرز حفاظت از بین می‌رود. همچنین اگر فرایند استقرار مقدار را در گزارش چاپ کند، امنیت فایل مخزن کمکی به آن نشت نمی‌کند. طراحی باید از لحظه تولید راز تا مصرف و حذف آن را پوشش دهد.
اولین آزمایش را با مقدار ساختگی انجام دهید
یک فایل کوچک با دو مقدار غیرواقعی بسازید: نام خدمت و رمز نمونه. آن را با روش انتخابی رمز کنید و خروجی را بررسی کنید. ببینید کدام بخش‌ها برای ساختار و بازبینی قابل مشاهده مانده‌اند و کدام مقدارها رمز شده‌اند. سپس روی حساب مجاز رمزگشایی کنید و نتیجه را با ورودی مقایسه کنید. در مرحله بعد، از حسابی بدون کلید یا مجوز لازم همان کار را امتحان کنید و انتظار شکست داشته باشید. این آزمون منفی نشان می‌دهد کنترل دسترسی واقعاً در مسیر اجرا حضور دارد.
در این مرحله هنوز از راز تولید استفاده نکنید. پیام خطا، رفتار ویرایشگر، فایل موقت و خروجی استاندارد را مشاهده کنید. بعضی ابزارهای توسعه فایل پشتیبان یا تاریخچه محلی ایجاد می‌کنند. باید بدانید داده آشکار در کجا ممکن است باقی بماند. تنظیمات عمومی ویرایشگر و سامانه پشتیبان رایانه نیز بخشی از سطح حفاظت هستند. حذف فایل اصلی به تنهایی به معنی حذف همه نسخه‌های ساخته‌شده توسط ابزارهای دیگر نیست.
قواعد ایجاد فایل باید قابل بازبینی باشند
در یک مخزن چندمحیطی، فایل توسعه و تولید نباید بی‌دلیل گیرندگان یکسان داشته باشند. قواعد انتخاب کلید را بر اساس مسیر و نیاز دسترسی طراحی کنید و با چند نام فایل آزمایشی بسنجید. الگوی مسیر بیش از حد گسترده ممکن است فایل تولید را برای گروه توسعه قابل رمزگشایی کند. الگوی بیش از حد محدود نیز می‌تواند فایل تازه را بدون گیرنده درست بسازد. تغییر این قواعد باید مانند تغییر مجوزهای سامانه بازبینی شود، زیرا اثر آن صرفاً زیبایی تنظیمات نیست.
ایجاد قاعده تازه الزاماً همه فایل‌های قدیمی را تغییر نمی‌دهد. پس از تغییر گیرندگان، باید وضعیت فایل‌های موجود را بررسی و عملیات مناسب همان نسخه ابزار را اجرا کنید. یک فهرست از فایل‌های رمز‌شده و گروه‌های مجاز نگه دارید تا خروج عضو تیم یا تغییر نقش به فراموشی یک فایل قدیمی منجر نشود. آزمون از روی یک فایل نمونه کافی نیست؛ فایل‌های محیط‌ها و مسیرهای متفاوت ممکن است قواعد متفاوتی داشته باشند.
حذف گیرنده با بی‌اعتبار کردن راز تفاوت دارد
اگر کاربری قبلاً توانسته فایل را رمزگشایی کند، حذف دسترسی بعدی نمی‌تواند دانسته قبلی او را پاک کند. او ممکن است مقدار راز یا نسخه قدیمی فایل و کلید مربوط را داشته باشد. بنابراین در خروج عضو دارای دسترسی یا احتمال نشت، تنها تغییر فهرست گیرندگان کافی نیست. خود رمز برنامه، توکن یا گواهی باید در سامانه مصرف‌کننده تعویض شود. سپس نسخه تازه با مجوزهای مناسب رمز و منتشر شود. این ترتیب باید با تداوم خدمت هماهنگ باشد تا نسخه‌های در حال اجرا فرصت انتقال داشته باشند.
همچنین تعویض کلید داده فایل و تغییر گیرندگان دو عملیات مفهومی متفاوت‌اند. مستندات نسخه نصب‌شده را برای فرمان مناسب بخوانید و نتیجه را با فایل آزمایشی بررسی کنید. نام یک فرمان نباید مبنای فرض درباره تاریخچه دسترسی باشد. پس از هر تغییر، حساب جدید باید بتواند فایل لازم را بخواند و حساب حذف‌شده نباید بتواند نسخه جدید را با مسیرهای مجاز قبلی باز کند. این آزمون درباره نسخه جدید است و ادعایی درباره پاک شدن نسخه‌های قدیمی ایجاد نمی‌کند.
دسترسی خودکار در خط ساخت
فرایند خودکار باید فقط رازهای لازم برای همان محیط را دریافت کند. دادن کلید همه محیط‌ها به هر اجرای شاخه آزمایشی دامنه خطر را زیاد می‌کند. به ویژه کدی که از تغییرات بازبینی‌نشده اجرا می‌شود نباید به طور پیش‌فرض امکان رمزگشایی تولید داشته باشد. هویت اجرای خودکار، شرایط صدور مجوز و مقصد استفاده راز را مشخص کنید. اگر از خدمت مدیریت کلید استفاده می‌شود، گزارش دسترسی آن می‌تواند برای بررسی اینکه چه هویتی و چه زمانی رمزگشایی کرده مفید باشد.
در فرمان‌های پوسته، چاپ خودکار دستورات و محیط را با دقت کنترل کنید. ماسک کردن چند الگوی شناخته‌شده در گزارش تضمین نمی‌کند همه شکل‌های راز پنهان شوند. بهتر است راز اصلاً وارد خروجی قابل مشاهده نشود. برای تحویل به برنامه، از روش محدود به عمر همان فرایند یا فایل موقت با مجوز مناسب استفاده کنید و رفتار پاک‌سازی در شکست را هم آزمایش کنید. اگر ساخت در میانه کار متوقف شود، فایل آشکار نباید برای اجرای بعدی باقی بماند.
تعارض Git را روی داده رمز‌شده چگونه بررسی کنیم؟
دو نفر ممکن است همزمان بخش‌های متفاوت یک فایل را تغییر دهند. ترکیب دستی رشته‌های رمز‌شده بدون فهم ساختار می‌تواند فایل نامعتبر بسازد. روش ادغام باید با قابلیت ابزار و قالب فایل هماهنگ باشد. در محیط مجاز، نسخه‌های لازم را باز کنید، تغییر معنایی را بررسی کنید و نتیجه نهایی را دوباره به روش صحیح رمز کنید. پس از ادغام، رمزگشایی آزمایشی و اعتبارسنجی قالب را انجام دهید. سالم بودن نحو YAML به تنهایی اثبات نمی‌کند محتوای رمز‌شده قابل استفاده است.
بازبین نیز باید بداند چه چیزی تغییر کرده است. اگر فقط رشته‌های رمز‌شده متفاوت دیده می‌شوند، بررسی امنیتی ممکن است به تأیید کور تبدیل شود. توضیح تغییر باید بدون افشای مقدار، هدف را بیان کند؛ مثلاً تعویض حساب خدمت یا افزودن نشانی وابستگی. در صورت نیاز به مشاهده مقدار، این کار در مسیر محدود و ثبت‌شده انجام شود، نه در نظر عمومی درخواست ادغام. تاریخچه Git برای ردگیری مفید است، اما محلی برای بحث آشکار درباره رازهای تولید نیست.
بازیابی کلید و خرابی وابستگی
اگر تنها کلید خصوصی روی لپ‌تاپ یک نفر باشد، خرابی آن دستگاه می‌تواند استقرار و بازیابی را متوقف کند. روش نگهداری اضطراری باید از قبل طراحی و آزموده شود. در مقابل، تکثیر بی‌حساب کلید روی چند دستگاه کنترل دسترسی را ضعیف می‌کند. راه‌حل باید امکان بازیابی توسط افراد مجاز را با ثبت و محدودیت مناسب فراهم کند. تمرین کنید که یک اپراتور مجاز بدون دستگاه نویسنده فایل بتواند نسخه لازم را باز کند و سپس دسترسی اضطراری دوباره بسته شود.
در روش وابسته به خدمت مدیریت کلید، قطع شبکه یا اختلال هویت می‌تواند رمزگشایی را متوقف کند. خطای نبود مجوز را از خطای دسترسی شبکه جدا تشخیص دهید. افزایش مجوز برای رفع خطای ارتباطی نه لازم است و نه مفید. رفتار برنامه و فرایند استقرار هنگام در دسترس نبودن کلید باید روشن باشد. نسخه سالم در حال اجرا را صرفاً به دلیل شکست دریافت راز برای نسخه تازه متوقف نکنید، مگر آنکه سیاست خدمت چنین رفتاری را آگاهانه خواسته باشد.
معیار پذیرش یک گردش کار امن
در پایان، چهار آزمایش انجام دهید: فرد مجاز بتواند ویرایش کند، فرد غیرمجاز نتواند نسخه تازه را باز کند، اجرای خودکار فقط محیط لازم را بخواند و بازیابی اضطراری بدون افشای عمومی انجام شود. علاوه بر نتیجه، مسیر باقی ماندن داده آشکار را بررسی کنید. این آزمایش‌ها با مقدار ساختگی قابل انجام‌اند و خطر بی‌دلیل ندارند. مرجع تکمیلی برای قالب‌ها و روش‌های پشتیبانی‌شده، مستندات رسمی SOPS است؛ فرمان‌ها را با نسخه نصب‌شده تطبیق دهید. رمزنگاری فایل زمانی ارزش عملی دارد که دسترسی، چرخه تعویض و مصرف نهایی راز نیز به همان اندازه روشن باشند.
