暗号資産システムは、自由に移動できることを前提に設計されています。しかし、プラットフォームから assets がどのように流出するかに責任を負う立場では、その自由さがリスクになり得ます。顧客資金、規制対象の活動、機関投資家向けのフローが関わる場合、資産の送付先や受け取りを許可する相手を定めるルールが必要になることが少なくありません。ホワイトリストを使うことで、チームはあらかじめ一定の境界を設け、管理すべき取引上の攻撃対象領域を絞り込めます。
以下では、暗号資産ホワイトリストが実際にどのように機能するのか、そしてチームが不要な作業を増やさずにリスク管理を強化できるよう、どのように適切に運用すべきかを説明します。
目次
- 暗号資産ホワイトリストとは
- アドレスホワイトリストの実際の仕組み
- 企業が暗号資産ホワイトリストを管理するためのシステムとツール
- ホワイトリストによる法令遵守の向上と不正利用リスクの軽減
- ホワイトリストに伴う制限や課題
- チームによる効果的な暗号資産ホワイトリスト登録プロセスの設計と維持
- Stripe Payments の活用方法
暗号資産ホワイトリストとは
暗号資産ホワイトリストとは、お客様が明示的に承認したウォレットアドレスのリストです。システムは、ホワイトリストにないアドレスへの取引をブロックします。
多くのブロックチェーンはデフォルトでオープンになっており、取引は自動的に送信されます。問題が起きたとしても、送信者がそれを知るのは事後です。ホワイトリスト登録では、この仕組みが逆転します。確認されて明示的に許可されない限り、どのアドレスも有効とは見なされません。
アドレスホワイトリストの実際の仕組み
ホワイトリストはさまざまな方法で使用できます。一部のスマートコントラクトでは、トークンを購入したり、NFT (非代替性トークン) を発行したりする前に、ウォレットをホワイトリストに登録しておく必要があります。NFT は、ブロックチェーンに記録される一意のデジタル識別子で、トークン化して真正性や所有権の証明に使用できます。多くの取引所やカストディプラットフォームでは、ホワイトリスト登録済みの宛先にのみ出金できる機能を提供しています。機関投資家向けチームは、ホワイトリストを使用して、出金先を社内の資金管理口座、ベンダー、またはデューデリジェンスをすでに完了したその他の相手方に限定することがあります。
取引所やカストディプラットフォームでは、多くの場合、ユーザーが内部の「許可」リストにアドレスを追加することからプロセスが始まります。そのリストを改ざんから保護するために、プラットフォームは確認ステップ (例: 二要素認証、メール内リンクのクリック、またはその両方) を要求することがあります。また、多くのプラットフォームでは、新しいアドレスを使用できるようになるまで短い待機時間を設けています。この待機期間は、誤って、または攻撃者がアカウントに侵入したために、本来追加すべきではないアドレスが追加された場合に備えるためのものです。
機関投資家向けチームは通常、多層的なアプローチを取ります。社内ウォレット、ベンダー、相手方、コールドストレージなどの用途ごとに個別のホワイトリストを管理します。変更には通常、複数人の承認が必要で、システムには一連のアクションがすべて記録されます。重要なのは、1 人の担当者だけで、誰にも気付かれずに多額の送金先を作成または変更できないようにすることです。
スマートコントラクト環境では、ホワイトリストをコード内に直接組み込むことができます。トークン販売、NFT の発行、制限付きのオンチェーンプログラムでは、通常、開始前に承認済みウォレットのリストを読み込みます。アドレスがそのリストに含まれていなければ、コントラクトはその取引を受け付けません。
どのホワイトリストのシナリオでも、宛先は事前に検証されるため、送金がすでに進行してからシステムが判断を下す必要はありません。これにより、起こり得るミスや攻撃の範囲を狭めることができます。
企業が暗号資産ホワイトリストを管理するためのシステムとツール
ホワイトリスト登録に必要なインフラの多くは、企業がすでに資産の保管や自社ウォレット運用に使っているプラットフォーム内にあります。ここからは、各要素を詳しく見ていきます。
取引所とウォレットプラットフォーム
取引所や主要なウォレットプロバイダーでは、より簡単な形でホワイトリスト登録を利用できます。許可するアドレスの内部リストを管理し、多要素認証やメールで追加を確認したうえで、そのリストへの出金だけを許可する設定を有効にします。プラットフォームは、送金が開始されるたびにこのルールを適用します。これは、小規模なチームや、スタックに別のシステムを追加せずに主に出金先を制限したいユースケースに適しています。
機関投資家向けカストディプラットフォーム
カストディプラットフォームも同様に機能しますが、ガバナンス機能も備えています。通常は、次のようなオプションに対応しています。
異なるフロー向けの複数のホワイトリスト (例: ベンダーへの支払い、内部送金、コールドストレージ、顧客の出金)
リストの変更に対する複数ステップの承認
エントリーを追加または変更したユーザーと日時を示す詳細な監査ログ
コピーと貼り付けのエラーを減らすように設計されたインターフェイス
これは、成熟した財務チームの一般的な運用方法に近いものです。構造化されていてレビューしやすく、1 人の判断だけでは動かしにくい設計になっています。
カスタムの内部システム
独自のウォレットインフラを運用している企業は、その中にホワイトリストレイヤーを組み込むことができます。基本的なパターンは同じで、すべての外向きの送金が承認済みアドレスのセットと照合されますが、そのリストに関する管理は内部のセキュリティモデルの一部になります。
たとえば、承認済みアドレスを保存するデータベースを用意したり、使われなくなったアドレスを廃止するためのレビュープロセスを設けたりすることが考えられます。いずれにしても、内部システムを使えば高い柔軟性を確保できますが、そのプロセスのあらゆる側面を自社で管理することになります。
法令遵守およびスクリーニングツール
ホワイトリストは、特に規制対象のフローを扱う企業にとって、法令遵守ツールと並行して機能します。スクリーニングでは、ホワイトリストに登録される前にウォレットの履歴を評価し、制裁措置への抵触リスク、過去の不正利用との関連、異常なやり取りなどの問題がないかを確認できます。
より成熟した運用体制では、スクリーニングとホワイトリスト登録が連携しています。アドレスは法令遵守レイヤーを通過した後にのみ承認され、システムは削除が必要になる変更がないか監視を続けます。
ホワイトリストによる法令遵守の向上と不正利用リスクの軽減
ホワイトリストが機能するのは、取引が始まる前に資産の送付先を制限できるためです。チームが規制環境や高リスク環境で業務を行っている場合、この 1 つの制限で複数の問題を同時に解決できます。
法令遵守
規制当局は、特に資金がプラットフォームから出て自己管理型ウォレットに入る場合、企業が取引相手を把握していることを求めます。ホワイトリストは、オンチェーンアドレスを確認済みの顧客や審査済みの取引先に関連付けることで役立ちます。多くの場合、アドレスが承認される前に顧客確認 (KYC) に沿った確認が完了していることを意味します。また通常、ユーザーは自分がそのウォレットを管理していることを証明しており (多くの場合はメッセージへの署名によって)、そのアドレスは制裁対象への該当や過去の不正利用との関連についてスクリーニングされています。
そのウォレットへの決済が承認されると、常に同じ既知の主体に対応付けられます。これにより監査が簡素化され、禁止対象に資産を送ってしまう可能性も低くなります。
不正利用防止
アカウントの乗っ取りは、多くの場合、認証情報を侵害し、悪意のある出金先アドレスを追加して、資産を流出させるというパターンをたどります。ホワイトリストは、この流れを断ち切ります。攻撃者が侵入できたとしても、資金を新しいウォレットに振り向けることはできず、ホワイトリストの変更を試みるとアラートが発せられます。多くのシステムでは、必須の時間遅延によって問題を修正するための猶予も得られます。
ホワイトリストは、ユーザーに事前承認済みのリストから引き出し先を選ばせることで、誤ったアドレスの入力といった意図しない人的ミスを最小限に抑えることにも役立ちます。
アウトバウンドフローが承認済みかつスクリーニング済みのウォレットにのみ送られると示せることは、銀行パートナー、規制当局、顧客にとって重要です。これは、望ましくない結果を防ぐために取引フローを適切に設計していることの表れです。
ホワイトリストに伴う制限や課題
ホワイトリストは便利ですが、作業が増える可能性があります。ホワイトリストを利用する際には、リストを正確かつ最新の状態に保ち、保護する責任があります。
ワークフローの停滞
資金を移動する前に、新しい取引先、ベンダー、またはウォレットを追加し、スクリーニングして承認する必要があります。管理策に 24 時間の有効化遅延が含まれている場合、プラットフォームがセキュリティ上の理由でこれを適用することがあるため、緊急の送金は遅れる可能性があります。この遅延には維持するだけの価値がありますが、その分、チームはこの待機時間を見込んで計画するか、一部の取引はオンデマンドでは実行できないことを受け入れる必要があります。
ホワイトリストガバナンス
1 人で監督なしにリストを更新できる場合、別の種類のリスクが生じます。悪意のある内部関係者や、プレッシャーのかかった善意の従業員でさえ、本来追加すべきではないアドレスを追加してしまう可能性があります。複数承認者のワークフローと監査証跡がなければ、ホワイトリスト自体が脆弱な部分になります。
継続的な監視
前四半期には問題のなかったアドレスでも、新たに制裁対象との関わりが生じたり、侵害されたウォレットとのつながりを持ったりする可能性があります。定期的なレビューと更新がなければ、古い前提に頼ることになります。
暗号資産の慣行への対応
多くの相手方は、プライバシーや運用上の理由からアドレスを頻繁に変更します。生成される新しいアドレスをそのたびにホワイトリストに追加すると、保守の負担になる可能性があり、追加を拒否すると関係が損なわれるおそれがあります。一部のチームは、法人レベルでホワイトリストに登録することでこれに対応しています。
チームによる効果的な暗号資産ホワイトリスト登録プロセスの設計と維持
優れたホワイトリストプロセスは、リストの正確性を保ち、レビューしやすい状態を維持できるよう設計されています。いくつかの基本的な実践を取り入れることで、企業は実用的なホワイトリストプロセスを構築できます。
条件の設定
アドレスを追加する前に、オーナーは KYC チェックを完了し、ウォレットを管理していることを証明し (通常はメッセージへの署名によって)、制裁とリスクのスクリーニングに合格している必要があります。よりリスクの高いカテゴリで事業を運営している場合は、法人確認や法人用ウォレット向けの補足書類などの手順も追加してください。
変更の承認に複数の担当者が必要
ホワイトリストにアドレスを載せるかどうかを、1 人の判断だけで決めるべきではありません。複数承認者によるフローが一般的です。すべての手順はログに記録されます。ある送金が許可された理由を確認する必要がある場合は、その記録を確認します。
リストの定期的なレビュー
ウォレットは使われなくなることがあり、パートナーも変わります。また、以前は問題のなかったアドレスが新たなリスクにさらされることもあります。月次または四半期ごとのレビューによって、リストを最新の状態に保てます。
ワークフローの可視化
財務、法令遵守、エンジニアリング、サポートは、それぞれ異なる形でホワイトリストに関わります。追加申請の方法、審査担当者、有効化までにかかる時間といった手順を公開すれば、全員がこのプロセスを理解でき、安全対策を損なう「緊急の免除」を防げます。
繰り返し作業の自動化
承認ルートの設定、アドレスへのラベル付け、レビューのお知らせの生成、変更の記録は、いずれも自動化しやすい作業です。
Stripe Payments でできること
Stripe Payments は、成長中のスタートアップからグローバル企業まで、あらゆるビジネスがオンライン、対面、そして世界中で決済を受け付けられるよう支援する、統合されたグローバル決済ソリューションです。世界中のほぼどこからでもステーブルコイン決済を受け付けることができ、Stripe 残高では法定通貨として決済されます。
Stripe Payments でできることは以下の通りです。
決済体験の最適化: 構築済みの決済 UI と、ステーブルコインや暗号資産を含む 125 種類以上の決済手段を活用することで、スムーズな顧客体験を実現し、数千時間に及ぶ開発工数を削減できます。
新市場への迅速な展開: 195 カ国、135 種類以上の通貨に対応した越境決済オプションにより、世界中の顧客にリーチし、多通貨管理の複雑さとコストを軽減できます。
対面とオンラインの決済を統合: オンラインと対面のチャネル全体でユニファイドコマース体験を構築し、顧客とのやり取りをパーソナライズし、ロイヤルティを向上させ、収益を拡大できます。
決済パフォーマンスの向上: ノーコードの不正利用対策や、オーソリ率向上のための高度な機能を含む、カスタマイズ可能で設定が簡単な決済ツールを活用して、収益を増やせます。
柔軟で信頼性の高い成長基盤で迅速に前進: 99.999% の稼働率実績と業界トップクラスの信頼性を備え、ビジネスの成長に合わせて拡張可能なプラットフォーム上で構築できます。
Stripe Payments がオンラインおよび対面決済をどのように強化できるかについて詳しくご覧いただくか、今すぐ利用を開始してください。
この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。