情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#마이데이터#전송보안#CPO#접근관리#개인정보#132회
最終更新 · 2026-10-01

マイデータ送信セキュリティ(マイデータ送信セキュリティガイド, 2023.09)

1. 概要

A. 定義

マイデータ(本人信用情報管理業)において、情報主体の要求に応じて個人(信用)情報を機関間で送信する際に発生するリスクを統制するための管理的・技術的・物理的な安全措置の基準を整理したガイドであり、送信者(情報提供者)と受信者(マイデータ事業者)の双方に、保護責任者の指定・アクセス管理・送信区間の保護・事故対応などを共通して求めるものである。

マイデータの本質は、銀行・カード・保険・通信会社など複数の機関に散在する「自分の情報」を、情報主体の送信要求権に基づいて一か所に集め、統合照会・分析・推薦に活用することである。従来は利用者が各機関の画面を一つひとつ巡って情報を確認していたが、マイデータは標準APIを通じて情報提供者のデータを事業者が直接引き寄せる構造へと変えた。この構造の効用は明確だが、その分、大量の機微な個人信用情報が機関の間を常時・自動で行き来するという点が根本的なリスクである。データが移動するまさにその瞬間が、漏えい・改ざん・誤送信・再利用のリスク区間であるため、送信の全区間をend-to-endで統制することがマイデータの信頼の前提となる。

B. 登場背景および必要性

マイデータが2022年に全面施行されて以降、参加機関数と送信トラフィックが急増し、一参加者のセキュリティ上の穴がエコシステム全体の信頼を崩しかねない構造になった。API一件あたりの平均送信量は小さく見えても、数百の機関が数千万人の資産・所得・決済・融資履歴を定期的にやり取りすれば、全体の露出面は従来の個別サービスとは比較にならないほど広くなる。特に対象情報が資産・信用・所得といった財産に関わる機微情報であるため、漏えい時にはボイスフィッシングや融資詐欺などによって即座に金銭被害につながり、一度漏れた情報の回収は事実上不可能である。

また、送信は「渡す側」と「受け取る側」が分離した双方の行為であるため、どちらか一方だけが安全でも意味がない。送信者がいくら暗号化しても、受信者がアクセス制御を怠れば受信直後にデータが露出し、その逆もまた同様である。そこで監督・関連機関は、信用情報法・個人情報保護法の安全性確保措置義務をマイデータ送信という特殊な文脈に合わせて具体化し、送信者と受信者が同じ水準の保護責任を負うよう基準を統一したのが本ガイドである。すなわちガイドは新たな規制の創設ではなく、既存の法的義務を送信シナリオに投影した実務解説・チェックリストの性格を持つ。

C. 特徴

マイデータ送信セキュリティは、一般的な情報保護措置と比較して三つの特徴を持つ。第一に、常時性である。従来サービスのデータ移動が断続的なバッチであったのに対し、マイデータは定期送信・随時送信が24時間自動で起こるため、統制も常時運用されなければならない。第二に、標準化である。参加機関が多く個別協議ではセキュリティを揃えられないため、標準APIと共通の安全措置でセキュリティ水準を平準化する。第三に、情報主体中心性である。すべての送信の根拠は情報主体の送信要求であるため、要求の真偽・範囲・撤回を正確に反映すること自体がセキュリティ要件となる。

2. マイデータ送信セキュリティの全体構造

マイデータ送信セキュリティは、「誰が責任を負うのか(管理)」「誰がアクセスするのか(アクセス制御)」「何がどのように行き来するのか(送信・保存の保護)」「止まったり破綻したりしたらどうするのか(可用性・事故対応)」という四つの軸で構成される。この四つの軸は独立しておらず鎖のように絡み合っているため、最も弱い輪の強度が全体のセキュリティ水準を決定する。

