DevOps vs DevSecOps: hogyan nézett ki egy bankban

A bank a projektjeit sok vállalkozónak adja ki. A „külsők” kódot írnak, majd az eredményeket nem túl kényelmes formában továbbítják. Konkrétan a folyamat így nézett ki: átadtak velük egy projektet, ami átment a funkcionális teszteken, majd a banki peremen belül tesztelték az integrációt, a terhelést stb. Gyakran kiderült, hogy a tesztek kudarcot vallanak. Aztán minden visszakerült a külső fejlesztőhöz. Ahogy sejtheti, ez hosszú átfutási időt jelentett a hibajavításokhoz.

A bank úgy döntött, hogy lehetséges és szükséges az egész vezetéket a szárnyai alá húzni, a kötelezettségvállalástól az elengedésig. Hogy minden egységes legyen és a termékért felelős csapatok ellenőrzése alatt álljanak a bankban. Vagyis mintha a külső vállalkozó egyszerűen az iroda szomszédos helyiségében dolgozna valahol. A vállalati veremben. Ez egy közönséges devops.

Honnan jött Sec? A bank biztonsága magas követelményeket támaszt amellett, hogy egy külső vállalkozó hogyan dolgozhat a hálózati szegmensben, milyen hozzáféréssel rendelkezik valaki, hogyan és ki dolgozik a kóddal. Csak az IB még nem tudta, hogy amikor a vállalkozók kint dolgoznak, kevés banki szabványt követnek. Aztán pár napon belül mindenkinek el kell kezdenie megfigyelni őket.

Az az egyszerű kinyilatkoztatás, hogy a vállalkozó teljes hozzáféréssel rendelkezik a termékkódhoz, máris felforgatta a világukat.

Ebben a pillanatban elkezdődött a DevSecOps története, amiről szeretnék nektek mesélni.

Milyen gyakorlati következtetéseket vont le a bank ebből a helyzetből?

Sok vita volt arról, hogy mindent rosszul csinálnak. A fejlesztők elmondták, hogy a biztonság csak azzal van elfoglalva, hogy beavatkozzon a fejlesztésbe, és ők, mint az őrök, gondolkodás nélkül próbálják tiltani. A biztonsági szakemberek viszont tétováztak a következő szempontok között: „a fejlesztők sebezhetőséget hoznak létre az áramkörünkben” és „a fejlesztők nem hoznak létre sebezhetőséget, hanem maguk azok”. A vita sokáig folytatódott volna, ha nem jönnek létre az új piaci igények és a DevSecOps paradigma megjelenése. Meg lehetett magyarázni, hogy a folyamatok automatizálása, amely az információbiztonsági követelményeket is figyelembe veszi, „kivételesen” segít, hogy mindenki boldog legyen. Abban az értelemben, hogy a szabályokat azonnal leírják, és nem változnak a játék során (az információbiztonság nem tilt meg váratlanul valamit), és a fejlesztők folyamatosan tájékoztatják az információbiztonságot mindenről, ami történik (az információbiztonság nem találkozik hirtelen valamivel) . Minden csapat felelős a végső biztonságért is, nem pedig néhány elvont idősebb testvér.

1. Mivel a külső munkatársak már hozzáférnek a kódhoz és számos belső rendszerhez, valószínűleg ki lehet venni a dokumentumokból a „fejlesztést teljes mértékben a bank infrastruktúráján kell végezni” követelményt.
2. Másrészt meg kell erősíteni a kontrollt a történések felett.
3. A kompromisszum a többfunkciós csapatok létrehozása volt, ahol az alkalmazottak szorosan együttműködnek külső emberekkel. Ebben az esetben meg kell győződnie arról, hogy a csapat a bank szerverein lévő eszközökön dolgozik. Elejétől végéig.

Vagyis a vállalkozókat be lehet engedni, de külön szegmenseket kell nekik adni. Azért, hogy ne vigyenek be valamiféle fertőzést kívülről a bank infrastruktúrájába, és ne lássanak többet a szükségesnél. Nos, hogy a tetteik naplózva legyenek. DLP a szivárgás elleni védelem érdekében, mindez benne volt.

Erre elvileg minden bank előbb-utóbb rájön. Itt végigmentünk a kitaposott úton, és megállapodtunk az olyan környezetek követelményeiben, ahol „külsősök” működnek. A hozzáférés-ellenőrző eszközök, a sebezhetőség-ellenőrző eszközök, az áramkörök, szerelvények és tesztek vírusellenőrző elemzése maximális skálája jelent meg. Ezt DevSecOps-nak hívják.

