Datasikkerhed og privatliv ved implementering af adgang til optjent løn

For at sikre datasikkerheden i forbindelse med adgang til optjent løn (earned wage access) skal virksomheder vide præcist, hvilke data der indsamles, hvad de bruges til, hvor de gemmes, hvem der har adgang, hvem de deles med, og hvornår de skal slettes. De centrale foranstaltninger omfatter dataminimering, rollebaseret adgangsstyring, stærk godkendelse, kryptering, nøgle- og hemmelighedsstyring, manipuleringssikre logfiler, uregelmæssighedsovervågning, sikkerhedskopiering, sikkerhedstest, leverandørstyring og beredskabsprocedurer. Sikkerhed er ikke en enkeltstående funktion, men et fælles ansvar gennem hele livscyklussen for adgang til optjent løn.

> Bemærk: Dette er en referenceramme for styring, teknik og drift. Bestemmelsen af specifikke juridiske forpligtelser afhænger af hver parts rolle, datatyper, formål med behandlingen, dataoverførselsstrømme og den faktiske implementeringsmodel. Virksomheder bør lade deres juridiske afdeling, informationssikkerhed og HR gennemgå dette i fællesskab før implementering.

> Terminologi: Adgang til optjent løn (earned wage access) · HRIS (HR-informationssystem) · ERP (virksomhedsresursestyring) · payroll (lønbehandling) · API (softwaregrænseflade) · SFTP (sikker filoverførsel) · token (dataerstatningskode) · MFA (multifaktor-godkendelse) · OTP (engangskode) · idempotency (transaktionsbeskyttelse mod dublering) · webhook/callback (automatiserede meddelelser mellem systemer) · log (logfil) · SOC (sikkerhedsovervågningscenter) · go-live (lancering i drift) · playbook (håndbog til hændelseshåndtering) · OWASP ASVS/MASVS (standarder for applikationssikkerhedstest) · backup (sikkerhedskopiering).

Hvorfor kræver data til adgang til optjent løn et højt beskyttelsesniveau?

Adgang til optjent løn — giver medarbejdere mulighed for at få adgang til en del af deres optjente løn før den almindelige lønningsdag. For at fastslå, om en person er berettiget og har et resterende beløb til rådighed, skal systemet typisk forbinde flere datadomæner:

• identitetsoplysninger og ansættelsesstatus;

• afdeling, stilling eller løngruppe;

• tidsregistreringsdata og godkendelsesstatus;

• lønniveau, lønperiode og visse justeringer;

• udbetalingskonto eller betalingsoplysninger;

• historik over anmodninger, beløb, tidspunkter og transaktionsresultater;

• enhedsdata, loginsessioner og logfiler til svindelforebyggelse.

Når disse data samles, kan de beskrive et ansættelsesforhold og en persons økonomiske adfærd relativt detaljeret. En hændelse kan ikke blot føre til lækage af oplysninger, men også til kontokapring, overførsel af penge til forkerte modtagere, fejlberegnede beløbsgrænser, afbrydelse af lønudbetalinger, tvister og faldende tillid blandt medarbejderne (se også risici ved implementering af adgang til optjent løn).

Derfor er det rigtige spørgsmål ikke blot "blive data krypteret?", men snarere: forhindrer hele processen uautoriseret adgang, datakorruption, falske transaktioner, dobbeltbetalinger og misbrug af data?

1. Udarbejd et datakort før valg af sikkerhedsløsning

En virksomhed kan ikke beskytte et aktiv, som den ikke ved eksisterer eller hvor det befinder sig. Det første skridt er at udarbejde et datakort for adgang til optjent løn fra det opstår, til det slettes.

For hver strøm bør profilen besvare:

1. Hvilke data overføres?

2. Hvilket formål tjener dataene?

3. Hvilket system er kilden til sandhed for dataene?

4. Hvilken part bestemmer formålet og metoden for behandlingen?

5. Hvilken part udfører behandlingen i henhold til aftalen?

6. Overføres data via API, fil eller manuel indtastning?

7. Hvor gemmes dataene, og hvor længe?

8. Hvem kan se, ændre, eksportere eller slette dem?

9. Overføres der data til underleverandører eller uden for det fastsatte omfang?

10. Hvad sker der, når medarbejderen fratræder, eller serviceaftalen ophører?

Eksempel på dataregister

