ID とアクセス管理: Odoo の SSO、MFA、およびロールベースのアクセス

アイデンティティは新しい境界です。従業員がホーム オフィス、支店、モバイル デバイスから Odoo ERP にアクセスすると、従来のネットワーク境界は無意味になります。変わらないのはアイデンティティです。すべてのアクセス要求は、特定のユーザー、特定のデバイス、特定の時間に送信され、特定のリソースへのアクセスを要求します。これらの ID シグナルを効果的に管理することは、現代の企業セキュリティの基礎です。

Verizon のデータ侵害調査レポートでは、60% 以上の侵害の主なベクトルとして認証情報関連の攻撃が一貫して特定されています。財務データ、顧客記録、人事情報、サプライ チェーン インテリジェンスを一元管理する Odoo ERP システムの場合、単一の認証情報が侵害されると、ビジネスの運用バックボーン全体が暴露される可能性があります。

重要なポイント

• ID プロバイダーによる一元化された SSO により、パスワードのスプロールが排除され、アクセスの強制と取り消しのための単一ポイントが提供されます。
• ハードウェア セキュリティ キー (WebAuthn/FIDO2) は最強の MFA を提供しますが、TOTP 認証アプリはほとんどの展開でセキュリティと使いやすさの最適なバランスを提供します
• Odoo のグループベースのアクセス制御システムは、デフォルトのユーザー/マネージャーの役割を超えたカスタム グループで適切に構成されている場合、きめ細かい RBAC をサポートします。
• 四半期ごとのアクセス レビューにより、過剰な権限の蓄積が軽減され、孤立したアカウントが攻撃ベクトルとなる前に捕捉されます。

---

一元的な ID 管理

一元化された ID 管理は、すべてのビジネス アプリケーションを単一の ID プロバイダー (IdP) に接続します。IdP は、ユーザー認証、および多くの場合、認可の信頼できるソースとして機能します。各アプリケーションが独自のユーザー データベースとパスワードを維持する代わりに、ユーザーは IdP を通じて 1 回認証され、すべての承認されたアプリケーションへのアクセスを受け取ります。

ID プロバイダーのオプション

Odoo ERP を実行している組織の場合、通常、選択肢は Authentik (最大限の制御、ライセンス費用なし、強力な OIDC サポート) または Okta/Azure AD (マネージド サービス、広範なアプリ マーケットプレイス、運用オーバーヘッドゼロ) になります。

SSO プロトコル: SAML と OIDC

SAML 2.0 (Security Assertion Markup Language) は、確立されたエンタープライズ SSO プロトコルです。 IdP とサービス プロバイダー (SP) の間で交換される XML ベースのアサーションを使用します。 SAML はエンタープライズ アプリケーションで広くサポートされており、豊富な属性マッピングを提供します。

OIDC (OpenID Connect) は、OAuth2 上に構築された最新のプロトコルです。 JSON ベースのトークン (JWT) と RESTful エンドポイントを使用します。 OIDC は実装が簡単で、API や SPA に適しており、新しい統合にますます好まれています。

Odoo の SSO の構成

Odoo は、OAuth2 プロバイダー構成を通じて OAuth2/OIDC 認証をネイティブにサポートします。セットアップには以下が含まれます。

