CSA STAR 레벨 1

Odoo CSA 보안 신뢰 보증 및 위험(STAR) 프로그램에 참여합니다.
CAIQv3.1 설문 조사에 대한 답변 보기

— Odoo 클라우드 (플랫폼) —

백업 및 재해 복구

  • 각 Odoo 데이터베이스의 14개 전체 백업을 최대 3개월 동안 유지합니다: 7일 기준 1일, 4주 기준 1주, 3개월 기준 1개월
  • 최소 2개 지역의 다른 지역의 대륙에 위치한 최소 3개 이상의 데이터 센터로 백업을 복제 관리하고 있습니다.
  • 데이터 센터의 실제 위치는 다음 내용에 지정되어 있습니다 개인정보 보호정책.
  • 언제든지 제어판을 통하여 라이브 데이터 백업을 수동으로 다운로드 받을 수 있습니다.
  • 헬프데스크로 문의하시면 해당되는 라이브 데이터베이스 (또는 사이드 데이터베이스) 백업을 복원하실 수 있습니다.
  • 하드웨어 장애 조치: 하드웨어 장애가 발생할 수 있는 베어 메탈에서 호스팅되는 서비스의 경우, 5분 이내에 완료할 수 있는 모니터링 및 수동 장애 복구 절차와 함께 로컬 핫 스탠바이 복제를 구현합니다.
  • 재해 복구: 데이터 센터가 장기간 완전히 다운되어 로컬 핫 스탠바이의로 장애 조치 (전례없는 시나리오)를 할 수 없는 치명적인 재해가 발생하는 경우, 다음과 같은 내용을 목표로 합니다:
    • RPO (복구시점목표, Recovery Point Objective) = 24시간. 즉 데이터 복구가 불가능하거나 최근의 일일 백업을 복구해야 하는 상황의 경우에는 최대 24시간 동안의 작업이 손실 될 수 있습니다.
    • RTO (Recovery Time Objective: 복구시간목표) = 유료 구독의 경우 24시간, 무료 평가판이나 교육 연수, 무료 사용자의 경우 48시간. 재해가 발생하여 데이터 센터가 완전히 다운된 경우 다른 데이터 센터에서 서비스를 복원하는 시간입니다.
    • 이는 여러 대륙의 여러 위치에 복제된 일일 백업을 지속적으로 모니터링하여 달성할 수 있습니다. 자동화된 프로비저닝 시스템을 통해 새로운 호스팅 위치에 서비스를 신속하게 배포합니다. 재해가 발생하면 대규모 클러스터의 경우 유료 구독자에게 우선권을 부여하여 전일 백업의 데이터 복구를 몇 시간 내에 완료할 수 있습니다.
      또한 일상 업무에서 일일 백업과 프로비저닝 스크립트를 모두 정기적으로 사용하여 재해 복구 절차의 두 구성 요소를 지속적으로 테스트하고 안정성을 보장합니다.

데이터베이스 보안

  • 고객 데이터는 전용 데이터베이스에 안전하게 저장되므로 서로 다른 고객 간에 데이터가 공유되지 않습니다.
  • 데이터 액세스 제어 규칙은 동일한 클러스터에서 실행되는 고객 데이터베이스 간의 완벽한 격리를 보장합니다. 한 데이터베이스에서 다른 데이터베이스로 액세스할 수 없으므로 각 개별 데이터베이스의 보안과 개인정보 보호가 강화됩니다.

비밀번호 보안

  • 고객 비밀번호는 업계 표준인 PBKDF2+SHA512 암호화(수천 회에 걸쳐 솔티드+스트레칭)로 보호됩니다.
  • Odoo 관리자는 회원님의 비밀번호에 액세스하거나 검색할 수 없습니다. 비밀번호를 분실한 경우 사용할 수 있는 유일한 옵션은 비밀번호를 재설정하는 것입니다.
  • 로그인 자격 증명은 HTTPS를 통해 안전하게 전송됩니다.
  • 고객 데이터베이스 관리자는 다음과 같은 옵션을 선택할 수 있습니다 속도 제한 설정 및 로그인 시도 반복에 따른 대기 시간.
  • 비밀번호 정책: 데이터베이스 관리자는 사용자의 최소 비밀번호 길이를 설정할 수 있습니다. 그러나 특정 문자 클래스에 대한 요구 등 특정 정책은 효과적이지 않은 것으로 입증되었기 때문에 지원되지 않습니다. 예를 들어, [Shay et al. 2016]), 뿐만 아니라 NIST SP 800-63b.