flowchart LR
  subgraph Provider["情報提供者(送信者)"]
    DB1[(個人信用情報)]
    AUTH1["認証・アクセス制御"]
  end
  subgraph Channel["送信区間"]
    TLS["mTLS暗号化チャネル"]
    TOK["アクセストークン(最小権限・短期)"]
  end
  subgraph MyData["マイデータ事業者(受信者)"]
    AUTH2["認証・アクセス制御"]
    DB2[(収集情報の保存・暗号化)]
  end
  US["情報主体(送信要求)"] --> MyData
  DB1 --> AUTH1 --> TLS
  TOK --> TLS
  TLS --> AUTH2 --> DB2
  CPO["保護責任者(CPO)・方針・点検"] -.統括.-> Provider
  CPO -.統括.-> MyData

上図のとおり、送信は情報主体の送信要求を起点として、提供者のデータベースから認証・アクセス制御を経て暗号化されたチャネル(mTLS)で受信者に伝達され、受信者側で再びアクセス制御の下に安全に保存される。そしてこの流れ全体を、双方の保護責任者が方針・点検で統括する。ガイドの要件は、ほとんどがこの図の各区間にマッピングされる — 以下の3〜5章は、それぞれ管理(CPO)、アクセス管理、送信・保存・可用性を扱う。

この構造で特に重要なのは、アクセストークンがチャネルと分離して管理される点である。送信要求に応じて発行されるトークンは、「どの情報主体の、どの範囲の情報を、いつまで」持ち出せるかを収めた鍵であるため、トークンの発行・検証・廃棄の全過程が送信セキュリティの中心軸となる。チャネル(mTLS)が「通路の安全」を保証するとすれば、トークンは「権限の安全」を保証し、両者は相互補完的であって、どちらか一方だけでは送信を信頼できない。

3. 送信対象個人情報保護責任者(CPO)の指定

安全措置は技術以前に「誰が責任を負って管理するのか」から出発する。いかに精緻な技術的統制を備えても、これを統括し定期的に点検し、事故時に指揮する主体がいなければ、統制は設置されたまま放置され、事故対応は漂流する。そこでガイドは、送信業務を所管する個人情報保護責任者(CPO)を明確に指定し、送信セキュリティ方針の策定と履行点検、侵害事故対応を統括するよう求める。

CPO体制が実効を持つには、実質的な権限と独立性が核心である。保護責任者が現場(営業・サービス)部署に従属すると、「送信速度を上げよう」「認証段階を減らそう」といった利便性の要求に押され、セキュリティ統制を緩めようとする圧力に抵抗しにくい。したがってCPOは、経営陣に直接報告(直報)できる位置で、予算・人員・組織権限を配分されなければならない。これはCISO・CPOの独立性を強調するISMS-P・信用情報法の趣旨とも整合する。

また、送信は双方の行為であるため、送信者と受信者の双方とも責任主体を明確にしなければならない。一方だけが責任体制を備えると、事故発生時に「提供段階の問題なのか受信段階の問題なのか」で責任の所在が曖昧になり、対応が遅れる。実務的には、双方のCPOが送信規格・セキュリティ要件を事前に合意し、定期的にログ・点検結果を相互確認するガバナンスを置く。たとえば特定の事業者で異常な送信が検知されれば、受信者CPOの判断だけで終わらせず、提供者CPOに通知して共同で調査・遮断する協力手順を事前に文書化する。

さらにCPOの役割は、事故発生後の「消防士」にとどまらない。新規サービスの企画段階で送信範囲・保管期間・利用目的を検討し、個人情報影響評価(PIA)のような事前統制を通じてリスクを設計段階で取り除くことのほうが重要である。事故が起きた後の復旧コストと信頼の喪失は、設計段階での統制コストと比較にならないほど大きいからである。この意味でCPOの指定は、組織にセキュリティを「常に問う問い」として植え込む装置である。

項目 内容 理由
CPO指定 送信業務を統括する保護責任者の指定・責任の明確化 統制の運用・点検主体の不在を防止
役割 送信セキュリティ方針の策定・履行点検、侵害事故対応の統括 設置された統制の継続的な実効性の維持
独立性 実質的権限・独立性、経営陣への直報体制 現場の統制緩和圧力への抵抗力
双方体制 送信者・受信者ともに責任主体を指定・協力手順 事故時の責任所在の明確化・共同対応