Hirtelen világossá vált, hogy ha a DevSecOps előtt a bankbiztonságnak nem volt befolyása arra, hogy mi történik a fejlesztői oldalon, akkor az új paradigmában a biztonságot ugyanúgy ellenőrzik, mint a hétköznapi eseményeket az infrastruktúrán. Csak most vannak figyelmeztetések az összeállításokról, a könyvtárak vezérléséről stb.

Már csak a csapatok áthelyezése van hátra az új modellre. Nos, hozd létre az infrastruktúrát. De ezek apróságok, olyan, mintha baglyot rajzolnánk. Tulajdonképpen az infrastruktúrában segítettünk, és akkoriban változtak a fejlesztési folyamatok.

Mi változott

Azért döntöttünk úgy, hogy kis lépésekben valósítjuk meg, mert megértettük, hogy sok folyamat szétesik, és sok „külsős” nem biztos, hogy mindenki felügyelete mellett képes ellenállni az új munkakörülményeknek.

Először keresztfunkcionális csapatokat hoztunk létre, és megtanultuk az új követelmények figyelembevételével projekteket szervezni. Szervezeti értelemben megbeszéltük, hogy milyen folyamatokat. Az eredmény egy diagram volt az összeszerelő vezetékről az összes felelőssel.

• IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
• Teszt: Sonarqube, SoapUI, jMeter, szelén: MF Fortify, Performance Center, MF UFT, Ataccama.
• Bemutatás (riportálás, kommunikáció): Grafana, Kibana, Jira, Confluence, RocketChat.
• Művelet (karbantartás, menedzsment): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Kiválasztott köteg:

• Tudásbázis - Atlassian Confluence;
• Feladatkövető - Atlassian Jira;
• Műterméktár - „Nexus”;
• Folyamatos integrációs rendszer - „Gitlab CI”;
• Folyamatos elemző rendszer - „SonarQube”;
• Alkalmazásbiztonsági elemző rendszer - „Micro Focus Fortify”;
• Kommunikációs rendszer - „GitLab Mattermost”;
• Konfigurációkezelő rendszer - „Ansible”;
• Felügyeleti rendszer - „ELK”, „TICK Stack” („InfluxData”).

Elkezdtek létrehozni egy csapatot, amely készen állna a vállalkozók bevonására. Felismerhető, hogy számos fontos dolog van:

• Mindennek egységesnek kell lennie, legalábbis a kód továbbításakor. Mert annyi volt a kivitelező, ahány különböző fejlesztési folyamat a maga sajátosságaival. Mindenkit körülbelül egybe kellett illeszteni, de lehetőségekkel.
• Sok vállalkozó van, és az infrastruktúra manuális létrehozása nem megfelelő. Minden új feladatnak nagyon gyorsan el kell kezdődnie – vagyis a példányt szinte azonnal üzembe kell helyezni, hogy a fejlesztők egy sor megoldással rendelkezzenek a folyamat kezeléséhez.

Az első lépés megtételéhez meg kellett érteni, mi történik. És meg kellett határoznunk, hogyan juthatunk el oda. Kezdetben segítettünk a célmegoldás architektúrájának megrajzolásában mind az infrastruktúra, mind a CI/CD automatizálás területén. Aztán elkezdtük összeszerelni ezt a szállítószalagot. Egyetlen, mindenki számára azonos infrastruktúrára volt szükségünk, ahol ugyanazok a szállítószalagok futnának. Számításokkal kínáltunk lehetőségeket, gondolta a bank, majd eldöntötte, hogy mit és milyen forrásból építenek.

Következő az áramkör létrehozása - szoftver telepítése, konfigurálása. Szkriptek fejlesztése az infrastruktúra telepítéséhez és kezeléséhez. Ezután következik az átállás a szállítószalag támogatására.

Úgy döntöttünk, hogy mindent tesztelünk a piloton. Érdekes módon a pilotálás során először jelent meg egy bizonyos stack a bankban. Többek között az egyik megoldás hazai szállítóját ajánlották fel a pilot hatókörébe a gyors indulás érdekében. A biztonságiak megismerték őt a pilóta közben, és ez felejthetetlen benyomást tett. Amikor a váltás mellett döntöttünk, szerencsére az infrastruktúra réteget egy Nutanix megoldásra cserélték, ami már korábban is a bankban volt. Sőt, azelőtt VDI-nek volt, de mi újra felhasználtuk infrastrukturális szolgáltatásokhoz. Kis mennyiségben nem fért be a gazdaságba, de nagy mennyiségnél kiváló fejlesztési és tesztelési környezetté vált.

A verem többi része többé-kevésbé mindenki számára ismerős. Az Ansible automatizálási eszközeit használták, és a biztonsági szakemberek szorosan együttműködtek velük. Az Atlassin stacket a bank használta a projekt előtt. Fortinet biztonsági eszközök – maguk a biztonsági emberek javasolták. A tesztelési keretet a bank készítette, nem tettek fel kérdéseket. A repository rendszer kérdéseket vetett fel, meg kellett szoknom.

