تنظیمات GitLab بعد از نصب؛ چک‌لیست امنیت و نگهداری

تنظیمات اولیه GitLab بعد از نصب

نصب موفق فقط آغاز کار است؛ پیش از انتقال Repositoryهای اصلی، امنیت، دسترسی، پشتیبان‌گیری و Pipeline را آماده کنید.

بعد از بالا آمدن صفحه GitLab وسوسه‌انگیز است که همه Repositoryها را فوراً منتقل کنید. بهتر است پیش از ورود داده اصلی، یک چک‌لیست کوتاه را کامل کنید. هدف این است که دسترسی مدیریتی، دامنه، HTTPS، کاربران، Backup و Runner از ابتدا قابل‌کنترل باشند.

۱. نسخه و وضعیت سرویس را ثبت کنید

نسخه GitLab، روش نصب، آدرس سرویس، منابع سرور و تاریخ راه‌اندازی را در مستند داخلی بنویسید. این اطلاعات برای Upgrade، Restore و عیب‌یابی لازم است.

۲. حساب مدیر را امن کنید

رمز طولانی و منحصربه‌فرد انتخاب کنید؛

آن را در Password Manager نگه دارید؛

2FA را فعال کنید؛

برای کار روزمره حساب غیرمدیر بسازید؛

دسترسی مدیر را فقط به افراد ضروری بدهید.

حساب Root یا Administrator نباید Token عمومی ابزارهای AI و Automation باشد.

۳. دامنه و HTTPS را کامل کنید

یک زیردامنه مانند git.example.com بسازید و رکورد DNS آن را به IP سرور متصل کنید. سپس آدرس خارجی GitLab را مطابق روش نصب تنظیم و گواهی TLS معتبر فعال کنید.

پس از فعال‌شدن HTTPS موارد زیر را آزمایش کنید:

ورود از مرورگر؛

Clone با HTTPS؛

Callbackهای اتصال خارجی؛

Webhookها؛

انقضا و تمدید گواهی.

۴. کاربران و نقش‌ها را محدود کنید

همه کاربران به نقش Maintainer نیاز ندارند. دسترسی را بر اساس کار واقعی بدهید و حساب‌های غیرفعال را دوره‌ای حذف یا مسدود کنید. برای Botها، CI و ابزارهای AI حساب یا Token مجزا بسازید تا فعالیت هرکدام قابل‌ردیابی باشد.

۵. SSH Key را تنظیم کنید

SSH Key امکان Clone، Pull و Push امن را بدون واردکردن مداوم رمز فراهم می‌کند. کلید عمومی در GitLab ثبت می‌شود و کلید خصوصی باید فقط روی دستگاه کاربر بماند.

GitLab در مستند فعلی ED25519 را ترجیح می‌دهد. برای ساخت و افزودن کلید، راهنمای SSH Key را ببینید.

۶. یک پروژه آزمایشی بسازید

قبل از انتقال Repository اصلی:

یک پروژه Private بسازید؛

Clone با SSH را آزمایش کنید؛

یک Branch و Commit ایجاد کنید؛

Merge Request باز کنید؛

یک Pipeline ساده اجرا کنید؛

دسترسی کاربر Developer را بررسی کنید.

۷. Branch اصلی را محافظت کنید

برای main یا Branch انتشار، Rule بسازید. Push مستقیم را ببندید و مجوز Merge را محدود کنید. اگر Tier شما Approval اجباری را پشتیبانی می‌کند، تعداد تأییدها و Code Ownerها را تعریف کنید.

در پروژه AI، Token ابزار خودکار نباید بتواند Rule را دور بزند یا مستقیماً روی Branch اصلی Push کند.

۸. Runner را جداگانه ارزیابی کنید

Runner برنامه‌ای است که Jobهای Pipeline را اجرا می‌کند. یک Job آزمایشی برای Lint یا echo بسازید و مطمئن شوید Runner فعال، سازگار با نسخه GitLab و دارای Tag درست است.

برای Build و تست سنگین، Runner جداگانه کمک می‌کند فشار CI/CD از سرور اصلی GitLab جدا شود. راهنمای GitLab Runner را بخوانید.

۹. Secretها را از Repository خارج کنید

رمز، API Key و Private Key را داخل کد یا فایل .env قابل Commit قرار ندهید. متغیرهای CI/CD را با سطح محافظت مناسب ثبت کنید و Secret Detection را در Pipeline فعال کنید.