4. 送信対象個人情報処理システムのアクセス管理

アクセス管理の原理は、「必要な人が、必要なだけ、痕跡を残して」と要約される。送信データは結局、個人情報処理システムに保存・処理されるため、このシステムに誰がどこまでアクセスするかを統制できなければ、暗号化・送信の保護は無意味になる。

flowchart LR
  A["アクセス権限の最小化・職務分離"] --> B["多要素認証(MFA)"]
  B --> C["接続記録の保管・改ざん防止"]
  C --> D["異常行為の検知・自動遮断"]
  D -.フィードバック.-> A

第一に、最小権限と職務分離である。処理システムの権限は業務上どうしても必要な範囲に狭め、開発者と運用者、照会権限と変更権限を分離する。その理由は、ある一つのアカウントが奪取されても、そのアカウントで到達可能な情報の範囲を狭めて被害を局限するためである。権限は一度付与して終わりにせず、入社・退社・職務変更に合わせて定期的に回収・再検討しなければならない。放置された遊休アカウントと過剰権限が、実際の事故の最も一般的な入口だからである。

第二に、認証の強化である。パスワード単一認証はフィッシング・使い回し・総当たりに脆弱であるため、マイデータ送信の文脈では、人のログインに多要素認証(MFA)を適用し、機械間のAPI呼び出しには相互TLS認証(mTLS)と短期アクセストークンを組み合わせる。トークンは奪取されても被害を最小化できるよう、有効期間を短く、権限範囲(scope)を狭く発行することが実務の核心である。

第三に、接続記録の管理と異常行為の検知である。すべての接続・処理行為を接続記録として残し、改ざん防止措置(ハッシュ・完全性保護・分離保管)とともに保管する。接続記録は事後追跡の根拠であるだけでなく、深夜の大量照会や普段のパターンを大きく逸脱した送信要求のような異常行為をリアルタイムで検知する入力となる。たとえばあるアカウントが普段の数百倍に達する送信要求を短時間に発生させれば、自動遮断・通知が発動するよう設計し、その結果を再び権限方針にフィードバックして統制を強化する。

この三つの統制は互いを補完する。最小権限が「被害範囲」を狭め、MFAが「侵入の可能性」を下げ、接続記録・異常検知が「検知と事後追跡」を担う。どれか一つが破られても残りが被害を吸収する多層防御(defense in depth)構造として設計してこそ、単一統制の失敗がただちに大量漏えいにつながる事態を防げる。

項目 内容
アクセス権限 最小権限・職務分離、権限の付与・回収の定期的な検討
認証 MFA(人)・mTLS・短期トークン(機械)、セッション・アカウント管理
接続記録 接続・処理記録の保管および改ざん防止、分離保管
統制・検知 アクセス制御システム、異常行為のモニタリング・自動遮断

5. 個人情報管理および災害・災難への備え

送信データの安全は、移動中(in transit)と保存中(at rest)の両方を守ってこそ完成する。送信区間はTLS/mTLSで暗号化して中間者攻撃を防ぎ、受信後に保存されるデータは暗号化して、保存媒体の奪取や内部者の漏えいの際にも平文での露出を防ぐ。どちらか一方だけを保護すれば — たとえば送信は暗号化しても保存を平文のままにすれば — 最も脆弱な地点が全体のセキュリティを決定することになる。

ここに、データが伝達の過程で変わっていないことを保証する完全性検証(電子署名・ハッシュ)と、大量漏えいの試みを検知・遮断するDLP的な統制を置く。特にマイデータでは「誤った相手に送信される」誤送信も致命的であるため、受信者の識別・認可を送信直前に再確認する統制が重要である。

一方でマイデータは、多数の機関がリアルタイムで接続されたサービスであるため、可用性それ自体がセキュリティ要件となる。特定の提供者のシステムが災害で止まると、その機関の情報に依存する送信チェーン全体が影響を受けるからである。したがってバックアップ・復旧体制(BCP/DRS)とシステムの二重化でサービス継続性を確保し、侵害事故が発生した際の迅速な隔離・調査・通知・申告の手順を事前に用意しておく。金融分野では侵害事故を認知したら監督機関に遅滞なく報告しなければならないため、技術的な復旧とあわせて規制報告の手順を対応マニュアルに含めなければならない。

