تاریخچهٔ فعالیت و نقش‌های تیم: چه کسی چه چیزی را تغییر داد، و چه کسی می‌توانست

سؤالی که یک login مشترک نمی‌تواند پاسخ دهد

بیشتر تیم‌های کوچک با یک مجموعه credential شروع می‌کنند. تا اولین incident کار می‌کند، و بعد به یک شکل بسیار خاص شکست می‌خورد: چیزی تغییر کرده، تغییر قابل‌مشاهده است، و هیچ‌کس نمی‌تواند بگوید چه کسی آن را انجام داده یا چه چیزی را جایگزین کرده.

آن شکاف بیشتر از شرمندگی هزینه دارد. بدون یک رکورد نمی‌توانید یک اشتباه را از یک نفوذ تشخیص دهید. نمی‌توانید با اطمینان تغییر را برگردانید، چون مقدار قبلی را نمی‌دانید. و نمی‌توانید فرایند را بهتر کنید، چون وقتی هیچ‌کس نمی‌داند واقعاً چه اتفاقی افتاده، «مراقب‌تر باش» تنها درسی است که در دسترس است.

یک نگاه بیرونی هم هست. یک ردپای قابل‌بازبینی از اقدامات مدیریتی و کنترل دسترسی معنادار، انتظارات استاندارد در پرسشنامه‌های امنیتی و در چارچوب‌هایی مثل ISO 27001 هستند، و رژیم‌های حفاظت از داده مثل KVKK و GDPR انتظار دارند بتوانید نشان دهید چه کسی به چه چیزی دسترسی داشته. چه دارید برای چیزی certification می‌گیرید یا نه، این الزام چیزی را توصیف می‌کند که به‌خاطر خودتان هم می‌خواهیدش.

چه چیزی ثبت می‌شود

activity history تغییراتی را پوشش می‌دهد که می‌توانند روی چیزی که بازدیدکنندگان می‌بینند اثر بگذارند: purgeهای کش، تغییرات رکورد DNS، تغییرات delivery rule، تغییرات security preset — شامل HSTS و blocklistهای کشور و ASN — اقدامات certificate و تغییرات hostname.

هر مدخل چهار چیز دارد که آن را مفید می‌کند. چه کسی: شخص واقعی، پس یک sub-user به‌جای «حساب» به‌شکل خودش ظاهر می‌شود. کِی. کدام حساب و مسیر که تغییر لمسش کرده. و before و after، پس مقدار قبلی همان‌جا هست به‌جای اینکه چیزی باشد که از حافظه بازسازی می‌کنید.

همان فیلد آخر همان چیزی است که لاگ را از یک گزارش به یک ابزار تبدیل می‌کند. «Delivery rule تغییر کرد» به شما می‌گوید کجا نگاه کنید. «Cache TTL 3600 → 60» به شما می‌گوید همان لحظه چه اتفاقی برای ترافیک origin شما افتاده.

خواندنش وقتی چیزی خراب است

نوار کناری حساب را باز کنید، بعد Monitoring → Activity history — /management/cdn/activities.

در طول یک incident، ترتیبی که کار می‌کند: به بازهٔ زمانی که برایتان مهم است محدود شوید، به کل حساب نگاه کنید نه فقط تغییری که از قبل به آن مظنونید، و مقادیر before/after را بخوانید نه عنوان مدخل‌ها. تغییری که سایت را خراب کرده اغلب همان چیزی نیست که در ذهن داشتید، و معمولاً ترتیب همان چیزی است که لو می‌دهد — دو مدخل از دو نفر متفاوت پنج دقیقه فاصله معمولاً کل داستان است.

فیلترکردن بر اساس action type همان چیزی است که یک حساب شلوغ را خواندنی می‌کند. سایتی با یک purge خودکار روی هر publish تعداد زیادی مدخل تولید می‌کند که همان چیزی نیستند که دنبالشان می‌گردید؛ آن‌ها را فیلتر کنید و آن چند تغییر کانفیگ باقیمانده به‌قدر کافی کوتاه است که کامل بخوانید.

خارج از یک incident، همان صفحه به یک سؤال آرام‌تر پاسخ می‌دهد: آیا چیزی دارد تغییر می‌کند که کسی ذکرش نکرده؟ این ارزش پنج دقیقه در ماه را دارد.

دسترسی به آن از API

تاریخچه از طریق API هم در دسترس است، که همان چیزی است که می‌خواهید اگر آرشیوش می‌کنید، آن را به سیستم لاگینگ خودتان forward می‌کنید، یا صرفاً بیشتر از آن چیزی که حوصلهٔ scroll کردنش را دارید نگهش می‌دارید. action_type همان دسته‌بندی‌هایی را می‌گیرد که فیلتر در پنل دارد، و endpoint همیشه فقط حساب‌هایی را نشان می‌دهد که token شما اجازهٔ دیدنشان را دارد.

