728 x 90

Podstawy systemów SCADA [aktualizacja 02.05.2022]

Podstawy systemów SCADA [aktualizacja 02.05.2022]

W większości świata IT wiedza, również ta praktyczna, jest relatywnie łatwa do zdobycia. Są jednak takie obszary, kryjące się za różnymi akronimami lub nazwami własnymi (np. SAP, Oracle, czy właśnie SCADA), w których wiedza i dostęp nowych osób do branży są z różnych względów ograniczane. Celem tego artykułu jest wyjaśnienie, co to takiego ta SCADA i od czego zacząć praktykę w zakresie bezpieczeństwa ofensywnego.

A więc czym właściwie jest SCADA?

SCADA to system informatyczny nadzorujący przebieg procesu technologicznego lub produkcyjnego. A więc system używany np. w fabrykach, elektrowniach, oczyszczalniach ścieków i wielu innych miejscach, w których używane są urządzenia mechaniczne, którymi da się sterować z poziomu komputera.

System SCADA służy przede wszystkim do przedstawienia procesu przemysłowego w sposób wizualny – a więc aby każde z urządzeń, które wymaga jakiejś formy nadzoru lub ręcznego sterowania, było pokazane na diagramie takim jak powyższy (to co widzisz, jest realną wizualizacją urządzeń w jednej z elektrowni wodnych w USA).

Istnieją 4 główne cele stosowania systemu SCADA:

  1. Redukcja kosztów operacyjnych i zwiększenie bezpieczeństwa procesu przemysłowego – umożliwienie pracownikom obserwowania pracy urządzeń z jednego centralnego miejsca, zamiast ciągłego chodzenia od urządzenia do urządzenia (specyfiką systemów SCADA jest to, że ktoś ciągle w te panele sterujące patrzy i kontroluje co się dzieje, a więc każdy zbyt oczywisty atak typu np. ustawienie parametrów jakiegoś urządzenia powyżej bezpiecznego maksimum, najprawdopodobniej zostanie momentalnie zauważony i powstrzymany).
  2. Rozliczanie usług – systemy SCADA nie tylko pokazują bieżące działanie urządzeń (np. bieżące ciśnienie wody), ale potrafią również rejestrować wskazane dane (np. łączny przepływ wody w skali całego miesiąca). Mając takie dane, firma może rozliczać klientów z realnego zużycia usług (a więc od prawidłowości i precyzji tych danych zależą jej finanse).
  3. Detekcja obecnych i przyszłych wąskich gardeł w procesie przemysłowym – zbieranie i wizualizacja różnego rodzaju metryk z poszczególnych urządzeń pozwala przewidywać nietrywialne wąskie gardła, zależące od wielu składowych (np. maksymalna ilość wody dostarczanej na osiedle X w godzinach porannych, biorąc pod uwagę jednoczesne zużycie wody przez innych odbiorców). Dzięki takim danym menedżerowie mogą podejmować trafne decyzje, kiedy należy wymienić jakieś urządzenie na bardziej wydajny model.
  4. Zapewnienie ciągłości procesu przemysłowego – systemy SCADA i ich komponenty (np. sterowniki PLC) są budowane w taki sposób, aby umożliwić wyłączenie części systemu z powodu awarii, konserwacji, wymiany jakiegoś elementu na większy, czy wdrożenia nowszej wersji oprogramowania itp., zachowując jednocześnie płynność działania procesu jako całości. Jest to o tyle niezbędne, że o ile całkowite wyłączenie niektórych procesów (np. produkcji w fabryce) wiązałoby się ze stratami finansowymi, o tyle w innych przypadkach jest to fizycznie niemożliwe (np. rdzenie paliwowe w elektrowni jądrowej muszą być stale chłodzone i kontrolowane nawet jeśli cała energia parowa z nich jest wypuszczana do atmosfery ze względu na awarię turbiny parowej).

Z czego składają się systemy SCADA?

