Pięć mitów dotyczących bezpieczeństwa kontenerów – bierzemy je pod lupę

Istnieje sporo mitów związanych z korzystaniem z technologii open source i konteneryzacją. Często sprawiają one, że przedsiębiorstwa nie stosują podstawowych środków bezpieczeństwa lub środki te są niewystarczające. Marie Innes, architekt rozwiązań w firmie Red Hat, rozprawia się z najczęściej spotykanymi mitami i wyjaśnia, jak firmy mogą zabezpieczyć skonteneryzowane aplikacje.

Technologie open source są sercem większości rewolucyjnych technologii, takich jak sztuczna inteligencja i uczenie maszynowe, przetwarzanie brzegowe, przetwarzanie bezserwerowe i właśnie konteneryzacja. Tak jak we wszystkich obszarach IT, tak również przy korzystaniu z oprogramowania open source i kontenerów nie można pomijać kwestii zabezpieczeń. Istnieje przy tym kilka nieporozumień, które powodują, że przedsiębiorstwa nie podchodzą do bezpieczeństwa w sposób całościowy i wielowarstwowy. Tymczasem, odpowiednie podejście stawia na pierwszym planie bezpieczeństwo łańcucha dostaw oprogramowania i uwzględnia kontenery na wszystkich etapach – w procesie tworzenia, udostępniania i uruchamiania. Dzięki temu ryzyko związane ze stosowaniem kontenerów jest ograniczone do minimum.

Pięć najczęstszych mitów związanych z bezpieczeństwem kontenerów

Mit 1: O bezpieczeństwo technologii open source dba tylko powiązana z nią społeczność.

Technologia open source cechuje się dużą innowacyjnością i bezpieczeństwem, ponieważ stoją za nią społeczności liczące tysiące członków. Mimo to firmy muszą wprowadzić pewne podstawowe środki bezpieczeństwa, choćby w związku z używanymi obrazami podstawowymi, procesem kompilacji czy wdrażaniem. Kluczowe jest tu przede wszystkim używanie obrazów kontenerów wyłącznie z wiarygodnych źródeł. Przykładem są sprawdzone podstawowe obrazy systemu operacyjnego Linux lub certyfikowane obrazy na potrzeby języków programowania, oprogramowania warstwy pośredniej i baz danych. Oprócz weryfikacji pochodzenia kontenera aplikacji firma powinna sprawdzić jego zawartość za pomocą skanerów bezpieczeństwa, aby wykryć słabe punkty w obrazie. Warto też korzystać z platformy, która obsługuje spójne tworzenie i skalowanie skonteneryzowanych aplikacji. Takie rozwiązanie powinno zapewniać przede wszystkim zarządzanie cyklem życia, tożsamościami i dostępem oraz bezpieczeństwo danych na platformie.

Mit 2: Dotychczasowe koncepcje bezpieczeństwa są wystarczające.

Od centrum przetwarzania danych po brzeg sieci – zadania kontenerów są rozłożone na wiele infrastruktur. W efekcie trzeba więc zabezpieczyć każdą warstwę stosu infrastruktury i każdy krok cyklu tworzenia aplikacji. Firma może wprawdzie sięgnąć po dotychczasowe mechanizmy zabezpieczające, wymagają one jednak dostosowania do nowych okoliczności. W czasach, w których tak wiele rozwiązań jest definiowanych programowo i używane są liczne technologie oparte na oprogramowaniu, niezbędne są też inne koncepcje bezpieczeństwa dostosowane właśnie do definiowanej programowo sieci czy pamięci masowej.

Mit 3: Bezpieczeństwo to temat ważny tylko podczas audytów.

Zabezpieczenia nierzadko są traktowane jako coś, co utrudnia tworzenie aplikacji. Często są więc brane pod uwagę dopiero na końcu procesu tworzenia oprogramowania. Takie podejście jest ryzykowne. Bezpieczeństwo zawsze musi być częścią kompletnego procesu. Nie chodzi tu tylko o kwestie technologiczne, lecz przede wszystkim o zależności organizacyjne oraz o ścisłą współpracę między wszystkimi uczestnikami procesu i współodpowiedzialność. Bezpieczeństwo nie może być tematem, który pojawia się tylko przy okazji audytów. Niezbędne jest stosowanie podejścia „security by design”, czyli włączenie bezpieczeństwa w każdy etap tworzenia rozwiązań. W odniesieniu do kontenerów i dążenia do tego, aby raz napisana aplikacja działała wszędzie, oznacza to, że w procesie kompilacji musi powstać bezbłędny produkt, który będzie mógł trafić do środowiska produkcyjnego.

Mit 4: Do zapewnienia bezpieczeństwa wystarczy skanowanie pod kątem luk w zabezpieczeniach.

Kontenery należy skanować za pomocą narzędzi, które stosują aktualizowane na bieżąco bazy danych luk w zabezpieczeniach. W oprogramowaniu wciąż wykrywane są nowe słabe punkty, dlatego firmy muszą sprawdzać przy pobieraniu zawartość swoich obrazów kontenerów i wraz z upływem czasu monitorować stan zabezpieczeń wszystkich udostępnianych obrazów. To jednak tylko jeden z aspektów, ponieważ bezpieczeństwo należy zawsze traktować jako całościowy proces i nie można ograniczać go do skanowania pod kątem luk w zabezpieczeniach. W ostatecznym rozrachunku zawsze chodzi o cały cykl życia stosu rozwiązań, a tym samym o wypracowanie takiego potoku DevSecOps, który będzie obejmował monitorowanie bezpieczeństwa aplikacji, ochronę platformy i reagowanie na zagrożenia w środowisku uruchomieniowym.

Mit 5: Programiści nie muszą zajmować się bezpieczeństwem.

Przy ponad milionie projektów open source programiści mogą stosunkowo łatwo wykorzystać istniejące rozwiązania, dopasować je do wymagań danej firmy i wdrożyć w środowisku produkcyjnym. Niezbędne są tu jednak precyzyjnie sformułowane reguły oraz zasady dotyczące kontroli i automatyzacji tworzenia kontenerów. Firmy powinny też przestrzegać najlepszych praktyk w zakresie bezpieczeństwa w potoku tworzenia aplikacji, przede wszystkim w obszarze integracji automatycznych testów bezpieczeństwa.

Przedstawione mity dowodzą, że kwestia bezpieczeństwa musi być traktowana znacznie poważniej zarówno w ujęciu organizacyjnym, jak i technologicznym. Powinna być obecna w całym cyklu życia skonteneryzowanej aplikacji, tj. na etapach projektowania, kompilacji, uruchomienia, zarządzania i automatyzacji oraz dostosowywania. Na etapie projektowania chodzi o identyfikację wymogów bezpieczeństwa, a w trakcie kompilacji o bezpośrednie włączenie zabezpieczeń w stos aplikacji. Aby odciążyć firmę na etapie uruchomienia, należy stosować godne zaufania platformy wyposażone w rozbudowane funkcje bezpieczeństwa. Etap zarządzania i automatyzacji obejmuje automatyzację systemów pod kątem bezpieczeństwa i zgodności z przepisami, a przy dostosowywaniu chodzi o regularne aktualizacje w przypadku pojawienia się zmian w środowisku zabezpieczeń.

Takie całościowe podejście, które na pierwszym planie stawia bezpieczeństwo łańcucha dostaw oprogramowania, pozwala firmie optymalnie przygotować się na korzystanie z kontenerów. Zabezpieczenia przestają być wtedy postrzegane jako czynnik hamujący lub utrudniający pracę i mogą wspierać działanie nowoczesnej infrastruktury informatycznej.