MongoDB セキュリティ強化 (認可、TLS、ロール、監査)
MongoDBレベル: 上級所要時間: 10 分 (監査) – 2 時間 (全面的な強化)稼働中の MongoDB (スタンドアロン、レプリカセット、シャードクラスタ) をダウンタイムなしで強化するためのシナリオ別 runbook です。読み取り専用のセキュリティ監査、keyFile + transitionToAuth によるローリングでの認可有効化、最小権限のカスタムロールとユーザー、SCRAM-SHA-256、bindIp とファイアウォール、allowTLS → preferTLS → requireTLS への移行、x.509 メンバー認証、監査ログ (Enterprise/Percona)、保存時の暗号化 (encryption at rest) を扱い、最後に監査を再実行してリスクが解消されたことを確認します。本サイトのインストールガイドで構築したシステムでは、認可と keyfile はすでに有効です。監査から始め、RISK が出たシナリオだけを実施してください。日常運用とバックアップは別の MongoDB ガイドで扱います。
構成: スタンドアロン、3 メンバー以上のレプリカセット、またはシャードクラスタ
シナリオ
- セキュリティ状態の監査 (読み取り専用) — 何も変更しません。認証なしのアクセス、待ち受けアドレス、TLS、認証メカニズム、高権限ユーザー、監査ログ、保存時の暗号化の状態を OK / WARN / RISK で報告します。どこから始めればよいかわからない場合はこれを選んでください。
- 全面的な強化 (すべてを順番に実施) — 監査 → 内部認証 + 認可 (transitionToAuth でダウンタイムなし) → 最小権限ユーザー → SCRAM-SHA-256 → bindIp/ファイアウォール → TLS (allowTLS → preferTLS → requireTLS) → 監査ログ (Enterprise/Percona) → 最終監査。レプリカセットではローリングで実施し、リスクのあるステップごとに確認を求めます。
- 認可が無効: authorization を有効にする (keyFile、ダウンタイムなし) — ユーザー名とパスワードなしで誰でも接続できる状態です。レプリカセットとシャードクラスタでは keyFile + transitionToAuth により、ローリングでダウンタイムなしに有効化します。スタンドアロンでは短い再起動が 1 回必要です。
- 最小権限のユーザーとカスタムロール (アプリケーション、バックアップ、監視) — アプリケーションが root または共用の管理者アカウントで接続している状態です。アプリケーションに自分のデータベースで必要な操作だけを許可するカスタムロールと、バックアップ用・監視用の個別ユーザーを作成します。cron/アプリケーション側でのパスワードの安全な保管方法も示します。
- SCRAM-SHA-1 を無効化し SCRAM-SHA-256 のみにする — 古いユーザーの認証情報が SHA-1 で保存されているか、監査で SCRAM-SHA-1 が有効と検出された状態です。ユーザーを SHA-256 に移行し、その後ローリング再起動で authenticationMechanisms を絞り込みます。
- ネットワークアクセスを制限する (bindIp 0.0.0.0、ファイアウォール) — mongod がすべてのインターフェース (0.0.0.0、bindIpAll) で待ち受けているか、ポートが誰にでも開いている状態です。bindIp を localhost + サーバーの内部 IP に絞り、ファイアウォールではメンバーとアプリケーションネットワークのみを許可します。ローリングで実施し、ダウンタイムはありません。
- 接続を暗号化する: TLS (allowTLS → preferTLS → requireTLS) — アプリケーションとメンバー間、およびメンバー同士の通信が暗号化されていない状態です。証明書を配布し、まずメンバーをローリングで allowTLS にし、次に稼働中に preferTLS に切り替え、アプリケーションの準備ができたら requireTLS にします。オプション: メンバー間の x.509 認証。
- 監査ログを有効にする (Enterprise / Percona) — 誰がいつログインしたか、ユーザー/ロールの変更、drop 操作を記録する必要があります。MongoDB Enterprise と Percona Server for MongoDB では auditLog で有効化します。Community にはこの機能がありません (代替手段を示します)。
- 保存時の暗号化 (ディスク上のデータを暗号化する) — ディスクやバックアップが盗まれてもデータを読めないようにします。Enterprise/Percona では、メンバーを 1 台ずつ初期同期 (initial sync) で再構築して WiredTiger 暗号化を有効にします。Community ではデータディスクを LUKS で暗号化します。
開始前の確認
- すべての mongod… および mongos… サーバーでの root/sudo アクセス。最初のサーバーから他のサーバーへの SSH (keyfile と証明書のコピー用)。
- …レプリカセットが正常であること: 全メンバーが PRIMARY/SECONDARY で、ラグが小さいこと。正常でないクラスタではローリング操作を行いません。…mongod が稼働していること。…
- アプリケーションの一覧と担当者: 認可/TLS を必須にする前に、各アプリケーションの接続文字列を更新します。接続文字列には全メンバーと replicaSet= を含める必要があります (ローリング中に切断されないようにするため)。
- メンテナンスウィンドウ: ローリング操作でダウンタイムは発生しませんが、プライマリが切り替わるたびに書き込みが数秒待たされます。スタンドアロンでは認可/TLS の有効化に短い停止が必要です。
- シャードクラスタで認可がすでに有効な場合: 各シャードのプライマリに、mongos 上の … と同じ名前・パスワードのシャードローカルユーザー (root) が必要です。メンバー単位のステップ (ローリング再起動中の rs.stepDown、setParameter、監査) はシャードメンバーに直接接続するため、mongos のユーザーはそこでは有効ではありません。確認方法: シャードメンバーで mongosh --port <shard port> を実行し、db.getSiblingDB("admin").auth("…", passwordPrompt())。
- リストアを検証済みの最新のフルバックアップ。
- 監査ログと保存時の暗号化には MongoDB Enterprise ライセンスまたは Percona Server for MongoDB が必要です。Community にはこれらの機能がありません。
- 各サーバーでメンバー名が名前解決できること (DNS または /etc/hosts)。TLS ではこの名前で接続します。
ガイドのフェーズ
- 準備: セーフティネットと補助ツール — 設定と状態のバックアップ · PyYAML をインストールする · YAML 編集ツールを作成する (dbatlas-yaml) · ローリング再起動ツールを作成する (dbatlas-mongod-restart) · 管理者パスワードを一時ファイルに書き込む
- 状態の監査 (読み取り専用) — ネットワーク、プロセス、ファイルのパーミッション: … · ネットワークとプロセス: … · 認可、TLS、パラメータ: … · 認可、TLS、パラメータ: … · ユーザー、ロール、認証メカニズム · 検出事項をシナリオに対応付ける
- 認可: 診断と keyfile — 診断: 認可は本当に無効か · アプリケーション接続を棚卸しする · keyfile を作成する · keyfile を他のサーバーにコピーする · keyfile のパーミッション: … · keyfile のパーミッション: …
- 認可: 管理者ユーザー — 管理者ユーザーを作成する (…) · シャードローカル管理者: …
- 最小権限のユーザーとカスタムロール — アプリケーション用のカスタムロールを作成する (…@…) · アプリケーションユーザーを作成する (…) · バックアップユーザーと監視ユーザー · 最小権限を確認する (…) · アプリケーション側と cron 側でパスワードを安全に保管する
- 認可: 認証なしの接続が残っていないことを確認する — 認証なしのクライアント接続: …
- 認可を強制する (スタンドアロン) — authorization: enabled · サービスを安全に再起動する (…)
- 認可: 検証 — 認証なしのアクセスは拒否されるか · 最小権限を確認する (…) · 切り戻し手順 (必要な場合)
- SCRAM-SHA-256: ユーザーを移行する — SHA-1 の認証情報を持つユーザー · ユーザーを SCRAM-SHA-256 のみに絞る
- SCRAM-SHA-256: 検証 — SHA-1 でのログインは拒否されるか
- ネットワークアクセス: ファイアウォール — ファイアウォールのルール
- ネットワークアクセス: 検証 — 待ち受けアドレス: …
- TLS: 証明書 — 現在の TLS の状態 · 社内 CA とサーバー証明書を生成する · 証明書を配布する · 証明書のパーミッションと検証: … · 証明書のパーミッション: …
- TLS: アプリケーションを移行する — アプリケーションを TLS に移行し、TLS 接続を数える
- TLS: 検証 — 非 TLS の接続は拒否されるか: …
- 監査ログ: 事前チェック — この mongod は監査をサポートしているか: …
- 監査ログ: 検証とローテーション — 監査レコードは書き込まれているか: … · Community 向けの代替手段: 認証ログを監視する
- 保存時の暗号化: 事前チェックとバックアップ — 暗号化のサポートとディスク容量: … · フルバックアップは取得済みか
- 保存時の暗号化: テスト用マーカー — 平文のマーカーを書き込む
- 保存時の暗号化 (Community): LUKS によるデータディスク — LUKS ディスクを準備する: … · データを暗号化ディスクに移す: …
- 最終監査 (強化後) — ネットワーク、プロセス、ファイルのパーミッション: … (最終状態) · ネットワークとプロセス: … (最終状態) · 認可、TLS、パラメータ: … (最終状態) · 認可、TLS、パラメータ: … (最終状態) · ユーザー、ロール、認証メカニズム (最終状態)
- 後片付けと次のステップ — 一時パスワードファイルを削除する · 次のステップ: 監視と定期作業