Podstawowe komponenty systemu SCADA to:

  • sterownik PLC, będący sercem wykonawczym systemu – sterownik taki jest punktem separującym część wykonawczą od części wizualizacyjnej – w przypadku skomplikowanych procesów, sterowników PLC może być wiele, połączonych w bardzo różne układy, albo po prostu cały proces może być podzielony na kilka niezależnie zrealizowanych części z osobnymi sterownikami, osobną wizualizacją, bazami danych itd.
  • system wizualizacyjny – często taki system, wraz z kompletem narzędzi deweloperskich, jest dostarczany przez producenta sterownika PLC jako element większej całości
  • baza danych, umożliwiająca archiwizację danych związanych z eksploatacją systemu, a także wymianę danych z innymi systemami (np. eksport danych rozliczeniowych do systemu finansowego)
  • czujniki i urządzenia pomiarowe – czyli wszystko to, co zamienia różne wartości fizyczne (np. ciśnienie) na dane wejściowe dla sterownika PLC
  • elementy wykonawcze – czyli wszystko to, co zamienia sygnały od sterownika PLC na konkretne działania (np. uruchomienie silnika w pompie, zwiększenie obrotów itd.)

Czym właściwie jest sterownik PLC?

Najprościej jest to wyjaśnić poprzez analogię do popularnych płytek typu Arduino czy Raspberry Pi. Więc jest to niewielki specjalizowany komputer, wyposażony w:

  • procesor, pamięć RAM i ROM (a właściwie flash)
  • system operacyjny i oprogramowanie wewnętrzne
  • program wgrany przez użytkownika
  • złącza komunikacyjne typu Ethernet do komunikacji z innymi komputerami (wizualizacją, bazą danych, systemami komunikacyjnymi do wysyłania alertów itp.)
  • złącze GPIO, będące interfejsem wejścia-wyjścia dla czujników i urządzeń wykonawczych (tyle że zamiast np. diod LED, czujników temperatury, mechanizmów serwo itp. typowych dla amatorskich zastosowań Arduino, podłączane są nieco większe elementy przemysłowe)
  • przemysłową obudowę i zasilacz (bardziej odporne na warunki zewnętrzne)

Sterownik PLC ma jednakże kilka istotnych różnic w stosunku do płytek typu Arduino:

  • jest zbudowany w taki sposób, aby być odpornym na zwarcia, przepięcia i inne zakłócenia elektryczne (jednym z najbardziej zasadniczych wymogów wobec sterownika jest właśnie to, aby w/w sytuacje nie doprowadziły do jego uszkodzenia, czy choćby zawieszenia się wgranego programu) – najczęściej jest to zrealizowane poprzez wbudowanie w sterownik elementów izolujących galwanicznie instalację zewnętrzną od rdzenia sterownika
  • ma wbudowane sprzętowe watchdogi, a więc mechanizmy wykrywające problemy z pracą sterownika i potrafiące wymusić jego restart, albo inną formę przywrócenia prawidłowej pracy
  • ma własny język programowania i dedykowane narzędzia, najczęściej oparte o tworzenie diagramów podobnych do BPMN (patrz zdjęcie) – taki sposób tworzenia programu dla sterownika całkowicie uniemożliwia bezpośredni dostęp do sprzętu (zarówno samego sterownika, jak i podłączonych elementów przemysłowych), a tym samym eliminuje możliwość popełnienia przez programistę wielu różnych klas błędów, jakie występują w „klasycznym” oprogramowaniu

Bezpieczeństwo systemów SCADA

Panele wizualizujące pracę naprawdę krytycznych urządzeń są najczęściej obserwowane w trybie 24/7. Dodatkowo zbyt ewidentne przekroczenia różnych wartości dopuszczalnych (czy to wskutek ataku, czy zwykłej awarii) często są automatycznie alertowane do różnych osób, np. SMS-ami. W efekcie prymitywne ataki polegające na rozkręceniu jakiegoś zaworu na maksimum (czy to po uzyskaniu dostępu z zewnątrz, czy jako sabotaż wewnętrzny), najprawdopodobniej zostaną wychwycone i powstrzymane, zanim dojdzie do choćby niewielkiej awarii.

Dodatkową trudnością przy penetrowaniu i atakowaniu systemów SCADA jest to, że z założenia powinny być one albo całkowicie odcięte od Internetu, albo podłączone w taki sposób, aby już samo dostanie się przeglądarką do jakiegokolwiek ekranu logowania było czymś nietrywialnym (mimo że w praktyce często dzieje się inaczej i wiele paneli do systemów SCADA da się znaleźć po prostu w wyszukiwarce Shodan).

Zagadnienia bezpieczeństwa SCADA można podzielić na kilka osobnych warstw:

