تصویر کلی
GitHub از روش‌های مختلف برای امضای commit پشتیبانی می‌کند و وضعیت verification را کنار commit نمایش می‌دهد.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
امضا integrity و ارتباط با key را نشان می‌دهد اما به‌تنهایی امنیت account، review یا build artifact را تضمین نمی‌کند.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
برای supply chain بهتر است branch protection، review، CI provenance و مدیریت کلید در کنار signed commit استفاده شوند.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی GitHub Docs نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
دقیقاً چه چیزی امضا می‌شود؟
یک commit در Git فقط متن تفاوت فایل‌ها نیست؛ اطلاعاتی مانند درخت محتوا، والدها، نویسنده، ثبت‌کننده و پیام را در ساختار خود دارد. امضای commit به این شیء و محتوای مشخص آن مرتبط است. اگر تاریخچه بازنویسی شود و والد یا اطلاعات دیگر تغییر کند، شیء تازه‌ای ساخته می‌شود و نباید انتظار داشت امضای شیء قبلی خودبه‌خود برای آن معتبر بماند. این نکته دلیل اهمیت امضا پس از عملیات تغییر تاریخچه را روشن می‌کند.
امضا نشان می‌دهد دارنده کلید مشخص، داده امضاشده را تأیید کرده است؛ اینکه آن کلید به چه شخص یا سامانه‌ای اعتمادپذیر مرتبط است، مسئله دیگری است. نام و ایمیل در commit به تنهایی اثبات هویت نیستند و می‌توانند به صورت متن تنظیم شوند. رابطه کلید و هویت باید از مسیر مورد اعتماد برقرار شود. همچنین امضا نمی‌گوید نویسنده همه خط‌ها را شخصاً نوشته یا کد بی‌نقص است؛ این ادعاها به بررسی و شواهد دیگری نیاز دارند.
کلید ورود SSH با کلید امضای Git یکی نیست
ممکن است برای ورود به میزبان کد از کلید SSH استفاده کنید و برای امضا نیز روش SSH را انتخاب کنید، اما کاربرد این دو عملیات متفاوت است. احراز هویت اتصال تعیین می‌کند چه کسی اجازه ارسال داده به میزبان را دارد؛ امضای commit یک مدرک قابل بررسی روی خود شیء ایجاد می‌کند. موفقیت push به معنای امضاشده بودن commit نیست. در سوی دیگر، commit امضاشده می‌تواند پیش از هر اتصال شبکه‌ای به صورت محلی ساخته شود.
برای کاهش ابهام، فهرست کنید هر کلید چه کاربردی دارد و در کدام سامانه ثبت شده است. جدا کردن کلیدهای کاربردهای حساس می‌تواند لغو و بررسی حادثه را ساده‌تر کند، ولی روش مناسب به سیاست تیم و امکانات نگهداری کلید وابسته است. مهم این است که تغییر یک کلید به صورت ناخواسته همه مسیرها را مختل نکند و مدیر بداند برای پایان همکاری چه ثبت‌هایی باید حذف یا لغو شوند. نام‌گذاری روشن کلیدها در این کار کمک می‌کند.
انتخاب روش امضا و تنظیم محلی
GitHub امکان استفاده از روش‌هایی مانند GPG، SSH و S/MIME را در جریان تأیید امضا پشتیبانی می‌کند، اما پیش‌نیازهای محلی و رابطه اعتماد آنها متفاوت است. روش را بر اساس ابزارهای تیم، نگهداری کلید و شیوه اعتبارسنجی انتخاب کنید. نصب ابزار رمزنگاری به تنهایی کافی نیست؛ Git باید بداند از چه روش و کدام کلید استفاده کند. همچنین تنظیم مخزن محلی ممکن است تنظیم عمومی کاربر را تغییر دهد و نتیجه در دو پروژه متفاوت باشد.
پس از پیکربندی، یک commit آزمایشی در مخزن غیرحساس بسازید و امضای آن را محلی بررسی کنید. سپس همان commit را به میزبان مورد نظر بفرستید و وضعیت نمایش‌داده‌شده را ببینید. تفاوت میان بررسی محلی و وضعیت میزبان می‌تواند از ثبت نبودن کلید یا ناسازگاری اطلاعات هویت ناشی شود. مشکل را با انتشار کلید خصوصی حل نکنید؛ برای ارتباط هویت، بخش عمومی و تنظیم درست لازم است، نه واگذاری راز امضا.
چرا نشان تأیید کافی نیست؟
نشان تأیید در رابط میزبان درباره قواعد همان سامانه برای امضا و هویت اطلاعات می‌دهد. آن را گواهی کیفیت کد یا مجوز ادغام تلقی نکنید. یک تغییر مخرب هم می‌تواند توسط کلید معتبر امضا شده باشد، به‌ویژه اگر حساب یا دستگاه صاحب کلید آسیب دیده باشد. بررسی انسانی، آزمون، حفاظت شاخه و کنترل انتشار همچنان لازم‌اند. امضا یک لایه شواهد است که به این کنترل‌ها اضافه می‌شود و جای آنها را پر نمی‌کند.
همچنین باید میان وضعیت تاریخی امضا و وضعیت فعلی اعتماد به کلید تفاوت بگذارید. رفتار میزبان‌ها در نگهداری نتیجه تأیید، لغو کلید و نمایش امضاهای قدیمی می‌تواند متفاوت باشد. برای سیاست سازمانی، مستندات همان میزبان را بخوانید و صرفاً از رنگ نشان در یک صفحه نتیجه عمومی نگیرید. در حادثه افشای کلید، بازه زمانی احتمالی سوءاستفاده و commitهای مربوط را بررسی کنید؛ حذف کلید به تنهایی پاسخ کامل به مسئله محتوای قبلاً منتشرشده نیست.
Rebase، cherry-pick و ادغام
عملیات بازنویسی تاریخچه می‌تواند commitهای تازه بسازد. اگر تیم الزام امضا دارد، جریان rebase و cherry-pick را با همان الزام آزمایش کنید. انتقال تغییر یک commit به والد جدید، همان شیء قبلی را حفظ نمی‌کند. بنابراین قبل از ادغام، وضعیت امضاهای نهایی روی شاخه مقصد را بررسی کنید. نگاه کردن فقط به commit اولیه در شاخه نویسنده ممکن است تصویر کاملی از تاریخچه نهایی ارائه ندهد.
روش‌های ادغام میزبان نیز می‌توانند نتیجه متفاوتی تولید کنند؛ ادغام معمولی، squash و rebase از نظر ساختار تاریخچه یکسان نیستند. سیاست تیم باید روشن کند کدام شیء باید امضا شود و چه کسی یا چه سامانه‌ای آن را امضا می‌کند. برای نمونه، اگر چند commit به یکی تبدیل می‌شوند، مدرک امضای commit تازه را با امضاهای ورودی اشتباه نگیرید. این تصمیم را پیش از اجباری کردن قانون اتخاذ کنید تا انتشار عادی به خطاهای غیرمنتظره برخورد نکند.
حفاظت شاخه و استثناهای ربات‌ها
الزام commit امضاشده زمانی مفید است که مسیر ادغام واقعی آن را اجرا کند. اگر حسابی بتواند بی‌دلیل قانون را دور بزند یا مستقیم روی شاخه حساس بنویسد، مدل اعتماد باید این استثنا را توضیح دهد. ربات‌های به‌روزرسانی وابستگی و سامانه‌های انتشار نیز باید در طراحی دیده شوند. دادن کلید شخصی مدیر به ربات برای عبور از قانون، مالکیت و پیگیری را مبهم می‌کند. هویت خودکار باید از هویت انسان جدا و دامنه اختیارش محدود باشد.
برای آزمون سیاست، یک commit بدون امضا، یک commit با امضای مورد انتظار و یک تغییر از مسیر خودکار را در مخزن آزمایشی بررسی کنید. نتیجه هر مسیر باید با قرارداد تیم سازگار باشد. اگر قانون باعث توقف ابزار مهمی می‌شود، استثنا را محدود و مستند کنید یا جریان ابزار را اصلاح کنید. خاموش کردن سراسری کنترل برای حل مشکل یک ربات، معمولاً دامنه اثر بیش از نیاز دارد و بعداً فراموش می‌شود.
نگهداری و چرخش کلید
کلید خصوصی باید در محل مناسب با حفاظت متناسب نگهداری شود. عبارت عبور، عامل امضا و در صورت نیاز ابزار سخت‌افزاری هر کدام نقش مشخص دارند، اما هیچ‌کدام جای مراقبت از دستگاه کاربر را نمی‌گیرند. اگر برنامه نامطمئن بتواند هنگام باز بودن عامل درخواست امضا بدهد، وجود کلید رمزدار به تنهایی مانع همه سوءاستفاده‌ها نیست. دسترسی به محیط توسعه و اجرای کد ناشناس نیز بخشی از حفاظت کلید محسوب می‌شود.
برای چرخش، ابتدا کلید جدید و رابطه هویت آن را آماده و در مخزن آزمایشی تأیید کنید. سپس تنظیمات محلی و ابزارهای خودکار را مرحله‌ای تغییر دهید. درباره کلید قبلی، سیاست نگهداری عمومی و لغو دسترسی را مشخص کنید تا بررسی تاریخچه دچار ابهام نشود. اگر کلید گم شده یا افشا شده است، فرایند حادثه با چرخش عادی تفاوت دارد و باید اثر احتمالی بر تغییرهای منتشرشده بررسی شود. ثبت زمان و علت تغییر در این بررسی مهم است.
از commit تا اثر منتشرشده
حتی وقتی همه commitها امضا شده‌اند، هنوز باید بدانید فایل منتشرشده از کدام commit و با چه فرایندی ساخته شده است. یک خط لوله ساخت آسیب‌دیده می‌تواند اثری متفاوت از کد بررسی‌شده تولید کند. برای پوشش این فاصله، شناسه ورودی ساخت، اطلاعات منشأ، کنترل دسترسی سازنده و اعتبارسنجی اثر انتشار را در نظر بگیرید. امضای کد و امضای اثر ساخته‌شده دو پرسش مرتبط ولی متفاوت را پاسخ می‌دهند.
در یک تمرین کوچک، یک انتشار آزمایشی را از commit امضاشده بسازید و شناسه commit و شناسه محتوایی خروجی را در گزارش انتشار ثبت کنید. سپس از شخص دیگری بخواهید رابطه این دو را با شواهد موجود بررسی کند. اگر تنها توضیح شفاهی سازنده در دسترس است، زنجیره شواهد هنوز کامل نیست. هدف این تمرین تولید سند زیاد نیست؛ هدف این است که بتوان با داده مشخص پاسخ داد چه چیزی بررسی شد، چه چیزی ساخته شد و چه چیزی در نهایت به کاربر رسید.
