Kontrolowane zmiany na serwerze SCADA z użyciem Ansible

Ansible może standaryzować powtarzalne zmiany na serwerach aplikacji SCADA, serwerach archiwizacji danych, stacjach roboczych inżynierskich oraz pomocniczych urządzeniach sieciowych. Nie należy traktować go jako zgody na automatyzację zasobów sterowania bez określonych ograniczeń. Zadanie inżynierskie polega na zdefiniowaniu, co może się zmienić, gdzie może się zmienić oraz jak zakład może potwierdzić rezultat.

Niniejszy przewodnik koncentruje się na kontrolowanych zmianach infrastruktury związanej z systemem SCADA. Nie proponuje zastępowania logiki sterowników PLC ani omijania procedur obowiązujących w zakładzie. Najbezpieczniej jest zazwyczaj rozpocząć od środowiska testowego i wąsko zdefiniowanego zadania po stronie serwera.

Miejsce Ansible w architekturze OT

Ansible używa inwentarzy do identyfikowania zarządzanych hostów oraz playbooków do opisywania wymaganych zadań. Oficjalny przewodnik po inwentarzu Ansible wyjaśnia, jak hosty, grupy i zmienne definiują cele automatyzacji.

W zakładzie przemysłowym cele te mogą obejmować serwery SCADA, hosty przesiadkowe, repozytoria poprawek, serwery kopii zapasowych oraz zarządzane urządzenia sieciowe. Sterowniki PLC i systemy bezpieczeństwa wymagają osobnej oceny. Wsparcie dostawcy, działanie protokołów i mechanizmy kontroli zmian różnią się od standardowej administracji serwerami.

Praktyczna architektura umieszcza węzeł sterujący Ansible w zarządzanej strefie. Nie powinien on mieć nieograniczonego dostępu do całej sieci sterowania. Reguły zapory sieciowej, nazwane konta i zatwierdzone dane uwierzytelniające powinny ograniczać każdy playbook do systemów, dla których jest przeznaczony.

Osoby analizujące szerszą architekturę mogą skorzystać z biblioteki wiedzy PLC ProTech oraz kolekcji Communication & Networking, aby uzyskać dodatkowy kontekst dotyczący sterowania i sieci.

Rozpocznij od wąskiego, odwracalnego przypadku użycia

Dobre pierwsze zadania mają jasno określone dane wejściowe i łatwy sposób wycofania zmian. Przykłady obejmują skopiowanie zweryfikowanego pliku konfiguracyjnego, sprawdzenie stanu usługi, zebranie informacji o wersjach lub potwierdzenie istnienia kopii zapasowej.

Unikaj rozpoczynania od aktualizacji oprogramowania sprzętowego, pobierania programów do sterowników, konfiguracji systemów bezpieczeństwa lub szeroko zakrojonych zmian zapory sieciowej. Działania te mogą zmienić zachowanie produkcji. Wymagają również mocniejszych dowodów ze strony dostawcy i testów dostosowanych do konkretnego zakładu.

Dla każdego zadania zdefiniuj stan oczekiwany przed napisaniem playbooka. Zapisz, których plików, usług, portów, kont i zależności ono dotyczy. Określ, co powinno pozostać niezmienione.

Rozdziel inwentarze według funkcji i ryzyka

Nie umieszczaj wszystkich hostów OT w jednym, niepodzielonym inwentarzu. Grupuj systemy według zakładu, funkcji, środowiska i potencjalnych skutków. Serwery SCADA środowiska deweloperskiego nie powinny korzystać z tego samego wzorca celów co serwery produkcyjne.

Używaj jawnie zdefiniowanych grup hostów dla każdego zatwierdzonego okna zmian. Przechowuj zmienne hostów w systemie kontroli wersji. Przeglądaj zmiany inwentarza z taką samą starannością jak zmiany playbooków. Prawidłowe zadanie wysłane do niewłaściwego hosta nadal oznacza awarię.

Inwentarz dynamiczny może być użyteczny, ale wprowadza kolejne źródło danych. Inżynierowie powinni potwierdzić, w jaki sposób hosty są dodawane do inwentarza lub z niego usuwane. Nieaktualny rejestr zasobów może skierować automatyzację do wycofanego z użycia lub ponownie wykorzystanego urządzenia.

Projektuj idempotentne playbooki

Zadanie idempotentne osiąga wymagany stan bez wprowadzania niepotrzebnych zmian przy każdym uruchomieniu. Ułatwia to zrozumienie wielokrotnego wykonywania i ogranicza zbędne restarty.

