【レポート】KPMGによる暗号通貨監査システムのソリューション #AWSSummit

AWS Summit Online Japan 2020

#レポート

#AWS

#Blockchain

春田拓海 | Takumi

2020.09.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DA事業本部の春田です。

AWS Summit Online絶賛開催中！ということで、本記事では「CUS-67: KPMG Digital Audit X Blockchain Analytics」の内容についてまとめていきます。

セッション情報

有限責任あずさ監査法人 IT 監査部シニアマネジャー近藤純也氏
有限責任あずさ監査法人 IT 監査部マネジャー関資倫氏
株式会社 KPMG Ignition Tokyo ディレクター豊田雅丈氏

KPMG Japanあずさ監査法人とKPMG Ignition Tokyoが推進する監査のデジタル化の取組、及び、その一環として構築したブロックチェーンデータの分析システムの概要について解説する。

※セッション動画は以下リンク

アジェンダ

KPMG Japan Digital Auditについて
ケースとソリューション
次のステップ

KPMG Japan Digital Auditについて

KPMG AZSA LLC
- あずさ監査法人はKPMGのメンバーファームとして、複雑な課題を有するクライアントや社会に対して価値ある監査・アドバイザリーサービスを提供
- 最近では帳票の照合や伝票取引が電子化されており、監査の分野でもデジタル化が進められている
- KPMG社が持つ監査の知見とテクノロジーを組み合わせて、付加価値を高めていく
3C x I
- Comprehensive Audit（網羅的監査）
  - 監査対象の帳簿を精査的な指標を用いて、網羅的に監査を行う
  - 従来は手作業だったためサンプルを抽出して一部分のみに監査を行っていたが、それを母集団全体に対して行う
- Centralized Audit（一元的監査）
  - 大量のデータを効果的・効率的に分析するための、監査プラットフォーム
- Continuous Audit（リアルタイム監査）
  - 従来は年の決算のタイミングで行っていた監査を、常にデータを追うようリアルタイムで行う
  - ビジネス環境や経営状態の変更・変化に迅速に対応する
- Insights
  - KPMGもともとの監査に関する豊富な知見

Future of Audit
- 2025年、監査現場でのある2日間の出来事
- Continuous Auditが実現している未来の監査現場を描いている
- 制作: KPMG UK

KPMG Ignition Tokyo
- 約120名のデジタル人材集団
- KPMG Japanの監査、税務、アドバイザリーの各業務が共用して使えるデジタルプラットフォームを開発

6つの注力する技術領域
- Secure Computing
  - 監査情報・税務情報・アドバイザリー情報などKPMGが取り扱う情報群を一元化し、より安全な状態で処理することを可能にする技術総称
- Knowledge Processing
  - 画像・文字・音声などの非構造データから情報を抽出・認識・データベース化
  - 集約された構造データ間を結合し、人間の知識・感覚に沿った意味的価値を獲得
- Intelligent Agent
  - ある特定の分野において、集約された情報知識をもとに、人間との自然な対話を可能とする知的感覚を有するエージェント
- Scientific Visualization
  - 効果的な視覚・聴覚・触覚的フィードバック技術
  - Business Intelligence toolsを始めとしたデータ分析・グラフ化技術
- Smart Transaction
  - 人間が検知不可能な異常の発見、意図的かつ悪意の処理の検出
  - KPMGの業務の根幹といえる部分への貢献を想定
- Edge Computing & IoT
  - IoTを中心としたリアルタイムデータキャプチャー技術と、高速処理のための次世代コンピューティング技術
技術ドメインを支える基盤
- Cloud
- DevOps
- Security

ケースとソリューション

仮想通貨分析ツール（特許出願中）開発の背景と要件
- 監査において、仮想通貨を対象に年間を通じた取引分析及び期末時点の残高を検証する必要が出てきた
- クライアントが仮想通貨で資産を大量に保有しているケースが増えてきている
要件
- 監査対象の通貨は複数ある
- 監査対象アドレスは数百万件に達する通貨もある
  - 主にBitcoin
