แนวทางการใช้งาน Ignition Cloud Edition แบบ Hosted / Multi-tenant

Inductive Automation ยินดีที่จะอนุญาตให้ใช้Licensing สำหรับแอปพลิเคชันแบบ Hosted และ Multi-tenant โดยไม่มีค่าใช้จ่ายเพิ่มเติมแก่ผู้ได้รับLicensee เมื่อใช้งาน Ignition Cloud Edition โดยการ Hosting ช่วยให้สามารถแบ่งปันทรัพยากรได้อย่างยืดหยุ่น และรองรับโมเดลบริการแบบ “pay as you go” ส่วน Multi-tenancy ช่วยให้สามารถส่งมอบแอปพลิเคชัน Ignition ที่ปรับแต่งเองในรูปแบบบริการ (as a Service) ได้ในวงกว้าง การเปลี่ยนแปลงนี้ช่วยส่งเสริมบทบาทใหม่ๆ ของ Service Provider ซึ่งมีศักยภาพในการสร้างประโยชน์แก่ชุมชน Ignition โดยรวม อย่างไรก็ตาม โมเดลเหล่านี้ย่อมมาพร้อมกับความเสี่ยงสำหรับ Stakeholders โดยธรรมชาติ

ในฐานะที่เป็นเครื่องมือออกแบบซอฟต์แวร์แบบอเนกประสงค์ (General-purpose) Ignition ช่วยขับเคลื่อนแอปพลิเคชันที่ผู้ใช้สร้างขึ้นหลากหลายรูปแบบ ตั้งแต่เครื่องมือแชร์ข้อมูลที่มีผลกระทบต่ำ ไปจนถึงระบบที่มีผลกระทบสูงซึ่งเชื่อมต่อกับ Critical Infrastructure ในพื้นที่ที่มีการควบคุมดูแล (Regulated spaces) ระบบ Ignition มีส่วนร่วมในการรับความเสี่ยงด้านความปลอดภัย (Safety), การรักษาความลับ (Confidentiality), ความถูกต้องสมบูรณ์ (Integrity) และความพร้อมใช้งาน (Availability) ของสภาพแวดล้อม Process โดยรวมรวมถึงระบบที่เชื่อมต่อ ข้อกำหนดด้าน Configuration, Architecture และการดำเนินงานจะแตกต่างกันอย่างมากตามแอปพลิเคชัน แนวทางจัดการความเสี่ยงแบบ "one size fits all" จึงไม่เหมาะสมอย่างยิ่งสำหรับแอปพลิเคชัน Ignition และการแชร์ทรัพยากรร่วมกันย่อมเพิ่มความเสี่ยงด้าน Security, Privacy และ Performance โดยธรรมชาติ

วัตถุประสงค์

คู่มือนี้จัดทำขึ้นเพื่อปูพื้นฐานให้ Stakeholders เข้าใจถึงข้อควรพิจารณาและความเสี่ยงที่เกี่ยวข้องกับแอปพลิเคชัน Ignition แบบ Hosted หรือ Multi-tenant โดยคู่มือนี้เป็นเพียงส่วนเสริม ไม่ใช่สิ่งที่มาทดแทน Quality Assurance และ Security Engineering เฉพาะโครงการที่ได้รับการสนับสนุนโดยผู้เชี่ยวชาญเฉพาะทาง 

แนะนำคำควรรู้

• Ignition Application (Application): แอปพลิเคชัน Runtime ที่พัฒนาขึ้นบน Ignition โดยอาจมีการแชร์สิทธิ์การเข้าถึงเพื่อประโยชน์ของบุคคลที่สาม ซึ่งมักหมายถึงโครงการ Ignition Perspective ที่รันบนเว็บเบราว์เซอร์สมัยใหม่
  
• Privileged Ignition Access (Privileged Access): สิทธิ์เข้าถึงระดับสูงภายในระบบ Ignition ได้แก่ สิทธิ์ “Application Design” (บทบาท Designer) หรือ “Ignition Configuration” (บทบาท Gateway config) โดย Privileged Access จะจำกัดไว้เฉพาะ End User รายเดียวและบุคคลที่ได้รับความไว้วางใจที่กำหนดไว้ต่อหนึ่ง License
  
