Zarządzanie tożsamością i dostępem użytkownika, czyli o co chodzi z IDP?
Czym jest tożsamość użytkownika? Z czego wynika potrzeba zarządzania dostępem w firmie? Jak działa tzw. IDP? Odpowiedź na te pytania znajdziesz w artykule.
Hej dzisiaj jako Innokrea chcemy Wam opowiedzieć o tym jak dbać o bezpieczeństwo produktu w ramach procesu DevOps, czym są SASTy, DASTy i SCA i jak to wszystko może wpłynąć na poprawę bezpieczeństwa. Polecamy także nasze artykuły o IAC (ang. infrastructure as code), Dockerze oraz SDLC.
SDLC vs SSDLC
SDLC (ang. software development lifecycle) to model opisujący jak powinien przebiegać cały proces wytwarzania oprogramowania – od planowania, aż po testowanie, wdrożenie czy utrzymanie aplikacji. W tradycyjnym podejściu do SDLC często brakuje jednak wyraźnego uwzględnienia bezpieczeństwa jako integralnej części procesu. W efekcie dział bezpieczeństwa bywa postrzegany przez deweloperów jako przeszkoda w szybkim dostarczaniu nowych funkcjonalności. W efekcie aspekt bezpieczeństwa aplikacji może być nawet pomijany lub traktowany jako sprawa drugorzędna. Na ratunek przychodzi tutaj rozwinięcie procesu SDLC, tj. SSDLC (ang. Secure Software Development Lifecycle).
SSDLC integruje praktyki bezpieczeństwa na każdym etapie cyklu życia oprogramowania, podkreślając współpracę między zespołami deweloperskimi, DevOps i działami bezpieczeństwa. Dzięki temu bezpieczeństwo staje się częścią kultury tworzenia oprogramowania, a nie przeszkodą w jego rozwoju.
Rysunek 1 – SDLC kontra SSDLC, źródło: medium.com
Etapy SSDLC można opisać w następujący sposób:
- Planowanie i wymagania bezpieczeństwa – podczas planowania warto przeprowadzać analizy ryzyka, ustalać potencjalne ryzyka wynikające z użytych technologii czy z dziedziny biznesowej problemu, który rozwiązujemy. W tym miejscu należy także zwrócić uwagę na regulacje prawne jak choćby RODO i obowiązujące standardy bezpieczeństwa.
- Bezpieczny design i prototypowanie – w tym etapie należy uwzględnić zabezpieczenia, które zminimalizują powierzchnię ataku i zapewnią odporność systemu na potencjalne zagrożenia. Warto stosować zasadę minimalnych uprawnień.
- Bezpieczne wytwarzanie oprogramowanie – w tym kroku warto postawić między innymi na wykorzystanie narzędzie do statycznej analizy kodu SAST (ang. Static Application Security Testing) oraz narzędzi analizy zależności w kodzie SCA (ang. Software Composition Analysis). Istnieje wiele rozwiązań do SSDLC, które udostępniają także wtyczki do środowisk deweloperskich pozwalających na analizę kodu i poprawki z wykorzystaniem sztucznej inteligencji.
- Bezpieczeństwo i testowanie aplikacji – w tym etapie zaleca się wykorzystanie technik takich jak testy jednostkowe, integracyjne, E2E (ang. end-to-end), fuzz testing czy DAST (ang. Dynamic Application Security Testing) oraz testowanie funkcjonalności związanych z bezpieczeństwem jak: uwierzytelnianie, autoryzacja i szyfrowanie. Mogą tu występować także testy penetracyjne.
- Bezpieczne wdrożenie – w tym kroku należy zadbać o tym aby środowisko było odpowiednio skonfigurowane na wielu poziomach tj. na poziomie IAC (ang. infrastructure as code), chmury, sekretów czy plików yml. Automatyzacja z użyciem CI/CD zmniejsza ryzyko popełniania błędów podczas wdrożenia aplikacji. Istnieją także narzędzia do analizy kodu w formacie yml oraz kodu Terraform (IAC).
- Zarządzanie i monitorowanie – należy również pamiętać, że pomimo wszystkich kroków wykonanych w celu zwiększenia bezpieczeństwa niezbędne jest monitorowanie aplikacji, zbieranie logów, odpowiednio ustawione alerty oraz schematy postępowania w przypadku ataków. Nowe podatności typu zero-day pojawiają się nieustannie i zespoły techniczne powinny umieć na nie reagować.
Procesem SSDLC zajmuje się często zespół DevSecOps, czyli zespół DevOps poszerzony o kompetencje Security.
Współczesny stos technologiczny aplikacji
Nowoczesne aplikacje składają się często z dziesiątek lub setek komponentów tj. zarówno zależności w kodzie jak i zewnętrznych narzędzi, co znacząco zwiększa powierzchnię ataku i utrudnia zarządzanie bezpieczeństwem. Na poniższym, przykładowym diagramie (rysunek 2) możemy zauważyć dziesiątki komponentów wykorzystywanych przy zarządzaniu aplikacją w ramach chmury Azure. Są to między innymi:
- aplikacje chmurowe wspomagające nasz system/aplikację – Azure AD, Azure monitor czy Azure Container Registry wykorzystywane do zarządzania dostępem, monitorowania czy budowania obrazów. Definicje konfiguracji chmury opierają się często o IAC (ang. Infrastructure as code). Błędy w tym miejscu wynikają głównie nie z błędów po stronie chmury, a raczej po stronie użytkownika, w skutek niepoprawnej konfiguracji.
- aplikacje wspomagające wdrożenie – narzędzie CI/CD współpracujące z rejestrami kontenerów i repozytorium GIT
- klaster – główna aplikacja, którą wdrażamy w oparciu o kontenery będzie działać na klastrze (często zarządzalnym w ramach danej chmury). Klaster powinien mieć narzędzia monitorowania aplikacji i logowania, aby zwiększać widoczność (observability) tego co dzieje się w aplikacji.
- kod – współczesny kod wytwarzany w ramach aplikacji posiada często mnóstwo zależności, w tym zależności open-source. Z kolei każda zależność w kodzie, każda paczka może posiadać inne zależności. Jednym z wektorów ataku może być tzw. supply chain attack w którym przejmując repozytorium czy bibliotekę od której zależy nasz kod, ktoś może zmusić nas do nieświadomego wdrożenia podatności poprzez wykorzystane w kodzie zależności. Dodatkowo, deweloperzy mogą popełniać błędy które należy wykrywać i poprawiać czy choćby udostępniać klucze/sekrety w kodzie, które trzeba chronić i usuwać (chodzi tu np. o udostępnienie ich w ramach współdzielonego repozytorium kodu).
- agile/biznes – przy tym wszystkim należy także zadbać o płynność procesu zarządzania bezpieczeństwem, aby nie zakłócić działania biznesowego aplikacji, ani nie utrudniać wprowadzania przez deweloperów nowych funkcjonalności.
Rysunek 2 – Architektura aplikacji stworzona w oparciu o chmure Azure, źródło: microsoft.com
SAST, DAST, SCA i shift-left approach
W artykule omówiliśmy już tematykę związaną z SSDLC i z tym jak skomplikowane może być zarządzanie bezpieczeństwem aplikacji ze względu na ilość używanych narzędzi i zależności w kodzie. Podejście DevSecOps kładzie nacisk na adresowanie problemów bezpieczeństwa tak wcześnie jak to możliwe tzw. shift-left approach tj. implementacje testowania kodu, w tym jego bezpieczeństwa w jak najwcześniejszych etapach rozwoju oprogramowania.
Rysunek 3 – Podejście shift-left, źródło: medium.com
Zespoły DevSecOps wykorzystują więc różne narzędzia wspierające ich pracę w zaadresowaniu problemów bezpieczeństwa na różnych poziomach, na różnych etapach cyklu rozwoju oprogramowania. Są to przede wszystkim narzędzia typu:
- SCA (ang. Software Composition Analysis) – narzędzie tego typu służy do wymienionej wcześniej analizy zależności w kodzie i identyfikacja podatności w nich występujących. Mówimy tu także o zależnościach drugiego poziomu, czyli zależności w naszych paczkach używanych w kodzie. Oprogramowanie typu SCA analizuje też często licencję oraz sugeruje jak naprawiać poszczególne błędy np. poprzez podniesienie poziomu wersji. Może także analizować wpływ podniesienia wersji danej zależności na możliwość poprawnego wykonywania kodu, a także generować tzw. raporty SBOM (ang. software bill of materials) czyli raport zależności pozwalający np. na oszacowanie ryzyka podatności jakie wprowadzają zależne paczki.
- SAST (ang. Static Application Security Testing) – analiza statyczna to skanowanie kodu na wczesnym etapie w celu wykrywania podatności w samym kodzie, który wytwarza nasza firma. Pozwala to na wykrycie takich podatności jak SQL injection, Cross-site scripting czy choćby niebezpiecznych operacji na pamięci.
- Skanowanie sekretów (ang. secret scanning) – tego typu funkcjonalności koncentrują się na wykrywaniu odpowiednich wzorców dotyczących kluczy API, sekretów w kodzie czy logach. Sprawia to, że tajne dane mogą pozostać tajne, a jeśli wyciekną np. w ramach współdzielonego repozytorium mogą być szybko zrotowane.
- DAST (ang. Dynamic Application Security Testing) – narzędzia tej kategorii służą do dynamicznej analizy aplikacji w runtime, czyli podczas jej działania. Symulują one ataki na udostępnione API próbując wstrzyknąć odpowiedni payload na odpowiednie endpointy. Są w stanie wykryć problemy z uwierzytelnieniem, słabe konfiguracje czy słabą walidację inputu użytkownika.
- Wtyczki AI – nowoczesne narzędzia oparte o AI mogą pomagać nie tylko w wykrywaniu podatności w kodzie i nietypowych wzorców, ale także w automatycznej naprawie podatnego kodu. Algorytmy mogą także analizować i sugerować, które obszary wytwarzanego kodu mają największą szansę na błąd.
Powyższe narzędzia są spięte często w jedno rozwiązanie oraz połączone z bazami danych agregującymi dane o podatnościach. Algorytmy poszczególnych narzędzi mają więc za zadanie często oszacowanie dotkliwości (ang. severtity) danych podatności, potencjalnego ryzyka czy priorytetyzację zagrożeń, którymi powinien zająć się zespół DevSecOps lub deweloperzy.
Przykładowe oprogramowanie wspierające DevSecOps
Istnieje wiele narzędzi, które służą do części, lub większości wyżej wymienionych problemów. Są to np. Dependabot, Snyk, Mend, Semgrep, Fortify, SonarQube, CodeQL, Copilot czy ZAP. Nie będziemy ich wszystkich opisywać, ale możemy Wam przybliżyć jak może wyglądać używanie wymienionych funkcjonalności w niektórych narzędziach. Należy także zaznaczyć, że tego typu oprogramowanie jest często wykorzystywane w procesie CI/CD w ramach budowania pipelineów do automatycznego testowania i wdrażania aplikacji. Dzięki temu cały proces jest przewidywalny i powtarzalny.
Przykładowo mamy znaną w świecie cyberbezpieczeństwa instancję tzw. juice-shop, gdzie autorzy przedstawiają gotowe pipeliney w GitHub Actions zintegrowane z takimi narzędziami do skanowania jak CodeQL (analiza statyczna), Dependabot (analiza zależności) czy ZAP.
Podobne gotowe konfiguracje z wykorzystaniem różnych narzędzi CI/CD możemy także znaleźć dla innych narzędzi bezpieczeństwa jak Snyk, czy Semgrep. Wyniki takich skanów dostarczane są następnie na platformę danego rozwiązania.
Rysunek 4 – Zrzut ekranu przedstawiający konsole narzędzia Semgrep, źródło semgrep.dev
Implementacja wtyczek w ramach skanowania w środowisku deweloperskim może wyglądać jak na poniższym zrzucie ekranu.
Rysunek 5 – aplikacja automatycznej naprawy wadliwego kodu poprzez rozszerzenie do Visual Studio Code od Semgrep, źródło: Semgrep.dev
Podsumowanie
Mamy nadzieję, że udało nam się przybliżyć Wam proces zarządzania bezpieczeństwem z perspektywy DevSecOps. Zespoły DevSecOps integrują bezpieczeństwo z każdym etapem procesu tworzenia oprogramowania, pozwalając na wykrywanie i eliminowanie podatności od najwcześniejszych faz rozwoju (shift-left). Dzięki narzędziom typu SAST, DAST, SCA czy skanowanie sekretów, zespoły mogą skuteczniej zabezpieczać aplikacje przed nowoczesnymi zagrożeniami. Podejście SSDLC oraz automatyzacja w ramach CI/CD zapewniają przy tym powtarzalność całego procesu zarządzania bezpieczeństwem. Jeśli jesteście ciekawi większej ilości technicznych szczegółów zapraszamy do zajrzenia do źródeł.
Źródła:
https://medium.com/@usamayaseen/application-security-in-ssdlc-a778205ac810