可用性の保護には、災害だけでなく大量トラフィック・障害の伝播への備えも含まれる。送信要求が特定の時点(月初・給与日など)に集中すると、提供者のAPIに負荷が集中するが、このとき処理遅延が再試行の殺到につながって障害が広がる「障害伝播」のリスクがある。これを防ぐために、呼び出し速度制限(rate limit)、キューイング、指数バックオフ再試行といった負荷制御の設計を置き、一機関の過負荷がエコシステム全体の可用性を引き下げないようにする。すなわち可用性は、ハードウェアの二重化だけでなくトラフィック管理まで含む総合的な設計の産物である。

項目 内容
暗号化 送信区間(TLS/mTLS)・保存データの暗号化
完全性・漏えい防止 送信データの改ざん防止(署名・ハッシュ)、漏えい検知・遮断(DLP)
誤送信防止 受信者の識別・認可の再確認、送信対象・範囲の検証
災害・災難への備え バックアップ・復旧(BCP/DRS)、二重化で継続性を確保
事故対応 侵害事故の隔離・調査・通知・規制報告の手順策定

6. 送信者・受信者の責任比較と適用事例

送信者と受信者は同じ安全措置の目標を共有するが、リスクの重心が異なる。送信者(情報提供者)は「正当な要求にのみ、正確な範囲で、正しい受信者に」送り出すことが核心であるため、送信要求の真偽確認・受信者認証・送信範囲の最小化に重みが置かれる。逆に受信者(マイデータ事業者)は、受け取った大量の情報を「安全に保管し、目的の範囲内でのみ使う」ことが核心であるため、保存の暗号化・アクセス制御・目的外利用の防止に重みが置かれる。この違いを理解せず双方に同じチェックリストだけを機械的に適用すると、それぞれにとって本当に重要なリスクを見落とすことになる。

区分 送信者(情報提供者) 受信者(マイデータ事業者)
リスクの中心 誤送信・過剰送信・要求の改ざん 保存情報の漏えい・目的外利用
核心的統制 送信要求の検証・受信者認証・範囲の最小化 保存の暗号化・アクセス制御・利用の統制
代表的な事故 他人への送信、要求より広い送信 収集情報の大量漏えい、再販売

具体的な事例として、① ある事業者のサーバ設定の誤りでアクセストークン検証が緩み、他の利用者の資産情報が照会された事例は、受信者側のアクセス制御・トークン管理の重要性を示す。② 提供者のAPIが要求範囲(例:直近1年)より広い全期間データを返した過剰送信の事例は、送信者側の範囲検証の必要性を示す。③ 数百の参加機関の中でセキュリティが脆弱な小規模事業者がエコシステム全体の攻撃表面となる「弱い輪」の問題は、標準APIのセキュリティ適合性審査を通過した機関のみを参加させる認証・監督体制の妥当性を示す。

これらの事例に共通する教訓は、送信セキュリティが単一技術の問題ではなく、要求検証→送信→保存→利用という全ライフサイクルにわたる統制設計の問題であるという点である。ある事業者が「我々は送信区間をTLSで暗号化している」と主張しても、トークン検証がずさんであったり保存情報が平文であったりすれば、攻撃者は最も弱い地点を狙う。したがって点検も単一項目ではなく、全区間を貫くシナリオベースの点検(実際の攻撃経路を仮定した模擬送信・侵入試験)として実施してこそ実効を持つ。

7. 深化 — 標準・制度の連携と最新動向

マイデータ送信セキュリティは単独のガイドで完結せず、複数の制度・標準と噛み合って作動する。第一に、標準APIとの整合である。事業者は機能適合性・セキュリティ適合性の審査を通過した標準APIを使わなければならず、本ガイドの安全措置はそのAPIの上での運用セキュリティを規定する。第二に、mTLSとトークンセキュリティである。機関間の信頼は相互認証(mTLS)で確保し、OAuthベースのアクセストークンは最小権限・短期有効・範囲制限で設計して、奪取時の被害を最小化する。

