Team Orgs interne dokumentasjon

^Edit ^me: ^{https://github.com/navikt/team-org/tree/main/src/main/asciidoc}

Teamkatalogen: Team Org

1. Applikasjoner/Systemer

Figure 1. orginaltegningen på Figma

1.1. State of the Union

Figure 2. Orginalmatrise på Mural

1.2. NOM - NAV Organisasjons Master

Visjon
- NOM skal inneholde og dele autoritativ informasjon om hvordan NAV er organisert og hvem som jobber for NAV.

— fra dkoumentasjonen

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Gammelt - Deprekeres?
https://confluence.adeo.no/display/FEL/NOM
https://confluence.adeo.no/display/NOM/NAV+Organisasjonsmaster+-+NOM

Repo

https://github.com/navikt/nom

1.3. Skjerming - NAV Skjermingsløsning

Skjermingsløsning holder på info om ansatte og evt. familiemedlemmer av disse som har bedt om skjerming i NAVs systemer. Default settes ansatte til skjermet, men de kan avskjerme seg.

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Repo

https://github.com/navikt/skjerming

1.4. NORG/NORG2

NORG har informasjon om enheter, oppgavekøer (virtuelle enheter) og rutingregler. NORG er NAVs rutingmaster (eks. hvor skal en AAP-søknad for en person bosatt i Drammen behandles).

Norg1 (https://stash.adeo.no/projects/FEL/repos/norg/browse) er ikke i vedlikehold.
Benyttes per i dag av IDM som skal over til Axsys, og av AAReg WEB (?), #dv-team-arbeidsforhold (?), som skal avvikles

Repository

https://github.com/navikt/norg2

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Gammelt - Deprekeres?
NORG - https://confluence.adeo.no/display/FEL/NORG
NORG2 - https://confluence.adeo.no/display/FEL/NORG2
NORG2 Frontend - https://confluence.adeo.no/display/FEL/NORG2-frontend

1.5. Teamkatalog

Teamkatalogen gir en oversikt over alle leveranseteam i NAV og deres tilhørighet til (produkt)områder.

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Repo

https://github.com/navikt/team-catalog

1.6. Kodeverk

NAVs systemer utveksler kodeverdier fra mange forskjellige kodeverk. Denne applikasjonen er en master for disse kodeverkene, og den tilbyr diverse grensesnitt som konsumenter kan benytte seg av for å hente ut informasjonen om de kodeverkene de er interesserte i.

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Gammelt - Deprekeres?
Kodeverk - https://confluence.adeo.no/display/FEL/Kodeverk

Repo

https://github.com/navikt/felleskodeverk

1.7. Axsys

AXSYS holder på hvilke dokumenttilganger en ressurs har. Det betyr at ressurs A kan lese dokumenter med tema B når man representerer enhet C.

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Gammelt - Deprekeres?
Axsys - https://confluence.adeo.no/display/FEL/Axsys

Repo

https://github.com/navikt/axsys

1.8. Sak Og Behandling

Sak og behandling sørger for at NAV ivaretar oversikt over saker og behandlinger på en enhetlig måte, og muliggjør informasjonsdeling til brukere, samhandlere og saksbehandlere.

Dokumentasjon

SakOgBehandling Ekstern (kilde)
SakOgBehandling Intern (kilde)

SoB Proxy Ekstern (kilde)
SoB Proxy Intern (kilde)

Gammelt - Deprekeres?
SoB - https://confluence.adeo.no/display/FEL/Sak+og+behandling
SoBProxy - https://confluence.adeo.no/display/FEL/SOB+Proxy

Repo

https://github.com/navikt/sakogbehandling https://github.com/navikt/sobproxy

1.9. BTSYS

Suspensjonsregister for Behandler og Tjenesteytere
Systemeier er PO Helse, Camilla Bårnes Roark

Dokumentasjon

Ekstern (kilde)
Intern (kilde)

Gammelt - Deprekeres?
Confluence - Handover fra Paul Magne Lunde til Team Org
Confluence - Opprinnelig løsningsskisse
Confluence - ABAC internbruker policy
Confluence - ABAC systembruker policy

Swagger

Swagger - For konsumenter
Swagger - Internt for BTSYS-WEB
Swagger - Internal api mot BTSYS-WEB

Repo

https://github.com/navikt/btsys

2. Dokumentasjon

Preferert vertøy for dokumentasjon i Team Org er Asciidoc. Ett par nyttige guider er Vogella Asciidoctor og Powerman cheatseet. Det finnes også en plugin til intellij som gjør editering enklere (Asciidoc plugin).

Når bilder av tegninger, diagrammer, bilder etc. limes inn i dokumentasjonen, bør orginal legges med i asciidoc kildekoden med henvisning til denne. Når orginalen ligger i annet system/online benytt url til orginalen.

Merk at dokumentasjonen ut på GitHub pages er og bør være public.

2.1. Team dokumentasjon

Team Org har denne dokumentasjonen som sin hoveddokumentasjon for teamet. Denne kan inneholde alt som går på tvers av de ulike systemene og programmene.

2.2. System- og brukerdokumentasjon

Skal være en del av systemets kode repository.

Se for eksempel hvordan dette er gjort i NOM prosjeket.

Ascii doc prosjektet i NOM: https://github.com/navikt/nom/tree/main/docs
GitHub Worklfow filen for deploy til gh-pages: https://github.com/navikt/nom/blob/main/.github/workflows/docs.yaml

Systemdokumentasjonen kan deles i en ekstern og en intern del. I tillegg kommer annen type dokumentasjon slik Swagger etc. som gjerne deployes som en del av selve applikasjonen. Denne type dokumentasjon kan henvises til fra systemdokumentasjon.

2.2.1. Ekstern dokumentasjon

Rettet mot interessenter utenfor teamet og brukere av grensesnitt og API’er. Beskrive hva, hvordan og hvorfor.

2.2.2. Intern systemdokumentasjon

Den delen av dokumentasjonen som retter seg til oss i teamet. Arkitektur, løsningsvalg/beskrivelser, utvikling/bygg/deploy, etc.

2.3. AsciiDoc Best practice

New lines etter hvert setning. Asciidoctor lager ikke new lines basert på nye linjer i dokumentet, men med + eller doble linjer. Nye setninger lages på hver sin linje ettersom endringer i git da ikke blir helt kaos.

3. Sikkerhet

3.1. Snyk security scan

Snyk er et SAAS verktøy som scanner prosjekter etter kjente sårbarheter i benyttede biblioteker. NAV IT har egen lisens på Snyk, og hvert team setter opp egen organisasjon i Snyk. Team org har org som organisasjon i Snyk, og brukere må administreres manuelt. (Send invite for nye i Team Org)

Logg inn i snyk med SSO med Nav e-mail adressen som bruker.
Tilgang til Snyk må aktiveres av bruker selv gjennom https://myapplications.microsoft.com/

3.1.1. GitHub repo scan

For å scanne et repo i GitHub, legg til dette direkte i Snyk. Velg 'Add Project', finn prosjektet, huk av, og trykk 'Add selected projects'. Snyk finner da selv frem i alle Maven, gradle, npm prosjektene etc på egenhånd og scanner disse. Snyk lager pull-requests på de endringern som den mener kan fikse sårbarhetene. Disse PR’ene kommer med en tilfeldig bruker i repoet. (Snyk har ikke selv en bruker i repoet som kan være PR innsender)

3.1.2. Scanne Docker image

Snyk får ikke til å skanne docker image bare ved å se på repositoriet. Dette kan gjøres ved å legge inn i GitHub Actions en manuell scan av deployed image. F.eks. slik:

Eksempel fra btsys.yaml

security:
  runs-on: ubuntu-latest
  needs: build-jar-docker
  steps:
    - name: Run Snyk to check Docker image for vulnerabilities
      env:
        SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SEVERITY_TRESHOLD: high
      run: |
        sudo npm install -g snyk
        snyk auth ${SNYK_TOKEN}
        docker login docker.pkg.github.com -u ${GITHUB_REPOSITORY} -p ${GITHUB_TOKEN}
        snyk monitor --severity-threshold=${SEVERITY_TRESHOLD} --org=org-6kx --docker ${IMAGE_LATEST}
      continue-on-error: false

4. Logging

Kan deles inni to ulike behov:

Forvalte applikasjonen - Applikasjonslogging
Lovkrav/ekstern krav - Sikkerhetslogging (auditing)

4.1. Applikasjonslogging

Her inngår all logging et team har behov for i en applikasjon for å kunne forvalte, monitorere aktivitet, og feilsøke.
Dette kan vi dele opp i:

Alarmer/feilmeldinger
Når det skjer feil i systemet
Dette vil i stor grad være WARN, ERROR og FATAL logging
- Exceptions
- Feil mot delsystemer
- Feil i input
Applikasjonsstatus
Logging av deploys og restarter etc.
Logging av jobber/schedueled aktiviteter
Trafikk Logge innkommende og utgående kall
(NB/OBS - persondata - i URL eller headere etc)
Flyt og hendelser
Logge flyt og hendelser/avgjørelser i behandlinger av kall.
Det er her de aller fleste DEBUG log behov kommer inn
Auditing
Hva aksesseres, av hvem (NB/OBS - persondata), med hvilke parametere
Og hva er resultatet av dette:
- Tillatt eller avvist (isåfall hvorfor)
- Endring, sletting eller visning av spesifik informasjon

4.1.1. To steder å sende applikasjonsloggingen til

Console logging fra applikasjonen (stdout/errout)
Dette skrapes av FluentD til Elasticsearch og presenteres i Kibana/logs.adeo.no
NB!! Aldri logg persondata informasjon hit (f.eks, Fødselsnummer, akørId, husadresser, IP adresser, orgnummer)
Secure Logs - Egene loggfiler i /secure-logs/ katalog
Dette skrapes til Elasticsearch og presenteres i Kibana/logs.adeo.no, men er ikke åpent tilgjengelig.
Tilgang til disse loggene styres på behov.
Det er hit logging med persondata-informasjon kan logges når det er behov.
NB! Logging av persondata SKAL minimeres til det faktiske behovet for forvaltning av applikasjonen.
Det skal også foreligge (til enhver tid oppdatert) ROS (risikovurdering) for denne loggingen og tilgangene til dette.

4.2. Sikkerhetslogging (auditing)

Som databehandler av persondata påligger det oss krav om hvordan denne dataen forvaltes. Disse kravene kommer fra lov/datatilsyn og sikkerhetsavdelingen i NAV har ansvaret for dette. Denne loggingen foregår per i dag til ArcSight, og gjøres via Syslog i applikasjonen (f.eks. med en Syslog4jAppender), som sendes til audit.nais som skrapes av arcsight. ArcSight krever at loggmeldingen kommer i et spesielt format. Les mer her https://github.com/navikt/naudit#log-format

Fra Slack thread

Det vi i NAV bruker Arcsight handler om innsyn/endring på bruker. Ikke nødvendigvis personopplysninger. Det er nok at en ansatt har gått inn på din profil. ( Men alt er vel kanskje som personopplysninger å regne ) Arcsight skal ha oversikt over alle oppslag som er gjort på en bruker, evt alle oppslag som en ansatt har gjort. Gjerne også hva den ansatte har gjort, men det er litt opp til applikasjonseiere nøyaktig hva de logger siden vi ikke nødvendigvis har greie på hver enkelt applikasjon

Det går rykter om at ArcSight kanskje skal byttes ut - men behov/krav for logging vil fortsatt være den samme

4.2.1. Sluttkommentar til auditing

Det er også (historisk ihvertfall) vanlig å logge i database hvem (system eller sluttbruker) som opprettet/endret en informasjon (record i SQL, melding i event etc) sammen med tidspunkt Det får være opp til hver enkelt app hva som er ønskelig

4.3. Referanser og annen dok på logging

Logghygiene - Data og Utvikling dok
Logging - Security Champions playbook
Logging - Nais dok
Sikkerhetlogging/naudit

5. Div/nyttige Linker

STS rest API: https://security-token-service.dev.adeo.no/api
Vault: https://vault.adeo.no/ui/vault/secrets
API GW: https://api-management.nais.adeo.no/api.html
Gammel Gui https://api-management.nais.adeo.no/apimanagement.html
IDA: https://ida.intern.nav.no/
Appdynamics: https://appd.adeo.no/ Pålogging 'account' ⇒ NON-PROD/PROD
status.nav.no: https://status.nav.no/published/f30afd1e0f62769b4da8f64014d59a06/rogertest
HDIR / Helsedirektoratet åpne API https://utvikler.helsedirektoratet.no
NAV åpne API tjenester https://api-portal.nav.no/
Applikasjonstilganger/lisenser https://myapplications.microsoft.com/
Gamle Felles registrene på Confluence https://confluence.adeo.no/display/FEL
NAIS dokumentasjonen https://doc.nais.io/
NAV Security Playbook https://sikkerhet.nav.no/
NAV Security blueprints https://security.labs.nais.io/
NAV designsystem https://aksel.nav.no/
'Undeploye' versjoner i VERA. Fra utv.image - https://atom.adeo.no/job/vera_undeploy/