Bezpieczeństwo aplikacji webowych do wizualizacji i sterowania

A więc aplikacji używanych przez operatorów systemu, menedżerów i inne osoby. Aplikacje te są z założenia (choć nie zawsze) tak projektowane, aby być bezpieczne funkcjonalnie, tj. pozwalać tylko na takie zmiany parametrów kontrolowanych urządzeń, które mieszczą się w zakładanych granicach bezpieczeństwa – dzięki czemu zwykły operator z założenia nie jest w stanie doprowadzić do poważnej awarii, w każdym razie nie z poziomu samej aplikacji.

Zagadnienia bezpieczeństwa tej warstwy są więc porównywalne z zagadnieniami dotyczącymi każdej innej aplikacji webowej, w której występują dane wrażliwe, których ujawnienie może narazić daną firmę na różnego rodzaju straty:

  • wyciek danych osobowych
  • wyciek danych finansowych (niekoniecznie bezpośrednio w postaci danych finansowych, ale również w postaci informacji o zużyciu zasobów, co następnie można samodzielnie przeliczyć na pieniądze)
  • wyciek informacji o fizycznej architekturze procesów, używanych konkretnych modelach różnych urządzeń itd. – narażenie np. na ataki terrorystyczne (w przypadku elektrowni i innych tego typu obiektów)
  • wyciek informacji stanowiącej własność intelektualną (do konkurencji)

Dodatkowo, niezależnie od możliwości wycieku danych, kolejnym ryzykiem jest też sabotaż optymalności procesu. O ile systemy takie powinny być bezpieczne funkcjonalnie i nie pozwolić na wywołanie żadnej awarii, o tyle operatorzy najczęściej mają możliwość zdalnego korygowania pracy różnych urządzeń – np. przyspieszenia lub spowolnienia tempa ich pracy. A zatem napastnik dysponujący dostępem do takiego systemu i rozumiejący proces przemysłowy od strony technologicznej, jest w stanie wprowadzić w jego konfiguracji szereg drobnych i nie zwracających szczególnej uwagi zmian, które np. zwiększą poziom marnowania zasobów na różnych urządzeniach, a tym samym doprowadzą do obniżenia efektywności ekonomicznej procesu i całej firmy.

Bezpieczeństwo wewnętrznych interfejsów administracyjnych poszczególnych urządzeń wykonawczych

Wiele dzisiejszych urządzeń elektrycznych, często nawet proste płytki ze zdalnie sterowanymi przekaźnikami, jest dzisiaj budowanych w formie kontrolera sterowanego z poziomu sieci LAN przez port Ethernet, zamiast, jak dawniej, z pojedynczego komputera przez port RS-232, czy choćby USB. Zarazem sporo takich urządzeń klasy domowej lub nawet przemysłowych z niższej półki, nie ma jakichkolwiek zabezpieczeń przed nieautoryzowanym dostępem (jedynym zabezpieczeniem może być odcięcie dostępu sieciowego), albo jest zabezpieczona pojedynczym współdzielonym hasłem (co m.in. nie pozwala rozliczać poszczególnych operatorów ich działań na tym urządzeniu).

W przeciwieństwie do poprzedniej kategorii, interfejsy administracyjne nie są projektowane pod kątem bezpieczeństwa funkcjonalnego – są bowiem narzędziem stricte serwisowym, pozwalającym np. wymusić pracę urządzenia w trybie testowym, zmianę kolejności obrotów w celu dokonania czyszczenia, ciśnienie wyższe od dopuszczalnego itp. – a często też odłączyć to urządzenie od sterownika PLC czy innych zewnętrznych systemów sterujących całością procesu przemysłowego. Z tego względu to właśnie takie interfejsy są jednym z najważniejszych celów, jakich powinien szukać napastnik chcący zaatakować cały system.

Bezpieczeństwo fizyczne poszczególnych urządzeń wykonawczych

Punkt ten pozornie może być nieco mylący, ponieważ urządzenia wykonawcze biorące udział w procesie przemysłowym są z zasady zabezpieczone przed nieuprawnionym dostępem fizycznym – poza tym kwestie siłowego przełamywania zabezpieczeń fizycznych (np. napadu na strzeżone pomieszczenia) raczej wychodzą poza zakres tego artykułu.