Korzystaj z modułów przeznaczonych do konkretnych celów, jeśli obsługują daną platformę docelową. Polecenia powłoki mogą ukrywać skutki uboczne i zwracać niejednoznaczne wyniki. Jeśli użycie polecenia jest nieuniknione, określ jego warunki, oczekiwane kody zwrotu i sposób wycofania zmian.

Procedury obsługi powinny restartować usługi tylko wtedy, gdy zmieniła się powiązana konfiguracja. Wykonywanie szeregowe może ograniczyć liczbę objętych zmianą węzłów. Niewielki rozmiar partii ułatwia również monitorowanie i wycofywanie zmian.

Przeprowadź walidację przed wykonaniem w produkcji

Walidacja składni wykrywa błędy strukturalne, ale nie potwierdza, że zmiana jest bezpieczna. Tryb sprawdzania Ansible symuluje obsługiwane zadania, a tryb różnic może pokazywać proponowane zmiany w plikach. Oficjalna dokumentacja trybu sprawdzania i różnic opisuje również ich ograniczenia.

Niektóre moduły nie obsługują w pełni trybu sprawdzania. Zarejestrowane zmienne i zadania warunkowe mogą zachowywać się inaczej podczas symulacji. Dane wyjściowe trybu różnic mogą ujawnić sekrety. Traktuj te narzędzia jako element szerszego procesu testowania.

Najpierw uruchom playbook na reprezentatywnym hoście testowym. Następnie użyj ograniczonego wdrożenia pilotażowego w środowisku produkcyjnym. Przed rozszerzeniem grupy docelowej potwierdź prawidłowe działanie aplikacji, alarmy, komunikację, gromadzenie danych w archiwum, synchronizację czasu i widoczność dla operatorów.

Chroń dane uwierzytelniające i dzienniki

Używaj nazwanych kont usługowych z minimalnym wymaganym zakresem uprawnień. Unikaj współdzielonych kont administratorów. Przechowuj sekrety w zatwierdzonym sejfie i zapobiegaj ujawnianiu przez dane wyjściowe playbooka haseł, tokenów, certyfikatów lub kluczy prywatnych.

Dzienniki powinny wskazywać osobę zgłaszającą, osobę zatwierdzającą, wersję playbooka, inwentarz, czas rozpoczęcia, rezultat i zmienione elementy. Przesyłaj rekordy do chronionej lokalizacji. Lokalne dzienniki na węźle sterującym nie wystarczą, jeśli ten węzeł ulegnie awarii.

Uwzględnij wycofanie zmian w planie

Wycofanie zmian musi być opisane bardziej szczegółowo niż „przywrócić kopię zapasową”. Przed wykonaniem zarejestruj dokładne pliki, pakiety, stany usług i wersje aplikacji. Przetestuj ścieżkę odzyskiwania na reprezentatywnym systemie.

Niektórych zmian nie można bezpiecznie odwrócić podczas pracy produkcyjnej. Typowymi przykładami są zmiany schematu bazy danych i aktualizacje oprogramowania sprzętowego. W takich przypadkach plan wymaga przestoju konserwacyjnego, wskazówek dostawcy i nośników odzyskiwania.

Lista kontrolna działań operacyjnych

• Potwierdź właściciela playbooka, osobę zatwierdzającą i zatwierdzone zgłoszenie zmiany.
• Ogranicz inwentarz do wskazanych hostów i właściwego środowiska.
• Przed wykonaniem zweryfikuj kopie zapasowe i instrukcje odzyskiwania.
• Wykonaj kontrolę składni, tryb sprawdzania i próbę na hoście testowym, jeśli są obsługiwane.
• Używaj partii wykonywanych szeregowo i określonych warunków zatrzymania.
• Monitoruj usługi SCADA, komunikację, alarmy i gromadzenie danych.
• Zarchiwizuj wersję playbooka, dzienniki, wyniki i dowody możliwości wycofania zmian.

Podsumowanie

Ansible może ograniczyć rozbieżności konfiguracji i ręczne różnice w infrastrukturze SCADA. Jego wartość wynika z powtarzalnych dowodów, a nie z wykonywania większej liczby zmian w krótszym czasie. Rozpocznij od ograniczonych zadań serwerowych, rozdziel inwentarze według ryzyka, testuj każdy playbook i zachowaj sprawdzoną ścieżkę odzyskiwania.