직원 액세스

  • Odoo 헬프데스크 직원이 계정에 로그인하여 지원 문제와 관련된 설정에 액세스할 수 있습니다. 그러나 이 경우 지정된 직원 자격 증명을 사용하므로 비밀번호에 액세스할 수 없습니다.
  • 이 특별 직원 액세스는 문제를 즉시 재현할 수 있고, 비밀번호를 공유할 필요가 없어 효율성과 보안을 향상시킵니다. 또한 직원의 작업을 별도로 감사하고 제어할 수 있습니다.
  • 헬프데스크 직원은 사용자의 개인정보를 최대한 존중하며, 특정 문제를 진단하고 해결하는 데 필요한 파일과 설정에만 액세스합니다.

시스템 보안

  • 모든 Odoo 클라우드 서버는 최신 보안 패치가 설치되어 보안이 강화된 Linux 배포판을 실행합니다.
  • 설치는 임시로 이루어지며, PHP/MySQL 스택을 제외하는 등 서비스 수를 제한하여 취약점 발생 가능성을 줄이기 위해 최소한으로 유지됩니다.
  • 서버를 원격으로 관리할 수 있는 액세스는 신뢰할 수 있는 Odoo 엔지니어의 일부 그룹으로 제한됩니다. 또한 이러한 액세스는 암호화된 개인 SSH 키쌍을 사용해야만 가능하며, 전체 디스크 암호화가 적용된 컴퓨터로 제한됩니다.

물리적 보안

Odoo 클라우드 서버는 전 세계 여러 지역에 위치한 신뢰할 수 있는 데이터 센터(예: OVH, 구글 클라우드)에서 호스팅됩니다. 이러한 각 서버는 엄격한 물리적 보안 기준을 통과해야 합니다.

  • 승인된 데이터 센터 직원만 물리적으로 접근할 수 있는 제한된 경계 구역.
  • 보안 배지 또는 생체 인식 보안 조치를 통한 물리적 액세스 제어.
  • 보안 카메라가 데이터 센터 위치를 연중무휴 24시간 모니터링합니다.
  • 연중무휴 24시간 보안 요원이 현장에 상주합니다.

신용카드 보안

  • 당사는 신용카드 정보를 자체 시스템에 저장하지 않습니다.
  • 신용카드 정보는 항상 사용자와 당사 서비스 간에 직접 안전하게 전송됩니다.PCI 준수 결제대행업체 (다음에서 목록보기: 개인정보 보호정책 페이지).

데이터 암호화

고객 데이터는 항상 암호화된 형태로 전송 및 저장됩니다. (네트워크를 통해 전송 중이거나 데이터베이스에저장될 때에도 암호화를 통해 보호됩니다.)
  • 클라이언트 인스턴스와의 모든 데이터 통신은 최첨단 256비트 SSL 암호화(HTTPS)를 사용하여 보호됩니다.
  • 서버 간의 모든 내부 데이터 통신도 최첨단 암호화(SSH)로 보호됩니다.
  • 당사의 서버는 보안을 위해 엄격하게 모니터링되며, 최신 SSL 취약점으로부터 보호하기 위해 패치를 적용합니다. A 단계 항상 SSL 등급을 유지합니다
  • 모든 SSL 인증서는 강력한 2048비트 모듈러스와 전체 SHA-2 인증서 체인을 사용합니다.
  • 모든 고객 데이터(데이터베이스 콘텐츠 및 저장된 파일)는 암호화되며, 운영 환경과 백업 환경 모두에 적용됩니다. (AES-128 또는 AES-256)

네트워크 보안

  • Odoo 클라우드가 이용하는 모든 데이터센터 제공업체는 광범위한 네트워크 용량을 보유하고 있으며, 가장 심각한 디도스(DDoS) 공격을 견딜 수 있도록 인프라를 설계했습니다. 자동 및 수동 마이그레이션 시스템은 여러 대륙에 걸쳐 있는 네트워크의 어느 부분에서라도 공격 트래픽을 감지하고 우회하여 서비스 중단이 일어나지 않도록 방지할 수 있습니다.
  • Odoo 클라우드 서버의 방화벽과 침입 방지 시스템은 무차별 암호 대입 공격을 비롯한 다양한 위협을 탐지하고 차단하는 데 중요한 역할을 합니다.
  • 고객 데이터베이스 관리자는 다음과 같은 옵션을 선택할 수 있습니다 속도 제한 설정 및 로그인 시도 반복에 따른 대기 시간.

— Odoo (소프트웨어) —

소프트웨어 보안

오픈 소스 플랫폼인 Odoo는 전 세계 사용자와 기여자가 전체 코드베이스를 검토하는 지속적인 모니터링을 받습니다. 커뮤니티 버그 리포트는 특히 보안과 관련하여 중요한 피드백의 원천이 됩니다. 저희는 개발자가 코드를 감사하고 보안 문제를 발견하면 보고할 것을 적극 권장합니다.

