Bezpieczeństwo Odoo

Kopie zapasowe / Odzyskiwanie Awaryjne

• Przechowujemy 14 pełnych kopii zapasowych każdej bazy danych Odoo przez co najmniej 3 miesiące: 1/dzień przez 7 dni, 1/tydzień przez 4 tygodnie, 1/miesiąc przez 3 miesiące.
• Kopie zapasowe są zreplikowane w przynajmniej 3 różnych centrach danych, na przynajmniej 2 różnych kontynentach.
• Rzeczywiste lokalizacje naszych centrów danych są określone na naszej stronie Polityka prywatności.
• Możesz także pobrać ręczne kopie zapasowe danych na żywo w dowolnym momencie za pomocą panelu sterowania.
• Możesz skontaktować się z naszym działem pomocy technicznej, aby przywrócić dowolną z tych kopii zapasowych w swojej aktywnej bazie danych (lub dodatkowej).
• Przełączenie awaryjne sprzętu: w przypadku usług hostowanych na urządzeniach typu bare metal, gdzie możliwa jest awaria sprzętu, wdrażamy lokalną replikację hot standby, z monitorowaniem i ręczną procedurą przełączania awaryjnego, która zajmuje mniej niż 5 minut.
• Odzyskiwanie po awarii: w przypadku całkowitej awarii, gdy centrum danych jest całkowicie wyłączone przez dłuższy czas, uniemożliwiając przełączenie awaryjne do naszego lokalnego hot-standby (jak dotąd nigdy się to nie zdarzyło, jest to najgorszy scenariusz), mamy następujące cele:
  • RPO (Recovery Point Objective) = 24h. Oznacza to, że możesz stracić maksymalnie 24 godziny pracy, jeśli dane nie mogą zostać odzyskane i musimy przywrócić ostatnią codzienną kopię zapasową.
  • RTO (Recovery Time Objective) = 24h dla płatnych subskrypcji, 48h dla bezpłatnych wersji próbnych, oferty edukacyjnej, użytkowników freemium itp. Jest to czas na przywrócenie usługi w innym centrum danych, jeśli wystąpi awaria i centrum danych zostanie całkowicie wyłączone.
  • Jak to jest realizowane: aktywnie monitorujemy nasze codzienne kopie zapasowe i replikujemy je w wielu lokalizacjach na różnych kontynentach. Zautomatyzowaliśmy zaopatrzenie, aby wdrożyć nasze usługi w nowej lokalizacji hostingowej. Przywracanie danych w oparciu o nasze kopie zapasowe z poprzedniego dnia może być wykonane w ciągu kilku godzin (dla największych klastrów), z priorytetem dla płatnych subskrypcji.
    Rutynowo używamy zarówno codziennych kopii zapasowych, jak i skryptów aprowizacyjnych do codziennych operacji, więc obie części procedury odzyskiwania po awarii są cały czas testowane.

Bezpieczeństwo bazy danych

• Dane klientów są przechowywane w dedykowanej bazie danych - bez udostępniania informacji pomiędzy klientami.
• Reguły kontroli dostępu do danych wdrażają pełną izolację między bazami danych klientów działającymi na tym samym klastrze, nie jest możliwy dostęp z jednej bazy danych do drugiej.

Bezpieczeństwo haseł

• Hasła klientów są chronione za pomocą standardowego w branży szyfrowania PBKDF2+SHA512 (wzmocnione + rozciągane przez tysiące rund).
• Pracownicy Odoo nie mają dostępu do Twojego hasła i nie mogą go dla Ciebie odzyskać, jedyną opcją w przypadku jego utraty jest jego zresetowanie.
• Dane logowania są zawsze bezpiecznie przesyłane przez HTTPS.
• Administratorzy baz danych klientów mają nawet możliwość skonfigurowania ograniczenia częstotliwości oraz długości trwania czasu pomiędzy próbami logowania.
• Polityka haseł: administratorzy bazy danych mają wbudowaną możliwość wymuszania minimalnej długości haseł. Inne reguły dotyczące haseł jak wymagane rodzaje znaków nie są domyślnie wspierane, ponieważ udowodniono że są kontrproduktywne. Patrz np. [Shay et al. 2016], oraz NIST SP 800-63b.

Dostęp personelu

