Odoos sikkerhedspolitik

Sikkerhedskopiering / IT-katastrofeberedskab

• Vi opbevarer en historik med 14 komplette sikkerhedskopier af hver Odoo-database i op til 3 måneder: 1/dag for 7 dage, 1/uge for 4 uger, 1/måned for 3 måneder.
• Sikkerhedskopier gemmes i mindst tre forskellige datacentre på to forskellige kontinenter.
• De præcise placeringer af vores datacentre fremgår af vores privatlivspolitik.
• Du kan desuden når som helst downloade manuelle sikkerhedskopier af dine livedata via kontrolpanelet.
• Kontakt vores kundeservice for at gendanne en hvilken som helst af disse sikkerhedskopier til din livedatabase (eller på siden).
• Hardwarefailover: For tjenester, der hostes på bare metal-servere, hvor hardwarefejl kan forekomme, implementerer vi en lokal kopi på en reservedatamaskine. Denne står standby med overvågning og en manuel fejlsikringsprocedure, klar til brug i tilfælde af nedbrud.
• IT-katastrofeberedskab: I tilfælde af en alvorlig katastrofe, hvor et datacenter er nede i en længere periode, og failover til vores straks brugbare standby-erstatningscomputer forhindres (dette er aldrig sket før, men proceduren er klar til det værst tænkelige scenarie), bestræber vi os på nedenstående:
  • Maksimalt acceptable datatab (Recovery Point Objective, RPO) = 24 timer. Det betyder, at du maksimalt kan miste 24 timer af dit arbejde, hvis dataene ikke kan gendannes, og vi er nødt til at gendanne din seneste sikkerhedskopi.
  • Maksimalt acceptable datatab (Recovery Point Objective, RPO)= 24 timer for betalte abonnementer, 48 timer for gratis prøveperioder, oplæringstilbud, freemium-brugere osv. Det er den tid, det tager at genoprette tjenesten i et andet datacenter, hvis katastrofen er ude, og et datacenter bryder helt sammen.
  • Det opnår vi således: Vi overvåger aktivt dine daglige sikkerhedskopier på flere lokationer på forskellige kontinenter. Vi har automatiseret overførsel af vores tjenester til en ny hostinglokation. Genoprettelsen af data baseret på vores sikkerhedskopier fra den foregående dag kan derefter finde sted indenfor et par timer (for de største dataklynger), hvorved betalte abonnementer prioriteres.
    Vi gør rutinemæssigt brug af både de daglige sikkerhedskopier og klargøringsscripts til den daglige drift, så begge dele af IT-katastrofeberedskabsproceduren hele tiden testes.

Databasesikkerhed

• Kundedata gemmes i en dedikeret database – data deles ikke mellem kunder.
• Reglerne for dataadgangskontrol sikrer en fuldstændig adskillelse mellem kundedatabaser i samme dataklynge, så adgang fra en database til en anden er ikke mulig.

Adgangskodesikkerhed

• Kunders adgangskoder beskyttes med PBKDF2+SHA512-kryptering i henhold til branchestandard (saltet + forlænget til tusindvis af runder).
• Odoos medarbejdere har ingen adgang til din adgangskode og kan ikke gendanne den for dig. Det eneste, du kan gøre, hvis du mister den, er at nulstille den.
• Legitimationsoplysninger overføres altid sikkert via HTTPS.
• Kundedatabaseadministratorer kan sågar konfigurere hastighedsbegrænsning og ventetid mellem loginforsøg.
• Politik for adgangskoder: databaseadministratorer har en indbygget indstilling til at kræve en minimumslængde for brugeradgangskoder. Andre politikker for adgangskoder som eksempelvis påkrævede tegnklasser understøttes som udgangspunkt, da de har vist sig at være kontraproduktive. Se for eksempel [Shay et al. 2016] og NIST SP 800-63b.

Medarbejderadgang

• Odoos kundeservice kan logge ind på din konto for at løse supportrelaterede problemer. Det gør de ved at bruge deres særlige medarbejderoplysninger og ikke din adgangskode (som de ikke kan have kenskab til).
• Denne særskilte medarbejderadgang forbedrer effektiviteten og sikkerheden: Medarbejderne kan øjeblikkeligt genskabe det problem, du ser, uden at du behøver give dem din adgangskode, og vi kan kontrollere og styre medarbejdernes handlinger separat!
• Vores kundeservicemedarbejdere bestræber sig på at respektere dit privatliv så meget som muligt og tilgår udelukkende filer og indstillinger, der er nødvendige for at diagnosticere og løse dit problem.

Systemsikkerhed

• Alle Odoo Cloud-servere kører hærdede Linux-distributioner med de seneste sikkerhedsopdateringer.
• Installationer er ad hoc og minimale for at begrænse antallet af tjenester, der kan indeholde sikkerhedsrisici (f.eks. ingen PHP/MySQL-stak).
• Kun få betroede Odoo-ingeniører har autoriseret fjernadgang til at administrere servere – og adgang er kun mulig via et krypteret personligt SSH-nøglepar fra en computer med fuld diskkryptering.

