DB接続経路についての申し送り（セキュリティ・4項目）

作成: 2026-09-16 / 作成者: DFA Robotics

★★本書の位置づけ（2026-09-16 更新）— ★本書は外部に送付しません★★★

★送り方は「1通に統合する」に決まりました★（ユーザー daichi 判断。2026-09-16）。

項目	送付先	統合先
★項目1★（平文・接続元制限）	★TeamWorks 様へ送付★	★docs/handoff/TeamWorks確認事項_第9回_20260915.md 12-2 / 12-3 / 12-4★
★項目2★（コネクタの脆弱性）	★★外部に出しません★★	★DFA内製アプリの依存であり、解き方はDFA内部の判断★。★ただし「TLS より先に経路を閉じるほうが効く」という優先順の理由づけだけは、勧告ID・バージョン・依存関係を伏せたうえで統合版 12-3 に入れました★
★項目3★（アカウント再発行）	★TeamWorks 様へ送付★	同 ★12-5★
★項目4★（本番構成の確認）	★TeamWorks 様へ送付★	同 ★12-6（Q12-1〜Q12-6）★

★★したがって本書は、いまや★内部記録★です。★★ ★残る役割は次の2つです。★

1. ★★項目2 を DFA 内部で判断するための材料★★（統合版には詳細を書いていないため、 ★勧告の内容・バージョン・依存関係の実測は本書にしか残っていません★ → §2）
2. ★統合版に載せた実測値・判断の★根拠の控え★（測定日・測定方法・出典 → §1-1、§3-1）

★本文は当時のまま残してあります★（削っておりません）。 ★ただし、外部向けの文面としては読まないでください。外部向けの正は統合版（第9回）です。★ ★本書の §0-1 にある「宛先が未確定」という記述は、上記の決定により解決済みです★（→ 付録 A-1 / A-2）。

はじめに

★本書はご依頼です。質問ではありません。★

★D-Watch のアプリケーション（DFA内製）を棚卸ししたところ、アプリのコードには 危険な箇所が1件も見つかりませんでした。★ ★問題があるのはコードではなく、DBへ至る「経路」のほうです。★ ★そして経路は、当方（DFA）のコードでは閉じられません。★

そのため、★当方で直せない4項目★を本書にまとめ、正式にお渡しいたします。

本書の構成は次のとおりです。

★各節は【事実（実測）】【なぜ問題か】【誰が直せるか】【依頼したいこと】の4つで構成しています。★ ★「事実」に書いたことは、すべて実測値か、実測記録の引用です。推測は「推測」と明示します。★

★本書に書いた値について★ ホスト名（133.125.238.144）とDBユーザー名（★2026-10-08 に資料から除いた。値は .env.local の DATABASEUSER★）は、★すでに本リポジトリの 追跡済み文書に載っている値★のため本書でも使用します（`docs/handoff/TeamWorks確認事項第9回_20260915.md:58/ 同:748ほか。★他4ファイル。§3-1 に一覧★★統合により行番号が移動しています（2026-09-16 実測）★）。 ★**パスワードその他の認証情報は本書に一切書いていません**★（CLAUDE.md` §9.3）。 ★実在の攻撃手順・再現コマンドも書いていません★。

0. ★★宛先と期限★★

0-1. ★宛先は項目ごとに異なります（★2026-09-16 に確定しました★）★

★本書を「誰に渡すか」は、項目ごとに違います。★ ★★本節はもともと「一部が未確定」という状態で書かれていました。2026-09-16 のユーザー判断で すべて確定しましたので、確定後の内容に書き直してあります。★★

★注1 — 項目1 の契約主体（★2026-09-16 に解決★）★

★★テスト環境（133.125.238.144:13306）は、サーバーを契約し支払っているのが DFA、 構築・保守をしているのが TeamWorks 様です★★（ユーザー daichi 確認。2026-09-16）。

