استفاده از انسیبل برای اعمال کنترل‌شده تغییرات در سرور اسکادا

Ansible می‌تواند تغییرات تکرارشونده را در سرورهای برنامه SCADA، تاریخچه‌نگارها، ایستگاه‌های کاری مهندسی و تجهیزات شبکه پشتیبان استاندارد کند. نباید آن را مجوزی برای خودکارسازی دارایی‌های کنترلی بدون تعیین مرزها تلقی کرد. وظیفه مهندسی این است که مشخص کند چه چیزی، در کجا و چگونه می‌تواند تغییر کند و سایت چگونه می‌تواند نتیجه را اثبات کند.

این راهنما بر تغییرات کنترل‌شده زیرساختی پیرامون یک سیستم SCADA تمرکز دارد. هدف آن جایگزین‌کردن منطق PLC یا دورزدن رویه‌های کارخانه نیست. معمولاً امن‌ترین نقطه شروع، یک محیط آزمایشی و یک کار محدود در سمت سرور است.

Ansible در معماری OT کجا قرار می‌گیرد

Ansible از inventoryها برای شناسایی میزبان‌های مدیریت‌شده و از playbookها برای شرح وظایف موردنظر استفاده می‌کند. راهنمای رسمی inventory در Ansible توضیح می‌دهد که میزبان‌ها، گروه‌ها و متغیرها چگونه اهداف خودکارسازی را تعریف می‌کنند.

در یک سایت صنعتی، این اهداف می‌توانند شامل سرورهای SCADA، میزبان‌های پرش، مخازن وصله، سرورهای پشتیبان‌گیری و تجهیزات شبکه مدیریت‌شده باشند. PLCها و سیستم‌های ایمنی به بررسی جداگانه نیاز دارند. پشتیبانی فروشنده، رفتار پروتکل و کنترل‌های تغییر با مدیریت عادی سرورها متفاوت است.

در یک معماری عملی، گره کنترل Ansible در یک ناحیه مدیریت‌شده قرار می‌گیرد. این گره نباید دسترسی نامحدود به سراسر شبکه کنترل داشته باشد. قوانین فایروال، حساب‌های نام‌دار و اعتبارنامه‌های تأییدشده باید هر playbook را به سیستم‌های موردنظر آن محدود کنند.

خوانندگانی که معماری گسترده‌تر را بررسی می‌کنند، می‌توانند برای زمینه مرتبط با کنترل و شبکه به کتابخانه دانش PLC ProTech و مجموعه ارتباطات و شبکه مراجعه کنند.

با یک مورد استفاده محدود و برگشت‌پذیر شروع کنید

کارهای مناسب برای شروع، ورودی‌های مشخص و بازگشت آسان دارند. نمونه‌ها شامل کپی‌کردن یک فایل پیکربندی تأییدشده، بررسی وضعیت یک سرویس، جمع‌آوری اطلاعات نسخه یا تأیید وجود یک نسخه پشتیبان هستند.

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

برای هر کار، پیش از نوشتن playbook وضعیت موردانتظار را تعریف کنید. فایل‌ها، سرویس‌ها، درگاه‌ها، حساب‌ها و وابستگی‌های درگیر را ثبت کنید. مشخص کنید چه چیزهایی باید بدون تغییر باقی بمانند.

Inventory را بر اساس کارکرد و ریسک جدا کنید

همه میزبان‌های OT را در یک inventory یکپارچه و بدون تفکیک قرار ندهید. سیستم‌ها را بر اساس سایت، کارکرد، محیط و پیامد گروه‌بندی کنید. سرورهای SCADA توسعه نباید الگوی هدف یکسانی با سرورهای تولید داشته باشند.

برای هر بازه زمانی تغییرِ تأییدشده، گروه‌های صریح میزبان ایجاد کنید. متغیرهای میزبان را تحت کنترل نسخه نگه دارید. تغییرات inventory را با همان دقت تغییرات playbook بررسی کنید. ارسال یک کار صحیح به میزبان اشتباه همچنان شکست محسوب می‌شود.

Inventory پویا می‌تواند مفید باشد، اما یک منبع داده دیگر ایجاد می‌کند. مهندسان باید تأیید کنند که میزبان‌ها چگونه وارد inventory می‌شوند یا از آن خارج می‌شوند. یک رکورد قدیمی دارایی می‌تواند خودکارسازی را به سمت تجهیزات بازنشسته یا تغییرکاربری‌یافته هدایت کند.

Playbookهای idempotent طراحی کنید

