Nəzarətli SCADA server dəyişiklikləri üçün Ansible-dan istifadə

Ansible SCADA tətbiq serverlərində, tarixçə serverlərində, mühəndis iş stansiyalarında və dəstəkləyici şəbəkə cihazlarında təkrarlana bilən dəyişiklikləri standartlaşdıra bilər. Bu, sərhədlər müəyyən edilmədən idarəetmə aktivlərinin avtomatlaşdırılmasına icazə kimi qəbul edilməməlidir. Mühəndislik tapşırığı nəyin, harada və necə dəyişdirilə biləcəyini, həmçinin obyektin nəticəni necə sübut edə biləcəyini müəyyənləşdirməkdir.

Bu təlimat SCADA sistemi ətrafında idarə olunan infrastruktur dəyişikliklərinə yönəlib. Burada PLC məntiqinin dəyişdirilməsi və ya müəssisə prosedurlarından yan keçilməsi təklif edilmir. Ən təhlükəsiz başlanğıc adətən sınaq mühiti və server tərəfində dar əhatəli tapşırıqdır.

Ansible OT arxitekturasında hansı rolu oynayır

Ansible idarə olunan hostları müəyyənləşdirmək üçün inventarlardan, arzu olunan tapşırıqları təsvir etmək üçün isə playbook-lardan istifadə edir. Rəsmi Ansible inventar təlimatı hostların, qrupların və dəyişənlərin avtomatlaşdırma hədəflərini necə müəyyən etdiyini izah edir.

Sənaye obyektində bu hədəflərə SCADA serverləri, keçid hostları, yamaq depoları, ehtiyat nüsxə serverləri və idarə olunan şəbəkə avadanlıqları daxil ola bilər. PLC-lər və təhlükəsizlik sistemləri ayrıca nəzərdən keçirilməlidir. Təchizatçı dəstəyi, protokol davranışı və dəyişikliklərə nəzarət normal server administrasiyasından fərqlənir.

Praktik arxitekturada Ansible idarəetmə qovşağı idarə olunan zonada yerləşdirilir. Onun idarəetmə şəbəkəsinə məhdudiyyətsiz çıxışı olmamalıdır. Firewall qaydaları, adlandırılmış hesablar və təsdiqlənmiş giriş məlumatları hər playbook-un yalnız nəzərdə tutulan sistemlərə tətbiqini məhdudlaşdırmalıdır.

Daha geniş arxitekturanı nəzərdən keçirən oxucular əlaqəli idarəetmə və şəbəkə konteksti üçün PLC ProTech-in Bilik kitabxanasından və Rabitə və şəbəkələşmə kolleksiyasından istifadə edə bilərlər.

Dar əhatəli və geri qaytarıla bilən istifadə ssenarisi ilə başlayın

Yaxşı ilk tapşırıqların girişləri aydın və geri qaytarılması asan olur. Nümunələrə təsdiqlənmiş konfiqurasiya faylının kopyalanması, xidmətin vəziyyətinin yoxlanılması, versiya məlumatlarının toplanması və ya ehtiyat nüsxənin mövcudluğunun təsdiqlənməsi daxildir.

Firmware yeniləmələri, kontrollerə yükləmələr, təhlükəsizlik konfiqurasiyası və genişmiqyaslı firewall dəyişiklikləri ilə başlamaqdan çəkinin. Bu fəaliyyətlər istehsal davranışını dəyişə bilər. Həmçinin daha güclü təchizatçı sübutları və müəssisəyə xas sınaqlar tələb edir.

Hər tapşırıq üçün playbook-u yazmazdan əvvəl gözlənilən vəziyyəti müəyyənləşdirin. İştirak edən faylları, xidmətləri, portları, hesabları və asılılıqları qeyd edin. Dəyişməz qalmalı olanları bildirin.

İnventarı funksiyaya və riskə görə ayırın

Bütün OT hostlarını fərqləndirilməmiş vahid inventara yerləşdirməyin. Sistemləri obyektə, funksiyaya, mühitə və nəticələrin ağırlığına görə qruplaşdırın. İnkişaf SCADA serverləri istehsal serverləri ilə eyni hədəf nümunəsini paylaşmamalıdır.

Hər təsdiqlənmiş dəyişiklik pəncərəsi üçün konkret host qruplarından istifadə edin. Host dəyişənlərini versiya nəzarəti altında saxlayın. İnventardakı dəyişiklikləri playbook dəyişiklikləri qədər diqqətlə nəzərdən keçirin. Düzgün tapşırığın yanlış hosta göndərilməsi də uğursuzluqdur.

Dinamik inventar faydalı ola bilər, lakin əlavə məlumat mənbəyi yaradır. Mühəndislər hostların inventara necə daxil olduğunu və ya oradan necə çıxarıldığını təsdiqləməlidirlər. Köhnəlmiş aktiv qeydi avtomatlaşdırmanı istismardan çıxarılmış və ya başqa məqsədlə istifadə olunan avadanlığa yönəldə bilər.

İdempotent playbook-lar hazırlayın

İdempotent tapşırıq hər icra zamanı lazımsız dəyişikliklər etmədən tələb olunan vəziyyətə çatır. Bu, təkrar icranı daha anlaşılan edir və qarşısı alına bilən yenidən başladılmaları azaldır.