• ★実施（TLS 有効化・接続元IP制限・アカウント再発行）を依頼する相手は TeamWorks 様です★
• ★★「貴社にお渡しいただいたテスト環境」という従来の表現は事実と違うため、 外部向けの文面では使いません★★。★統合版（第9回 12-2）では「弊社が契約し、貴社に構築・保守を お願いしているサーバー」と書き直しました★

★★注2 — 項目4 には未解決の食い違いがあります（★内部向け★）★★

★ユーザー daichi は 2026-09-16 に「★本番のアプリサーバ（VM）も TeamWorks が用意する★」と 判断しました。★宛先はこれで確定です。★

★★ところが docs/decisions.md D-100 項5（docs/decisions.md:4768）は 「★DFA が構築するのはアプリ側（VM）なので、当方の作業には影響しない見込み★」と記録しています。★★

★★どちらが正しいかは未確定です。★★ ★そのため統合版（第9回 12-6）では、これを断定せず「どちらが用意する想定か」自体を 1問（Q12-1）として立てました。★ ★★「貴社が本番VMを用意される前提で」とは書いていません。★★ ★★A と B のどちらであっても、「VM と DB が同じ閉域に入れるか」は両者が突き合わせないと 決まりません。だからこそ YES / NO の確認という形を崩していません。★★

0-2. ★★期限 — ステージングに実データが入る前★★

★これが期限です。日付ではなく、「イベント」で切ってあります。★

★過ぎるとどうなるか★

★具体的には、実データ投入後に同じことをやろうとすると、次が全部必要になります。★

1. ★DBアカウントの再発行★ → ★接続している側（当方のアプリ、TeamWorks 様のデータ収集処理・ 集計バッチ）を★全部止めて★差し替える必要があります★
2. ★TLS の有効化★ → ★★サーバ再起動を伴う可能性があり、夜間の清掃データ収集を止められません★★ （D-Watch は★夜間に自動実行された清掃を翌朝確認する運用★です。CLAUDE.md §1）
3. ★接続元IPの制限★ → ★実データが流れている状態で絞ると、漏れた接続元から データ収集が止まります★

★★つまり「止める調整」が発生します。いまなら、その調整が要りません。★★

★だからこそ、実データが入る前にお願いしております。★

0-3. ★★4項目はいずれも、DFA のアプリコードでは直せません★★

★前提としてお伝えします。★

★2026-09-13 に当方のアプリコードを棚卸ししました（docs/handoff/指示書AE_セキュリティ強化と仕上げ.md:30-37）。 結果は次のとおりで、★危険な箇所は1件も見つかっていません★★。

★★したがって本書の4項目は「アプリを直せば済む話」ではありません。★★ ★★DB本体・ネットワーク・資格情報の発行はいずれも DFA のアプリ開発の担当範囲外です★★ （CLAUDE.md §2 の責任分界）。

1. ★★テストDBが公開IPに平文（TLS無効）で開いています★★

1-1. 【事実（実測）】

★いつ・誰が・どう測ったか★を明記します。

★実測値★:

★出典★: docs/handoff.md:3669（4項目すべて）/ docs/handoff/TeamWorks確認事項_第9回_20260915.md:744-748 （have_ssl と 参照用アカウント@%）/ docs/handoff/指示書AE_セキュリティ強化と仕上げ.md:52 :817

★★本書の作成にあたり、テストDBへの再接続は行っていません（意図的です）★★。 ★参照専用のアカウントではありますが、接続条件が現在も揃っているかが不明なため★、 ★★上記は「2026-09-13 に実測された値の引用」です★★。 ★★もし現時点で既にご対応済みでしたら、本節は読み飛ばしてください。★★

1-2. 【なぜ問題か】

