DevOpsナレッジハブ
DevOpsナレッジハブ

今すぐ導入すべきMongoDBの5つの重要なセキュリティ設定

MongoDBの絶対に譲れない5つのセキュリティ設定に関するこのガイドで、データを即座に保護しましょう。必須のユーザー認証、厳格なロールベースアクセス制御（RBAC）、ネットワークIPバインディング、およびエンドツーエンドTLS暗号化を実装することで、脆弱なデフォルト設定から高度に保護された環境へ移行する方法を学びましょう。また、コンプライアンスと即座の脅威検出に不可欠な重要な監査プラクティスについても触れ、すぐに実行可能な実践的な設定例をご紹介します。

38 ビュー

今すぐ実装すべきMongoDBの5つの重要なセキュリティ設定

MongoDBは、世界中の何百万もの開発者や企業によって使用されている、強力で柔軟なNoSQLドキュメントデータベースです。MongoDBの魅力である柔軟性と展開の容易さは、デフォルト設定をすぐに強化しなければ、重大なセキュリティ脆弱性につながる可能性があります。初期バージョンのMongoDBが公にデータ漏洩を頻繁に起こしたのは、主にセキュリティのデフォルト設定が緩すぎたためです。

MongoDBデプロイメントを保護することは任意ではなく、データ整合性、機密性、および規制遵守を維持するための基本です。本ガイドでは、不正アクセスとデータ盗難を防ぐために、すべての本番環境およびプリプロダクション環境のMongoDBで実装しなければならない、譲れない5つのセキュリティ対策のステップを概説します。これらの設定を実装することで、脆弱なデフォルト状態から堅牢で保護されたデータベースクラスタへと移行できます。

1. 必須アクセス制御と強力な認証を有効にする

MongoDBを保護するための最も重要なステップの1つは、認証がグローバルに有効になっていることを保証することです。そのままの状態では、明示的に設定しない限り、多くのMongoDBデプロイメントは資格情報なしでの接続を許可します。この慣行は本質的に危険です。

認証を有効にする方法

認証は通常、設定ファイル（mongod.conf）または起動時のコマンドラインフラグを介して有効になります。

設定ファイル（/etc/mongod.conf）:

# /etc/mongod.conf スニペット
security:
  authorization: enabled

コマンドライン:

mongod --auth --dbpath /var/lib/mongodb

管理者ユーザーの作成

アクセス制御を有効にしたら、userAdminAnyDatabaseまたはrootロールを持つ管理者ユーザーを作成する必要があります。このユーザーは、サービスが--authを有効にして再起動される前、またはシステムが既に実行中の場合は初期作成ステップのために一時的に認証を無効にしてからのみ作成できます。

mongoshを介したルートユーザーの作成例

まず、データベースに接続します（既に認証なしで実行中の場合、またはlocalhost例外を使用する場合）。

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // パスワードを安全にプロンプト表示
    roles: [ { role: "root", db: "admin" } ]
  }
)

⚠️ 警告: 常に強力で複雑なパスワードを使用し、シークレットマネージャーを通じて安全に保存してください。機密性の高い資格情報をスクリプトや設定ファイルにハードコードしないでください。

2. 詳細なロールベースアクセス制御（RBAC）の実装

認証を有効にした後、次のステップは最小権限の原則（PoLP）を確立することです。これは、すべてのユーザー、アプリケーション、およびサービスアカウントが、必要なタスクを実行するために最小限の権限のみを持つべきであることを意味します。

アプリケーション接続にrootロールやreadWriteAnyDatabaseロールを使用することは避けてください。代わりに、特定のデータベースまたはコレクションに対して特定の権限を付与するカスタムロールを定義します。

実用的なRBACの手順

  1. カスタムロールの定義: ビルトインロール（read、readWrite）で不十分な場合は、きめ細かなアクセスアクションを持つロール（例：特定のコレクションに対するinsertとfindのみ）を作成します。
  2. アプリケーションユーザーの分離: 異なるアプリケーション層（例：バックエンド用のapp_rw、分析用のreporting_ro）に対して専用のユーザーを作成します。
  3. 外部ツールのアクセス制限: 管理ツールは、絶対に必要な場合にのみ特権アカウントを使用して接続するようにしてください。

特定のデータベースに対する読み取り専用ユーザーの作成例

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // users_dbへの読み取りアクセスのみ
  }
)

3. 厳格なネットワークバインディングとファイアウォールの設定

