Menggunakan Ansible untuk Perubahan Terkawal pada Pelayan SCADA

Ansible boleh menyeragamkan perubahan berulang pada pelayan aplikasi SCADA, pengumpul sejarah, stesen kerja kejuruteraan dan peranti rangkaian sokongan. Ia tidak seharusnya dianggap sebagai kebenaran untuk mengautomasikan aset kawalan tanpa batasan. Tugas kejuruteraan adalah untuk menentukan perkara yang boleh berubah, lokasi perubahan itu boleh berlaku dan cara tapak tersebut membuktikan hasilnya.

Panduan ini memfokuskan perubahan infrastruktur terkawal di sekitar sistem SCADA. Panduan ini tidak mencadangkan penggantian logik PLC atau pemintasan prosedur loji. Titik permulaan paling selamat biasanya ialah persekitaran ujian dan tugas sisi pelayan yang terhad.

Peranan Ansible dalam Seni Bina OT

Ansible menggunakan inventori untuk mengenal pasti hos terurus dan playbook untuk menerangkan tugas yang dikehendaki. Panduan inventori Ansible rasmi menerangkan cara hos, kumpulan dan pemboleh ubah mentakrifkan sasaran automasi.

Di tapak perindustrian, sasaran tersebut mungkin merangkumi pelayan SCADA, hos lompat, repositori tampalan, pelayan sandaran dan peralatan rangkaian terurus. PLC dan sistem keselamatan memerlukan semakan berasingan. Sokongan vendor, tingkah laku protokol dan kawalan perubahan berbeza daripada pentadbiran pelayan biasa.

Seni bina praktikal menempatkan nod kawalan Ansible dalam zon terurus. Nod tersebut tidak seharusnya mempunyai capaian tanpa had merentasi rangkaian kawalan. Peraturan tembok api, akaun bernama dan bukti kelayakan yang diluluskan hendaklah mengehadkan setiap playbook kepada sistem yang dimaksudkan.

Pembaca yang menyemak seni bina lebih luas boleh menggunakan pustaka Pengetahuan PLC ProTech dan koleksi Komunikasi & Rangkaian untuk konteks kawalan dan rangkaian yang berkaitan.

Mulakan dengan Kes Penggunaan yang Terhad dan Boleh Dipulihkan

Tugas pertama yang baik mempunyai input yang jelas dan proses pemulihan yang mudah. Contohnya termasuk menyalin fail konfigurasi yang telah disahkan, menyemak status perkhidmatan, mengumpulkan data versi atau mengesahkan bahawa sandaran wujud.

Elakkan memulakan dengan kemas kini perisian tegar, muat turun pengawal, konfigurasi keselamatan atau perubahan tembok api yang meluas. Aktiviti tersebut boleh mengubah tingkah laku pengeluaran. Aktiviti itu juga memerlukan bukti vendor dan ujian khusus loji yang lebih kukuh.

Bagi setiap tugas, tentukan keadaan yang dijangka sebelum menulis playbook. Catat fail, perkhidmatan, port, akaun dan kebergantungan yang terlibat. Nyatakan perkara yang sepatutnya kekal tidak berubah.

Asingkan Inventori Mengikut Fungsi dan Risiko

Jangan letakkan semua hos OT dalam satu inventori yang tidak dibezakan. Kumpulkan sistem mengikut tapak, fungsi, persekitaran dan kesan. Pelayan SCADA pembangunan tidak seharusnya berkongsi corak sasaran yang sama dengan pelayan pengeluaran.

Gunakan kumpulan hos yang jelas bagi setiap tetingkap perubahan yang diluluskan. Simpan pemboleh ubah hos di bawah kawalan versi. Semak perubahan pada inventori dengan ketelitian yang sama seperti perubahan pada playbook. Tugas yang betul tetapi dihantar kepada hos yang salah tetap merupakan kegagalan.

Inventori dinamik boleh berguna, tetapi ia memperkenalkan satu lagi sumber data. Jurutera hendaklah mengesahkan cara hos dimasukkan ke dalam atau dikeluarkan daripada inventori. Rekod aset yang lapuk boleh mengarahkan automasi kepada peralatan yang telah dinyahaktifkan atau digunakan semula.

Reka Bentuk Playbook Idempoten

