Open WebUIにパスワード保護をかけ、ユーザー登録を制限する方法

Open WebUI インスタンスをセットアップしたばかりであれば、誰がアクセスして何ができるかを完全に制御することが非常に重要であることに気づいているでしょう。単に... Open WebUIをDockerでインストールする 以上です。そして、それは必要なことでもあります。 Open WebUIをパスワードで保護するそうすれば、あなたの環境は真に安全になります。

この意味で、Open WebUI のセキュリティは単一のボタンに依存するのではなく、 階層的なアプローチデータベース管理からネットワーク構成まで、サーバーを要塞のように機能させ、許可されたユーザーのみが言語モデルとやり取りできるようにするための変数やツールは数多く存在します。

ネットワークシールドと外部アクセス

WebUIを開く これはプライベートで安全なネットワーク上で動作するように設計されています。中間障壁なしにインターネットに直接公開するのは良い考えではありません。最善のアプローチは、アプリケーションを...の背後に配置することです。 WireGuardやTailscaleのようなVPNまたは、Cloudflare Accessのようなゼロトラストアクセスプロキシを使用する。

リバースプロキシ（NginxやCaddyなど）を選択する場合は、HTTPSトラフィックを適切に処理できることが不可欠です。セッションセキュリティを強化するには、適切なパラメータを使用してCookieを設定する必要があります。 Secure=true かつ SameSite=strictこれにより、アクセストークンが安全でないチャネルを通過するのを防ぎます。また、

認証とユーザー管理

登録システムは非常に巧妙です。最初に登録したユーザーが自動的に管理者になり、その後、 公開登録簿は無効化されています。参加人数を増やす必要がある場合は、管理者が変数を使用して再アクティブ化できます。 ENABLE_SIGNUP=trueただし、新規ユーザーは、権限を持つ担当者が承認するまで「保留中」の状態のままとなります。

よりプロフェッショナルな環境や企業環境で Open WebUI をパスワードで保護するには、ローカルパスワードを忘れて、 シングルサインオン（SSO）Open WebUIは、Google、Microsoft、GitHub、およびあらゆるOIDCプロバイダーと互換性があります。より従来型のインフラストラクチャをご利用の場合は、LDAPサーバーを統合することも可能です。 Open WebUIでユーザーを作成し、権限を管理します。 自分のディレクトリから。アカウントの作成と削除を自動化するには、 SCIM 2.0 これにより、IDプロバイダーは手動による介入なしにユーザーライフサイクルを管理できるようになります。

関連記事：

Open WebUIとOllamaの完全ガイド：インストール、設定、および高度な管理

役割ベースアクセス制御（RBAC）

このプラットフォームは追加権限モデルを使用しています。つまり、ユーザーは基本的な機能セットからスタートし、 彼らはより多くの許可を得る 特定のグループに追加された場合、管理者（完全な制御権限）、ユーザー（標準アクセス権限）、保留中（承認されるまでアクセス不可）の3つの主要な役割があります。

各ユーザーができることを厳密に制御できます。たとえば、次のような変数を使用して、ファイルのアップロード、チャットの編集、さらにはコードインタープリタの使用を無効にすることができます。 USER_PERMISSIONS_CHAT_FILE_UPLOADモデルや知識ベースなどのリソースは デフォルトでは非公開そして、作成者はそれらを他のユーザーと共有するか、グループ全体と共有するか、インスタンス全体に公開するかを決定します。

データベースのセキュリティと機密情報

ほとんどのユーザーはSQLiteから始めますが、本番環境では[他のSQLite]への移行を強くお勧めします。 PostgreSQL 並行処理と信頼性を向上させるため。SQLite を使い続けるが、非常に機密性の高いデータを扱う場合は、 SQLCipher 保存時のデータベースを暗号化するには、 DATABASE_TYPE として sqlite+sqlcipher.

関連記事：

Open WebUIのバックアップとアップデートに関する完全ガイド

重要なポイントは WEBUI_SECRET_KEYこのキーは、JWT トークンに署名し、セッション データを暗号化するために使用されます。定義しない場合、システムはデータ ディレクトリにランダムなキーを生成しますが、ロード バランサーの背後に複数のレプリカがあるデプロイメントでは、 すべてのインスタンスは同じキーを共有する必要があります ユーザーがサーバーを変更するたびにログインする必要がないようにするためです。

コンテナの強化とコード実行

Open WebUI をパスワードで保護する場合に重要: Docker を使用している場合は、アプリケーションを root 権限で実行しないでください。 非特権UID 万が一システムに侵入された場合の被害を最小限に抑えるため。さらに、/app/backend/data ディレクトリは厳格なファイルシステム権限で保護する必要があります。

「ツール」と「関数」を使うことは最も強力ですが、同時に最もリスクの高い側面でもあります。なぜなら、サーバー上でPythonコードを実行できるからです。問題を回避するためには、以下の点に留意することが不可欠です。 自動依存関係インストールを無効にする を通して ENABLE_PIP_INSTALL_FRONTMATTER_REQUIREMENTS=falseチャット内でコードを実行する必要がない場合は、変数を使用してインタープリタを完全に無効にするのが最善です。 ENABLE_CODE_EXECUTION=false.

関連記事：

Open WebUIをアップデートする際に、何も失うことなくアップデートする方法

Open WebUIをパスワードで保護する：トラブルシューティング

Open WebUI をパスワードで保護しようとした際に、誤ってロックアウトされてしまうことがあります。Docker を使用していて、標準のトラブルシューティング ガイド コマンドが失敗する場合 (たとえば、次のエラー) socat o bash)、覚えておいてください 変数の読み取りを強制する 環境設定 ENABLE_PERSISTENT_CONFIG=Falseこれにより、システムはデータベースの内容を無視し、設定ファイルやコンテナ変数に記述された内容を優先するようになります。

極端な場合、データベースにアクセスできない場合 webui.db WSLまたはDockerから、パスが正しいこと、およびファイルが他のプロセスによってロックされていないことを確認してください。 管理者用の環境変数 (WEBUI_ADMIN_EMAIL y WEBUI_ADMIN_PASSWORD) は、以前のユーザーがいないクリーンインストールでのみ機能します。最初の管理者が作成されると、これらの変数は効果を失います。

システムを常に最新の状態に保ち、キーと限定されたエンドポイントでAPIアクセスを制限し、メタデータレベルの監査ログを監視することで、Open WebUIの導入環境は堅牢で侵入耐性が確保されます。Open WebUIをパスワードで保護することで、データプライバシーを損なうことなく、生成型AIを利用できます。

ダニエル・テラサ

テクノロジーとインターネット問題を専門とする編集者で、さまざまなデジタル メディアで 10 年以上の経験があります。私は、電子商取引、通信、オンライン マーケティング、広告会社で編集者およびコンテンツ作成者として働いてきました。経済、金融、その他の分野のウェブサイトにも執筆しています。私の仕事は私の情熱でもあります。さて、私の記事を通じて、 Tecnobits, 私は、私たちの生活を向上させるために、テクノロジーの世界が私たちに提供するすべてのニュースや新しい機会を毎日調査しようとしています。