Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Dette indhold kan ikke ses af eksterne (og er ikke relevant for eksterne)

DS-2775 - Getting issue details... STATUS

BI-756 - Getting issue details... STATUS
JOB-1449 - Getting issue details... STATUS

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):

Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)

Beskrivelse af epic

NB. (Under udarbejdelse / Work in progress)

Det er af epic planlagt at udføre anonymisering, af CPR numre og CV numre i forbindelse med dataløft, på datascrambling serveren SF allerede i dag benytter til at fortage den resterende datascrabling.

Ved at fortage scambling på netop dette tidspunkt vil SF derved have mulighed for at have to kopier af dataløftet

• En med den alm. datascambling.
• En med den alm. datascambling + CPR nummer og CV nummer scambling.

Derved vil man kunne udvælge specifikke TMiljøer, hvor CPR nummer og CV nummer scambling er indeholdt, ved at udføre scambling af CPR og CV nummer på datascambling serveren, sikres det også at serveren scamblingen skal fortages på har den fornødende kapacitet.

Der vil med udgangspunkt i proff of concept (POC) udført i https://manuscript.star.dk/f/cases/153691/Unders-gelse-om-kunstige-cpr-numre-i-DFDG, blive eksekveret script som anonymisere CPR numre og CV numre i såvel hovedtabeller som historik tabeller.

Eksisterende Proff of concept

Eksisterende scripts i POC udføre følgende for X borgere:

• Tabel indeholdende originalt CPR nummer og CV nummer, hvor konskruteret CPR nummer og CV nummer fortages efter nedenstående regler:
  • Konstrueret CPR-Nummer: Alder beholdes (også på 7 ciffer, hvis borger ligger på grænsen af udfaldsrum 1936, 2000 og mindre end 1899).
  • Konstrueret CPR-Nummer: Køn beholdes ulige/lige på 10 ciffer.
  • Konstrueret CPR-Nummer: Må ikke allerede eksistere i CPR tabelen i DFDG i forvejen
  • Konstrueret CV-Nummer: Genereres ved at tage det næste ubrugte CV-nummer i rækken.
• CPR udskiftes i tabeller i DFDG, hvor kolonne navn i tabellen er en af følgende:
  • 'PersonCivilRegistrationIdentifier'
  • 'CivilRegistrationIdentifier'
  • 'CivilRegistrationRowNumber'
  • 'GuardianCivilRegistrationIdentifier'
  • 'ReceiverPersonCivilRegistrationIdentifier'
  • 'ChildCPRNumber'
  • 'Cpr'
  • 'CprNumber'
  • 'AEGTEPNR'
  • 'BenefitsExpiry_CivilRegistrationIdentifier'
  • 'BenefitsExpiryHistory_CivilRegistrationIdentifier'
  • 'BenefitsGrading_CivilRegistrationIdentifier'
  • 'BenefitsGradingHistory_CivilRegistrationIdentifier'
  • 'BenefitsRate_CivilRegistrationIdentifier'
  • 'BenefitsRateHistory_CivilRegistrationIdentifier'
  • 'ChildCivilRegistrationIdentifier'
  • 'Citizen_ID'
  • 'CivilRegistrationIdentifier'
  • 'Consumption_CivilRegistrationIdentifier'
  • 'ConsumptionHistory_CivilRegistrationIdentifier'
  • 'CPR','CPR_nummer'
  • 'CPR_nummer_familiemedlem'
  • 'CPRNr'
  • 'CprNummer'
  • 'DD_CPRNummer'
  • 'DW_Map_AktivData_PersonCivilRegistrationIdentifier'
  • 'DW_Map_JCP_CPR'
  • 'EmploymentAccount_CivilRegistrationIdentifier'
  • 'EmploymentAccountHistory_CivilRegistrationIdentifier'
  • 'p_nr','PersonCivilRegistrationIdentifier'
  • 'Personnummer'
  • 'PNR','PNRFAR','PNRGAELD'
  • 'PNRMOR','QualifyingHours_CivilRegistrationIdentifier'
  • 'QualifyingHoursHistory_CivilRegistrationIdentifier'
  • 'QualifyingHoursReportHistory_CivilRegistrationIdentifier'
  • 'ReferentialPeriod_CivilRegistrationIdentifier'
  • 'ReferentialPeriodHistory_CivilRegistrationIdentifier'
  • 'RegradingAccount_CivilRegistrationIdentifier'
  • 'RegradingAccountHistory_CivilRegistrationIdentifier'
  • 'ShorteningReport_CivilRegistrationIdentifier'
  • 'ShorteningReportHistory_CivilRegistrationIdentifier'
  • 'SupplementalBenefitsAccount_CivilRegistrationIdentifier'
