مصاحبهٔ دوآپس؛ شب ۴: پایش، لاگ و امنیت
فهرست نوشته
پایش و امنیت هر دو به بازخورد وابسته‌اند: باید رفتار سامانه را ببینیم، انحراف را تشخیص دهیم و واکنش قابل تکرار داشته باشیم. امشب ده پرسش را طوری مرور می‌کنیم که نام ابزار جای هدف را نگیرد. در پایان باید بتوانید signal مناسب را انتخاب کنید و امنیت را به چرخهٔ تحویل وصل کنید.
پرسش‌های ۳۱ تا ۳۵: پایش و لاگ#
۳۱. monitoring در DevOps چیست؟#
پاسخ کوتاه: monitoring گردآوری، پردازش و ارزیابی پیوستهٔ signalهای سامانه برای فهم سلامت، کارایی و دستیابی به هدف خدمت است. metric، log، trace و synthetic check می‌توانند ورودی باشند، اما پایش زمانی ارزش دارد که به پرسش و اقدام مشخص وصل شود.
داشبورد زیبا به‌تنهایی پایش عملیاتی نیست. ابتدا رفتار مهم برای کاربر را تعریف کنید؛ سپس شاخص، آستانه و بازه را بر همان اساس انتخاب کنید. alert باید وضعیت نیازمند اقدام را نشان دهد و owner و runbook داشته باشد. پوشش CPU بدون نرخ خطای درخواست ممکن است خرابی واقعی را پنهان کند. همچنین دادهٔ telemetry هزینه، retention و ملاحظات حریم خصوصی دارد و نباید بی‌هدف جمع شود.
۳۲. ELK Stack چیست؟#
پاسخ کوتاه: ELK نام تاریخی ترکیب Elasticsearch، Logstash و Kibana است: Elasticsearch داده را ذخیره و جست‌وجو می‌کند، Logstash آن را دریافت و تبدیل می‌کند و Kibana رابط جست‌وجو و نمایش است. اکوسیستم امروزی معمولاً با عنوان Elastic Stack شامل Elastic Agent و Beats نیز شناخته می‌شود.
هر رویداد باید timestamp، منبع و فیلدهای قابل جست‌وجو داشته باشد. طراحی mapping و index lifecycle روی کارایی و هزینه اثر می‌گذارد. Logstash همیشه اجباری نیست؛ agent می‌تواند مستقیم یا از مسیر دیگری داده را بفرستد. عبارت «ELK یک ابزار APM است» بیش از حد کلی است؛ stack می‌تواند لاگ، جست‌وجو، امنیت و مشاهده‌پذیری را پشتیبانی کند، ولی نتیجه به pipeline دریافت، schema، دسترسی و retention وابسته است.
۳۳. Prometheus چیست؟#
پاسخ کوتاه: Prometheus سامانهٔ متن‌باز پایش و alerting مبتنی بر time series است. معمولاً endpointهای metric را pull می‌کند، داده را با label نگه می‌دارد و با PromQL پرس‌وجو می‌شود. Alertmanager مسیر ارسال و گروه‌بندی alertها را مدیریت می‌کند.
مدل pull مشاهدهٔ targetهای ازدست‌رفته را آسان می‌کند، ولی برای همهٔ سناریوها کافی نیست. cardinality بالای label—مثلاً قرار دادن شناسهٔ کاربر—حجم series و حافظه را منفجر می‌کند. Prometheus پایگاه بلندمدت نامحدود یا سامانهٔ log نیست؛ retention محلی و راه‌حل remote storage باید آگاهانه طراحی شوند. metric باید نام، نوع، واحد و label محدود و پایدار داشته باشد.
۳۴. Grafana چیست؟#
پاسخ کوتاه: Grafana لایهٔ پرس‌وجو، visualization و alerting روی data sourceهای مختلف است. خودش الزاماً منبع اصلی metric نیست؛ می‌تواند به Prometheus، پایگاه‌های time series، log و منابع دیگر وصل شود و dashboard مشترک بسازد.
dashboard باید یک سؤال عملیاتی را پاسخ دهد، نه اینکه هر دادهٔ موجود را نشان دهد. نرخ درخواست، خطا و latency بهتر است با واحد، بازه و percentile روشن نمایش داده شوند. متغیرهای dashboard امکان فیلتر محیط و سرویس می‌دهند، اما دسترسی منبع داده و folder باید کنترل شود. alerting در Grafana ممکن است مناسب باشد، ولی تیم باید منبع حقیقت ruleها و مسیر مالکیت را مشخص کند تا دو سامانه alert متناقض نسازند.
۳۵. monitoring و logging چه تفاوتی دارند؟#
پاسخ کوتاه: monitoring وضعیت و روند را با signalهای خلاصه و کنترل‌های سلامت دنبال می‌کند؛ logging رویدادهای گسسته و دارای زمینه را برای تشخیص، ممیزی و عیب‌یابی ثبت می‌کند. این دو هم‌پوشانی دارند، اما جای یکدیگر را نمی‌گیرند.
metric سریع می‌گوید نرخ خطای سرویس بالا رفته است؛ log می‌تواند نشان دهد کدام درخواست و خطا دخیل بوده؛ trace مسیر همان درخواست را میان سرویس‌ها آشکار می‌کند. چاپ هر چیز در log، مشاهده‌پذیری نمی‌سازد. سطح، ساختار، correlation ID، حذف secret و سیاست retention مهم‌اند. از سوی دیگر استخراج همهٔ alertها از log پرحجم می‌تواند دیر و پرهزینه باشد. signal را بر اساس پرسش انتخاب کنید.
پرسش‌های ۳۶ تا ۴۰: امنیت و انطباق#
۳۶. DevSecOps چیست؟#
پاسخ کوتاه: DevSecOps یعنی مسئولیت و کنترل امنیت در سراسر چرخهٔ توسعه و عملیات توزیع شود، نه اینکه یک بررسی دیرهنگام در پایان باشد. threat modeling، آزمون کد و وابستگی، مدیریت راز، سیاست تحویل و پایش runtime اجزای آن‌اند.
«shift left» فقط افزودن scanner به CI نیست؛ بازخورد زودتر و قابل اقدام است. در کنار آن «shift right» رفتار واقعی و رخداد production را می‌بیند. تیم امنیت guardrail و مسیر مشورت می‌سازد و تیم محصول مالک رفع ریسک می‌ماند. هر یافته نیز نباید pipeline را بدون توجه به شدت متوقف کند؛ policy باید exploitability، محیط، استثنا و مهلت اصلاح را روشن کند.
۳۷. امنیت زیرساخت چیست؟#
پاسخ کوتاه: امنیت زیرساخت حفاظت از compute، network، storage، control plane، هویت و مسیر مدیریت است. هدف کاهش احتمال دسترسی نامجاز، محدودکردن blast radius و حفظ محرمانگی، یکپارچگی و دسترس‌پذیری است.
کنترل‌ها شامل inventory، patch، hardening، least privilege، MFA، جداسازی شبکه، رمزنگاری، backup و ثبت رویدادند. فایروال تنها یک لایه است. حساب مدیریتی، pipeline و API ابر نیز بخشی از سطح حمله‌اند. پاسخ خوب چرخهٔ کنترل را می‌گوید: وضعیت مطلوب تعریف می‌شود، تغییر از مسیر مجاز می‌آید، انحراف دیده می‌شود و بازیابی آزموده می‌ماند. امنیت بدون دارایی‌شناسی و owner قابل سنجش نیست.
۳۸. امنیت container چیست؟#
پاسخ کوتاه: امنیت container زنجیرهٔ ساخت تا اجرا را پوشش می‌دهد: منبع و وابستگی، image و registry، runtime، میزبان و orchestrator. image حداقلی، اسکن و امضا، کاربر غیرریشه، filesystem فقط‌خواندنی و محدودیت capability نمونهٔ کنترل‌اند.
اسکن image فقط آسیب‌پذیری شناخته‌شده را نشان می‌دهد و پیکربندی بد یا منطق آسیب‌پذیر برنامه را کامل نمی‌بیند. tag قابل جابه‌جایی است؛ digest هویت محتوایی دقیق‌تری می‌دهد. mountکردن socket Docker یا اجرای privileged مرز جداسازی را شدیداً ضعیف می‌کند. secret نباید در layer image یا environment قابل افشای گسترده قرار گیرد. patch نیز با rebuild و redeploy image انجام می‌شود، نه تغییر دستی containerهای پراکنده.
۳۹. compliance as code چیست؟#
پاسخ کوتاه: compliance as code تبدیل کنترل‌های انطباق به policy و آزمون ماشین‌خوان است تا در زمان طراحی، pipeline و runtime ارزیابی شوند. مثال آن ردکردن storage عمومی یا الزام encryption و tag مالکیت است.
کد کردن کنترل، مدرک انطباق را تکرارپذیر می‌کند، ولی خودبه‌خود اثبات حقوقی کامل نیست. هر policy باید به الزام، owner، نسخه و روش استثنا وصل شود. کنترل پیشگیرانه تغییر نامجاز را متوقف می‌کند و کنترل تشخیصی انحراف موجود را گزارش می‌دهد. نتیجه‌ها باید قابل ممیزی و false positiveها مدیریت شوند. اگر قاعده‌ای بی‌توضیح همهٔ deployها را می‌بندد، تیم احتمالاً راه دورزدن پیدا می‌کند.
۴۰. بهترین رویه‌های امنیتی در DevOps کدام‌اند؟#
پاسخ کوتاه: حداقل‌دسترسی و credential کوتاه‌عمر، جداسازی وظایف حساس، مدیریت secret، patch و inventory، review و آزمون خودکار، حفاظت زنجیرهٔ تأمین، ثبت رویداد و برنامهٔ پاسخ به رخداد پایه‌های مشترک‌اند.
«best practice» نسخهٔ واحد برای همه نیست؛ threat model و ریسک تعیین می‌کند چه کنترلی لازم است. runner CI باید ephemeral و محدود باشد، artifact با provenance قابل ردگیری تولید شود و انتشار production از شاخه و محیط محافظت‌شده بیاید. backup تغییرناپذیر بدون آزمون restore کافی نیست. مهم‌تر از تعداد ابزار، بستن حلقه است: یافته owner و مهلت دارد، رفع آن راستی‌آزمایی می‌شود و استثنا تاریخ انقضا دارد.
جمع‌بندی مصاحبه‌ای#
در پاسخ‌های پایش بگویید چه signalی، برای کدام تصمیم و با چه واکنشی جمع می‌شود. در پاسخ‌های امنیت نیز دارایی، تهدید، کنترل و روش راستی‌آزمایی را کنار هم بگذارید. این ساختار جلوی دو پاسخ ضعیف را می‌گیرد: فهرست ابزارهای بی‌هدف و فهرست کنترل‌های بدون مدل تهدید.