اگر Secret قبلاً Push شده است، آن را Rotate کنید؛ حذف فایل بدون تعویض Secret کافی نیست.

۱۰. Backup و Restore را طراحی کنید

Backup موفق فقط وقتی ارزش دارد که Restore آن آزمایش شده باشد. برنامه باید شامل دوره Backup، محل نگهداری، رمزگذاری، Retention، هشدار شکست و آزمون بازیابی باشد.

طبق مستند GitLab، آرشیو پیش‌فرض بسیاری از داده‌ها مانند Database، Repository، LFS، Artifact و Upload را شامل می‌شود؛ اما /etc/gitlab، کلیدها و گواهی‌های TLS/SSH و برخی داده‌های Object Storage باید جداگانه پشتیبان‌گیری شوند.

نسخه Backup را فقط روی همان سرور اصلی نگه ندارید. Restore معمولاً به نصب GitLab با همان نسخه Backup نیاز دارد؛ این وابستگی را در Runbook ثبت کنید.

۱۱. مانیتورینگ و ظرفیت Disk را فعال کنید

CPU، RAM، Load، Disk Usage، Disk I/O، وضعیت سرویس‌ها، صف Job و زمان پاسخ را پایش کنید. برای فضای آزاد Disk هشدار زودهنگام بگذارید؛ پرشدن دیسک می‌تواند روی Repository، Database و Backup اثر بگذارد.

۱۲. برنامه Upgrade داشته باشید

GitLab را بدون بررسی مسیر Upgrade مستقیماً چند نسخه جلو نبرید. Release Note، نسخه پشتیبان، فضای کافی، زمان نگهداری و مسیر Rollback را پیش از Upgrade آماده کنید. Runner نیز بهتر است از نظر Major و Minor با GitLab هماهنگ بماند.

چک‌لیست نهایی

☐ نسخه و روش نصب ثبت شده است.

☐ 2FA مدیر فعال است.

☐ دامنه و HTTPS آزمایش شده‌اند.

☐ نقش کاربران محدود است.

☐ SSH Key کاربران ثبت شده است.

☐ Push مستقیم به Branch اصلی بسته شده است.

☐ پروژه و Pipeline آزمایشی موفق‌اند.

☐ Runner ظرفیت و جداسازی مناسب دارد.

☐ Secretها خارج از Repository هستند.

☐ Backup خارج از سرور اصلی نگهداری می‌شود.

☐ Restore آزمایش شده است.

☐ هشدار Disk و منابع فعال است.

☐ برنامه Upgrade مستند شده است.

جمع‌بندی

GitLab آماده استفاده زمانی است که فقط صفحه ورود آن باز شود؟ خیر. سرویس آماده باید دسترسی محدود، HTTPS، Branch Rule، Runner، Backup قابل‌بازیابی و مانیتورینگ داشته باشد. این چک‌لیست را پیش از انتقال پروژه‌های اصلی کامل کنید.

اگر هنوز سرویس را نساخته‌اید، از آموزش راه‌اندازی GitLab در آرانیک شروع کنید.

منابع

Use SSH keys with GitLab

Protected branches

Back up GitLab

Restore GitLab

GitLab Runner

پرسش‌های متداول

اولین تنظیم مهم بعد از نصب GitLab چیست؟

ابتدا حساب مدیر، دامنه و HTTPS را امن کنید؛ سپس کاربران و نقش‌ها را محدود و یک پروژه آزمایشی برای کنترل سلامت بسازید.

Backup GitLab شامل چه چیزهایی است؟

Repository، پایگاه داده و داده‌های برنامه مهم‌اند، اما بعضی فایل‌های پیکربندی و Secretها فرایند نگهداری جدا دارند؛ راهنمای رسمی نسخه خود را بررسی کنید.

هر چند وقت یک‌بار GitLab را به‌روزرسانی کنیم؟

برنامه منظم Upgrade داشته باشید، مسیر نسخه‌های میانی الزامی را بررسی کنید و پیش از تغییر، Backup و آزمون بازیابی انجام دهید.

منابع رسمی

• مستند رسمی محصول
• مستند رسمی محصول
• مستند رسمی محصول

قدم بعدی: برای راه‌اندازی سرویس مرتبط، وارد داشبورد آرانیک شوید و از بخش Easy Install سرویس را بسازید.