IBANはパスワードではありませんが、機微な決済データです。実際のIBANから銀行口座を特定でき、その口座を個人や企業に結び付けられます。また、支払い、請求書、口座振替の同意、サポートチケット、エクスポート、監査証跡にも現れます。
IBANを安全に保存するには、エンジニアリング設計が必要です。プロダクトが必要とする場合だけ取得し、一度だけ正規化し、サーバー側で検証し、役に立つ最小限の表現を保存し、生の値をログ、分析、下位環境から遠ざけることが目標です。
IBANを機微な金融データとして扱う
多くの決済プロダクトでは、個人に属するIBANは個人の金融データとして、企業に属するIBANは機密の企業銀行データとして扱うべきです。
IBANだけで通常は支払いを承認できません。口座名義の証明にはならず、同意、口座確認フロー、決済プロバイダーの確認、詐欺審査の代わりにもなりません。それでも銀行との関係を露出し、漏えい時には運用上のリスクを生みます。
実務上の社内ルールは次のとおりです。
- ユーザーが入力、確認、修正するときだけ完全なIBANを表示する。
- それ以外の場所ではマスクしたIBANを表示する。
- 今後の決済実行に必要な場合だけ完全なIBANを保存する。
- 開発、デモ、スクリーンショット、分析イベントで実際のIBANを使わない。
データ最小化から始める
保存設計の前に、そもそもIBANを保存する必要があるかを決めます。
1回限りの検証、見積もり、一時的な設定手順だけに使うなら、長期保存は不要かもしれません。その場合は入力を検証し、必要なら決済プロバイダーに渡し、処理完了後に破棄します。
継続的な支払い、口座振替、マーケットプレイスの販売者口座、給与、仕入先への支払い、サブスクリプション請求、保存済み口座を特定するサポート業務を提供するなら、保存が必要になる可能性が高いでしょう。
保存が必要な場合は、目的ごとにフィールドを分けます。
| フィールド | 目的 |
|---|---|
iban_ciphertext |
決済実行用に暗号化した完全なIBAN |
iban_country |
経路選択、フィルタリング、コンプライアンス確認 |
iban_last4 |
安全な表示とサポート検索 |
iban_fingerprint |
IBANを露出させない重複検出 |
verification_status |
名義やプロバイダー確認の状態 |
created_at と updated_at |
監査と保持の制御 |
表示用に整形した文字列を主値として保存するのは避けます。正規形を保存し、表示時だけ整形してください。
保存前に正規化する
IBANは、銀行アプリからコピーした空白、小文字、ばらばらのグループ分けを含んだ状態で入力されがちです。検証と保存の前に正規化します。
実用的な正規化手順は次のとおりです。
- 前後の空白を取り除く。
- 内部の空白を取り除く。
- 文字を大文字に変換する。
- 対応していない文字を拒否する。
- 国コード、長さ、チェックサムを検証する。
- サーバー側で検証した後にだけ正規形を保存する。
たとえば、de89 3704 0044 0532 0130 00 は DE89370400440532013000 になります。
表示用の整形は分離してください。UIでは読みやすいグループで表示できますが、後続のプロバイダーは通常、空白のない正規形を期待します。
完全なIBANを暗号化する
完全なIBANを保存する場合は、データベースディスクの暗号化だけに依存せず、フィールドレベル暗号化を使用します。ディスク暗号化は一部のインフラ環境には有効ですが、アプリケーション、バックアップ、分析、データベースへの多くのアクセス経路は保護できません。
より安全な設計では、データベースへ書き込む前にIBANを暗号化し、決済実行フローまたは厳格に管理された運用手順の中でだけ復号します。
実装上の要点は次のとおりです。
- 利用できる場合はマネージド鍵管理サービスを使う。
- 計画した移行プロセスで鍵をローテーションする。
- 復号権限を本当に必要なサービスだけに限定する。
- 一般的な管理画面から復号できないようにする。
- 完全な銀行データの特権表示やエクスポートをすべて記録する。
エンジニア、分析担当、サポート担当が自由に完全なIBANを検索できるなら、暗号化だけでは不十分です。
検索にはフィンガープリントを使う
多くのシステムでは、同じIBANがすでに追加されているかを検出する必要があります。IBANの単純なハッシュを保存して解決しないでください。
IBANは国ごとの既知の形式に従い、値の一部には構造があります。鍵付きHMACは重複検出に適しています。データベースが漏えいしても、単純な事前計算検索を防げるためです。
次のようなフィンガープリントを保存します。
HMAC-SHA256(secret_key, canonical_iban)
フィンガープリントは一致確認、重複防止、内部照合に使います。HMAC鍵はデータベースとは分離して管理し、慎重にローテーションしてください。鍵を変えるとすべてのフィンガープリントが変わります。
IBANを一貫してマスクする
マスキングは共有ユーティリティにし、コードの各所で個別の文字列処理を作らないようにします。
よくある表示形式は国コードと末尾4文字だけを見せる方法です。
DE89 **** **** **** **3000
さらにプライバシーを重視するなら次の形式もあります。
DE****************3000
形式を1つ選び、顧客ダッシュボード、請求書、管理画面、ログ、メールテンプレート、エクスポート、サポートツールのすべてで使います。
無害に見えるからといって途中の数字を追加で見せないでください。同じ口座が複数のシステムに現れると、部分的な開示が積み重なります。
ログと分析からIBANを除外する
ログへの漏えいは、決済データが意図した境界の外へ出る一般的な原因です。リクエスト本文、検証エラー、プロバイダーのペイロード、Webhookのトレース、バックグラウンドジョブの引数、検索インデックス、分析プロパティにIBANが含まれることがあります。
プラットフォーム層にマスキングを組み込みます。
iban、account_number、bank_accountとプロバイダー固有の同等フィールドをマスクする。- アプリケーションプロセスからログを出す前にマスクする。
- 成功した検証だけでなく失敗した検証のペイロードもマスクする。
- 決済ルートでは完全なリクエストログを無効にする。
- エラー監視ツールがローカル変数やBreadcrumbを取得していないか確認する。
有効なテストは、既知の偽IBANをstagingに送信し、ログ、トレース、分析イベント、サポートツールで完全な値を検索することです。完全なIBANは、暗号化ストレージと必要なプロバイダーリクエスト以外には現れてはいけません。
形式検証と口座名義確認を分ける
有効なIBANは、ユーザーが所有する口座と同じ意味ではありません。
IBAN検証が確認するのは、形式とチェックサムが妥当らしいということだけです。口座の存在、決済種別への対応、ユーザーの所有、支払いに対する安全性は確認しません。
プロダクトのリスクに応じ、名義確認には次のいずれかが必要になる場合があります。
- 決済プロバイダーによる口座確認。
- オープンバンキングによる確認。
- 少額入金による確認。
- 口座振替同意の確認。
- 対応している場合の名義照合。
- 高額支払いに対する手動の財務審査。
この状態は別フィールドに保存します。iban_validに、名義確認済み、支払い可能、承認済みの意味を詰め込まないでください。
安全なサポート業務を設計する
サポート担当は完全なIBANを見ずに銀行口座を特定する必要があります。マスク済みデータで機能するツールを用意します。
顧客、決済参照、国、末尾4文字、確認状態で検索できると便利です。完全なIBANの表示は例外とし、権限、時間制限、監査を必須にします。
表示を一時解除するフローには次を含めます。
- アクセス理由の記録。
- 機微なケース用の権限。
- 短時間後の自動マスキング。
- 誰がいつ値を見たかの監査記録。
- 大量アクセスや不自然な閲覧パターンへのアラート。
これにより、管理画面をデータ露出のリスクに変えずにサポートを行えます。
開発とQAでは生成IBANを使う
開発環境とstaging環境に実際の顧客IBANを置いてはいけません。本番データベースのコピーは、決済データがバックアップ、検索ツール、ローカルマシン、スクリーンショット、デバッグセッションへ広がるため危険です。
代わりに生成したテストIBANを使います。形式が有効なテストIBANは、フォーム検証、UIテスト、単体テスト、CSVエクスポート、Webhookシミュレーション、多くのプロバイダーのsandboxフローに十分です。
Random IBANは標準チェックサム検証を通る国別IBANを生成でき、次の用途に使えます。
- 決済フォームのテスト。
- デモアカウント。
- QAスクリプト。
- シードデータ。
- ドキュメント用スクリーンショット。
- マスキングとログ除去の回帰テスト。
テストデータだと明確に分かるようにします。架空の顧客名、sandboxのプロバイダー口座、非本番メタデータを使い、生成IBANを実口座と誤認しないようにしてください。
保持ルールを定める
決済チームは、削除の担当者がいないため、銀行口座データを必要以上に保持しがちです。機能を作る段階で保持ルールを定義します。
次のタイミングで完全なIBANの削除またはアーカイブを検討します。
- ユーザーが銀行口座を削除したとき。
- 販売者、仕入先、従業員の口座を閉じたとき。
- 同意が期限切れになったとき。
- 企業が支払い機能を必要としなくなったとき。
- 法定保持期間が過ぎたとき。
- ユーザーが消去を求め、優先する義務がないとき。
表示用フィールド、フィンガープリント、監査記録、暗号化した生データを分けると、保持管理が容易になります。マスクした決済履歴を残し、将来の取引に必要な完全なIBANだけを削除できる場合もあります。
エンジニアリングチェックリスト
IBANを収集・保存する機能をリリースする前に、次を確認します。
- 完全なIBANを保存する明確な理由がある。
- 入力を検証前に正規化している。
- 検証をブラウザーだけでなくサーバーでも実行している。
- 正規形のIBANをフィールドレベルで暗号化している。
- マスク表示に共有ユーティリティを使っている。
- ログ、トレース、分析、エラーレポートからIBANフィールドを除去している。
- 重複検出に鍵付きフィンガープリントを使っている。
- 完全なIBANへのアクセスを権限管理し、監査している。
- 開発とstagingで生成テストIBANを使っている。
- 保持と削除のルールを文書化している。
検証の詳細はIBAN番号を検証する方法を、QA用の安全なデータはフィンテックQA向け合成IBANデータを参照してください。
良いIBANシステムとは、正しい形式を受け付けるだけのものではありません。銀行データを見られる人を制限し、実口座を非本番環境から排除し、決済運用に必要な情報だけを提供して、余分な情報を露出させないシステムです。