誰でも接続できるのに、なぜ安全なのか
クラウドのデータベースには、世界中から届く公開の住所があります。『そんな場所に会社のデータを置いて大丈夫?』という不安はもっともです。でも実は、扉の前まで誰でも来られることと、扉が開くことは、まったく別の話です。
守りの正体は、扉を隠すことではなく“鍵の組み合わせの数”です。当てずっぽうが成立しない理由も、『利用者の誰かが偶然当てるのでは』が起きない理由も、鍵の差し替え（ローテーション）をいつやるべきかも、すべてこの数から素直に導けます。
接続はできても、照合で止まる
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「“当てずっぽうの接続”に何が起きるか」。参加者4人、ステップ8個。 【参加者】（左から右） - 正規のアプリ: 強い鍵を持つ - 公開の受付: クラウド DB の入口 - データベース: 守られる中身 - 攻撃者: 当てずっぽうの接続 【流れ】（上から下へ） ── ① 正規のアプリの接続 ── 1. 正規のアプリ → 公開の受付: TLS で接続し、強い鍵を提示 2. 公開の受付（自身で処理）: 鍵を照合 3. 公開の受付 → データベース: 照合 OK の相手だけ中へ 4. 公開の受付 → 正規のアプリ: データを返す（応答） ── ② 当てずっぽうの接続 ── 5. 攻撃者 → 公開の受付: 接続自体はできる（入口は公開） 6. 攻撃者 → 公開の受付: 鍵を当てずっぽうで提示 7. 公開の受付 → 攻撃者: 照合失敗 — 中の様子は何も分からない（応答） 8. 公開の受付（自身で処理）: 失敗を繰り返す相手を絞る
確率の物差し — “偶然当たる”はどれくらい起きないか
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。3列 × 4行。 【列】 1. 組み合わせの数（空間の広さ） 2. 当たる見込み（現実的に?） 3. 守り方（何で防ぐ?） 【比較】（観点ごとに） ■ 4 桁の暗証番号 - 組み合わせの数: 1 万通り / すぐ数え切れる - 当たる見込み: 総当たりなら一瞬 - 守り方: 回数制限（3 回でロック） ■ ジャンボ宝くじ 1 等 - 組み合わせの数: 1000 万通り - 当たる見込み: 買い続ければ積み上がる - 守り方: （比較のための物差し） ■ クラウドが生成する強い鍵 - 組み合わせの数: 10 の 36 乗通り級 / 0 が 36 個 - 当たる見込み: 宝くじ 1 等 5 回連続の規模 / 毎秒 10 億回でも宇宙の年齢超え - 守り方: 鍵の強さそのもの＋試行制限 ■ “利用者の誰か”が当たる? - 組み合わせの数: 空間はそのまま / 誕生日のパラドックス? - 当たる見込み: 全利用者×100 年でも約 300 億分の 1 - 守り方: 空間が広すぎて“みんなで引いても”埋まらない
ローテーションは定期? イベント駆動?
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 5行。 【列】 1. 定期で回す（カレンダー駆動） 2. イベントで回す（出来事駆動） 【比較】（観点ごとに） ■ 推測（総当たり）への効果 - 定期で回す: 無い / 引き直しても確率は同じ - イベントで回す: 無い / 同じく ■ 漏洩への効果 - 定期で回す: 被害期間を最長 90 日等に区切る / 気づけない漏洩の保険 - イベントで回す: 疑いの時点で即失効 / 被害を最短で断つ ■ 回すきっかけ - 定期で回す: カレンダー（90 日ごと等） - イベントで回す: 漏洩の疑い・人の出入り・端末紛失 / 事業者の告知も ■ 作業事故のリスク - 定期で回す: 作業のたびに発生機会 / 貼り忘れ・環境ズレで障害 - イベントで回す: 回数が少なく手順を磨ける / 金庫 1 箇所化とセットで ■ 業界の流れ - 定期で回す: 見直されつつある / 強制変更は弱い鍵を生む - イベントで回す: 主流 / 自動化＋出来事をきっかけに
“公開の入口＋強い鍵”は標準の形
ソースコード置き場のアクセストークンも、クラウドの API キーも、サーバー接続の鍵も、みな同じ構造です。経路を隠すのではなく、秘密の強度で守るのがインターネットの標準モデル。『入口が公開されている＝危ない』ではなく、『秘密が強く・漏れていない＝安全』と捉え直すのがこの世界の考え方です。
怖いのは“空間が狭くなる”こと
偶然の一致より、組み合わせの数を狭める実装・運用のミスが現実の事故を生みます。4 桁の暗証番号、推測できる連番の ID、そして乱数の不具合 — 過去には生成される鍵が実質 3 万通りほどに縮み、総当たりできてしまった実例もあります。マネージドサービスを使う利点の一つは、鍵生成の乱数品質を事業者が担保し、不具合があれば一斉に検知・差し替えされることです。
ローテーションより先にやる漏洩対策
守るべきは接続文字列そのものです。優先順位は、①誤コミットの防止と自動検知（.env を公開してしまうと数分で拾われます）、②本番用と開発用で鍵を分けて被害範囲を区切る、③ログやエラー画面に接続文字列を出さない、④差し替え箇所を金庫 1 箇所に集約して『いつでも安全に回せる』状態を作る。回すのはイベントが起きたときだけで構いません。
押さえておきたい用語
- 接続文字列
- エントロピー（鍵の強さ）
- 総当たり攻撃（ブルートフォース）
- レート制限
- 誕生日のパラドックス
- イベント駆動ローテーション