• End User (EU): องค์กรที่ใช้งาน Ignition Applications ซึ่งมักจะเป็น Licensee ของ Ignition โดย EU อาจจะมีหรือไม่มี Privileged Ignition Access ก็ได้ ทั้งนี้ หากหลายองค์กรมีความสัมพันธ์ทางธุรกิจร่วมกันและใช้สิทธิ์ Privileged Access ระดับเดียวกัน จะถือว่าเป็น EU เดียวกัน
  
• Single Tenant: รูปแบบ Architecture ที่แต่ละ EU จะได้รับการจัดสรร Ignition Gateway แบบส่วนตัว (Dedicated) การออกแบบและ Configure แอปพลิเคชัน Ignition จะจำกัดอยู่เฉพาะ EU นั้นๆ แต่อาจเปิดให้แชร์หรือมอบหมายสิทธิ์ได้ โดย Single Tenant Architecture สามารถดูแลโดย EU เองหรือใช้บริการ Hosting ก็ได้ ซึ่งปกติแล้ว EU จะเป็น Licensee
  
• Multi-tenant: รูปแบบ Architecture ที่เปิดให้ End Users หลายรายใช้งาน Ignition Application ร่วมกันผ่าน Ignition Gateway เดียวกัน ทั้งนี้ Privileged Access จะถูกจำกัดไว้เฉพาะ Licensee รายเดียวและพาร์ทเนอร์ที่ได้รับความไว้วางใจเท่านั้น การให้ Privileged Access แบบ Multi-tenant ถือเป็นแนวทางปฏิบัติที่ไม่ปลอดภัย (Poor security practice) และข้อตกลง License ห้ามทำเช่นนี้
  
• Hosting: โมเดลการให้บริการ Ignition หรือทรัพยากรประมวลผล (Compute resources) แก่ EUs ซึ่งมักเชื่อมโยงกับ Cloud Services, ทรัพยากรที่ใช้ร่วมกัน และ Shared Responsibility Model โดยโมเดล Hosting สามารถเสนอได้ทั้งแบบ Single Tenancy หรือ Multi-tenancy สำหรับแต่ละ Ignition Gateway
  
• Ignition Service Provider (“Host”): Stakeholder ที่จัดการโครงสร้างพื้นฐาน Ignition เพื่อประโยชน์ของฝ่ายอื่น มักจะพึ่งพา Cloud Service Providers แต่ไม่จำเป็นต้องเป็นเช่นนั้นเสมอไป Host อาจเสนอบริการอื่นๆ เช่น การปรับแต่งแอปพลิเคชัน (Customization), Validation, จัดทำเอกสาร, Regulatory Compliance หรือความสามารถทางเทคนิคต่างๆ
  
• Ignition Management Model: โมเดลที่อธิบายการบริหารจัดการระบบ Ignition ได้แก่ Customer Managed, Hosted และ Multi-tenant Hosted โดย Customer Managed จะคล้ายกับโมเดล On-premises หรือ IT แบบดั้งเดิมที่สุด (แม้อาจรวม Cloud Computing ด้วย) ส่วนโมเดล Hosted คือการที่มี Host คอยจัดการโครงสร้างพื้นฐาน Ignition ให้ และ Multi-tenant จะเพิ่มตัวเลือกให้หลาย EUs เข้าถึง Ignition Applications ร่วมกันได้ ซึ่งจะจำกัด Privileged Access โดยธรรมชาติ
  
• Shared Responsibility Model: แนวคิดที่ Stakeholders ร่วมกันรับผิดชอบในแง่มุมต่างๆ ภายในสภาพแวดล้อม Hosted หรือ Multi-tenant ซึ่ง Cloud Service Providers มักจะมีแนวทางอ้างอิงให้

Roles and Responsibilities

• End User: มีหน้าที่กำหนดความเหมาะสมสำหรับอุตสาหกรรม แอปพลิเคชัน และระดับความเสี่ยงที่ยอมรับได้ (Risk appetite) ของตนเอง ซึ่งรวมถึงงาน Due diligence ที่องค์กรต้องทำสำหรับบริการ SaaS / PaaS / IaaS ทั่วไป ทั้งนี้เนื่องจากลักษณะทางอุตสาหกรรมของ Ignition จึงมักครอบคลุม Stakeholders ทั้งจากฝ่าย Operational Technology (OT) และ Information Technology (IT) โดยความสัมพันธ์ทางธุรกิจทั่วไประหว่าง EUs กับ Inductive Automation (IA) คือ EU เป็น Licensee ของ Ignition ซึ่งอาจรวมถึงสัญญา Software Support ด้วย ทั้งนี้ IA แนะนำให้ปรึกษาผู้เชี่ยวชาญเฉพาะทาง เช่น System Integrator ที่มีความเชี่ยวชาญในโดเมนนั้นๆ (ดูมาตรฐาน ISA/IEC 62443-2-x ภายใต้บทบาท “Asset Owner” สำหรับ Best practices ทั่วไป)
  
