Odoo Безпека

Резервне копіювання / Відновлення після аварій

• Ми зберігаємо 14 повних резервних копій кожної бази даних Odoo протягом принаймні 3 місяців: 1/день протягом 7 днів, 1/тиждень протягом 4 тижнів, 1/місяць протягом 3 місяців.
• Резервні копії дублюються в щонайменше 3 різних дата-центрах, на щонайменше 2 різних континентах.
• Реальні місцезнаходження наших дата-центрів вказані у нашому Політика конфіденційності.
• Ви також можете завантажувати ручні резервні копії ваших живих даних в будь-який час, використовуючи панель керування.
• Ви можете звернутися до нашої служби підтримки, щоб відновити будь-який з цих бекапів у вашій активній базі даних (або додатково).
• Відмова апаратного забезпечення: для служб, розміщених на «голому металі», де можливий збій апаратного забезпечення, ми впроваджуємо реплікацію локального гарячого резерву з моніторингом і ручною процедурою перемикання після відмови, яка займає менше 5 хвилин.
• Аварійне відновлення: у разі повної катастрофи, коли центр обробки даних повністю не працюватиме на тривалий період, запобігаючи переключенню збоїв на наш локальний гарячий резерв (поки що такого не траплялося, це найгірший варіант), ми маємо такі цілі:
  • RPO (Recovery Point Objective) = 24h. Це означає, що ви можете втратити максимум 24 години роботи, якщо дані не можна відновити і нам потрібно відновити ваш останній щоденний резервний копію.
  • RTO (Recovery Time Objective) = 24 години для платних підписок, 48 годин для безкоштовних пробних версій, освітніх пропозицій, користувачів freemium, тощо. Це час для відновлення сервісу в іншому дата-центрі, якщо стається катастрофа і дата-центр повністю вийшов з ладу.
  • Як це досягається: ми активно контролюємо наші щоденні резервні копії, які реплікуються в кількох місцях на різних континентах. У нас є автоматизоване розгортання для розгортання наших послуг в новому місці хостингу. Відновлення даних на основі наших резервних копій попереднього дня потім може бути зроблено за кілька годин (для найбільших кластерів), з пріоритетом на платні підписки.
    Ми регулярно використовуємо як щоденні резервні копії, так і скрипти розгортання для щоденних операцій, тому обидві частини процедури відновлення після аварії постійно тестуються.

Безпека бази даних

• Дані клієнтів зберігаються у спеціалізованій базі даних - немає обміну даними між клієнтами.
• Правила контролю доступу до даних забезпечують повну ізоляцію між базами даних клієнтів, що працюють на одному кластері, доступ з однієї бази даних до іншої неможливий.

Безпека пароля

• Паролі клієнтів захищені за допомогою шифрування за стандартом промисловості PBKDF2+SHA512 (salted + розтягнуті протягом тисяч раундів).
• Персонал Odoo не має доступу до вашого паролю і не може його відновити для вас, єдиною опцією, якщо ви його втратите, є його скидання.
• Дані для входу завжди передаються безпечно через HTTPS.
• Адміністратори бази даних клієнтів навіть мають можливість  налаштуйте обмеження швидкості and тривалість відновлення для повторних спроб входу.
• Політика паролів: адміністратори баз даних мають вбудоване налаштування для впровадження мінімальної довжини паролю користувача. Інші політики паролів, такі як обов'язкові класи символів, за замовчуванням не підтримуються, оскільки вони виявилися контрпродуктивними. Див. наприклад [Shay та ін. 2016]), а також NIST SP 800-63b.

Доступ персоналу

• Персонал служби підтримки Odoo може увійти у ваш акаунт, щоб отримати доступ до налаштувань, пов'язаних з вашим питанням підтримки. Для цього вони використовують свої власні спеціальні службові облікові дані, а не ваш пароль (який вони ніяк не можуть знати).
• Цей спеціальний доступ для персоналу покращує ефективність та безпеку: вони можуть негайно відтворити проблему, з якою ви стикаєтесь, вам ніколи не потрібно ділитися своїм паролем, і ми можемо аудитувати та контролювати дії персоналу окремо!
• Наш персонал служби підтримки прагне поважати вашу приватність максимально можливо і звертається лише до файлів та налаштувань, які необхідні для діагностики та вирішення вашої проблеми.

Безпека системи

• Усі сервери Odoo Cloud працюють на укріплених дистрибутивах Linux з останніми патчами безпеки.
• Установки є спрямованими і мінімізованими, щоб обмежити кількість служб, які можуть містити вразливості (наприклад, немає стеку PHP/MySQL).
• Лише кілька довірених інженерів Odoo мають дозвіл на віддалене керування серверами - і доступ можливий тільки за допомогою зашифрованої персональної пари ключів SSH, з комп'ютера із повним дисковим шифруванням.

Фізична безпека

Сервери Odoo Cloud розташовані в надійних дата-центрах у різних регіонах світу (наприклад, OVH, Google Cloud), і вони всі повинні перевищувати наші критерії фізичної безпеки:

• Обмежений периметр, фізично доступний тільки для авторизованих співробітників дата-центру.
• Фізичний контроль доступу за допомогою бейджів безпеки або біометричної безпеки.
• Камери безпеки, що моніторять розташування дата-центру 24/7.
• Персонал безпеки на місці 24/7.

Безпека кредитної картки

• Ми ніколи не зберігаємо інформацію про кредитну картку на наших власних системах.
• Інформація про вашу кредитну картку завжди передається безпечно безпосередньо між вами та нашим PCI-Сумісний платіжні еквайери (див. список на нашому Політика конфіденційності сторінка).

Шифрування даних

• Усі дані для комунікацій з клієнтськими інстанціями захищені сучасним 256-бітним SSL шифруванням (HTTPS).
• Усі внутрішні комунікації даних між нашими серверами також захищені за допомогою сучасного шифрування (SSH).
• Наші сервери знаходяться під суворим контролем безпеки і завжди патчуються проти останніх вразливостей SSL, насолоджуючись Категорія A Рейтинги SSL у будь-який час.
• Усі наші SSL-сертифікати використовують надійний 2048-бітний модуль з повними ланцюжками сертифікатів SHA-2.
• Всі дані клієнтів (вміст бази даних та збережені файли) зашифровані у режимі очікування, як у виробництві, так і в резервних копіях (AES-128 або AES-256)

Захист мережі 

• Всі провайдери дата-центрів, що використовуються Odoo Cloud, мають дуже великі мережеві потужності і розробили свою інфраструктуру, щоб витримати найбільші атаки Distributed Denial of Service (DDoS). Їхні автоматичні та ручні системи пом'якшення можуть виявляти та перенаправляти атакуючий трафік на краю їхніх багатоконтинентальних мереж, до того як у ньому з'явиться можливість порушити доступність сервісу.
• Брандмауери та системи запобігання вторгненням на серверах Odoo Cloud допомагають виявляти та блокувати загрози, такі як атаки на паролі з методом грубої сили.
• Адміністратори бази даних користувачів навіть мають можливість налаштуйте обмеження швидкості та тривалість перерви для повторних спроб входу.

Безпека програмного забезпечення

Odoo є системою з відкритим кодом, тому весь код неперервно перевіряється користувачами Odoo та співавторами по всьому світу. Таким чином, повідомлення про помилки від спільноти є одним із важливих джерел відгуку щодо безпеки. Ми заохочуємо розробників проводити аудит коду та повідомляти про проблеми з безпекою.

Процеси R&D в Odoo мають етапи перегляду коду, які включають аспекти безпеки, для нових та внесених частин коду.

Безпечний за концепцією

Odoo розроблено таким чином, що запобігає виникненню більшості поширених проблем з безпекою:

• SQL-ін'єкції запобігаються за допомогою використання API вищого рівня, яке не вимагає ручного введення SQL-запитів.
• Атаки XSS запобігаються за допомогою високорівневої системи шаблонів, яка автоматично замінює внесені дані.
• Фреймворк запобігає RPC доступу до приватних методів, ускладнюючи введення експлуатованих вразливостей.

Дивіться також OWASP Топ Вразливості section to see how Odoo є спроектованою з нуля, щоб запобігти появі таких вразливостей.

Незалежні аудити безпеки

Odoo регулярно перевіряється незалежними компаніями, які наймають наші клієнти та потенційні клієнти для проведення аудитів та тестів на проникнення. Команда безпеки Odoo отримує результати та вживає відповідних коригувальних заходів, коли це необхідно.

Ми не можемо розкрити жодних з цих результатів, оскільки вони є конфіденційними та належать комісіярам. Будь ласка, не питайте ;-)

Odoo також має дуже активну спільноту незалежних дослідників з питань безпеки, які постійно контролюють вихідний код і працюють з нами над покращенням та посиленням безпеки Odoo. Наша Програма Безпеки описана на нашому Відповідальне Розкриття сторінка.

OWASP Топ Вразливості

Ось де Odoo стоїть на чолі за питанням безпеки веб-додатків, як це вказано в списку Відкрийте проєкт захисту веб-додатків (OWASP):

• Недоліки впровадження: Недоліки впровадження, зокрема SQL, є поширеними у веб-додатках. Впровадження відбувається, коли надані користувачем дані надсилаються інтерпретатору як частина команди чи запиту. Ворожі дані зловмисника змушують інтерпретатора виконати ненавмисні команди або змінити дані.

  Odoo базується на фреймворку об'єктно-реляційного відображення (ORM), який абстрагує побудову запитів і за замовчуванням запобігає SQL-ін'єкціям. Зазвичай, розробники не створюють SQL-запити вручну, вони генеруються ORM, і параметри завжди належним чином екрануються.