Ovenstående skabelon er blot en designramme. Opbevaringsperioder og klassificeringsniveauer skal fastsættes af virksomheden på grundlag af juridiske grundlag, kontraktlige krav, afstemningsbehov og faktiske risikovurderinger.

2. Indsaml kun data, der er reelt nødvendige

Dataminimering reducerer både risici og beskyttelsesomkostninger. Hvis systemet kun behøver at vide, at en medarbejder er aktiv og tilhører en bestemt gruppe, er det ikke nødvendigt at kopiere hele HR-arkivet.

Virksomheder bør gennemgå hvert datafelt ud fra fire spørgsmål:

• Kan adgang til optjent løn udføre sin funktion korrekt uden dette felt?

• Kan fulde data erstattes af en referencekode, et token eller maskerede data?

• Er det nødvendigt at gemme dataene, eller skal de kun bruges under behandlingssessionen?

• Kan detaljeringsgraden reduceres, eller opbevaringstiden forkortes?

Tre almindelige teknikker

Maskering af data: Vis kun en del, f.eks. de sidste fire cifre på udbetalingskontoen.

Tokenisering: Erstat følsomme oplysninger med en referencekode; de fulde data findes kun i det ansvarlige behandlingsdomæne.

Dataseparation: Undlad at gemme identitetsfiler, kontoopplysninger og transaktionshistorik i den samme tabel eller med den samme adgangskode, medmindre det er nødvendigt.

Minimering betyder ikke mangel på kontrol-data. Systemet har stadig brug for tilstrækkelige transaktionskoder, kildeversioner, tidsstempler og logfiler til at forhindre dobbeltbetalinger og støtte afstemning.

3. Adskil roller og ansvar mellem parterne

Et program med adgang til optjent løn kan involvere arbejdsgiveren, leverandøren af adgang til optjent løn, infrastrukturenheden, tidsregistreringssystemet, lønsystemet, banken eller betalingspartneren. Hvis ansvaret er uklart, skubbes hændelser let frem og tilbage mellem parterne.

Ansvarsmatricen skal klart definere:

Denne matrice skal tilpasses den faktiske kontrakt. Det bør ikke betragtes som en overdragelse af alt ansvar for data og informationssikkerhed blot ved at "ansætte en leverandør".

4. Stærk godkendelse uden at genere medarbejderne

Kontoen for adgang til optjent løn er direkte knyttet til muligheden for at modtage penge og skal derfor beskyttes strengere end en konto, der kun bruges til at læse nyheder.

For medarbejderne

• identitetsverifikation ved aktivering af kontoen;

• anvendelse af godkendelsesmekanismer, der svarer til transaktionens risikoniveau;

• krav om forstærket verifikation ved enhedsskift, skift af udbetalingskonto eller ved usædvanlig adfærd;

• begrænsning af forsøgsantal og registrering af kodegætning;

• undladelse af at basere sig på let gættelige sikkerhedsspørgsmål;

• underretning ved nye logins, ændringer af vigtige oplysninger eller transaktioner;

• en sikker kontogendannelsesprocedure for at undgå, at supportpersonale egenmægtigt springer verifikationstrin over.

For administratorer og driften

• obligatorisk multifaktor-godkendelse;

• prioritering af centraliseret login og individuelle identitetskonti;

• forbud mod delte administratorkonti;

• begrænsning af logins efter enhed, netværk eller risikoforhold, når det er relevant;

• tidsbegrænsede rettigheder til særlige opgaver;

• fuld registrering af visning, ændring, eksport af data og konfigurationsændringer.

Adgangskoder, engangskoder (OTP) og godkendelsesoplysninger må ikke logføres. Supportmedarbejdere må heller ikke bede medarbejdere om at læse adgangskoder eller engangskoder op.

5. Rollebaseret adgangsstyring og princippet om mindste privilegium

Adgangsrettigheder skal være baseret opgaver, ikke blot på høj eller lav stilling.

Højrisikohandlinger bør anvende opdelte opgaver eller to-lags godkendelse, for eksempel:

• ændring af udbetalingskonto;

• oplåsning af konti med tegn på svindel;

• ændring af afsluttede transaktioner;

• masseeksport af data;

• ændring af grænserelaterede regler;

• tildeling af administratorrettigheder;

• sletning af logfiler eller transaktionsdata.

