กลับไปยังบล็อก

การใช้ Ansible เพื่อควบคุมการเปลี่ยนแปลงเซิร์ฟเวอร์ SCADA

ใช้ Ansible เพื่อทำให้การเปลี่ยนแปลงเซิร์ฟเวอร์ SCADA เป็นมาตรฐานโดยไม่เพิ่มความเสี่ยงต่อ OT คู่มือนี้ครอบคลุมอินเวนทอรี เพลย์บุ๊กแบบไอดีมโพเทนต์ การทดสอบแบบเป็นขั้นตอน ข้อมูลรับรอง การบันทึกล็อก แ...

Ansible สามารถทำให้การเปลี่ยนแปลงที่ทำซ้ำได้บนเซิร์ฟเวอร์แอปพลิเคชัน SCADA ระบบจัดเก็บประวัติข้อมูล เวิร์กสเตชันวิศวกรรม และอุปกรณ์เครือข่ายสนับสนุนเป็นมาตรฐานเดียวกันได้ แต่ไม่ควรถือว่าเป็นการอนุญาตให้ทำระบบควบคุมโดยอัตโนมัติโดยไม่มีขอบเขต งานวิศวกรรมคือการกำหนดว่าอะไรเปลี่ยนแปลงได้ เปลี่ยนได้ที่ใด และไซต์จะพิสูจน์ผลลัพธ์ได้อย่างไร

คู่มือนี้มุ่งเน้นการเปลี่ยนแปลงโครงสร้างพื้นฐานที่มีการควบคุมรอบระบบ SCADA โดยไม่ได้เสนอให้เปลี่ยนตรรกะของ PLC หรือหลีกเลี่ยงขั้นตอนปฏิบัติของโรงงาน จุดเริ่มต้นที่ปลอดภัยที่สุดมักเป็นสภาพแวดล้อมทดสอบและงานฝั่งเซิร์ฟเวอร์ที่มีขอบเขตแคบ

Ansible เหมาะกับสถาปัตยกรรม OT ตรงไหน

Ansible ใช้ inventory เพื่อระบุโฮสต์ที่อยู่ภายใต้การจัดการ และใช้ playbook เพื่ออธิบายงานที่ต้องการ เอกสารคู่มือ inventory ของ Ansible อย่างเป็นทางการอธิบายว่าโฮสต์ กลุ่ม และตัวแปรใช้กำหนดเป้าหมายของระบบอัตโนมัติอย่างไร

ในไซต์อุตสาหกรรม เป้าหมายเหล่านี้อาจรวมถึงเซิร์ฟเวอร์ SCADA jump host ที่เก็บแพตช์ เซิร์ฟเวอร์สำรองข้อมูล และอุปกรณ์เครือข่ายที่อยู่ภายใต้การจัดการ ส่วน PLC และระบบความปลอดภัยจำเป็นต้องได้รับการทบทวนแยกต่างหาก การสนับสนุนจากผู้จำหน่าย พฤติกรรมของโปรโตคอล และการควบคุมการเปลี่ยนแปลงแตกต่างจากการดูแลเซิร์ฟเวอร์ทั่วไป

สถาปัตยกรรมที่เหมาะสมควรให้โหนดควบคุม Ansible อยู่ในโซนที่มีการจัดการ และไม่ควรเปิดให้เข้าถึงเครือข่ายควบคุมได้อย่างไร้ข้อจำกัด กฎไฟร์วอลล์ บัญชีที่ระบุชื่อ และข้อมูลรับรองที่ได้รับอนุมัติควรจำกัดให้แต่ละ playbook เข้าถึงเฉพาะระบบที่กำหนดไว้

ผู้อ่านที่ทบทวนสถาปัตยกรรมโดยรวมสามารถใช้คลังความรู้ของ PLC ProTech และคอลเลกชันการสื่อสารและเครือข่ายเพื่อศึกษาบริบทที่เกี่ยวข้องกับระบบควบคุมและเครือข่าย

เริ่มจากกรณีใช้งานที่มีขอบเขตแคบและย้อนกลับได้

งานเริ่มต้นที่ดีควรมีอินพุตชัดเจนและย้อนกลับได้ง่าย ตัวอย่างเช่น การคัดลอกไฟล์การกำหนดค่าที่ผ่านการตรวจสอบแล้ว การตรวจสอบสถานะบริการ การรวบรวมข้อมูลเวอร์ชัน หรือการยืนยันว่ามีข้อมูลสำรองอยู่

