コールドストレージとマルチシグウォレット:暗号資産取引所が数十億ドルを守る方法
目次
- 2022年だけで38億ドルが盗まれた。その多くは防げたはずだ
- コールド/ホット/ウォームウォレットのアーキテクチャ(95/5ルール)
- マルチシグセキュリティ:単一障害点の排除
- APIセキュリティ:多くの取引所が開け放したままの正面玄関
- DDoS対策:盗めないなら破壊しようとする攻撃者たち
- 内部セキュリティ統制:最大の脅威は社員証をぶら下げている
- KYC/AML:合法であり続けるためのセキュリティ
- インシデント対応:使わずに済むことを祈る計画
- 取引所運営者のためのセキュリティ監査チェックリスト
- Codonoのセキュリティへの取り組み
- セキュリティマインドセット
2022年だけで38億ドルが盗まれた。その多くは防げたはずだ
すべての取引所運営者が夜も眠れなくなるべき話をしましょう。暗号資産取引所へのハッキングが、いかに予測可能なパターンに従っているかという話です。
Ronin Networkが2022年3月に6億2500万ドルを失ったとき、根本の原因は巧妙なゼロデイ攻撃などではありませんでした。バリデーターの秘密鍵が侵害されたのです。9つのバリデーターのうち5つが単一の主体に支配されており、攻撃者はソーシャルエンジニアリングでブリッジを空にするのに十分な鍵を手に入れました。2014年に85万BTCが消えてMt. Goxが崩壊したとき、その背景にはホットウォレットの管理不備、マルチシグ統制の完全な欠如、そしてほぼ存在しない内部監査証跡がありました。ではFTXの破綻は?あれは厳密にはハッキングですらありませんでした。顧客資金への無制限のアクセスを持つ内部者がいて、それを止める運用統制が一切なかったのです。
何度も見てきた者にとって、そのパターンは痛いほど明白です。実際、私たちは見てきました。500以上の取引所のプラットフォーム構築とセキュリティ確保を支援してきましたが、失敗の形はほぼいつも同じです。取引所を倒すのは、高度な国家レベルの攻撃ではありません。退屈な基本的ミスです。ずさんな鍵管理。単一障害点。神モードのアクセス権を持つ管理者アカウント。スイープを回すのが面倒だからと、本来あるべき量をはるかに超える暗号資産が詰め込まれたホットウォレット。
ここからは、実際に機能する方法をお話しします。「軍事レベルの暗号化」や「AI搭載の脅威検出」といったマーケティング用語のバージョンではなく、本物のバージョンです。優れたセキュリティアーキテクチャは徹底的に地味であり、それこそが効果的である理由だとお伝えするバージョンです。
コールド/ホット/ウォームウォレットのアーキテクチャ(95/5ルール)
取引所のセキュリティ対策を1つだけ導入するなら、これにしてください。顧客資金の95%以上を、常にコールドストレージに保管するのです。
コールドストレージとは、秘密鍵がインターネット接続されたデバイスに一度も触れないことを意味します。一切例外なしです。鍵はオフラインで生成され、ハードウェアセキュリティモジュールやエアギャップされたコンピューターに保管され、トランザクションは物理的に隔離された環境で署名されます。秘密鍵がネットワークに接続されたマシン上に存在した瞬間、それは標的になります。コールドストレージは、その攻撃面全体を排除します。
しかし、コールドストレージだけで取引所は運営できません。ユーザーは暗号資産の入出金を数時間ではなく数分で済ませたいと期待しています。そこで登場するのが、ホットウォレットとウォームウォレットの層です。
ホットウォレットは最前線です。インターネットに接続され、取引所の出金システムと統合され、通常の出金量を処理するのに十分な量(通常は総資金の2〜5%)だけを保持します。小売店のレジの現金だと考えてください。おつりに十分な紙幣は入れておきますが、その日の売上全額を引き出しに入れておくことはしません。
ウォームウォレットはホットとコールドの中間に位置します。準接続状態で、たとえばホットウォレットを補充するためのスケジュールされた時間にのみオンラインになるシステム上にあります。ウォームウォレットは資金の5〜10%を保持し、定常業務のためにコールドストレージにアクセスする必要がないよう、バッファーとして機能します。
コールドウォレットはその他すべて、つまり大多数、85〜95%を保持します。
スイープの仕組み
流れはこうです。入金は入金アドレスに届きます。これは実質的に一時的なホットウォレットです。スイーププロセスが定期的にこれらのアドレスから入金を回収し、集約します。少額はホットウォレットに移され、運用残高が維持されます。それ以外はすべてコールドストレージにスイープされます。
出金側では、ユーザーが出金をリクエストすると、ホットウォレットから支払われます。ホットウォレットの残高がしきい値を下回った場合、誰か(理想的には2人の誰か、詳しくは後述)がウォームウォレットからの補充送金を承認します。コールドストレージに触れるのは、大規模で計画された資金移動のときだけです。そしてそれらは、複数の承認、物理的な立ち会い、文書化されたプロセスを必須とすべきです。
実際の数字は取引所の規模によって異なります。1日100万ドルの出来高の小規模取引所なら、ホットウォレットに5万ドルを置くかもしれません。1日5000万ドルの中堅取引所なら、50万〜100万ドルをホットに保持するかもしれません。重要な指標はこうです。ホットウォレットで通常の出金需要の4〜8時間分をカバーできるか?イエスなら、おそらく適正サイズです。それ以上を保持しているなら、不要なリスクを取っています。
堅牢な暗号資産ウォレットインフラは、スイープスケジュール、しきい値の監視、層間の自動リバランスといったこのすべてを処理します。しかし最高のソフトウェアも、その周囲に張り巡らされたポリシーと同じ品質にしかなりません。そこでマルチシグの出番です。
マルチシグセキュリティ:単一障害点の排除
マルチシグ(マルチシグネチャ)ウォレットは、トランザクションの承認に複数の秘密鍵を要求します。シンプルな概念ですが、セキュリティへの影響は絶大です。
マルチシグがなければ、1つの鍵の侵害が全損を意味します。フィッシングにかかった従業員1人、盗まれたハードウェアウォレット1つ、悪意ある内部者1人で、資金は消えます。マルチシグはその計算を根本から変えます。攻撃者は今や、理想的には異なる場所で異なるセキュリティ慣行を用いる異なる人物が保持する、複数の独立した鍵を侵害しなければなりません。
マルチシグの現代的な後継は、このアイデアをさらに推し進めています。しきい値MPCは完全な鍵そのものを排除するため、個々の署名者からさえ盗むべきものが存在しません。詳しくはCodono EnterpriseのMPC署名者の仕組みで解説しています。
一般的なマルチシグ構成
2-of-3: 3つの鍵が存在し、任意の2つでトランザクションを承認できます。これは取引所運営における最小限の実用的マルチシグです。典型的には、1つをCEO/創設者、1つをCTOまたはセキュリティ責任者が保持し、1つをバックアップとして安全な金庫に保管します。1つの鍵が侵害されても保護されつつ、1人の鍵保持者が不在でも運用を継続できます。
3-of-5: 5つの鍵で3つが必要。多額の資産を保持するコールドストレージウォレットに私たちが推奨する構成です。鍵は経営陣、取締役、さらには外部カストディアンに分散させます。地理的分散も重要です。鍵は異なる物理的場所、理想的には異なる都市や国に置くべきです。5人の鍵保持者のうち3人が同じオフィスで働いているなら、1回の物理セキュリティインシデントで全体が危険にさらされ得ます。
4-of-7: 数億ドルを保持する大規模取引所向け。要求される署名が多いほど攻撃は困難になりますが、すべてのトランザクションの運用複雑性も増します。このレベルでは、タイムロック(署名後24〜48時間はトランザクションが実行されず、不正なトランザクションを検出・キャンセルする猶予を確保)と、鍵の生成・保管のためのハードウェアセキュリティモジュールも導入しているでしょう。
それぞれの構成が適するケース
カストディ総額が100万ドル未満で始めるなら?2-of-3で十分です。運用の悪夢を生まずに意味のある保護が得られます。カストディが1000万ドルを超えたら、ウォームウォレットは2-of-3のまま、コールドストレージは3-of-5に移行します。1億ドルを超えたら、地理的分散、タイムロック、そしておそらく何らかの機関投資家向けカストディパートナーシップを伴う4-of-7を検討すべきです。
重要なルールはこれです。コールドストレージから資金を単独で動かせる人物がいてはならない。例外なし。あなたの取引所がCEO一人でコールドウォレットを空にできる構成なら、それはセキュリティアーキテクチャではありません。「CEOが正直であり続けますように」という祈りのアーキテクチャです。FTXが持っていたのはそれであり、結末がどうなったかは皆が見た通りです。
APIセキュリティ:多くの取引所が開け放したままの正面玄関
取引所のAPIは、世界があなたのプラットフォームとやり取りするための窓口です。取引ボット、マーケットメーカー、機関投資家クライアント、モバイルアプリ、そのすべてがAPIを叩きます。同時に、あらゆる取引所で最も攻撃される領域でもあり、毎秒数千のリクエストを処理し、その多くは24時間体制で弱点を探る自動化システムからのものです。
レート制限:最初の防御ライン
レート制限は単なる悪用防止ではありません。侵害された1つのAPIキーが数秒でアカウントを空にできないようにするためのものです。
スマートなレート制限は複数のレベルで機能します。
- IPごとの制限: 単一のIPアドレスからのリクエスト数に上限を設けます。一般的なエンドポイントには1分あたり1,200リクエストが妥当なデフォルトです。機微な操作にはより厳しく。
- アカウントごとの制限: 認証済みリクエストにも上限を設けるべきです。正当な取引ボットなら1秒あたり10件程度の注文かもしれません。あるAPIキーが突然1秒あたり1,000件の出金リクエストを出し始めたら、それはボットではなく攻撃です。
- エンドポイントごとの制限: 出金エンドポイントは、マーケットデータエンドポイントより劇的に低いレート制限を設けるべきです。1分間に50件の出金リクエストを正当に必要とする人はいません。
- 段階的対応: 初回の違反には穏やかな速度低下を。繰り返しの違反には一時的なBANを。継続的な悪用には永久ブロックとアカウントのセキュリティレビューを。
HMAC署名認証
注文の発注、出金、残高確認など、アカウント操作を伴うすべてのAPIリクエストは、HMAC(Hash-based Message Authentication Code)署名で認証されるべきです。
実際の仕組みはこうです。ユーザーはAPIキー(公開識別子)とシークレットキー(決して通信上で送信されない)を持ちます。リクエストを行う際、クライアントはリクエストパラメータとタイムスタンプをシークレットキーでハッシュ化して署名を生成します。サーバーはリクエストを受け取り、自身が持つシークレットキーのコピーで署名を再生成し、一致するか検証します。タイムスタンプが30秒以上古い場合は拒否します。これにより、署名済みリクエストを傍受して再利用するリプレイ攻撃を防ぎます。
これは基本中の基本です。取引所のAPIが認証済みエンドポイントにHMAC署名を要求していないなら、深刻な問題があります。
IPホワイトリスト
ユーザーが自分のAPIキーを特定のIPアドレスに制限できるようにします。3台の既知のサーバーからボットを運用しているマーケットメーカーは、APIキーをその3つのIPにロックできるべきです。誰かがAPIキーを盗んで別のIPから使おうとしても、リクエストは拒否されます。
この1つの機能だけで、APIキーの盗難の大多数が実際の資金損失につながるのを防げます。利用可能にし、目立たせ、出金権限を持つAPIキーでは必須化も検討してください。
取引所運営パネルは、セキュリティチームにAPI使用パターンのリアルタイムな可視性を提供すべきです。突然のスパイク、異常な地理的発信元、新しいIPから使われるキー。検知は防止とほぼ同じくらい重要です。
DDoS対策:盗めないなら破壊しようとする攻撃者たち
暗号資産取引所へのDDoS(分散型サービス拒否)攻撃は、絶え間なく続いています。時々ではなく、常時です。市場が変動する時期(まさに取引所が稼働している必要があるとき)には、攻撃量が10〜20倍に跳ね上がることがあります。攻撃者は、ユーザーを自分たちのプラットフォームに押しやろうとする競合から、取引所がオフラインになり市場がパニックになることで利益を得る空売り筋、ビットコインの身代金を要求する古典的な恐喝者までさまざまです。
レイヤー3/4保護(ネットワークレベル)
これはボリュメトリック攻撃の緩和です。サーバーに到達する前に大量のジャンクトラフィックの洪水を吸収します。Cloudflare、Akamai、AWS ShieldのようなCDN/DDoS緩和プロバイダーが必要です。自分で対処しようとしてはいけません。本格的なDDoS攻撃は500Gbps以上のトラフィックを押し寄せることがあります。大容量のアップストリーム帯域を備えた自社データセンターを所有していない限り、この種の洪水を吸収すること自体が事業であるプロバイダーが必要です。
Cloudflareの無料プランでは取引所には足りません。BusinessまたはEnterpriseプランが必要です。高度なDDoS保護、APIトラフィックパターンに合わせてカスタマイズされたWAFルール、セキュリティチームによる24時間365日のサポートが含まれます。最低でも月額200〜500ドルを予算に。安い保険です。
レイヤー7保護(アプリケーションレベル)
こちらは巧妙な攻撃です。生の帯域で押し流すのではなく、正当に見えるがアプリケーションを圧倒するように設計された、精巧に作られたリクエストを送りつけます。数千件の複雑なオーダーブッククエリ、大量のログイン試行、高コストなデータベース操作を引き起こすAPIリクエストなどです。
レイヤー7保護とは以下を意味します。
- 悪意あるリクエストパターンを検出してブロックするWeb Application Firewall(WAF)ルール
- 不審なトラフィックへのチャレンジページ(CAPTCHA、JavaScriptチャレンジ)
- 地理的フィルタリング。特定の地域のユーザーにサービスを提供していないなら、攻撃時にその地域からのトラフィックをブロックまたはチャレンジできる
- リクエストパターン、マウスの動き、閲覧行動に基づいて人間のユーザーとボットを区別する行動分析
取引エンジンの分離パターン
多くの小規模取引所が見落としていることがあります。取引エンジンは公開向けWebサーバーから分離すべきです。DDoS攻撃でウェブサイトが落ちるのは最悪です。しかしそれでマッチングエンジンまで落ち、ユーザーが取引や出金を実行できなくなるのは、壊滅的です。
マッチングエンジンは、インターネットに直接公開されない別のインフラ上で実行してください。Webサーバーは内部メッセージキューを通じてマッチングエンジンと通信します。Webフロントエンドが落ちてもマッチングエンジンは動き続け、保留中の注文や取引に影響を与えることなくフロントエンドを復旧させられます。
内部セキュリティ統制:最大の脅威は社員証をぶら下げている
被害妄想に聞こえるかもしれません。違います。データは明確です。内部者の脅威は、取引所のセキュリティインシデントの不釣り合いなほど大きな割合を占めています。従業員の大多数が悪意を持っているからではなく(大多数は持っていません)、昇格されたアクセス権を持つ1人の悪意ある行為者が、千人の外部攻撃者よりも大きな被害を与えられるからです。
ロールベースアクセス制御(RBAC)
すべての管理者がすべてにアクセスする必要はありません。実際、どの管理者もすべてにアクセスすべきではありません。最小権限の原則を中心にアクセス制御を構築してください。
- カスタマーサポート担当はアカウント詳細と取引履歴を閲覧できる。残高の変更、KYCステータスの上書き、出金の処理はできない。
- コンプライアンス担当はKYC書類をレビューし、アカウントにフラグを立てられる。ウォレットインフラや取引システム設定にはアクセスできない。
- 財務チームは集計レポートと財務残高を閲覧できる。個別のトランザクションを開始することはできない。
- システム管理者はインフラを管理できる。秘密鍵へのアクセス権は持たない。
- 経営幹部はより広いアクセス権を持つが、機微な操作には依然として2人目の人物が必要。
Codono取引所管理パネルはこの原則を中心に構築されています。すべてのロールに特定の権限があり、その権限の拡大には明示的な承認が必要で、監査証跡が作成されます。
二人制ルール
金銭的損失につながり得るすべての操作に、2人の承認された人物を要求してください。以下が含まれます。
- 一定のしきい値(たとえば1万ドル)を超える出金
- ウォレット設定の変更
- 取引ペア設定の変更
- セキュリティ機能の無効化
- KYC/AMLフラグの上書き
- 新しい管理者アカウントの追加
1人が起案し、別の人物が承認します。両方の操作がタイムスタンプ、IPアドレス、デバイスフィンガープリントとともにログに記録されます。これは悪意ある内部者を防ぐだけでなく、侵害された管理者アカウントからも保護します。攻撃者が1人の管理者の認証情報を手に入れても、危険な操作には2人目の管理者の承認が必要です。
実際に意味のある監査証跡
取引所でのすべての操作、すべての取引、すべての出金、すべての管理者ログイン、すべての設定変更は、不変の監査ログを生成すべきです。「不変」が鍵となる言葉です。ログは、シニア開発者でさえ変更も削除もできないシステムに書き込まれるべきです。外部ロギングサービスに送信するか、追記専用ストレージに書き込むか、ブロックチェーンベースの監査証跡を使用してください。
これらのログは、フォレンジック上の命綱です。何かが(起こり得るかではなく、起こった)とき、何が、いつ、誰によって起こったかを正確に再構築する必要があります。完全な監査証跡がなければ、インシデント調査は推測頼みになり、規制当局の照会は悪夢になり、法的責任は天井知らずになります。
KYC/AML:合法であり続けるためのセキュリティ
KYC/AMLシステムを純粋なコンプライアンス要件、つまり規制当局が要求するから渋々実装するものだと考える傾向があります。それは間違いです。優れたKYC/AMLはセキュリティ層でもあります。
本人確認は、攻撃者が偽アカウントの軍団を作ってプラットフォームを悪用するのを防ぎます。トランザクションモニタリングは、アカウント乗っ取り、マネーロンダリング、内部者による操作を示し得る異常なパターンにフラグを立てます。制裁スクリーニングは、取引所が制裁対象組織の導管として使われるのを防ぎます。法的結果はさておき、それはどの取引所も望まない種類の法執行機関の注目を引くことになりがちです。
複数の法域と書類タイプにまたがる本人確認を処理する、Sumsubのような評判の良いKYCプロバイダーと統合してください。この技術は今や成熟しています。生体認証チェックを伴うリアルタイムのID確認は、ほとんどのユーザーにとって2分足らずです。それを省略したり中途半端に実装したりする言い訳はもはや存在しません。
インシデント対応:使わずに済むことを祈る計画
すべての取引所は、いずれセキュリティインシデントに直面します。直面するかもしれない、ではなく、直面します。問題は、5分で対応できるか、5時間かかるかであり、その差が、インシデントが管理可能な出来事で済むか、存続の危機になるかを決めることがよくあります。
インシデント対応計画がカバーすべきこと
検知: 何かがおかしいことをどうやって知るか?自動化された監視は、異常な出金パターン、ログイン異常、API悪用、サーバーリソースのスパイク、ウォレット残高の乖離をカバーすべきです。アラートしきい値は、感度不足より感度過剰の側に倒して設定してください。誤報の調査は面倒です。本物の侵害を見逃すのは致命的です。
封じ込め: 最初の5分間に何が起こるか?チームは、侵害が確認されてから60秒以内にすべての出金を一時停止できるべきです。「出金を止めるべきか会議で議論する」ではなく。「CEOの承認を取ろうとする」でもなく。即座に、自動的に、文書化された形で。オンコールの担当者は、出金を即座に停止する権限と技術的能力を持つべきです。
評価: 封じ込めたら、範囲を特定します。どのシステムが侵害されたか?どのアカウントが影響を受けたか?いくら持ち出されたか?攻撃経路は何か?ここで監査証跡がその価値を発揮します。
コミュニケーション: 何が起こったかをユーザーに伝えます。迅速かつ誠実に。セキュリティインシデントを生き延びる取引所は、それについて透明です。隠蔽しようとしたり、何日も沈黙したりする取引所は、憶測の渦に飲まれて破壊されます。数日ではなく数時間以内に公式声明を出してください。知っていることは具体的に、まだ知らないことは正直に。
復旧: 脆弱性を修正し、サービスを復旧させ、可能であれば影響を受けたユーザーの損失を補填します。そしてポストモーテムを公開します。暗号資産コミュニティは、インシデントをプロフェッショナルかつ透明に処理する取引所を尊重します。
改善: すべてのインシデントは学びの機会です。学んだことに基づいてセキュリティアーキテクチャを更新します。同様の攻撃を想定した机上訓練を実施します。同じ経路が二度と悪用されないことを確認します。
四半期ごとに机上訓練を実施する
チームを集めてください。シナリオを提示します。「土曜日の午前3時。監視システムが、過去15分間に500BTCがホットウォレットから未知のアドレスに送金されたとアラートを出した。どうする?」対応を一歩ずつ歩いて確認します。本物の攻撃者に見つけられる前に、計画のギャップを見つけてください。
取引所運営者のためのセキュリティ監査チェックリスト
ローンチ前、そしてその後は四半期ごとに、このチェックリストを確認してください。網羅的ではありませんが、私たちが取引所で最もよく見かける見落としの基本をカバーしています。
ウォレットセキュリティ
- コールドストレージが顧客資金全体の95%以上を保持している
- すべてのウォレットでマルチシグが有効(最低2-of-3)
- 鍵生成がエアギャップされたデバイスで行われている
- バックアップ鍵が存在し、地理的に離れた安全な場所に保管されている
- スイープが残高しきい値を伴う自動スケジュールで実行されている
- ホットウォレット残高がリアルタイムアラートで監視されている
アクセス制御
- すべての管理者アカウントでロールベースの権限が強制されている
- すべての機微な操作で二人制ルールが有効
- すべての管理者アカウントにハードウェア2FA(SMSではない)が必須
- 管理者セッションが15分の非アクティブで失効する
- 退職者のアクセスが退職から1時間以内に取り消される
- 四半期ごとのアクセスレビューですべての権限が依然として適切であることを確認
APIセキュリティ
- すべての認証済みエンドポイントでHMAC署名認証
- すべてのエンドポイントでレート制限、機微なものにはより厳しい制限
- APIキーにIPホワイトリストが利用可能(かつ推奨)
- 出金権限を持つAPIキーに追加の検証が必須
- すべてのAPIトラフィックがTLS 1.2以上を使用
- リクエストのタイムスタンプ検証がリプレイ攻撃を防止
インフラ
- 評判の良いプロバイダー(Cloudflare、Akamai、AWS Shield)によるDDoS保護
- 取引エンジンが公開向けWebサーバーから分離されている
- データベースの保管時・転送時の暗号化
- 復旧手順がテストされた定期的な自動バックアップ
- サーバーアクセスはSSH鍵のみ(パスワード認証なし)
- すべての依存関係が既知の脆弱性について監視されている
監視と対応
- 異常な出金パターンに対するリアルタイムアラート
- ログイン異常検知(新しいデバイス、新しい場所、物理的に不可能な移動)
- 外部ストレージに送信される不変の監査ログ
- 文書化され四半期ごとにテストされるインシデント対応計画
- 出金を即座に一時停止する権限を持つオンコールローテーション
- セキュリティインシデント用のコミュニケーションテンプレートが準備済み
コンプライアンス
- しきい値を超えるすべてのユーザーにKYC/AML確認
- 不審なパターンのトランザクションモニタリング
- 最新のOFACおよびEUリストに対する制裁スクリーニング
- すべてのスタッフへの定期的なコンプライアンストレーニング
- 文書化された規制報告手順
Codonoのセキュリティへの取り組み
私たちは2018年から暗号資産取引所ソフトウェアを構築してきました。セキュリティは後付けではなく、最初からアーキテクチャの中核にありました。
Codonoプラットフォームは、この記事で説明したすべてを標準で実装しています。ウォレットシステムは、自動スイープ、設定可能な残高しきい値、マルチシグサポートを備えた完全なコールド/ホット/ウォームウォレットアーキテクチャをサポートしています。管理パネルは、機微な操作に対する二人制ルールと完全な監査ログを備えたロールベースアクセス制御を強制します。
KYC/AMLは組み込みで、Sumsubのようなプロバイダーをネイティブサポートし、リアルタイムの本人確認、トランザクションモニタリング、制裁スクリーニングを含みます。プラットフォーム管理パネルは、セキュリティチームに取引所で起こっているすべての可視性を提供します。API使用パターン、ログイン異常、出金傾向、システムヘルス指標まで。
しかし、正直にお伝えしたいことがあります。どんなソフトウェアも、優れたセキュリティ慣行の代わりにはなりません。Codonoはツールを提供します。それを正しく使うのはあなたです。適切な鍵管理を実装する必要は依然としてあります。チームをトレーニングする必要は依然としてあります。第三者のセキュリティ監査を受ける必要は依然としてあります。インシデント対応計画は依然として必要です。
2025年にハッキングされる取引所は、悪いソフトウェアを使っている取引所ではないでしょう(そういう例もあるでしょうが)。良いソフトウェアを悪い運用セキュリティで使っている取引所です。ツールは、それを握る手と同じ品質にしかなりません。
セキュリティマインドセット
これから1つだけ持ち帰ってほしいことがあるとすれば、それは、セキュリティは実装してチェックリストから消し去る機能ではないということです。継続的な規律です。脅威の状況は進化します。攻撃者はより巧妙になります。新しい脆弱性が現れます。誰も注意を払っていなければ、先月安全だった取引所が今月も安全とは限りません。
セキュリティをすべての意思決定に組み込んでください。すべての新機能にセキュリティレビューを。すべての新入社員にセキュリティトレーニングを。四半期ごとにセキュリティ監査を。すべてのインシデントからポストモーテムと改善を。
長期的に成功する取引所は、セキュリティが技術スタックだけでなく文化に組み込まれている取引所です。ジュニア開発者が潜在的な脆弱性を気兼ねなく指摘できる取引所、CEOが机上訓練に参加する取引所、そして「そのセキュリティの件は後で直そう」が決して許容される答えでない取引所です。
セキュリティを正しく行うコストは、数千ドルと計画に費やす時間で測れます。間違えた場合のコストは、数百万ドル、刑事責任、そして事業の終わりで測られます。この計算は複雑ではありません。
退屈な基本をやってください。それを一貫して。そして、誰かがあなたの取引所を狙って来たとき(来るかもしれない、ではなく来たとき)、それを止めるために合理的なすべてをやったと知って、夜は少しだけ安眠してください。
Codono Team
Codono builds enterprise-grade crypto exchange software deployed by 250+ operators across 40+ countries. Our team writes from production experience running spot, derivatives, custody, and compliance at scale.
View all posts by Codono Team →