Rettigheder skal gennemgås regelmæssigt og tilbagekaldes med det samme, når medarbejdere skifter stilling, fratræder eller ikke længere har relaterede opgaver.

6. Datakryptering og nøglestyring

Kryptering skal anvendes til data under transmission og i hvile, men blot at "slå kryptering til" er ikke nok.

Virksomheder skal kontrollere:

• om forbindelser mellem applikationer, API, SFTP og administrationssystemer er krypterede;

• om databaser, sikkerhedskopier, filområder og logfiler er beskyttet;

• om krypteringsnøgler opbevares adskilt fra dataene;

• hvem der har ret til at bruge, rotere eller tilbagekalde nøgler;

• om der føres log over nøgleadgangsaktivitet;

• hvordan tab eller lækage af nøgler håndteres;

• om data eksporteret til CSV/Excel forbliver uden for beskyttede områder.

API-nøgler, systemadgangskoder og certifikater skal forvaltes i dedikerede hemmelighedslagre. Hemmeligheder må ikke placeres i kildekode, e-mails, vejledninger eller bredt delte konfigurationsfiler.

7. Beskyttelse af API og integrationsstrømme

API'er mellem tidsregistrering, løn, adgang til optjent løn og betaling er vejen for både data og forretningskommandoer (detaljeret under Integration af adgang til optjent løn med tidsregistrering, løn og ERP). De vigtigste kontroller omfatter:

• godkendelse af det kaldende system og rettighedsstyring efter funktion;

• kontrol af struktur, datatype og grænser for inputdata;

• frekvensbegrænsning og registrering af usædvanlig adfærd;

• API-versionering og kontrollerede ændringsprocedurer;

• signaturer eller verifikationsmekanismer for webhook/callback;

• forebyggelse af genafspilning af anmodninger ved hjælp af tid, nonce eller egnede nøgler;

• idempotency_key til transaktionsoprettelseskommandoer;

• correlation_id til sporing på tværs af systemer;

• lister over fejlkoder, der ikke afslører interne detaljer;

• kontrol af genforsøg (retry), især når pengeoverførslens resultat er ukendt.

Ved brug af batch-filer er det nødvendigt at styre separate SFTP-konti, kryptering af filer efter behov, checksum, partinummer, behandlingsrækkefølge, dublerede poster, delvise fejlfiler og tidsfrister for sletning af filer fra overførselsområdet.

OWASP Application Security Verification Standard kan bruges som ramme for opbygning og test af applikationssikkerhedskontroller. For mobile applikationer er OWASP MASVS en specialiseret reference for krav til godkendelse, lagring, netværk, kode og privatliv.

8. Logfiler skal være tilstrækkelige til undersøgelse uden at blive en kilde til lækage

Logfiler hjælper med at opdage svindel, håndtere klager og spore hændelser. Men logfiler, der indeholder for mange følsomme data, skaber blot en ekstra kopi, der er svær at kontrollere.

Bør registreres

• kontrollerede bruger- eller administratorkoder;

• handlinger og berørte objekter;

• standardiserede tidspunkter og tidszoner;

• adresser eller enhedstegn i henhold til politik;

• succes-/fejlresultater og årsagskoder;

• transactionid, correlationid og dataversioner;

• ændringer af rettigheder, konfiguration, grænser og udbetalingskonti;

• masseeksporthandlinger;

• begivenheder om kontolåsning eller opdagelse af uregelmæssigheder.

Bør ikke registreres fuldstændigt

• adgangskoder, engangskoder (OTP) og adgangsnøgler;

• fulde kontonumre eller identitetsdokumenter;

• indhold af anmodninger/svar, der indeholder fulde medarbejderprofiler;

• uaktiverede sessions-tokens;

• data, der ikke tjener overvågnings- eller undersøgelsesformål.

Vigtige logfiler skal beskyttes mod uautoriseret ændring eller sletning, tids synkroniseret, sendes til et centraliseret overvågningssystem og have scenariebaserede alarmer. OWASP understreger, at applikationslogning skal understøtte både sikkerheds- og driftsformål, men data i logfiler skal også beskyttes.

9. Håndtering af enheder, applikationer og loginsessioner

Medarbejdere kan bruge personlige telefoner, skifte SIM-kort eller skifte enhed. Derfor skal systemet balancere mellem sikkerhed og tilgængelighed.

