En IT-afdeling kan have bygget noget selv. Et script, der opretter nye brugere. En lille webside, hvor servicedesken kan nulstille adgangskoder. En automatisering, der flytter filer hver nat, eller et dashboard over licenser og maskiner. Værktøjerne sparer tid og løser reelle problemer, men de er ikke nødvendigvis bygget med samme omhu som de systemer, IT køber. Svaret på, om de skal med i en penetrationstest, er ja, når de har adgang til noget vigtigt. Og det kan de have, for de er bygget til at gøre administratorarbejde.
Hvorfor egne værktøjer bliver et testområde
Et internt værktøj arver de rettigheder, det kører med. Et script, der opretter brugere, har rettigheder til at oprette brugere. En webside til nulstilling af adgangskoder har en konto bag sig, der kan nulstille adgangskoder. Hvis nogen kan misbruge værktøjet, får de de samme rettigheder, uden at skulle have en administratorkonto.
Samtidig kan værktøjerne mangle det, købte systemer har: en leverandør, der retter fejl, en dokumentation, en ejer i organisationen og en plads i opdateringsplanen. De blev bygget af en medarbejder til et formål og har kørt siden. Når medarbejderen skifter job, ved ingen, hvordan de virker. Hos en MSP er billedet det samme, blot ganget op: værktøjer, der er bygget til én kunde, bliver genbrugt hos de næste, måske med samme konti og samme svagheder.
Det britiske NCSC anbefaler i sin vejledning om sikker udvikling, at alle, der udvikler software, også internt, tænker sikkerhed ind fra starten, holder koden enkel og planlægger for, at der vil være fejl. Vejledningen er skrevet til udviklingsteams, men principperne passer lige så godt til en driftsafdeling, der bygger sine egne værktøjer.
Det, testen afprøver
En test, der omfatter interne værktøjer, afprøver typisk:
- Hvem der kan nå værktøjet · om websiden kan nås af alle på det interne net eller kun af dem, der skal bruge den.
- Login og roller · om værktøjet kræver login, og om en almindelig bruger kan gøre det, kun servicedesken skal kunne.
- Rettighederne bag værktøjet · hvilken konto værktøjet kører med, og om den har flere rettigheder end nødvendigt. → Tjenestekonti
- Hemmeligheder · om adgangskoder og nøgler står i koden, i konfigurationsfiler eller i planlagte opgaver. → Adgangskoder i scripts og konfigurationsfiler
- Hvor koden ligger · om scripts og kode ligger i delte mapper, hvor andre kan læse eller ændre dem.
- Logning · om det kan ses bagefter, hvem der brugte værktøjet til hvad.
Punktet om, hvor koden ligger, er vigtigere, end det ser ud. Et script, der kører med høje rettigheder, men ligger et sted, hvor mange kan skrive, er i praksis en åben dør til de rettigheder.
Det, IT forbereder
Interne værktøjer kommer kun med i testen, hvis nogen husker at nævne dem. Lav derfor en liste før testen:
- Hvilke værktøjer findes · scripts, websider, automatiseringer og dashboards, som IT selv har bygget eller tilpasset.
- Hvad gør de · med hvilke rettigheder og mod hvilke systemer.
- Hvor kører de · på hvilken server, under hvilken konto og med hvilken tidsplan.
- Hvem ejer dem · hvem der har bygget dem, og hvem der vedligeholder dem i dag.
- Hvem bruger dem · hvilke grupper af medarbejdere der skal kunne nå dem.
Listen er også nyttig uden testen. Den kan vise, at nogle værktøjer ikke længere bruges, og at andre kører på en konto, der burde have været lukket. → Netværkstegning og systemoversigt
Typiske fund
- Websider uden login · fordi de kun var tænkt til internt brug.
- Konti med domæneadministratorrettigheder · fordi det var den hurtigste måde at få værktøjet til at virke.
- Adgangskoder i klartekst · i scripts, der ligger på et drev, mange kan læse.
- Ingen adskillelse af roller · alle, der kan åbne værktøjet, kan bruge alle funktioner.
- Glemte værktøjer · scripts og sider, der kører, men ingen bruger eller kender.
- Forældede komponenter · biblioteker og platforme, som værktøjet blev bygget på, og som aldrig er opdateret. → Forældede komponenter og biblioteker
Rettelser på begrebsniveau
Værktøjerne skal ikke nødvendigvis erstattes. De skal behandles som systemer:
- En ejer pr. værktøj · der svarer for det og ved, hvordan det virker.
- Egen konto med smalle rettigheder · så værktøjet kun kan det, det skal. → Mindst mulig adgang i praksis
- Hemmeligheder ud af koden · i en central opbevaring, der er bygget til det.
- Login og roller · også på interne websider.
- Koden et beskyttet sted · hvor kun dem, der vedligeholder værktøjet, kan ændre den, og hvor ændringer kan følges. → Kodeopbevaring og byggeservere
- Med i opdateringsplanen · på lige fod med andre systemer.
- Luk det, der ikke bruges · et værktøj, ingen bruger, er kun en risiko.
Prioritér værktøjer med administratorrettigheder og værktøjer, der kan nås af mange. Et script, der kører med høje rettigheder fra en mappe, mange kan skrive i, kommer først.
Når et lille værktøj er blevet stort
Nogle værktøjer vokser. Et script til én afdeling bliver brugt af hele virksomheden, og en lille webside bliver den måde, lederne godkender adgang på. Så er værktøjet ikke længere et hjælpemiddel for driften, men et forretningssystem, og det skal behandles sådan.
Tegnene er tydelige: mange brugere, adgang til persondata eller økonomi, eller at arbejdet stopper, hvis værktøjet går ned. Når tegnene er der, bør IT tage stilling til, om værktøjet skal have en egentlig udviklingsproces med test før ændringer, eller om det skal erstattes af en købt løsning. En penetrationstest kan være anledningen til at stille spørgsmålet, men beslutningen om at investere kan ligge hos ledelsen. → IT-afdelingen og ledelsens beslutning
Det skal I lade være med
- At glemme egne værktøjer, når testen afgrænses. De kan have de bredeste rettigheder.
- At give værktøjet administratorrettigheder for at få det til at virke. Find de rettigheder, det faktisk skal bruge.
- At lade et værktøj leve videre uden ejer. Når den, der byggede det, stopper, skal en anden overtage.
- At gemme adgangskoder i scripts. De bliver læst af flere, end I tror.
- At undlade login, fordi det kun er internt. Det interne net er ikke et lukket rum.
Hvad kan og ikke kan konkluderes
Testen viser, hvordan de værktøjer, der var med i afgrænsningen, holdt på testtidspunktet, og hvad testeren kunne opnå gennem dem. Den kan ikke finde værktøjer, ingen nævnte, og som ikke var synlige fra testerens udgangspunkt. Den er heller ikke en gennemgang af koden, medmindre det er aftalt.
Tjekliste til egne værktøjer
- ☐ Er alle egne værktøjer registreret med formål, server og konto?
- ☐ Har hvert værktøj en ejer?
- ☐ Kører værktøjerne med smalle rettigheder?
- ☐ Er adgangskoder og nøgler fjernet fra koden?
- ☐ Kræver interne websider login?
- ☐ Kan kun de ansvarlige ændre koden?
- ☐ Er værktøjer, ingen bruger, lukket?
Kilder
- NCSC: Secure development and deployment guidance: det britiske NCSC’s principper for sikker udvikling, herunder at sikkerhed er alles opgave, at koden holdes enkel, at kodeopbevaringen beskyttes, og at der planlægges for fejl.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Driftsværktøjer med bred adgang · Tjenestekonti
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
