GitHub Audit Log یک قابلیت در سطح سازمان است که همه‌ی رویدادهای مهم را ثبت می‌کند: ورود کاربران، تغییر دسترسی‌ها، ایجاد و حذف مخزن، تغییر تنظیمات امنیتی و صدها رویداد دیگر. برخلاف لاگ‌های معمولی، Audit Log به‌صورت غیرقابل تغییر (immutable) طراحی شده و برای ممیزی انطباق و پاسخ به حادثه کاربرد اصلی دارد. اما در بسیاری از سازمان‌ها، این قابلیت نادیده گرفته می‌شود تا زمانی که یک حادثه‌ی امنیتی رخ دهد و نیاز به بررسی گذشته باشد. در آن لحظه، فقدان لاگ کافی به یک بحران تبدیل می‌شود. این نوشته از ساختار لاگ تا پیاده‌سازی جریان کار ممیزی و پاسخ به حادثه را پوشش می‌دهد.

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

Audit Log چیست و چه رویدادهایی را ثبت می‌کند

Audit Log در GitHub یک سیستم ثبت رویداد در سطح سازمان است که همه‌ی اقدامات مهم را به‌صورت خودکار ثبت می‌کند. برخلاف لاگ‌های معمولی که ممکن است تغییرپذیر باشند، Audit Log به‌صورت immutable طراحی شده و امکان دستکاری یا حذف رکوردها وجود ندارد.

انواع رویدادهای ثبت‌شده:

  • احراز هویت: ورود موفق و ناموفق، تغییر رمز، فعال‌سازی 2FA.
  • دسترسی: اعطا، تغییر یا لغو دسترسی کاربران و تیم‌ها.
  • مخزن: ایجاد، انتقال، تغییر visibility و حذف.
  • تنظیمات امنیتی: تغییر branch protection، ruleset و policy.
  • GitHub Actions: اجرا، تغییرات در workflow و سکرت‌ها.
  • GitHub Apps: نصب، حذف و تغییر دسترسی‌ها.
  • پکیج‌ها: انتشار، حذف و تغییر دسترسی در GitHub Packages.
  • Enterprise: تغییرات در سطح سازمان و Enterprise.
  • OAuth و PAT: ایجاد، استفاده و لغو توکن‌ها.
  • Webhooks: تغییرات در webhookها.

این تنوع، Audit Log را به یک ابزار جامع تبدیل می‌کند که در ممیزی، پاسخ به حادثه و تحلیل استفاده کاربرد دارد. اصول مشابه این نوع ثبت رویداد در لاگ‌های دیتابیس (Database Logs) چگونه بررسی می‌شوند؟ بررسی شده است.

Audit Log ابزاری برای آینده است؛ ارزش آن زمانی آشکار می‌شود که به آن نیاز دارید و از قبل فعالش کرده‌اید.

ساختار هر رکورد و فیلدهای کلیدی

هر رکورد در Audit Log یک رویداد مشخص را توصیف می‌کند. فیلدهای اصلی این رکوردها:

{
  "@timestamp": 1699999999999,
  "action": "repo.create",
  "actor": "username",
  "actor_ip": "203.0.113.10",
  "actor_location": {
    "country_code": "IR"
  },
  "org": "my-org",
  "repo": "my-org/my-repo",
  "user_agent": "Mozilla/5.0 ...",
  "created_at": 1699999999999
}

فیلدهای کلیدی:

  • action: نوع رویداد، مثل repo.create یا user.login.
  • actor: کاربری که رویداد را انجام داده.
  • actor_ip: آدرس IP کاربر.
  • actor_location: موقعیت جغرافیایی تقریبی.
  • org و repo: سازمان و مخزن مربوطه.
  • user_agent: اطلاعات مرورگر یا ابزار.
  • @timestamp: زمان دقیق رویداد.

این ساختار، امکان فیلتر دقیق رویدادها را فراهم می‌کند. مثلاً می‌توان رویدادهای user.login ناموفق از IP غیرمنتظره را فیلتر کرد و برای بررسی سریع به دست آورد.

نکته‌ی مهم این است که Audit Log در پلن‌های مختلف، فیلدهای متفاوتی دارد. پلن Enterprise دسترسی به فیلدهای بیشتر و مدت نگهداشت طولانی‌تر را فراهم می‌کند. اصول مشابه در گیت‌هاب اینترپرایز بررسی شده است.