Situationer, der bør have særlige regler:

• login fra en ny enhed;

• ændring af telefonnummer;

• enheder med root/jailbreak eller tegn på indgriben;

• usædvanligt mange konti, der bruger den samme enhed;

• samme konto logger ind fra flere steder på kort tid;

• anmodning om udbetaling umiddelbart efter ændring af betalingsoplysninger;

• langvarige loginsessioner eller genbrugte tokens.

Applikationen bør ikke gemme følsomme data i klar tekst i lokal hukommelse, udklipsholder, skærmbilleder eller låseskærmsmeddelelser. Loginsessioner skal have en tidsbegrænsning, mulighed for tilbagekaldelse og genverifikation før følsomme handlinger.

10. Svindelopdagelse med respekt for privatlivets fred

Svindelbekæmpelse kan kræve analyse af enheder, adfærd og transaktionsmønstre. Indsamlingen skal dog være knyttet til et klart formål, nødvendighed og en specifik opbevaringsperiode.

Visse forretningssignaler kan omfatte:

• ændring af udbetalingskonto efterfulgt af øjeblikkelig transaktion;

• gentagne mislykkede godkendelsesforsøg;

• gentagne anmodninger med lignende indhold;

• transaktioner, der overskrider grænserelaterede regler;

• unormalt ændrede arbejdstidsdata før en transaktion;

• en konto, der modtager manuel support for ofte;

• en administrator, der foretager mange følsomme ændringer uden for arbejdstiden.

Man bør ikke automatisk konkludere, at en person begår svindel ud fra et enkelt signal. Systemet har brug for en risikoscore, ekstra verifikationstrin, undtagelseshåndteringsmekanismer og mulighed for gennemgang af en autoriseret person. Enhver automatiseret model skal testes for at undgå fejlagtigt at blokere en gruppe medarbejdere på grund af forskellige enhedsdata, geografiske områder eller brugsforhold.

11. Sikkerhedskopiering, tilgængelighed og genoprettelsesevne

Sikkerhed omfatter også tilgængelighed og integritet. Et system, der ikke lækker data, men mister sin transaktionshistorik eller stopper med at fungere på selve lønningsdagen, har stadig store konsekvenser.

Virksomheder bør kræve:

• sikkerhedskopiering i henhold til vigtigheden af hver datatype;

• separat kryptering og adgangsstyring for sikkerhedskopier;

• adskilte sikkerhedskopier for at begrænse virkningen af ransomware;

• test af genoprettelsesevnen, ikke blot test af "vellykket backup";

• målsætninger for genoprettelsestid og datatab aftalt mellem parterne;

• redundansarkitektur for væsentlige komponenter;

• alternative driftsforhold, når adgang til optjent løn eller betalingskanalen afbrydes;

• bevarelse af transaktionsstatus med ukendt resultat efter systemgendannelse.

Tidsmål bør ikke markedsføres med tal uden måling og officielle tjenesteklausuler (SLA).

12. Leverandørstyring og forsyningskæde

Leverandøren af adgang til optjent løn kan fortsat bruge cloud-infrastruktur, OTP-tjenester, overvågning, identitetsverifikation eller betalingspartnere. Virksomheden skal vide, hvilke parter data passerer igennem, og hvad hver parts ansvar er.

Spørgsmål, der skal stilles før kontraktunderskrivelse

(Se også den fulde tjekliste i Tjekliste til valg af leverandør af adgang til optjent løn.)

1. Hvilke datagrupper behandler leverandøren præcist?

2. Hvor gemmes data og sikkerhedskopier?

3. Er der underleverandører, der har adgang til data?

4. Er der en ordning for forudgående meddelelse ved udskiftning af underleverandører?

5. Hvilken proces bruger leverandørens medarbejdere til at få adgang til data?

6. Er der kryptering, nøglestyring, multifaktor-godkendelse og miljøseparation?

7. Med hvilket omfang og i hvilke cyklusser udføres penetrationstests?

8. Hvordan klassificeres og afhjælpes sårbarheder?

9. Hvad er tidsfristen for hændelsesmeddelelse og det koordinerende kontaktpunkt?

10. Ved kontraktens ophør, hvordan returneres eller slettes data og kopier?

11. Hvilke beviser dokumenterer, at sletningen er fuldført?