یک کار idempotent بدون ایجاد تغییرات غیرضروری در هر اجرا، به وضعیت موردنیاز می‌رسد. این ویژگی درک اجرای تکراری را آسان‌تر می‌کند و راه‌اندازی‌های مجدد قابل اجتناب را کاهش می‌دهد.

هرگاه ماژول‌های اختصاصی از پلتفرم هدف پشتیبانی می‌کنند، از آن‌ها استفاده کنید. فرمان‌های پوسته می‌توانند عوارض جانبی را پنهان کنند و نتایج مبهمی برگردانند. اگر استفاده از فرمان اجتناب‌ناپذیر است، شرایط اجرا، کدهای بازگشت موردانتظار و رفتار بازگشت را تعریف کنید.

Handlerها باید فقط هنگام تغییر پیکربندی مرتبط، سرویس‌ها را راه‌اندازی مجدد کنند. اجرای ترتیبی می‌تواند تعداد گره‌های تحت‌تأثیر را محدود کند. اندازه کوچک دسته نیز پایش و بازگشت را قابل‌کنترل‌تر می‌کند.

پیش از اجرای تولید اعتبارسنجی کنید

اعتبارسنجی نحوی خطاهای ساختاری را شناسایی می‌کند، اما ایمن‌بودن تغییر را ثابت نمی‌کند. حالت بررسی Ansible وظایف پشتیبانی‌شده را شبیه‌سازی می‌کند و حالت diff می‌تواند تغییرات پیشنهادی فایل‌ها را نشان دهد. مستندات رسمی حالت بررسی و diff نیز به محدودیت‌های آن‌ها اشاره می‌کند.

برخی ماژول‌ها از حالت بررسی به‌طور کامل پشتیبانی نمی‌کنند. متغیرهای ثبت‌شده و کارهای شرطی ممکن است هنگام شبیه‌سازی متفاوت عمل کنند. خروجی diff می‌تواند اسرار را آشکار کند. این ابزارها را بخشی از شواهد در یک فرایند آزمون گسترده‌تر در نظر بگیرید.

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

از اعتبارنامه‌ها و گزارش‌ها محافظت کنید

از حساب‌های سرویس نام‌دار با حداقل سطح دسترسی موردنیاز استفاده کنید. از اعتبارنامه‌های مشترک مدیر سیستم اجتناب کنید. اسرار را در یک خزانه تأییدشده ذخیره کنید و مانع نمایش گذرواژه‌ها، توکن‌ها، گواهی‌ها یا کلیدهای خصوصی در خروجی playbook شوید.

گزارش‌ها باید درخواست‌کننده، بازبین، نسخه playbook، inventory، زمان شروع، نتیجه و موارد تغییر‌یافته را مشخص کنند. سوابق را به یک محل محافظت‌شده ارسال کنید. گزارش‌های محلی روی گره کنترل، در صورت خرابی آن گره، کافی نیستند.

بازگشت را در خود تغییر بگنجانید

بازگشت باید دقیق‌تر از عبارت «نسخه پشتیبان را بازیابی کنید» باشد. فایل‌ها، بسته‌ها، وضعیت سرویس‌ها و نسخه‌های برنامه را پیش از اجرا به‌طور دقیق ثبت کنید. مسیر بازیابی را روی یک سیستم نماینده آزمایش کنید.

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

فهرست بررسی عملیاتی

• مالک، بازبین و تیکت تغییر تأییدشده playbook را مشخص کنید.
• Inventory را به میزبان‌های نام‌برده و محیط صحیح محدود کنید.
• پیش از اجرا، نسخه‌های پشتیبان و دستورالعمل‌های بازیابی را تأیید کنید.
• بررسی نحوی، حالت بررسی و آزمایش روی میزبان آزمایشی را، در صورت پشتیبانی، اجرا کنید.
• از دسته‌های ترتیبی و شرایط توقف تعریف‌شده استفاده کنید.
• سرویس‌های SCADA، ارتباطات، هشدارها و جمع‌آوری داده را پایش کنید.
• نسخه playbook، گزارش‌ها، نتایج و شواهد بازگشت را بایگانی کنید.

جمع‌بندی

Ansible می‌تواند انحراف پیکربندی و تفاوت‌های ناشی از کار دستی را در زیرساخت SCADA کاهش دهد. ارزش آن از شواهد تکرارپذیر ناشی می‌شود، نه از اجرای سریع‌تر تغییرات بیشتر. با کارهای محدود در سمت سرور شروع کنید، inventoryها را بر اساس ریسک جدا کنید، هر playbook را آزمایش کنید و یک مسیر بازیابی آزموده‌شده را حفظ کنید.