دسترسی به Audit Log؛ UI، API و Streaming

سه روش اصلی برای دسترسی به Audit Log:

رابط وب

از طریق Settings → Audit log در سطح سازمان یا Enterprise. رابط وب امکان فیلتر ساده و مشاهده‌ی سریع را فراهم می‌کند، اما برای تحلیل گسترده محدودیت دارد.

API

نقطه‌ی پایانی /orgs/{org}/audit-log امکان دریافت رویدادها با فیلترهای متنوع را فراهم می‌کند. این API برای یکپارچگی با ابزارهای داخلی مناسب است.

gh api /orgs/my-org/audit-log 
  --paginate 
  -f phrase="action:user.login" 
  -f per_page=100

Streaming

Streaming به سازمان‌های Enterprise اجازه می‌دهد رویدادها را در زمان واقعی به یک مقصد خارجی ارسال کنند. این قابلیت برای SIEM و ابزارهای پایش پیشرفته ضروری است.

# نمونه پیکربندی streaming به AWS S3
{
  "enabled": true,
  "vendor": "amazon_s3",
  "bucket": "my-audit-log-bucket",
  "region": "us-east-1"
}

Streaming یکی از مهم‌ترین قابلیت‌های Audit Log است، چون امکان تحلیل زمان‌واقعی و هشدار سریع را فراهم می‌کند. بدون Streaming، سازمان ناچار به خواندن دوره‌ای از API است که هم کندتر است و هم تأخیر دارد.

مدت نگهداشت و تفاوت پلن‌ها

مدت نگهداشت Audit Log بسته به پلن متفاوت است:

پلنمدت نگهداشت (UI/API)امکان Streaming
Free۹۰ روزندارد
Team۹۰ روزندارد
Enterprise Cloud۱۸۰ روز یا بیشتردارد
Enterprise Serverبسته به پیکربندیدارد

برای سازمان‌هایی که نیاز به نگهداشت طولانی‌تر دارند، Streaming به یک مقصد خارجی راه‌حل اصلی است. رویدادها به S3، Azure Blob Storage یا سیستم‌های SIEM منتقل می‌شوند و مدت نگهداشت به سیاست سازمان بستگی دارد.

نکته‌ی مهم در طراحی نگهداشت: هرچه نگهداشت طولانی‌تر باشد، حجم داده بیشتر و هزینه‌ی ذخیره‌سازی بالاتر است. تعادل بهینه، بر اساس الزامات انطباق، نیاز تحلیل و بودجه تعیین می‌شود. اصول مشابه در هزینه‌های رایانش ابری چگونه با Cloud FinOps مدیریت می‌شود؟ بررسی شده است.

Streaming به SIEM و سیستم‌های خارجی

Streaming به SIEM (Security Information and Event Management) یکی از مهم‌ترین کاربردهای Audit Log در سازمان‌های بزرگ است. SIEM رویدادها را از منابع مختلف جمع می‌کند و امکان تحلیل متمرکز را فراهم می‌کند.

مقصدهای پشتیبانی‌شده برای Streaming:

  • AWS S3: ذخیره‌سازی طولانی‌مدت و ارزان.
  • Azure Blob Storage: جایگزین Azure.
  • Google Cloud Storage: برای سازمان‌هایی که روی GCP کار می‌کنند.
  • Splunk: یکی از رایج‌ترین SIEMها.
  • Datadog: پایش و تحلیل یکپارچه.
  • Microsoft Sentinel: راه‌حل بومی Azure.

در سطح معماری، Streaming یک pipeline است که از GitHub شروع می‌شود، از طریق HTTPS به مقصد می‌رسد و در SIEM برای تحلیل استفاده می‌شود. هر گام این pipeline باید پایدار و امن باشد. اصول مشابه در ERP چگونه فرآیندهای کسب‌وکار را یکپارچه می‌کند؟ بررسی شده است.

کاربردهای اصلی؛ ممیزی، انطباق و پاسخ به حادثه

Audit Log در سه حوزه‌ی اصلی کاربرد دارد:

انطباق و ممیزی

برای سازمان‌هایی که تحت استانداردهای ISO 27001، SOC 2، PCI-DSS یا HIPAA فعالیت می‌کنند، Audit Log یکی از الزامات است. ممیزان نیازمند شواهد مشخصی از فعالیت‌های کاربران و تغییرات امنیتی هستند. Audit Log این شواهد را فراهم می‌کند.