• CVNummer i DFDG udskiftes kun hvis kolonnen har navnet CVCustomerNumber
• CVNummer i Jobnet udskiftes, hvis følgende er gældende:
  • Kolonne navn er et af følgende: 
    • 'CVNumber'
    • 'iKundnummer'
    • 'iKundnummmer'
  • Tabelnavn er et af følgende:
    • 'tKundnummerSokande'
    • 'tKundnummerOrganisation'
    • 'tKundnummerArbetsstalle'
    • 'tKundnummerArbetsgivareKP'

Derved vil det være en scambling af de 4-3 sidste cifre af CPR nummeret der vil blive foretaget.

Tabellen: CivilRegistrationIdentifierMap vil være eneste mapping mellem det originale CPR nummer, CV numre og de scramblede udgaver, denne tabel skal derfor benyttes, af de andre projekter i STAR City til ligeledes at udskifte til scamblede udgaver af CPR numre og CV numre.

Overvejelser

• Indledende samtaler med VOA?
• Fremrykkelse af samtaler med de eksterne?
• Observation af nye tabeller med CVnummer/CPR-nummer (regel? benyt PersonID fremadrettet i DFDG)
• Data nedenunder?
  • Sammenhænge af data, eks. en borger med 7 samtaler på en uge?
• Profil afklarings værktøjet?
• CPR sammenhæng til børn under 18?
• Det skal undersøges, hvorvidt der i forbindelse med implementering af POC er glemt tabeller.
• CPR og CV numre efter scambling skal være forskellige fra original CPR numre.
• Eksisterende DUPLA/NemSMS borgere skal bibeholdes og skal ikke være en del af konverteringen.
• Dataminimeringen af borgere til 100.000, er det inddelt i populationer? eller skal det være tilfældige borgere?

  • Eks. X% fordelt pr. kontaktgruppe? Fravær, A-kasse medlemskaber, forskellige kommuner, tilmeldingsforhold etc. etc.

• SF Log 6 måneder , bliver disse fjernet ved dataløft?
• Fjernelse af Data efter teleport?
• LetAsyl?
• STIL, UDB?
• Planner efter 2020?
• Shrink af mdf og log efter dataminimering? (Plads på disk)

Juridiske overvejelser

Fra CPR:

https://cpr.dk/cpr-systemet/opbygning-af-cpr-nummeret/

Opbygningen af CPR-nummeret er baseret på følgende:

NB: Indtil den 1. oktober 2007 opfyldte alle personnumre den såkaldte modulus 11 kontrol.

(Opdateret Juni 2019)

https://cpr.dk/cpr-systemet/personnumre-uden-kontrolciffer-modulus-11-kontrol/

CPR-numre som ikke overholder modolus 11, hvor kontrolciffer på position 10 ikke er modulus 11 complient, er pr. Juni 2019 indeholdt i de personer der har fødselsdato på følgende datoer:

Overvejelsen går derfor på, hvorvidt eksisterende POC er tilstrækkeligt, da scramblingen af CPR-nummer bliver udført på kørsels tidspunktet af datascramlingen, hvor der tjekkes op på, hvorvidt det nye genererede CPR-nummer eksistere i DFDG.

Datascambling sker i forbindelse med at kopi af produktion tages, dette sker idag ca. hver tredje måned, derved vil der potentielt blive genereret CPR-numre i forbindelse med scamblingen som på kørselstidspunktet ikke er benyttet men som indenfor tidsrammen på de ca. 3 måneder vil være kunnet være taget i brug af en borger som har fået tildelt en CPR-nummer.

