Odoo Säkerhet

Säkerhetskopieringar / Återställning efter katastrof

• Historik över 14 fullständiga backuper av varje databas i Odoo under de senaste 3 månaderna: 1/dag i 7 dagar, 1/vecka i 4 veckor, 1/månad i 3 månader.
• Säkerhetskopieringar återskapas i minst 3 olika datacenter, på minst 2 olika kontinenter.
• De fysiska platserna där våra datacenter befinner sig specificeras i vår Säkerhetspolicy.
• Du kan även genomföra och ladda ner en manuell backup av din data när som helst genom kontrollpanelen.
• Du kan kontakta vår kundtjänst för att återställa någon av de säkerhetskopieringarna på din databas som är live (eller på andra sidan).
• Överlämning vid fel: för tjänster som genomförs på bar metall, där utrustningsfel är möjliga, så implementerar vi lokala akativa reserver med övervakade och manuella felöverlämningsprocesser.
• Katastrofåterställning: vid en omfattande katastrof där ett data center är helt nedstängt under en längre tid och i det fall att det automatiska överlämnandet till vår lokala aktiva reserv (det har aldrig hänt än så länge, och skulle bara hända i absolut värsta fall) så har vi följande mål:
  • Målsättning för återställning av data = 24h. Detta innebär att du aldrig förlorar mer än 24 timmars arbete i det fall att datan inte kan återställas helt. I sådana fall återställer vi din senaste dagliga säkerhetskopiering.
  • M̀ålsättning för återställningstid = 24h för betalda prenumerationer, 48h för gratis provperioder, utbildningserbjudanden, freemium-användare, osv. Detta är den tid som det maximalt bör ta att återställa tjänsten i ett annat datacenter i det fall att en katastrof sker och ett datacenter blir satt helt ur funktion.
  • Hur detta uppnås: vi ser aktivt över våra dagliga säkerhetskopieringar och de återskapas på flera platser på olika kontinenter. Vi har automatiserad provisionering för att implementera våra tjänster på en ny hostingplats. Att återskapa datan utifrån våra senaste säkerhetskopieringar kan genomföras på ett par timmar (för de största klustren), med förtur för betalande kunder.
    Vi använder regelbundet både de dagliga säkerhetskopieringarna och provisioneringsscripten för daglig verksamhet för att testa båda delarna av katastrofproceduren.

Databassäkerhet

• Kunddata lagras i en dedikerad databas - ingen data delas med andra kunder.
• Åtkomstkontrollregler för data implementerar fullständig isolering mellan kunddatabaser som körs på samma kluster, det är aldrig möjligt att få tillgång till en databas från en annan.

Lösenordssäkerhet

• Kunders lösenord skyddas med PBKDF2+SHA512-kryptering enligt branschstandarden (saltade och stretchade i tusentals rundor).
• Odoos personal har inte tillgång till ditt lösenord, och har inte möjlighet att återhämta det, om du glömmer lösenordet blir du därför tvungen att återställa det.
• Inloggningsuppgifter överförs alltid tryggt och säkert med HTTPS.
• Administratörer för en kunddatabas kan till och med välja att ställ in andelsbegränsningar och låsningstider efter upprepade inloggningsförsök.
• Lösenordspolicy: databasadministratörer har möjligheten att ställa in ett krav på minst antal tecken. Andra lösenordskrav såsom krav på olika teckengrupper stöds inte som standardalternativ eftersom de har bevisats vara kontraproduktiva. Se t.ex. [Shay et al. 2016]), samt NIST SP 800-63b.

Åtkomstbehörighet för personalen

• Odoos kundtjänstpersonal kan logga in på ditt konto för att få tillgång till de inställningar som är relaterade till ditt kundtjänstärende. För att logga in använder de sina egna personalbehörigheter, inte ditt lösenord (vilket de aldrig har tillgång till).
• Denna speciella personalåtkomst förbättrar både effektiviteten och säkerheten: de kan omedelbart återskapa det problem du stött på, du behöver aldrig dela ditt lösenord och vi kan granska och kontrollera personalens åtgärder separat!
• Vår kundtjänstpersonal har som mål att respektera din integritet så mycket som möjligt, och att endast få tillgång till de dokument och inställningar som behövs för att kunna lösa ditt problem.

Systemsäkerhet

• Alla Odoo Cloud-servrar körs på härdade Linux-distributioner med uppdaterade säkerhetspatches.
• Installationer är ad hoc och minimala för att begränsa antalet tjänster som kan innehålla sårbarheter (till exempel inga stacks från PHP/MySQL).
• Endast ett fåtal betrodda Odoo-ingenjörer har behörighet att fjärrstyra servrarna – och åtkomst är endast möjlig med hjälp av ett krypterat personligt SSH-nyckelpar, från en dator med fullständig diskkryptering.

Fysisk säkerhet

Odoo Cloud-servrar hostas i pålitliga datacenter i olika geografiska regioner världen över (t.ex. OVH, Google Cloud) och de måste överstiga våra fysiska säkerhetskriterier:

