Penetrationtest

Skoler og uddannelser: penetrationstest med mange brugere og elevdata

Skoler og uddannelser: penetrationstest med mange brugere og elevdata

En skole har mange brugere med meget forskellige roller og ofte oplysninger om børn og unge. En penetrationstest på en skole eller uddannelsesinstitution skal derfor bygges op om de roller, der findes, og om de systemer, hvor elevernes oplysninger ligger, og testen skal planlægges, så rigtige elevdata ikke bliver en del af den.

Hvad der skal testes, afhænger af, hvem der driver hvad. Mange skoler bruger platforme, som andre udvikler og driver, mens nettet på skolen og enkelte lokale løsninger er skolens eget ansvar. Den fordeling bestemmer, hvad skolen selv kan bestille.

Mange roller i de samme systemer

På en skole bruger elever, lærere, forældre, administration og ledelse ofte de samme systemer, men med forskellige rettigheder. En elev skal kunne se sine egne opgaver og karakterer, men ikke andres. En forælder skal kunne se sit eget barn. En lærer skal kunne se sine klasser. Administrationen har adgang til mere.

Det er netop den adskillelse, en penetrationstest kan belyse. Spørgsmålet kan være, om en bruger med elevrolle kan nå oplysninger, som kun lærere eller administration skal se, eller om en forælder kan se andre børns oplysninger. Testen kræver konti i hver af de relevante roller. → Testkonti og testdata

Rollerne skifter desuden hvert skoleår. Elever rykker op eller går ud, lærere skifter klasser, og vikarer får adgang i en kortere periode. Det giver et særligt spørgsmål: Har en bruger stadig adgang til en klasse eller en elev, når tilknytningen er ophørt? En test kan belyse, hvordan rollerne virkede på testtidspunktet, men rutinerne for at ændre og fjerne adgang er skolens egen opgave og bør gennemgås for sig.

Mange skoler bruger fælles login, hvor én konto giver adgang til flere platforme. Det gør login til et centralt punkt, og det skal afklares, om login-løsningen er med i testen, eller om den hører til en anden part. → Fælles login (single sign-on) i testen

Platforme, som andre driver

Læringsplatforme, elevadministration og kommunikation med forældre er ofte leveret af eksterne leverandører, der driver dem for mange skoler. Så kan skolen ikke alene give tilladelse til en test. Leverandøren skal spørges, og ofte giver det mere mening at efterspørge leverandørens egen testdokumentation. → Leverandørens godkendelse mangler

Det, skolen selv råder over, kan være opsætningen af platformene: hvem der er tildelt hvilke roller, hvordan deling er sat op, og hvilke integrationer skolen selv har koblet på. Delte mapper med elevopgaver, karakterark eller elevplaner er eksempler på steder, hvor en forkert opsætning kan give for bred adgang. → Fildeling og samarbejdsværktøjer

Er skolen en del af en større organisation med fælles IT, skal det afklares, hvem der kan bestille testen, og hvem der skal give tilladelse. En lokal skoleleder kan ikke nødvendigvis beslutte en test af systemer, som en central IT-funktion driver.

Elevnettet og det administrative net

En skole kan have flere net: et til elever og deres egne enheder, et til lærere, et til administration og måske et gæstenet til besøgende. Elevernes enheder er ikke styret af skolen på samme måde som skolens egne computere, og de kan være mange.

Et relevant spørgsmål til en test er, om adskillelsen mellem elevnettet og det administrative net holder, så en enhed på elevnettet ikke kan nå administrationens systemer. Det er et spørgsmål om planen og om, hvorvidt virkeligheden svarer til den. → Trådløse net og gæstenet

Printere, projektorer, skærme og adgangskontrol kan også stå på skolens net. De er ofte leveret af andre og hører med i overvejelsen, når nettet beskrives. En oversigt over, hvilke enheder der står på hvilket net, og hvem der vedligeholder dem, gør det lettere at afgrænse testen og at fordele eventuelle fund bagefter.

Elevdata skal ikke bruges i testen

Oplysninger om elever er personoplysninger, og for børn og unge er der særlig grund til forsigtighed. Datatilsynet har vejledning på området. Planlæg testen med testkonti og opdigtede elever frem for rigtige oplysninger, hvor det er muligt.

Er det ikke muligt at undgå rigtige data, skal det aftales med testeren, hvordan oplysninger behandles under testen, hvad der må stå i rapporten, og hvordan testdata slettes bagefter. Rapporten bør kun indeholde det, der er nødvendigt for at dokumentere et fund. Teksten er ikke juridisk rådgivning.

Skolen skal også tænke over, hvem der skal kende til testen. Lærere og administration, der oplever noget usædvanligt, skal vide, hvem de kontakter. Elever og forældre behøver normalt ikke inddrages, men det er skolens beslutning.

Tidspunktet i skoleåret

En skole har perioder, hvor systemerne er særligt vigtige: eksaminer, terminsprøver, karaktergivning og skolestart. En test, der forstyrrer i de perioder, kan få betydning for eleverne. Ferier kan være et godt tidspunkt, men så skal leverandører og IT-ansvarlige også kunne træffes. → Hvornår på året skal testen ligge?

Planlæg også, hvornår fundene kan rettes. En test lige før skolestart giver kort tid til rettelser, før alle brugere er tilbage. Aftal også, hvem der modtager rapporten. Skolelederen skal kunne forstå konsekvenserne, mens den IT-ansvarlige eller leverandøren skal bruge de tekniske detaljer til at rette.

Det skal I lade være med

  • At teste en platform, som andre driver, uden tilladelse · leverandøren skal spørges.
  • At bruge rigtige elevdata, når testdata kan bruges · opdigtede elever er at foretrække.
  • At glemme forældrerollen · forældre har adgang og skal med, hvis rollerne testes.
  • At overse elevernes egne enheder · de står på skolens net uden skolens styring.
  • At teste midt i eksamensperioden · en forstyrrelse rammer eleverne direkte.
  • At lade rapporten ligge i en delt mappe · den beskriver svagheder og skal holdes i en lille kreds.

Hvad kan og ikke kan konkluderes

En test kan vise, om de roller, der indgik, var adskilt som tiltænkt, og om nettene på skolen holdt adskillelsen under de aftalte forhold. Den siger ikke noget om platforme, der ikke var med, og den er ikke en vurdering af leverandørernes samlede sikkerhed.

Hvis testen ikke afdækker alvorlige forhold, er det et resultat for de roller og net, der indgik. Elevernes oplysninger i andre systemer er dermed ikke vurderet, og nye platforme eller ændrede roller kræver en ny stillingtagen.

Tjekliste for skolen

  • ☐ Er det afklaret, hvem der kan bestille, og hvem der skal give tilladelse?
  • ☐ Er de roller, der skal testes, beskrevet, også forældrerollen?
  • ☐ Er det klart, hvilke platforme skolen selv råder over?
  • ☐ Er nettene på skolen og deres formål beskrevet?
  • ☐ Bruges testkonti og opdigtede elever i stedet for rigtige data?
  • ☐ Ligger testen uden for eksamens- og karakterperioder?
  • ☐ Er der tid til rettelser, før alle brugere er tilbage?

Kilder

  • Datatilsynet: vejledning om behandling og sikkerhed af personoplysninger.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Typer af penetrationstest · Spørgsmål og svar · Vikar- og rekrutteringsbureauer

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have testet noget?

Fortæl kort, hvad I vil have testet, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.