Nalega, aby decydenci IT opracowali lepszą strategię i zmienili tylko to, co jest optymalne dla nowego środowiska – przekształcając zasoby w celu zmniejszenia złożoności, prawdopodobieństwa błędu ludzkiego i kosztów. Według Firmenta błędna konfiguracja kontenerów jest objawem większych problemów związanych z migracjami, które nie uwzględniają modernizacji architektury i praktyki.
Dobra strategia oznacza mniej strat
Oczywiście zarządzanie konfiguracją sieci i kontenerami może być trudne – począwszy od ustalenia alokacji zasobów na potrzeby skalowania kontenerów lub sposobu utrzymania stanu i trwałości przy jednoczesnym unikaniu dryfowania, a skończywszy na zwracaniu uwagi na zabezpieczanie obrazów, rejestrów prywatnych i publicznych, uprawnień i tym podobnych.
Beltramini zaleca, aby liderzy IT wybierali kaskadowo wybór modelu operacyjnego – samoobsługa programistów w infrastrukturze w postaci modułów kodu lub katalogów usług lub za pośrednictwem centralnego zespołu zajmującego się platformą – i odpowiednio ustrukturyzuj organizację. Zespoły ds. bezpieczeństwa i rozwoju powinny również ściśle współpracować, aby zmniejszyć opóźnienia w systemie. Ponadto należy wcześnie zdefiniować kryteria akceptacji i unikać blokad niezgodności z przepisami uniemożliwiających uruchomienie systemów.
Beltramini poleca szelki dla liderów IT automatyzacja, szyfrowanie i natywne integracje, ze wszystkimi działami zaangażowanymi w tworzenie lub zmianę współdzielonego kodu, jeżeli to możliwe. Oznacza to szczegółowe zasady dotyczące poszczególnych procesów, kontenerów i podów oraz szczegółowe konfiguracje środowiska wykonawczego i rozliczanie zasobów. Profile zabezpieczeń należy dostosować pod kątem wywołań systemowych, dostępu do systemu plików, plików binarnych, bibliotek, ograniczeń możliwości i tak dalej.
Aby uwzględnić wszystkie podstawy o tym stopniu złożoności w stosie, konieczne jest podejście systematyczne. Na przykład tylko w przypadku każdego modułu rozważane są obrazy, aplikacje, systemy operacyjne, użytkownicy, wszelkie ukryte tajemnice i nie tylko, mówi Beltramini.
Chris Jenkins, główny architekt rozwiązań w Red Hat, również podkreśla dokładne rozważenie kontenerów i ich aranżacji, a także tego, co znajduje się w kontenerach. Nie zapominaj, iż wiele błędów związanych z bezpieczeństwem może wynikać z zaniedbania podstaw, takich jak aktualizacja i skraweking, nie wspominając już o nieprzemyślanym użyciu kluczy prywatnych i publicznych.
Uprość to, jeżeli możesz
Jenkins namawia liderów IT, aby zaczęli od czystego działania i tam, gdzie to możliwe, starali się zachować prostotę. „Chcesz zacząć od zrobienia czegoś dobrze. Daj im [clean] podstawowy obraz, od którego mogą zacząć i minimalizować ból” – mówi.
Jenkins nalega, aby twórcy systemu korzystali wyłącznie z pakietów niezbędnych do uruchomienia aplikacji. Na przykład, jeżeli zainstalowanych zostanie 50 000 pakietów, które nigdy nie zostaną użyte, prawdopodobnie ujawnią one ogromną liczbę potencjalnych luk w zabezpieczeniach. Zamiast tego podejście Jenkinsa polega na rozpoczęciu od a pusta strona, na której można oprzeć prace nad rozwojem aplikacji, gdzie można poznać stan bezpieczeństwa lub wskaźnik kondycji konkretnego obrazu.
„Tworzymy obrazy podstawowe co sześć tygodni” – mówi. „Następnie przeprowadzamy analizę kodu, aby sprawdzić cały kod. Deweloperzy też będą mieli zależności kodu który wezwie inne biblioteki”.
Ostateczny, niezmienny wykaz materiałów lub receptura powinien być równy i zweryfikowany na podstawie tego konkretnego obrazu. jeżeli coś się zmieni, jeżeli wyjaśnienia okażą się błędne lub klucz nie będzie pasował, nie wdrażaj tego, mówi.
Mniejsze organizacje mogą oczywiście uważać ten poziom zarządzania ryzykiem za wyzwanie. Można rozważyć podzielenie wszystkich zadań, na przykład poprzez cykliczne wykonywanie różnych zadań w różne dni tygodnia, aby zapewnić wszystkim bezpieczeństwo cybernetyczne.
Istnieje wiele różnych narzędzi, które mogą w tym pomóc, szczególnie na arenie open source.
Dinesh Majrekar, dyrektor ds. technologii w firmie Civo, która świadczy usługi, twierdzi, iż niektóre narzędzia mogą pomóc organizacjom.przesuń w lewo‘ w sprawie bezpieczeństwa kontenerów. Oferują takie funkcje, jak skanowanie kontenerów podczas kompilacji i raportowanie do potoków ciągłej integracji i ciągłego dostarczania (CI/CD) w zakresie znanych problemów. Przykłady obejmują to, czy porty sieciowe są otwarte, jak zdefiniowano biblioteki lub czy wersja Java lub Node.js jest nieaktualna.
Przekazywanie programistom ciągłych informacji zwrotnych jest „naprawdę ważne” – mówi Majrekar. Zaleca wybranie najniższych przywilejów i uprawnień, minimalnej liczby instalacji i zależności – chociaż decydenci IT muszą to zrównoważyć z wymaganiami dotyczącymi debugowania.
„Wszędzie można popełnić błędy” – dodaje Majrekar. „Dzięki Kubernetesowi możesz zmienić 100 różnych rzeczy. Być może nie zauważyłeś czegoś, co powinieneś powiedzieć „tak”, a które jest w tej chwili ustawione na „nie” i niekoniecznie są to kontenery, ale zarządzane środowisko Kubernetes, w którym działasz.
„Teraz trzeba na przykład zaaranżować zmianę hasła i jednoczesne wdrożenie kodu w środowisku produkcyjnym” – mówi. „Zamiast tego musisz wykorzystać swoje doświadczenie również w zakresie sekretów, przechowywania i tym podobnych. To znowu sprowadza się do odrobiny edukacji i, jak sądzę, specjalnego szkolenia poświęconego bezpieczeństwu [such as certified Kubernetes security specialist (CKS)] i/lub czytanie.”
Regularny Pwejście i testowanie konfiguracji może być kluczem do ujawnienia luk w zabezpieczeniach związanych z dostępem opartym na rolach i brakujących najlepszych praktyk, takich jak segmentacja sieci lub zarządzanie sekretami – między innymi dlatego, iż potencjalne problemy również stale się zmieniają, mówi.
„Mniejsze firmy mogą być zmuszone do większego ryzyka ze względu na koszty” – dodaje dyrektor naczelny Civo, Mark Boost. „Czasami możesz po prostu sprawić, iż coś zacznie działać, wypchnąć je i zanim się zorientujesz, produkt jest już w fazie produkcyjnej, mimo iż nie zabrałeś się za jego utwardzanie. Dlatego też zaleceniem jest, abyś po prostu do tego wrócił.”
Organizacje powinny dokładnie sprawdzić wszystko samodzielnie. Nie zostawiaj wszystkiego dostawcy usług zarządzanych, zakładając, iż wziął on na siebie tę odpowiedzialność i wszystkie bezpieczeństwo jest obsługiwane.
„Konteneryzacja może dawać ogromne możliwości, ale z wielką mocą wiąże się wielka odpowiedzialność” – dodaje Majrekar.
Zmniejsz publiczne powierzchnie ataku
Crystal Morin, strateg ds. bezpieczeństwa cybernetycznego w Sysdig, zauważa, iż „około 66% rejestrów” jest przez cały czas publicznych – a nie wewnętrznych, nie prywatnych ani zarządzanych przez dostawców. Mówi, iż często „po prostu wyciągają coś z Internetu i wrzucają do swojej infrastruktury”.
Skanowanie odbywa się podczas umieszczania aktualizacji w obrazie dostępnym publicznie, a zespół ds. bezpieczeństwa IT może nie być świadomy tego, co się dzieje. Morin uważa, iż jest to problem, którym muszą się zająć zespoły ds. bezpieczeństwa IT i programistów
Shift w lewo, tarcza w prawo pozostaje najlepszą praktyką: od początku zapewnij zwiększone bezpieczeństwo i kontynuuj ochronę na zapleczu. Zabezpiecz kontenery w środowisku produkcyjnym dzięki wykrywaniu zagrożeń w czasie rzeczywistym i zasadom szybkiego ostrzegania i reagowania, w tym automatyzacji reakcji na incydenty.
Zauważa, iż bez automatyzacji może zabraknąć czasu, wydajności i możliwości.
„Organizacje skupiające się na bezpieczeństwie w chmurze zdają sobie teraz sprawę, iż bezpieczeństwo jest problemem organizacji. Każdy musi być świadomy tego, co robi i jak może pomóc” – mówi Morin.
Integracja zabezpieczeń w całej organizacji zapewnia także wartość wszystkim użytkownikom, a ostatecznie każdemu klientowi.
„Jeśli wejdę i porozmawiam z innymi o bezpieczeństwie, może zrozumieją może 40%” – mówi Morin. „Musimy lepiej współpracować w całej firmie, koordynując działania, a nie tylko w roli technicznych maniaków za kulisami. Przesuń w lewo, aby rozwój był bezpieczniejszy. A to oczywiście dużo większy obraz niż tylko pojemniki.”