Web3 ウォレットのインフラ｜AI 開発スタジオの事例

一行のミスが、資産流出に直結する世界

暗号資産を扱うサービスのインフラでは、設定の一行の誤りが、そのまま顧客資産の流出につながります。問題が起きてから直せばよい、という一般的なクラウドサービスの運用の前提が、ここでは通用しません。

案件初日に、チームが設計の原則として書き出したのは次の一文でした。

ここでは、ミスは取り返せないという前提で設計する。

本案件の WaaS（Wallet as a Service：顧客の暗号資産を預かり、その操作をサービスとして提供する仕組み）は、顧客の資産そのものを直接扱います。一度外部に送られた暗号資産は、原則として取り戻せません。

セキュリティと応答速度の両方に、最高水準が求められる現場でした。どちらかを優先する選択肢はなく、両立を当然の条件として設計を組み立てる必要がありました。

「内部ネットワークだから安全」という前提は、一切置きませんでした。サービス間の通信ひとつひとつで認証・認可を行い、監査ログを残す構成を、後付けではなく最初から組み込みました。

ゼロトラストは、「信頼を前提にしない」という設計思想です。ネットワークの内側だから安全、という発想を捨て、すべての通信を疑う立場で設計します。

この三点を後から付け足そうとすると、セキュリティの穴を残したまま運用に入ることになります。本案件では、最初の数週間で構成の骨格をゼロトラスト前提で固め、その後の作業はすべてその上で進めました。

ゼロトラストを徹底すると、通信のたびに確認処理が入るため、工夫せずに組むと応答が遅くなります。一方で暗号資産サービスでは、応答の遅れも許されません。

守りを重ねることと速度は、どちらかを削るしかない関係に見えます。実際には、設計の細部を詰めることで両方を満たせます。

インフラの設定は、管理画面での手作業に頼らず、すべてコードとして書き表しました。実行・通信・保管・認証の各層は、ほかの層に依存しない作りにしています。ある層だけを差し替えるときも、ほかの層に手を入れずに済みます。

クラウド上で動くサービスは、計算する場所、通信する経路、データを保管する場所、誰がアクセスできるかを制御する仕組みなど、複数の部品で構成されます。本案件ではそれぞれの部品の役割を、「実行・通信・保管・認証」の4層に整理しました。

設定をコードで管理し、レビューのときに「変更前後の差分を一行単位で確認できる状態」⁠を作りました。暗号資産の基盤の設定を手作業で変えていくと、何がどう変わったかを正確に確かめられず、ミスが紛れ込む余地が残ります。

認証の確認処理による遅れを、通信経路の最短化、認証結果の安全な短期保存、負荷が高まる前のサーバー自動増設で吸収しました。

速度を高める施策は、セキュリティを下げない範囲に限りました。わずかな妥協が、後で大きな損失につながりかねない領域だからです。

暗号資産の基盤では、変更前のレビュー、影響範囲の確認、本番反映前のテストのいずれも、ほかの領域より一段慎重に行います。インフラの上で動くウォレットアプリと整合がとれた状態で運用に引き渡すところまでが、納期に含まれていました。

「事故が起きてから直す」運用は、この領域では許されません。設定のささいなミスも見逃さない前提で、先に挙げた確認とテストを一つ残らず終えてから、運用に引き渡しました。

やり直しのきかない領域では、勝負は本番に出す前に決まっている。