หลีกเลี่ยงการเริ่มต้นด้วยการอัปเดตเฟิร์มแวร์ การดาวน์โหลดไปยังคอนโทรลเลอร์ การกำหนดค่าระบบความปลอดภัย หรือการเปลี่ยนแปลงไฟร์วอลล์ในวงกว้าง กิจกรรมเหล่านี้อาจเปลี่ยนแปลงพฤติกรรมของการผลิต และยังต้องใช้หลักฐานจากผู้จำหน่ายและการทดสอบเฉพาะของโรงงานที่เข้มงวดยิ่งขึ้น

สำหรับแต่ละงาน ให้กำหนดสถานะที่คาดหวังก่อนเขียน playbook บันทึกว่าเกี่ยวข้องกับไฟล์ บริการ พอร์ต บัญชี และการพึ่งพาใดบ้าง พร้อมระบุสิ่งที่ต้องไม่เปลี่ยนแปลง

แยก inventory ตามหน้าที่และความเสี่ยง

อย่านำโฮสต์ OT ทั้งหมดใส่ไว้ใน inventory เดียวโดยไม่แบ่งแยก ให้จัดกลุ่มระบบตามไซต์ หน้าที่ สภาพแวดล้อม และผลกระทบที่อาจเกิดขึ้น เซิร์ฟเวอร์ SCADA สำหรับการพัฒนาไม่ควรใช้รูปแบบเป้าหมายเดียวกับเซิร์ฟเวอร์สำหรับการผลิต

ใช้กลุ่มโฮสต์ที่ระบุอย่างชัดเจนสำหรับช่วงเวลาการเปลี่ยนแปลงที่ได้รับอนุมัติ เก็บตัวแปรของโฮสต์ไว้ภายใต้การควบคุมเวอร์ชัน และทบทวนการเปลี่ยนแปลง inventory ด้วยความละเอียดรอบคอบเช่นเดียวกับการเปลี่ยนแปลง playbook งานที่ถูกต้องแต่ส่งไปยังโฮสต์ผิดก็ยังถือเป็นความล้มเหลว

inventory แบบไดนามิกอาจมีประโยชน์ แต่จะเพิ่มแหล่งข้อมูลอีกหนึ่งแห่ง วิศวกรควรยืนยันว่าโฮสต์ถูกเพิ่มหรือนำออกจาก inventory อย่างไร ระเบียนสินทรัพย์ที่ล้าสมัยอาจทำให้ระบบอัตโนมัติทำงานกับอุปกรณ์ที่เลิกใช้งานแล้วหรือถูกนำไปใช้ใหม่

ออกแบบ playbook แบบ Idempotent

งานแบบ idempotent จะทำให้ระบบเข้าสู่สถานะที่ต้องการโดยไม่ทำการเปลี่ยนแปลงที่ไม่จำเป็นทุกครั้งที่รัน วิธีนี้ช่วยให้เข้าใจการทำงานซ้ำได้ง่ายขึ้นและลดการรีสตาร์ตที่หลีกเลี่ยงได้

ใช้โมดูลเฉพาะทางเมื่อรองรับแพลตฟอร์มเป้าหมาย คำสั่ง Shell อาจซ่อนผลข้างเคียงและคืนผลลัพธ์ที่คลุมเครือ หากหลีกเลี่ยงคำสั่งไม่ได้ ให้กำหนดเงื่อนไข รหัสผลลัพธ์ที่คาดหวัง และพฤติกรรมเมื่อย้อนกลับไว้อย่างชัดเจน

ตัวจัดการควรรีสตาร์ตบริการเฉพาะเมื่อการกำหนดค่าที่เกี่ยวข้องมีการเปลี่ยนแปลง การทำงานแบบลำดับสามารถจำกัดจำนวนโหนดที่ได้รับผลกระทบได้ และขนาดชุดงานที่เล็กยังช่วยให้ติดตามและย้อนกลับการเปลี่ยนแปลงได้ง่ายขึ้น

ตรวจสอบก่อนดำเนินการในระบบจริง

การตรวจสอบไวยากรณ์ช่วยตรวจจับข้อผิดพลาดด้านโครงสร้าง แต่ไม่สามารถพิสูจน์ได้ว่าการเปลี่ยนแปลงนั้นปลอดภัย โหมด check ของ Ansible จะจำลองงานที่รองรับ ส่วนโหมด diff สามารถแสดงการเปลี่ยนแปลงไฟล์ที่เสนอ เอกสารโหมด check และ diffอย่างเป็นทางการยังระบุข้อจำกัดของทั้งสองโหมดด้วย

โมดูลบางตัวไม่รองรับโหมด check อย่างเต็มรูปแบบ ตัวแปรที่ลงทะเบียนไว้และงานแบบมีเงื่อนไขอาจทำงานแตกต่างกันระหว่างการจำลอง ผลลัพธ์จาก diff อาจเปิดเผยข้อมูลลับ ให้ถือว่าเครื่องมือเหล่านี้เป็นหลักฐานส่วนหนึ่งของกระบวนการทดสอบที่กว้างขึ้น