• Personel helpdesku Odoo może zalogować się na Twoje konto, aby uzyskać dostęp do ustawień powiązanych z Twoim zgłoszeniem wsparcia. Aby to zrobić korzystają z własnych pracowniczych loginów, a nie z Twojego hasła (którego nie mają możliwości znać).
• Specjalny dostęp pracowniczy usprawnia efektywność i bezpieczeństwo: pracownicy helpdesku mogą natychmiastowo odtworzyć problem z którym się borykasz, nigdy nie musisz udostępniać swojego hasła, a my możemy przeprowadzić audyt i kontrolować działania personelu osobno.
• Nasi pracownicy helpdesku starają się w jak największym stopniu szanować Twoją prywatność i uzyskują dostęp tylko do plików i ustawień niezbędnych do zdiagnozowania i rozwiązania Twojego problemu.

Bezpieczeństwo systemu

• Wszystkie systemy Odoo Cloud działają na wzmocnionych dystrybucjach Linuxa z aktualnymi poprawkami bezpieczeństwa.
• Instalacje są doraźne i minimalne, aby ograniczyć liczbę usług, które mogą zawierać luki w zabezpieczeniach (na przykład brak stosu PHP/MySQL).
• Tylko kilkoro zaufanych inżynierów Odoo ma zezwolenie na zdalne zarządzanie serwerami - dostęp jest możliwy jedynie przy użyciu szyfrowanego, osobistego klucza SSH, z komputera z pełnym szyfrowaniem dysku.

Fizyczne bezpieczeństwo

Serwery Odoo Cloud są hostowane w zaufanych centrach danych w różnych regionach świata (np. OVH, Google Cloud), i wszystkie muszą spełniać nasze kryteria bezpieczeństwa fizycznego:

• Ograniczony obszar, fizyczny dostęp tylko dla autoryzowanych pracowników centrum danych.
• Kontrola fizycznego dostępu z kartami dostępu lub zabezpieczeniami biometrycznymi.
• Kamery monitorujące lokalizacje centrów danych 24/7.
• Służby ochroniarskie na miejscu 24/7.

Bezpieczeństwo kart kredytowych

• Nigdy nie przechowujemy informacji o kartach kredytowych wewnątrz naszych systemów.
• Informacje o Twojej karcie kredytowej są zawsze bezpiecznie przesyłane bezpośrednio między Tobą a naszymi podmiotami obsługującymi płatności zgodnymi ze standardem PCI (zobacz pełną listę na stronie Polityka prywatności ).

Szyfrowanie danych

• Cała komunikacja danych z instancjami klienta jest chroniona najnowocześniejszym 256-bitowym szyfrowaniem SSL (HTTPS).
• Cała wewnętrzna komunikacja między naszymi serwerami jest również chroniona za pomocą najnowocześniejszego szyfrowania (SSH).
• Nasze serwery znajdują się pod ścisłą kontrolą bezpieczeństwa i są zawsze zabezpieczane przed najnowszymi lukami w zabezpieczeniach, ciesząc się oceną SSL klasy A przez cały czas.
• Wszystkie nasze certyfikaty SSL wykorzystują solidny 2048-bitowy moduł z pełnymi łańcuchami certyfikatów SHA-2.
• Wszystkie dane klienta (zawartość bazy danych i przechowywane pliki) są szyfrowane w spoczynku, zarówno w produkcji, jak i w kopiach zapasowych (AES-128 lub AES-256).

Ochrona sieci

• Wszyscy dostawcy centrów danych wykorzystywani przez Odoo Cloud mają bardzo dużą przepustowość sieci i zaprojektowali swoją infrastrukturę tak, aby wytrzymać największe ataki typu Distributed Denial of Service (DDoS). Ich automatyczne i ręczne systemy przeciwdziałające atakom mogą wykrywać i przekierowywać ruch związany z atakami na skraju ich wielokontynentalnych sieci, zanim będą one miały szansę zakłócić dostępność usług.
• Zapory sieciowe i systemy zapobiegania włamaniom na serwerach Odoo Cloud pomagają wykrywać i blokować zagrożenia, takie jak ataki na hasła typu brute-force.
• Administratorzy baz danych klientów mają nawet możliwość skonfigurowania ograniczenia częstotliwości oraz czasu oczekiwania dla powtarzających się prób logowania.

Bezpieczeństwo oprogramowania

Odoo jest oprogramowaniem typu open source, więc cała baza kodu jest stale pod kontrolą użytkowników i współpracowników Odoo na całym świecie. Zgłaszane przez społeczność błędy są zatem jednym z ważnych źródeł feedbacków dotyczących bezpieczeństwa. Zachęcamy deweloperów do audytowania kodu i zgłaszania błędów związanych z bezpieczeństwem.

Procesy badawczo-rozwojowe Odoo obejmują etapy przeglądu kodu, które obejmują aspekty bezpieczeństwa, zarówno dla nowych, jak i współtworzonych fragmentów kodu.

