Odoo zabezpečení

Zálohování / obnovení po havárii

• Spravujeme 14 plných záloh pro každou Odoo databázi po dobu až 3 měsíců: denní zálohy po dobu 7 dní, týdenní zálohy po dobu 4 týdnů a měsíční zálohy po dobu 3 měsíců.
• Zálohy jsou replikovány do alespoň 3 různých datových center, napříč minimálně 2 různými kontinenty.
• Aktuální lokace našich datových center jsou specifikovány v našich Zásadami ochrany osobních údajů.
• Také si můžete kdykoliv stáhnout manuální zálohu vašich produkčních dat z ovládacího panelu vaší instance.
• Můžete kontaktovat naši zákaznickou podporu, aby vám pomohla obnovit kteroukoliv z těchto záloh na vaši produkční databázi (případně mimo).
• Selhání hardwaru: pro služby, které hostujeme na "bare-metal" fyzických serverech, kde může dojít k selhání hardwaru, máme nasazeny místní repliky, kde díky neustálému monitorování můžeme spustit proces převzetí služeb za méně než 5 minut.
• Obnova po havárii: v případě katastrofického selhání, tedy v případě kdy je datové centrum zcela nedostupné po delší časové období a neumožňuje přesměrování na blízké zdroje (což se zatím nikdy nestalo, takže je to vážně plán na nejhorší možný případ), máme následující cíle:
  • RPO (Cíl bodu obnovy) = 24h. To znamená, že v nejhorším případě ztratíte maximálně 24 hodin práce, a to pouze pokud tato data z nějakého důvodu nemůžeme zachránit a musíme obnovit vaši poslední denní zálohu.
  • RTO (Cíl času obnovy) = 24h pro platící předplatitele, 48h pro zkušební verze zdarma, nabídky pro vzdělávací sektor, freemium uživatele, atd. Toto je čas, který potřebujeme k obnově služeb v jiném datovém centru, v případě že nastane selhání a dané datacentrum je kompletně nedostupné.
  • Jak toho dosáhneme: Aktivně monitorujeme naše denní zálohy a replikujeme je ve více lokacích na různých kontinentech. také máme automatizované možnosti jak nasadit naše služby na nových hostingových lokacích. Obnova dat na záloze z předcházejícího dne tak může být provedena během pár hodin (pro naše největší klustry), s prioritou pro platící zákazníky.
    Denní zálohy a automatické skripty používáme rutinně, na denní bázi, takže obě tyto části plánu obnovy po havárii testujeme prakticky neustále.

Zabezpečení databází

• Zákaznická data jsou ukládána v dedikované databázi - nehrozí žádné sdílení dat mezi zákazníky.
• Naše pravidla pro kontrolu přístupů k datům zaručují kompletní izolaci mezí zákaznickými databázemi, které běží na stejném klastru. Žádný přístup z jedné databáze do druhé není možný.

Zabezpečení hesel

• Zákaznická hesla jsou chráněna dle standardů v oboru PBKDF2+SHA512 šifrováním (používá "salt" + protahuje heslo na tísíce opakování).
• Odoo personál nemá přístup k vašemu heslu a nemůže pro vás zjistit vaše heslo. V případě ztráty hesla je jedinou možností jej resetovat.
• Přihlašovací údaje jsou vždy bezpečně posílány prostředníctvím HTTPS.
• Customer database administrators even have the option to nastavit omezení četnosti (rate limiting) a časovou prodlevu pro opakované pokusy o přihlášení.
• Password policies: database administrators have a built-in setting for enforcing a minimum user password length. Other password policies like required character classes are not supported by default because they have been proven counter-productive. See e.g. [Shay et al. 2016]), as well as NIST SP 800-63b.

Přístup Odoo zaměstnanců