• Er det tilstrækkeligt, at CPR nummer tjekkes en gang pr. release, hvorvidt nye er kommet til?

Acc.kr 955.11.1 Optimeringer af generering af anonymiserende CPR-numre

Efter at SF og DFDG i samarbejde har arbejdet på sagen i manuscript sagerne 172971 og 175995 er kørselstiden kommet ned på:

2 dage, 14 timer, 19 minutter og 31 sekunder

Dette har SF godkendt i manuscript 175995, hvor der jo også med tiden er planer om at få slettet data fra døde borgere, hvilket vil få populationen som der skal foretages datascambling ned.

Ydermere kan der også i forbindelse med skift af driftleverandør også være nye og mere kraftfulde servere som kan håndtere datascamblingen.

Grundet ovenstående optimerer DFDG ikke yderligere på datascamblingen.

Kørsel på den nye dataløft server:

1 dag, 20 timer, 5 minutter og 30 sekunder.

Acc.kr 955.11.2 Interne aftager systemer af DFDG data, har taget forholdregler i forbindelse med anonymisering af CPR numre og CV numre.

Efter endt datascambling har SF valgt TMiljø T17, til at være miljøet, hvor datascamblingen af CV og CPR-nummer er ude på.

Jobnet laver regressionstest via  JOB-882 - Getting issue details... STATUS . I forbindelse med denne test er fundet 3 fejl på batchjob, der er samlet på denne samlesag: 

https://manuscript.star.dk/f/cases/180835/Samlesag-Fejl-fundet-p-batchjobs-i-forbindelse-med-reg-test-p-T17-GDPR-form-rkning-af-CV-og-CPR.

Hvis fejl skal prioriteres, skal  Jobnet CPO autorisere det. 

Acc.kr. 955.11.3 CV nummer skal fremgå unmasked af Jobnet på udvalgte miljøer

I Jobnet vises CVnummer i dag, i alle udviklingsmiljøer, som maskeret. Konkret vises 99999999 for alle borgere - både ved visning af nummeret i kontekst af CV og i bjælken øverst i browseren, som udelukkende vises på T-miljøerne. 

Årsagen til, at tallet er rettet til 9999999 for alle er, at Jobnet bruger Browserstack, hvor CV-nummer kan tænkes sendt til Browserstack, når vi afvikler en jobnet session for en borger i en given browseropsætning. Af GDPR hensyn har man derfor maskeret det oprindelige nummer. Da numrene nu er anonymiserede (på udvalgte miljøer) og de derfor ikke udgør en GDPR risiko ved anvendelse af Browserstack på disse miljøer, kan vi vise det anonymiserede nummer i stedet for det maskerede . Dette letter arbejdet for udviklere, FA'ere mv. i disse testmiljøer i det daglige, da vi herved let kan finde borgeren i LSS mv. 

I Job-2012: CV-nummer som unmasked i udvalgte T-miljøerudvides jobnets fil  settings.XML derfor med en indstilling pr. T-miljø, som angiver hvorvidt der på det pågældende miljø skal vises det maskerede "99999999" CV-nummer eller det anonymiserede CV-nummer, som det fremgår i databasen. Defaultsetting bliver, at det maskerede nummer vises i alle testmiljøer (unmasked = false). Er der ikke angivet en testmiljøsetting for unmasked, defaultes ligeledes til false. Angives eksplicit for et T-miljø, at maskering ikke skal ske (unmasked = true), så vises vises CV-nummer som det fremgår i databasen.

For Produktion og PreProd gælder indstilling ikke. Her vises allerede i dag det aktuelle nummer fra basen.

Jobnets kode vil virke fra 20-3 og frem.

Særlige krav til test

* Batchjobs

• bør testes både med delta og fuldt load,
• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
• bør testes i samarbejde med teams som har afhængigheder
• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres
• skal der køres konvertering
• Skal der køres databasescripts for opdatering af tabeller i databasen

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder
• Nye snitflader
• Nye komponenter
• Nye miljøer
• Nye teknologier
• Nye aftagertyper
• Eller afvigelser fra principperne
• Eventuelle behov for reduktion af teknisk gæld skal afdækkes

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.