Banka zadává své projekty mnoha dodavatelům. „Externí“ zapíší kód a poté přenesou výsledky v nepříliš vhodné formě. Konkrétně proces vypadal takto: předali projekt, který s nimi prošel funkčními testy, a poté byl testován uvnitř bankovního perimetru na integraci, zatížení a tak dále. Často se zjistilo, že testy selhávají. Poté se vše vrátilo k externímu vývojáři. Jak můžete hádat, znamenalo to dlouhé dodací lhůty pro opravy chyb.
Banka rozhodla, že je možné a nutné přetáhnout pod svá křídla celé potrubí, od závazků až po uvolnění. Aby vše bylo jednotné a pod kontrolou týmů odpovědných za produkt v bance. Tedy jako kdyby externí dodavatel prostě pracoval někde ve vedlejší místnosti kanceláře. Na firemním zásobníku. Tohle je obyčejný devops.
Kde se vzal Sec? Zabezpečení banky kladlo vysoké nároky na to, jak může externí dodavatel pracovat v segmentu sítě, jaký má kdo přístup, jak a kdo pracuje s kódem. Jen IB ještě nevěděla, že když dodavatelé pracují venku, je dodržováno málo bankovních standardů. A pak je za pár dní musí začít všichni pozorovat.
Prosté odhalení, že dodavatel má plný přístup ke kódu produktu, už obrátilo jejich svět vzhůru nohama.
V tuto chvíli začal příběh DevSecOps, o kterém vám chci vyprávět.
Jaké praktické závěry z této situace banka vyvodila?
Hodně se polemizovalo o tom, že se všechno dělá špatně. Vývojáři řekli, že bezpečnost je zaneprázdněna pouze snahou zasahovat do vývoje a oni, jako strážci, se bez přemýšlení snaží zakázat. Bezpečnostní specialisté zase váhali mezi výběrem mezi úhly pohledu: „vývojáři vytvářejí zranitelnost v našem okruhu“ a „vývojáři nevytvářejí zranitelnosti, ale jsou jimi sami“. Spor by pokračoval ještě dlouho, nebýt nových požadavků trhu a vzniku paradigmatu DevSecOps. Bylo možné vysvětlit, že právě tato automatizace procesů zohledňující požadavky na bezpečnost informací „z krabice“ pomůže všem zůstat spokojeni. V tom smyslu, že pravidla jsou zapsána okamžitě a během hry se nemění (informační bezpečnost nezakáže něco nečekaně) a vývojáři informují informační bezpečnost o všem, co se děje (informační bezpečnost nenarazí na něco náhle) . Každý tým je také zodpovědný za maximální bezpečnost, a ne někteří abstraktní starší bratři.
- Vzhledem k tomu, že externí zaměstnanci již mají přístup ke kódu a řadě interních systémů, je pravděpodobně možné z dokumentů odstranit požadavek „vývoj musí být prováděn výhradně na infrastruktuře banky“.
- Na druhou stranu musíme posílit kontrolu nad tím, co se děje.
- Kompromisem bylo vytvoření mezifunkčních týmů, kde zaměstnanci úzce spolupracují s externími lidmi. V takovém případě se musíte ujistit, že tým pracuje na nástrojích na serverech banky. Od začátku do konce.
To znamená, že dodavatelé mohou být povoleni, ale musí jim být přiděleny samostatné segmenty. Aby do infrastruktury banky nezanesli nějakou infekci zvenčí a neviděli víc, než je nutné. No, aby se jejich akce zaznamenávaly. DLP pro ochranu proti úniku, to vše bylo zahrnuto.
V zásadě na to dříve nebo později přijdou všechny banky. Zde jsme se vydali vyšlapanou cestou a dohodli se na požadavcích na taková prostředí, kde „externí“ pracují. Objevila se maximální škála nástrojů pro kontrolu přístupu, nástrojů pro kontrolu zranitelnosti, antivirové analýzy na obvodech, sestavách a testech. Toto se nazývá DevSecOps.
Najednou bylo jasné, že pokud před DevSecOps bankovní zabezpečení nemělo žádnou kontrolu nad tím, co se děje na straně vývojáře, pak v novém paradigmatu je zabezpečení řízeno stejným způsobem jako běžné události v infrastruktuře. Teprve teď jsou upozornění na sestavení, ovládání knihoven a tak dále.
Zbývá jen převést týmy do nového modelu. No, vytvořte infrastrukturu. Ale to jsou maličkosti, je to jako kreslit sovu. Vlastně jsme pomohli s infrastrukturou a v té době se vývojové procesy měnily.
Co se změnilo
Rozhodli jsme se to implementovat po malých krůčcích, protože jsme pochopili, že mnoho procesů se rozpadne a mnoho „externích“ by nemuselo nové pracovní podmínky pod dohledem všech vydržet.
Nejprve jsme vytvořili mezifunkční týmy a naučili se organizovat projekty s ohledem na nové požadavky. Ve smyslu organizačně jsme diskutovali jaké procesy. Výsledkem bylo schéma montážního potrubí se všemi zodpovědnými.
- IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
- CD: Ansible, Puppet, TeamCity, Gitlab TFS, Liquidbase.
- Test: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Ataccama.
- představení (hlášení, komunikace): Grafana, Kibana, Jira, Confluence, RocketChat.
- operace (údržba, správa): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.
Vybraný zásobník:
- Knowledge Base - Atlassian Confluence;
- Task tracker - Atlassian Jira;
- Úložiště artefaktů - „Nexus“;
- Systém kontinuální integrace - „Gitlab CI“;
- Systém kontinuální analýzy - „SonarQube“;
- Systém analýzy zabezpečení aplikací - „Micro Focus Fortify“;
- Komunikační systém - „GitLab Mattermost“;
- Systém řízení konfigurace - „Ansible“;
- Monitorovací systém - „ELK“, „TICK Stack“ („InfluxData“).
Začali vytvářet tým, který by byl připraven vtáhnout dodavatele dovnitř. Je zřejmé, že existuje několik důležitých věcí:
- Vše by mělo být sjednoceno, alespoň při přenosu kódu. Protože jak mnoho dodavatelů bylo, existovalo tolik různých vývojových procesů s vlastními zvláštnostmi. Bylo nutné všechny vměstnat přibližně do jedné, ale s možnostmi.
- Existuje mnoho dodavatelů a ruční vytváření infrastruktury není vhodné. Jakákoli nová úloha by měla začít velmi rychle – to znamená, že instance by měla být nasazena téměř okamžitě, takže vývojáři mají sadu řešení pro správu jejich potrubí.
Abychom udělali první krok, bylo nutné pochopit, co se dělá. A museli jsme určit, jak se tam dostat. Začali jsme tím, že jsme pomohli nakreslit architekturu cílového řešení jak v infrastruktuře, tak v automatizaci CI/CD. Poté jsme začali s montáží tohoto dopravníku. Potřebovali jsme jednu infrastrukturu, stejnou pro všechny, kde by jezdily stejné dopravníky. Nabídli jsme možnosti s kalkulacemi, pomyslela si banka, a pak se rozhodli, co se bude stavět as jakými prostředky.
Dále je vytvoření obvodu – instalace softwaru, konfigurace. Vývoj skriptů pro nasazení a správu infrastruktury. Následuje přechod na podporu dopravníku.
Rozhodli jsme se vše vyzkoušet na pilotu. Zajímavé je, že během pilotování se v banku poprvé objevil jistý stack. V rámci pilotního projektu byl mimo jiné nabídnut tuzemský prodejce jednoho z řešení pro rychlé spuštění. Bezpečnost ho poznala, když pilotoval, a zanechalo to nezapomenutelný dojem. Když jsme se rozhodli přejít, naštěstí byla infrastrukturní vrstva nahrazena řešením Nutanix, které bylo v bance již dříve. Navíc předtím to bylo pro VDI, ale znovu jsme to použili pro infrastrukturní služby. V malých objemech se nevešel do ekonomiky, ale ve velkých objemech se stal vynikajícím prostředím pro vývoj a testování.
Zbytek zásobníku je víceméně známý všem. Byly použity automatizační nástroje v Ansible a úzce s nimi spolupracovali bezpečnostní specialisté. Před projektem banka používala zásobník Atlassin. Bezpečnostní nástroje Fortinet – navrhli to samotní bezpečnostní lidé. Testovací rámec vytvořila banka, žádné dotazy. Systém úložiště vyvolával otázky, musel jsem si na to zvyknout.
Dodavatelé dostali nový zásobník. Dali nám čas na přepsání pro GitlabCI a na migraci Jiry do bankovního segmentu a tak dále.
krok za krokem
Krok 1. Nejprve jsme použili řešení od tuzemského dodavatele, produkt byl napojen na nově vytvořený segment sítě PDS. Platforma byla zvolena pro svou dodací lhůtu, flexibilitu škálování a možnost plné automatizace. Provedené testy:
- Možnost flexibilní a plně automatizované správy infrastruktury virtualizační platformy (síť, diskový subsystém, subsystém výpočetních zdrojů).
- Automatizace správy životního cyklu virtuálních strojů (šablony, snímky, zálohy).
Po instalaci a základní konfiguraci platformy byla použita jako místo pro umístění subsystémů druhé etapy (nástroje DSO, osnovy rozvoje maloobchodních systémů). Byly vytvořeny potřebné sady pipeline - vytváření, mazání, modifikace, zálohování virtuálních strojů. Tyto kanály byly použity jako první fáze procesu nasazení.
Výsledkem je, že poskytované zařízení nesplňuje požadavky banky na výkon a odolnost proti poruchám. DIT banky se rozhodlo vytvořit komplex založený na softwarovém balíku Nutanix.
Krok 2. Vzali jsme zásobník, který byl definován, a napsali jsme automatizované instalační a postkonfigurační skripty pro všechny subsystémy, aby se vše přeneslo z pilotního do cílového okruhu co nejrychleji. Všechny systémy byly nasazeny v konfiguraci odolné proti chybám (kde tato schopnost není omezena licenčními zásadami dodavatele) a připojeny k subsystémům pro metriky a sběr událostí. IB analyzovala dodržování svých požadavků a dala zelenou.
Krok 3. Migrace všech subsystémů a jejich nastavení na nový PAC. Byly přepsány skripty pro automatizaci infrastruktury a migrace subsystémů DSO byla dokončena v plně automatizovaném režimu. Kontury vývoje IP byly znovu vytvořeny pomocí potrubí vývojových týmů.
Krok 4. Automatizace instalace aplikačního softwaru. Tyto úkoly stanovili vedoucí nových týmů.
Krok 5. Vykořisťování.
Vzdálený přístup
Vývojové týmy požadovaly maximální flexibilitu při práci s obvodem a požadavek na vzdálený přístup z osobních notebooků byl vznesen již na začátku projektu. Banka už měla vzdálený přístup, ale ten nebyl vhodný pro vývojáře. Faktem je, že schéma využívalo připojení uživatele k chráněnému VDI. To bylo vhodné pro ty, kteří na svém pracovišti potřebovali pouze poštu a kancelářský balík. Vývojáři by potřebovali těžké klienty, vysoký výkon, se spoustou zdrojů. A samozřejmě musely být statické, protože ztráta uživatelské relace pro ty, kteří pracují s VStudio (například) nebo jiným SDK, je nepřijatelná. Organizace velkého počtu tlustých statických VDI pro všechny vývojové týmy značně zvýšila náklady na stávající řešení VDI.
Rozhodli jsme se zapracovat na vzdáleném přístupu přímo ke zdrojům vývojového segmentu. Jira, Wiki, Gitlab, Nexus, sestavení a testování lavic, virtuální infrastruktura. Bezpečnostní strážci požadovali, aby byl přístup umožněn pouze za následujících podmínek:
- Využití technologií již dostupných v bance.
- Infrastruktura by neměla používat existující řadiče domény, které ukládají záznamy o objektech produktivních účtů.
- Přístup by měl být omezen pouze na zdroje požadované konkrétním týmem (takže jeden produktový tým nemůže získat přístup ke zdrojům jiného týmu).
- Maximální kontrola nad RBAC v systémech.
V důsledku toho byla pro tento segment vytvořena samostatná doména. Tato doména obsahovala všechny prostředky vývojového segmentu, a to jak uživatelské pověření, tak infrastrukturu. Životní cyklus záznamů v této doméně je spravován pomocí stávajícího IdM banky.
Přímý vzdálený přístup byl organizován na základě stávajícího vybavení banky. Řízení přístupu bylo rozděleno do AD skupin, kterým odpovídala pravidla o kontextech (jedna produktová skupina = jedna skupina pravidel).
Správa šablon VM
Rychlost tvorby montážní a testovací smyčky je jedním z hlavních KPI nastavených vedoucím vývojové jednotky, protože rychlost přípravy prostředí přímo ovlivňuje celkovou dobu provádění pipeline. Byly zvažovány dvě možnosti přípravy základních obrazů virtuálních počítačů. Prvním z nich jsou minimální velikosti obrázků, výchozí pro všechny systémové produkty, maximální soulad s pravidly banky ohledně nastavení. Druhým je základní obraz, který obsahuje nainstalované vysoce výkonné POPPO, jehož doba instalace by mohla výrazně ovlivnit rychlost provádění pipeline.
Při vývoji byly zohledněny i požadavky na infrastrukturu a zabezpečení – udržování aktuálního obrazu (záplaty atd.), integrace se SIEM, nastavení zabezpečení dle bankovních standardů.
V důsledku toho bylo rozhodnuto používat minimální obrázky, aby se minimalizovaly náklady na jejich aktualizaci. Je mnohem snazší aktualizovat základní OS než opravovat každý obrázek pro nové verze POPPO.
Na základě výsledků byl vytvořen seznam minimální požadované sady operačních systémů, jejichž aktualizaci provádí operační tým, a skripty z kanálu jsou plně odpovědné za aktualizaci softwaru a v případě potřeby za změnu verze nainstalovaného softwaru - stačí přenést požadovaný tag do potrubí. Ano, to vyžaduje, aby produktový tým devops měl složitější scénáře nasazení, ale výrazně to zkracuje provozní dobu potřebnou k podpoře základních bitových kopií, které by jinak mohly vyžadovat údržbu více než stovky základních bitových kopií virtuálních počítačů.
Přístup k internetu
Dalším kamenem úrazu bankovní bezpečnosti byl přístup k internetovým zdrojům z vývojového prostředí. Navíc lze tento přístup rozdělit do dvou kategorií:
- Přístup k infrastruktuře.
- Přístup pro vývojáře.
Přístup k infrastruktuře byl organizován prostřednictvím proxy externích úložišť pomocí zařízení Nexus. To znamená, že přímý přístup z virtuálních strojů nebyl poskytnut. To umožnilo dosáhnout kompromisu s informační bezpečností, která byla kategoricky proti poskytování jakéhokoli přístupu do vnějšího světa z vývojového segmentu.
Vývojáři potřebovali přístup k internetu ze zřejmých důvodů (stackoverflow). A ačkoli všechny příkazy, jak je uvedeno výše, měly vzdálený přístup k okruhu, není to vždy vhodné, když nemůžete provést ctrl+v z vývojářského pracoviště v bance v IDE.
S IS bylo dosaženo dohody, že zpočátku, ve fázi testování, bude přístup poskytován prostřednictvím bankovního proxy na základě bílé listiny. Po dokončení projektu bude přístup převeden na černou listinu. Byly připraveny obrovské přístupové tabulky, které uváděly hlavní zdroje a úložiště, ke kterým byl na začátku projektu vyžadován přístup. Koordinace těchto přístupů zabrala poměrně dost času, což umožnilo trvat na co nejrychlejším přechodu na černé listiny.
výsledky
Projekt skončil o něco méně než před rokem. Kupodivu všichni dodavatelé přešli na nový zásobník včas a nikdo neodešel kvůli nové automatizaci. IB se sdílením pozitivních ohlasů nespěchá, ale ani si nestěžuje, z čehož můžeme usoudit, že se jim to líbí. Konflikty ustoupily, protože informační bezpečnost se opět cítí pod kontrolou, ale nezasahuje do vývojových procesů. Týmy dostaly větší odpovědnost a celkový přístup k informační bezpečnosti se zlepšil. Banka pochopila, že přechod na DevSecOps je téměř nevyhnutelný a udělala to dle mého názoru tím nejšetrnějším a nejsprávnějším způsobem.
Alexander Shubin, systémový architekt.
Zdroj: www.habr.com