Nooit eerder hebben organisaties meer informatie verwerkt - of waren ze meer bezorgd over hoe deze in verkeerde handen zou kunnen vallen. Deze zorg geldt voor alle gegevens, maar vooral voor de broncode waarop ze vertrouwen om hun processen draaiende te houden.
Zowel bedrijven als particulieren vertrouwen op platforms zoals GitHub, GitLab en BitBucket om hun broncode op te slaan en te beheren en hun ontwikkelingsprojecten draaiende te houden. Deze platforms zijn razend populair: GitHub heeft meer dan 73 miljoen ontwikkelaars en 200 miljoen repositories, GitLab schattingen 30 miljoen geregistreerde gebruikers en BitBucket gerapporteerd 10 miljoen gebruikers in 2019.
Als beveiligingsteams zich geen zorgen maken over de broncode die op deze platforms is opgeslagen, zouden ze dat wel moeten zijn, omdat de kans groot is dat hun ontwikkelaars op zijn minst een paar projecten hebben die ze daar houden. Sommige aanvallen van de afgelopen jaren hebben de dreiging duidelijk gemaakt: een ransomware-aanval in 2019 veegde Git-broncode-opslagplaatsen op verschillende platforms en verving ze door een eis om losgeld. Er is ook het risico van downtime, zoals het geval was toen GitHub was neer voor minimaal twee uur in juni 2020.
De kosten van het verliezen van broncode zijn hoog, zegt John Bambenek, principal threat hunter bij Netenrich.
"Van alles wat van cruciaal belang is voor een organisatie, moet een back-up worden gemaakt", zegt hij. “Een goede vuistregel is: 'Kan het bedrijf zonder dit voortbestaan?' en als het antwoord nee is, moet er een back-upplan zijn.”
Er zijn veel redenen waarom een bedrijf er misschien niet aan denkt om een back-up van hun broncode te maken. Het kan deels zijn dat ze geld willen besparen en deels onkwetsbaar zijn voor aanvallen die hun broncode in gevaar brengen. Er is ook de realiteit dat back-ups geld kosten zonder enig tastbaar voordeel - totdat ze nodig zijn, merkt Mark Loveless op, senior beveiligingsingenieur bij GitLab.
"Voor het grootste deel doe je gewoon iets waar je geen onmiddellijke winst ziet", zegt hij. “Zo zijn back-ups. U ziet geen onmiddellijke winst en u wilt nooit een onmiddellijke winst op back-ups zien, omdat u hoopt dat alles goed komt en u er nooit een beroep op hoeft te doen. Maar daar heb je een plan voor nodig.”
Bewustwording is een ander probleem. Sommige mensen maken misschien geen back-up van hun broncode omdat ze denken dat dat niet nodig is, voegt hij eraan toe. GitLab, GitHub en BitBucket hebben, net als de grote cloudproviders, een "gedeeld verantwoordelijkheidsmodel" waarin gebruikers en providers van de service de verantwoordelijkheid delen voor het beschermen van hun informatie.
GitLab maakt "vrijwel constant" back-ups op zijn eigen servers, zegt Loveless, maar veel mensen hebben hun eigen exemplaar van GitLab op hun eigen private cloudruimte of op een fysieke server in hun datacenter. In deze gevallen moeten gebruikers nadenken over de cloudprovider die ze gebruiken, wat voor soort back-ups ze bewaren en hoe ver terug ze hun gegevens willen back-uppen.
"Git ... aangezien het een geschiedenis van code-check-ins opslaat en je kunt terugdraaien naar een eerdere versie van code, hebben [gebruikers] de neiging om te denken dat er een back-up is", zegt Loveless. "Er is, voor zover revisies en uw codewijzigingen ... maar die worden opgeslagen in een database [en] gegevensbestanden, en daar moet een back-up van worden gemaakt."
Een werkkopie van de repository op elke computer moet niet als een back-up worden beschouwd, aangezien deze doorgaans alleen de broncode bevat en niet de problemen, opmerkingen, pull-verzoeken en andere metadata die ermee verband houden. Het is gebruikelijk om te denken dat een Git-repository of ander versiebeheer voldoende is, voegt Taylor Gulley, senior applicatiebeveiligingsadviseur bij nVisium, toe. Versiebeheer, hoewel erg handig, heeft uw code nog steeds alleen op één centrale locatie opgeslagen.
"Tenzij je noodherstelplan is om de code van de lokale computer van een ontwikkelaar te halen - ervan uitgaande dat er een zijn die het incident overleven waarbij de server werd uitgeschakeld - zijn goede back-ups van cruciaal belang", zegt Gulley.
Wat bedrijven moeten weten over het proces
Back-ups voor broncode kunnen meerdere vormen aannemen. Organisaties kunnen ervoor kiezen om hun eigen back-ups te beheren en eigenaar te worden van de bijbehorende infrastructuur, processen en reparatiekosten. Hoewel dit hen meer controle over hun gegevens geeft, kan het op de lange termijn meer kosten vanwege de middelen die aan onderhoud worden besteed.
Handmatige back-ups brengen ook technische uitdagingen met zich mee. Het is moeilijk om alle activa consistent te houden om ze herstelbaar te maken naar elke Git-repository, omdat elke leverancier zijn eigen API, proces, opmerkingen en problemen heeft. De API-verzoeksnelheidslimieten vormen een ander obstakel: Git-back-up wordt meestal geassocieerd met het verzenden van veel verzoeken naar de API van de Git-provider, en ze moeten het aantal verzoeken dat in een beperkte periode wordt verzonden, beperken.
Als alternatief kunnen ze kijken naar een derde partij die het back-upbeheer afhandelt. In veel gevallen zijn er clouddiensten die hierbij kunnen helpen, merkt Bambenek op. Organisaties kunnen zich wenden tot een service zoals GitProtect.io, een tool die is ontworpen om een back-up te maken van code op GitHub, GitLab en BitBucket.
"De behoefte werd gevonden binnen ons eigen bedrijf", zegt GitProtect productontwikkelingsmanager Greg Bak over de creatie van het product. “We hadden interne scripts om die repositories te beschermen, maar niemand kon garanderen dat we die repositories altijd kunnen herstellen … dat ze goed worden beschermd, dat onze back-ups worden getest. Dus hebben we besloten om het te [bouwen].”
GitProtect is beschikbaar in twee modellen: back-up-as-a-service en on-premises, zodat organisaties het lokaal kunnen installeren of in de public cloud kunnen implementeren. Het doel van het product is niet alleen de broncode te beschermen, maar ook alle gerelateerde metadata die nodig zijn om een repository consistent te houden, zoals opmerkingen, problemen en CI/CD-taken, zegt Bak.
Er zijn een aantal bedreigingen die de broncode kunnen compromitteren, naast aanvallen gericht op opslagplaatsen en mogelijke verstoring van deze platforms. Menselijke fouten en ongewenste wijzigingen in de code zelf kunnen back-ups vereisen om processen weer aan de gang te krijgen, voegt hij eraan toe.
Best practices voor back-ups
Ongeacht hoe je besluit een back-up van je broncode te maken, GitLab's Loveless adviseert om een beveiligingsexpert in de kamer te brengen.
"Investeer in een aantal beveiligingsmensen", zegt hij. “Als je daar mensen kunt hebben, ervaren mensen die weten hoe ze dit moeten doen, investeer dan in mensen en je zou veel betere resultaten moeten behalen.”
Experts adviseren ook om back-ups op een veilige plaats en versleuteld te bewaren. Als u een multicloud-omgeving gebruikt, kunt u back-ups off-site of off-systeem roteren. Gulley raadt aan om een paar exemplaren op locatie te bewaren en één op een andere locatie, voor het geval de locatie in gevaar komt. Eerdere back-ups mogen niet worden gewijzigd of verwijderd door de geautomatiseerde back-upprocessen of -accounts.
Alle experts zijn het erover eens dat het maken van back-ups van de broncode niet voldoende is. Het is ook belangrijk om ze te testen en ervoor te zorgen dat ze werken. Als ze dat niet doen, wil je niet weten wanneer je ze nodig hebt. Test het proces van toegang tot en gebruik van de back-ups om er zeker van te zijn dat u ze kunt gebruiken en dat alle betrokkenen hun rol begrijpen in het geval van een aanval, storing of compromittering.