• Begränsad tillgång, endast behöriga anställda har tillgång till datacentret.
• Fysisk tillgång med säkerhetsbrickor eller biometriska faktorer.
• Säkerhetskameror övervakar datacentren 24/7.
• Säkerhetspersonal på plats 24/7.

Säkerhet för kreditkort

• Vi sparar aldrig kortuppgifter i våra egna system.
• Din betalinformation överförs alltid på ett säkert sätt direkt mellan dig och vår Kompatibel med PCI Betalningsförmedlare (se listan på vår Säkerhetspolicy sida).

Kryptering av data

• All datakommunikation med kundinstanser skyddas med 256-bit SSL-kryptering (HTTPS).
• All intern datakommunikation mellan våra servrar skyddas också med kryptering från början till slut
• Våra servrar hålls under ständig säkerhetsuppsikt och blir alltid patchade mot de senaste SSL-sårbarheterna
• Alla våra SSL-certifikat använder 2048-bit moduler med fullständiga SHA-2 certifikatkedjor Märkning A+
• All kunddata (databasens innehåll och lagrade filer) krypteras i vila, både vid produktion och vid säkerhetskopieringar med AES-256

Nätverksförsvar

• Alla leverantörer av datacenter som används av Odoo Cloud har väldigt stora nätverksmöjligheter och har utformat sina infrastrukturer för att stå emot de största Denial-of-service (DoS) attackerna. De använder sig av förebyggande system som är både automatiska och manuella för att upptäcka och förhindra attack-trafik som ens kommer i närheten av deras fler-kontinentala nätverk, innan attackerna får chansen att störa deras tjänstetillförsel.
• Brandväggar och förebyggande system för intrång på Odoo Cloud-servrar hjälper dig att identifiera och blockera attacker som till exempel så kallade totalsökningar på lösenord.
• Administratörer för en kunddatabas kan till och med välja att ställ in andelsbegränsningar och nedkylningstid för upprepade inloggningsförsök eller konfigurera en CAPTCHA för att förmildra automatiserade totalsökningsattacker.

Skydd av mjukvara

Odoo är ett program med öppen källkod, så hela kodbasen är ständigt under uppsikt av Odoos användare och community-deltagare världen över. Rapporter om buggar från communityt är därför en viktig källa till feedback när det kommer till programmets säkerhet. Vi uppmanar utvecklare att övervaka koden och rapportera säkerhetsproblem.

Odoos F&U processer innefattar steg för att granska programmeringskod som har säkerhetsaspekter i åtanke, både för ny och för inskickade bitar kod.

Är utformad att vara säker

Odoo är utformat på ett sätt som förebygger de vanligaste säkerhetsriskerna:

• SQL-injektioner förhindras av användningen av en API på högre nivå som inte kräver några manuella SQL-frågor.
• XSS-attacker förhindras genom användningen av ett mallsystem på hög nivå som automatiskt undviker injicerad data.
• Ramverket förhindrar RPC-tillgång till privata metoder, vilket gör det svårare att introducera möjliga sårbarheter.

Se även Största OWASP-svagheter sektion för att läsa mer om hur Odoo är utformat från början till slut för att förhindra sådana säkerhetssvagheter.

Oberoende säkerhetsrevisioner

Odoo granskas regelbundet av oberoende företag som anställs av våra kunder och prospekt för att genomföra revisioner och stickprov. Odoos säkerhetsteam får resultaten från granskningarna och implementerar passande korrigerande åtgärder vid behov.

Vi kan dock inte avslöja några av dessa resultat, eftersom de är konfidentiella och tillhör uppdragsgivarna. Snälla, fråga inte ;-)

Odoo har också ett väldigt aktivt community av självständiga säkerhetsforskare, som ständigt håller uppsikt över källkoden och hjälper oss att förbättra och stärka säkerheten hos Odoo. Läs mer om vårt Säkerhetsprogram i vår Ansvarigt avslöjande .

Största OWASP-svagheter

Här är Odoos ställning när det kommer till de största säkerhetsfrågorna för webbprogram, enligt listan från Open Web Application Security Project (OWASP):

• Injektionsfel: Injektionsfel, speciellt SQL-injektion, är vanliga i webbprogram. Injektion kan uppstå när användardata skickas till en programtolk som en del av ett kommando eller en fråga. Angriparens fientliga data lurar programtolken till att utföra oönskade kommandon eller ändra datan.

  Odoo använder sig av ramverk med objekt-relationell mappning (ORM) som gör skapandet av frågor abstrakta och förhindrar SQL-injektioner som standard. Utvecklare skapar vanligtvis inte SQL-frågor manuellt, de skapas istället av ORM, vilket innebär att parametrarna alltid är korrekt utformade.