پاسخ به حادثه

در زمان حادثه‌ی امنیتی، Audit Log اولین منبع اطلاعات است. سؤال‌هایی مثل «چه کسی دسترسی را تغییر داد؟» یا «چه زمانی سکرت لو رفت؟» با بررسی لاگ پاسخ می‌گیرند. بدون لاگ، پاسخ این سؤال‌ها غیرممکن یا حدسی است.

شکار تهدید

در سازمان‌های بالغ، تیم امنیت به‌طور فعال در لاگ‌ها به دنبال الگوهای مشکوک می‌گردد. مثلاً ورود از IP غیرمنتظره، تغییر ناگهانی دسترسی یا حذف مخزن بدون دلیل. این فعالیت به‌عنوان Threat Hunting شناخته می‌شود و بخشی از استراتژی امنیت فعال است. اصول مشابه در اشتباهات رایج در مقابله با حملات سایبری کدامند؟ بررسی شده است.

Audit Log فعال، در زمان بحران معادل یک تیم بررسی است؛ Audit Log غیرفعال، معادل صفر است.

Audit Log و استانداردهای انطباق

چند استاندارد کلیدی که Audit Log نقش مستقیم در انطباق با آن‌ها دارد:

  • ISO 27001: نیازمند ثبت رویدادهای امنیتی و امکان ممیزی.
  • SOC 2: نیازمند شواهد کنترل‌های امنیتی.
  • PCI-DSS: نیازمند ثبت دسترسی به داده‌های حساس.
  • HIPAA: نیازمند ثبت دسترسی به داده‌های سلامت.
  • GDPR: نیازمند ثبت دسترسی به داده‌های شخصی.

در هر یک از این استانداردها، Audit Log به‌عنوان یک کنترل کلیدی دیده می‌شود. سازمان‌هایی که این استانداردها را جدی می‌گیرند، معمولاً Audit Log را از ابتدا فعال می‌کنند و به یک SIEM متصل می‌کنند. اصول مشابه در چرا انطباق با GDPR در پروژه وردپرس حیاتی است؟ بررسی شده است.

تحلیل لاگ و شناسایی الگوهای مشکوک

تحلیل Audit Log نیازمند رویکردی ساخت‌یافته است. چند الگوی رایج که باید بررسی شوند:

  • ورود از IP ناشناس: ورود کاربر از IP که با الگوی معمول او هماهنگ نیست.
  • ورود ناموفق مکرر: نشانه‌ی تلاش برای نفوذ.
  • تغییر دسترسی ناگهانی: افزایش دسترسی کاربر بدون دلیل روشن.
  • حذف مخزن یا branch: اقداماتی که به‌ندرت توسط کاربران مجاز انجام می‌شود.
  • ایجاد توکن جدید: به‌ویژه Personal Access Token با دسترسی گسترده.
  • نصب GitHub App ناشناس: ممکن است نشانه‌ی نفوذ باشد.
  • تغییر branch protection: کاهش سطح امنیتی بدون دلیل.

ابزارهای تحلیل می‌توانند از قواعد ساده یا مدل‌های یادگیری ماشین استفاده کنند. در سازمان‌های بزرگ، ترکیب قواعد ثابت با مدل‌های آماری، کارآمدترین رویکرد است. اصول مشابه در ML چگونه پیش‌بینی‌های هوشمند می‌سازد؟ بررسی شده است.

یکپارچگی با ابزارهای پایش و هشدار

Audit Log بدون هشدار، فقط یک آرشیو است. برای بهره‌برداری کامل، باید به ابزارهای پایش و هشدار متصل شود:

  • Slack یا Teams: ارسال هشدار فوری برای رویدادهای حساس.
  • PagerDuty: مدیریت حادثه و اطلاع‌رسانی به تیم.
  • SIEM: تحلیل متمرکز و همبستگی با رویدادهای دیگر.
  • Email: هشدار به مالکان مخزن برای رویدادهای خاص.
  • Webhook سفارشی: برای یکپارچگی با ابزارهای داخلی.

یک الگوی رایج، تعریف چند قاعده‌ی هشدار است: ورود از IP ناشناس، تغییر branch protection، ایجاد PAT با دسترسی write، و حذف مخزن. این قواعد باید با سیاست سازمان هماهنگ باشند و به‌طور دوره‌ای بازبینی شوند.