25 purge آخر روی یک حساب

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://cdn.com.tr/api/accounts/<account-uuid>/activities?per_page=25&action_type=purge_cache"

سه نقش، و هرکدام برای چیست

یک لاگ به شما می‌گوید چه اتفاقی افتاده. نقش‌ها کاهش می‌دهند چه اتفاقی می‌تواند بیفتد. یک sub-user در cdn.com.tr یکی از این سه را می‌گیرد.

Viewer همه‌چیزی را که حساب نشان می‌دهد می‌خواند و هیچ‌چیزی را تغییر نمی‌دهد جز پروفایل و رمز خودش. این نقش درست برای مدیری است که نمودارها را می‌خواهد، یک آژانس که دربارهٔ عملکرد گزارش می‌دهد، یا هرکسی که باید در طول یک incident نگاه کند بدون اینکه بتواند بدترش کند.

Editor کار عملیاتی را انجام می‌دهد: پاک‌کردن کش، ویرایش delivery ruleها، مدیریت رکوردهای DNS، certificateها و hostnameها. چیزی که یک editor نمی‌تواند بکند تغییردادن شکل خود حساب است — نه ساخت یا حذف sub-user، نه billing، نه حذف حساب. این نقش برای آدم‌هایی است که روزبه‌روز سایت را می‌چرخانند.

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

دو جزئیات که ارزش دانستن دارند. اگر یک sub-user بدون انتخاب نقش ساخته شود، viewer می‌شود — امن‌ترین سر طیف، پس یک فیلد فراموش‌شده هرگز نمی‌تواند بیشتر از آنچه منظورتان بوده واگذار کند. و نقش‌ها دقیقاً همان‌طور که در پنل هستند برای API tokenها هم اجرا می‌شوند: token یک viewer می‌تواند بخواند و نمی‌تواند بنویسد، پس اسکریپتی که توسط کسی اجرا می‌شود که ممکن است اجازهٔ تغییر DNS را نداشته باشد، نمی‌تواند DNS را تغییر دهد.

اضافه‌کردن کسی، با دسترسی‌ای که نیاز دارد

به Authorization بروید — /management/authorization — و New user را انتخاب کنید. جزئیاتشان را پر کنید و پیش از ذخیره نقش را انتخاب کنید؛ همین فیلد است که همه‌چیز دیگر را دربارهٔ اینکه آن شخص چه می‌تواند بکند تعیین می‌کند.

دو عادت این را در عمل جواب می‌دهد. به هر شخص login خودش را بدهید نه یک login مشترک: activity history فقط به‌اندازهٔ نام‌هایی که در آن هست مفید است، و «توسط حساب مشترک purge شد» همان بن‌بستی است که از آن شروع کردید. و وقتی کسی برای یک کار مشخص می‌پیوندد — یک migration، یک همکاری با آژانس، یک پیمانکار — نقشی را بدهید که آن کار نیاز دارد و وقتی تمام شد حذفش کنید. دسترسی خفته‌ای که هیچ‌کس پاسخگویش نیست رایج‌ترین یافتهٔ هر access review است، و آسان‌ترین یافته برای اجتناب.

least privilege بدون آزاردهنده‌بودن

least privilege شهرت بدی دارد چون معمولاً به‌شکل «هر بار از من بپرس» پیاده می‌شود، که آدم‌ها ظرف یک هفته دورش می‌زنند. نسخه‌ای که برخورد با یک تیم واقعی را تاب می‌آورد ساده‌تر است.

همه را به‌طور پیش‌فرض viewer کنید و روی درخواست ارتقا دهید. اولین باری که کسی نیاز به purge دارد یک پیام هزینه دارد، و یعنی هیچ‌کس دسترسی‌ای را حمل نمی‌کند که هرگز درخواستش نکرده.

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

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

این دو ویژگی یک کنترل واحدند

وسوسه‌انگیز است که لاگ را ویژگی امنیتی و نقش‌ها را اداری در نظر بگیرید. برعکس کار می‌کند.

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

هیچ‌کدام به‌تنهایی ارزش زیادی ندارد. نقش‌ها بدون یک رکورد یعنی به مرزی اعتماد می‌کنید که هرگز نمی‌توانید چکش کنید. یک رکورد بدون نقش‌ها یعنی می‌توانید هر incident را کامل توصیف کنید و هیچ‌کدام را جلو نگیرید. با هم به سؤالی پاسخ می‌دهند که واقعاً بعد از یک outage پرسیده می‌شود — هرگز «CDN چیست» نه، همیشه «چه کسی این را تغییر داد، و چرا توانست؟»