Bezpieczne IT – zagadnienia bezpieczeństwa w obszarze Delivery
Advertorial

Advertorial
Często działy bezpieczeństwa nie są zaangażowane w ramach projektów realizowanych w modelu DevOps. Zastanówmy się zatem, jak te aspekty powinny być zaadresowane, aby DevOps był skuteczny i bezpieczny.

Czy DevOps może być błędem? Określenie DevOps stało się obecnie równie popularne jak do niedawna Agile. W zależności od doświadczenia, wykształcenia oraz pełnionej roli rozumiane jest ono różnie – od zmiany kulturowej, procesowej, organizacyjnej, aż do technologicznej. Często żongluje się tymi elementami, nadając im różne priorytety, zależne od potrzeb organizacji, a częściej preferencji i znajomości tematyki przez decydentów. Oczywiście pewna elastyczność jest możliwa, a nawet wskazana, trzeba jednak pamiętać, że niewłaściwe priorytety czy też pominięcie niektórych elementów raczej będzie stanowić ryzyko, stąd warto przemyśleć temat dogłębnie.

Pominąwszy aspekty organizacyjne, widać, że dziś DevOps w warstwie narzędziowej to automatyzacja wydań i wdrożeń. Trudno sobie wyobrazić wdrożenie tego podejścia bez kontrolowanego, automatycznego procesu wytwarzania oprogramowania, zarządzającego wszystkimi środowiskami i „przesuwającego” oprogramowanie przez kolejne stany. To dla IT taki sam punkt przełomowy jak dla branży samochodowej uruchomienie przestrajanych linii produkcyjnych.

Niewątpliwie wpływ na popularność tego podejścia mają sukcesy firm takich jak Facebook czy Google, w których IT wewnętrznie funkcjonuje zdecydowanie inaczej niż IT w banku czy firmie telekomunikacyjnej. Ponadto pojawienie się rozwiązań typu Jenkins czy Chef spowodowało, że duże działy IT powoli wdrażają rozwiązania automatyzacji procesu dostarczania oprogramowania. Jest to duża zmiana. Jeszcze dwa lata temu dyskusja na temat tego typu rozwiązań zazwyczaj kończyła się stwierdzeniem – no tak, ale my jesteśmy zbyt skomplikowani, złożeni i mamy dużo systemów, które powstały wiele lat temu.

Mamy zatem do czynienia z sytuacją, gdzie większość firm rozpoczęła pracę nad automatyzacją, przy czym przegląd tych aktywności pokazuje, że jest to często DevOps ułomny – powstaje z pomysłu jednego działu (np. Rozwoju), tworzony jest wewnętrznie bez zaangażowania innych stron (np. Utrzymania), po czym następuje faza próby implementacji, która naturalnie spotyka się z oporem pominiętych do tej pory działów. Innymi słowy: do wdrożenia kultury współpracy, zaangażowania i wzajemnego wsparcia stosowane są metody kompletnie zaprzeczające tym wartościom. W ten sposób zaniedbania w zarządzaniu zmianą powodują, że idea bliskiej współpracy likwidująca silosy zostaje pogrzebana. W tym przypadku możemy mówić o błędach menedżerskich, ale warto przyjrzeć się jednemu ryzyku, które my, pracując przy projektach, wyraźnie dostrzegamy, patrząc na implementacje rozwiązań Continuous Delivery. Tym ryzykiem jest brak zaangażowania działów bezpieczeństwa we współdziałanie w ramach DevOps. Nie chodzi tu bynajmniej o proste włączenie ich w projekt (co dalej jest rzadkością), ale uwzględnienie wymogów bezpieczeństwa na poziomach: strategicznym, taktycznym i narzędziowym.

Pominięcie tego we wdrożeniu skutecznie zmniejsza wartość wdrażanych z takim trudem praktyk DevOps, w najlepszym zaś przypadku naraża organizacje na dysfunkcję działu IT, a w najgorszym – na poważne straty finansowe oraz wizerunkowe.

Bezpieczeństwo DevOps
Kwintesencją DevOps jest współpraca wsparta odpowiednio zestawioną linią produkcyjną, która obejmuje:
• Narzędzia budujące środowisko nieprodukcyjne (warstwa sprzętu, systemu operacyjnego, middleware i sieci).
• Narzędzia tworzące kopie danych.
• Narzędzia zarządzające cyklem życia komponentów.
• Diagnostykę i monitoring – zarówno na poziomie funkcjonalności, wydajności, jak i bezpieczeństwa.

