鍵の強さと確率
「入口が誰にでも見えているなら、中にも入られてしまうの？」
入口への到達と鍵の確認を分け、推測されにくい鍵でも残るリスクを見てみましょう。
01思い込み
入口が見えている！
接続できるだけ誰でもここまで来られるなら、中も見られるの？
02予想外
鍵が合わなかった
照合は別入口には届いても、鍵が合わなければ開かないんだ。
03理由
組み合わせが膨大
推測を難しく長くランダムな鍵ほど、当てずっぽうで探すのが難しいね。
04捉え直し
強さと漏洩は別
漏洩は別に備える入口が見えるだけでは入れない。でも鍵が漏れたら失効と交換だ。
接続できることと、操作できることはどう違うのか
クラウドのデータベースには、公開エンドポイントで接続できるものがあります。『そんな場所に会社のデータを置いて大丈夫?』という不安はもっともです。でも実は、扉の前まで誰でも来られることと、扉が開くことは、まったく別の話です。
長くランダムな鍵は推測への備えになります。ただし、漏洩・権限の渡しすぎ・実装の弱点は別の問題です。まず仮定を置いて推測の確率を考え、更新や失効の方針は資格情報の用途ごとに整理します。
接続はできても、照合で止まる
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「“当てずっぽうの接続”に何が起きるか」。参加者4人、ステップ8個。 【参加者】（左から右） - 正規のアプリ: 強い鍵を持つ - 公開の受付: クラウド DB の入口 - データベース: 守られる中身 - 攻撃者: 当てずっぽうの接続 【流れ】（上から下へ） ── ① 正規のアプリの接続 ── 1. 正規のアプリ → 公開の受付: TLS で接続し、強い鍵を提示 2. 公開の受付（自身で処理）: 鍵を照合 3. 公開の受付 → データベース: 照合 OK の相手だけ中へ 4. 公開の受付 → 正規のアプリ: データを返す（応答） ── ② 当てずっぽうの接続 ── 5. 攻撃者 → 公開の受付: 接続自体はできる（入口は公開） 6. 攻撃者 → 公開の受付: 鍵を当てずっぽうで提示 7. 公開の受付 → 攻撃者: 照合失敗 — 中の様子は何も分からない（応答） 8. 公開の受付（自身で処理）: 失敗を繰り返す相手を絞る
鍵の推測を、明示した仮定で計算する
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。3列 × 4行。 【列】 1. 組み合わせの数（空間の広さ） 2. 当たる見込み（現実的に?） 3. 守り方（何で防ぐ?） 【比較】（観点ごとに） ■ 4桁の暗証番号 - 組み合わせの数: 1 万通り / すぐ数え切れる - 当たる見込み: 試行制限が重要 - 守り方: 回数制限（3 回でロック） ■ 仮想のくじ - 組み合わせの数: 1000 万通り - 当たる見込み: 買い続ければ積み上がる - 守り方: （比較のための物差し） ■ 等確率で選ぶ鍵の例 - 組み合わせの数: 仮定：10の36乗通り / 約119.6bit - 当たる見込み: 推測で当てるのは非現実的 / 生成方法と試行モデルが前提 - 守り方: 鍵の強さそのもの＋試行制限 ■ 多数の対象を狙う場合 - 組み合わせの数: 空間はそのまま / 等確率の鍵を仮定 - 当たる見込み: 100年間でも約317億分の1 - 守り方: 空間が広すぎて“みんなで引いても”埋まらない
パスワードと機械用資格情報の更新方針
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 5行。 【列】 1. 人間のパスワード（利用者が選ぶ秘密） 2. 機械用の資格情報（APIキー・DB等） 【比較】（観点ごとに） ■ 守りの基本 - 人間のパスワード: 長さ・漏洩対策・MFA / 用途に応じて判断 - 機械用の資格情報: 短期資格情報を優先 / 用途に応じて判断 ■ 平時の更新 - 人間のパスワード: 不要な定期変更を強制しない / 用途に応じて判断 - 機械用の資格情報: 用途に応じ自動更新を設計 / 用途に応じて判断 ■ 漏洩の疑い - 人間のパスワード: 変更・関連セッションを確認 / 用途に応じて判断 - 機械用の資格情報: 速やかに失効・交換 / 用途に応じて判断 ■ 切替時の注意 - 人間のパスワード: 本人確認・復旧手段も保護 / 用途に応じて判断 - 機械用の資格情報: 発行元・金庫・利用側を連携 / 用途に応じて判断 ■ 判断の根拠 - 人間のパスワード: 人間向け認証の指針 / 用途に応じて判断 - 機械用の資格情報: 製品の推奨・規定・リスク / 用途に応じて判断
長くて強い鍵でも、コピーされたら？
十分に長い乱数の鍵は、当てずっぽうで探す攻撃に強くなります。しかし、その鍵をソースコードやログからコピーされると、攻撃者は候補を探す必要がありません。「推測されにくさ」と「漏らさない扱い」は、別々に守る必要があります。
生成時には、暗号用途に適した乱数を使います。候補数が多く見えても、値が偏っていたり次の値を予測できたりすれば、想定した強さにはなりません。実装やサービスの生成方法を確認します。
運用では、本番と開発の資格情報を分け、取得権限を必要最小限にします。誤コミットを防ぎ、ログに秘密を出さず、更新と失効を自動化します。漏洩時は予定の交換日を待たずに対応できるようにします。
システム全体の安全とは別
公開の経路でも適切に設計できますが、強い鍵とTLSだけでは足りません。認可、脆弱性対策、漏洩対策、監視を組み合わせます。
押さえておきたい用語
- 接続文字列
- エントロピー（鍵の強さ）
- 総当たり攻撃（ブルートフォース）
- レート制限
- 誕生日のパラドックス
- イベント駆動ローテーション