Od kilku dni obserwuje małe zamieszanie wokół wtyczki WPML, która umożliwia relatywnie łatwe tworzenie na WordPressie stron wielojęzykowych. Sam może nie jestem jakimś specjalnym fanem tej wtyczki, ale nie można nie zauważyć, że jest to rozwiązanie dość popularne, zwłaszcza, przy większych projektach (nie tylko dlatego, że jest płatne). Zaczęło się od wiadomości o prawdopodobnej podatności we wtyczce, z czym miały wiązać się dziwne e-maile, jakie zaczęli otrzymywać użytkownicy wtyczki. W pewnym momencie głos zabrali autorzy wtyczki (głównie Amir Helzer), informując o tym, że to nie kwestia podatności w samej wtyczce, a działania byłego pracownika, który miał cały czas dostęp do różnych elementów infrastruktury wykorzystywanej przez autorów WPML. Ciężko jednak nie odnieść wrażenia, że to nie tylko wina niecnych działań byłego pracownika, ale też i procedur w samej firmie.

Procedury bezpieczeństwa (nie tylko) IT (nie tylko) w firmie

Na początku miał to być ewentualnie (bo nie byłem pewny, czy aby faktycznie jest sens o tym pisać) artykuł tylko o WPLM i potencjalnej podatności. Szybko się okazało, że raczej nie mamy do czynienia z bezpośrednią podatnością w samej wtyczce, co w procedurach – jeśli w ogóle jakieś były – w firmie stojącej za wtyczką.

Nie bez znaczenia jest też to, że w ostatnich dniach pod moje skrzydła trafiło trzech nowych klientów, u których również widać, że nikt nie pomyślał o jakichkolwiek procedurach związanych z zabezpieczeniem dostępu do strony, jak i całej infrastruktury towarzyszącej (rejestr domen, konto hostingowe, sam hosting).

Domeny często porozsiewane po kolejnych firmach, które przez lata kolejno zajmowały się obsługą. Do tego dostęp administracyjny do strony (WordPress) czy samego hostingu posiadają osoby, z którymi firmy dawno przestały współpracować.

Oczywiście nie powiem (napiszę), że musi to od razu oznaczać problemy, ale… jak widać może. I o ile w przypadku „prywatnego blogaska” można jeszcze ewentualnie (troszkę) przymknąć na to oko, to w przypadku strony firmowej, czy – a i na takie sytuacje trafiam – sklepu internetowego, gdzie przetwarzamy nie tylko dane klientów, ale również (do pewnego stopnia) dane dotyczące płatności takie sytuacje nie powinny mieć miejsca.

Fajnie byłoby ten artykuł uzupełnić o jakieś uniwersalne porady, wskazówki… Problem tylko w tym, że z bezpieczeństwem jest jak z poradą prawną – działania zależą od konkretnych okoliczności. Ale jest kilka takich elementów, na które na pewno warto zwrócić uwagę:

• Zapisz sobie, gdzie masz domeny, hosting, do kogo możesz się zwrócić w razie problemów
• Pilnuj kto i w jakim zakresie ma dostęp do strony, hostingu, panelu zarządzania domenami, ogólnie… do wszystkiego
• Jeśli musisz komuś udzielić dostępu, to najlepiej za pomocą założonego (i odpowiednio skonfigurowanego) konta, które można skasować/zablokować po wszystkim (jeśli musisz udostępnić swoje, to po wszystkim zmień hasło i sprawdź ustawienia konta)
• Jeśli kończysz z kimś współpracę, to niezależnie od powodów rozstania zmień hasła dostępowe, wyłącz zbyteczne konta, preprowadź analizę (audyt) systemów, czy nie zostały jakieś „niespodzianki” (przyda się wiedza i dokumentacja, o której pisałem powyżej)
• Gdzie tylko można, korzystaj z uwierzytelnienia dwuskładnikowego (m.in. brak 2FA dla połączeń po SSH mógł zgubił twórców wtyczki WPML)
• Pamiętaj o regularnych kopiach zapasowych i aktualizacjach, zwłaszcza gdy Twoja strona działa na CMSie (np. WordPress, Joomla, Drupal)
• Jeśli sam nie czujesz się na siłach – włącz nas do współpracy, czy do zarządzania, czy „tylko” w ramach konsultacji, a sam zajmij się zarabianiem pieniędzy ;-)

Są to oczywiście dość ogólne punkty, które raczej należy potraktować jako wskazówki, bo jak już wspomniałem – konkretne działania/rozwiązania, zwłaszcza od strony technicznej i samych procedur zależą od konkretnego środowiska.