รัน playbook กับโฮสต์ทดสอบที่เป็นตัวแทนก่อน จากนั้นใช้ canary ที่จำกัดในระบบจริง ตรวจสอบสุขภาพของแอปพลิเคชัน สัญญาณเตือน การสื่อสาร การเก็บข้อมูลของระบบจัดเก็บประวัติ การซิงโครไนซ์เวลา และการมองเห็นของผู้ปฏิบัติงาน ก่อนขยายกลุ่มเป้าหมาย

ปกป้องข้อมูลรับรองและบันทึก

ใช้บัญชีบริการที่ระบุชื่อและมีสิทธิ์เท่าที่จำเป็น หลีกเลี่ยงการใช้ข้อมูลรับรองผู้ดูแลระบบร่วมกัน จัดเก็บข้อมูลลับไว้ในห้องนิรภัยที่ได้รับอนุมัติ และป้องกันไม่ให้เอาต์พุตของ playbook เปิดเผยรหัสผ่าน โทเค็น ใบรับรอง หรือคีย์ส่วนตัว

บันทึกควรระบุผู้ร้องขอ ผู้ตรวจสอบ เวอร์ชันของ playbook inventory เวลาเริ่มต้น ผลลัพธ์ และรายการที่เปลี่ยนแปลง ส่งระเบียนไปยังตำแหน่งที่ได้รับการปกป้อง บันทึกภายในโหนดควบคุมเพียงอย่างเดียวไม่เพียงพอหากโหนดนั้นขัดข้อง

สร้างการย้อนกลับไว้ในการเปลี่ยนแปลง

การย้อนกลับต้องมีรายละเอียดมากกว่าเพียงคำว่า “กู้คืนข้อมูลสำรอง” ให้บันทึกไฟล์ แพ็กเกจ สถานะบริการ และเวอร์ชันแอปพลิเคชันที่แน่นอนก่อนดำเนินการ และทดสอบเส้นทางการกู้คืนบนระบบที่เป็นตัวแทน

การเปลี่ยนแปลงบางอย่างไม่สามารถย้อนกลับได้อย่างปลอดภัยระหว่างการผลิต การเปลี่ยนแปลงสคีมาฐานข้อมูลและการอัปเดตเฟิร์มแวร์เป็นตัวอย่างที่พบบ่อย สำหรับกรณีเหล่านี้ แผนงานจำเป็นต้องมีช่วงหยุดซ่อมบำรุง คำแนะนำจากผู้จำหน่าย และสื่อสำหรับการกู้คืน

รายการตรวจสอบการปฏิบัติงาน

  • ยืนยันเจ้าของ playbook ผู้ตรวจสอบ และใบคำขอเปลี่ยนแปลงที่ได้รับอนุมัติ
  • จำกัด inventory ให้เหลือเฉพาะโฮสต์ที่ระบุชื่อและสภาพแวดล้อมที่ถูกต้อง
  • ตรวจสอบข้อมูลสำรองและคำแนะนำการกู้คืนก่อนดำเนินการ
  • รันการตรวจสอบไวยากรณ์ โหมด check และการทดลองบนโฮสต์ทดสอบเมื่อรองรับ
  • ใช้ชุดงานแบบลำดับและเงื่อนไขหยุดที่กำหนดไว้
  • ติดตามบริการ SCADA การสื่อสาร สัญญาณเตือน และการเก็บข้อมูล
  • จัดเก็บเวอร์ชันของ playbook บันทึก ผลลัพธ์ และหลักฐานการย้อนกลับ

สรุป

Ansible สามารถลดความคลาดเคลื่อนของการกำหนดค่าและความแตกต่างจากการทำงานด้วยตนเองรอบโครงสร้างพื้นฐาน SCADA คุณค่าของ Ansible มาจากหลักฐานที่ทำซ้ำได้ ไม่ใช่จากการทำให้การเปลี่ยนแปลงจำนวนมากขึ้นเสร็จเร็วขึ้น เริ่มจากงานฝั่งเซิร์ฟเวอร์ที่มีขอบเขตชัดเจน แยก inventory ตามความเสี่ยง ทดสอบ playbook แต่ละรายการ และรักษาเส้นทางการกู้คืนที่ผ่านการทดสอบแล้ว

แสดงความคิดเห็น

โปรดทราบว่าความคิดเห็นจะต้องได้รับการอนุมัติก่อนที่จะได้รับการเผยแพร่