Odoo에는 고객 기록, 영업 활동, 청구서, 직원 세부 정보, 프로젝트, 재고, 운영 문서 등 조직 전체에 중요한 정보가 담겨 있는 경우가 많습니다. 이러한 정보에 대한 접근은 이메일, 파일, 기타 핵심 비즈니스 시스템에 대한 접근과 마찬가지로 신중하게 관리되어야 합니다.

하지만 Odoo는 별도의 ID 섬이 될 수 있습니다. 직원은 Microsoft 365용 비밀번호와 Odoo용 비밀번호를 따로 사용할 수 있습니다. 관리자는 서로 다른 위치에서 접근 권한을 관리해야 할 수도 있습니다. 누군가 역할을 변경하거나 회사를 떠날 때, 모든 애플리케이션에서 체크리스트가 정확히 완료되어야만 절차가 끝나는 상황이 생길 수 있습니다.

Microsoft 싱글 사인온은 조직에 또 다른 선택지를 제공합니다. Odoo를 Microsoft Entra ID에 연결하면 사용자는 Microsoft 계정으로 인증할 수 있으며, 조직은 기존의 Microsoft ID 제어를 Odoo 로그인 과정에 적용할 수 있습니다.

이미 Microsoft ID 기반이 마련되어 있을 수 있습니다

조직이 Microsoft 365를 사용하고 있다면, 일반적으로 이미 Microsoft Entra 워크포스 테넌트를 보유하고 있습니다. Microsoft는 비즈니스가 Microsoft 365와 같은 Microsoft 클라우드 서비스를 등록하면 직원, 내부 애플리케이션, 조직 리소스를 위한 워크포스 테넌트가 생성된다고 설명합니다. 따라서 Entra는 별도의 독립 계정 시스템을 추가하기보다 Odoo에 대해 고려할 만한 자연스러운 ID 제공자입니다. Microsoft의 설명인 워크포스 및 외부 테넌트 구성을 참조하세요.

Odoo도 이 사용 사례를 인식하고 있습니다. 공식 Odoo 19 Microsoft Azure 로그인 문서는 Odoo 사용자가 Microsoft 계정으로 로그인할 수 있는 방법을 설명합니다. 또한 통합을 구성하려면 양쪽 모두에서 설정이 필요하다고 명확히 밝힙니다.

더 큰 이점은 Microsoft가 Odoo 세션이 시작되기 전에 조직이 인증 정책을 적용할 수 있는 지점이 된다는 것입니다.

Odoo 로그인 경로에 강력한 인증을 추가하세요

Microsoft Entra 다단계 인증은 두 가지 이상의 확인 수단을 요구할 수 있습니다. 이러한 요소에는 사용자가 알고 있는 것, 사용자가 소유한 것, 또는 사용자가 본질적으로 가진 것이 포함될 수 있습니다. Microsoft는 Entra 로그인 과정의 일부로 이 확인이 어떻게 처리되는지 MFA 개요에서 설명합니다.

Odoo가 로그인을 Entra에 위임하면, 조직은 승인된 MFA 방법을 요구할 수 있습니다. 또한 패스키, FIDO2 보안 키, Windows Hello for Business, 인증서 기반 인증과 같은 피싱 저항성이 있는 방법을 일부 사용자에게 적용하도록 전환할 수도 있습니다. Microsoft는 인증 가이드에서 이러한 방법을 권장합니다.

이 구분은 중요합니다. 일반적인 MFA는 대체로 비밀번호만 사용하는 것보다 강력하지만, 모든 MFA 방식이 피싱 저항성을 제공하는 것은 아닙니다. NIST는 비밀번호는 피싱 저항성이 없고, 수동으로 입력하는 일회용 코드는 공격자가 중계할 수 있으므로 피싱 저항성이 없다고 설명합니다. 또한 NIST는 FIDO2 인증기에 사용되는 WebAuthn을 도메인 바인딩을 통한 피싱 저항성의 예로 제시합니다. 자세한 내용은 NIST SP 800-63B-4에서 확인할 수 있습니다.

SSO 통합을 통해 조직은 이러한 Entra 기능을 Odoo에 적용할 수 있는 경로를 갖게 됩니다. 다만 적절한 정책을 활성화하고 강제하는 일은 여전히 조직의 몫입니다.

더 많은 맥락으로 접근 결정을 내리세요

Microsoft Entra 조건부 액세스는 사용자, 그룹, 애플리케이션, 위치, 디바이스 상태, 로그인 위험 등의 신호를 평가할 수 있습니다. 그런 다음 접근을 차단하거나 MFA, 특정 인증 강도, 규정 준수 디바이스 같은 제어를 요구할 수 있습니다. Microsoft는 조건부 액세스를 Zero Trust 정책 엔진이라고 부르며, 사용 가능한 신호와 결정을 조건부 액세스 개요에서 설명합니다.