• Odoo personál zodpovědný za zákaznickou podporu se může přihlásit do vašeho účtu v rámci podpory s vaším problémem. Za tímto účelem používají své vlastní zaměstnanecké přístupy, nikoliv vaše heslo (které nemohou žádným způsobem zjistit).
• Tento speciální zaměstnanecký přístup zlepšuje efektivnost a zabezpečení při řešení problémů. Díky němu může Odoo personál okamžitě reprodukovat problém tak, jak ho vidíte vy, a přitom nikdy nemusíte sdílet své heslo. Zároveň nám to umožňuje auditovat aktivity, které náš personál udělal!
• Náš personál zákaznické podpory vždy respektuje vaše soukromí, jak jen to je možné. Proto přistupuje pouze k souborům a nastavením nezbytně nutným pro diagnostiku a vyřešení vašeho problému.

Zabezpečení systému

• Všechny Odoo cloud servery použivají specifické Linuxové distribuce s důrazem na zabezpečení a s aktuálními bezpečnostními záplatami.
• Instalace jsou provozovány na ad-hoc bázi a v minimálním režimu, aby se redukoval počet služeb, které mohou obsahovat zranitelnosti (což znamená např. žádné PHP/MySQL služby).
• Pouze několik proveřených Odoo techniků má prověrku ke vzdálené správě serverů - a přístup je možný pouze s použitím zašifrovaného, osobního SSH klíče a to z počítače, který disponuje kompletním zašifrováním úložiště.

Fyzické zabezpečení

Odoo Cloud servery jsou hostovány v důvěryhodných datových centerech v různých regionech světa (např. OVH, Google Cloud) a všechny musí překonávat naše kritéria fyzického zabezpečení:

• Omezený přístup, fyzicky dostupný pouze pro autorizované zaměstnance datového centra.
• Osobní kontrola přístupu skrze bezpečnostní zaměstnanecké karty nebo biometrické zabezpečení.
• 24/7 sledování datového centra skrze bezpečnostní kamery.
• 24/7 přítomnost ochranky v datovém centru.

Zabezpečení platebních karet

• Nikdy neukládáme vaše platební informace v našich vlastních systémech.
• Vaše platební informace jsou vždy bezpečně přenášeny mezi vámi a našimi  PCI-standardizovanýmiplatebními bránami (podívejte se na naší Zásadami ochrany osobních údajů stránku).

Šifrování dat

• Veškerá datová komunikace vůči zákaznickým instancím je chráněna špičkovým 256-bitovým SSL šifrováním (HTTPS).
• Veškerá interní datová komunikace mezi našimi servery je také chráněna špičkovým šifrováním (SSH).
• Naše servery držíme pod přísným dohledem a vždy je udržujeme v aktuálním stavu před nejnovějšími SSL zranitelnostmi, což nám dlouhodobě zajišťuje známku A v hodnocení SSL zabezpečení.
• Naše SSL certifikáty používají robustní 2048-bitový modulus s kompletním řetězcem SHA-2 certifikátů.
• Veškerá zákaznická data (jak obsah databáze, tak uložené soubory) jsou šifrována v lokální "at rest" podobě, jak na produkčním prostředí tak na zálohách (AES-128 nebo AES-256).

Síťové zabezpečení

• Všichni poskytovatelé datových služeb, používaných pro Odoo Cloud, mají značné síťové kapacity a jejich infrastruktura je specificky vytvořena tak, aby odolala největším útokům distribuovaného odepření služby (DDoS). Jejich automatické a manuální mitigační systémy dokážou odklonit síťový provoz útočníka do okrajových částí své sítě dříve, než dokáží odepřít dostupnost služeb.
• Firewally a systémy na prevenci vniknutí na našich Odoo Cloud serverech nám pomáhají včas detekovat a blokovat hrozby, jako třeba útoky hrubou silou na zjištění hesla.
• Customer database administrators even have the option to nastavit omezení četnosti (rate limiting) a čas prodlevy mezi opakovanými pokusy o přihlášení.

Zabezpečení aplikace

Odoo je open source software, takže celý zdrojový kód je průběžně sledován Odoo uživateli a přispěvateli. Hlášení bugů od naší komunity je proto také důležitý zdroj zpětné vazby, i co se týče zabezpečení. Proto podporujeme vývojáře v tom, aby auditovali náš kód a hlásili bezpečnostní problémy.