• System Integrator: System Integrators (SIs) มักเสนอบริการออกแบบ จัดทำ (Implementation) และดูแลแอปพลิเคชันแก่ EUs ซึ่งมักครอบคลุมเกินกว่าขอบเขตของ Ignition โดย SI มักจะถือครอง Privileged Ignition Access ผ่านความสัมพันธ์ทางธุรกิจกับ EU ทั้งนี้ Inductive Automation มี Integrator Program ที่มอบสิทธิประโยชน์และ Software Support ให้แก่ SIs รวมถึงช่วยประสานการติดต่อกับ EUs แต่ IA จะไม่มีส่วนเกี่ยวข้องกับตัวโครงการหรือแอปพลิเคชันซึ่งเป็นข้อตกลงระหว่าง EUs และ SIs โดยตรง (ดูมาตรฐาน ISA/IEC 62443-3-x สำหรับข้อแนะนำในการทำ Integration)
  
• Inductive Automation: บทบาทของ Inductive Automation (IA) คือการส่งมอบซอฟต์แวร์ Ignition รวมถึงการอัปเดตซอฟต์แวร์ตามรอบ เอกสารประกอบ การฝึกอบรม และ Technical support (สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับ Software Development Lifecycle (SDLC) ของ IA ซึ่งได้รับการรับรองมาตรฐาน ISASecure และ IEC 62443-4-1 ได้ที่พอร์ทัล Security and Trust) ทั้งนี้ IA ไม่ได้ให้บริการ Hosting และไม่มีสิทธิ์เข้าถึงข้อมูล เน็ตเวิร์ก หรือระบบของ EU โดย IA จะเน้นการสนับสนุนด้านเอกสาร Software Support การจัดอบรม และส่งเสริมความร่วมมือในชุมชน Ignition
  
• Ignition Service Provider: Ignition Service Providers (“Hosts”) นำเสนอบริการเกี่ยวกับ Ignition ที่หลากหลาย ตั้งแต่โครงสร้างพื้นฐานไปจนถึงบริการระดับแอปพลิเคชัน โดยอาจมีการรับรองระบบจากภายนอก (External certification) และให้บริการอื่นๆ ที่เกี่ยวข้อง เช่น การจัดทำเอกสาร Validation ความสามารถทางเทคนิค และ Automated configuration ซึ่ง Hosts มักจะใช้บริการจากผู้ให้บริการรายอื่น เช่น Cloud Service Providers (CSPs) สำหรับโครงสร้างพื้นฐาน ผู้ให้บริการ Cybersecurity หรือบริการจาก Third party เช่น Voice notification, Federated Identity Providers หรือ Data archiving ทั้งนี้ เป็นหน้าที่ของ Hosts ในการกำหนดข้อกำหนดตามข้อเสนอของตน และดูแลให้ลูกค้าใช้งานอยู่ภายใต้ขอบเขตที่ยอมรับได้ ซึ่งความสัมพันธ์นี้เป็นข้อตกลงระหว่าง EU และ Host โดยตรง Inductive Automation ไม่ได้เป็นคู่สัญญากับบริการที่รันบน Ignition เหล่านี้
• 
  

Stakeholder Role Diagrams

แผนภาพเหล่านี้แสดงกรอบแนวคิด (Conceptual frameworks) สำหรับการประยุกต์ใช้ Ignition Shared Responsibility Model โดยโมเดล Stakeholder จะแบ่งออกเป็น 3 หมวดหมู่หลักตามแนวคิด ได้แก่ “Customer managed”, “Hosted” และ “Multi-tenant hosted” ทั้งนี้ อาจมีรูปแบบการจัดเตรียมอื่นๆ ที่นอกเหนือจากนี้ได้ โดยรายละเอียดจะขึ้นอยู่กับการตกลงร่วมกันระหว่าง Stakeholders

สำหรับบทบาทสมมติ (Notional roles) ในแผนภาพจะมีการใช้รหัสสีเพื่อระบุความหมาย ดังนี้:

• ข้อความสีดำ: แสดงบทบาทและความรับผิดชอบหลัก
  