- 取引分析は1会計期間分（1年）のデータで十分
  - 残高検証については、前期末残高という概念が仮想通貨に存在しない
  - ジェネシスから期末時点までのデータを積み上げて計算する必要がある
- 監査において扱う情報の信頼性、正確性と網羅性は担保する必要がある
外部Explorerサイトの利用がダメな理由
- 監査対象アドレスは機密情報扱いのため、外部Explorerにアドレスを渡すことができない
- 監査において、情報源の信頼性を評価する必要がある
  - 外部Explorerのソースコードは公開されているものの、バックエンドの運用管理状況は公開されておらず、信頼性を評価できない
Explorerサイトの自社運用でもダメな理由
- 監査対象アドレスが数百万件存在するケースもあるため、WebインターフェースしかないExplorerでは取扱が事実上困難
- 過去の特定時点の残高を表示できる機能を持つExplorerは極わずか
  - 監査で必要なのは、期末時点のデータ
- 結果の表示方法（HTML、JSON等）が千差万別であり、Explorer毎に検証方法を変えるのは監査人の負担が大きい

当初のシステム構成
- よくあるモノリシックなシステム構成
- 各通貨のノードはAPIを備えており、それを介して監査に必要な情報（主にブロックとトランザクション）をJSON形式で取得・分析しやすい形に加工するシステム

開発時における課題
- 当初は2~3カ月で終わると思ったプロジェクトだが、開始したら課題が噴出
  - 通貨ノードの運用コストの課題
  - システム運用の課題
  - 通貨仕様の理解不足
  - データ加工の課題

通貨ノードの運用コストの課題

課題
- ストレージの運用コストが高額
  - ノードのストレージとしてSSDが要求
  - 容量がTB級になる通貨が存在
- インスタンスの運用コストも高額
  - ノードインスタンスも最低Large級のマシンパワーが必要

解決策
- 毎日使うものではないため、ノードの同期及びデータ抽出は定期実行
- 通常時はインスタンスを停止し、ストレージもスナップショットに退避し、運用コスト削減
- 不要なインスタンス、スペックは削除（タグ付けを活用）
- スポットを活用し、インスタンスの運用コストをさらに削減

システム運用の課題

課題
- 現時点では一部のチームが特定の時期に使用するのみのシステムであり、運用の手間はかけたくない
解決策
- 積極的にマネージドサービスを活用することにより、運用の手間を省力化
  - 細かいチューニングよりも運用の省力化を優先
- 月次で動かすバッチシステムなので、ストレージ容量以外の監視系は無視

通貨仕様の理解不足

課題
- 単純な通貨が一つもない
  - ブロックに入っているトランザクションを取り出して、アドレス毎に金額フィールドを合算すれば残高が求められると思っていた
- ビットコイン: ノードバージョンによってアドレス解釈が異なる
- イーサリアム: あるハードフォーク以前は、トランザクションデータの成功・失敗のフィールドが存在しない
解決策
- ホワイトペーパーを隅から隅まで目を通す
- ソースコードを直接読む
- （この辺は力業）

データ加工の課題

課題
- ノードAPIから取得したデータのどの項目が検証に必要なのか良く分かってない
- 当初不要と思っていた項目が後から必要になるケースが出てきた
- ノードAPIからのデータ取得は速度が上げにくく、データ変換の仕様変更対応に時間がかかる

解決策
- ブロックチェーンの特性上、既存データの更新はあり得ない
- ストレージをリレーショナルデータベース（RDS）からオブジェクトストレージ（S3）に変更
- 変換のフローを分割（データレイク的思想）
  - APIから取得したデータは、オブジェクトストレージに貯めておく
  - 要件決定後にGlue Sparkを使って必要な形にデータを加工