MongoDBでSCRAM認証エラーをトラブルシューティングする

MongoDBでのセキュリティ設定は、機密データを保護するために不可欠です。最新のMongoDBデプロイメントは、安全なパスワードベースの認証にSCRAM（Salted Challenge Response Authentication Mechanism）に大きく依存しています。しかし、SCRAMの実装と管理は、しばしばイライラする接続エラーやアクセス拒否につながることがあります。

このガイドは、MongoDBでSCRAM認証を設定または使用する際に遭遇する最も一般的な問題の特定と解決のための実用的なトラブルシューティングマニュアルとして機能します。ユーザー作成、ロール割り当て、クライアント設定に関連する一般的な落とし穴を理解することで、安全なデータベースアクセスを迅速に回復できます。

MongoDBにおけるSCRAMの理解

SCRAMは、最近のMongoDBバージョン（MongoDB 3.0+で強く導入され、現在の標準であるSCRAM-SHA-256に進化）のデフォルトの認証メカニズムです。強力なパスワードハッシュを提供し、パスワードがネットワーク上で平文で送信されるのを防ぎます。これは、古い方法に比べて大幅なセキュリティ改善です。

トラブルシューティングを行う際は、認証の失敗は通常、サーバー設定、ユーザー定義、またはクライアント接続構文の3つの領域のいずれかに起因することを覚えておいてください。

一般的なエラーカテゴリ1：接続拒否または認証失敗（クライアント側）

これは最も一般的な症状です。クライアントが接続できず、認証が厳格に強制されている場合、しばしばAuthentication failed.またはConnection refusedのようなメッセージが表示されます。

1. 不正な認証メカニズムの指定

MongoDBデプロイメントでSCRAMが必要なのに、クライアントが古いまたはサポートされていないメカニズム（MONGODB-CRなど）を使用しようとすると、接続はすぐに失敗します。

解決策： 接続文字列またはドライバー設定で、SCRAMを明示的に要求していることを確認してください。

最新のドライバーをサポートするクライアントの場合、接続文字列はしばしば認証メカニズム（authMechanism）を指定します。SCRAM-SHA-256（推奨）を使用する最新のデプロイメントの場合：

mongodb://user:password@host:27017/dbname?authSource=admin&authMechanism=SCRAM-SHA-256

ヒント： SCRAMのみで設定されたサーバーでauthMechanismを省略した場合、ドライバーは正しくデフォルト設定されるはずですが、明示的に設定することで曖昧さをなくすことができます。

2. 間違った`authSource`の使用

MongoDBでは、authSourceパラメータはユーザーアカウントが定義されているデータベースを指定します。ユーザーがadminデータベースに存在するのに、authSource=myappdbを指定して接続すると、サーバーは認証情報を見つけられません。

例：ユーザーapp_userはadminデータベースで作成されました。

不正な接続：

mongodb://app_user:password@localhost:27017/myappdb?authSource=myappdb

正しい接続：

mongodb://app_user:password@localhost:27017/myappdb?authSource=admin

3. ネットワークまたはバインディングの問題が認証失敗を隠蔽している

接続の問題が実際にはネットワークバインディングの問題であるにもかかわらず、認証失敗のように見えることがあります。mongodインスタンスが127.0.0.1（localhost）にのみバインドされている場合、リモートクライアントは認証を試みる前に接続拒否を受け取ります。

対処法： mongod.confのnet.bindIpがクライアントIPアドレスからの接続を許可している（例：すべてのインターフェイスに0.0.0.0、または特定のIP）ことを確認してください。

一般的なエラーカテゴリ2：ユーザー作成とロール割り当てのエラー

認証の失敗は、ユーザーの作成方法や付与された権限に起因することがよくあります。

1. パスワードなし（または不正な形式）でユーザーが作成された

mongoshまたはmongoシェルを使用して有効なパスワードを指定せずにユーザーを作成しようとすると、作成プロセスがサイレントに失敗したり、SCRAM経由で正常に認証できないユーザーが作成されたりする可能性があります。

作成のベストプラクティス： 必ず強力なパスワードを指定し、ユーザー作成中に推奨されるSCRAMメカニズムを使用していることを確認してください。

// まずadminユーザーとして接続
use admin