Hədəf platformanı dəstəklədikdə məqsədyönlü modullardan istifadə edin. Shell əmrləri əlavə təsirləri gizlədə və qeyri-müəyyən nəticələr qaytara bilər. Əmrdən istifadə qaçılmazdırsa, onun şərtlərini, gözlənilən qaytarma kodlarını və geri qaytarma davranışını müəyyənləşdirin.

Handler-lər yalnız əlaqəli konfiqurasiya dəyişdikdə xidmətləri yenidən başlatmalıdır. Ardıcıllıqla icra təsirlənən qovşaqların sayını məhdudlaşdıra bilər. Kiçik paket ölçüsü monitorinqi və geri qaytarmanı da daha idarəolunan edir.

İstehsal icrasından əvvəl yoxlayın

Sintaksis yoxlaması struktur səhvlərini aşkar edir, lakin dəyişikliklərin təhlükəsiz olduğunu sübut etmir. Ansible yoxlama rejimi dəstəklənən tapşırıqları simulyasiya edir, fərq rejimi isə təklif olunan fayl dəyişikliklərini göstərə bilər. Rəsmi yoxlama və fərq rejimi sənədlərində onların məhdudiyyətləri də qeyd olunur.

Bəzi modullar yoxlama rejimini tam dəstəkləmir. Qeydiyyata alınmış dəyişənlər və şərti tapşırıqlar simulyasiya zamanı fərqli davrana bilər. Fərq çıxışı məxfi məlumatları üzə çıxara bilər. Bu alətləri daha geniş sınaq prosesinin tərkibində sübut kimi qəbul edin.

Əvvəlcə playbook-u təmsilçi sınaq hostunda icra edin. Sonra məhdud istehsal kanareykası istifadə edin. Hədəf qrupunu genişləndirməzdən əvvəl tətbiqin sağlamlığını, həyəcan siqnallarını, rabitəni, tarixçə məlumatlarının toplanmasını, vaxt sinxronizasiyasını və operatorun görünürlüğünü təsdiqləyin.

Giriş məlumatlarını və jurnalları qoruyun

Tələb olunan minimum səlahiyyətlərə malik adlandırılmış xidmət hesablarından istifadə edin. Ortaq administrator giriş məlumatlarından çəkinin. Məxfi məlumatları təsdiqlənmiş seyfdə saxlayın və playbook çıxışının parolları, tokenləri, sertifikatları və ya şəxsi açarları göstərməsinin qarşısını alın.

Jurnallarda sorğunu edən şəxs, nəzərdən keçirən şəxs, playbook versiyası, inventar, başlanma vaxtı, nəticə və dəyişdirilmiş elementlər göstərilməlidir. Qeydləri qorunan məkana göndərin. İdarəetmə qovşağındakı yerli jurnallar həmin qovşaq sıradan çıxarsa, kifayət etmir.

Dəyişikliyə geri qaytarmanı daxil edin

Geri qaytarma “ehtiyat nüsxəni bərpa edin” ifadəsindən daha konkret olmalıdır. İcradan əvvəl dəqiq faylları, paketləri, xidmət vəziyyətlərini və tətbiq versiyalarını qeydə alın. Bərpa yolunu təmsilçi sistemdə sınaqdan keçirin.

Bəzi dəyişiklikləri istehsal zamanı təhlükəsiz şəkildə geri qaytarmaq mümkün deyil. Verilənlər bazası sxemində dəyişikliklər və firmware yeniləmələri buna ümumi nümunələrdir. Belə hallarda plana texniki xidmət dayanması, təchizatçı təlimatı və bərpa vasitələri daxil edilməlidir.

Əməliyyat yoxlama siyahısı

• Playbook-un sahibini, nəzərdən keçirən şəxsi və təsdiqlənmiş dəyişiklik sorğusunu təsdiqləyin.
• İnventarı adları göstərilən hostlar və düzgün mühitlə məhdudlaşdırın.
• İcradan əvvəl ehtiyat nüsxələri və bərpa təlimatlarını yoxlayın.
• Dəstəkləndiyi hallarda sintaksis yoxlamalarını, yoxlama rejimini və sınaq hostunda sınağı icra edin.
• Ardıcıl paketlərdən və müəyyən edilmiş dayandırma şərtlərindən istifadə edin.
• SCADA xidmətlərini, rabitəni, həyəcan siqnallarını və məlumat toplanmasını monitorinq edin.
• Playbook versiyasını, jurnalları, nəticələri və geri qaytarma sübutlarını arxivləşdirin.

Yekun

Ansible SCADA infrastrukturunda konfiqurasiya yayınmalarını və əl ilə edilən dəyişikliklər arasındakı fərqləri azalda bilər. Onun dəyəri daha çox dəyişikliyi daha sürətli icra etməkdə deyil, təkrarlana bilən sübutlardadır. Server tərəfində sərhədləri müəyyən edilmiş tapşırıqlarla başlayın, inventarları riskə görə ayırın, hər playbook-u sınaqdan keçirin və sınaqdan keçirilmiş bərpa yolunu qoruyun.