Czym jest bezpieczeństwo DevOps?

• Słownik IAM
• Czym jest bezpieczeństwo DevOps?

Bezpieczeństwo DevOps, znane również jako DevSecOps, to połączenie słów development (projektowanie), operations (operacje) i security (bezpieczeństwo). Zarówno bezpieczeństwo DevOps security, jak i DevSecOps odnoszą się do filozofii włączania bezpieczeństwa do cyklu rozwoju oprogramowania (SDLC) tak wcześnie, jak to możliwe, najlepiej przed napisaniem pojedynczej linii kodu.

Jaka jest różnica między DevOps a DevSecOps?

DevSecOps to rozszerzenie lub ulepszenie filozofii DevOps. Z tego powodu ważne jest, aby zrozumieć, co DevOps i DevSecOps mają wspólnego, zanim omówimy różnice między nimi.

Zarówno DevOps jak i DevSecOps odnoszą się do filozofii lub podejścia do rozwoju oprogramowania, a nie do konkretnego narzędzia lub zestawu narzędzi. Tak jak zainstalowanie systemu śledzenia problemów nie oznacza, że „robisz DevOps”, tak zainstalowanie statycznych lub dynamicznych narzędzi bezpieczeństwa aplikacji nie oznacza, że „robisz DevSecOps”.

DevOps i DevSecOps kładą nacisk na współpracę, automatyzację i aktywne monitorowanie aplikacji. Zdolność do przechwytywania danych aplikacji w czasie rzeczywistym jest kluczem do obu filozofii, ponieważ „robienie” DevOps i DevSecOps wymaga ciągłego przechwytywania i analizowania tych danych w celu odkrycia sposobów na zwiększenie produktywności i zapewniania ulepszeń.

Obie filozofie zależą również od współpracy, a w szczególności od eliminacji silosów organizacyjnych. DevOps dąży do przełamania silosów pomiędzy rozwojem oprogramowania a operacjami IT. Idea polega na tym, że kiedy programiści i personel IT pracują razem, oprogramowanie jest wydawane szybciej i z mniejszą ilością błędów. DevSecOps idzie o krok dalej i stara się zapewnić udział operacji bezpieczeństwa. Idea DevSecOps polega na tym, że gdy programiści, personel IT i personel bezpieczeństwa pracują razem, oprogramowanie jest wydawane szybciej, ma wyższą jakość i jest bezpieczniejsze.

„Robienie” DevSecOps we właściwy sposób oznacza, że aplikacje są odpowiednio zabezpieczone przed zagrożeniami, zanim zostaną dostarczone do produkcji. Praktyka ta jest często nazywana „przesunięciem w lewo”, ponieważ odnosi się do integracji zabezpieczeń na początku osi czasu projektu — przed napisaniem pojedynczej linii kodu — zamiast zajmowania się tą kwestią w późniejszych fazach. W środowisku DevSecOps programiści piszą kod z myślą o bezpieczeństwie — czyli czymś, czego DevOps samo w sobie nie uwzględnia.

Poprzez wprowadzenie do cyklu SDLC praktyk takich jak analiza kodu, badanie zagrożeń i ocena podatności, wraz z ciągłym testowaniem i oceną, DevSecOps zapewnia, że baza kodu jest bezpieczna od samego początku. Oprócz poprawy bezpieczeństwa aplikacji, DevSecOps zwiększa produktywność. Znajdowanie i naprawianie problemów bezpieczeństwa na wczesnym etapie jest znacznie mniej czasochłonne i kosztowne niż konieczność refaktoryzacji kodu na późniejszym etapie cyklu życia oprogramowania.

Wyzwania bezpieczeństwa DevOps

Przy wszystkich korzyściach płynących z DevSecOps, organizacje mogą mieć problemy z jego prawidłowym wdrożeniem. Poznajmy niektóre z najczęstszych wyzwań związanych z bezpieczeństwem DevOps.

• Zbyt duży nacisk na narzędzia, zbyt mały na procesy. Jak wspomniano wcześniej w artykule, zarówno DevOps, jak i DevSecOps to filozofie, a nie zalecenia używania konkretnego oprogramowania.

