Når en udvikler stopper, er det ikke nok at spærre den almindelige brugerkonto. Udviklere har typisk adgang til kodearkiver, byggesystemer, cloudkonti og en række tokens og nøgler, som ikke forsvinder med adgangskoden. Det vigtigste er at lukke adgangene i den rigtige rækkefølge og gemme organisationens logs, før de udløber. Ellers kan I hverken se, hvad der er sket, eller dokumentere det senere.
Artiklen er skrevet til CTO’en, IT-ansvarlige og ledere i virksomheder, hvor kode, scripts eller konfigurationer er en vigtig del af forretningen. Den gælder både ved en almindelig fratrædelse og ved en fratrædelse i konflikt.
Hvorfor udviklere er et særligt tilfælde
En almindelig medarbejder har som regel én konto i Microsoft 365 eller Google Workspace. En udvikler har ofte mange identiteter:
- en personlig konto hos GitHub, GitLab eller Bitbucket, som er medlem af virksomhedens organisation,
- personlige adgangstokens og SSH-nøgler, der virker uden login,
- nøgler til cloudplatforme, databaser og tredjepartstjenester,
- adgang til byggeservere, pakkeregistre og overvågning,
- lokale kopier af alle kodearkiver på egen computer.
Den personlige konto hos kodeplatformen er ofte medarbejderens egen og fortsætter med at eksistere efter fratrædelsen. Det er medlemskabet af organisationen, der er virksomhedens. Den forskel er vigtig, både når I lukker adgangen, og hvis der senere opstår uenighed om, hvad der er taget med.
Hvad gør I nu?
- Gem organisationens auditlog først. De fleste kodeplatforme har en auditlog for organisationen, der viser medlemskaber, kloninger, ændringer af rettigheder og oprettelse af tokens, afhængigt af abonnement. Eksportér den, før I fjerner medlemmet. Tjek, hvor længe jeres abonnement gemmer loggen.
- Lav en liste over adgange. Gå igennem organisationens medlemmer, deploy-nøgler, tokens, apps og cloudkonti. Notér, hvad udvikleren havde adgang til.
- Fjern medlemskabet af organisationen. Fjern ikke data i arkiverne, og slet ikke grene, som udvikleren har arbejdet på.
- Tilbagekald nøgler og tokens. Rotér hemmeligheder, som udvikleren har kendt: API-nøgler, databaseadgange, servicekonti. Notér tidspunktet for hver.
- Sikr udviklerens computer. Den bærbare indeholder lokale kopier, historik i terminalen og ofte nøgler. Den skal ikke geninstalleres, før det er besluttet, om den skal sikres.
- Tjek forks og private kopier. Undersøg, om der findes forks af virksomhedens private arkiver uden for organisationen, og notér det. Rør dem ikke.
Skriv ned, hvornår hvert skridt blev taget. Skiftes en nøgle, før loggen er gemt, kan det blive svært at skelne jeres egne handlinger fra den tidligere medarbejders.
Overlevering uden at ødelægge sporene
Udvikleren skal typisk overlevere viden i opsigelsesperioden: dokumentation, åbne opgaver, adgang til systemer, som kun vedkommende kender. Det er fornuftigt, men det kan også give anledning til ændringer, der senere er svære at forklare. Store oprydninger i arkiverne, sletning af gamle grene og omskrivning af historik er eksempler på handlinger, der kan være helt legitime, men som også kan fjerne spor.
Bed derfor om, at overleveringen sker som almindeligt arbejde: nye ændringer oven på de eksisterende, ikke omskrivning af det, der allerede ligger. Aftal, at grene ikke slettes i perioden, og at historikken ikke omskrives. Det er en rimelig arbejdsinstruks, og den beskytter både virksomheden og udvikleren, hvis der senere opstår tvivl.
Notér også, hvilke systemer kun udvikleren kender adgangen til. Det kan være en gammel server, en domæneudbyder eller en betalingstjeneste. Få adgangene overdraget til en virksomhedskonto, og skriv ned, hvornår det skete. Ved en fratrædelse i konflikt er den liste ofte det første, advokaten spørger efter.
Overvej endelig, om udviklerens computer skal sikres som rutine, selv om der ikke er mistanke. Hos nøglepersoner kan det være billigere end at stå uden spor, hvis mistanken opstår et halvt år senere.
Hvem gør hvad?
- CTO eller teamleder · Lister adgange og afgør, hvad der er forretningskritisk
- IT · Eksporterer logs, fjerner medlemskab og roterer nøgler
- HR · Tjekker kontrakt, klausuler og aftaler om kode
- Leder · Beslutter, om der er grundlag for mistanke, og inddrager advokat
Er den, der skal lukke adgangene, en tæt kollega til udvikleren, så overvej, om en anden skal gøre det. Det handler ikke om mistillid, men om at kunne vise, at det skete sagligt.
Det må I ikke gøre
- Slette udviklerens grene eller arkiver. De viser, hvad der er arbejdet på og hvornår. Når de er væk, er historikken svær at genskabe.
- Skrive direkte til udvikleren om sletning. Bed ikke om, at private kopier slettes, før I har talt med en advokat. En sletning kan fjerne netop det, der viser, hvad der er taget.
- Undersøge udviklerens private GitHub-profil indefra. Det, der er offentligt, kan dokumenteres. Private dele er medarbejderens egne.
- Lade en kollega overtage computeren. Så forsvinder de lokale spor under nyt arbejde.
- Glemme sessioner. En tilbagekaldt adgangskode lukker ikke nødvendigvis en aktiv session eller et token.
→ Sessioner og tokens efter skift af adgangskode
Når der er mistanke om, at koden er taget med
Det er normalt, at en udvikler har kode på sin computer. Det er en del af jobbet. Mistanken opstår typisk, når en konkurrent pludselig har en funktion, der minder meget om jeres, når der er klonet mange arkiver kort før fratrædelsen, eller når udvikleren har arbejdet på et arkiv uden for organisationen.
I den situation er det endnu vigtigere at stoppe og sikre, før nogen konfronterer udvikleren. Auditloggen, computeren og eventuelle backupper skal sikres af en, der kan dokumentere metoden. Sammenligning af kode er et specialistområde, og det er ikke en opgave for jeres egne udviklere, der kan blive vidner i sagen.
→ En udvikler har taget kildekoden med
Hvornår skal I have hjælp udefra?
Kontakt en IT-sagkyndig, hvis udvikleren stopper i konflikt, hvis I ser usædvanlig aktivitet i loggen før fratrædelsen, eller hvis I overvejer en sag om forretningshemmeligheder eller ophavsret til koden. Sig tydeligt, hvis loggen er ved at udløbe. Hastesager koster ekstra. → Pris og tilbud
Er der ingen mistanke, kan I klare offboardingen selv. Brug den alligevel som anledning til at tjekke, at loggen er slået til og gemmes længe nok.
Forebyg det næste gang
- ☐ Kræv, at medlemmer af organisationen bruger to-faktor-login.
- ☐ Brug korte levetider på tokens, og hold styr på, hvem der har oprettet dem.
- ☐ Hold hemmeligheder i en central boks, ikke i kode eller private noter.
- ☐ Skriv i ansættelseskontrakten, hvem der ejer kode, og hvad der må ligge på private konti.
- ☐ Gør udviklere til en egen sektion i jeres offboarding-tjekliste.
En løbende dokumentation af, hvem der har udviklet hvad, gør det også lettere at vise, at koden er jeres, hvis det bliver nødvendigt.
→ Dokumentér jeres egen udvikling løbende
Læs også: Firmaets sociale medier og Meta Business: administratoren er stoppet · Konsulenter og freelancere: adgang og data ved ophør
→ Medarbejderen har taget data: hjælp til virksomheden · Haster det? Akut hjælp · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