ネットワーク設定は、データベースの周辺防御です。デフォルトでは、MongoDBはしばしばすべての利用可能なネットワークインターフェイス（0.0.0.0）にバインドするため、適切なファイアウォールルールなしでクラウドインスタンス上で実行されている場合、ネットワーク全体、あるいは最悪の場合、インターネット全体からアクセス可能になる可能性があります。

bindIpの制限

主要なセキュリティ対策は、設定ファイルでbindIp設定を定義することです。これは、MongoDBがリッスンすべきIPアドレスまたはホスト名を明示的に指示します。

設定ファイル（/etc/mongod.conf）:

# バインドするIPまたはホスト名のリスト
# ローカルアクセスのみの場合は 127.0.0.1 を使用
# アプリケーションサーバーからのアクセスのみの場合は内部IPを使用
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

外部ファイアウォール（セキュリティグループ）の実装

bindIp（MongoDBプロセスを制限する）に加えて、サーバーにトラフィックが到達する前にトラフィックをフィルタリングするために、外部ファイアウォール（iptables、AWSセキュリティグループ、Azureネットワークセキュリティグループなど）を使用する必要があります。

ベストプラクティス: MongoDBポート（デフォルト27017）へのインバウンドトラフィックは、アプリケーションサーバー、ロードバランサー、および管理用ジャンプボックスからのみ許可します。

4. 通信中のデータ暗号化（TLS/SSL）の強制

クライアント（アプリケーション、シェル、ドライバ）とMongoDBサーバー間で送信されるデータは、トランスポート層セキュリティ（TLS）またはセキュアソケットレイヤー（SSL）を使用して暗号化する必要があります。認証情報、クエリ、および結果を暗号化されていない接続経由で送信すると、データが盗聴（中間者攻撃）のリスクにさらされます。

MongoDBは、トラフィックの暗号化とオプションのクライアント証明書検証の両方で、ネイティブのTLS/SSL構成をサポートしています。

TLS/SSLの有効化

暗号化を有効にするには、有効なTLS証明書を生成または取得し、設定ファイルでその場所を指定する必要があります。

設定ファイル（/etc/mongod.conf）:

net:
  ssl:
    mode: requireTLS
    # 結合された証明書とキーファイルへのパス
    serverCertificateKeyFile: /etc/ssl/mongodb.pem
    # クライアント検証用の認証局（CA）ファイルへのパス
    CAFile: /etc/ssl/ca.pem

TLSを使用したクライアント接続

サーバーがTLSを要求したら、すべてのクライアントは適切なセキュアフラグを使用して接続する必要があります。

mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem

ヒント: すべての接続が保護されていることを保証するために、本番環境ではmode: requireTLSを使用します。preferTLSモードは通常、移行またはテスト中にのみ使用されます。

5. 監査の有効化とアクティビティログの監視

強力なアクセス制御と暗号化があっても、侵害された内部アカウントや権限昇格からセキュリティ上の脅威が発生する可能性があります。包括的な監査を有効にすることで、コンプライアンス、フォレンジック分析、および不審な動作の検出に不可欠なアクションの履歴記録が得られます。

MongoDBの監査機能は、管理アクション、認証試行、不正アクセス試行、および潜在的なデータ読み取り/書き込みを記録できます。

監査のための設定

監査は、設定ファイルのauditLogセクションを介して設定されます。宛先（ファイル、syslog、コンソール）とフィルター条件を指定できます。

設定ファイル（/etc/mongod.conf）:

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # 認証や管理者の変更など、重要なセキュリティイベントに焦点を当てる
  filter: '{ atype: { $in: [ "authenticate", "authorize", "createCollection", "createUser", "dropDatabase" ] } }'

監視の必須集中ポイント

  • 認証試行の失敗: 突然の急増は、潜在的なブルートフォース攻撃を示します。
  • ユーザー/ロールの作成/削除: すべての権限変更は記録され、レビューされる必要があります。
  • データベースまたはコレクションの削除: 破壊的な操作には即時アラートが必要です。

MongoDBの監査ログを集中型ログ管理システム（例：Splunk、ELKスタック、DataDog）と統合し、リアルタイムのアラートと長期的な保持を実現します。

結論

これら5つの重要な設定を実装することで、MongoDBデプロイメントは脆弱な状態から回復力のある状態へと移行します。MongoDBのセキュリティは、設定して忘れるものではなく、継続的なプロセスです。必須の認証、詳細なRBAC、厳格なネットワークバインディング、TLS暗号化、および包括的な監査といったこれらの設定が、すべてのデプロイメントで検証され、定期的にレビューされることを確認してください。これらのステップを優先することで、不正アクセスとデータ侵害のリスクを大幅に軽減できます。