Tugas idempoten mencapai keadaan yang diperlukan tanpa membuat perubahan yang tidak perlu pada setiap pelaksanaan. Hal ini memudahkan pelaksanaan berulang difahami dan mengurangkan mula semula yang boleh dielakkan.

Gunakan modul khusus apabila modul tersebut menyokong platform sasaran. Perintah shell boleh menyembunyikan kesan sampingan dan menghasilkan keputusan yang tidak jelas. Jika perintah tidak dapat dielakkan, takrifkan syaratnya, kod pulangan yang dijangka dan tingkah laku pemulihannya.

Pengendali hendaklah memulakan semula perkhidmatan hanya apabila konfigurasi yang berkaitan berubah. Pelaksanaan bersiri boleh mengehadkan bilangan nod yang terjejas. Saiz kelompok yang kecil juga memudahkan pemantauan dan pemulihan.

Sahkan Sebelum Pelaksanaan Pengeluaran

Pengesahan sintaks mengesan kesilapan struktur, tetapi tidak membuktikan bahawa perubahan itu selamat. Mod semakan Ansible mensimulasikan tugas yang disokong, manakala mod perbezaan boleh menunjukkan perubahan fail yang dicadangkan. Dokumentasi mod semakan dan perbezaan rasmi turut menyatakan batasannya.

Sesetengah modul tidak menyokong mod semakan sepenuhnya. Pemboleh ubah yang didaftarkan dan tugas bersyarat mungkin berkelakuan berbeza semasa simulasi. Output perbezaan boleh mendedahkan rahsia. Anggap alat ini sebagai bukti dalam proses ujian yang lebih menyeluruh.

Jalankan playbook terlebih dahulu terhadap hos ujian yang mewakili keadaan sebenar. Kemudian gunakan canary pengeluaran yang terhad. Sahkan kesihatan aplikasi, penggera, komunikasi, pengumpulan data sejarah, penyegerakan masa dan keterlihatan operator sebelum meluaskan kumpulan sasaran.

Lindungi Bukti Kelayakan dan Log

Gunakan akaun perkhidmatan bernama dengan hak minimum yang diperlukan. Elakkan penggunaan bukti kelayakan pentadbir yang dikongsi. Simpan rahsia dalam peti besi yang diluluskan dan cegah output playbook daripada mendedahkan kata laluan, token, sijil atau kunci peribadi.

Log hendaklah mengenal pasti pemohon, penyemak, versi playbook, inventori, masa mula, hasil dan item yang berubah. Hantar rekod ke lokasi yang dilindungi. Log setempat pada nod kawalan tidak mencukupi jika nod tersebut gagal.

Bina Proses Pemulihan dalam Perubahan

Proses pemulihan mesti lebih khusus daripada sekadar “pulihkan sandaran”. Tangkap fail, pakej, keadaan perkhidmatan dan versi aplikasi yang tepat sebelum pelaksanaan. Uji laluan pemulihan pada sistem yang mewakili keadaan sebenar.

Sesetengah perubahan tidak boleh dipulihkan dengan selamat semasa pengeluaran. Perubahan skema pangkalan data dan kemas kini perisian tegar ialah contoh biasa. Bagi perubahan ini, pelan tersebut memerlukan masa henti penyelenggaraan, panduan vendor dan media pemulihan.

Senarai Semak Operasi

• Sahkan pemilik, penyemak dan tiket perubahan yang diluluskan bagi playbook.
• Hadkan inventori kepada hos bernama dan persekitaran yang betul.
• Sahkan sandaran dan arahan pemulihan sebelum pelaksanaan.
• Jalankan semakan sintaks, mod semakan dan percubaan pada hos ujian jika disokong.
• Gunakan kelompok bersiri dan syarat henti yang ditetapkan.
• Pantau perkhidmatan SCADA, komunikasi, penggera dan pengumpulan data.
• Arkibkan versi playbook, log, hasil dan bukti pemulihan.

Kesimpulan

Ansible boleh mengurangkan hanyutan konfigurasi dan variasi manual di sekitar infrastruktur SCADA. Nilainya datang daripada bukti yang boleh diulang, bukannya daripada menjalankan lebih banyak perubahan dengan lebih pantas. Mulakan dengan tugas pelayan yang mempunyai batasan, asingkan inventori mengikut risiko, uji setiap playbook dan kekalkan laluan pemulihan yang telah diuji.