در تیم‌های کوچک‌تر، هشدار ساده به یک کانال Slack می‌تواند تفاوت مهمی ایجاد کند. بدون هشدار، لاگ به‌سرعت به یک آرشیو فراموش‌شده تبدیل می‌شود. اصول مشابه در گیت‌هاب ادونس سکیوریتی بررسی شده است.

اشتباهات رایج در استفاده از Audit Log

  • فعال‌سازی دیرهنگام: فعال کردن Audit Log پس از حادثه.
  • نادیده گرفتن Streaming: اکتفا به API بدون پایش زمان واقعی.
  • نگهداشت کوتاه: از دست رفتن لاگ‌های قدیمی که برای ممیزی لازم است.
  • نبود تحلیل: جمع‌آوری لاگ بدون تحلیل منظم.
  • نبود هشدار: لاگ فعال اما بی‌استفاده.
  • نادیده گرفتن فیلدهای امنیتی: عدم بررسی actor_ip و actor_location.
  • نداشتن نقش مسئول: نبود مالک مشخص برای Audit Log.
  • نادیده گرفتن الزامات انطباق: طراحی نگهداشت بدون توجه به استانداردها.
  • نداشتن برنامه‌ی پاسخ به حادثه: نداشتن رویه‌ی مشخص برای بررسی رویدادهای مشکوک.
  • نداشتن پشتیبان از لاگ‌ها: از دست رفتن شواهد در صورت حذف.
  • نادیده گرفتن امنیت خود لاگ: دسترسی نامحدود به لاگ‌های حساس.
  • نبود بازبینی دوره‌ای: هشدارهای منسوخ که بی‌فایده شده‌اند.

بخش زیادی از این اشتباهات با یک طراحی اولیه‌ی درست قابل پیشگیری است. سازمان‌هایی که Audit Log را از ابتدا در استراتژی امنیتی خود می‌گنجانند، در زمان بحران سریع‌تر و مؤثرتر عمل می‌کنند. اصول مشابه در چرا مدیریت آسیب‌پذیری‌ها در بیشتر سازمان‌ها شکست می‌خورد؟ بررسی شده است.

پرسش‌های پرتکرار درباره Audit Log گیت‌هاب

GitHub Audit Log چیست؟ یک سیستم ثبت رویداد در سطح سازمان که فعالیت‌های مهم را به‌صورت غیرقابل تغییر ثبت می‌کند.

چه رویدادهایی در Audit Log ثبت می‌شود؟ احراز هویت، تغییر دسترسی، ایجاد و حذف مخزن، تغییر تنظیمات امنیتی، فعالیت Actions، نصب Apps و رویدادهای دیگر.

چقدر لاگ نگهداری می‌شود؟ در پلن‌های Free و Team تا ۹۰ روز، در Enterprise تا ۱۸۰ روز یا بیشتر با Streaming.

Streaming چیست؟ ارسال رویدادها در زمان واقعی به مقصد خارجی مثل S3 یا SIEM.

چطور به Audit Log دسترسی داشته باشم؟ از طریق رابط وب، API یا Streaming (در پلن Enterprise).

آیا می‌توانم لاگ را فیلتر کنم؟ بله، هم در رابط وب و هم در API با فیلترهای مختلف مثل action، actor و actor_ip.

چطور از Audit Log برای انطباق استفاده کنم؟ با فعال‌سازی Streaming به SIEM و نگهداشت طولانی‌مدت مطابق با الزامات استاندارد.

آیا Audit Log قابل تغییر است؟ خیر، رکوردها immutable هستند و امکان حذف یا دستکاری وجود ندارد.

چطور هشدار امنیتی تعریف کنم؟ با اتصال Audit Log به SIEM یا ابزار هشدار و تعریف قواعد برای رویدادهای حساس.

آیا می‌توانم روی Audit Log دسترسی محدود تعریف کنم؟ بله، دسترسی به Audit Log معمولاً محدود به نقش‌های Owner و Security Manager است. اصول این حوزه در گیت‌هاب اینترپرایز بررسی شده است.

تفاوت Audit Log با Activity Log چیست؟ Activity Log محدود به یک مخزن یا سازمان با نگهداشت کوتاه‌تر است. Audit Log سطح Enterprise با نگهداشت طولانی‌تر و امکان Streaming.