• Міжсайтовий скрипт (XSS): Помилки XSS виникають щоразу, коли програма бере надані користувачем дані та надсилає їх у веб-браузер без попередньої перевірки чи кодування цього вмісту. XSS дозволяє зловмисникам виконувати сценарії у браузері жертви, які можуть захоплювати сеанси користувачів, псувати веб-сайти, можливо запроваджувати хробаків тощо.

  Фреймворк Odoo за замовчуванням екранує всі вирази, які відображаються на сторінках і відображеннях, запобігаючи XSS. Розробники повинні спеціально позначати вирази як "безпечні" для безпосереднього включення на відрендерені сторінки.

• Підробка міжсайтового запиту (CSRF): Атака CSRF змушує браузер жертви, яка ввійшла в систему, надіслати підроблений HTTP-запит, включаючи файл cookie сеансу жертви та будь-яку іншу автоматично включену інформацію автентифікації, до вразливої веб-програми. Це дозволяє зловмиснику змусити браузер жертви генерувати запити, які вразлива програма вважає законними запитами від жертви.

  Механізм захисту від CSRF вбудований в двигун вебсайту Odoo. Він запобігає отриманню пост-запиту будь-яким HTTP-контролером без відповідного захисного токену. Це рекомендований метод для запобігання CSRF. Цей захисний токен відомий і присутній лише тоді, коли користувач дійсно отримав доступ до відповідної форми вебсайту, і зловмисник не може сформувати запит без нього.

• Виконання шкідливого файлу: Код, вразливий до віддаленого включення файлів (RFI), дозволяє зловмисникам включати ворожий код і дані, що призводить до руйнівних атак, таких як повна компрометація сервера.

  Odoo не використовує функції для включення віддалених файлів. Однак вона дозволяє привілейованим користувачам налаштовувати функції, додаючи власні вирази, які будуть оцінені системою. Ці вирази завжди виконуються в пісочниці та очищеному середовищі, яке дозволяє доступ тільки до дозволених функцій.

• Незахищене пряме посилання на об’єкт: Пряме посилання на об’єкт виникає, коли розробник надає посилання на внутрішній об’єкт реалізації, наприклад файл, каталог, запис бази даних або ключ, як URL-адресу або параметр форми. Зловмисники можуть маніпулювати цими посиланнями для доступу до інших об’єктів без авторизації.

  Контроль доступу в Odoo не реалізований на рівні користувацького інтерфейсу, тому немає ризику викриття посилань на внутрішні об'єкти в URL-ах. Зловмисники не можуть обійти шар контролю доступу, маніпулюючи цими посиланнями, оскільки кожний запит все ще повинен пройти через шар перевірки доступу до даних.

• Незахищене криптографічне сховище: Веб-додатки рідко використовують криптографічні функції належним чином для захисту даних і облікових даних. Зловмисники використовують слабко захищені дані для крадіжки особистих даних та інших злочинів, таких як шахрайство з кредитними картками.

  Odoo використовує стандартне безпечне хешування для паролів користувачів (за замовчуванням PBKDF2 + SHA-512, з розтягуванням ключа), щоб захистити збережені паролі. Також можливо використовувати зовнішні системи автентифікації, такі як OAuth 2.0 або LDAP, щоб уникнути взагалі локального зберігання паролів користувачів.

• Незахищений зв'язок: Програми часто не можуть зашифрувати мережевий трафік, коли це необхідно для захисту конфіденційних даних.

  Odoo Cloud працює на HTTPS за замовчуванням. Для локальних встановлень рекомендується запускати Odoo за веб-сервером, який виконує шифрування і перенаправляє запити до Odoo, наприклад Apache, Lighttpd або nginx. Посібник з розгортання Odoo включає в себе Перевірочний список безпеки для безпечніших публічних розгортань.

• Не вдалося обмежити доступ до URL-адреси: Часто програма захищає лише конфіденційні функції, запобігаючи показу посилань або URL-адрес неавторизованим користувачам. Зловмисники можуть використовувати цю слабкість для доступу та виконання несанкціонованих операцій шляхом прямого доступу до цих URL-адрес.

  Контроль доступу в Odoo не реалізований на рівні користувальницького інтерфейсу, і безпека не заснована на приховуванні спеціальних URL-адрес. Зловмисники не можуть обійти шар контролю доступу, повторно використовуючи або маніпулюючи будь-яким URL, оскільки кожний запит все ще має проходити через шар перевірки доступу до даних. У рідкісних випадках, коли URL надає неаутентифікований доступ до конфіденційних даних, наприклад, спеціальні URL-адреси, які клієнти використовують для підтвердження замовлення, ці URL-адреси підписуються унікальними цифровими токенами і відправляються по електронній пошті тільки призначеному отримувачу.

Повідомлення про Вразливості Безпеки

Якщо вам потрібно повідомити про вразливість безпеки, будь ласка, перейдіть до нашого сторінка відповідального розкриття. Ці звіти обробляються з високим пріоритетом, проблема негайно оцінюється та вирішується командою безпеки Odoo, у співпраці з репортером, а потім у відповідальний спосіб розкривається клієнтам і користувачам Odoo.