Zaprojektowany z myślą o bezpieczeństwie

Odoo zostało zaprojektowane w sposób, który zapobiega wprowadzaniu najbardziej powszechnych luk w zabezpieczeniach:

• Użycie interfejsu API wyższego poziomu, zapobiega wstrzykiwaniu SQL, ponieważ ten nie wymaga ręcznych zapytań SQL.
• Atakom XSS zapobiega zastosowanie wysokopoziomowego systemu szablonów, który automatycznie unika wstrzykiwania danych.
• Framework zapobiega dostępowi RPC do prywatnych metod, utrudniając wprowadzenie podatności na nadużycia.

Zobacz także sekcję Najważniejsze luki w zabezpieczeniach OWASP aby zobaczyć jak Odoo jest zaprojektowane od podstaw, żeby zapobiegać pojawianiu się luk w zabezpieczeniach.

Niezależne audyty bezpieczeństwa

Odoo jest regularnie kontrolowane przez niezależne firmy, które są wynajmowane przez naszych klientów i potencjalnych klientów do przeprowadzania audytów i testów penetracyjnych. Zespół ds. bezpieczeństwa Odoo otrzymuje wyniki i w razie potrzeby podejmuje odpowiednie działania naprawcze.

Nie możemy jednak ujawnić żadnych z tych wyników, ponieważ są one poufne i należą do osób zlecających. Proszę o nie nie pytać ;-)

Odoo ma również bardzo aktywną społeczność niezależnych badaczy zabezpieczeń, którzy stale monitorują kod źródłowy i pracują z nami nad ulepszeniem i wzmocnieniem bezpieczeństwa Odoo. Nasz Program Bezpieczeństwa jest opisany na stronie Odpowiedzialne Ujawnianie Informacji .

Najważniejsze luki w zabezpieczeniach OWASP

Oto, gdzie Odoo znajduje się na liście najważniejszych kwestii związanych z bezpieczeństwem aplikacji internetowych, zgodnie z listą Open Web Application Security Project (OWASP):

• Wstrzyknięcia (Injection flaws): Wstrzyknięcia, zwłaszcza wstrzyknięcia SQL, są częste w aplikacjach internetowych. Wstrzyknięcie następuje, gdy dane dostarczone przez użytkownika są wysyłane do interpretera jako część polecenia lub zapytania. Wrogie dane atakującego nakłaniają interpreter do wykonania niezamierzonych poleceń lub zmiany danych.

  Odoo opiera się na frameworku mapowania obiektowo-relacyjnego (ORM), który abstrahuje tworzenie zapytań i domyślnie zapobiega wstrzyknięciom SQL. Programiści zwykle nie tworzą zapytań SQL ręcznie, są one generowane przez ORM, a parametry są zawsze odpowiednio unikane.

• Cross Site Scripting (XSS): Wady XSS występują zawsze, gdy aplikacja pobiera dane dostarczone przez użytkownika i wysyła je do przeglądarki internetowej bez uprzedniego sprawdzenia poprawności lub zakodowania tej zawartości. XSS pozwala atakującym na wykonywanie skryptów w przeglądarce ofiary, które mogą przejąć sesje użytkownika, uszkodzić strony internetowe, ewentualnie wprowadzić robaki itp.

  Framework Odoo domyślnie ucieka przed wszystkimi wyrażeniami renderowanymi do widoków i stron, zapobiegając XSS. Programiści muszą specjalnie oznaczyć wyrażenia jako "bezpieczne", aby można je było włączyć do renderowanych stron.

• Cross Site Request Forgery (CSRF): Atak CSRF zmusza zalogowaną przeglądarkę ofiary do wysłania fałszywego żądania HTTP, w tym pliku cookie sesji ofiary i wszelkich innych automatycznie dołączonych informacji uwierzytelniających, do podatnej aplikacji internetowej. Pozwala to atakującemu zmusić przeglądarkę ofiary do generowania żądań, które podatna aplikacja uważa za prawidłowe żądania od ofiary.

  Silnik strony Odoo zawiera wbudowany mechanizm ochrony CSRF. Uniemożliwia on kontrolerowi HTTP otrzymanie żądania POST bez odpowiedniego tokena zabezpieczającego. Jest to zalecana technika zapobiegania atakom CSRF. Ten token bezpieczeństwa jest znany i obecny tylko wtedy, gdy użytkownik rzeczywiście uzyskał dostęp do odpowiedniego formularza strony internetowej, a atakujący nie może sfałszować żądania bez niego.

• Uruchamianie złośliwych plików: Kod podatny na zdalne dołączanie plików (RFI) pozwala atakującym na dołączenie wrogiego kodu i danych, co prowadzi do niszczycielskich ataków, takich jak całkowite przejęcie kontroli nad serwerem.

  Odoo nie pozwala użytkownikom na zdalne dołączanie plików, ale umożliwia uprzywilejowanym użytkownikom dostosowywanie funkcji poprzez dodawanie niestandardowych wyrażeń, które są oceniane przez system. Te wyrażenia są zawsze oceniane przez środowisko sandbox i pozbawiane błędów, co pozwala na dostęp tylko do dozwolonych funkcji.

• Niezabezpieczone bezpośrednie odwołanie do obiektu: Bezpośrednie odwołanie do obiektu występuje, gdy programista ujawnia odwołanie do wewnętrznego obiektu implementacji, takiego jak plik, katalog, rejestr bazy danych lub klucz, jako parametr adresu URL lub formularza. Atakujący mogą manipulować tymi odniesieniami, aby uzyskać dostęp do innych obiektów bez autoryzacji.

  Kontrola dostępu w Odoo nie jest zaimplementowana na poziomie interfejsu użytkownika, więc nie ma ryzyka związanego z ujawnianiem odwołań do wewnętrznych obiektów w adresach URL. Atakujący nie mogą obejść warstwy kontroli dostępu poprzez manipulowanie tymi odniesieniami, ponieważ każde żądanie nadal musi przejść przez warstwę walidacji dostępu do danych.

• Niezabezpieczone przechowywanie kryptograficzne: Aplikacje internetowe rzadko wykorzystują funkcje kryptograficzne do ochrony danych i danych logowania. Atakujący wykorzystują słabo chronione dane do kradzieży tożsamości i innych przestępstw, takich jak oszustwa związane z kartami kredytowymi.

  Odoo korzysta ze standardowego bezpiecznego haszowania haseł użytkowników (domyślnie PBKDF2 + SHA-512, z rozciąganiem klucza) w celu ochrony przechowywanych haseł. Możliwe jest również korzystanie z zewnętrznych systemów uwierzytelniania, takich jak OAuth 2.0 lub LDAP, aby uniknąć przechowywania haseł użytkowników lokalnie.

• Niezabezpieczona komunikacja: Aplikacje często nie szyfrują ruchu sieciowego, gdy konieczna jest ochrona poufnej komunikacji.

  Odoo Cloud domyślnie działa w protokole HTTPS. W przypadku instalacji lokalnych zaleca się uruchomienie Odoo za serwerem WWW implementującym szyfrowanie i proxy żądań do Odoo, na przykład Apache, Lighttpd lub nginx. Przewodnik wdrażania Odoo zawiera listę kontrolną dla bezpieczniejszych wdrożeń publicznych.

• Brak ograniczenia dostępu do adresów URL: Często aplikacja chroni wrażliwe funkcje tylko poprzez uniemożliwienie wyświetlania linków lub adresów URL nieautoryzowanym użytkownikom. Atakujący mogą wykorzystać tę słabość, aby uzyskać dostęp i wykonać nieautoryzowane operacje, uzyskując bezpośredni dostęp do tych adresów URL.

  Kontrola dostępu do Odoo nie jest zaimplementowana na poziomie interfejsu użytkownika, a bezpieczeństwo nie opiera się na ukrywaniu specjalnych adresów URL. Atakujący nie mogą obejść warstwy kontroli dostępu poprzez ponowne wykorzystanie lub manipulowanie dowolnym adresem URL, ponieważ każde żądanie nadal musi przejść przez warstwę walidacji dostępu do danych. W rzadkich przypadkach, gdy adres URL zapewnia nieuwierzytelniony dostęp do wrażliwych danych, takich jak specjalne adresy URL używane przez klientów do potwierdzenia zamówienia, adresy te są cyfrowo oznaczane za pomocą unikalnych tokenów i wysyłane pocztą elektroniczną tylko do zamierzonego odbiorcy.

Zgłaszanie luk w zabezpieczeniach

Jeśli chcesz zgłosić lukę w zabezpieczeniach, możesz to zrobić na stronie odpowiedzialnego ujawniania informacji. Zgłoszenia te są traktowane priorytetowo, problem jest natychmiast oceniany i rozwiązywany przez zespół ds. bezpieczeństwa Odoo we współpracy ze zgłaszającym, a następnie ujawniany w odpowiedzialny sposób klientom i użytkownikom Odoo.