• ★★have_ssl = DISABLED と require_secure_transport = OFF が重なると、 接続は必ず平文になります★★。★クライアント側で「TLSを使う」と書いても、 サーバが提供していないため暗号化されません★
• ★★接続元が %（どこからでも）なので、経路は公開IP上にあります★★
• ★この2つが重なると、★DB接続の資格情報が経路上で保護されていない状態★になります★
• ★★現在は検証用データのみのため実害はありません。問題になるのは実データが入った後です★★ （→ §0-2 の期限）

1-3. 【誰が直せるか】

★★いずれも DFA のアプリコードでは実施できません。★★

1-4. 【依頼したいこと】

★実データを入れる前に、次の3点をご検討ください。★

1. ★接続元の制限★ — ★参照用アカウント@% の % を、★固定IP★（または閉域ネットワーク内のみ）に絞ってください★
2. ★TLS の有効化★ — ★have_ssl を有効にし、可能であれば require_secure_transport = ON にしてください★
3. ★パスワードの再発行★ — ★§3 の理由により、★本番で使う資格情報は新規に発行してください★★

★ご負担や副作用のご懸念があれば、その旨をお知らせください。当方で別の手を検討します。★

★★この3点は、2026-09-16 に第9回確認書へ統合しました★★ ★第9回確認書の初版（2026-09-15）では、末尾に「参考: テスト環境について（申し送り）」として 情報共有のみで記載していました★。★★その章を削除し、正式なお願いとして12章に書き直してあります★★ （docs/handoff/TeamWorks確認事項_第9回_20260915.md:703-900。 ★接続元の制限＝12-3 / TLS＝12-4 / アカウント再発行＝12-5★）。 ★★重複は残していません。外部に出る文面はそちらが正です。★★ ★★なお、統合版では★接続元の制限（12-3）を TLS（12-4）より先★に置いています★★ （★理由は §2-2。ただし勧告ID・バージョン・依存関係は外部向けには書いていません★）。

★★第9回確認書を送付したという記録が docs/decisions.md に残っていません★★ （docs/handoff/セッション引き継ぎ_20260916.md:70-79）。 ★★統合版は1通として送りますので、初版の送付状況の確定は引き続き DFA 内部の宿題です★★。

2. ★★mariadb コネクタの既知の脆弱性 — 修正版を取り込めません★★

2-1. 【事実（実測）】★2026-09-16 に再実測しました★

★古い記録の転記ではありません。本書の作成時（2026-09-16）に npm audit --json を実行し直しました。★

npm audit --json

★実測結果（2026-09-16）★

★mariadb に報告されている勧告3件（★すべて同一パッケージ★）★

★CVE番号について★: ★npm audit --json の出力に CVE 番号は含まれていませんでした★ （勧告ごとに GHSA ID と URL のみ）。★推測で CVE を補わないため、GHSA ID のまま記載しています★。

★★No fix available の理由が分かりました（2026-09-13 の記録より一歩踏み込んだ実測）★★

★★つまり「修正版は上流に存在するのに、アダプタが脆弱版をピン留めしているため取り込めない」★★ という状態です。

★これは 2026-09-13 の記録（docs/deploy.md 7-4「上げても直りません」）の書き方より 正確な表現です。★ ★上げられないのは★当方の都合ではなく、@prisma/adapter-mariadb の依存指定が原因★です★。

★SQLインジェクション勧告（GHSA-g5xc-5w98-jfvm）は該当しません（★再確認済み★）★

grep -n "charset\|collation" .env.example .env.production.example lib/db/prisma.ts
# → ヒット0件（2026-09-16 実測。2026-09-13 と同じ）

• ★DATABASE_URL のひな型にクエリ文字列がありません★
• ★lib/db/prisma.ts にも charset / collation の指定がありません★（同ファイルに ssl の指定も0件）
• ★★したがって既定（utf8mb4）で動作し、勧告の条件（big5 等）に当たりません★★
• ★本番の DATABASE_URL に charset= / collation= を足す場合は、この勧告を先に読んでください★

★参考: 本節の実行では npm audit fix を一切かけていません（--force なしも含む）★。 ★package-lock.json に差分が無いことを git status で確認済みです★。