Odoo 배포에서는 다음과 같은 정책을 지원할 수 있습니다.

  • Odoo 관리자와 재무 사용자는 MFA를 요구하기.
  • 권한이 있는 역할에는 피싱 저항성 인증 강도를 요구하기.
  • 조직이 서비스하지 않는 지역에서는 Odoo 로그인을 차단하기.
  • 민감한 내부 접근에는 규정 준수 또는 관리 디바이스를 요구하기.
  • 외부 또는 고위험 로그인에는 더 엄격한 정책을 적용하기.

이는 예시일 뿐, 보편적인 설정은 아닙니다. 내부 재무팀에 적합한 정책이 고객 포털에는 부적합할 수 있습니다. 제어를 선택하기 전에 조건부 액세스가 Odoo 로그인을 강화하는 방식을 읽어보세요.

조건부 액세스에는 라이선스 요구사항도 있습니다. 조건부 액세스에는 Microsoft Entra ID P1이 필요하며, 위험 기반 정책에는 P2가 필요합니다. Microsoft 365 Business Premium에는 조건부 액세스 기능이 포함됩니다. 라이선스와 현재 기능 제공 여부는 Microsoft의 공식 문서와 대조해 확인해야 합니다.

ID와 Odoo 접근을 더 가깝게 통합하세요

인증은 사용자가 누구인지에 답합니다. Odoo 권한 부여는 여전히 그 사용자가 무엇을 할 수 있는지 결정합니다.

잘 설계된 통합은 승인된 Microsoft ID를 기존 Odoo 계정에 매핑하고, 최초 로그인 시 승인된 계정을 생성하며, 선택된 Entra 그룹 또는 애플리케이션 역할을 Odoo 접근 그룹에 매핑할 수 있습니다. 이는 중복 관리 작업을 줄이고 접근 결정을 더 쉽게 검토할 수 있게 합니다.

ID와 권한 부여의 경계를 유지하는 것이 중요합니다. Entra 그룹에서 누군가를 제거하면 통합의 문서화된 동기화 동작에 따라 Odoo 매핑에 영향을 주어야 하지만, 기존 Odoo 세션이 즉시 종료된다는 뜻은 아닙니다. 접근이 로그인 시점에 동기화된다면, 다른 세션 제어가 개입하지 않는 한 사용자가 다시 로그인할 때 변경 사항이 적용됩니다.

이메일 일치도 주의가 필요합니다. Microsoft는 이메일 주소와 사용자 주 식별자(User Principal Name)가 변경되거나 재사용될 수 있다고 경고합니다. ID 토큰 클레임 가이드는 지속적인 ID를 위해 필요한 경우 테넌트 컨텍스트와 함께 sub 또는 oid와 같은 변경 불가능한 식별자를 권장합니다. 이메일은 통제된 최초 연결에서는 유용할 수 있지만, 영구적인 ID 키로 사용해서는 안 됩니다.

더 깊은 접근 설계는 Entra 그룹과 앱 역할로 Odoo 접근을 중앙 집중화하는 방법을 읽어보세요.

Microsoft SSO가 대체하지 못하는 것

Microsoft SSO는 Odoo 업데이트, 최소 권한 역할, 레코드 규칙, 보안 호스팅, 백업, 모니터링, 세션 제어, 사고 대응을 대체하지 않습니다. 공식 Odoo 문서도 Odoo.com에서 호스팅되는 데이터베이스의 소유자나 관리자에게 문서화된 OAuth 흐름 사용을 경고하는데, 포털 관리에 영향을 줄 수 있기 때문입니다. 배포 전에 소유자와 비상 관리 방안을 확인하세요.

Microsoft 로그인을 도입하는 더 안전한 방법

작은 테스트 그룹으로 시작하세요. Microsoft 검색 메타데이터와 서명 키를 검증하고, 콜백 URL을 확인하며, 계정 일치를 테스트하고, 신규 사용자와 권한이 없는 사용자에 대한 결과를 점검하세요. 흐름이 처음부터 끝까지 테스트될 때까지는 비상용 관리 경로를 유지하세요.

그다음 Odoo에 적용되는 정책, 필요한 Entra 라이선스, 그룹 또는 역할 변경이 Odoo에 반영되는 방식, 그리고 Microsoft 로그인이 사용할 수 없을 때 지원이 어떻게 대응할지 문서화하세요. 고객과 파트너가 접근해야 한다면, 이를 직원으로 간주하기보다 별도의 고객 ID 설계를 고려하세요. 우리의 안내서 Odoo 고객 및 파트너를 위한 Microsoft Entra External ID에서 그 차이점을 설명합니다.

Odoo 19에 안내형 Microsoft SSO를 도입하세요

우리의 Odoo 모듈용 Microsoft Entra SSO은 Odoo 19를 위한 안내형 연결을 제공합니다. 여기에는 직원 및 외부 사용자, 제어된 첫 로그인, 그룹 및 앱 역할 매핑, 로그인 테스트, 검증 후 Microsoft 전용 대화형 로그인이 포함됩니다. 이 기능은 PKCE가 포함된 OpenID Connect authorization code flow를 사용합니다.

이 모듈이 보안 정책을 대신 선택하지는 않습니다. Entra 설정, Odoo 액세스 설계 및 배포에 대한 책임은 여전히 귀사에 있습니다.