Support 24/7: +48 61 646 07 77
Z artykułu dowiesz się:
Odpowiem na 2 sposoby: metaforycznie i wprost.
Mówiąc metaforycznie: środowisko testowe może przypominać zapomnianą furtkę w grubych murach zamku, która zamiast solidnej kłódki ma cienki sznurek. Na nic zdadzą się zaawansowane systemy obronne w siedzibie króla, gdy wystarczy zabawkowy nóż i trochę siły, żeby dostać się do środka.
Mówiąc wprost: należy zadbać o bezpieczeństwo środowisk testowych, ponieważ mogą znajdować się tam wrażliwe dane.
Oto elementy, o których warto pamiętać, analizując infrastrukturę i środowiska testowe pod kątem zabezpieczeń:
To najbardziej oczywisty element tej listy. Do danych tego rodzaju należą między innymi:
O czym musisz pamiętać?
Są to nie tylko dane wykorzystywane przez Ciebie, lecz także przez różnego rodzaju automatyzacje. Dlatego ważne jest odpowiednie zabezpieczenie używanych repozytoriów czy pipeline’ów CI/CD.
Służy do filtrowania ruchu sieciowego na podstawie zdefiniowanych reguł. Możliwe jest filtrowanie zarówno ruchu przychodzącego, jak i wychodzącego.
Na co musisz zwrócić uwagę?
Środowiska z bardzo wysokimi wymaganiami dotyczącymi bezpieczeństwa potrafią mieć zablokowany ruch wychodzący, który jest otwierany tylko w razie konkretnej potrzeby. Jest to niewygodne i z reguły – niepotrzebne. Aplikacja zazwyczaj potrzebuje zewnętrznych zależności, korzysta z zewnętrznych wtyczek czy usług do analizy ruchu klientów. Weryfikacja takich elementów jest również konieczna na etapie przygotowywania czy testowania kodu aplikacji, co jest znacznie utrudnione w przypadku zablokowanego ruchu wychodzącego.
Dobre praktyki:
Najlepszym podejściem jest domyślne blokowanie całego ruchu, a dopuszczanie wymaganego ruchu odpowiednimi regułami. Daje to znacznie większą kontrolę nad politykami.
Potencjalne niebezpieczeństwo:
Domyślne akceptowanie całego ruchu, a blokowanie konkretnych adresów czy portów może spowodować, że niechcący zapomnisz o jakiejś usłudze. Efekt: pozostanie ona dostępna ze świata.
SSH to protokół komunikacyjny do bezpiecznego łączenia się ze zdalnym serwerem. Zapewnia kilka różnych metod autoryzacji (hasło, klucz RSA/DSA lub protokół Kerberos), a cała komunikacja jest szyfrowana.
Czego nie polecam?
Zdecydowanie najmniej bezpiecznym i wygodnym sposobem autoryzacji jest hasło. Może ono zostać przechwycone lub złamane atakiem brute force, a dodatkowo utrudnia automatyczne wykonywanie zadań wykorzystujących połączenie SSH. Z kolei protokół Kerberos wymaga dodatkowego czasu na wdrożenie i utrzymanie rozwiązania.
Co polecam?
Najbardziej popularną, najwygodniejszą i bardzo bezpieczną metodą autoryzacji są klucze RSA/DSA. Sugeruję korzystanie z takiego właśnie rozwiązania.
Cały proces nadania dostępu polega na wygenerowaniu pary kluczy (publicznego oraz prywatnego) oraz dopisaniu klucza publicznego do jednego pliku na serwerze zdalnym. Klucz publiczny nie jest żadną informacją wrażliwą. Może być dostępny publicznie i nie wpływa to w żadnym stopniu na bezpieczeństwo.
Z kolei klucz prywatny musi być bardzo dokładnie pilnowany, gdyż jego wyciek może pozwolić osobom trzecim na dostęp do serwera, do którego został dodany odpowiadający klucz publiczny.
Izolacja środowiska testowego od produkcyjnego jest bardzo istotna, ponieważ kod aplikacji w trakcie procesu developmentu może posiadać niezweryfikowane jeszcze problemy czy luki bezpieczeństwa.
Oczywiście zostaną one poprawione przed trafieniem na środowisko produkcyjne, ale zanim to się stanie, trzeba je jeszcze znaleźć i poprawić. Taki proces potrafi trwać wiele miesięcy. Jeżeli środowiska nie są od siebie odizolowane, to włamanie na środowisko testowe np. przez wcześniej wspomnianą lukę może otworzyć dostęp do środowiska produkcyjnego.
Ważne:
Izolacja taka powinna być możliwie jak najbardziej restrykcyjna. Przykłady:
Dobra praktyka:
Jeżeli konieczne jest tymczasowe otwarcie takiego dostępu np. w celu synchronizacji dużej ilości danych, to należy pamiętać, aby taki stan trwał jak najkrócej oraz otwarty był dostęp ze środowiska produkcyjnego do testowego, a nie na odwrót.
O czym musisz pamiętać?
O tym, by nie pracować na danych klientów ze środowiska produkcyjnego, tylko przygotować specjalną bazę danych dla środowiska testowego albo (w przypadku wykorzystywania bazy produkcyjnej) zanonimizować wcześniej dane osobowe w takiej bazie.
To mechanizm, który umożliwia serwerowi zażądanie od klienta informacji uwierzytelniających (nazwy użytkownika oraz hasła). Z reguły wykorzystywany jest do dodatkowego zabezpieczenia wrażliwych elementów serwisu, takich jak panel administratora.
Mechanizm może zostać połączony z filtrowaniem adresów IP po stronie serwera HTTP. W takim wypadku wskazane adresy IP połączą się z serwerem bez żadnej dodatkowej autoryzacji, a klienci o innych adresach IP muszą podać nazwę użytkownika oraz hasło.
Co musisz wiedzieć?
W skrajnych przypadkach, jeśli z jakichś powodów nie jest możliwe zablokowanie ruchu HTTP/HTTPS na firewallu, można w ten sposób zabezpieczyć serwis przed dostępem ze świata, ale znacznie lepszym rozwiązaniem jest oczywiście wykorzystanie zapory sieciowej.
DNS to rozproszony system nazw sieciowych. Jego zadaniem jest tłumaczenie nazw domenowych (np. nasz‑serwis.pl) na odpowiadające im adresy IP. Dzięki temu po wpisaniu w przeglądarce przyjaznego dla nas adresu wiadomo, na który serwer powinno trafić zapytanie.
Co musisz przemyśleć?
To bardzo wygodny mechanizm. Warto jednak zastanowić się, czy chcesz domenę testową w ten sposób wystawiać na świat. Jeśli tak, to pamiętaj, że każda osoba będzie mogła sprawdzić, na jakim serwerze znajduje się dany serwis. Często wystarczy wykorzystać plik hosts i za jego pomocą lokalnie skierować domenę na konkretny adres IP.
Co może być problemem?
Sytuacja, gdy do serwisu muszą mieć dostęp osoby nietechniczne, a ich urządzenia nie są centralnie zarządzane. Wtedy edycja pliku hosts przez taką osobę będzie problematyczna. Rozwiązaniem alternatywnym może być wewnętrzna strefa DNS dostępna np. tylko po zestawieniu połączenia VPN.
W przypadku środowiska testowego istotne jest:
Co może pójść nie tak?
Znane są przypadki, gdy firmy były przekonane o tym, że ich dane są bezpieczne. Było tak aż do momentu, kiedy trzeba było te dane odzyskać. Okazywało się wtedy, że wszystkie wykonywane dotychczas kopie zapasowe są bezużyteczne.
Jeśli uważasz, że Twoje środowisko jest już bezpieczne, to wspaniale. Masz już połowę pracy za sobą! 😉 Najwyższy czas pomyśleć o zleceniu zewnętrznej firmie testów penetracyjnych. Ujawnią one istnienie dodatkowych problemów w infrastrukturze lub samej aplikacji.
O czym musisz pamiętać?
O tym, żeby faktycznie była to zewnętrzna firma, a nie ktoś, nawet bardzo kompetentny, ale pochodzący z wewnątrz organizacji. Jeśli osoba wykonująca testy zna infrastrukturę czy aplikację nawet w niewielkim stopniu, to prawie na pewno wpłynie to negatywnie na wyniki testów.
To, o czym wspomniałem w niniejszym artykule, to nie wszystko, na co musisz zwrócić uwagę, zajmując się kwestią bezpieczeństwa środowisk testowych. To dobry punkt wyjścia do dalszych prac w tym zakresie.
Idea jest prosta: środowisko testowe powinno być bezpieczne i możliwie jak najbardziej wygodne. Paradoksalnie, zbyt skomplikowane standardy w tym zakresie potrafią prowadzić do obniżenia poziomu bezpieczeństwa, ponieważ użytkownicy szukają często sposobów na obejście niewygodnych polityk, aby ułatwić sobie życie. Musisz mieć tego świadomość i w takich sytuacjach wypracować kompromis. Będzie nim dbałość o bezpieczeństwo, które nie będzie wpływało na efektywność i komfort pracy.
Powodzenia!
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-1320x713.jpg)
![Bezpieczeństwo środowisk testowych [krótki poradnik dla DevOps/SysOps]](https://centuria.pl/wp-content/uploads/2022/09/07-12-bezpieczenstwo-srodowisk-424x228.jpg)
