Sikker dataimport: flyt Excel, CSV og gamle systemdata ind i appen

Behandl importen som en kontrolleret udgivelse

En dataimport ændrer appens virkelighed på én gang. Fejl i kode kan ofte rettes med et nyt deploy, men fejl i kunder, priser, lager, bookinger eller relationer kan leve videre og påvirke rigtige beslutninger. Derfor skal importen have ejer, testdata, stopkriterier, afstemning og en aftalt vej tilbage.

Skeln mellem skemaændring og flytning af data

En skemamigrering ændrer databasens struktur, for eksempel en ny kolonne eller en constraint. En dataimport opretter eller ændrer virksomhedens konkrete poster. De to kan hænge sammen, men de bør have hver sin kontrol: en vellykket skemamigrering beviser ikke, at navne, beløb og relationer er blevet mappet korrekt.

• Beskriv målmodellen: Hvilke tabeller eller collections modtager data, og hvilke regler gælder allerede i appen?
• Lav en feltmapping: Skriv kildefelt, målfelt, type, om feltet er påkrævet, og hvilken omformning der sker.
• Beslut tomme værdier: En tom celle, en tom tekst og en manglende værdi er ikke nødvendigvis det samme. PostgreSQL beskriver eksempelvis særskilt håndtering af tom tekst og NULL i CSV.
• Bevar kildereferencen: Gem en stabil kilde-id eller en særskilt mapping, så hver ny post kan spores tilbage og genkøres uden gætteri.

Valider filen, før den når appens data

Excel-, CSV- og leverandørudtræk er ubetroet input, også når filen kommer fra en medarbejder. OWASP anbefaler både syntaktisk validering af format og semantisk validering af betydningen. En dato kan være korrekt skrevet og stadig ligge før startdatoen; et beløb kan være et tal og stadig bruge forkert valuta.

1. 1. Kontrollér filen: Tilladte kolonner, kodning, separator, størrelse og ét dokumenteret dato- og talformat.
2. 2. Pars uden at skrive: Vis antal gyldige og afviste rækker samt konkrete fejl med række og felt.
3. 3. Læg data i et mellemområde: Brug en importtabel, en midlertidig collection eller et isoleret miljø, hvor data ikke vises for brugerne.
4. 4. Valider forretningsregler: Find manglende nøgler, ukendte kunder, brudte relationer, umulige datoer og værdier uden for de aftalte rammer.
5. 5. Kræv godkendelse: En navngiven dataejer skal kunne læse fejlrapporten og godkende det endelige importgrundlag.

Gør importen sikker at genkøre

Netværksfejl, timeouts og afbrudte jobs sker. Importen skal derfor kunne fortsætte eller genkøres uden at oprette den samme kunde eller ordre igen. Brug et import-id, stabile kildenøgler og en entydig regel for, om en eksisterende post skal afvises, opdateres eller stå urørt.

Opret kun

Afvis en række, hvis kildenøglen allerede findes. Passer til en engangsimport, hvor eksisterende poster aldrig må overskrives.

Opret eller opdatér

Definér præcist hvilke felter importen ejer. Ellers kan den overskrive nyere ændringer, som en bruger har lavet i appen.

Spring over

Registrér at rækken blev genkendt og ikke ændret. En stille skip uden rapport kan skjule et problem.

Afvis

Gem en forståelig fejl uden at kopiere unødvendige persondata til logs. Fejlen skal kunne rettes og prøves igen.

Brug transaktioner eller afgrænsede batches med omtanke

Poster, der kun giver mening samlet, bør også skrives samlet. PostgreSQL-transaktioner kan gøre flere trin til en alt-eller-intet-operation. Firestore tilbyder transaktioner og atomiske batch-skrivninger, men har en anden model og andre grænser. Følg derfor dokumentationen for den database og det kodebibliotek, appen faktisk bruger.

• Indsæt forældre før børn, eller brug en dokumenteret strategi for midlertidige nøgler og relationer.
• Gruppér kun de skriverier, der forretningsmæssigt skal lykkes eller fejle sammen.
• Del store importer i afgrænsede batches, og gem checkpoint og resultat pr. batch.
• Stop ved uventet fejlrate, tabte relationer eller afstemningsafvigelser i stedet for at fortsætte til en ukendt sluttilstand.
• Kontrollér platformens timeout-, batch-, transaktions- og omkostningsgrænser i den aktuelle plan før produktionskørslen.

Bevis resultatet med afstemning

At jobstatus står som gennemført betyder kun, at koden nåede slutningen. En import er accepteret, når kildens og appens data stemmer efter aftalte kontroller, og en forretningskyndig person har godkendt stikprøverne.

• Antal: Modtaget, godkendt, oprettet, opdateret, sprunget over og afvist skal kunne forklares.
• Summer: Afstem relevante beløb, antal varer, timer, saldi eller andre kontroltotaler.
• Relationer: Find poster uden gyldig kunde, ordre, projekt, ejer eller anden påkrævet reference.
• Stikprøver: Kontrollér normale poster, grænsetilfælde og kendte vanskelige rækker i appens brugerflade.
• Brugerrejser: Åbn, søg, redigér, rapportér og eksportér importerede data som en rigtig bruger.