12. Hvordan er virksomhedens ret til inspektion, revision eller modtagelse af uafhængige rapporter?

Certificeringer er et nyttigt signal, men erstatter ikke kontrol af det korrekte omfang. Virksomheder skal undersøge, hvilke systemer, placeringer og perioder certificeringen dækker, og om den inkluderer den platform for adgang til optjent løn, der rent faktisk bruges.

13. Sikkerhedstest før og efter go-live

En enkelt test før lancering er ikke tilstrækkelig for hele produktets livscyklus (knyttet til 90-dages pilotplan for adgang til optjent løn). Et passende program kan omfatte:

• gennemgang af arkitektur og trusselsmodel;

• kontrol af kildekode og afhængige biblioteker;

• sårbarhedsscanning af applikationer, servere og konfigurationer;

• test af API, web og mobile applikationer;

• rollebaserede adgangstests;

• test af kontogendannelsesprocesser;

• test mod gentagne transaktioner og falske callbacks;

• uafhængige penetrationstests før go-live og efter større ændringer;

• hændelses- og genoprettelsesøvelser;

• opfølgning på afhjælpning, indtil der er bevis for, at fejl er lukket.

Testresultater skal klart skelne mellem kritiske fejl, midlertidigt acceptable fejl og resterende risici godkendt af en ansvarlig person. Systemet bør ikke tages i drift blot fordi "der ikke blev fundet nogen kritiske fejl", hvis testomfanget ikke omfattede betalingsstrømme og reel integration.

14. Beredskabsprocedure for datasikkerhedshændelser ved adgang til optjent løn

Når der opdages tegn på uregelmæssigheder, er det første mål at begrænse skaden uden at miste beviser.

Playbooken bør definere:

• hvad en hændelse er, og dens sværhedsgrad;

• hvem der har ret til at låse konti, stoppe API'er eller midlertidigt standse udbetalinger;

• hvordan logfiler, systemskærmbilleder og transaktionsbeviser bevares;

• hvordan berørte data, brugere og tidsrammer identificeres;

• juridiske kontaktpunkter, HR, kommunikation, sikkerhed og leverandører;

• grundlag, indhold og tidspunkt for underretning af kompetente myndigheder eller berørte personer;

• kriterier for genåbning af tjenesten;

• støtteplan for medarbejdere i tilfælde af forkerte transaktioner;

• rapport om årsag til problemet og foranstaltninger til forebyggelse af gentagelse.

Juridiske underretningsfrister skal fastsættes af det juridiske team i overensstemmelse med hændelsestypen og hver parts specifikke rolle, og der bør ikke anvendes et generelt tal for alle situationer.

15. Datalivscyklus: Fra oprettelse til sikker sletning

Hver datagruppe kræver sin egen opbevaringsplan. "Opbevaring for evigt i tilfælde af behov for opslag" øger normalt risikoen uden at tilføje værdi.

Politikken skal dække:

• data i brug i hovedsystemet;

• sikkerhedskopier;

• overførselsfiler;

• data eksporteret til brugeres maskiner;

• applikations- og sikkerhedslogfiler;

• testdata;

• data hos underleverandører;

• support-tickets og vedhæftede filer;

• data om fratrådte medarbejdere;

• data efter servicekontraktens ophør.

Sikker sletning kræver en sletningskommando, udførelseslog, håndtering af kopier og bevis for fuldførelse. I visse tilfælde skal data opbevares på grund af juridiske forpligtelser, tvistbilæggelse eller revisionskrav; i sådanne tilfælde skal adgangen begrænses, og anvendelsesformålet begrænses.

16. Relevante juridiske rammer

Ud over generelle regler skal virksomheder, afhængigt af forretningsstrømme, overholde gældende lovgivning om elektroniske transaktioner, ikkekontante betalinger og andre relevante sektorspecifikke forskrifter.

Overholdelse bør ikke forstås enkelt som at tilføje et "Jeg accepterer"-felt. Virksomheder skal fastslå parternes korrekte roller, formål og grundlag for behandling, oplysninger, der gives til medarbejdere, delingsomfang, beskyttelse af registreredes rettigheder, nødvendige vurderingsdokumenter, beskyttelsesforanstaltninger og hændelseshåndteringsprocedurer. Specifikke juridiske konklusioner skal baseres på datadiagrammet og den faktiske implementeringskontrakt.

