Jak zabezpečit firemní vývojové prostředí

Loňský bezpečnostní problém SolarWinds a letošní Codecow ukázaly, že mnohá bezpečnostní narušení vznikají v rámci dodavatelských řetězců poskytovatelů softwaru. S tím firma v roli koncového uživatele může těžko přímo něco dělat. Co ale v její moci naproti tomu je, to je její vlastní software a vnitropodnikový vývoj. Vývojové nebo testovací prostředí bývá přitom kompromitováno poměrně často. Pro útočníky se jedná o oblíbený cíl, který jim dává možnost provádět celou řadu dalších akcí na různých úrovních. Výsledkem může být např. krádež přístupových údajů a šifrovacích klíčů, hesel i samotného softwaru. Dále se pak nabízí možnost software modifikovat např. ve fázi finálního sestavování, a zasáhnout tak nejenom samotnou firmu, ale i jeho další uživatele prostřednictvím backdoorů. Obecně to, že útočníci takto mohou získávat informace, jak kritické aplikace přesně fungují, jim dává možnost přesněji cílit další útoky.

Jai Vijayan na DarkReading nabízí následující tipy pro zabezpečení vývojového prostředí (respektive systémů CD/CI, DevOps apod.). K jeho doporučením patří:

Inventarizace všech prostředků používaných ve vývojovém prostředí (systémy a zařízení používané jak pro samotný vývoj, tak i pro ukládání dat a řízení přístupu k prostředí). V podkategorii zařízení to znamená počítače, servery, mobilní zařízení, a to včetně systémů používaných ke vzdálenému přístupu, virtuálních a cloudových prostředí. K „aktivům“, tj. využívaným prostředkům, patří samozřejmě i software, kromě zabezpečení aplikací a operačních systémů je třeba do bezpečnostních mechanismů zahrnout také řízení přístupu a protokolů, zabezpečení e-mailu a zavedený systém reakcí na bezpečnostní incidenty.

Nasazení silného ověřování, např. vícefaktorové autentifikace. Mělo by se to týkat zejména práce se samotným kódem, jeho stahování a modifikace. Vývojářům, kteří přejdou na jiné projekty, je třeba oprávnění odebírat.

Posílit řízení změn. Předpokládejme, že některé účty jsou stejně kompromitovány. Změny v kódu by měly vyžadovat schvalování více osobami. Řízení změn, správa oprávnění a audit by se měly týkat jak samotného vývojového prostředí, tak i procesů testování a zajištění kvality, dále i systémů pro další distribuci softwaru. (V kódu SolarWinds byla například pouze přidána zadní vrátka, nešlo o žádný sofistikovaný exploit, ale jednoduše vložený kód, který by při revizi kódu měl být jednoduše odhalitelný.)

K repozitářům kódu by měl být zaveden přístup s nulovou důvěrou. Podniky stále častěji ukládají kód ve veřejných a soukromých cloudech. To je jeden z důvodů, proč je GitHub v posledních letech poměrně oblíbeným cílem útočníků. Metody ochrany, které organizace mohly nasadit k zabezpečení svého lokálního vývojového prostředí, jako jsou firewally, sítě VPN a segmentace sítě, obvykle nestačí k ochraně přístupu k úložištím kódu v cloudu, zvlášť v režimu všudypřítomné práce na dálku. Vhodnou odpovědí je právě princip nulové důvěry pro přístup k libovolnému úložišti kódu, ať už požadavek přichází odkudkoliv.

Finální verze (master copy) libovolného produktu by měla být zálohována na fyzicky odděleném úložném systému. U všech aplikací, spustitelných souborů, kontejnerů a snímků, které budou odeslány do „výroby“ finální verze, je třeba používat nástroje pro správu integrity souborů. Procesy správy změn by měly zahrnovat kontrolu dále distribuované verze softwaru oproti fyzicky zabezpečenému snímku. To je jeden ze způsobů, jak odhalit změny, které útočník mohl skrytě začlenit do kódu těsně před jeho vlastní distribucí.

Monitoring vývojového prostředí z hlediska neobvyklých aktivit (připojování k podezřelým webům, nečekané činnosti u účtů s vysokými oprávněními apod.).

Ochrana dat používaných pro testování. Tato data mohou často obsahovat citlivé informace převzaté přímo z produkčního prostředí. Ačkoli osvědčené postupy vyžadují, aby taková data byla při exportu z vlastního prostředí náležitě ošetřena, běžně obsahují informace umožňující identifikaci osob nebo údaje o účtech a transakcích, které by mohly mít pro útočníky velkou cenu. Je třeba využívat anonymizaci, filtraci a šifrování a především neustále testovací data z hlediska jejich formátu, kontrolovat metadata atd.