2-2. 【なぜ問題か】

★★ここが本書で最も重要な点です。★★

★GHSA-cqhc-2h57-wpxf は「ssl: true を指定しても平文パスワードが漏れる」という勧告です。★

★つまり、§1 の TLS を有効化していただいても、このコネクタを使っている限り 資格情報が保護されない可能性が残ります。★

★そして修正版（3.4.6 以降）は、★アダプタ側の依存指定が変わらない限り取り込めません★★。

★★帰結: 「アプリ側で ssl: true を足す」では解決しません。★★ ★★経路そのものを閉じる（固定IP／閉域ネットワーク）ほうを優先していただきたい、というのが 本項の依頼です。★★

★なお lib/db/prisma.ts には★意図的に TLS の指定を入れていません★★。 ★上記の理由で、アプリ側の設定では解決にならないと判断したためです★ （docs/handoff.md:3692-3694）。

2-3. 【誰が直せるか】

2-4. 【依頼したいこと】

1. ★TLS を有効にしても、このコネクタでは資格情報が保護されない可能性があることを前提に ご検討ください★
2. ★★経路そのものを閉じること（固定IP／内部ネットワーク）を優先していただきたい★★

★★DFA内部の判断待ち（ユーザー daichi 宛）★★ ★上流が mariadb のピン留めを上げるまで待つのか、それとも別のアダプタ構成を検討するのか★は、 ★DFA 側で決める話★です。★本書では「経路を閉じる」依頼だけを外部に出し、 構成変更の是非は判断待ちとして残します★。

3. ★★実在のDBユーザー名が Git の履歴に残っています★★

3-1. 【事実（実測）】

★経緯（コミットを実測しました）★

★実測コマンド★: git show --stat c832891 / git show --stat a5502ac / git grep -n "<DATABASE_USER の値>" a5502ac -- lib/db/__tests__/local-guard.test.ts

★★現在の状態★★

• ★★a5502ac は現在も参照でき、当該の値が読めます★★（上記 git grep で2件ヒット）
• ★履歴は書き換えていません★。★c832891 のコミットメッセージに理由が明記されています★:

  「★履歴は書き換えない★。コミット a5502ac に残るが、パスワードは含まれておらず、 force push は禁止（CLAUDE.md §6-5）で並行セッションも動いているため。」

• ★★a5502ac に含まれていたのはユーザー名のみで、パスワードは架空の値（pw / s3cret）です★★ （ホスト名も example.com のダミー）
• ★リポジトリの可視性★: ★DFARobotics/d-watch / PRIVATE★（実測 gh repo view --json visibility。2026-09-16）

★現時点で DBユーザー名を含む追跡済みファイル（2026-09-16 実測。★2026-10-08 に全件から除いた★）★

★実測コマンド★: git grep -n "<DATABASE_USER の値>"

★★合計5ファイル。いずれも docs/ 配下の文書で、アプリのコード（lib/ app/ components/ prisma/）には 1件もありません★★。★本書（docs/handoff/セキュリティ申し送り_20260916.md）を加えると6ファイルになります★。

★★注意: これは「4件」ではなく「5件」でした★★（本書作成時の実測）。 ★.py 2件は第9回確認書のPDF生成／検査スクリプトです★。

★★2026-09-16 に同種の再発が1件あり、コミット前に止まっています★★

★d792067（fix(db): 部品変数での接続を足し、実在のDBユーザー名をコードから外す。2026-09-16）★の コミットメッセージより:

「あわせて、作業中に置いていた user の既定値(実在のDBユーザー名)を外した。 CLAUDE.md §9.3『認証情報を絶対にコミットしない』に反するうえ、同じ値は 2026-09-10 の c832891『テストから実在のDBユーザー名を除去する』でわざわざコードから消したもの。」

