全国クレカ決済とAWSが同日に相次ぎダウン ― 見えない「単一障害点」のリスク

朝と夕方、二度落ちたインフラ #

7月16日午前8時ごろ、全国でクレジットカード決済ができない障害が発生した。LIXILやサンドラッグのECサイト、大塚商会のWeb請求、モバイルSuica・モバイルPASMOのチャージ、d払いでのカード払いなど、影響は決済の枠を超えて交通・小売・法人請求にまで広がった。運営元とされるCARDNETは「自社の障害ではない」と説明し、Visa子会社のCyberSourceは「取引処理のタイムアウトが発生した」と述べたが、これらが同一原因を指すのかは公表されていない。

同日午後5時40分ごろには、本来無関係のはずのAWS CloudFrontが世界規模で障害を起こした。日本ではPayPay、note、ニコニコ生放送、はてなブログが軒並み繋がりにくくなり、皮肉にも朝と同じPayPayが再びダウンする形になった。

「誰の障害か」が分からないという恐怖 #

この一日が突きつけたのは、障害の規模そのものより「説明責任の所在が誰にも分からない」という構造だ。決済は加盟店→カード会社→国際ブランド→決済代行という何層ものレイヤーが連鎖しており、一枚のカードの裏には見えない仲介者が何社も連なっている。CDNも同様に、無数のサービスがAWSという単一のクラウド事業者・単一のエッジ網に依存している。攻撃者が仕掛けたわけでなくとも、たった一つの結節点の不調が、一見無関係なサービス群を同時に沈黙させる。これは可用性(Availability)という、セキュリティの三要素(CIA)の一角が持つ脆さそのものだ。

BCPは「自社の外」まで見る必要がある #

セキュリティ対策というと自社システムの防御に目が向きがちだが、今回の教訓は依存先の可用性そのものがリスクだということだ。決済代行やCDNのようなクリティカルな外部依存を洗い出し、代替経路(オフライン決済への切替手順、マルチCDN構成、キャッシュ戦略)を用意しておくことが、攻撃されるより先に「止まる」現実への備えになる。単一障害点を数えられない組織は、事業継続計画も絵に描いた餅で終わる。攻撃を防ぐだけでなく、止まった後どう生き延びるかを設計する視点が、これからのセキュリティ担当者には求められる。