防御の設計/ Defense in Depth

外側から内側へ、粗いものから細かいものへと 4 段階に絞ります。それぞれ数える単位が違うので、どこか 1 つをすり抜けても次で捕まります。

数え方の違いが効く場面

たとえば、1 本のリンクのパスワードを総当たりしようとした場合。第 3 層で端点別のレート制限に絞られ、それでも続けると第 4 層が立って正しいパスワードを入力しても 1 時間開きません。接続元 IP を次々に変えても、第 3 層と第 4 層はリンク側で数えているため効きません。逆に、たくさんのリンクへ広く浅く当たろうとすれば、第 1・第 2 層が IP 側で数えて止めます。

発行する側にも上限がある

発行の API にも、ログインした利用者ごとの上限を置いています。パスワードのハッシュ計算は 1 回あたり数十ミリ秒の CPU を使うため、機械的な連打で処理能力を占有されないようにするためです。人が手で操作する範囲では到達しない値で、こちらは数える仕組みが壊れたときは通す側に倒しています（発行業務そのものを止めないため）。

共有リンクの最初の鍵は URL そのものです。ここが弱いと、他の層が全部無駄になります。

256 bit は、仮に 1 秒あたり 1 兆回の試行を続けても宇宙の年齢では到底終わらない規模です。実際にはその手前で第 1〜第 3 層のレート制限が働くため、総当たりは成立する前に止まります。

存在しないトークンへのアクセスも記録します。ただし、アクセス記録は「どのリンクへのアクセスか」を必ず持つ形になっているため、存在しないリンクの分は監査ログ側へ「不明なリンクへのアクセス」として残します。

パスワードも確認コードも、元に戻せない形で保存します。データベースを丸ごと持ち出されても、そこから値そのものは取り出せません。

scrypt と HMAC の使い分け

パスワードは人が決めた短い文字列なので、総当たりに耐える必要があります。scrypt はわざと計算を重くする方式で、しかもメモリを要求するため、専用ハードウェアを並べて大量に試す攻撃に効きます。

一方、確認コードはシステムが生成する 6 桁で、有効期限が 10 分、1 つのコードにつき試行できる回数にも上限があります。総当たりの余地は仕組みの側で潰してあるので、重い計算は不要です。むしろ、受取人が画面の前で待っている場面で数十ミリ秒を積む方が損になります。

本人確認つきのリンクでは、受取人のメールアドレスを入力してもらいます。ここが素直な作りだと、「このリンクの受取人は誰か」を 1 件ずつ当てられます。

送信の上限を置いているのは、列挙とは別の理由もあります。60 秒に 1 回でも 1 日回し続ければ 1440 通になり、受取人のメールボックスへの嫌がらせに使えてしまいます。正規の利用（入力を間違えて 2〜3 回送り直す）には十分な余裕を残しつつ、この使い方を封じています。

ここまでの層はすべてアプリの中の話です。アプリに書き間違いがあれば通り抜けられます。そこでデータベース自身にも同じ制限を持たせて、アプリの外側からもう一度絞っています。

「最新版だけ」が効く場面

共有したあとにファイルが差し替えられた場合、受取人に見えるのは常に最新の検査済みの版です。過去の版は経路の外にあるため、版の識別子を直接指定してもたどれません。逆に、差し替えた新しい版がまだ検査中であれば、その間は検査済みの版が 1 つも無い状態になり、受取人からはダウンロードできなくなります。

共有リンクの URL は、それ自体が鍵です。どこかに写しが残ると、期限や回数の設定を回り込まれます。写しが残りうる場所を 1 つずつ塞いでいます。

リンクプレビューを固定にした理由

チャットやメールに URL を貼ると、多くのサービスが自動的にそのページを取りに行き、タイトルや説明文をカードとして表示します。ここに動的な値を入れると、クローラーが取得した内容が外部サービス側にキャッシュされます。パスワードを設定していても、カードにファイル名が出ていれば「何を渡したか」は漏れます。

そこで、プレビューに出すのは「共有ファイルの受け取り」という固定のタイトルと、松葉のブランド画像だけにしました。素の URL がそのまま出るより信頼できる見た目になり、なおかつ中身は一切漏れません。