A vállalkozók új köteget kaptak. Időt adtak nekünk, hogy átírjuk a GitlabCI-re, és áttelepítsük a Jira-t a banki szegmensbe, és így tovább.

lépésről lépésre

Lépés 1. Először egy hazai gyártó megoldását használtuk, a terméket egy újonnan létrehozott DSO hálózati szegmenshez kapcsoltuk. A platformot a szállítási idő, a skálázási rugalmasság és a teljes automatizálás lehetősége miatt választották ki. Elvégzett tesztek:

• A virtualizációs platform infrastruktúra (hálózat, lemez alrendszer, számítási erőforrások alrendszer) rugalmas és teljesen automatizált kezelésének lehetősége.
• Virtuális gép életciklus-kezelésének automatizálása (sablonok, pillanatképek, biztonsági mentések).

A platform telepítése és alapkonfigurációja után a második szakasz alrendszereinek (DSO eszközök, kiskereskedelmi rendszerfejlesztési vázlatok) elhelyezési pontjaként szolgált. Elkészültek a szükséges csővezetékek - virtuális gépek létrehozása, törlése, módosítása, biztonsági mentése. Ezeket a csővezetékeket a telepítési folyamat első szakaszaként használták.

Az eredmény az, hogy a szállított berendezés nem felel meg a bank teljesítmény- és hibatűrési követelményeinek. A bank DIT-je a Nutanix szoftvercsomagon alapuló komplexum létrehozásáról döntött.

2 színpad. Átvettük a definiált veremet, és automatizált telepítési és utólagos konfigurációs szkripteket írtunk az összes alrendszerhez, hogy minden a lehető leggyorsabban átkerüljön a pilotból a céláramkörbe. Az összes rendszert hibatűrő konfigurációban telepítették (ahol ezt a képességet nem korlátozzák a szállító licencszabályai), és mérőszámokhoz és eseménygyűjtési alrendszerekhez csatlakoztak. Az IB elemezte a követelményeinek való megfelelést, és zöld utat adott.

3 színpad. Az összes alrendszer és beállításaik áttelepítése az új PAC-ba. Az infrastruktúra automatizálási szkriptek átírása megtörtént, a DSO alrendszerek migrációja teljesen automatizált módban történt. Az IP-fejlesztés körvonalait a fejlesztőcsapatok pipeline-jai alkották újra.

Lépés 4. Alkalmazási szoftverek telepítésének automatizálása. Ezeket a feladatokat az új csapatok csapatvezetői határozták meg.

Lépés 5. Kizsákmányolás.

Távoli hozzáférés

A fejlesztőcsapatok maximális rugalmasságot kértek az áramkörrel való munkavégzés során, és már a projekt elején felvetődött a személyi laptopokról való távoli hozzáférés követelménye. A bank már rendelkezett távoli hozzáféréssel, de fejlesztők számára nem volt megfelelő. Az a tény, hogy a rendszer a felhasználó védett VDI-hez való csatlakozását használta. Ez azoknak volt megfelelő, akiknek csak postára és irodai csomagra volt szükségük a munkahelyükön. A fejlesztőknek nehéz kliensekre lenne szükségük, nagy teljesítményre, sok erőforrással. És persze statikusnak kellett lenniük, mivel a felhasználói munkamenet elvesztése azok számára, akik például VStudióval vagy más SDK-val dolgoznak, elfogadhatatlan. A nagyszámú vastag statikus VDI megszervezése minden fejlesztőcsapat számára nagymértékben megnövelte a meglévő VDI-megoldás költségeit.

Úgy döntöttünk, hogy a fejlesztési szegmens erőforrásaihoz való közvetlen hozzáférésen dolgozunk. Jira, Wiki, Gitlab, Nexus, építési és tesztpadok, virtuális infrastruktúra. A biztonsági őrök azt követelték, hogy a belépés csak az alábbiak szerint történjen:

1. A bankban már elérhető technológiák felhasználásával.
2. Az infrastruktúra nem használhat meglévő tartományvezérlőket, amelyek produktív fiókobjektumok rekordjait tárolják.
3. A hozzáférést csak azokra az erőforrásokra kell korlátozni, amelyeket egy adott csapat igényel (hogy az egyik termékcsapat ne férhessen hozzá egy másik csapat erőforrásaihoz).
4. Maximális vezérlés az RBAC felett a rendszerekben.

Ennek eredményeként külön domain jött létre ehhez a szegmenshez. Ez a tartomány tartalmazta az összes fejlesztési szegmens erőforrást, mind a felhasználói hitelesítő adatokat, mind az infrastruktúrát. A tartomány rekordjainak életciklusát a bankban meglévő IdM segítségével kezelik.