Odoo의 R&D 프로세스에는 신규 코드와 기여한 코드 모두에 대한 보안 고려 사항을 포함하는 코드 검토 단계가 포함되어 있습니다.

설계를 통한 보안

Odoo는 가장 일반적인 보안 취약점의 유입을 방지하는 방식으로 설계되었습니다.

  • SQL 인젝션은 수동 SQL 쿼리가 필요 없는 상위 수준의 API를 사용하여 방지할 수 있습니다.
  • 삽입된 데이터를 자동으로 이스케이프하는 높은 수준의 템플릿 시스템을 사용하여 XSS 공격을 차단합니다.
  • 이 프레임워크는 비공개 메서드에 대한 RPC 액세스를 제한하여 보안 조치를 강화하고 익스플로잇 가능한 취약점을 도입할 가능성을 줄입니다.

또한 OWASP 취약점 내역 취약점이 나타나는 것을 사전에 방지하기 위해 Odoo가 처음부터 어떻게 설계되었는지 자세히 설명하는 섹션입니다.

독립 보안 감사

Odoo는 고객과 잠재 고객이 고용한 독립적인 업체로부터 정기적인 감사를 받아 철저한 감사 및 침투 테스트를 수행합니다. Odoo 보안팀은 그 결과를 검토하고 필요할 때마다 적절한 시정 조치를 시행합니다.

결과는 기밀 사항이며 위원의 소유이므로 공개할 수 없습니다. 정보에 대한 요청은 자제해 주시기 바랍니다. ;-)

또한, 독립 보안 연구자 커뮤니티가 활발하게 활동하고 있으며, 소스 코드를 적극적으로 모니터링하고 Odoo의 보안을 개선하고 강화하기 위해 당사와 협력하고 있습니다. 보안 프로그램에 대한 자세한 정보는 책임 있는 정보 공개 페이지

OWASP 취약점 내역