آیا Audit Log برای سازمان‌های کوچک هم مناسب است؟ بله، به‌ویژه برای پاسخ به حادثه. حتی با نگهداشت کوتاه، ارزش آن در زمان بحران آشکار می‌شود.

چطور از لاگ‌ها پشتیبان بگیرم؟ با Streaming به ذخیره‌سازی خارجی و اعمال سیاست نگهداشت مطابق با الزامات سازمان. اصول مشابه در پشتیبان‌گیری امن از دیتابیس (Database Backup) چگونه است؟ بررسی شده است.

لایه‌ی مهندسی سطح بالا در حسابرسی امنیتی

از منظر معماری امنیتی، Audit Log یک سیستم Append-Only Log است که پایه‌ی هر سیستم حسابرسی امنیتی محسوب می‌شود. طراحی Append-Only، تضمین می‌کند که رویدادها پس از ثبت قابل تغییر نیستند. این تضمین، پایه‌ی اعتماد به لاگ در زمان ممیزی و بررسی حادثه است.

در سطح SIEM، Audit Log یکی از منابع داده است که با لاگ‌های AWS، Azure، Kubernetes و ابزارهای دیگر ترکیب می‌شود. همبستگی رویدادها از منابع مختلف، امکان شناسایی حملات پیچیده‌ای را فراهم می‌کند که در یک منبع تنها دیده نمی‌شوند. مثلاً ترکیب Audit Log با CloudTrail می‌تواند حملات از یک IP خاص به چند سرویس را آشکار کند.

در سطح تحلیل، روش‌های آماری و یادگیری ماشین می‌توانند الگوهای غیرعادی را شناسایی کنند: زمان ورود غیرمعمول، تعداد درخواست غیرعادی یا تغییرات ناگهانی دسترسی. این روش‌ها به‌ویژه در سازمان‌های بزرگ که حجم لاگ بالا است، ضروری هستند. اصول مشابه در هوش مصنوعی و امنیت سایبری: اخبار جدید بررسی شده است.

در سطح حاکمیت، Audit Log بخشی از چارچوب امنیت سازمان است و باید با سیاست‌های دیگر هماهنگ باشد: سیاست دسترسی، سیاست نگهداشت داده و سیاست پاسخ به حادثه. هماهنگی این سیاست‌ها، به یک چارچوب منسجم تبدیل می‌شود که در زمان بحران کارآمد است. اصول مشابه در امنیت وب چیست و چه اصولی دارد؟ بررسی شده است.

در نهایت، از منظر پایداری، Audit Log باید به‌عنوان یک دارایی استراتژیک مدیریت شود. پشتیبان‌گیری منظم، آزمون دوره‌ای بازیابی و بازبینی سیاست نگهداشت، بخشی از این مدیریت است. سازمان‌هایی که این موضوع را جدی می‌گیرند، در زمان بحران آماده‌تر عمل می‌کنند. اصول مشابه در پشتیبان گیری از mysql بررسی شده است. 🧩

در سطح اقتصاد امنیت، هزینه‌ی فعال‌سازی Audit Log و Streaming در مقایسه با هزینه‌ی یک حادثه‌ی امنیتی ناچیز است. سازمان‌هایی که این محاسبه را جدی می‌گیرند، در بلندمدت سرمایه‌گذاری بهتری انجام می‌دهند. 📊

بستن بحث

Audit Log در GitHub یک ابزار زیرساختی است که ارزش آن در زمان بحران آشکار می‌شود. فعال‌سازی آن، اتصال به SIEM و تعریف هشدارهای مناسب، سه گام اصلی برای هر سازمانی است که امنیت را جدی می‌گیرد. نادیده گرفتن این ابزار، به‌معنای کور بودن در برابر تهدیدات است.

اگر در ابتدای مسیر هستید، از فعال‌سازی Audit Log و بررسی دوره‌ای رویدادها شروع کنید. اگر در سازمان بزرگ هستید، از Streaming به SIEM و تحلیل مستمر بهره ببرید. اگر الزامات انطباق دارید، Audit Log را بخشی از چارچوب ممیزی خود قرار دهید.

اگر تجربه‌ای از استفاده‌ی Audit Log در پاسخ به حادثه‌ای واقعی دارید، برایم جالب است بدانید کدام جنبه بیشترین کمک را کرد و کدام بخش بیشترین چالش را داشت. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر رویکردی برای ترکیب Audit Log با ابزارهای پایش پیدا کرده‌اید.