Ponadto kluczowe jest, aby bezpieczeństwo było włączane do każdego projektu, by mogło ocenić oraz doradzić, w jaki sposób uwzględnić jego potrzeby w wyborach technologicznych i architektonicznych.

Linia produkcyjna oprogramowania

Niestety, choć osiągnięcie tego wydaje się możliwe, to obecnie jest realizowane bardzo rzadko. Rysunek pokazuje przykładową linię produkcyjną, której konstrukcja adresuje perspektywę bezpieczeństwa. Składa się ona z wielu środowisk – programistycznego, integracyjnego, testów akceptacyjnych, wydajnościowych oraz środowiska produkcyjnego. Niezależnie od tego, które z nich są właściwe dla danej organizacji, schemat pokazuje kilka ważnych elementów:
• Systemy tworzone są w sposób zautomatyzowany, na podstawie przepisu czy też konfigurowalnej, powtarzalnej metody.
• Dane są pozyskiwane i przenoszone z wykorzystaniem mechanizmów wirtualizacyjnych pozwalających na kontrolę nad nimi i dostęp do nich, a także umożliwiających anonimizację.
• Mechanizmy interfejsów są wirtualizowane i symulowane przez odpowiednie rozwiązanie.
• Zarówno proces wydań, jak i wdrożenie kontrolowane jest przez odpowiednią platformę umożliwiającą przede wszystkim pełną audytowalność procesu, zmian w nim zachodzących oraz jego przebiegu.
• Komponenty używane podczas tworzenia oprogramowania poddane są zarządzaniu w aspektach: konfiguracji, bezpieczeństwa oraz compliance’u.
• Dyskusja w zakresie działania systemów odbywa się na podstawie zunifikowanych narzędzi diagnostyczno-monitorujących, zaś logi produkcyjne podlegają anonimizacji, spójnej z maskowaniem innych źródeł danych, m.in. baz.

Rozważając konstrukcję takiej linii produkcyjnej, trzeba wziąć pod uwagę wymagania na poszczególne jej komponenty. Poniżej ich krótka charakterystyka wraz z pytaniami, które wymagają odpowiedzi.

1. Artefakty/Komponenty
Obecnie budowa systemów IT różni się od tego, co znamy z lat poprzednich. Budowanie dzisiaj przypomina integrację wielu komponentów firm trzecich i open source z elementami programowania. Rodzi to wiele zagadnień, które adresują rozwiązania zarządzające cyklem życia komponentów:
• Wersjonowanie – to najprostsze wyzwanie, rozwiązywane na wiele sposobów. Warto pokazać, że jest to ten element, który najczęściej organizacje już rozwiązują, przy czym często zaniedbują aspekty bezpieczeństwa.
• Audyt użytych komponentów pod kątem dziur bezpieczeństwa, złośliwego kodu, spójności wdrożonych wersji, licencji.
• Uruchomienie polityk bezpieczeństwa regulujących automatycznie, które komponenty mogą być użyte w środowisku IT.
• Narzędziowe wsparcie programistów podczas developmentu, realizujące ustalone polityki bezpieczeństwa, integrujące się z narzędziami deweloperskimi.

Dobrze wdrożone narzędzie klasy Software Supply Chain Management musi dawać odpowiedzi na wszystkie wymienione zagadnienia, jednak zazwyczaj firmy skupiają się na wersjonowaniu. To za mało. Aby zapewnić bezpieczeństwo organizacji, a jednocześnie umożliwić jej skalowanie i dynamikę, konieczne jest szersze spojrzenie, zwłaszcza że dziś mamy na rynku odpowiednie rozwiązania, np. Nexus firmy Sonatype.

2. Narzędzie automatyzacyjne
Automatyzacja nigdy nie była prosta, a jeszcze do niedawna była realizowana rękoma zdolnych adminów. Pojawienie się koncepcji Infrastructure As a Code, a także wymóg szybkiego budowania środowisk wymusił konieczność zmiany narzędzi. Pojawiły się rozwiązania typu Chef, Puppet czy Ansible, które są coraz częściej znane i stosowane. Oprócz oczywistych zalet generuje to jednak pewne ryzyka, które muszą być uwzględnione podczas projektowania tych rozwiązań:
• Automatyzacja powinna być oparta na konfigurowalnym modelu (tak jak na przykład realizowane jest to w narzędziu XL Deploy firmy XebiaLabs), w przeciwnym razie każde środowisko będzie najprawdopodobniej wymagało zmian w skryptach. Ograniczy to znacząco zdolność skalowania i dynamikę wdrożeń, a także nie pozwoli na odpowiednie przetestowanie procedur automatyzacji.
• Nieodłącznym elementem wdrożenia jest proces wydań – wybrane narzędzie musi integrować się z rozwiązaniem do zarządzania i kontrolowania procesu wydań. Trzeba także zwrócić uwagę na to, aby możliwa była praca z wykorzystaniem istniejących skryptów oraz obsługa pracy manualnej (co jest często konieczne w organizacjach z długą historią istnienia i dużym długiem technologicznym).
• Narzędzie do automatyzacji musi umożliwiać pełen audyt procesu, tj. wskazać, kto zbudował konkretną procedurę wdrożeniową, kiedy ją uruchomił, jaki był jej wynik itp.
• Z tych samych względów narzędzie musi umożliwiać zarządzanie uprawnieniami użytkownika.