第三に、個人情報送信要求権の全分野への拡大である。金融マイデータから始まった送信要求権は、個人情報保護法の改正を通じて公共・医療などへ拡張される流れにあり、送信セキュリティの要求は金融を超えて全産業の共通課題になりつつある(詳細な施行時期・範囲は制度の進行状況によって変わりうるため、断定は避ける)。第四に、ゼロトラストとの接合である。「一度認証したから信頼する」ではなく、送信ごと・アクセスごとに検証するゼロトラスト原則は、機関の境界を常時越えて行き来するマイデータ送信と特によく合う。今後の送信セキュリティは、静的なチェックリストから継続検証・行為ベースの検知を中心とするものへと進化すると展望される。

この流れで注目すべき変化は、送信対象の情報が次第に非定型・大容量・リアルタイムへと広がる点である。単純な残高・取引履歴を超えて決済パターン、行動データ、さらには医療・健康情報まで含まれると機微度が高まり、AIベースの分析と結合したときに再識別・プロファイリングのリスクが大きくなる。したがって送信セキュリティは、暗号化・アクセス制御のような従来の統制に加え、送信された情報がどのように結合・活用されるかまで見る利用段階の統制へと範囲を広げなければならない。仮名・匿名処理、目的外利用の遮断、結合履歴の管理がその具体的な手段である。

8. 考慮事項および示唆点(技術士の観点)

  • 送信全区間の信頼の鎖:認証・暗号化・アクセス制御・保存保護のどれか一つが弱ければ全体が崩れる。mTLSベースの相互認証と短期・最小権限トークンを組み合わせてend-to-endの信頼を設計し、「最も弱い輪」を定期的に識別・補強することが核心である。
  • 標準と運用セキュリティの並行充足:標準API(機能・セキュリティ適合性)と本ガイドの安全措置は、両方とも充足すべき別個の要件である。適合性審査の通過が運用中のセキュリティを保証するわけではないため、常時点検・ログ分析で運用セキュリティを継続的に検証しなければならない。
  • 法・制度との整合と管理的統制の実効性:信用情報法・個人情報保護法の安全性確保措置基準と整合させつつ、文書化にとどまらないよう、定期点検・役職員教育・模擬訓練で管理的統制の実効性を維持する。
  • エコシステムの信頼がすなわち競争力:参加機関全体が同じ水準のセキュリティを守らなければならないため、脆弱な参加者をふるい落とす認証・監督体制と相互責任ガバナンスが、マイデータ拡散の前提である。セキュリティ水準はコストではなく、信頼を基盤とする事業競争力として見るべきである。
  • プライバシー・バイ・デザイン:送信範囲の最小化・目的拘束・保管期間の制限を設計段階から内在化し、事後統制ではなく構造的にリスクを減らす接近が望ましい。
  • 可用性とセキュリティの均衡:セキュリティを強化するあまり送信が遅延・中断すれば、それ自体が可用性事故になる。負荷制御・二重化とセキュリティ統制を併せて設計し、安全性とサービス継続性の間のトレードオフを工学的に管理しなければならない。

参考資料

  • 個人情報保護委員会・金融委員会、マイデータ(本人信用情報管理業)関連の案内資料、https://www.pipc.go.kr
  • 金融保安院、マイデータ技術ガイドライン・標準API規格、https://www.fsec.or.kr
  • 信用情報の利用および保護に関する法律(信用情報法)、https://www.law.go.kr

一言まとめ: マイデータ送信セキュリティガイドは、*保護責任者(CPO)の指定、処理システムのアクセス管理(最小権限・MFA・接続記録・異常検知)、送信・保存の保護と災害対策(暗号化・完全性・バックアップ・事故対応)*を送信者・受信者の双方に共通して求め、機関間を常時行き来する機微情報のend-to-endの信頼の鎖を確保させるものである。