Szczególnym przypadkiem są jednak urządzenia wykonawcze pracujące w trybie rozproszonym – a więc nie w jednym budynku, tylko np. na terenie całego miasta (np. czujniki ciśnienia wody w różnych węzłach). Trendem w ostatnich latach jest łączenie takich urządzeń z centralą bezprzewodowo, głównie z użyciem przemysłowych modemów komórkowych – co nie tylko redukuje koszty związane z prowadzeniem kabli, ale przy okazji zapobiega opisanym niżej ryzykom. Są jednak przypadki:

  • starszych urządzeń (lub nawet nowych urządzeń w starszych instalacjach),
  • braku sygnału lub zbyt dużych zakłóceń w danym miejscu,
  • norm bezpieczeństwa (np. militarnych) lub innych okoliczności szczególnych, wykluczających taki sposób połączenia,

gdzie urządzenia takie są połączone z centralą (lub z kolejną lokalizacją zewnętrzną) za pomocą kabla. Sama łączność może przy tym być realizowana na bardzo różne sposoby, najczęściej spotykane są:

  • MODBUS po TCP/IP
  • TCP/IP z autorskim protokołem wymiany danych
  • OPC
  • MODBUS na łączu szeregowym
  • transmisja szeregowa RS-485 z autorskim protokołem wymiany danych
  • CAN-BUS (często stosowane w pewnych branżach pomimo ograniczenia długości kabla)

Połączenia tego typu narażone są na 4 główne grupy ryzyk:

  • trywialne ryzyka związane z przypadkowym (lub celowym) przerwaniem kabla (np. przez koparkę), czy np. podłączeniem go do średniego/wysokiego napięcia (a więc najłatwiejszymi sposobami szybkiej dywersji np. w warunkach wojennych) – większość instalacji jest przed takimi ryzykami zabezpieczona (np. mierzenie pojemności elektrycznej kabla jako metoda określenia miejsca jego przerwania, czy separacja galwaniczna kabla od elektroniki), często jednak nie są to zabezpieczenia idealne (naprawa przerwanego kabla wymaga czasu, a zabezpieczenie galwaniczne może być skuteczne przy podłączeniu kabla do 230V – ale przy 10kV już niekoniecznie, bo łuk elektryczny i tak spali całą elektronikę zabezpieczającą)
  • opisane w dalszej części artykułu błędy w implementacji stosu komunikacyjnego i inne, pozwalające najczęściej na atak Denial of Service, poprzez zawieszenie urządzenia lub jego części stricte elektronicznej – zdarzały się jednak przypadki (np. CVE-2020-11896, zwany też Ripple20), w których możliwe było zdalne wykonanie kodu na wadliwym urządzeniu z całkowitym pominięciem uwierzytelnienia
  • brak szyfrowania przesyłanych danych, umożliwiający łatwy podsłuch i pozyskiwanie informacji (natomiast co ciekawe, często spotykane są różne prymitywne sposoby detekcji błędów i zarazem zapewniania integralności przesyłanych danych – łatwe do złamania, ponieważ oparte na prostych pojedynczych operacjach bitowych, zamiast na kryptografii, trzeba jednak znać schemat tych operacji, a ten zależny jest od konkretnych urządzeń)
  • wspomniany brak kryptograficznej weryfikacji integralności danych wprowadza 2 rodzaje ryzyk: modyfikacji danych pomiarowych (przesyłanych z różnego rodzaju czujników do centrali), oraz dużo gorszej w skutkach modyfikacji (albo wstrzykiwaniu nowych) poleceń dla poszczególnych urządzeń (np. zwiększyć ciśnienie w węźle o 3.4%) – i to jest właśnie najskuteczniejszy sposób wywołania potencjalnej awarii, o ile tylko napastnik dysponuje odpowiednią wiedzą, sprzętem i możliwością podłączenia się do właściwych kabli (a wcześniej ich identyfikacji)

Modyfikacja lub wstrzykiwanie danych są trudniejsze w realizacji od samego podsłuchu nie tylko ze względu na możliwe do napotkania mechanizmy detekcji błędów. Systemy przemysłowe łączone są ze sobą na duże odległości, np. magistrala RS-485 może mieć maksymalną długość pojedynczego odcinka kabla dochodzącą do 1200 metrów. Przy takich odległościach, na kablach zachodzą 4 zjawiska elektryczne:

  • opóźnienie sygnału
  • opór (i tym samym wysokość napięcia, które nie musi wcale mieć 5V albo 3.3V, jak w instalacjach lokalnych – czy wręcz jego wysokość może być dynamiczna, zależna od ilości przesyłanych akurat „jedynek”)
  • pojemność
  • indukcja