Odoo R&D proces používá kroky revize kódu, které zahrnují bezpečnostní aspekty, ať už pro zcela nové nebo upravené kusy kódu od našich přispěvatelů.

Navrženo s důrazem na zabezpečení

Odoo je navrženo způsobem, který předchází nejčastějším bezpečnostním hrozbám:

• SQL injekcím je předcházeno pomocí vysokoúrovňové API, která nevyžaduje používání manuálních SQL dotazů.
• XSS útokům je předcházeno pomocí šablonovacího systému, který automaticky ošetřuje všechna vložená data.
• Odoo framework znemožňuje RPC přístup pro "private" modifikátory přístupu, což jej činí značně odolnějším vůči zranitelnostem.

Podívejte se také na sekci hlavní OWASP zranitelnosti , abyste viděli jak je Odoo od základu navrženo aby předcházelo těmto bezpečnostím hrozbám.

Nezávislé bezpečnostní audity

Odoo je pravidelně auditováno nezávislými společnostmi, najatými našimi zákazníky, za účelem kontroly zabezpečení a penetračního testování. Odoo bezpečnostní tým obdržuje výsledky těchto testů a provádí patřičná nápravná opatření kdykoliv je to zapotřebí.

Bohužel nemůžeme zveřejnit ani sdílet jakékoliv z těchto výsledků, protože jsou důvěrné a patří zadavateli. Prosíme o pochopení ;-)

Odoo má také velmi aktivní komunitu nezávislých bezpečnostních analytiků, kteří průběžně sledují naši práci a zdrojový kód a tím nám pomáhají vylepšovat zabezpečení Odoo. Naše politika hlášení chyb je k dispozici na naší stránce pro zodpovědné nahlášení stránce.

hlavní OWASP zranitelnosti

Zde je seznam, jak Odoo nakládá s nejvážnějšímí bezpečnostními hrozbami pro webové aplikace, stanovenými dle Open Web Application Security Project (OWASP):

• Chyby vložení kódu: Tzv. "Injection" chyby, obzvláště "SQL injekce", jsou relativně běžné mezi webovými aplikacemi. Ke vložení škodlivého kódu dochází ve chvíli, kdy jsou uživatelem poskytnutá data poslána službě v rámci příkazu nebo požadavku. Útočníkův kód pak přiměje službu spustit nežádoucí příkaz nebo jiným způsobem modifikovat data.

  Odoo spolehá na své objektově relační mapování (ORM), které abstrahuje strukturu požadavků a v základu znemožňuje provést SQL injekce. Vývojáři také běžně nevolají SQL požadavky napřímo, ale o jejich generování se stará ORM samotné, které vždy vstupní parametry správně očiští a interpretuje.

• "Cross Site Scripting" (XSS): XSS chyby se objevují ve chvíli, kdy aplikace vezme data, která do ní uživatel vložil, a přepošle je prohlížeči, aniž by první zvalidovala či zakódovala jejich obsah. XSS umožňuje útočníkovi např. spouštet skripty v prohlížeči oběti, které mohou vyústit v převzetí kontroly nad webovou relací uživatele.

  Odoo framework v základu ošetřuje všechny datové výstupy ze zobrazení a stránek, a tím zamazuje XSS útoku. V případě, že chce vývojář zobrazit zdrojový obsah datové zprávy do vyrenderované stránky, musí specificky použít parametr "safe".

• Cross Site Request Forgery (CSRF):CSRF útok přinutí prohlížeč přihlášeného uživatele zaslat podvržený HTTP požadavek vůči zranitelné aplikaci, včetně cookie informací oběti a jakýchkoliv dalších autentikačních informací. Toto umožní útočníkovi zasílat zranitelné aplikaci požadavky, o kterých si bude myslet, že jsou legitimními požadavky oběti.

  Jádro Odoo má vestavěný ochranný mechanismus proti CSRF. Ten znemožňuje jakémukoliv HTTP řadiči obdržet POST požadavek bez odpovídajících bezpečnostních tokenů. Toto je standardní, doporučená ochrana proti CSRF útokům. Tento bezpečnostní token je znám a přítomen pouze, pokud uživatel doopravdy použil požadovaný webový formulář a útočník bez něj nemůže padělat webový požadavek.

