アクセス デニード(Access Denied)📒

ある日突然、ネットスーパーで決済できない。
以下、トラブル中にClaudeに相談した内容を時系列にまとめてもらった。
たまたま、スーパーで買い物が出来ずに2日で復旧したけれど。
（それでもかなり困ったけど）
これで不渡りを出して倒産したらどうなるのか。ガクガクブルブル…

「Access Denied」の犯人を三度も間違えた話 —— 誰も直せない層の存在について

症状

ネットスーパーで決済しようとすると、見慣れない画面が出る。

Access Denied
You don't have permission to access "..." on this server.
Reference #18.xxxxxxxx.xxxxxxxxxx.xxxxxxxx

条件を整理すると、こうなった。

• スマートフォンでもPCでも同じ

• 支払いカードを変更しても同じ

• カードのブランドを変えても同じ

「カードを変えても直らない」時点で、決済の問題ではないことは分かる。そもそも決済処理まで到達していない。Webサーバの手前で403を返されている。

切り分け

端末が二つとも同じなら、共通因子を探すことになる。共通しているのは三つしかない。

1. 出口のグローバルIPアドレス

2. 経路の書き換え（VPN、プライベートリレー、DNS設定）

3. アカウント側の状態

一番手っ取り早いのは、スマートフォンのWi-Fiを切ってモバイル回線だけで開くこと。これで通れば①か②、通らなければ③。

結果、モバイル回線では通った。自宅回線のIPが弾かれている、で確定。

犯人探しが三回外れる

一回目：ネットスーパー

最初はネットスーパー側のWAFがブロックしていると考えた。妥当な仮説に見えたが、外れ。

二回目：カード会社

エラー画面のURLをよく見ると、アクセス先はネットスーパーではなく、カードの本人認証サービス（3-Dセキュア）の認証サーバだった。パスに 3dsmethod とあり、決済確定の直前に端末情報を収集する工程を指す。

つまりブロックしていたのは認証基盤側。宛先はカード会社だと判断した。

問い合わせた。「分かりません」と言われて終わった。

三回目：実はCDN

その後、別ブランドのカードでも同じ症状が出た。ブランドが違えば認証サーバの運用元も違う。にもかかわらず同じエラーが出るなら、共通しているのはもう一段手前しかない。

エラーページのドメインは errors.edgesuite.net
—— Akamaiのものだった。

Akamaiという層

Akamaiは1998年にMITの研究から生まれた米国の企業で、CDN（コンテンツ配信網）事業者としては最古参にあたる。

やっていることを物流に翻訳すると分かりやすい。中央倉庫から全国に直送するのではなく、各地にデポを置いて近い場所から出荷する。リードタイムの短縮と幹線の負荷分散。発想としてはまったく同じだ。

そして、すべての通信が必ずそこを経由するということは、そこに検品工程を挟めるということでもある。配送網を持っていたら検問所として使うのが合理的だった、という順序で、今ではCDN事業者はどこもセキュリティ機能を主力にしている。

Webトラフィックの相当な割合がここを通っている。銀行、航空会社、通販、動画配信、そしてカード決済の認証基盤。日常的に何度も通過しているが、利用者が名前を知る機会はほぼない。エラー画面が出て初めて存在に気づく。

なぜ無関係の人間が弾かれるか

日本の家庭用光回線の多くは、IPoE方式で1つのIPv4アドレスを数十〜数百世帯で共有している。IPv4アドレス枯渇への対応措置だ。

CDNのWAFはIPアドレス単位で評価を持つ。同じIPを共有している誰かが不審な通信をすれば、無関係の世帯が巻き添えで弾かれる。共有相手は選べないし、防ぎようもない。

相手は人間ですらないかもしれない。マルウェアに感染したまま放置された家電やルータが勝手に通信していることもある。あるいは単なる誤検知の可能性も普通にある。

結末

2日放置していたら直った。

Akamaiのこの手のIP評価は時間で自動的に減衰する。数時間から数日で判定が解除されるので、何もしなくても戻るのは典型的な挙動だ。