1. Odoo インスタンス (https://your-odoo.com/auth_oauth/signin) を指すリダイレクト URI を使用して、アイデンティティ プロバイダー (Authentik、Okta など) で OAuth2/OIDC アプリケーションを作成します。
2. Odoo の OAuth プロバイダーを構成します。 [設定] > [一般設定] > [OAuth プロバイダー] で、クライアント ID、クライアント シークレット、認証 URL、トークン URL、およびユーザー情報 URL を使用します。
3. ユーザー属性のマッピング --- IdP が電子メール、名前、およびグループ マッピングに必要なカスタム属性を送信することを確認します。
4. 新しい SSO ユーザーを Odoo で自動的にプロビジョニングする場合は、自動アカウント作成を有効にする
5. 直接ログインを無効にし (オプションですが推奨)、SSO によるすべての認証を強制します。

高度な展開の場合、SCIM (クロスドメイン ID 管理システム) は、IdP と Odoo の間でユーザーのプロビジョニングとプロビジョニング解除を同期できるため、退職した従業員は IdP で無効にされた場合にすぐに Odoo アクセスを失うことが保証されます。

---

多要素認証 (MFA)

Microsoft の調査によると、MFA はパスワード以外に 2 番目の検証要素を追加し、自動認証情報攻撃の 99.9% をブロックします。財務データと人事データを含む Odoo システムの場合、MFA はオプションではありません。MFA は、利用可能な単一のセキュリティ制御の中で最も影響力の高いものです。

MFA 方式の比較

推奨される MFA 戦略

管理者および特権ユーザーの場合: WebAuthn/FIDO2 ハードウェア セキュリティ キー (YubiKey 5 シリーズ、Google Titan) が必要です。これらは、暗号化チャレンジが発信元ドメインにバインドされているため、フィッシング耐性があります。フィッシング サイトは認証を傍受できません。

標準的なビジネス ユーザーの場合: TOTP 認証アプリ (Google Authenticator、Microsoft Authenticator、Authy) が必要です。これらは、ユーザーごとにゼロコストで、資格情報スタッフィングやリモート攻撃に対する強力な保護を提供します。

すべてのユーザー向け: SMS ベースの OTP を排除します。 SIM スワッピング攻撃の実行コストはわずか 100 ドルで、SMS ベースの MFA を完全にバイパスできます。 SMS をフォールバックとしてサポートする必要がある場合は、デバイスの信頼性検証と組み合わせてください。

Odoo での MFA の実装

Odoo 17+ には TOTP サポートが組み込まれています。 [設定] > [権限] > [2 要素認証] で有効にします。 WebAuthn サポートとより高度な MFA ポリシー (場所、デバイス、またはリスクに基づく条件付き MFA) の場合は、ID プロバイダー レベルで MFA を実装します。

• Authentik --- アプリケーションごとに MFA ポリシーを構成します。管理者アクセスには WebAuthn、標準アクセスには TOTP が必要です。アカウントのロックアウトを防ぐためのリカバリ コードをサポートします。
• Okta --- 適応型 MFA は、リスク信号に基づいて要件を調整します。低リスクのログインにはプッシュ通知のみが必要な場合があります。高リスクのログイン (新しいデバイス、通常とは異なる場所) にはハードウェア キーが必要です。
• Azure AD --- 条件付きアクセス ポリシーは、ユーザー リスク、サインイン リスク、デバイス コンプライアンス、およびアプリケーションの機密性に基づいて MFA を強制します。

IdP レベルの MFA の利点は、単一の構成ポイントから接続されているすべてのアプリケーション (Odoo、電子メール、ファイル共有など) に適用されることです。

---

Odoo のロールベースのアクセス制御

Odoo は、グループベースのアクセス制御システムを通じて RBAC を実装します。すべてのモジュールはアクセス グループを定義し、ユーザーはその権限を決定するグループに割り当てられます。最小特権アクセスを強制するには、このシステムを理解し、適切に構成することが不可欠です。

Odoo アクセス制御アーキテクチャ

Odoo のアクセス制御は 4 つのレベルで動作します。

メニュー アクセス。 ユーザーに表示されるメニュー項目を制御します。これは表面的なものです。メニュー項目は非表示になりますが、データ レベルでのアクセスは強制されません。

オブジェクト アクセス (ir.model.access)。 データベース モデル全体に​​対する CRUD 操作 (作成、読み取り、更新、削除) を制御します。グループごと、モデルごとに定義されます。

レコード ルール (ir.rule)。 ユーザーがモデル内のどのレコードにアクセスできるかを制御します。これは、データ分離を強制するきめ細かいアクセス制御です。レコード ルールはドメイン フィルター ([('department_id', '=', user.department_id)] など) を使用します。

フィールド アクセス。 モデル内の特定のフィールドへのアクセスを制御します。機密性の高いフィールド (給与、原価、マージン) を特定のグループに制限できます。

カスタムアクセスグループの設計

ほとんどの Odoo モジュールのデフォルトのユーザーおよびマネージャーの役​​割は、セキュリティを重視した展開には広すぎます。組織構造に合ったカスタム グループを設計します。

マルチテナントのレコード ルール

複数の企業による Odoo 展開の場合、レコード ルールにより企業間のデータ分離を強制する必要があります。

• 企業機密データを含むすべてのモデルには、company_id でフィルタリングするレコード ルールが必要です
• 会社間のアクセスは、持株会社の管理者にのみ明示的に許可する必要があります。
• 異なる会社のユーザーとしてログインし、会社間のレコードへのアクセスを試みて、レコード ルールをテストします。
• 記録ルールを四半期ごとに監査して、新しいカスタム モデルに適切な企業分離が含まれていることを確認します

より広範な ビジネス プラットフォーム セキュリティ戦略 の一環として Odoo を使用している組織の場合、Odoo の RBAC は、接続されているすべてのシステムにわたって適用されるアクセス コントロール ポリシーと一致する必要があります。

---

アクセスレビューとガバナンス

アクセス制御は、一度設定すれば後は忘れるような構成ではありません。定期的にレビューしないと、従業員が役割を変更したり、追加の責任を引き受けたり、以前の役職からのアクセスを保持したりするにつれて、権限が時間の経過とともに蓄積されていきます。この「権限のクリープ」により過剰なアクセスが発生し、資格情報侵害の爆発範囲が拡大します。

四半期ごとのアクセスレビュープロセス

1. すべてのユーザー、ユーザーに割り当てられたグループ、および最終ログイン日をリストした アクセス レポートを生成
2. 異常の特定 --- IT スタッフではない管理者アクセス権を持つユーザー、自分の役割に関係のないモジュールへのアクセス権を持つユーザー、90 日以上ログインしていないアカウント
3. マネージャーによるレビュー --- 各部門長は、チームへのアクセス割り当てをレビューして確認します。
4. 過剰な権限を取り消す --- 不要になったグループ割り当てを削除します。
5. 休眠アカウントを無効にする --- 90 日以上ログイン操作がないアカウントを無効にします
6. 決定事項を文書化 --- レビュー日、レビュー担当者、監査証拠に対して行われた変更を記録します。

自動化されたアクセス ガバナンス

大規模な展開の場合は、以下を使用してアクセス ガバナンスを自動化します。

• SCIM プロビジョニング により、人事システムでの従業員の採用、役割の変更、退職時に Odoo ユーザー アカウントが自動的に作成および更新されます。
• IdP グループから Odoo グループへの グループ マッピング。そのため、アイデンティティ プロバイダーでのロールの変更により、Odoo 権限が自動的に調整されます。
• アクセス認定キャンペーンは、スケジュール (四半期ごと) またはイベント (役割変更、部門異動) によってトリガーされます。
• 孤立したアカウントの検出 アカウントが Odoo に存在するが IdP には存在しない場合にアラートを表示します (ガバナンスをバイパスした手動作成を示します)

特権アクセス管理

Odoo の管理アカウント (設定グループ、技術機能グループ、データベース マネージャー) には追加のコントロールが必要です。

• 個別の管理者アカウント --- 管理者は、日常の作業には標準アカウントを使用し、管理タスクには別の特権アカウントを使用します。
• ジャストインタイム (JIT) アクセス --- リクエストに応じて、承認ワークフローを使用して、特定の期間、管理アクセスが許可されます。
• セッションの記録 --- 管理セッションは監査目的でログに記録されます。
• 緊急時の手順 --- 通常の特権アクセス ワークフローが利用できない状況における緊急アクセス手順

---

Odoo 固有の IAM セキュリティ強化

標準の RBAC と SSO を超えて、Odoo 導入ではプラットフォーム固有の強化によるメリットが得られます。

XML-RPC および JSON-RPC アクセス

Odoo は、外部統合用に XML-RPC および JSON-RPC API を公開します。これらの API は Web UI 認証をバイパスするため、個別に保護する必要があります。

• ファイアウォール ルールまたはリバース プロキシ構成を使用して、IP による API アクセスを制限します
• 統合認証にはユーザー認証情報ではなく API キー を使用します
• **認証情報のスタッフィングやブルート フォース攻撃を防ぐための レート制限 API エンドポイント
• API 認証の失敗を監視し、異常なパターンについて警告します
• 未使用の API プロトコルを無効にする --- JSON-RPC のみを使用する場合は、XML-RPC を無効にします

データベースマネージャーのセキュリティ

Odoo のデータベース マネージャー (/web/database/manager) を使用すると、データベースの作成、複製、削除、復元が可能になります。本番環境:

• 強力なデータベース マネージャー パスワードを設定します (または --no-database-list を使用して完全に無効にします)
• リバース プロキシ ルールを介してデータベース マネージャー URL へのアクセスを制限
• --database フラグを使用して正確なデータベースを指定し、データベースの列挙を防止します

セッションセキュリティ

• アイドル セッションを自動的に期限切れにするように session_timeout を構成します (推奨: 標準ユーザーの場合は 30 ～ 60 分、特権ユーザーの場合は 15 分)
• セッション Cookie で secure および httpOnly フラグを有効にする
• 同時セッション制限を実装して、資格情報の共有を防止し、侵害を検出します

---

よくある質問

Odoo Community Edition で SSO を使用できますか?

Odoo Community Edition は、auth_oauth モジュールを介して OAuth2 認証をサポートし、Google や GitHub などのプロバイダーとの基本的な SSO を有効にします。 SAML、SCIM プロビジョニング、高度な属性マッピングを備えたエンタープライズ グレードの SSO のために、Odoo Enterprise Edition には追加のモジュールが用意されています。あるいは、Authentik または Keycloak によるリバース プロキシ認証を使用して、Community Edition で同様の機能を実現することもできます。この場合、プロキシは SSO を処理し、認証された ID をヘッダー経由で Odoo に渡します。

ID プロバイダーがダウンした場合はどうなりますか?

IdP が使用できない場合、ユーザーは SSO を通じて認証できません。これが、ガラス破りの手順が重要である理由です。物理的な金庫またはハードウェア セキュリティ モジュールに保存された強力で一意のパスワードを使用して、Odoo で少なくとも 1 つのローカル管理アカウントを維持します。このアカウントは SSO をバイパスし、管理者が IdP の停止中にシステムにアクセスできるようにします。高可用性展開の場合は、IdP クラスタリングまたは自動フェイルオーバーを備えたセカンダリ IdP を構成します。

既存の Odoo ユーザーを SSO に移行するにはどうすればよいですか?

移行プロセスには、既存の Odoo ユーザー アカウントと IdP ID (通常は電子メール アドレスによる) の照合が含まれます。 IdP でユーザーを作成し、Odoo で SSO を構成し、OAuth プロバイダーにリンクするように既存のユーザー レコードを更新します。ユーザーは次回ログイン時に SSO を通じて認証されます。ローカル認証と SSO 認証の両方が利用できる移行期間を計画し、すべてのユーザーが正常に移行したらローカル認証を無効にします。

MFA を IdP レベルで適用する必要がありますか、それとも Odoo で直接適用する必要がありますか?

IdP レベルで MFA を強制します。これにより、接続されているすべてのアプリケーション (Odoo だけでなく) にわたって一貫した MFA が提供され、MFA ポリシー管理が集中化され、条件付き MFA やリスクベース認証などの高度な機能が有効になります。 Odoo の組み込み TOTP は、IdP を使用しないスタンドアロン展開としてのみ適しています。

外部パートナーやベンダーのアクセスはどのように処理すればよいですか?

パートナー自身のデータのみに表示を制限する制限付きレコード ルールを使用して、Odoo に専用の「ポータル」または「外部ユーザー」グループを作成します。 IdP の外部 ID 機能 (Authentik の「ソース」または Okta の「顧客 ID」) を使用して、従業員認証とは別に外部ユーザー認証を管理します。外部ユーザーに対して、より厳格な MFA 要件とセッション タイムアウトを適用します。アクセスを許可する前に、ベンダー セキュリティ評価 を実施してください。

---

次は何ですか

ID とアクセス管理は、ゼロトラスト セキュリティ アーキテクチャ の基礎です。まず、一元化された ID プロバイダーを介して認証を統合し、すべてのユーザーに MFA を適用し、デフォルトのロールを超えて Odoo で詳細な RBAC を構成し、四半期ごとのアクセス レビューを実装します。各ステップにより、認証情報ベースの攻撃のリスクが大幅に軽減されます。

ECOSIRE は、Authentik との SSO 統合、ロールベースのアクセス設計、セキュリティ強化を含む、すべての Odoo ERP 導入 にわたってエンタープライズ グレードの IAM を実装します。当社の OpenClaw AI プラットフォーム は、アイデンティティ認識セキュリティを AI を活用したアプリケーションに拡張します。ビジネスのための安全な ID 基盤を構築するには、チームにお問い合わせください。

---

ECOSIRE によって発行 --- Odoo ERP、Shopify eCommerce、OpenClaw AI にわたる AI を活用したソリューションで企業のスケールアップを支援します。