• Spuštění škodlivých souborů: Kód náchylný na tzv. "RFI" útok (remote-file inclusion) umožní útočníkovi vložit škodliví kód nebo data a dosáhnout tak devastujících výsledků, jako například celkové převzetí kontroly nad serverem.

  Odoo nevystavuje své funkce vůči RFI útoku. Zároveň ale umožňuje privilegovaným uživatelům upravovat funkcionalitu skrze přidávání vlastních funkcí, které jsou poté vyhodnoceny systémem. Tyto funkce jsou vždy spouštěny v "Sandbox" prostředí, které umožní přístup pouze oprávněným funkcím.

• Nezabezpečený přímý odkaz na objekt: Přímý odkaz na objekt nastane ve chvíli, kdy vývojář umožní přístup k internímu objektu, jako třeba soubor, složka nebo databázový záznam, v rámci URL a nebo parametru formuláře. Útočníci pak mohou zneužít tohoto odkazu k zpřístupnění dalších objektů bez potřebné autorizace.

  Odoo řízení přístupů není implementováno na úrovní uživatelského rozhraní, a proto zde není žádné riziko odhalení odkazů na interní objekty v rámci URL. Útočníci nemohou obejít úroven řízení přístupů skrze manipulaci těchto odkazů, protože každý požadavek stejně musí projít skrze vrstvu kontroly přístupů.

• Nedostatečné šifrování úložiště: Webové aplikace málokdy používají vhodné šifrování dat a přístupových údajů. Útočníci mohou použít slabě zabezpečená data k provedení krádeží identity a dalším zločinům, jako třeba podvody s platebními kartami.

  Odoo se drží norem v oboru co se týče zabezpečení uživatelských hesel (výchozí je PKFDB2 + SHA-512 s protahováním klíče) k ochraně uložených hesel. Také je možné využít externí autentikační služby, jako třeba OAuth 2.0 nebo LDAP, aby se zamezilo ukládání uživatelských hesel na lokálním úložišti.

• Nezabezpečená komunikace: Aplikace často nešifrují síťovou komunikaci, ani ve chvíli, kdy je potřeba chránit citlivá data.

  Odoo Cloud používá HTTPS jako výchozí standard. Pro instalace na vlastních serverech je doporučeno spouštět Odoo v režimu za webovým serverem, který implementuje šifrování a přeposílá požadavky do Odoo, jako například Apache, Lighttpd nebo Nginx. Manuál pro nasazení Odoo zahrnuje seznam pokynů pro bezpečnější nasazení.

• Selhání v omezení URL přístupu: Aplikace často chrání citlivé funkcionality pouze pomocí schování odkazů nebo zamezení přístupu k URL neautorizovaným uživatelům. Útočníci ale stále mohou využít tuto slabinu k zpřístupnění a zneužití této URL napřímo.

  Odoo řízení přístupů není implementováno na úrovní uživatelského rozhraní a zabezpečení tedy nezávisí na schovávání speciálních URL. Útočníci nemohou obejít úroven řízení přístupů skrze přepoužívání či manipulaci s URL, protože každý požadavek stejně musí jít skrze vrstvu kontroly přístupů. Ve vzácných případech, kdy URL poskytuje neautorizovaný přístup k citlivým datům, jako například unikátní URL pro potvrzení zákaznických objednávek, jsou tyto URL digitálně podepsané unikátními tokeny a poslány skrze email pouze zamýšleným koncovým adresátům.

Hlášení bezpečnostních rizik

Pokud potřebujete nahlásit zranitelnost nebo bezpečnostní problém, navštivte naší stránku pro zodpovědné nahlášeníTěmto hlášením věnujeme vysokou prioritu a náš Odoo bezpečnostní tým je okamžitě vyhodnocuje a řeší, ve spolupráci s původním podavatelem. Poté vhodným způsobem informujeme své Odoo zákazníky a uživatele.