つまり正解は「待つ」だった。

誰も直せない

ここからが本題になる。

直せる主体がいないわけではない。CDN事業者は自社のIP評価を調整できるし、認証基盤の運用元もカード会社も契約者としてルール変更を要求できる立場にある。加盟店も決済代行経由で同じことができる。

問題は、利用者からの申告を技術部門まで届ける経路が存在しないことだ。窓口で止まる設計になっている。

決済の経路は、加盟店 → 決済代行 → カード会社 → 認証基盤 → CDN と連なっていて、各社は隣接する一段しか見ていない。障害が起きたのは、どの会社の管轄でもない継ぎ目の部分だった。

問い合わせを受けた担当者の「分かりません」は実のところ正確な回答だ。自社の設備でも委託先でもなく、CDN事業者がIP評価をどう扱ったかという話なのだから。参照する権限も手段もない。言われた側としては何の役にも立たないが。

電力網との比較

送配電の保守部隊との違いを考えると、構造がはっきりする。

送電網の保守は、個別の需要家を見ている。「〇〇町3丁目が停電」という単位で認識し、現場に人を出す。苦情の受け皿があり、そこから作業班に繋がる経路が制度化されている。

CDNが見ているのはトラフィックの統計だ。個々のIPが弾かれているかどうかは監視対象ですらない。むしろ「弾いている」ことは正常動作であって、障害ではない。

そして決定的なのは、CDN事業者にとっての顧客は認証基盤の運用元であって、末端の利用者ではないことだ。電力なら需要家が契約者だが、ここでは利用者は契約関係の外側にいる。誰の顧客でもない存在からの申告は、受け取る窓口そのものが存在しない。

電線の保守部隊はいる。ただし彼らが守っているのは「電気を安定して流すこと」ではなく「不正な電気を止めること」だ。今回起きたのは、その部隊が正しく仕事をした結果、正規の配電も止まったという事態だった。故障ではないので、修理の対象にならない。

閾値の非対称性

送配電には供給義務がある。法に基づく制度で、止めれば責任を問われる。

CDNのWAFにそういう義務はない。むしろ逆で、過剰に通すことのほうがリスクになる。誤って攻撃を通せば顧客が損害を被る。誤って正規利用者を弾いても、損害は末端に落ちるだけで契約上は何も起きない。

コストが非対称なので、判定は保守側に倒れ続ける。

検査工程の判定閾値と同じ話だ。見逃しのコストと過検出のコストが非対称なら、閾値は必ず過検出側に倒れる。そして過検出のコストを負担するのが工程の外側にいる誰かであるとき、閾値を戻す圧力は構造的に発生しない。

さらに、放置しても自然回復するので苦情は消える。改善する動機がどこにも働かない。

誰かの怠慢というより、インセンティブがそう配置されているだけだ。悪意を探しても何も出てこない。

実務的な結論

同じ症状に遭遇した場合。

切り分け：Wi-Fiを切ってモバイル回線で試す。通れば回線側の問題で、端末もカードもサービスも無実。この一手で一気に絞れる。

回避：決済のときだけモバイル回線に切り替える。カゴに入れるところまでは自宅回線でよく、支払いボタンの前に切り替えるだけ。手間は数秒。

対処：数日待つ。問い合わせは、おそらく無駄になる。

やらないほうがいいこと：リロードの連打はIP評価をさらに悪化させる。VPNも逆効果になりがちで、VPN事業者のIPは拒否リストに載っている率が家庭用回線より高い。

残るもの

回避策があるだけマシ、というのが現実的な着地になる。モバイル回線に切り替えれば買い物はできる。解決ではなく迂回だが、迂回路があるうちは実害が出ない。

ただ、これを「まあいいか」で処理していいのかというと…
そうとも思わない。個人が費やせるコストと得られる成果が釣り合わない領域である、というだけの話ではある。

インフラが正常に機能しているとき、その存在は誰にも見えない。壊れたときに初めて層の厚さが見え、同時に誰もそこに手が届かないことも見える。