Planlæg rollback før importen til produktion

Rollback kan være at slette poster fra et bestemt import-id, gendanne en database, køre en kompenserende ændring eller nulstille et isoleret målmiljø. Valget afhænger af appens stack og af, om brugerne allerede har ændret de importerede data. En gammel backup må ikke overskrive nye, korrekte ændringer uden en konkret plan.

• Tag en platformskorrekt backup eller eksport, og afprøv at den kan læses eller gendannes.
• Gem import-id og kildenøgle på de oprettede poster eller i en særskilt, beskyttet mapping.
• Beslut et cutover-tidspunkt, og gør det gamle system skrivebeskyttet, hvis to aktive sandheder ellers kan opstå.
• Aftal hvem der må starte, stoppe, godkende og rulle importen tilbage.
• Definér tidsrum og konkrete stopkriterier, mens relevante personer stadig kan reagere.

Firestores administrerede eksport er eksempelvis ikke et præcist snapshot fra starttidspunktet, og en import kan overskrive dokumenter med samme id uden at fjerne upåvirkede dokumenter. Det illustrerer, hvorfor backupens og importens faktiske semantik skal kontrolleres i leverandørens aktuelle dokumentation.

Beskyt persondata i midlertidige filer og miljøer

En eksportfil kan samle flere personoplysninger end den almindelige appskærm viser. Datatilsynet fremhæver dataminimering, passende sikkerhed og beskyttelse gennem design. Importarbejdet skal derfor have samme eller stærkere adgangskontrol end produktionen, ikke en fælles mappe eller privat indbakke som genvej.

• Eksportér kun de felter, der er nødvendige for den aftalte migration.
• Brug en godkendt, adgangsbegrænset overførsel og lagring frem for almindelig e-mail.
• Hold rigtige persondata ude af udvikleres lokale mapper, kode-repository og almindelige testmiljøer, medmindre det er nødvendigt og kontrolleret.
• Log række-id og fejlkode frem for hele navne, adresser, beskeder eller dokumentindhold.
• Slet eller arkivér kildefiler, mellemdata og fejludtræk efter den aftalte frist, og dokumentér hvem der gjorde det.

Typiske fejl

• CSV-filen skrives direkte i produktion: Fejl opdages først efter, at delvise data er synlige for brugerne.
• Navn eller e-mail bruges som eneste nøgle: Stavning, navneskift og delte adresser skaber dubletter eller forkerte matches.
• Tomme felter får en tilfældig standard: Manglende viden bliver til en tilsyneladende sikker, men forkert værdi.
• Genkørsel opretter alt igen: Jobbet mangler import-id, stabil kildenøgle og entydighedsregel.
• Alle rækker ligger i én stor operation: Timeout eller én dårlig række gør status og genstart unødigt svær.
• Kun rækkeantal afstemmes: Beløb, relationer eller den konkrete fordeling kan stadig være forkert.
• Backup kaldes automatisk rollback: Ingen har vurderet nye data, importen har påvirket, eller testet gendannelsen.
• Kundefilen bliver liggende: Midlertidige kopier ender i downloads, mail, logs og gamle testmiljøer uden slettefrist.

Tjekliste før en rigtig dataimport

• ☐ Kilde, udtræksdato, dataejer og endeligt importgrundlag er entydigt navngivet.
• ☐ Feltmapping beskriver typer, formater, tomme værdier, standarder og omformninger.
• ☐ Hver posttype har en stabil kildenøgle og en besluttet regel for eksisterende data.
• ☐ Fil og rækker valideres både teknisk og mod appens forretningsregler før skrivning.
• ☐ En testkørsel viser oprettede, opdaterede, ignorerede og afviste rækker uden at ændre produktion.
• ☐ Mellemdata er isoleret, adgangsbegrænset og usynlig for almindelige brugere.
• ☐ Importen kan genkøres eller fortsættes uden dubletter og med forståelige checkpoints.
• ☐ Sammenhængende skriverier bruger databaseplatformens dokumenterede transaktions- eller batchmodel.
• ☐ Stopkriterier, batchstørrelse, timeout og forventede platformomkostninger er vurderet.
• ☐ Antal, summer, relationer, stikprøver og kritiske brugerrejser har aftalte acceptkriterier.
• ☐ Backup, rollback, cutover, skrivepause og ansvar er afprøvet eller gennemgået.
• ☐ Persondata i filer, mellemområder, logs og fejlrapporter er minimeret og har en slettefrist.
• ☐ Resultatrapport og endelig godkendelse gemmes sammen med importens kode og dokumentation.

Relaterede guides

Officielle kilder

Importfunktioner, transaktioner, grænser og omkostninger afhænger af database og plan. Guiden er kontrolleret mod aktuelle sikkerheds- og leverandørkilder; kontrollér altid den konkrete platforms dokumentation og jeres egen konfiguration før en produktionsimport.

• OWASP: Input Validation Cheat Sheet
• PostgreSQL: COPY og CSV-format
• PostgreSQL: Transactions
• Firebase: Transactions and batched writes
• Firebase: Export and import data
• Datatilsynet: Behandlingssikkerhed og databeskyttelse gennem design