17. Tjekliste for sikkerhed før godkendelse af implementering af adgang til optjent løn

Styring og jura

• [ ] Der er en ejer af programmet for adgang til optjent løn og et kontaktpunkt for informationssikkerhed.

• [ ] Der er et datakort og en liste over systemer/leverandører, der modtager data.

• [ ] Parternes roller, formål og behandlingsansvar er fastlagt.

• [ ] Meddelelser, vilkår og mekanismer til udøvelse af medarbejderrettigheder er gennemgået.

• [ ] Der er opbevaringsperioder og sletningsprocedurer for hver datagruppe.

• [ ] Kontrakten fastsætter regler for hændelser, underleverandører, kontrol og tjenestens ophør.

Identitet og rettigheder

• [ ] Medarbejdere verificeres ved aktivering og ved ændring af følsomme oplysninger.

• [ ] Administratorer skal bruge multifaktor-godkendelse (MFA) og individuelle konti.

• [ ] Rettigheder tildeles efter rolle, organisatorisk omfang og opgaver.

• [ ] Højrisikohandlinger har to-lags godkendelse eller opdeling af opgaver.

• [ ] Rettigheder gennemgås regelmæssigt og tilbagekaldes ved jobskifte/fratrædelse.

Data og integration

• [ ] Kun reelt nødvendige felter overføres.

• [ ] Følsomme data tokeniseres eller maskeres, hvor det er muligt.

• [ ] Forbindelser og lagrede data er krypterede.

• [ ] Nøgler og hemmeligheder forvaltes adskilt fra kildekoden.

• [ ] API/webhook har godkendelse, beskyttelse mod genafspilning og belastningsbegrænsning.

• [ ] Transaktioner har indbygget transaktionsbeskyttelse (idempotency) og sporing på tværs af systemer.

Applikation og drift

• [ ] Web, API og mobile applikationer er blevet sikkerhedstestet i det rette omfang.

• [ ] Logfiler registrerer tilstrækkelige hændelser, men indeholder ikke hemmeligheder/fulde følsomme data.

• [ ] Der er overvågning, alarmer og klare modtagere af alarmer.

• [ ] Sikkerhedskopier beskyttes, og genoprettelse er testet med succes.

• [ ] Der er en playbook for kontokapring, datalækage og fejlagtige overførsler.

• [ ] Der er en plan for opretholdelse af driften ved afbrydelse af platform eller betaling.

Go-live og efter implementering

• [ ] Alle kritiske fejl er udbedret og kontrolleret igen.

• [ ] Resterende risici er godkendt skriftligt af en autoriseret person.

• [ ] Listen over nødrelevante kontakter mellem parterne er testet.

• [ ] Medarbejdere kender kanalen til at anmelde tabte konti eller usædvanlige transaktioner.

• [ ] Der er en tidsplan for gennemgang af rettigheder, sårbarheder, leverandører og alarm effektivitet.

• [ ] Der er bevis for kontrol efter større ændringer.

Konklusion

Datasikkerhed i forbindelse med adgang til optjent løn starter med en forståelse af datastrømme og ansvar, ikke med en liste over teknologier. Et pålideligt program skal begrænse indsamlede data, godkende den rette person, tildele de rette rettigheder, beskytte API'er og transaktioner, føre tilstrækkelige logfiler, kontrollere leverandører, kunne gendanne ved afbrydelser og håndtere hændelser gennemsigtigt.

Hvis din virksomhed vurderer en løsning for adgang til optjent løn, bør du forberede et systemdatakort, en liste over forventede dataintegrationer og en intern kontroltjekliste, og derefter udforske Adgang til optjent løn for virksomheder for at anmode om sikkerhedsdokumentation, integrationsmateriale og omfanget af teknisk vurdering før pilotfasen.

Referencer

• EU's generelle databeskyttelsesforordning (GDPR)

• OWASP Application Security Verification Standard

• OWASP Mobile Application Security Verification Standard

• OWASP Logging Cheat Sheet

Forfatter: Nguyen Tan Loc — Specialist hos Strategiafdelingen, Nhan Kiet Manpower Supply Co., Ltd.

Rådgivning om løsninger for adgang til optjent løn til virksomheder: Hotline 0937.022.655 · E-mail info@nhankiet.vn · Adgang til optjent løn for virksomheder