다음은 웹 애플리케이션의 주요 보안 이슈에 대한 Odoo의 입장입니다. 웹 애플리케이션 보안 프로젝트 열기 (OWASP):

  • 인젝션 결함: SQL 인젝션을 중심으로 한 인젝션 결함은 웹 애플리케이션에 널리 퍼져있습니다. 인젝션은 사용자가 제공한 데이터가 명령이나 쿼리의 일부로 인터프리터에 전송될 때 발생합니다. 공격자의 악의적인 데이터는 인터프리터를 속여 의도하지 않은 명령을 실행하거나 데이터를 변경하도록 합니다.

    Odoo는 쿼리 작성을 추상화하는 객체 관계형 매핑(ORM) 프레임워크를 활용하여 SQL 인젝션에 대한 기본 방어 기능을 제공합니다. 일반적으로 개발자는 SQL 쿼리를 수동으로 생성하지 않고, ORM이 쿼리를 생성하여 매개변수가 항상 적절하게 이스케이프되도록 합니다.

  • 크로스 사이트 스크립팅(XSS): XSS 취약점은 애플리케이션이 사용자가 제공한 데이터를 사전에 유효성을 검사하거나 인코딩하지 않고 웹 브라우저로 전송할 때 발생합니다. 이를 통해 공격자는 피해자의 브라우저에서 스크립트를 실행할 수 있으며, 세션 하이재킹, 웹사이트 변조, 웜 유입 등의 위험을 초래할 수 있습니다.

    Odoo 프레임워크는 기본적으로 뷰와 페이지에 렌더링되는 모든 표현식을 이스케이프 처리하여 XSS를 방지합니다. 개발자는 렌더링된 페이지에 표현식을 원시적으로 포함하려면 표현식을 '안전'으로 명시적으로 지정해야 합니다.

  • 교차 사이트 요청 위조 (CSRF: Cross Site Request Forgery): CSRF 공격은 로그인한 피해자의 브라우저가 피해자의 세션 쿠키 및 기타 자동으로 포함된 인증 데이터로 구성된 위조 HTTP 요청을 취약한 웹 애플리케이션으로 전송하도록 유도합니다. 이를 통해 공격자는 피해자의 브라우저에 취약한 애플리케이션이 피해자의 진짜 요청으로 간주하는 요청을 생성하도록 유도할 수 있습니다.

    Odoo 웹사이트 엔진에는 CSRF 보호 메커니즘이 내장되어 있어, 해당 보안 토큰이 없는 HTTP 컨트롤러가 POST 요청을 수신하지 못하도록 차단합니다. 이 방법은 CSRF 방지를 위해 적극 권장됩니다. 보안 토큰은 사용자가 관련 웹사이트 양식에 합법적으로 액세스할 때만 알려지고 사용 가능하므로 공격자가 보안 토큰 없이 요청을 위조하기 어렵습니다.

  • 악성 파일 실행: 원격 파일 인클루전(RFI)에 취약한 코드는 공격자가 악성 코드와 데이터를 포함할 수 있게 하여 잠재적인 서버 손상 등 심각한 결과를 초래할 수 있습니다.

    Odoo는 원격 파일 포함 기능을 제공하지 않습니다. 그럼에도 불구하고 권한 있는 사용자가 시스템이 평가하는 사용자 지정 표현식을 통합하여 기능을 사용자 지정할 수 있습니다. 이러한 표현식은 샌드박스와 위생 처리된 환경 내에서 일관되게 평가되므로 액세스가 승인된 기능으로만 제한됩니다.

  • 안전하지 않은 직접 객체 참조: 안전하지 않은 직접 객체 참조는 개발자가 URL 또는 양식 매개변수를 통해 파일, 디렉토리, 데이터베이스 레코드 또는 키와 같은 내부 구현 객체에 대한 참조를 공개할 때 발생합니다. 공격자는 이러한 참조를 악용하여 다른 개체에 대한 무단 액세스를 얻을 수 있습니다.

    Odoo의 접근 제어는 사용자 인터페이스 수준에서 적용되지 않으므로 URL에서 내부 개체에 대한 참조를 노출하는 것과 관련된 위험이 없습니다. 모든 요청은 여전히 데이터 액세스 유효성 검사 계층을 통해 유효성 검사를 거쳐야 하므로 이러한 참조를 조작해도 공격자가 액세스 제어 계층을 우회할 수 없습니다.

  • 안전하지 않은 암호화 저장소: 웹 애플리케이션은 암호화 기능을 잘못 처리하여 데이터와 자격 증명을 부적절하게 보호하는 경우가 많습니다. 공격자는 이러한 약점을 악용하여 신원 도용 및 신용카드 사기를 비롯한 다양한 범죄를 일으킬 수 있습니다.

    Odoo는 사용자의 비밀번호를 보호하기 위해 업계 표준 보안 해싱 방식 (일반적으로 키 스트레칭이 포함된 PBKDF2 + SHA-512)을 사용합니다. 또한 사용자의 비밀번호를 로컬에 저장하지 않기 위해 OAuth 2.0 또는 LDAP와 같은 외부 인증 시스템을 통합합니다.

  • 안전하지 않은 통신: 민감한 커뮤니케이션을 보호해야 할 때 애플리케이션이 네트워크 트래픽 암호화를 소홀히 하는 경우가 많습니다.

    기본적으로 Odoo 클라우드는 HTTPS에서 작동합니다. 온프레미스 설치의 경우, 암호화를 구현하고 Odoo에 대한 요청을 프록시하는 웹 서버(예: Apache, Lighttpd 또는 nginx) 뒤에서 Odoo를 실행하는 것이 좋습니다. Odoo 배포 가이드는 보안 체크리스트 더 안전한 공개 배포를 위해

  • URL 액세스를 제한하지 않음: 애플리케이션은 권한이 없는 사용자에게 링크나 URL을 표시하지 못하도록 제한하는 것만으로 민감한 기능을 보호하는 경우가 많습니다. 공격자는 이 취약점을 악용하여 해당 URL에 직접 액세스하여 권한이 없는 작업을 실행할 수 있습니다.

    Odoo의 액세스 제어는 사용자 인터페이스 수준에서 적용되지 않으며, 보안은 특정 URL을 숨기는 데 의존하지 않습니다. 각 요청은 여전히 데이터 액세스 유효성 검사 계층을 통해 유효성 검사를 거쳐야 하므로 공격자는 URL을 재사용하거나 조작하여 액세스 제어 계층을 우회할 수 없습니다. 고객이 주문을 확인하기 위한 특별 URL과 같이 민감한 데이터에 대한 인증되지 않은 액세스를 허용하는 URL의 경우, 이러한 URL은 고유 토큰으로 디지털 서명되며 지정된 수신자에게만 이메일을 통해 전송되어 보안이 보장됩니다.

보안 취약점 신고하기

보안 취약점을 신고해야 하는 경우 다음 페이지로 이동하세요. 책임 있는 정보 공개 페이지. 해당 신고 내용을 최우선으로 처리하며, Odoo 보안팀에서는 신고 당사자와 협력하여 문제에 대해 즉각적으로 평가하고 해결하여, 책임감 있는 방향으로 Odoo 고객과 사용자에게 이를 공개합니다.