• ข้อความสีน้ำเงิน: แสดงบทบาททางเลือก (Optional role) ซึ่งมักเน้นให้เห็นถึงตัวเลือกในการออกแบบ (Design choice)
  
• ข้อความสีแดง: แสดงฟังก์ชันหรือการทำงานที่ไม่ได้รับอนุญาต (Not allowed)

Shared Responsibility Model

รูปภาพนี้ แสดงบทบาทและความรับผิดชอบที่เป็นไปได้ระหว่าง Stakeholders ของระบบที่ทำงานบน Ignition ทั้งแบบ Hosted หรือ Multi-tenant ในบริบทของโมเดล SaaS / PaaS / IaaS (XaaS) แบบดั้งเดิม

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

Shared Responsibility Model - Example Roles

รูปภาพที่สองนี้ มีจุดประสงค์เพื่อสื่อสารบทบาทและความรับผิดชอบสมมติ (Notional roles and responsibilities) ที่เกี่ยวข้องกับโมเดล Stakeholder ต่างๆ โดยมีรายละเอียดดังนี้:

• ข้อความตัวหนา: แสดงถึงบทบาทสำคัญ (Key roles)
  
• ข้อความสีน้ำเงิน: เน้นความรับผิดชอบที่มีตัวเลือกในการกำหนดหรือมอบหมาย (Designation options)
  
• คำว่า “Owns infrastructure”: อ้างอิงถึงขอบเขตความรับผิดชอบตามที่ระบุไว้ ซึ่งไม่จำเป็นต้องหมายถึงการเป็นเจ้าของทางกายภาพ (Physical ownership) เสมอไป

Ignition Management Model Resource View

รูปที่ 3 และ 4 มีจุดประสงค์เพื่อสื่อสารการใช้งานทรัพยากรแบบแชร์ร่วมกัน (Shared resources) เปรียบเทียบกับแบบจัดสรรเฉพาะ (Dedicated resources)

ในมุมมองของ Ignition การดูแลรักษา Gateway แบบ Dedicated ให้กับแต่ละ EU (Figure 3) จะถือว่าเป็น Single tenancy แม้ว่าจะเป็นการรันแบบ Hosted ก็ตาม ส่วน Figure 4 แสดงให้เห็นกรณีที่หลาย EUs เข้าถึง Ignition Applications ร่วมกันบน Gateway เดียวกัน ซึ่งถือว่าเป็น Ignition application multi-tenancy

การแชร์ทรัพยากรร่วมกันระหว่าง EUs จะเพิ่มความเสี่ยงเมื่อเทียบกับการจัดสรรทรัพยากรแบบ Dedicated ให้กับแต่ละ EU ดังนั้น Architecture ของ Ignition ใน รูปที่ 3 จึงมักจะมีความเสี่ยงต่ำกว่า Architecture ใน รูปที่ 4

Risk Factors

แอปพลิเคชันแบบ Hosted และ Multi-tenant ย่อมนำมาซึ่งปัจจัยเสี่ยงเพิ่มเติมโดยธรรมชาติ การบริหารจัดการและการสื่อสารปัจจัยเสี่ยงอย่างชัดเจนจึงเป็นเรื่องสำคัญเมื่อวางแผนใช้งานแอปพลิเคชันแบบ Hosted หรือ Multi-tenant

Application customization and variety on a shared Gateway

การปรับแต่ง (Customization) แอปพลิเคชัน Ignition ที่เพิ่มมากขึ้น จะเพิ่มความเสี่ยงโดยรวมแก่ผู้ใช้งานทุกคนบน Gateway เดียวกันที่มีการใช้แอปพลิเคชันแบบ Multi-tenant ทั้งนี้ End Users ที่เข้าถึงแอปพลิเคชันเดียวกันเพื่อจุดประสงค์คล้ายกัน มักจะมี Risk profile ที่สอดคล้องกัน การ Host แอปพลิเคชันประเภทต่างกันไว้บน Ignition Gateway เดียวกันจึงเป็นการเพิ่มความเสี่ยงให้กับ Multi-tenant EUs การแยก Gateway ตาม EU, ประเภทแอปพลิเคชัน หรือ Risk profile อย่างเหมาะสมจะช่วยลดความเสี่ยงโดยรวมลงได้

Differing risk tolerance