// SCRAM-SHA-256（推奨）でユーザーを作成
db.createUser(
  {
    user: "reader_role",
    pwd: passwordPrompt(), // パスワードを安全にプロンプト表示
    roles: [ { role: "read", db: "mydatabase" } ]
  }
)

2. ロールが欠落または不正

接続は成功するものの、ユーザーが望む操作（例：データの読み取り、書き込みができない）を実行できないという状況は、よくある混乱の原因です。これは認証の失敗ではなく、認可の失敗ですが、エンドユーザーにとっては認証失敗と似たように表示されることがあります。

認可のトラブルシューティング：

ロール割り当ての確認： 正しいデータベース（authSource）でshow usersを使用して、ユーザーが存在し、期待されるロールを持っていることを確認します。
継承ロールの確認： カスタムロールを使用している場合は、それらが必要な組み込みロール（readまたはreadWriteなど）を正しく継承していることを確認します。
接続コンテキスト： ロールは、作成中に指定されたデータベース（またはクラスタレベルのロールの場合はadmin DB）でのみ有効であることを覚えておいてください。

ユーザーがdbAから読み取ろうとしても、dbBにロールしかない場合、操作は失敗します。

3. アップグレード中のSCRAMバージョン不一致

MongoDBをアップグレードする際、古いユーザーはまだレガシーなMONGODB-CRメカニズムを使用してマッピングされている場合があります。サーバーがSCRAM-SHA-256のみを受け入れるように設定されている場合、これらの古いユーザーはログインに失敗します。

解決策： サーバー設定をアップグレードした後、既存ユーザーの認証方法を明示的に更新する必要があります。

changePasswordコマンドを使用すると、現在のサーバーのデフォルトを使用して再ハッシュが強制されます。

// ユーザーパスワードを更新し、必要に応じてメカニズムを暗黙的に更新
db.changePassword(
  "old_user",
  "new_secure_password",
  { authenticationDatabase: "admin" }
)

一般的なエラーカテゴリ3：サーバー設定の問題

複数のクライアントが接続に失敗している場合、問題はmongod設定ファイル（mongod.conf）にある可能性が高いです。

1. 認証が無効になっている

認証が完全に無効になっている場合、認証情報なしで接続するクライアントは成功するか、クライアントがそれでも認証を試みる場合に予期せずブロックされる可能性があります。逆に、認証が必要なのに設定が間違っていると、接続は失敗します。

mongod.confのセキュリティセクションが正しく設定されていることを確認してください。

security:
  authorization: enabled

2. 不正なインターフェイスへのバインド

前述のように、net.bindIpが制限的すぎる場合、外部クライアントは認証サービスに到達できません。

mongod.confでの例：

ローカルアクセスのみ： bindIp: 127.0.0.1（リモート接続は失敗）
クラウド/内部ネットワークに推奨： bindIp: 0.0.0.0（任意のインターフェイスからの接続を許可しますが、強力なファイアウォールルールが必要です）

3. サポートされていないSCRAMバージョンの使用

明示的にsetParameter: { authSchemaVersion: 1 }（レガシー）を設定した場合、クライアントがSCRAM-SHA-256を使用できなくなり、古い、セキュリティの低いメカニズムへの依存を強制される可能性があります。これらのメカニズムは、最新のドライバーでサポートされなくなっている場合があります。

ベストプラクティス： 最新のMongoDBインストール（4.0+）では、authSchemaVersion: 4（SCRAM-SHA-256のデフォルト）を目指すべきです。古いクライアントとの後方互換性が必要な場合を除き、スキーマバージョンを明示的に設定することは避けてください。

SCRAM認証失敗の概要チェックリスト

トラブルシューティングを行う際は、この順序で確認してください。

サーバー状態： mongod.confでsecurity.authorizationは有効になっていますか？
ネットワークチェック： クライアントはサーバーIPとポートに到達できますか（netstatまたはtelnetを使用）？
クライアントURI： authMechanism=SCRAM-SHA-256は指定されていますか（必要な場合）？
authSource： authSourceはユーザーが作成されたデータベースと一致しますか？
ユーザー存在： 指定されたauthSourceデータベースにユーザーは存在しますか？
パスワード/ロール： パスワードは正しいですか、そしてユーザーは意図したアクションに必要な最小限のロールを持っていますか？

これらの設定ポイントを体系的に確認することで、MongoDBにおけるほとんどのSCRAM認証エラーを迅速に特定し、解決できます。