Bank zleca swoje projekty wielu kontrahentom. „Zewnętrzni” piszą kod, a następnie przesyłają wyniki w niezbyt wygodnej formie. W szczególności proces wyglądał następująco: przekazali projekt, który przeszedł wraz z nimi testy funkcjonalne, a następnie został przetestowany wewnątrz banku pod kątem integracji, obciążenia i tak dalej. Często odkrywano, że testy kończyły się niepowodzeniem. Następnie wszystko wróciło do zewnętrznego dewelopera. Jak można się domyślić, oznaczało to długi czas oczekiwania na naprawę błędów.
Bank uznał, że możliwe i konieczne jest przeciągnięcie pod swoje skrzydła całego rurociągu, od zatwierdzenia po wydanie. Aby wszystko było jednolite i pod kontrolą zespołów odpowiedzialnych za produkt w banku. To znaczy tak, jakby zewnętrzny wykonawca po prostu pracował gdzieś w sąsiednim pokoju biura. Na stosie korporacyjnym. To jest zwykły devops.
Skąd wziął się Sec? Bezpieczeństwo banku postawiło wysokie wymagania temu, jak zewnętrzny kontrahent może pracować w segmencie sieci, jaki ktoś ma dostęp, jak i kto pracuje z kodem. Tyle, że IB jeszcze nie wiedział, że gdy kontrahenci pracują na zewnątrz, przestrzeganych jest niewiele standardów bankowych. A za kilka dni wszyscy będą musieli zacząć je obserwować.
Proste odkrycie, że wykonawca miał pełny dostęp do kodu produktu, już wywróciło ich świat do góry nogami.
W tym momencie zaczęła się historia DevSecOps, o której chcę Wam opowiedzieć.
Jakie praktyczne wnioski wyciągnął bank z tej sytuacji?
Było wiele kontrowersji wokół tego, że wszystko jest robione w niewłaściwy sposób. Twórcy powiedzieli, że bezpieczeństwo jest zajęte jedynie próbami ingerencji w rozwój, a oni niczym stróże próbują zakazywać bez zastanowienia. Z kolei specjaliści ds. bezpieczeństwa wahali się między wyborem pomiędzy punktami widzenia: „programiści tworzą luki w naszym obwodzie” i „programiści nie tworzą luk, ale sami nimi są”. Spór trwałby długo, gdyby nie nowe żądania rynku i pojawienie się paradygmatu DevSecOps. Można było wyjaśnić, że właśnie ta automatyzacja procesów z uwzględnieniem wymogów bezpieczeństwa informacji „od razu po wyjęciu z pudełka” pomoże wszystkim pozostać szczęśliwymi. W tym sensie, że zasady są spisane natychmiast i nie zmieniają się w trakcie gry (bezpieczeństwo informacji nie zabrania czegoś niespodziewanie), a twórcy na bieżąco informują bezpieczeństwo informacji o wszystkim, co się dzieje (bezpieczeństwo informacji nie napotyka czegoś nagle) . Każdy zespół jest również odpowiedzialny za najwyższe bezpieczeństwo, a nie jacyś abstrakcyjni starsi bracia.
- Ponieważ pracownicy zewnętrzni mają już dostęp do kodu i szeregu systemów wewnętrznych, prawdopodobnie możliwe będzie usunięcie z dokumentów warunku „rozwój musi odbywać się w całości na infrastrukturze banku”.
- Z drugiej strony musimy wzmocnić kontrolę nad tym, co się dzieje.
- Kompromisem było utworzenie zespołów interdyscyplinarnych, w których pracownicy ściśle współpracują z osobami zewnętrznymi. W takim przypadku należy zadbać o to, aby zespół pracował na narzędziach znajdujących się na serwerach banku. Od początku do końca.
Oznacza to, że wykonawcy mogą zostać wpuszczeni, ale muszą mieć przydzielone oddzielne segmenty. Żeby nie wnieśli jakiejś infekcji z zewnątrz do infrastruktury banku i żeby nie widzieli więcej niż to konieczne. Cóż, aby ich działania były rejestrowane. DLP do ochrony przed wyciekami, wszystko to zostało uwzględnione.
W zasadzie wszystkie banki prędzej czy później do tego dochodzą. Tutaj poszliśmy utartą ścieżką i zgodziliśmy się na wymagania dla takich środowisk, w których pracują „elementy zewnętrzne”. Pojawił się maksymalny zakres narzędzi kontroli dostępu, narzędzi do sprawdzania podatności, analizy antywirusowej obwodów, podzespołów i testów. Nazywa się to DevSecOps.
Nagle stało się jasne, że jeśli przed DevSecOps bezpieczeństwo bankowe nie miało kontroli nad tym, co dzieje się po stronie dewelopera, to w nowym paradygmacie bezpieczeństwo jest kontrolowane w taki sam sposób, jak zwykłe zdarzenia na infrastrukturze. Dopiero teraz pojawiają się alerty dotyczące złożeń, kontroli bibliotek i tak dalej.
Pozostaje tylko przenieść zespoły na nowy model. Cóż, stwórz infrastrukturę. Ale to drobiazgi, to jak narysowanie sowy. Właściwie to my pomagaliśmy infrastrukturą, a w tym czasie procesy rozwojowe się zmieniały.
Co się zmieniło
Zdecydowaliśmy się na wdrażanie tego małymi krokami, bo rozumieliśmy, że wiele procesów się rozpadnie, a wielu „zewnętrznych” może nie wytrzymać nowych warunków pracy pod nadzorem wszystkich.
Najpierw stworzyliśmy zespoły interdyscyplinarne i nauczyliśmy się organizować projekty pod kątem nowych wymagań. W sensie organizacyjnym omawialiśmy jakie procesy. W rezultacie powstał schemat rurociągu montażowego ze wszystkimi odpowiedzialnymi.
- CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- PŁYTA CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- prezentacja (raportowanie, komunikacja): Grafana, Kibana, Jira, Confluence, RocketChat.
- operacje (utrzymanie, zarządzanie): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Wybrany stos:
- Baza wiedzy - Atlassian Confluence;
- Śledzenie zadań - Atlassian Jira;
- Repozytorium artefaktów - „Nexus”;
- System ciągłej integracji - „Gitlab CI”;
- System analizy ciągłej – „SonarQube”;
- System analizy bezpieczeństwa aplikacji – „Micro Focus Fortify”;
- System komunikacji – „GitLab Mattermost”;
- System zarządzania konfiguracją – „Ansible”;
- System monitorowania - „ELK”, „TICK Stack” („InfluxData”).
Zaczęto tworzyć zespół, który byłby gotowy wciągnąć do środka wykonawców. Jest świadomość, że jest kilka ważnych rzeczy:
- Wszystko powinno być ujednolicone, przynajmniej przy przesyłaniu kodu. Ponieważ było tyle wykonawców, ile było różnych procesów rozwojowych, mających swoją specyfikę. Trzeba było zmieścić wszystkich w przybliżeniu w jednym, ale z opcjami.
- Wykonawców jest wielu i ręczne tworzenie infrastruktury nie jest wskazane. Każde nowe zadanie powinno rozpocząć się bardzo szybko – czyli instancja powinna zostać wdrożona niemal natychmiast, aby programiści mieli zestaw rozwiązań do zarządzania swoim potokiem.
Aby zrobić pierwszy krok, trzeba było zrozumieć, co się dzieje. I musieliśmy ustalić, jak się tam dostać. Zaczęliśmy od pomocy w narysowaniu architektury docelowego rozwiązania zarówno w zakresie infrastruktury, jak i automatyzacji CI/CD. Następnie rozpoczęliśmy montaż tego przenośnika. Potrzebowaliśmy jednej infrastruktury, takiej samej dla wszystkich, w której kursowałyby te same przenośniki. Zaproponowaliśmy opcje z obliczeniami, pomyślał bank, a następnie zdecydowaliśmy, co zostanie zbudowane i za jakie fundusze.
Następnie następuje utworzenie obwodu - instalacja oprogramowania, konfiguracja. Tworzenie skryptów do wdrażania i zarządzania infrastrukturą. Następnie następuje przejście na obsługę przenośników.
Postanowiliśmy przetestować wszystko na pilocie. Co ciekawe, podczas pilotażu po raz pierwszy w banku pojawił się pewien stos. Między innymi zaoferowano krajowemu dostawcy jednego z rozwiązań w ramach pilotażu w celu szybkiego uruchomienia. Ochrona poznała go podczas pilotażu i pozostawiło to niezapomniane wrażenie. Kiedy zdecydowaliśmy się na zmianę, na szczęście warstwa infrastruktury została zastąpiona rozwiązaniem Nutanix, które było już wcześniej w banku. Co więcej, wcześniej był przeznaczony dla VDI, ale wykorzystaliśmy go ponownie do usług infrastrukturalnych. Przy małych ilościach nie pasowało to do ekonomii, ale przy dużych ilościach stało się doskonałym środowiskiem do rozwoju i testowania.
Reszta stosu jest mniej więcej znana każdemu. Wykorzystano narzędzia automatyzujące w Ansible, a specjaliści ds. bezpieczeństwa ściśle z nimi współpracowali. Stos Atlassin był używany przez bank przed realizacją projektu. Narzędzia bezpieczeństwa Fortinet – zostało to zaproponowane przez samych specjalistów od bezpieczeństwa. Ramka testowa została stworzona przez bank, bez zadawania pytań. System repozytoriów rodził pytania, musiałem się do tego przyzwyczaić.
Wykonawcy otrzymali nowy stos. Dali nam czas na napisanie go od nowa dla GitlabCI, migrację Jiry do segmentu bankowego i tak dalej.
krok po kroku
Krok 1. W pierwszej kolejności wykorzystaliśmy rozwiązanie od krajowego dostawcy, produkt został podłączony do nowo powstałego segmentu sieci DSO. Platformę wybrano ze względu na czas dostawy, elastyczność skalowania i możliwość pełnej automatyzacji. Przeprowadzone testy:
- Możliwość elastycznego i w pełni zautomatyzowanego zarządzania infrastrukturą platformy wirtualizacyjnej (sieć, podsystem dyskowy, podsystem zasobów obliczeniowych).
- Automatyzacja zarządzania cyklem życia maszyn wirtualnych (szablony, migawki, kopie zapasowe).
Po instalacji i podstawowej konfiguracji platforma posłużyła jako miejsce umieszczenia podsystemów drugiego etapu (narzędzia DSO, zarysy rozwoju systemów detalicznych). Utworzono niezbędne zestawy potoków - tworzenie, usuwanie, modyfikacja, tworzenie kopii zapasowych maszyn wirtualnych. Rurociągi te wykorzystano w pierwszym etapie procesu wdrażania.
W rezultacie dostarczony sprzęt nie spełnia wymagań banku w zakresie wydajności i odporności na awarie. DIT banku podjął decyzję o stworzeniu kompleksu w oparciu o pakiet oprogramowania Nutanix.
Krok 2. Wzięliśmy zdefiniowany stos i napisaliśmy zautomatyzowane skrypty instalacyjne i pokonfiguracyjne dla wszystkich podsystemów, tak aby wszystko zostało przeniesione z pilota do obwodu docelowego tak szybko, jak to możliwe. Wszystkie systemy zostały wdrożone w konfiguracji odpornej na awarie (gdzie możliwości te nie są ograniczone polityką licencyjną dostawcy) i połączone z podsystemami metryk i gromadzenia zdarzeń. IB przeanalizował spełnienie swoich wymagań i dał zielone światło.
Krok 3. Migracja wszystkich podsystemów i ich ustawień do nowego PAC-a. Napisano od nowa skrypty automatyzacji infrastruktury, a migracja podsystemów DSO została zrealizowana w trybie w pełni zautomatyzowanym. Kontury rozwoju własności intelektualnej zostały odtworzone przez rurociągi zespołów programistycznych.
Krok 4. Automatyzacja instalacji oprogramowania aplikacyjnego. Zadania te postawili przed sobą liderzy nowych zespołów.
Krok 5. Eksploatacja.
Dostęp zdalny
Zespoły programistów wymagały maksymalnej elastyczności w pracy z układem, a wymóg zdalnego dostępu z osobistych laptopów został podniesiony już na samym początku projektu. Bank miał już zdalny dostęp, ale nie był on odpowiedni dla deweloperów. Faktem jest, że schemat wykorzystywał połączenie użytkownika z chronionym VDI. Było to odpowiednie dla tych, którzy potrzebowali jedynie poczty i pakietu biurowego w swoim miejscu pracy. Programiści potrzebowaliby ciężkich klientów, wysokiej wydajności i dużych zasobów. I oczywiście musiały być statyczne, ponieważ utrata sesji użytkownika dla tych, którzy pracują z VStudio (na przykład) lub innym SDK, jest niedopuszczalna. Zorganizowanie dużej liczby grubych statycznych VDI dla wszystkich zespołów programistycznych znacznie zwiększyło koszt istniejącego rozwiązania VDI.
Postanowiliśmy popracować nad zdalnym dostępem bezpośrednio do zasobów segmentu deweloperskiego. Jira, Wiki, Gitlab, Nexus, stanowiska do budowania i testowania, infrastruktura wirtualna. Ochroniarze zażądali, aby dostęp mógł być zapewniony wyłącznie pod następującymi warunkami:
- Wykorzystanie technologii dostępnych już w banku.
- Infrastruktura nie powinna wykorzystywać istniejących kontrolerów domeny przechowujących rekordy obiektów kont produktywnych.
- Dostęp powinien być ograniczony tylko do zasobów wymaganych przez konkretny zespół (aby jeden zespół produktowy nie miał dostępu do zasobów innego zespołu).
- Maksymalna kontrola nad RBAC w systemach.
W rezultacie dla tego segmentu utworzono odrębną domenę. Domena ta zawierała wszystkie zasoby segmentu programistycznego, zarówno dane uwierzytelniające użytkowników, jak i infrastrukturę. Zarządzanie cyklem życia rekordów w tej domenie odbywa się przy wykorzystaniu istniejącego w banku IdM.
Bezpośredni zdalny dostęp został zorganizowany w oparciu o istniejący sprzęt banku. Kontrola dostępu została podzielona na grupy AD, którym odpowiadały reguły dotyczące kontekstów (jedna grupa produktowa = jedna grupa reguł).
Zarządzanie szablonami maszyn wirtualnych
Szybkość tworzenia pętli montażowo-testowej to jeden z głównych KPI stawianych przez kierownika jednostki deweloperskiej, ponieważ szybkość przygotowania środowiska wpływa bezpośrednio na całkowity czas wykonania rurociągu. Rozważano dwie opcje przygotowania podstawowych obrazów maszyn wirtualnych. Pierwsza to minimalne rozmiary obrazów, domyślne dla wszystkich produktów systemowych, maksymalna zgodność z polityką banku dotyczącą ustawień. Drugi to obraz bazowy, który zawiera zainstalowany wytrzymały POPPO, którego czas instalacji może znacząco wpłynąć na szybkość realizacji rurociągu.
Podczas rozwoju wzięto pod uwagę także wymagania infrastrukturalne i bezpieczeństwa - aktualność obrazów (łatki itp.), integracja z SIEM, ustawienia bezpieczeństwa zgodnie ze standardami bankowymi.
W rezultacie zdecydowano się na użycie minimalnej liczby obrazów, aby zminimalizować koszty ich aktualizacji. O wiele łatwiej jest zaktualizować podstawowy system operacyjny niż łatać każdy obraz pod kątem nowych wersji POPPO.
Na podstawie wyników utworzono listę minimalnego wymaganego zestawu systemów operacyjnych, których aktualizacja jest przeprowadzana przez zespół operacyjny, a skrypty z rurociągu są w pełni odpowiedzialne za aktualizację oprogramowania i w razie potrzeby zmianę wersji zainstalowanego oprogramowania - wystarczy przenieść wymagany tag do potoku. Tak, wymaga to od zespołu ds. produktu Devops posiadania bardziej złożonych scenariuszy wdrażania, ale znacznie skraca czas operacyjny wymagany do obsługi obrazów podstawowych, który w przeciwnym razie wymagałby utrzymania ponad stu podstawowych obrazów maszyn wirtualnych.
dostęp do Internetu
Kolejną przeszkodą w bezpieczeństwie bankowości był dostęp do zasobów Internetu ze środowiska deweloperskiego. Ponadto dostęp ten można podzielić na dwie kategorie:
- Dostęp do infrastruktury.
- Dostęp dla programistów.
Dostęp do infrastruktury został zorganizowany poprzez proxy do zewnętrznych repozytoriów za pomocą Nexusa. Oznacza to, że nie zapewniono bezpośredniego dostępu z maszyn wirtualnych. Umożliwiło to osiągnięcie kompromisu w zakresie bezpieczeństwa informacji, który kategorycznie sprzeciwiał się zapewnieniu jakiegokolwiek dostępu do świata zewnętrznego z segmentu deweloperskiego.
Programiści potrzebowali dostępu do Internetu z oczywistych powodów (stackoverflow). I chociaż wszystkie polecenia, jak wspomniano powyżej, miały zdalny dostęp do obwodu, nie zawsze jest to wygodne, gdy nie można wykonać ctrl+v z miejsca pracy programisty w banku w IDE.
Osiągnięto porozumienie z IS, że początkowo, na etapie testów, dostęp będzie zapewniany za pośrednictwem bankowego pełnomocnika w oparciu o białą listę. Po zakończeniu projektu dostęp zostanie przeniesiony na czarną listę. Przygotowano ogromne tabele dostępowe, które wskazywały główne zasoby i repozytoria, do których dostęp był wymagany na początku projektu. Koordynacja tych dostępów zajęła sporo czasu, co umożliwiło naleganie na jak najszybsze przejście na czarne listy.
wyniki
Projekt zakończył się nieco ponad rok temu. Co ciekawe, wszyscy wykonawcy przeszli na nowy komin na czas i nikt nie odszedł ze względu na nową automatyzację. IB nie spieszy się z dzieleniem się pozytywnymi opiniami, ale też nie narzeka, z czego możemy wnioskować, że im się to podoba. Konflikty ustąpiły, ponieważ bezpieczeństwo informacji znów jest pod kontrolą, ale nie zakłóca procesów rozwojowych. Zespołom powierzono większą odpowiedzialność, a ogólne podejście do bezpieczeństwa informacji uległo poprawie. Bank zrozumiał, że przejście na DevSecOps jest niemal nieuniknione i zrobił to moim zdaniem jak najbardziej delikatnie i poprawnie.
Alexander Shubin, architekt systemu.
Źródło: www.habr.com