Stakeholders อาจต้องเผชิญกับความเสี่ยงที่ไม่พึงประสงค์อันเกิดจากการปฏิบัติของฝ่ายอื่นที่เชื่อมต่ออยู่ ซึ่งอาจเกิดจากความแตกต่างของข้อกำหนด (Requirements) เพียงอย่างเดียว และซ้ำร้ายยิ่งขึ้นหากมีการปฏิบัติที่ไม่ดี การกำหนดความคาดหวังและกฎเกณฑ์ที่ชัดเจนระหว่าง Stakeholders จึงเป็นสิ่งจำเป็นสำหรับ Shared Responsibility Models

ลองพิจารณาตัวอย่างสมมติของระบบที่มีระดับ “low-impact”, “medium-impact” และ “high-impact”:

• Host ให้บริการระบบ Hosted บน Ignition Cloud Edition ที่มี Security เหมาะสมสำหรับระดับ “medium-impact”
  
• EU1 เชื่อมต่อระบบที่มีความละเอียดอ่อน ปลอดภัยสูง และเป็นระดับ “high-impact” เข้ากับ Host
  
• ระบบของ EU2 เป็นระดับ “low-impact” โดย EU2 ยอมรับความเสี่ยงที่เกิดจากการขาด Security controls และแนวปฏิบัติที่ไม่รัดกุม รวมถึงการเชื่อมต่อกับ Third party ที่ไม่สามารถควบคุมได้หลายรายการตาม Risk profile ของตนเอง
  

เห็นได้ชัดว่าการที่ EU2 เชื่อมต่อกับ Host ก่อให้เกิดปัญหาสำหรับ EU1 เพราะในมุมมองของ EU1 การเชื่อมต่อกับ Third party ที่ไม่รู้จักกลายเป็นเชื่อมต่อทางอ้อมกับระบบของตนเอง และบริการ Hosting ก็นิยมคุ้มครองจุดเชื่อมต่อร่วม (Common connection points) ได้ไม่เพียงพอ

การแยกสภาพแวดล้อมที่ทำงานบน Ignition ตามระดับผลกระทบ (Impact), Requirements, Risk appetite หรือประเภทแอปพลิเคชัน สามารถช่วยบริหารจัดการความเสี่ยงโดยรวมได้ การสื่อสารที่ชัดเจนเกี่ยวกับวัตถุประสงค์การใช้งานและความคาดหวังจึงมีความสำคัญ เพื่อสร้างความเข้าใจร่วมกันให้กับ Stakeholders ทุกฝ่าย

Privileged Access

Privileged access ของ Ignition ถูกนิยามถึงบทบาท Ignition Designer หรือ Gateway Configuration โดยสิทธิ์ Privileged access ใดๆ บน Ignition จะมอบความสามารถแบบเต็มรูปแบบครอบคลุมทั้ง Ignition Gateway ตามการออกแบบ ข้อตกลง License ของ Ignition จึงไม่อนุญาตให้มี Privileged access จากหลาย EUs บน Ignition Gateway เดียวกัน โดย Privileged access ของ Ignition ควรมองว่าเป็น Security role เดียวตามการออกแบบ และบริหารจัดการในระดับ Per-Gateway

ทั้งนี้ EU อาจมอบ Privileged access ให้แก่ฝ่ายที่ไว้วางใจได้ เช่น System Integrator, Partner หรือ Host แต่ต้องระมัดระวังเป็นพิเศษสำหรับ EUs ที่อาจเป็นคู่แข่งกันบน Gateway เดียวกัน ส่วนสิทธิ์ Privileged access ในระดับที่ต่ำกว่า เช่น สิทธิ์ระดับ Root ของ Operating System ก็ควรมองด้วยความเข้าใจในลักษณะเดียวกัน

Data Management

Data confidentiality, integrity และ availability มักเป็นข้อพิจารณาที่สำคัญสำหรับ End Users ควรพิจารณาเรื่อง Data classification รวมถึงวิธีการจัดเก็บและบริหารจัดการข้อมูล การปะปนกันของข้อมูล EU ภายใน Database หรือบริการร่วม ย่อมเพิ่มความเสี่ยงแก่ Stakeholders จึงควรพิจารณา Data lifecycle ทั้งหมด ซึ่งรวมถึงการวางแผน การสำรองข้อมูล (Backups) การเข้าถึง การจัดการ และการลบข้อมูล

End User site network connections

