Architektura dla bezpieczeństwa

Data: 2019-11-30
Autor: Sebastian Konkol
Architektura dla bezpieczeństwa

Włam do szpitala może mieć wiele twarzy. To może być wyciek bardzo wrażliwych danych, ale może także doprowadzić do paraliżu placówki (ransomware). Przed takimi zdarzeniami trzeba umieć się zabezpieczyć. Włam do szpitala może jednak nieść także potencjał działań terrorystycznych, na przykład podawania pacjentom leków dla nich szkodliwych. Przerażające, prawda?

Jak powinniśmy zmienić spojrzenie na wewnętrzną konstrukcję systemu czy aplikacji, aby minimalizować prawdopodobieństwo skuteczności takiego ataku, a jak, żeby minimalizować ekspozycję na takie ryzyko. To jedno z pytań, jakie ostatnio sobie stawiałem. I muszę przyznać, że sfera bezpieczeństwa zafascynowała mnie. Bardzo.

Od zawsze myślałem, że można być albo architektem, albo bezpiecznikiem, że są to tak szerokie dziedziny wiedzy i wymagają tyle doświadczenia, że jeden człowiek nie podoła. Po kilku ostatnich projektach wiem, że tak się nie uda. Z jednej strony bowiem praktyka pokazuje, że bezpiecznicy działają najczęściej po stronie wymagań (compliance) i niechętnie wchodzą w buty tworzenia rozwiązań. Z drugiej strony jednak, na własnej skórze sprawdziłem, że jednak można połączyć architekturę i bezpieczeństwo na takim poziomie, który – sądząc po jakości ostatecznego wyniku – i tak przewyższa inne układanki. Krótko mówiąc, wdrażając w życie security controls ćwiczyłem aplikowanie architektonicznej perspektywy bezpieczeństwa (security perspective).

Niby to normalna robota architekta – identyfikacja i szacowanie ryzyka i potencjału, analiza wartości opcyjnych, ustalanie obszarów wymaganych zdolności do przyszłego rozwoju poza znane na dziś wymagania. A jednak nałożenie tych ram pracy na wzorce taktyczne implementacji zagadnień bezpieczeństwa – od odporności na ataki, przez ich detekcję i reakcję, po odtwarzanie po ataku – otwiera nowe przestrzenie stawiania oczekiwań. Wcześniej odnajdywałem takie obszary wyłącznie w świecie systemów telekomunikacyjnych. Skoro takie podejście zaczyna się przyjmować w świecie rozwiązań informatycznych, wygląda, że poziom rzemiosła w tej branży także dorasta do potrzeb. Coraz mniej firm patrzy na mnie jak na kosmitę, kiedy mówię, że strefy sieciowe to nie tylko Internet, DMZ i Intranet. Coraz częściej z szefami IT Operations można dyskutować o ograniczaniu uprawnień administratorów systemów. Coraz więcej rozwiązań (chyba dzięki chmurom i usługom chmurowym) jest projektowanych i dokumentowanych w sferach bezpieczeństwa – to także duża porcja edukacji dla wszystkich.

Bardzo pouczające było dla mnie spojrzenie z pozycji „na przecięciu” – nie zupełnie z perspektywy bezpiecznika ale i nie z punktu widzenia architekta rozwiązania. Architekt aplikujący perspektywę bezpieczeństwa łączy dwie sfery trudne – zwykle dyskusja między architektem a programistami jest niełatwa, bo programiści mają często w poważaniu architekturę, a najczęściej jej po prostu nie rozumieją. W przypadku architektury dla bezpieczeństwa trudność podnosi się o rząd wielkości, a do niezrozumienia dochodzi niechęć, a zdarzają się nawet aktywniejsze formy oporu. Ten brak zrozumienia sprawia, że architekt zaczyna być traktowany (w najlepszym przypadku) jak ciało obce, ze wszystkimi konsekwencjami (np. w konieczności schodzenia do bardzo detalicznych, niskopoziomowych zagadnień, żeby cokolwiek sprawdzić). Nie lubię być policjantem, ale w kilku przypadkach i takie okoliczności się zdarzały. Nie chodzi o to, żeby wykrywać podatności w testach penetracyjnych – chodzi o to, żeby tworzyć rozwiązania nie tylko bezpieczne, ale gotowe na włączenie takich aspektów bezpieczeństwa, których na moment ich tworzenia jeszcze nie przewidzieliśmy. Bo sfera cyber to strefa wojny, w której toczenie włączają się firmy, organizacje międzynarodowe, państwa i służby specjalne – dzięki temu rozwija się ona w nieprawdopodobnym tempie.

Równie ciekawą konstatacją było spojrzenie trochę „od kuchni” na to, o czym się mówi w branży – na aspekty bezpieczeństwa terminów marketingowych jak IoT, Cloud, czy też zagadnienia z pogranicza etyki jak dla ML/DL czy szerzej AI. To są ciągle tworzące się architektury, w części oparte na doświadczeniach, a w części twory nieco teoretyczne. Pamiętajmy o tym, bo eksperymentowanie (często agresywne) jest jedyną drogą bycia lepszym od konkurencji, jednak najlepszy nawet eksperyment, w wyniku którego firma będzie martwa, nie przyniesie pozycji rynkowej.

Do wcześniejszego zainteresowania architektonicznymi perspektywami danych dołączam fascynację perspektywami bezpieczeństwa (bo tych także jest kilka). Lubię pisać o moich fascynacjach, więc można się spodziewać ciągu dalszego. Stay tuned!

Pozostaw komentarz