Kończmy rok zatem czas na szybką wrzutkę. Dziś będzie o bezpieczeństwie kodu. Ale nie pokażę wam żadnych przykładów. Będzie trochę filozofii i tego jak patrzeć na pojęcie „bezpieczny kod”.

Dwa rodzaje bezpieczeństwa

W języku polskim ciężko wyrazić jednym słowem różnicę pomiędzy angielskim safe a secure. Oba te słowa tłumaczy się jako „bezpieczny”, co powoduje pewne zamieszanie. Spróbuję je trochę wyprostować.

safe, czyli bezpieczeństwo i higiena pracy

Słówko safe można rozumieć jako bezpieczne zachowania. Postępowanie w sposób bezpieczny, nie narażając siebie i innych. W przypadku wytwarzania oprogramowania będzie to odpowiedni dobór narzędzi i praktyk. Wśród nich znajdą się takie, jak testy, czy code review. Jeżeli mamy testy, to możemy powiedzieć, że sprawdzamy nasz kod pod względem działania. Raczej nie powinniśmy zostać zaskoczeni przez oczywiste błędy. Podobnie CR pozwala na wyłapanie różnych baboli. Jednak to nie tylko te dwa zachowania. Na tego rodzaju bezpieczeństwo aplikacji wpływają różne czynniki. Jeżeli mamy dokumentację dla użytkownika końcowego, to duża szansa, że nie zepsuje nam aplikacji. Wykorzystanie CI/CD pozwala na dbanie o kod. Tak samo jak wzorce projektowe, które ułatwiają zrozumienie aplikacji.

Czasami są to duże rzeczy jak na przykład odpowiedni projekt architektury. Czasami są to małe rzeczy, jak użycie odpowiedniego typu danych. Wszystko to na co mamy wpływ tworząc i zarządzając aplikacją można wpisać w ten kontekst.

W tym kontekście działa policja. Chroni obywateli wewnątrz kraju.

secure, czyli bronić i chronić

Inny aspekt bezpieczeństwa reprezentuje słówko secure. Oznacza ono bezpieczeństwo wobec czynników zewnętrznych. Ataki hakerskie, ale też niestabilność zasilania w serwerowni, bo bezpieczeństwo, to nie tylko software. W świecie chmur trochę na dalszy plan zeszły różne problemy związane z zabezpieczeniem przed czynnikami zewnętrznymi. Cloudflare chroni nas przed DDoSami, aplikacje umieszczamy na serwerach wirtualnych, które zarządzane są przez odpowiednie oprogramowanie. W dodatku komunikujemy się z API, a nie z fizyczną maszyną. I to wszystko jest obłożone backupami, które robi dostawca rozwiązania. W teorii wystarczy zatem odpowiednio przechowywać hasła, łączyć się po HTTPS i wykonywać regularnie kopie bezpieczeństwa.

A przecież czynniki zewnętrzne bywają różne. Przeniesienie się OVH do chmury w 2021, czy przypadkowe skasowanie gitlaba przez gitlaba w 2017, to tylko dwa przykłady gdy coś idzie nie tak. I na takie przypadki też musimy być gotowi. Tylko problem polega na tym, że nie przygotujemy się na wszystko. Po prostu jest to niemożliwe.

W tym kontekście działa wojsko. Chroni obywateli przed zagrożeniem z zewnątrz.

A jak zaatakują zombie?

Atak zombie, czyli jeden z najbardziej przeruchany przez kino, gry i literaturę motywów niespodziewanego, niebezpiecznego i nieprzewidywalnego zdarzenia… i jednocześnie podstawowe pytanie, gdy tworzysz modele bezpieczeństwa. Zarówno w kontekście safe jak i secure. Nie przewidzisz wszystkiego. Nie jesteś w stanie zabezpieczyć się na każdą ewentualność. Jednak warto na bieżąco dbać o oba rodzaje bezpieczeństwa, żeby potencjalny problem nie wyrządził nam aż takiej krzywdy.