A közvetlen távoli elérést a bank meglévő eszközei alapján szerveztük meg. A hozzáférés-szabályozást AD csoportokra osztották, amelyekhez a kontextusokra vonatkozó szabályok feleltek meg (egy termékcsoport = egy szabálycsoport).

VM-sablonkezelés

Az összeállítási és tesztelési hurok létrehozásának sebessége az egyik fő KPI, amelyet a fejlesztő egység vezetője állított be, mivel a környezet előkészítésének sebessége közvetlenül befolyásolja a folyamat teljes végrehajtási idejét. A virtuális gép alapképeinek elkészítésére két lehetőséget vettek figyelembe. Az első a minimális képméretek, az összes rendszertermék alapértelmezése, a banki szabályzatoknak való maximális megfelelés a beállításokkal kapcsolatban. A második az alapkép, amely egy nagy teherbírású POPPO-t tartalmaz telepítve, melynek telepítési ideje nagyban befolyásolhatja a csővezeték végrehajtási sebességét.

A fejlesztés során figyelembe vették az infrastrukturális és biztonsági követelményeket is - képek naprakészen tartása (patch stb.), SIEM-mel való integráció, banki szabványok szerinti biztonsági beállítások.

Ennek eredményeként úgy döntöttek, hogy minimális képeket használnak, hogy minimalizálják a naprakészen tartás költségeit. Sokkal egyszerűbb frissíteni az alap operációs rendszert, mint az egyes képeket javítani a POPPO új verzióihoz.

Az eredmények alapján összeállítottunk egy listát a minimálisan szükséges operációs rendszerekről, amelyek frissítését az operatív csapat végzi, és a folyamatban lévő szkriptek teljes mértékben felelősek a szoftver frissítéséért, és szükség esetén a verzió módosításáért. a telepített szoftverről – csak vigye át a szükséges címkét a csővezetékre. Igen, ehhez bonyolultabb telepítési forgatókönyvekkel kell rendelkeznie a devops termékcsapatnak, de nagymértékben lecsökkenti az alapképfájlok támogatásához szükséges működési időt, amelynek karbantartása egyébként száznál is több alapképfájlt igényelne.

Internet hozzáférés

A banki biztonság másik akadálya az internetes forrásokhoz való hozzáférés volt a fejlesztői környezetből. Ezenkívül ez a hozzáférés két kategóriába sorolható:

1. Infrastruktúra hozzáférés.
2. Fejlesztői hozzáférés.

Az infrastruktúra-hozzáférést külső adattárak proxyjával szervezték meg a Nexusszal. Vagyis nem biztosítottak közvetlen hozzáférést a virtuális gépekről. Ez lehetővé tette az információbiztonsággal kapcsolatos kompromisszumot, amely kategorikusan ellenezte, hogy a fejlesztési szegmensből bármiféle hozzáférést biztosítsanak a külvilághoz.

A fejlesztőknek nyilvánvaló okokból (stackoverflow) volt szükségük az internet-hozzáférésre. És bár a fent említettek szerint minden parancs távoli hozzáféréssel rendelkezik az áramkörhöz, ez nem mindig kényelmes, ha nem tudja végrehajtani a ctrl+v billentyűkombinációt a fejlesztő munkahelyéről az IDE bankjában.

Megállapodás született az IS-vel, hogy kezdetben, a tesztelési szakaszban a hozzáférést egy banki proxyn keresztül biztosítják, fehérlista alapján. A projekt befejeztével a hozzáférés átkerül a feketelistára. Hatalmas hozzáférési táblák készültek, amelyek feltüntették azokat a fő erőforrásokat és adattárakat, amelyekhez a projekt indulásakor hozzáférésre volt szükség. Ezeknek a hozzáféréseknek a koordinálása meglehetősen sok időt vett igénybe, ami lehetővé tette, hogy ragaszkodjanak a feketelistákra való lehető leggyorsabb átálláshoz.

Álláspontja

A projekt valamivel kevesebb, mint egy éve ért véget. Furcsa módon minden vállalkozó időben átállt az új veremre, és senki sem távozott az új automatizálás miatt. Az IB nem siet a pozitív visszajelzésekkel, de nem is panaszkodik, amiből azt a következtetést vonhatjuk le, hogy tetszik nekik. A konfliktusok elcsitultak, mert az információbiztonságot ismét uralni lehet, de nem zavarja a fejlesztési folyamatokat. A csapatok nagyobb felelősséget kaptak, és az információbiztonsághoz való általános hozzáállás is jobb lett. A bank megértette, hogy a DevSecOps-ra való átállás szinte elkerülhetetlen, és ezt véleményem szerint a legszelídebb és legkorrektebb módon tette.

Alexander Shubin, rendszerépítész.

Forrás: will.com