TLS は、クライアントとMongoDBデプロイ、およびレプリカセット内のノード間の接続を暗号化します。 TLS を設定する前に、このページを使用して、セキュリティ要件に一致する構成を決定してください。
重要
これらの手順は、自己管理型MongoDB配置に適用されます。 MongoDB Atlasクラスターはデフォルトで TLS を使用します。 Cloud Managerまたは Ops Manager を使用する場合は、配置管理ツールを通じて TLS を構成します。
始める前に
TLS 構成を計画する前に、次のリソースと情報があることを確認してください。
TLS で構成する自己管理型MongoDBレプリカセット。
パブリック CA やプライベート CA など、使用可能な証明機関のタイプ。
X.509 認証 が必要かどうかなどのセキュリティ要件。
アクセス可能な CA のタイプによって、使用できる TLS 構成が決まります。
CA タイプ | 説明 | 推奨される使用 |
|---|---|---|
パブリック CA |
| mTLS または X.509認証を使用しないクラスター内 TLS暗号化 |
プライベート CA |
| インクラスター mTLS および X.509ノード認証 |
自己署名 |
| ローカル開発とテストのみ |
構成を選択する
以下のセクションは、 レプリカセット内のノード間、およびクライアントとサーバー間で TLS暗号化と認証を構成する方法を決定するのに役立ちます。
ノード間のクラスター内 TLS およびキーファイル認証と、クライアントとサーバー間の相互 TLS および X.509認証を使用する配置例。
ノード間の暗号化
すべての TLS 対応配置では、ノード間の接続が暗号化されます。また、クラスター内 mTLS を有効にすることもできます。これには、TLS ハンドシェイク中にノードがクライアントとして認証するために証明書を提示する必要があります。ノードは着信接続を受け入れる際に、接続側が ID を確認できるようにサーバー証明書を提示します。ノードが別のノードにアウトバウンド接続を行う場合、その動作はクラスター内 mTLS を有効にしているかどうかによって異なります。
各暗号化モードに必要な操作を決定するには、次の表を使用します。
暗号化モード | システム要件 |
|---|---|
mTLS を使用しないクラスター内 TLS |
|
イントロクラスター mTLS |
|
クラスター内 mTLS を使用しない場合、ノードはアウトバウンド接続でクライアントとして認証するための証明書を提示しません。接続ノードは受信ノードのサーバー証明書を検証しますが、受信ノードはTLS ハンドシェイクを通じて接続ノードの ID を検証しません。公開serverAuth CA など、 EKU でのみ証明書を取得できる場合は、この構成を使用します。この構成では、ノード間で X.509 認証を有効にすることはできません。
イントラクラスター mTLS では、各ノードは他のノードへのアウトバウンド接続にも証明書を提示し、相互 ID 検証を提供します。 X.509ノード認証を使用するには、 インクラスター mTLS が必要です。ただし、clientAuth EKU の証明書が必要なため、プライベート CA へのアクセス権が必要です。
ノード間の認証
レプリカセットのノードは相互に認証を行い、許可されたノードのみがレプリケーションに参加することを確認します。デフォルトでは 、認可が有効なレプリカセットはノード間で キーファイル認証を使用します。ただし、クラスター内 mTLS を有効にすると、代わりに X.509 証明書認証を使用できます。
各認証モードに必要なものを判断するには、次の表を使用します。
認証モード | システム要件 |
|---|---|
キーファイル認証 |
|
X.509ノード認証 |
|
キーファイル認証を使用する場合、すべてのレプリカセットノードはキーファイルに保存されている単一のシークレットを共有します。各ノードは、セット内の他のノードに接続するときに共有シークレットを提示することで、メンバーシップを証明します。すべてのノードは同じキーを共有しているため、個々のノードのアクセスを取り消す場合は、すべてのノードにわたってキーファイルを置き換える必要があります。
X.509認証は各ノードのクラスター証明書を使用してメンバーシップを検証します。証明書の交換は TLS ハンドシェイク中に発生するため、X.509ノード認証にはクラスター内 mTLS が必要になるため、ノードは ID を相互に検証できます。各ノードの一意の証明書 ID を使用すると、証明書を取り消すことで、他のノードに影響を与えずに個々のノードのアクセスを取り消すことができます。さらに、認証と暗号化は1 つのハンドシェイクで一緒に確立されます。
クラスター ノード証明書には、通常のクライアント証明書と区別する X.509 属性を含める必要があります。必要な証明書属性の詳細については、「 メンバー X.509 証明書 」を参照してください。
クライアントとサーバー間の暗号化
mongoshやドライバーなどのクライアントがTLSmongod 対応の インスタンスに接続すると、サーバーはID を証明するために証明書を提示し、クライアントはその証明書を信頼できる CA 証明書と照合します。また、クライアントは、サーバーのホスト名が証明書のホスト名と一致することも確認します。検証に成功すると、TLS はサーバーとクライアントの間の接続を暗号化します。
各暗号化モードに必要な操作を決定するには、次の表を使用します。
接続モード | システム要件 |
|---|---|
クライアント証明書なしの TLS |
|
相互 TLS または X.509クライアント認証 | クライアントは |
allowConnectionsWithoutCertificatestrueを に設定すると、クライアントが証明書を送信せずに接続できるようになります。これを有効にすると、serverAuth EKU のみを含む証明書など、誤った証明書で接続するユーザーによる接続を防止します。サーバーは接続を暗号化し、クライアントに自分の ID を証明しますが、サーバーはTLS ハンドシェイクを通じてクライアントの ID を確認できません。クライアントはSCRAM などの方法で認証する必要があります。
ハンドシェイク中にクライアントが独自の証明書を提示した場合、サーバーはクライアント証明書を信頼できる CA に対して検証できます。これにより、サーバーとクライアント間で相互 TLS が確立されます。クライアントとサーバー間で X.509クライアント認証を有効にするには、クライアントが証明書を提示する必要があります。
クライアントとサーバー間の認証
TLS 接続を確立した後、クライアントは配置にアクセスするために認証を行う必要があります。クライアントはさまざまな方法で認証できますが、このクイックスタートでは SCRAM と X.509 認証 を対象としています。
各認証モードに必要なものを判断するには、次の表を使用します。
認証モード | システム要件 |
|---|---|
SCRAM 認証 |
|
X.509クライアント認証 |
|
MongoDB はデフォルトのクライアント認証メカニズムとして SCRAM を使用します。クライアントはユーザー名、パスワード、認証データベースを提供し、 MongoDB は指定されたデータベース内のユーザーに対して認証情報を検証します。 SCRAM では、TLS ハンドシェイク中にクライアントが証明書を提示する必要はありません。
X.509クライアント認証では、クライアントが接続中に提示した証明書が使用されます。相互 TLS が確立されると、クライアントはMONGODB-X509 メカニズムを使用して $externalデータベースに対して認証を行います。 MongoDB は、証明書内のサブジェクトフィールドを $externalデータベース内のユーザーにマッピングします。