Fysisk sikring

Odoo Cloud-servere hostes i sikre datacentre i forskellige regioner rundt om i verden (f.eks. OVH, Google Cloud), og de skal opfylde alle vores fysiske sikkerhedskriterier:

• Begrænset fysisk adgang kun for autoriserede medarbejdere i datacentret.
• Fysisk adgangskontrol med sikkerhedsbadges eller biometriske sikkerhedsmetoder.
• 24/7-overvågningskameraer, der overvåger datacentrene.
• 24/7-sikkerhedspersonale på stedet.

Sikker kreditkortbetaling

• Vi lagrer aldrig kreditkortoplysninger i vores egne systemer.
• Dine kreditkortoplysninger overføres altid sikkert og direkte mellem dig og vores PCI-kompatible betalingsindløsere (se listen i vores privatlivspolitik ).

Datakryptering

• Al datakommunikation med kundeinstanserne er beskyttet med 256-bit SSL-kryptering (HTTPS).
• Al intern datakommunikation mellem vores servere er beskyttet med end-to-end-kryptering.
• Vores servere er underlagt streng sikkerhedsovervågning og er altid beskyttet mod de seneste SSL-sikkerhedsricisi.
• Alle vores SSL-certifikater gør brug af 2048-bit moduler med hele SHA-2-certifikatkæder – Vurdering A+
• Alle kundedata (databaseindhold og opbevarede filer) er krypteret i hvile, både i produktionen og i sikkerhedskopierne (AES-256).

Netværksforsvar 

• Alle datacenterudbydere, som Odoo Cloud bruger, har en meget stor netværkskapacitet og har designet deres infrastruktur til at modstå selv de største DDoS-angreb (Distributed Denial of Service). Deres automatiserede og manuelle forsvarssystemer kan opdage og omdirigere angrebstrafik i udkanten af deres multikontinentale netværk, før det har en chance for at forstyrre servicetilgængeligheden.
• Firewalls og systemer til forebyggelse af indtrængen på Odoo Cloud-servere hjælper med at identificere og blokere trusler som eksempelvis brute force-angreb på adgangskoder.
• Kundedatabaseadministratorer kan sågar konfigurere hastighedsbegrænsning og ventetid mellem loginforsøg.

Softwaresikkerhed

Da Odoo er en open source-software, kontrolleres hele kodebasen løbende af Odoos brugere og bidragydere over hele verden. Fejlrapporter fra fællesskabet er derfor en vigtig kilde til feedback om sikkerhed. Vi opfordrer udviklere til at gennemgå koden og rapportere sikkerhedsproblemer.

Odoos FoU-processer omfatter trin til gennemgang af koden, herunder sikkerhedsaspekter for nye og bidragede dele af koden.

Designet til at være sikker

Odoo er udviklet på en sådan måde, at de mest almindelige sikkerhedsproblemer ikke opstår:

• SQL-injektionsangreb forhindres ved at bruge et API (programmeringsgrænseflade) på højere niveau, som ikke kræver manuelle SQL-forespørgsler.
• XSS-angreb forhindres ved at bruge et avanceret skabelonsystem, der automatisk omgår indsatte data.
• Strukturen forhindrer RPC-adgang til private metoder, hvilket gør det sværere at introducere sikkerhedshuller, der kan udnyttes.

Se også afsnittet om De største OWASP-sikkerhedshuller for at se, hvordan Odoo er designet fra bunden af til at forhindre sådanne sårbarheder.

Uafhængige sikkerhedskontroller

Odoo bliver regelmæssigt revideret af uafhængige virksomheder, der får til opgave af vores kunder og interesserede parter at udføre revisioner og penetrationstest. Odoos sikkerhedsteam modtager resultaterne og træffer om nødvendigt passende korrigerende foranstaltninger.

Resultaterne af sikkerhedsrevisioner er fortrolige og ejes af de respektive kommissærer. Det nytter altså ikke noget at bede os om dem ;-)

Odoo har også et meget aktivt fællesskab af uafhængige sikkerhedseksperter, som løbende overvåger kildekoden og samarbejder med os om at forbedre og styrke sikkerheden i Odoo. Vi beskriver vores sikkerhedsprogram på vores side om ansvarlig offentliggørelse .

De største OWASP-sikkerhedshuller

Odoos holdning til de vigtigste sikkerhedsproblemer for webapplikationer, der er identificeret af Open Web Application Security Project (OWASP):

• Injektionsfejl: Injektionsfejl, især SQL-injektion, er almindelige i webapplikationer. Injektioner opstår, når brugerleverede data sendes til en fortolker som en del af en kommando eller forespørgsel. Angriberens fjendtlige data narrer fortolkeren til at udføre utilsigtede kommandoer eller ændre data.

  Odoo benytter en ORM-ramme (object-relational mapping), som abstraherer databaseforespørgsler og som udgangspunkt beskytter mod SQL-injektion. Udviklere skriver normalt ikke SQL-forespørgsler manuelt – de genereres automatisk af ORM, hvor parametre håndteres korrekt og sikkert