• Opór kulturowy ze strony programistów, czyli „Ale my zawsze robiliśmy to w ten sposób”. Programiści mogą nie być przyzwyczajeni do praktyk bezpiecznego kodowania. Zwykle programiści kodowali pod kątem wykonalności, a błędy bezpieczeństwa były odkrywane i łatane później. Programiści mogą obawiać się, że konieczność „martwienia się” o bezpieczeństwo spowolni produkcję.

• Opór kulturowy ze strony zespołów bezpieczeństwa. Nie tylko programiści mogą trzymać się „sposobu, w jaki zawsze to robiono”. Zespoły DevOps koncentrują się na szybkości, modyfikując i wypychając kod w ciągu godzin lub dni — jest to szybkie tempo, które może wywołać zdziwienie wśród zespołów bezpieczeństwa. Różnica polega na tym, że zespoły DevOps automatyzują jak najwięcej procesów, podczas gdy zespoły bezpieczeństwa często wykonują wiele czynności ręcznie.

• Nieodpowiednie zarządzanie wpisami tajnymi. Środowiska DevOps są bardzo złożone i głęboko połączone. Nie jest niczym niezwykłym, że działy DevOps posiadają setki grup bezpieczeństwa i tysiące instancji serwerów, z których wszystkie wykorzystują wpisy tajne, takie jak poświadczenia kont uprzywilejowanych, klucze SSH, tokeny API, hasła do baz danych i inne, rozproszone w całym środowisku danych organizacji w stanie znanym jako „rozproszenie wpisów tajnych”. Prosty błąd w konfiguracji może doprowadzić do ujawnienia jednego z tych wpisów, a organizacja może ucierpieć w wyniku katastrofalnego cyberataku.

• Niewystarczające zarządzanie dostępem uprzywilejowanym. Aby przyspieszyć produkcję, wiele zespołów DevOps daje swoim członkom praktycznie nieograniczony dostęp do kont uprzywilejowanych, takich jak root i admin. Co gorsza, wiele osób może współdzielić ten sam zestaw poświadczeń — jest to duży błąd w zakresie bezpieczeństwa, jak również poważny problem podczas audytów zgodności, gdzie oczekuje się od organizacji czystej ścieżki audytu. Dodatkowo, narzędzia do koordynacji, zarządzania konfiguracją i inne narzędzia DevOps mogą mieć bardzo wysokie poziomy dostępu, znacznie przekraczające potrzeby danego narzędzia do działania.

Najlepsze praktyki bezpieczeństwa DevOps

Poniżej przedstawiamy kilka najlepszych praktyk dotyczących wdrażania bezpieczeństwa DevOps w organizacji.

• Pamiętaj, że DevSecOps, podobnie jak DevOps, to sposób myślenia, a nie zestaw narzędzi. Zamiast kupować „narzędzia DevSecOps” i zastanawiać się, gdzie chcesz ich użyć, skup się na swoich celach końcowych, opracuj procesy do ich osiągnięcia, a następnie kup narzędzia, które wspierają te procesy i cele.
• Stosuj odpowiednie metody zarządzania zmianami, aby pokonać opór kulturowy ze strony programistów i personelu bezpieczeństwa. Pokaż obu zespołom, że DevSecOps pozwoli im zaoszczędzić czas i sprawi, że będą bardziej produktywni, a nie mniej. Ustanów jasne standardy kodowania dla swoich programistów i w jak największym stopniu zautomatyzuj procesy i narzędzia bezpieczeństwa.
• Eliminuj rozproszenie wpisów tajnych za pomocą narzędzia takiego jak Keeper Secrets Manager.
• Ogranicz nadmierne uprawnienia i poziomy dostępu za pomocą kontroli, takich jak kontrola dostępu oparta na rolach (RBAC), dostęp oparty na najmniejszych uprawnieniach i dostarczanie w trybie just-in-time.
• Zapobiegaj nadużyciom w zakresie dostępu do uprzywilejowanych danych dzięki rejestrowaniu i audytowi sesji.