Przy pasywnym nasłuchu, wszystkie te zjawiska można zignorować, z wyjątkiem jedynie ustalenia, od jakiego progu wysokości napięcia, rozróżniać stany logiczne 0 i 1. Zależności czasowe będące efektem w/w zjawisk są pomijalne – można wręcz nawet nagrać całą transmisję i odtworzyć ją później, w innym miejscu itp.

Natomiast próbując wstrzyknąć do kabla własne polecenia, a tym bardziej próbując w locie modyfikować oryginalny sygnał, niezbędne jest wzięcie pod uwagę tych wszystkich zjawisk, tak aby sygnał nadany przez napastnika w ogóle nadawał się do poprawnego zdekodowania przez urządzenie będące celem. Dlatego też, im większa fizyczna odległość pomiędzy napastnikiem a kontrolowanym urządzeniem, tym bardziej precyzyjny sprzęt elektroniczny jest niezbędny do realizacji takiego ataku.

Bezpieczeństwo sterowników PLC i ich oprogramowania

Sterownik PLC (opisany wyżej) stanowi serce systemu SCADA. Z dużym prawdopodobieństwem można założyć, że od strony bezpieczeństwa (fizycznego, elektrycznego, funkcjonalnego itd.) będzie to najsilniejszy element całego łańcucha. Błędem jednak jest myślenie, że urządzenie takie nie posiada słabych punktów.

Najsłabszym punktem sterownika PLC jest najczęściej program stworzony na potrzeby obsługi konkretnego procesu przemysłowego. O ile bowiem oprogramowanie systemowe sterownika zostało stworzone wiele lat temu i od tego czasu wielokrotnie przetestowane w praktyce, a ewentualne błędy dawno połatane, o tyle program sterujący procesem był najprawdopodobniej tworzony z myślą o jednym konkretnym przypadku, w warunkach biznesowych (czyli takich, w których pracownicy nie mogli sobie pozwolić na przesadnie długie myślenie o różnych wymyślnych scenariuszach ataku, tylko musieli w sensownym czasie dostarczyć działające rozwiązanie). Dlatego też napastnik chcący zaatakować cały system od strony sterownika PLC powinien zacząć przygotowania od analizy dostępnych artefaktów tego programu.

Bezpieczeństwo bazy danych systemu SCADA

O ile sterownik PLC jest z reguły najsilniejszym elementem całego łańcucha składającego się na system SCADA, o tyle baza danych jest często elementem najsłabszym, lub jednym z najsłabszych. Często bowiem różnego rodzaju integracje z systemami zewnętrznymi (np. finansowymi) robione są bezpośrednio na poziomie bazy danych – jak również wszelkiego rodzaju testy i prace związane z wdrażaniem nowych wersji programu sterującego wymagają swobodnego dostępu do bazy danych dla członków zespołu wdrożeniowego.

Dodać też należy, że ta dziedzina rozwoju oprogramowania w dużej części oparła się trendowi Agile i nie ma żadnych systemów CI/CD przystosowanych do realiów systemów SCADA. Wszystko to powoduje, że selektywne zarządzanie uprawnieniami dostępowymi do bazy danych jest procesem dość mozolnym i bywa czasami w praktyce zastępowane technikami typu współdzielenie hasła do jednego konta technicznego (lub podobnymi). Dlatego też:

  • jednym z pierwszych działań po uzyskaniu dostępu do panelu konfiguracyjnego lub kodów źródłowych, plików konfiguracyjnych itp. związanych z systemem SCADA, powinno być sprawdzenie, czy da się z nich wyciągnąć dane dostępowe do bazy danych
  • systemy poboczne (np. do rozliczania zużycia usług czy ERP) mogą być świetnym punktem wejścia do bazy danych systemu SCADA – często są bowiem dużo gorzej zabezpieczone od właściwego systemu SCADA, a mogą również posiadać dostęp do jego bazy danych – i nawet jeśli jest to dostęp tylko do odczytu, to może pozwolić na wydobycie z tej bazy ciekawych danych, pozwalających na eskalację działań napastnika

