Sử dụng Ansible để kiểm soát các thay đổi trên máy chủ SCADA

Ansible có thể chuẩn hóa các thay đổi có tính lặp lại trên máy chủ ứng dụng SCADA, máy chủ lưu trữ dữ liệu lịch sử, máy trạm kỹ thuật và các thiết bị mạng hỗ trợ. Không nên xem Ansible là sự cho phép tự động hóa các tài sản điều khiển mà không có ranh giới. Nhiệm vụ kỹ thuật là xác định những gì được phép thay đổi, nơi được phép thay đổi và cách cơ sở có thể chứng minh kết quả.

Hướng dẫn này tập trung vào các thay đổi hạ tầng có kiểm soát xung quanh hệ thống SCADA. Hướng dẫn không đề xuất thay thế logic PLC hoặc bỏ qua các quy trình của nhà máy. Điểm khởi đầu an toàn nhất thường là môi trường thử nghiệm và một tác vụ hẹp ở phía máy chủ.

Ansible phù hợp ở đâu trong kiến trúc OT

Ansible sử dụng các inventory để xác định máy chủ được quản lý và các playbook để mô tả những tác vụ mong muốn. Hướng dẫn inventory chính thức của Ansible giải thích cách máy chủ, nhóm và biến xác định các mục tiêu tự động hóa.

Tại một cơ sở công nghiệp, các mục tiêu đó có thể bao gồm máy chủ SCADA, máy chủ trung gian, kho bản vá, máy chủ sao lưu và thiết bị mạng được quản lý. PLC và hệ thống an toàn cần được xem xét riêng. Hỗ trợ của nhà cung cấp, đặc tính giao thức và quy trình kiểm soát thay đổi khác với hoạt động quản trị máy chủ thông thường.

Một kiến trúc thực tế sẽ đặt nút điều khiển Ansible trong một vùng được quản lý. Nút này không nên có quyền truy cập không hạn chế trên toàn mạng điều khiển. Các quy tắc tường lửa, tài khoản được định danh và thông tin xác thực được phê duyệt nên giới hạn mỗi playbook trong các hệ thống mà nó được thiết kế để tác động.

Độc giả xem xét kiến trúc tổng thể có thể tham khảo Thư viện kiến thức và bộ sưu tập Truyền thông & Mạng của PLC ProTech để tìm hiểu thêm về bối cảnh điều khiển và mạng liên quan.

Bắt đầu với một trường hợp sử dụng hẹp và có thể hoàn nguyên

Các tác vụ đầu tiên nên có đầu vào rõ ràng và khả năng khôi phục dễ dàng. Ví dụ gồm sao chép một tệp cấu hình đã được xác thực, kiểm tra trạng thái dịch vụ, thu thập dữ liệu phiên bản hoặc xác nhận rằng bản sao lưu tồn tại.

Tránh bắt đầu bằng việc cập nhật firmware, tải xuống bộ điều khiển, thay đổi cấu hình an toàn hoặc thay đổi tường lửa trên diện rộng. Những hoạt động này có thể làm thay đổi hành vi sản xuất. Chúng cũng đòi hỏi bằng chứng mạnh hơn từ nhà cung cấp và hoạt động kiểm thử dành riêng cho nhà máy.

Với mỗi tác vụ, hãy xác định trạng thái mong đợi trước khi viết playbook. Ghi lại các tệp, dịch vụ, cổng, tài khoản và phần phụ thuộc liên quan. Nêu rõ những gì phải giữ nguyên.

Tách inventory theo chức năng và rủi ro

Không đặt mọi máy chủ OT vào một inventory không được phân loại. Hãy nhóm các hệ thống theo cơ sở, chức năng, môi trường và mức độ hậu quả. Máy chủ SCADA phát triển không nên dùng cùng một mẫu mục tiêu như máy chủ sản xuất.

Sử dụng các nhóm máy chủ rõ ràng cho từng khoảng thời gian thay đổi đã được phê duyệt. Lưu các biến máy chủ trong hệ thống kiểm soát phiên bản. Xem xét các thay đổi đối với inventory cẩn trọng như các thay đổi đối với playbook. Một tác vụ đúng được gửi đến sai máy chủ vẫn là một sự cố.

Inventory động có thể hữu ích, nhưng nó đưa vào thêm một nguồn dữ liệu. Kỹ sư nên xác nhận cách máy chủ được thêm vào hoặc loại khỏi inventory. Bản ghi tài sản lỗi thời có thể hướng hoạt động tự động hóa đến thiết bị đã ngừng sử dụng hoặc được chuyển đổi mục đích.

Thiết kế playbook có tính idempotent

Một tác vụ idempotent sẽ đưa hệ thống về trạng thái yêu cầu mà không thực hiện các thay đổi không cần thiết trong mỗi lần chạy. Điều này giúp dễ hiểu hơn khi chạy lặp lại và giảm số lần khởi động lại không cần thiết.

Sử dụng các module chuyên dụng khi chúng hỗ trợ nền tảng mục tiêu. Các lệnh shell có thể che giấu tác động phụ và trả về kết quả không rõ ràng. Nếu bắt buộc phải dùng lệnh, hãy xác định điều kiện thực thi, mã trả về dự kiến và hành vi hoàn nguyên.

Handler chỉ nên khởi động lại dịch vụ khi cấu hình liên quan thay đổi. Việc thực thi tuần tự có thể giới hạn số nút bị ảnh hưởng. Kích thước lô nhỏ cũng giúp việc giám sát và hoàn nguyên dễ quản lý hơn.

Xác thực trước khi thực thi trong môi trường sản xuất

Việc xác thực cú pháp phát hiện lỗi cấu trúc, nhưng không chứng minh rằng một thay đổi là an toàn. Chế độ kiểm tra của Ansible mô phỏng các tác vụ được hỗ trợ, trong khi chế độ diff có thể hiển thị các thay đổi tệp được đề xuất. Tài liệu chính thức về chế độ kiểm tra và diff cũng nêu rõ các hạn chế của chúng.

Một số module không hỗ trợ đầy đủ chế độ kiểm tra. Các biến đã đăng ký và tác vụ có điều kiện có thể hoạt động khác trong quá trình mô phỏng. Kết quả diff có thể làm lộ thông tin bí mật. Hãy xem các công cụ này là bằng chứng trong một quy trình kiểm thử lớn hơn.

Trước tiên, chạy playbook trên một máy chủ thử nghiệm đại diện. Sau đó sử dụng một nhóm thử nghiệm giới hạn trong môi trường sản xuất. Xác nhận tình trạng ứng dụng, cảnh báo, thông tin liên lạc, việc thu thập dữ liệu lịch sử, đồng bộ hóa thời gian và khả năng quan sát của người vận hành trước khi mở rộng nhóm mục tiêu.

Bảo vệ thông tin xác thực và nhật ký

Sử dụng các tài khoản dịch vụ được định danh với quyền tối thiểu cần thiết. Tránh dùng thông tin xác thực quản trị viên dùng chung. Lưu bí mật trong kho bảo mật được phê duyệt và ngăn đầu ra của playbook làm lộ mật khẩu, token, chứng chỉ hoặc khóa riêng.

Nhật ký nên xác định người yêu cầu, người xem xét, phiên bản playbook, inventory, thời gian bắt đầu, kết quả và các mục đã thay đổi. Gửi bản ghi đến một vị trí được bảo vệ. Nhật ký cục bộ trên nút điều khiển là chưa đủ nếu nút đó gặp sự cố.

Tích hợp việc hoàn nguyên vào thay đổi

Hoàn nguyên phải cụ thể hơn câu “khôi phục bản sao lưu”. Hãy ghi nhận chính xác các tệp, gói phần mềm, trạng thái dịch vụ và phiên bản ứng dụng trước khi thực thi. Kiểm thử quy trình khôi phục trên một hệ thống đại diện.

Một số thay đổi không thể hoàn nguyên an toàn trong môi trường sản xuất. Thay đổi lược đồ cơ sở dữ liệu và cập nhật firmware là những ví dụ phổ biến. Với các trường hợp này, kế hoạch cần có thời gian ngừng bảo trì, hướng dẫn của nhà cung cấp và phương tiện khôi phục.

Danh sách kiểm tra vận hành

• Xác nhận người phụ trách, người xem xét và phiếu thay đổi đã được phê duyệt cho playbook.
• Giới hạn inventory ở các máy chủ được định danh và đúng môi trường.
• Xác minh bản sao lưu và hướng dẫn khôi phục trước khi thực thi.
• Chạy kiểm tra cú pháp, chế độ kiểm tra và thử nghiệm trên máy chủ thử nghiệm khi được hỗ trợ.
• Sử dụng các lô tuần tự và điều kiện dừng đã xác định.
• Giám sát các dịch vụ SCADA, thông tin liên lạc, cảnh báo và hoạt động thu thập dữ liệu.
• Lưu trữ phiên bản playbook, nhật ký, kết quả và bằng chứng hoàn nguyên.

Tóm lại

Ansible có thể giảm sai lệch cấu hình và sự khác biệt do thao tác thủ công xung quanh hạ tầng SCADA. Giá trị của Ansible đến từ bằng chứng có thể lặp lại, không phải từ việc thực hiện nhiều thay đổi nhanh hơn. Hãy bắt đầu với các tác vụ máy chủ có phạm vi giới hạn, tách inventory theo rủi ro, kiểm thử từng playbook và duy trì một quy trình khôi phục đã được kiểm thử.