Hopp til hovedinnhold

Logging

NAIS-plattformen tilbyr et standard opplegg for logging. stdout fra alle pods skrapes, indekseres i LogStash/Elasticsearch og kan søkes i fra Kibana (logs.adeo.no). For at dette skal funke bra er man avhengig av at det logges som JSON. Mange rammeverk har støtte for dette JSON-baserte formatet, f.eks. LogBack og winston.

Loggindekser og tilgang

Standardindeksene (logstash-apps-*) er åpne for veldig mange mennesker (bl.a alle utviklere), og egner seg derfor ikke for personopplysninger eller andre sensitive data. For dette formålet kan man få opprettet egne indekser som får navnet tjenestekall-*. Disse indeksene omtales ofte som secure log, og er kun lesbare for teamet som eier dem. Innholdet skrapes automatisk fra filer på fast sted i podene. Prosessen for å få opprettet slike indekser finner man i NAIS-docen.

Auditlogging

Auditlogger skal skrives til et system som heter ArcSight, nærmere info om dette finnes også i NAIS-docen. Loggene blir da søkbare for de som har behov for dette. ArcSight krever at man logger i Common Event Format (CEF) via Syslog. Det er ikke bred støtte for CEF i de mest brukte loggerammeverkene, så her må man fikse formatteringen selv. Ved behov for hjelp kan man henvende seg til #tech-logg_analyse_og_datainnsikt på Slack.

Et eksempel på en app som benytter alle disse loggemulighetene finner man her.

Logghygiene

  • Det burde ikke logges mer personinformasjon enn det som er nødvendig for å feilsøke. Ikke lagre mer informasjon enn man har tjenstlig behov for.
  • Rader som unikt identifiserer brukerne skal ikke i åpen logg. Eksempler:
    • Fødselsnummer, aktørId, husadresser, IP-adresser, organisasjonsnummer
  • Pass spesielt på URL-stier, HTTP-headere og lignende som ofte blir logget av rammeverk eller mellomtjenester
    • F.eks. fødselsnummer i URLen, /person/1234567890 eller /person?fnr=1234567890, vil fort feilaktig ende opp i tilgangslogger uten videre beskyttelse.
  • Alt det som ikke kan gå i åpen logg kan legges i secure logs, med begrenset tilgang til loggen (teamet må ha kontroll på hvem som har tilgang)
  • ROS på teamets logging og eventuelt tilgang til secure logs (husk å oppdatere ved behov!)
  • Er uhellet ute og det logges noe som ikke skal logges, bør man sørge for å slette loggene. Muligens må avvik også føres i Remedy. Et eksempel på hvordan ting gikk galt og hvordan det ble rettet kan leses i denne Slack-tråden
Savner du noe?

Legg det inn selv på GitHub, si ifra i #security-champion, eller kontakt redaksjonen. Takk! 💖