W tradycyjnym spojrzeniu bezpieczeństwo stanowi blokadę dla innowacyjności. Zespoły DevOps chcą mieć możliwość uwolnienia swojego potencjału i kreatywności oraz wdrażania technologii chmurowych, takich jak Docker, Kubernetes, PaaS i architektur bezserwerowych.
Jednakże kwestia bezpieczeństwa wiąże się z wprowadzaniem zasad i protokołów, które ograniczają wybór i wolność. Tym bardziej, jeśli bezpieczeństwo opiera się na odizolowanych od siebie rozwiązaniach i procesach operacyjnych. Takie fragmentaryczne podejście zwiększa złożoność oraz bardziej obciąża zespoły ds. bezpieczeństwa, które z kolei stają się bardziej defensywne w zarządzaniu ryzykiem.
99% oprogramowania komercyjnego zawiera przynajmniej jeden komponent open-source i ta powszechność czyni je celem. Nie dziwi więc fakt, że w 2021 roku nastąpił 650% wzrost liczby ataków na łańcuchy dostaw oprogramowania, których celem były luki w zabezpieczeniach w oddolnych społecznościach open source.
Pojedyncza luka może kosztować miliony w karach, a jeszcze więcej w utraconym zaufaniu. Przedsiębiorstwa muszą być świadome tego, jakie oprogramowanie open source wdrożyły i jak aktywnie nim zarządzają.
Zabezpieczenie się przed tymi zagrożeniami nie jest łatwym zadaniem. Nie należy bagatelizować kwestii zarządzania bezpieczeństwem we własnym zakresie oraz inwestycji w wiedzę i pracowników. „Czy wiesz, jakie oprogramowanie wdrożyłeś? Czy jest ono kompatybilne z zabezpieczeniami Twojej infrastruktury? Czy dysponujesz narzędziami identyfikacji luk w zabezpieczeniach? Czy potrafisz naprawić znalezione problemy?” To tylko niektóre z podstawowych pytań, jakie musi zadać sobie zespół ds. bezpieczeństwa.
Jeśli nie potrafi na nie odpowiedzieć, to co przedsiębiorstwo powinno zrobić? Przestać korzystać z oprogramowania open source? To jest równie ryzykowne. W 2021 r. wprowadzono sześć milionów nowych wersji oprogramowania open source, które pomogły przedsiębiorstwom wprowadzać innowacje, a ostatecznie także osiągać zyski.
Pozytywne podejście do kwestii bezpieczeństwa
Jest jeszcze inny sposób, aby ograniczyć nieodłączne zagrożenia związane z oprogramowaniem open source bez konieczności angażowania znacznych zasobów wewnętrznych. W ramach tego podejścia nie należy odpowiadać „nie”, gdy ktoś mówi: „Chcę spróbować tego, chcę pracować z tym narzędziem”. Bezpieczeństwo powinno raczej stać się powodem, dla którego możesz powiedzieć „tak”.
Bezpieczeństwo to zasadniczo kwestia kultury. A konkretnie: otwartej kultury. W otwartej kulturze innowacyjność i bezpieczeństwo nie stoją ze sobą w sprzeczności. Wzajemnie się przenikają. Chodzi o bezpieczeństwo i tworzenie oprogramowania, czyli DevSecOps.
Kwestia bezpieczeństwa nie jest już ograniczona do konkretnego zespołu w końcowej fazie tworzenia. Biorąc pod uwagę dzisiejsze szybkie cykle wydawnicze, bezpieczeństwo musi być traktowane priorytetowo i zostać włączone w przepływy pracy DevOps, a nie dopiero na etapie, gdy aplikacja ma być wdrożona w środowisku produkcyjnym.
Często wymaga to zmian organizacyjnych, innych praktyk pracy i „resetu kulturowego”.
78% przedsiębiorstw objętych badaniem Red Hat pt. „State of Kubernetes Security Report 2022” realizuje projekty DevSecOps, a 27% integruje i automatyzuje zabezpieczenia w całym cyklu życia aplikacji.
Jednakże bezpieczeństwo oprogramowania open source wykracza poza procesy wewnętrzne. To kwestia przewagi liczebnej: Ty kontra napastnicy. Cyberprzestępcy myślą jak programiści. W ten sposób planują swoje ataki. Tak więc, im więcej programistów po Twojej stronie, którzy szukają błędów i luk w kodzie, tym bezpieczniejszy jest ten kod i tym bardziej sfrustrowani będą atakujący.
Kluczem jest przejrzystość. Zmienia ona bezpieczeństwo z czegoś tajnego na coś, co jest wspólne. Każdy jest jego właścicielem, a wszystko dzieje się publicznie. Open source oznacza więcej osób, które mogą zidentyfikować lukę w zabezpieczeniach, więcej osób do jej zbadania, więcej do opracowania i przetestowania poprawki oraz więcej użytkowników końcowych świadomych i zdolnych do podjęcia działań.
Luki w zabezpieczeniach należy doceniać. Znajdź je szybko, napraw je szybko i ucz się na nich. Jest to wysiłek grupowy i spirala sukcesu, w której im więcej uczestników i otwartości, tym lepsze efekty. Porównajmy to z własnościowym spojrzeniem na bezpieczeństwo, które ostatecznie opiera się na świadomości i umiejętnościach stosunkowo niewielu osób.
Dużym wyzwaniem dla bezpieczeństwa oprogramowania open source jest to, że narzędzia i technologie DevOps – kontenery, Kubernetes, Docker, mikrousługi – zapewniają wiele opcji konfigurowania, które mogą wpłynąć na poziom bezpieczeństwa aplikacji. Błędna konfiguracja stanowi zagrożenie dla bezpieczeństwa. Automatyzacja zarządzania konfiguracją, tak aby technologia (a nie człowiek) zapewniała barierę ochronną, ogranicza te problemy.
Poznaj swoje źródło
Liczy się jednak pochodzenie. Wiedza o tym, skąd pochodzi oprogramowanie open source, to Twoja pierwsza linia obrony. Jedną z najwspanialszych rzeczy w open source jest to, że przedsiębiorstwo dowolnej wielkości może swobodnie wdrażać technologie open source i używać ich. Minusem jest związana z tym inwestycja, którą należy poczynić, aby upewnić się, że projekty te są odpowiednio sprawdzone, zweryfikowane i zabezpieczone przez Twoich własnych programistów, zanim zostaną wprowadzone do produkcji.
Opcjonalnie możesz poszukać oprogramowania open source udostępnianego przez dostawców, którzy wykonują za Ciebie kontrole bezpieczeństwa i aktualizacje. Im mniej dostawców, od których uzyskujesz swoje oprogramowanie, tym mniej partnerów, którym musisz zaufać lub od których otrzymujesz wsparcie. Mniej systemów to także mniejsza złożoność, a więc mniej pracy do wykonania. Lista zakupów powinna zawierać:
oprogramowanie, które jest pozyskiwane ze zweryfikowanych i bezpiecznych sieci dystrybucji oraz certyfikowane pod kątem autentyczności;
kod, który jest przechowywany w bezpiecznych wewnętrznych repozytoriach;
pakiety, które są certyfikowane i silnie zabezpieczone przed manipulacją;
oraz podlegają minimalnym modyfikacjom kodu w okresie eksploatacji produktu.
Więcej niż bezpieczeństwo
Jeśli zostawisz bezpieczeństwo na koniec, to będzie ono przeszkadzać, przerywać pracę, ograniczać Cię, a w efekcie odciągać Twoją uwagę i zasoby od działań, które naprawdę mogą pomóc w rozwoju Twojego przedsiębiorstwa. Z kolei uwzględniane od samego początku – w pakiecie oprogramowania, procesach bezpieczeństwa dystrybutora i platformie wdrożeniowej – bezpieczeństwo napędza innowacje. Staje się niewidocznym, działającym w tle elementem, który zapewnia produktywność, a nie ją ogranicza.
Autor: Wojciech Furmankiewicz, Head of Technology & Solutions Red Hat w regionie Europy Środkowo-Wschodniej