• Webbkodinjektion: XSS-brister uppstår när en applikation tar användaruppgifter och skickar den till en webbläsare utan att först validera eller kryptera innehållet. XSS låter angripare verkställa scripts i offrets webbläsare vilket kan kapa användares sessioner, vandalisera hemsidor, eventuellt introducera maskar, osv.

  Odoos ramverk undviker som standard alla uttryck som skapas i vyer och sidor, vilket förhindrar XSS. Utvecklare måste specifikt markera uttryck som "säkra" för rå inkludering i skapade sidor.

• Förfalskning av förfrågningar över flera webbplatser (CSRF): En CSRF-attack tvinga offrets webbläsare att skicka en förfalskad HTTP-förfrågan, inklusive offrets sessionscookies och övrig automatiskt inkluderad autentiseringsinformation, till en osäker webbapplikation. Detta gör det möjligt för angriparen tvinga offrets webbläsare att skapa förfrågningar som den osäkra applikationen tror är legitima förfrågningar som kommer direkt från offret.

  Odoos motor inkluderar en inbyggd skyddsmekanism mot CSRF. Detta förhindrar alla HTTP-kontrollerare från att ta emot en POST-förfrågan utan motsvarande säkerhetstoken. Detta är den rekommenderade metoden för att förhindra CSRF. Denna säkerhetstoken visas och presenteras bara när användaren verkligen har fått åtkomst till relevant formulär på hemsidan och en angripare kan inte förfalska en förfrågan utan rätt token.

• Skadliga filer som körs: Kod som är sårbar för inkludering av externa filer (RFI) låter angripare inkludera skadlig kod och data, vilket kan ha allvarliga konsekvenser som till exempel att hela servern blir komprometterad.

  Odoo blottar inte funktioner vid filinkluderingar på avstånd. Dock låter det vissa utvalda användare att anpassa funktioner genom att lägga till anpassningsbara uttryck som utvärderas av systemet. Dessa uttryck utvärderas alltid av en steriliserad sandlådemiljö som bara tillåter åtkomst till godkända funktioner.

• Osäker direkt objektreferens: En direkt objektreferens uppstår när en utvecklare exponerar en referens till ett internt implementeringsobjekt, som en fil, en katalog, en databashandling, eller nyckel som en URL eller en formulärparameter. Angripare kan manipulera de referenserna för att få åtkomst till andra objekt utan godkännande.

  Odoos åtkomstkontroll implementeras inte på användarnivå, så det ligger inga risker i att blotta referenser till interna objekt i URL:er. Angripare kan inte gå runt åtkomstkontrollagret genom att manipulera de referenserna, eftersom varje förfrågan fortfarande måste gå genom valideringslagret för dataåtkomst.

• Osäker kryptografisk lagring: Webbapplikationer använder sällan kryptografiska funktioner på rätt sätt för att skydda data och personliga handlingar. Angripare kan utnyttja svagt skyddad data för att genomföra identitetsstölder och andra brott, t.ex. kortbedrägerier.

  Odoo använder säker hashing som följer branschstandarden för användares lösenord (som standard PBKDF2 + SHA-512 med nyckelstretching) för att skydda lagrade lösenord. Det är dessutom möjligt att använda externa autentiseringssystem som OAuth 2.0 eller LDAP, för att undvika att alls behöva lagra användares lösenord lokalt.

• Osäker kommunikation: Många appar är inte noggranna nog med att kryptera nätverkstrafik när det är nödvändigt för att skydda känslig information.

  Odoo Cloud körs på HTTPS som standard. För installationer on-premise, så rekommenderas det att köra Odoo bakom en webbserver som implementerar krypterings- och proxyhanteringsförfrågningar åt Odoo, till exempel Apache, Lighttpd eller nginx. Odoos implementeringsguide inkluderar en Säkerhetschecklista för tryggare offentliga installationer.

• Underlåtenhet att begränsa åtkomsten till webbadresser: Ofta skyddar en app endast känsliga funktioner genom att förhindra att länkar eller webbadresser visas för obehöriga användare. Om angripare direkt kan få tillgång till dessa webbadresser och länkar så kan de använda den svagheten för att få tillgång till och genomföra obehöriga operationer.

  Odoos åtkomstkontroll implementeras inte på nivån av användarens gränssnitt, och säkerheten bygger inte på att gömma speciella URL:er. Angripare kan inte komma runt åtkomstkontrollagret genom att återanvända eller manipulera en URL, eftersom varje förfrågan måste gå genom dataåtkomstvalideringslagret. I de sällsynta fall där en URL ger oauktoriserad tillgång till känslig data, som till exempel speciella länkar som en kund använder för att bekräfta en beställning, så skrivs länkarna under med unika tokens och skickas bara på mejl till den tilltänkta mottagaren.

Rapporterar svagheter i säkerheten

Om du behöver rapportera en säkerhetsrisk, vänligen gör det via vår sida för avslöjande om ansvar. Dessa rapporter behandlas med hög prioritet, problemet bedöms och löses omedelbart av Odoos säkerhetsteam, i samarbete med rapportören, och rapporteras sedan på ett ansvarsfullt sätt till Odoos kunder och användare.