★★つまり「同じ値が、同じ理由で、2回コードに入りかけました」★★ （★1回目はコミットされ、2回目はコミット前に除去★）。 ★これは「注意して運用する」では止まらない類の問題だ、という実測上の裏付けです★。

3-2. 【なぜ問題か】

• ★★Git の履歴は、除去のコミットを積んでも消えません★★。 ★「いま git grep して出ない」＝「漏れていない」ではありません★（docs/deploy.md 7-3）
• ★リポジトリは PRIVATE ですが、★アクセス権を持つ全員が履歴を読めます★★
• ★★さらに、この参照用アカウントの認証情報は平文でチャットに貼られています★★ （docs/decisions.md D-078「セキュリティ上の申し送り」）。★会話ログにも残っています★
• ★★ユーザー名が既知である以上、§1 の 参照用アカウント@%（どこからでも接続可）と組み合わさると 推測の手間が減ります★★

3-3. 【誰が直せるか】

3-4. 【依頼したいこと】

★★本番接続に使うアカウントは、履歴に入った値とは別のものを新規発行してください。★★

• ★★ユーザー名・パスワードとも★★お願いします（★ユーザー名が既知のためです★）
• ★履歴の書き換えはお願いしていません★。★当方では実施できないため、 ★「発行し直す」ほうで解いていただきたい★というお願いです★
• ★タイミングは §0-2 のとおり、★ステージングに実データが入る前★です★

4. ★★本番構成の確認 — YES / NO でお答えいただけます★★

4-1. 【事実（実測）】

★当方の理解と、その根拠は次のとおりです★。

★★未確認なのは 4 と 5 です。★★

★docs/decisions.md D-100 項5 に、その旨が明記されています★:

★「つまり『アプリは VM、DB はアプライアンス』という構成と読める★が、★★明示の確認は 取れていない★★。★回答文はエンジン選定の理由として述べられただけで、構成を説明したものではない★」

★★すなわち、TeamWorks 様のご回答は「なぜ MariaDB なのか」の説明であり、 「本番の構成はこうなります」という説明ではありませんでした。当方が読み取っただけです。★★

4-2. 【なぜ問題か】

• ★★§1 と §2 の解き方（＝「経路を閉じる」）が成立するかどうかが、この構成にかかっています★★
• ★VM と DB が同一の閉域ネットワークに入れるなら★ → ★★§1・§2 は「初めから起きない」★★
• ★もし公開IP越しに接続する構成なら★ → ★★§1・§2 がそのまま本番に持ち越されます★★
• ★★当方は「閉じた構成になる見込み」と考えていますが、これは推測です★★。 ★推測のまま本番に進むと、§0-2 の「作り直し」に直結します★

4-3. 【誰が直せるか】

★★これは「直す」ではなく「確認する」項目です★★。→ ★宛先は §0-1 のとおり両論併記です★。

4-4. 【依頼したいこと】★★以下の5問に YES / NO でお答えください★★

★NO や「条件つき」の場合は、差し支えなければ理由を1行だけ添えていただけると助かります。★ ★当方はそれを前提に、§1・§2 の依頼内容を組み直します。★

5. ★DFA側でやったこと／やれないこと★

★「丸投げではありません」という説明のために書いています。★

おわりに

★本書の4項目は、いずれも「いまなら安く直る」ものです。★ ★実データが入った後では、同じことに運用停止の調整が必要になります。★

★まずは §4 の Q1〜Q5（YES / NO）だけでも先にお答えいただけますと、 §1 と §2 の依頼内容を確定できます。★

★ご負担や副作用のご懸念があれば、その旨をお知らせください。当方で別の手を検討します。★

以上です。ご確認のほど、よろしくお願いいたします。

★付録: DFA 内部で確定すること（★2026-09-16 更新★）★

★★この付録は社内向けです。★★ ★本書は送付しないことになりましたので（→ 冒頭「本書の位置づけ」）、本付録は「統合版（第9回）を送る前に確定すること」の一覧に読み替えてください。★