Odoo のセキュリティとアクセス制御: ビジネス データを保護

ERP には、財務記録、顧客情報、従業員の詳細、価格設定戦略、運用指標など、最も機密性の高いビジネス データが含まれています。アクセス制御が正しく構成されていないと、このデータが権限のないユーザーに公開されたり、偶発的 (または悪意のある) 変更が可能になったりする可能性があります。 Odoo は、適切に構成されている場合、データを保護しながら、人々が仕事をするために必要なアクセスを可能にする、階層化されたセキュリティ モデルを提供します。

セキュリティ層スタック

Odoo セキュリティは 4 つのレイヤーで動作し、それぞれにより詳細な制御が追加されます。

1. ユーザー グループ — 広範なアクセス カテゴリ (営業ユーザー、会計マネージャー、人事担当者)
2. アクセス権 — グループごとのモデルごとの CRUD 権限 (作成、読み取り、更新、削除)
3. レコード ルール — 行レベルのフィルタリング (ユーザーには自分のレコード、チームのレコード、またはすべてのレコードのみが表示されます)
4. フィールドレベルのアクセス — 個々のフィールドの制限 (HR 以外のユーザーに対して給与フィールドを非表示にする)

ユーザーグループ

事前定義されたグループ

各 Odoo モジュールは、典型的な組織の役割に一致するユーザー グループを定義します。販売モジュールには、販売ユーザー (自分のリードと注文にアクセス)、販売マネージャー (すべての販売データにアクセス)、および管理者 (完全な構成アクセス) が含まれます。

カスタムグループ

組織に固有の役割のカスタム グループを作成します。 「地域マネージャー」グループは、その地域のレコードに限定された営業マネージャーのアクセス権を持つ場合があります。

グループ階層

グループは他のグループから継承できます。 Sales Manager はすべての Sales User 権限を継承し、管理機能を追加します。この階層により、構成の重複が削減されます。

アクセス権 (ACL)

モデルレベルの権限

グループごとに、各モデル (データベース テーブル) に対するアクセス許可: 読み取り (レコードの表示)、作成 (新しいレコードの作成)、書き込み (既存のレコードの変更)、削除 (レコードの削除) を定義します。

倉庫作業者は、在庫ピッキング (注文の履行) では読み取り/書き込みができますが、製品では読み取りのみ (製品情報は変更できません) である場合があります。

一般的な構成

• 読み取り専用アクセス: データを表示する必要があるが変更は必要ないユーザー
• 作成はするが削除はできない: レコードを追加しても削除できないユーザー
• アクセス禁止: 特定のモデルをまったく表示すべきではないグループ (HR データは非 HR から隠蔽されます)

レコードのルール

ドメインベースのフィルタリング

レコード ルールは、グループがモデル内でアクセスできるレコードを制限するドメイン フィルターを適用します。例:

• 営業ユーザーには、自分に割り当てられたリードのみが表示されます: [('user_id', '=', user.id)]
• 部門マネージャーは自分の部門内のすべてのレコードを参照します: [('department_id', '=', user.department_id.id)]
• 複数企業の分離: [('company_id', '=', user.company_id.id)]

グローバル ルールとグループ固有のルール

グローバル ルールは全員に適用されます (複数の会社の分離など)。グループ固有のルールは、特定のグループのメンバーにのみ適用されます。グループ ルールは追加的です。ユーザーが複数のグループに属している場合、該当するすべてのルールの和集合が得られます。

フィールドレベルのセキュリティ

機密フィールドの保護

個々のフィールドを特定のグループに制限するものとしてマークします。一般的な使用例: 従業員の給与は人事部と財務部のみに表示され、顧客信用条件は営業マネージャーのみに表示され、製品原価は購買部と会計部にのみ表示され、マージン計算は経営陣のみに表示されます。

計算フィールドのセキュリティ

計算フィールド (利益率、手数料) の場合は、ソース データ フィールドも保護されていることを確認してください。原価を確認できないユーザーには、それを間接的に示すマージン フィールドを表示しないでください。

認証セキュリティ

二要素認証 (2FA)

すべてのユーザー、特に管理データや機密データにアクセスできるユーザーに対して 2FA を有効にします。 Odoo は、Google Authenticator、Authy、および同様のアプリと互換性のある TOTP (時間ベースのワンタイム パスワード) をサポートしています。

パスワードポリシー

パスワード要件を構成します: 最小長、複雑さの要件 (大文字、数字、記号)、および有効期限。ログイン試行が繰り返し失敗した後は、アカウントをロックします。

API キー管理

自動統合にはパスワードの代わりに API キーを使用します。各キーは個別に取り消すことができ、キーの使用状況がログに記録されます。

監査と監視

変更追跡

機密モデルの変更追跡を有効にして、誰が、いつ、何を変更したか、古い値と新しい値をログに記録します。これは、財務記録、人事データ、およびコンプライアンスで規制されている情報にとって不可欠です。

ログイン監視

ログイン アクティビティを監視します: ログインの成功、試行の失敗、異常なパターン (新しい場所からのログイン、営業時間外)。不審なアクティビティに対するアラートを設定します。

セッション管理

非アクティブなユーザーのセッション タイムアウトを構成します。管理者は、必要に応じて（デバイスを紛失した場合など）アクティブなセッションを表示および終了できます。

本番環境のセキュリティのベスト プラクティス

1. 最小権限の原則 — 最小限のアクセスから開始し、必要に応じて権限を追加します
2. 定期的なアクセスレビュー — 誰が何にアクセスできるかを四半期ごとに監査します。
3. 別の管理者アカウント — 日常の作業には管理者アカウントを使用しないでください。
4. データベースのセキュリティを確保 — データベースへの直接アクセスを DBA のみに制限します
5. Odoo を最新の状態に保つ — セキュリティ パッチは既知の脆弱性に対処します
6. HTTPS のみを使用します - 暗号化されていない接続は決して許可しないでください
7. バックアップの暗号化 — ライブ データベースだけでなく、保存時のバックアップも暗号化します。
8. ネットワーク セグメンテーション — Odoo サーバーをファイアウォールの内側に配置し、必要なポートのみを開きます
9. 未使用の機能を無効にする - 有効になっているすべてのモジュールが追加の攻撃対象領域となります
10. セキュリティ構成を文書化します - 確認して複製できるようにします

当社の Odoo サポートおよびメンテナンス サービス には、継続的なセキュリティ監査と構成レビューが含まれています。

よくある質問

ユーザー グループに基づいてメニューの表示を制限できますか?

はい。メニュー項目はグループにリンクされています。ユーザーには、アクセスできるモジュールと機能のメニューのみが表示されます。これによりインターフェースがすっきりし、混乱が防止されます。

複数企業のセキュリティはどのように機能しますか?

複数会社のレコード ルールが Odoo に組み込まれています。特定の会社に割り当てられたユーザーには、それらの会社のデータのみが表示されます。管理者は、アクセスできる会社を切り替えることができます。

従業員が退職するとどうなりますか?

ユーザー アカウントを非アクティブ化します (削除しないでください)。これにより、アクセスを防止しながら、監査証跡と履歴記録が保存されます。すべてのグループからユーザーを削除し、パスワードをリセットします。

特定のレコードに誰がアクセスしたかを監査できますか?

変更追跡を有効にすると、誰がレコードを変更したかを確認できます。 Odoo はデフォルトでは読み取りを追跡しないため、読み取りアクセスの監査には、カスタム ログ モジュールまたはサーバー ログ分析が必要です。