การเชื่อมต่อ Remote connections และเครือข่าย Third Party ไปยัง End Users (หรือ Host) ถือเป็นแหล่งความเสี่ยงต่อทุกฝ่ายที่เชื่อมต่อ ซึ่งรวมถึงการเชื่อมต่อแบบถาวร ชั่วคราว และการเชื่อมต่อที่เริ่มโดยผู้ใช้งาน (User-initiated connections) ทั้งนี้ การเชื่อมต่อที่ไม่น่าไว้วางใจ (Untrusted connections) จะกลายเป็นปัญหาอย่างยิ่งเมื่อระดับความเสี่ยงหรือการจัดหมวดหมู่ข้อมูลมีความแตกต่างกันอย่างมากระหว่างฝ่ายต่างๆ ที่เชื่อมต่อ

ควรพิจารณาการเชื่อมต่อในมุมมองของ Stakeholder แต่ละฝ่าย ซึ่งเป็นเรื่องปกติที่ Host จะระบุความคาดหวังอย่างชัดเจน และแสดงหลักฐานความน่าเชื่อถือให้แก่ EU แต่ละราย โดยมักจะอยู่ในรูปแบบของเอกสาร, การรับรองจาก Third party (Third party certifications), แบบสอบถาม และการตรวจสอบ (Audits)

OT network architecture network segmentation

Ignition Cloud Editionไม่ได้ถูกออกแบบมาเพื่อให้เชื่อมต่อกับ อุปกรณ์ (Devices) หรือ Cyber-physical systems โดยตรง ด้วยเหตุนี้จึงไม่ได้รวม Device drivers มาให้ ควรพิจารณาใช้ Segmented architectures และการทำ Segmentation ที่เหมาะสมเมื่อต้องเชื่อมต่อกับ Devices, บริการต่างๆ และ Databases ทั้งนี้ การทำ Segmentation หลายชั้น (Multiple layers) ถือเป็นเรื่องปกติจาก Edge ไปจนถึง Cloud มาตรฐานและ Framework ที่ได้รับการยอมรับในอุตสาหกรรม เช่น ISA/IEC 62443 ได้ให้ Best practices สำหรับ Network segmentation ไว้ จึงควรพิจารณาเชื่อมต่อเฉพาะ Network segments ที่จำเป็นเท่านั้น

User access network segmentation

การเข้าถึงแอปพลิเคชัน Ignition ในวงกว้างของผู้ใช้ โดยเฉพาะอย่างยิ่ง Privileged access และการเชื่อมต่อ Internet จะสร้าง Attack surface การปกป้องหรือลดขนาดของ Surface นี้ เช่น การใช้ Secure remote access หรือ Private networks สามารถช่วยลดความเสี่ยงได้ ผู้ให้บริการ Cloud มี Best practices ในอุตสาหกรรม เช่น “Well-Architected Frameworks”

การเข้าถึงของผู้ใช้ควรได้รับการปกป้องและแยกออกจาก Network segments อื่นๆ ของ Ignition เช่น Databases, อุปกรณ์ OT และ Enterprise หรือ Web services นอกจากนี้ EUs ควรแยกออกจากกันในรูปแบบ Multi-tenant construct

Appendix A - Getting Started

Extra Consideration

การใช้งาน Ignition ในรูปแบบระบบ Hosted หรือ Multi-tenant จำเป็นต้องมีข้อพิจารณาเพิ่มเติม โดยเป็นหน้าที่และความรับผิดชอบของ End User และ Hosts ในการกำหนดความต้องการสำหรับ Use case ของตนเอง

การดึง Stakeholders ทุกฝ่ายเข้ามาร่วมวางแผนตั้งแต่เนิ่นๆ และเริ่มต้นจาก Ignition Security Hardening Guide ถือเป็นแนวทางที่ดีที่สุด ทั้งนี้ โครงการ Cloud และ Multi-tenant มักต้องการทักษะเพิ่มเติมและนำมาซึ่งความเสี่ยง โดยหัวข้อเพิ่มเติมที่ควรพิจารณาเมื่อวางแผนโครงการแบบ Hosted หรือ Multi-tenant มีดังนี้:

Planning

• บริการใดบ้างที่จะถูกนำเสนอ?
  
• สภาพแวดล้อม (Environment) และวัตถุประสงค์การใช้งานเป็นอย่างไร?
  
• จำเป็นต้องมี Service Level Agreements (SLAs) หรือไม่?
  
• มีการแยกสภาพแวดล้อมการทำงานออกจากกันหรือไม่ (เช่น Dev, Test, Prod)? (ดูรายละเอียดเพิ่มเติมที่ Ignition 8 Deployment Best Practices)
  
• การเปลี่ยนแปลงแอปพลิเคชัน (Application changes) มีขั้นตอนอย่างไร? มี Workflow หรือไม่?
  
• แผนงานครอบคลุมการ Upgrade / Patching เซิร์ฟเวอร์ Ignition หรือไม่?
  
• แผนงานครอบคลุมการ Testing หรือไม่?
  
• แผนงานครอบคลุมการจัดเก็บข้อมูล (Data retention) หรือไม่?
  
• แผนงานครอบคลุมการทำ Backups, Disaster Recovery และ Business Continuity หรือไม่?
  
• แผนงานครอบคลุมการยกเลิกการใช้งานโครงการ (Project decommissioning) หรือไม่?
  
• User lifecycle มีขั้นตอนอย่างไร รวมถึงเรื่อง ข้อตกลง (Agreement), Billing, Connection, การใช้งาน, Modification, Scaling และ Decommissioning?
  
• จำเป็นต้องใช้ Multi-factor Authentication (MFA) หรือไม่?
  
• ข้อกำหนดด้าน Auditing ของ EU คืออะไร?
  
• โครงสร้างพื้นฐาน IT หรือ OT ที่มีอยู่เดิมสามารถรองรับ Architecture ที่นำเสนอได้หรือไม่?
  
• จำเป็นต้องมีผู้ให้บริการ Security, Incident Responders หรือ Stakeholders อื่นๆ หรือไม่?
  

Monitoring

• จัดทำแผนสำหรับการติดตามและเฝ้าระวัง (Monitoring) สภาพแวดล้อม Cloud ของคุณ
  
• มีการทำ Security monitoring ให้หรือไม่?
  
• มีการครอบคลุม Performance monitoring หรือไม่?
  
• เรื่องนี้จัดการโดย Cloud provider หรือผู้ให้บริการรายอื่น?
  
• ความรับผิดชอบภายในองค์กร (In-house) มีอะไรบ้าง?
  

Architecture

• การจัดทำแผนเมื่อส่งข้อมูลไปยัง Cloud: เมื่อส่งข้อมูลไปยัง Cloud ให้พิจารณาตัวเลือกด้าน Security ในทุกชั้น (Layers) ที่เป็นไปได้ เนื่องจากโปรโตคอลสื่อสารฝั่งอุตสาหกรรม (Industrial communication protocols) หลายตัวไม่ผ่านเกณฑ์มาตรฐาน Security สมัยใหม่ขั้นพื้นฐาน จึงมักจำเป็นต้องมี External security controls โดยแนวทางปฏิบัติที่ดีที่สุด (Best practice) ที่ยอมรับกันทั่วไป คือการเชื่อมต่ออุปกรณ์ OT เข้ากับ Local Gateway ที่รองรับการเชื่อมต่อที่ปลอดภัย จากนั้นจึงส่งผ่านข้อมูลด้วยหลากหลายวิธีการที่รองรับการเข้ารหัสที่รัดกุม (Strong encryption) เช่น Ignition’s Gateway Network, OPC-UA, MQTT, REST API endpoints ทั้งนี้ ควรโน้ตไว้ว่าลูกค้าบางรายอาจมีความต้องการเฉพาะ (หรือข้อกำหนดทางกฎหมาย) ที่ระบุพื้นที่ทางภูมิศาสตร์หรือเครือข่ายที่กำหนดไว้ โดย Best practice ทั่วไปคือการปกป้องโครงสร้างเครือข่ายชั้นล่าง (Underlying network transport layer) ที่อยู่ใต้ Application communication layer เมื่อสามารถทำได้
  

• การสร้าง Scalable Architecture บน Cloud: เมื่อพัฒนา Cloud Ignition Architecture ให้ตั้งคำถามต่อไปนี้:

  • มีแผนจะแยก Frontend และ Backend ออกจากกันเมื่อใด?
    
  • มีแผนจะเพิ่ม I/O servers ใหม่เมื่อใด?
    
  • มีแผนจะเพิ่ม Frontend servers ใหม่เมื่อใด?
    
  • แผนสำหรับ High Availability หรือ Redundancy เป็นอย่างไร?
    
  • มี SLAs เฉพาะร่วมกับลูกค้าของคุณหรือไม่?
    

Customer Isolation

เมื่อมีลูกค้าหลายรายใช้งาน Gateway เดียวกัน การแยก Project, Device และ Data ของ End User (EU) แต่ละรายออกจากกันจึงเป็นเรื่องสำคัญ แม้ว่าจะมีการให้บริการ Role-based Access Control (RBAC) แต่การทำ Segmentation ที่สมบูรณ์กว่ามักเป็นสิ่งจำเป็น

ควรมีแผนสำหรับ Lifecycle ของข้อมูลลูกค้าและ Service instances รวมถึง: การสร้าง, การแก้ไข, การดูแลรักษา และการลบออก โดยเน้นการใช้ Automation เป็นหลัก

คำถามเกี่ยวกับการทำ Segmentation โดยรวม:

• มีการทำ Data segmentation อย่างไร?
  
• มีการทำ Tag segmentation อย่างไร?
  
• มีการแยกลูกค้าออกจากกันอย่างไร?
  
• สำหรับการเชื่อมต่อผ่าน MQTT/Sparkplug ลูกค้าแต่ละรายมี Access Control List (ACL) ที่ควบคุมสิทธิ์การ Publish และ Subscribe ข้อมูลหรือไม่?
  
• จำเป็นต้องใช้ Identity Providers (IDP) แยกต่างหากสำหรับการ Authentication และ Authorization หรือไม่? (Identity สามารถบริหารจัดการแบบรวมศูนย์ หรือ Configure ให้กระจายสิทธิ์ (Delegate) สำหรับการจัดการของ EU โดยใช้ IDP แยกตามแต่ละ EU ก็ได้)
  
• Projects ของลูกค้าอันไหนบ้างที่จำเป็นต้องแยกออกจากกัน?
  
• จำเป็นต้องทำ Network segmentation ในส่วนใดบ้าง? (พิจารณา IEC 62443 “zones and conduits”, “Purdue Model” และ Cloud “well architected frameworks”)
  
• จำเป็นต้องมี External security controls หรือบริการภายนอกใดบ้าง?
  
• จำเป็นต้องมี Common services ใดบ้าง? และจำเป็นต้องใช้ Credentials แยกต่างหากหรือไม่?
  

ไอเดียในการแยก Projects ของลูกค้า:

• หากต้องการซ่อน Projects ของลูกค้าไม่ให้ End Users รายอื่นเห็น สามารถซ่อนจากหน้าเปิดใช้งานได้โดยเลือก “Hide from Launch Page and Native Apps” ใน Project Properties โดยจะต้องมีการส่ง Links ไปยัง Projects ให้แก่ End Users โดยตรง (เช่น Single domain / direct project links, Subdomains, Separate domains เป็นต้น)
  
• แยกการเข้าถึงภายนอก Ignition ด้วยเทคโนโลยีภายนอก เช่น Load balancers
  
• แยก Tag providers
  
• แยก Alarm journal profiles
  
• แยก Audit logs
  
• แยก User sources
  
• แยกข้อมูลลูกค้าบนพื้นฐาน Per-user (เช่น Databases, Schemas, Tables) โดยลดการปะปนกันของข้อมูลให้มากที่สุด

คู่มือการใช้งาน Ignition Cloud Edition แบบ Hosted และ Multi-tenant เน้นย้ำว่าการแชร์ทรัพยากรร่วมกันระหว่างผู้ใช้งานหลายราย แม้ช่วยเพิ่มความยืดหยุ่นและลดต้นทุน แต่ก็เพิ่มความเสี่ยงด้าน Security, Data Privacy และ Performance อย่างมีนัยสำคัญ จึงห้ามแชร์สิทธิ์ Privileged Access แก่หลาย End User บน Gateway เดียวกันโดยเด็ดขาด ทั้งนี้ ภายใต้ Shared Responsibility Model ทาง Inductive Automation จะรับผิดชอบเพียงการส่งมอบซอฟต์แวร์ ส่วนผู้ให้บริการ (Host) และ End User (ทั้งฝั่ง IT และ OT) จะต้องร่วมกันบริหารจัดการความเสี่ยงด้วยการแยกข้อมูลและโปรเจกต์ของลูกค้าออกจากกันอย่างชัดเจน (Customer Isolation) ควบคู่กับการทำ Network Segmentation ตามมาตรฐานอุตสาหกรรมอย่าง ISA/IEC 62443 เพื่อความปลอดภัยสูงสุดของระบบ

นัดหมายขอคำปรึกษา​

ขอคำปรึกษาเพื่อเลือกระบบที่เหมาะกับโรงงานของคุณ

ทีมผู้เชี่ยวชาญจาก Appomax พร้อมให้คำปรึกษาฟรี!