Same zagadnienia związane z bezpieczeństwem bazy danych systemu SCADA są już porównywalne z zagadnieniami dotyczącymi każdej innej bazy danych zawierających „poważne” dane.

Jak w praktyce zacząć przygodę z systemami SCADA?

Wg autora tego artykułu, aby zacząć przygodę z bezpieczeństwem (defensywnym lub ofensywnym) jakiegokolwiek systemu, dobrze jest zapoznać się z nim na początku od strony funkcjonalnej: jako zwykły użytkownik (operator) takiego systemu, oraz jako menedżer odpowiedzialny za bieżące działanie firmy, która takiego systemu miała by używać (zagadnienia ciągłości działania, wiarygodności danych rozliczeniowych, ukrytych kosztów i słabych punktów).

Warto przy tym zacząć od systemu Ignition, który jest najbardziej przystępny spośród kompletnych systemów dostępnych „tak po prostu” do pobrania przez osobę spoza branży (bez żadnych wcześniejszych umów z producentem) i pozwala „poczuć” pewne kwestie w praktyce.

Warto również zapoznać się z działaniem sterowników PLC i związanych z nimi systemów wizualizacji. Platformą wiodącą w Polsce jest Siemens SIMATIC. Materiały nt. tej platformy są niestety płatne, natomiast w serwisie Udemy dostępne są 3 tanie szkolenia w języku polskim:

Modelem sprzedażowym Udemy są ciągle przedłużane promocje, więc jeśli widzisz cenę któregoś z kursów wyższą niż 35 zł, poczekaj maksymalnie kilka dni do kolejnej promocji – w ten sposób wszystkie 3 szkolenia kupisz za 105 zł.

Oczywiście na platformie Udemy dostępnych jest dużo więcej kursów, ale głównie w języku angielskim – wybierając dobry kurs, poza barierą językową, bardzo istotne jest, aby przekazywana wiedza była nakierowana na polskie realia. Niestety wiele kursów w języku angielskim jest albo bardzo generycznych, albo nakierowanych na realia USA lub Indii (skąd wywodzi się mnóstwo ich autorów). Dlatego właśnie polecamy konkretnie te wymienione kursy (a w szczególności pierwszy z nich, nastawiony na poznanie platformy Siemens SIMATIC od strony programowej, oraz drugi, nastawiony na praktykę z właściwym sprzętem).

Materiały związane już konkretnie z bezpieczeństwem SCADA/PLC

Zacznij koniecznie od poniższej strony. Znajdziesz na niej mnóstwo materiałów związanych z bezpieczeństwem systemów SCADA, aczkolwiek głównie dotyczących warstwy interfejsów webowych (patrz klasyfikacja wyżej).

Zajrzyj też do Wikipedii:

  • polskiej – masz tu obszerną listę przykładowych systemów SCADA, z naciskiem na te popularne w Polsce
  • angielskiej – masz tam dodatkowe omówienie paru kwestii dot. bezpieczeństwa, w tym odnośnie ataku na wspomniany wyżej system Ignition (ICSA-11-231-01)

Następnie zainteresuj się świeżą (bo z czerwca 2020) publikacją znaną m.in. jako Ripple20:

Pozostałe materiały:

  • za pomocą wyszukiwarki Shodan możesz łatwo przeszukiwać cały Internet w poszukiwaniu aplikacji od systemów SCADA (oraz wszystkich innych)
  • Schneider Electric (jeden z głównych producentów elektroniki przemysłowej m.in. dla systemów SCADA) – powiadomienia o podatnościach bezpieczeństwa
  • Luigi Auriemma – strona jednego z security researcherów zajmujących się m.in. systemami SCADA
  • ICSA-11-131-01 – dość istotna podatność bezpieczeństwa w systemach firmy Iconics, znaleziona w 2011
  • plcscan – narzędzie do skanowania sterowników PLC za pomocą komunikacji S7 lub MODBUS po TCP/IP

Materiały dodane już po opublikowaniu artykułu

Ciekawe linki związane z wirusem Stuxnet, atakującym systemy przemysłowe:

Inne ciekawe materiały, dodane w grudniu 2020:

Inne ciekawe materiały, dodane w 2022: