Budowa odpornych i bezpiecznych systemów – lekcje z Devoxx Polska

Devoxx Poland to zakrojona na szeroką skalę konferencja dla programistów, gromadząca blisko 3000 inżynierów podczas trzech dni prezentacji i warsztatów prowadzonych przez najbardziej przyszłościowe umysły w branży. W tym roku znalazłem nieoficjalny temat dotyczący budowania, testowania i zabezpieczania złożonych architektur nowoczesnych aplikacji. W szczególności kilka prezentacji pozostawiło we mnie radykalnie nowe spojrzenie na rozwiązania niektórych z tych złożonych wyzwań. Podsumowałem kilka najważniejszych wydarzeń z konferencji, które moim zdaniem są kluczowe dla wszystkich inżynierów.

Podczas wykładu „Software Architecture Testing” Mark Richards przedstawił niesamowity wgląd w to, jak i dlaczego należy testować architekturę naszych aplikacji. Podczas gdy programiści są ogólnie dobrzy w tworzeniu testów jednostkowych, nie byliśmy w ogóle skuteczni w testowaniu warunków skrajnych naszej architektury.

„Jesteśmy zaznajomieni z pisaniem testów jednostkowych, jesteśmy w tym biegli, ale nie jesteśmy tak dobrzy w testowaniu naszej architektury.” – Mark Richards

Jak wyjaśnił Mark podczas swojego wystąpienia, testowanie architektury różni się od testowania aplikacji lub usługi, ale jest wykonalne i nazywa się Sprawność fizyczna.

Więc co tak naprawdę chcemy przetestować, kiedy uruchamiamy funkcję fitness? Mark zidentyfikował niektóre obszary twojej architektury, które musisz przetestować w warunkach skrajnych. Obejmuje to testowanie systemu:

Mark wyjaśnił, że istnieją dwa różne sposoby uruchamiania funkcji fitness: funkcje fitness oparte na trendach i funkcje fitness oparte na progach. Funkcje fitness oparte na trendach chcesz zobaczyć, czy z czasem sytuacja się poprawi, czy pogorszy. Funkcje sprawności progowej monitorować aktywność powyżej określonego progu. Ale kiedy właściwie uruchamiamy te funkcje?

Funkcje fitness mogą być wyzwalane przez zdarzenie, zwykle w potokach CI/CD, lub działać nieprzerwanie w środowisku produkcyjnym. Funkcje wyzwalane są dobre, ponieważ możemy je uruchomić przed rozpoczęciem produkcji. Ale dużym problemem jest to, że musimy pisać te testy w oparciu o to, jak to robimy myśleć Użytkownicy będą zachowywać się w naszych aplikacjach. Ale użytkownicy nigdy nie będą zachowywać się tak, jak tego oczekujemy. Funkcje ciągłe są tańsze i dokładniejsze, ale powiadamiają nas tylko wtedy, gdy spada sprawność naszego systemu lub przekraczany jest predefiniowany próg wydajności w produkcji. Oczywiście daleko jest do ideału, gdy okaże się, że Twoja architektura już ma problemy w produkcji.

Więc czego powinieneś użyć? Odpowiedź właściwie nie jest zaskakująca: funkcje wyzwalane = wczesne wykrywanie, podczas gdy ciągłe = dokładniejsze i tańsze wykrywanie na późniejszym etapie.

Więc wiesz, czym są funkcje fitness i kiedy je wykonywać, ale jak właściwie je wykonujemy? Świetnym wnioskiem z wykładu Marka były narzędzia, które zasugerował, aby pomóc w testowaniu architektury, takie jak:

„Testy te nie dotyczą funkcjonalności, lecz struktury” — Mark Richards

Wykład Barry’ego O’reily’ego był właściwie jedną z moich ulubionych prezentacji DevOxx. To naprawdę stanowiło wyzwanie dla mnie i publiczności pod względem naszego myślenia o budowaniu odpornych systemów dla świata realnego. W tym wykładzie nowa teoria testowania systemów zwana „ teoria pozostałości. Zrozumienie tego to podróż, ale trzymaj się mnie do końca, a nie pożałujesz.

Cała rozmowa koncentrowała się na idei, że nasze systemy oprogramowania są narażone na dużą liczbę losowych czynników stresogennych. W prawdziwym świecie te stresory, lub można je nazwać wydarzeniami, powodują zmiany w naszych systemach, czasem w nieoczekiwany i szkodliwy sposób. Problem polega na tym, że nie jesteśmy w stanie przewidzieć wszystkich stresorów, jakie rzuca na nas rzeczywistość. Ale używając matematycznych zasad tego, co Barry „teoria pozostałości’, nie musimy znaleźć wszystkich możliwych stresorów. Musimy tylko skupić się na tym, aby nasze systemy nadal działały pomimo tych wydarzeń. O jakie zaległości pytasz?

Po stresującym wydarzeniu nasze systemy mogą się zmienić, a to, co z nich pozostało, nazywa się zaległościami. Jeśli chodzi o oprogramowanie, reszta to funkcjonalność oprogramowania po wystąpieniu stresora lub zdarzenia stresowego. Stresory w prawdziwym świecie mogą być niewiarygodnie losowe: użytkownicy będą robić rzeczy, których za milion lat nigdy byś się po nich nie spodziewał. Ale korzystając z zasad Sieć logiczna Kauffmana, Barry faktycznie udowodnił, że kiedy w połączonych systemach zachodzą całkowicie przypadkowe zdarzenia, zaczynają się formować wzorce, a możliwe wyniki są ograniczone. Dzieje się tak, ponieważ węzły w połączonych systemach działają jak atraktory, które dodawałyby strukturę przypadkowości. Te atraktory to składniki, które ostatecznie wpływają na twoją pozostałość. Stresor to zdarzenie zewnętrzne. Komponenty, na które ma wpływ to zdarzenie, to atraktor, a pozostała funkcjonalność to reszta.

„Klątwa wielowymiarowości – jako ludzie, kiedy próbujemy robić przypadkowe rzeczy, ponosimy sromotną porażkę.” Barry O’Reily

„Koncentrujemy się na rzeczach, które są wysoce prawdopodobne w oparciu o nasze własne doświadczenia.” Barry O’Reily

A teraz sedno prezentacji: Dlaczego, do diabła, to wszystko ma znaczenie? Ponieważ Barry zasugerował zmianę sposobu myślenia w testowaniu odporności w architekturze oprogramowania. Zamiast testować każdy możliwy scenariusz, skup się na całkowicie niejasnych i losowych stresorach. Te następnie ujawnią twoje atraktory, które z kolei ujawnią twoje pozostałości. Jeśli skupisz się na funkcjonalnym backlogu, rozwiążesz problemy stojące za bardziej stresującymi wydarzeniami, niż pozwala na to konwencjonalne myślenie. Zmieniacz gier.

Dobrze przetestowana i zaprojektowana architektura nic nie znaczy, jeśli nie jest bezpieczna. Ostatnia prezentacja, którą chcę zrecenzować, pochodziła od Olimpiu Pop i Steve’a Poole’a. Wykład zatytułowany „Trzy rzeczy, które programiści powinni wiedzieć, aby zapewnić bezpieczeństwo swojego kodu”, był świetnym pierwszym spojrzeniem na bezpieczeństwo dla programistów.

Olimpiu i Steve zademonstrowali ogromne rozprzestrzenianie się cyberprzestępczości w skali globalnej. Dopiero około 2016 roku cyberprzestępczość po raz pierwszy przewyższyła handel narkotykami jako najbardziej dochodową działalność przestępczości zorganizowanej na świecie. Obecnie cyberprzestępczość kosztuje około 11,5 biliona dolarów rocznie, czyli 23 razy więcej niż handel narkotykami.

„Gdyby cyberprzestępczość była krajem, byłaby trzecią co do wielkości gospodarką na świecie pod względem PKB.” Steve Poole

Podczas prezentacji prelegenci wyjaśnili, w jaki sposób okno dnia zerowego, czyli czas potrzebny na usunięcie nieznanej wcześniej luki w zabezpieczeniach, skurczyło się niemal do zera. Z pomocą sztucznej inteligencji ci złośliwi aktorzy będą jeszcze skuteczniej znajdować i wykorzystywać luki w oprogramowaniu. Powstał nawet nowy termin: „Prompt Kiddies”, będący odmianą tego, co znaliśmy jako „Script Kiddies”: mniej doświadczeni złoczyńcy, którzy używają narzędzi takich jak ChatGPT do robienia złośliwych rzeczy.

„AI nie odbierze ci pracy, ale złoczyńcy z AI mogą to zrobić.” – Steve Poole

Prezentacja koncentrowała się na tym, w jaki sposób szkodliwi aktorzy atakują dzisiejsze oprogramowanie. Skoncentrowano się na łańcuchu dostaw oprogramowania i komponentach open source, które go tworzą. W szczególności złośliwi aktorzy, którzy wykorzystują luki w zabezpieczeniach tych pakietów. Co ciekawe, Steve wykazał, że w 94% przypadków użycia pakietu podatnego na ataki dostępny był pakiet niezabezpieczony. Na szczęście w rozmowie przedstawiono kilka podstawowych środków, które programiści mogą aktywnie podjąć, aby zapewnić bezpieczeństwo swoich aplikacji:

• Korzystanie z SBOM (Software Bill of Materials) – Ten nowy wymóg zapewnia dużą przejrzystość naszych zależności i zależności.
• przedstawiamy powtarzalne buildy – Jest to mechanizm podwójnego sprawdzania używanych przez nas kompilacji.
• Używać SigStore – bardzo niedawny rozwój, który pozwala rozpocząć podpisywanie kompilacji.

Chociaż żaden z tych trzech środków nie jest panaceum, razem mogą zapewnić skuteczną ochronę przed lukami w aplikacji źródłowej.

Częścią krytyki bezpieczeństwa jest produktywność, oparta na założeniu, że bezpieczeństwo spowalnia działalność biznesową. Aby przeciwstawić się temu argumentowi, chciałbym zakończyć tym, co uważam za najciekawszy i najbardziej wymowny punkt prezentacji:

„Firmy, które przedkładały produktywność nad bezpieczeństwo, były mniej produktywne niż te, które przedkładały bezpieczeństwo.” Steve Poole

DevOxx Polska była niesamowitą konferencją z wieloma radykalnie nowymi spostrzeżeniami i przełomami. Oczywiście było wiele innych niesamowitych prezentacji, o których mógłbym napisać jeszcze 100 blogów (kto wie, może napiszę). Ale dla mnie zyskałem nowe perspektywy, narzędzia i wiedzę jak budować, testować i zabezpieczać nowoczesne aplikacje na współczesne czasy. Sprawdź stronę konferencji DevOxx, aby zobaczyć, gdzie w pobliżu odbywa się następna konferencja.

*** To jest blog konsorcjalny z Security Bloggers Network Blog GitGuardian — automatyczne wykrywanie tajemnic Autor: Mackenzie Jackson. Przeczytaj oryginalny post na: https://blog.gitguardian.com/building-resilient-and-secure-systems-devoxx-poland/