Te wszystkie elementy są najczęściej pomijane podczas wyboru narzędzia, trzeba sobie jednak uświadomić, że nie ma możliwości ich zrealizowania z wykorzystaniem powszechnie używanych narzędzi skryptowych. W przypadku typowych na rynku rozwiązań niestety te problemy są pomijane. Wynika to z faktu, że najczęściej osoby wdrażające automatyzację i DevOps nie angażują w prace działów bezpieczeństwa, z drugiej zaś strony bezpieczeństwo często jest niechętne takim nowinkom.

3. Dane i maskowanie
Budowanie środowisk on demand wymusza potrzebę zasilania ich danymi. Typowe rozwiązania oparte na backupach i macierzach niestety nie zapewniają odpowiedniej skalowalności, uniemożliwiając de facto skuteczne operowanie środowiskami, a także nie dają się używać w trybie self-service.

Dynamika IT wymaga, aby osoba uprawniona mogła wykreować kopię danych w ciągu kilkunastu minut bez angażowania zbyt wielu ludzi. Oczywiście, tego typu sytuacja kreuje potrzeby związane z maskowaniem danych, co sprowadza się nie tylko do jednokrotnego wykonania, ale zaprojektowanego procesu, który zapewni, że:
• wszystkie dane, które mają być zamaskowane, zostaną zamaskowane,
• zmiany w systemie i zmiany w danych będą wychwycone, a procedury maskowania odpowiednio zmodyfikowane w ramach ciągłego procesu profilowania danych,
• dane będą maskowane w sposób spójny we wszystkich źródłach danych, w tym plikach płaskich (co na przykład pozwoli maskować logi produkcyjne, co zaimplementowano w Spica Masking Guard),
• uruchomienie i utrzymanie maskowania nie będzie wymagało zaangażowania dużych zasobów zewnętrznych,
• odświeżenie i powtórne maskowanie bazy nie uniemożliwi pracy w środowisku nieprodukcyjnym (można to osiągnąć np. z platformą Delphix),
• wszystkie te operacje zostaną zapisane i dostępne w raporcie potrzebnym podczas audytu kontrolerów,
• dane te są dostępne w ciągu kilkunastu minut – na żądanie.

Warto zwrócić uwagę, że poprawnie wykonane operacje anonimizacji danych poufnych pozwalają na uruchamianie środowisk nieprodukcyjnych choćby w chmurze. To oczywiście często pieśń przyszłości, ale możliwość obniżenia kosztów umów outsourcingowych już odległym tematem nie jest.

Podsumowanie

Jak widać, konstrukcja linii produkcyjnej, będąca faktycznie technologicznym objawem DevOpsa, nie jest tak oczywista i banalna, gdy zaczniemy uwzględniać wymagania skalowalności i audytowalności. Nie można jednak pominąć aspektów bezpieczeństwa, gdyż w rezultacie otrzymamy bardzo okaleczony DevOps, który w krótkim czasie stanie się kulą u nogi, a nie silnikiem napędowym organizacji. Biorąc pod uwagę zagadnienia związane z wymogami regulacyjnymi, wszystkie wymienione tutaj zagadnienia stają się istotne, gdyż inaczej ryzyko dla firmy staje się bardzo duże i potencjalnie kosztowne. Nawet tak teoretycznie banalne zagadnienie jak diagnostyka stawia niebanalne pytania w zakresie bezpieczeństwa – gdzie są umieszczane dane diagnostyczne, kto ma do nich dostęp, w jaki sposób udostępnić je dostawcy? Zagadnienie jest złożone, ale na szczęście rozwiązywalne. Odpowiednia wiedza pozwala skonstruować nowoczesną i bezpieczną narzędziowo informatykę, a zarazem dynamiczną – na miarę współczesnych wyzwań.

Daniel Spica,
prezes zarządu Spica Solutions