• Cross Site Scripting (XSS): XSS-sårbarheder opstår, når en app opfanger data, som brugeren har indtastet, og sender dem til en webbrowser uden at validere eller kryptere indholdet først. XSS giver angribere mulighed for at udføre skripter i offerets browser, som kan kapre brugersessioner, ødelægge hjemmesider og muligvis indføre orme.

  Som udgangspunkt undgår Odoo alle udtryk i visninger og sider for at forhindre XSS. Udviklere skal specifikt markere udtryk som "sikre" for at inkludere dem i gengivne sider.

• Cross Site Request Forgery (CSRF): Et CSRF-angreb tvinger et indlogget offers browser til at sende en forfalsket HTTP-anmodning med offerets sessionscookie og andre automatisk inkluderede autentificeringsoplysninger til en sårbar webapplikation. På denne måde kan angriberen tvinge offerets browser til at generere anmodninger, som den sårbare applikation tror er legitime anmodninger fra offeret.

  Odoo-webstedsmodulet indeholder en indbygget CSRF-beskyttelsesmekanisme. Den forhindrer en HTTP-kontrol i at modtage en POST-anmodning uden det tilsvarende sikkerhedstoken. Dette er den anbefalede teknik til at beskytte mod CSRF. Dette sikkerhedstoken er kun kendt og til stede, hvis brugeren faktisk har fået adgang til den tilsvarende webstedsformular, og en angriber kan ikke forfalske en anmodning uden dette token.

• Udførelse af ondsindede filer: En kode, der er sårbar over for inklusion af fjernfil (RFI), giver angribere mulighed for at indskyde fjendtlig kode og data, hvilket videre kan føre til ødelæggende angreb, eksempelvis at serveren komprimetteres fuldstændigt.

  Odoo har ingen funktioner til at inkludere fjernfiler. Det giver dog privilegerede brugere mulighed for at tilpasse funktioner ved at tilføje brugerdefinerede udtryk, som evalueres af systemet. Disse udtryk evalueres altid i et sandkassemiljø, der kun giver adgang til autoriserede funktioner.

• Usikker direkte objektreference: En direkte objektreference opstår, når en udvikler afslører en reference til et internt implementeringsobjekt som eksempelvis en fil, en mappe, en databasepost eller en nøgle som en URL- eller formularparameter. Angribere kan manipulere disse referencer for at få uautoriseret adgang til andre objekter.

  Odoos adgangskontrol er ikke implementeret på brugergrænsefladeniveau, så der er ingen risiko, hvis URL'er indeholder referencer til interne objekter. Angribere kan ikke omgå adgangskontrollen ved at manipulere disse referencer, da hver anmodning stadig skal gå gennem validering af dataadgang.

• Usikker kryptografisk lagring: Webapplikationer bruger sjældent kryptografiske funktioner korrekt til at beskytte data og legitimationsoplysninger. Angribere bruger svagt beskyttede data til at begå identitetstyveri og andre forbrydelser som eksempelvis kreditkortsvindel.

  Odoo bruger en industristandard sikker hash-funktion til brugeradgangskoder (PBKDF2 + SHA-512 som standardindstilling, med injektion af nøgle) til at beskytte gemte adgangskoder. Det er også muligt at bruge eksterne godkendelsessystemer som OAuth 2.0 eller LDAP for fuldstændig at undgå lokal lagring af brugeradgangskoder.

• Usikker kommunikation: Programmer krypterer ofte ikke netværkstrafik, når det er nødvendigt for at beskytte følsom kommunikation.

  Odoo Cloud kører som udgangspunkt via HTTPS. For lokale installationer anbefales det at køre Odoo bag en webserver, der implementerer kryptering og sender anmodninger til Odoo via en proxyserver, f.eks. Apache, Lighttpd eller nginx. Odoo-implementeringsguiden indeholder en sikkerhedstjekliste til mere sikre offentlige implementeringer.

• Manglende begrænsning af URL-adgang: Ofte beskytter et program kun følsomme funktioner ved at forhindre visning af links eller URL'er for uautoriserede brugere. Angribere kan udnytte denne sårbarhed til at få direkte adgang til disse URL'er og udføre uautoriserede handlinger.

  Odoos adgangskontrol er ikke implementeret på brugergrænsefladeniveau, og sikkerheden er ikke baseret på at skjule specifikke URL'er. Angribere kan ikke omgå adgangskontrollen ved at genbruge eller manipulere en URL, da alle anmodninger stadig skal igennem validering af dataadgang. I de sjældne tilfælde, hvor en URL giver ikke-autentificeret adgang til følsomme data, for eksempel særlige URL'er, som kunder bruger til at bekræfte en ordre, er disse URL'er digitalt signeret med unikke tokens og sendes kun via e-mail til den tilsigtede modtager.

Rapportering af sikkerhedshuller

Hvis du har fundet et sikkerhedshul, som du gerne vil rapportere, gå til vores ansvarlige offentliggørelse. Odoos sikkerhedsteam prioriterer disse rapporter og vurderer og retter dem omgående i samarbejde med rapportøren, hvorefter vi informerer vores kunder på en ansvarlig måde.