EWA導入時のデータセキュリティとプライバシー保護

EWAのデータを安全に保護するためには、企業が「どのデータを収集するのか」「何のために利用するのか」「どこに保存するのか」「誰がアクセスできるのか」「どの当事者と共有するのか」「いつ削除する必要があるのか」を正確に把握する必要があります。主な対策には、データ最小化、役割ベースのアクセス制御、強力な認証、暗号化、鍵およびシークレット情報の管理、改ざんに強いログ、異常監視、バックアップ、セキュリティテスト、ベンダー管理、インシデント対応手順などがあります。セキュリティは独立した機能ではなく、EWAのライフサイクル全体にわたる共同責任です。

> 注記: 本稿は、ガバナンス、テクノロジー、運用のための参考フレームワークです。具体的な法的義務は、各当事者の役割、データの種類、処理目的、データ移転の流れ、実際の導入モデルによって異なります。適用する前に、法務、情報セキュリティ、人事の各担当者が共同で確認することを推奨します。

> 用語: EWA（勤務日数に応じてすでに発生した賃金へアクセスするサービス） · HRIS（人事情報システム） · ERP（統合基幹業務システム） · payroll（給与処理） · API（アプリケーション・プログラミング・インターフェース） · SFTP（セキュア・ファイル転送） · token（元データを置き換えるコード） · MFA（多要素認証） · OTP（ワンタイムパスワード） · idempotency（取引の重複防止） · webhook/callback（システム間の自動通知） · log（ログ記録） · SOC（セキュリティ・オペレーション・センター） · go-live（本番環境への正式リリース） · playbook（インシデント対応ガイド） · OWASP ASVS/MASVS（Web/モバイルアプリケーションのセキュリティ検証標準） · backup（データバックアップ）。

EWAデータに高いレベルの保護が必要な理由

EWA – Earned Wage Accessでは、従業員が通常の給与支払日前に、すでに働いて発生した賃金の一部へアクセスできます。利用資格や利用可能な限度額を確認するため、通常は複数のデータ領域を連携する必要があります。

• 本人確認情報および在籍状況

• 事業部門、職務、給与グループ

• 勤怠データおよび承認状況

• 給与水準、給与期間および一部の調整内容

• 受取口座または決済情報

• 申請履歴、金額、タイムスタンプおよび取引結果

• 不正防止に利用する端末情報、ログインセッションおよびログ

これらのデータを組み合わせると、個人の雇用関係や金銭的な行動を比較的詳細に把握できる可能性があります。インシデントが発生すると、情報漏えいだけでなく、アカウント乗っ取り、誤った相手への支払い、限度額計算の誤り、給与処理の中断、紛争、従業員からの信頼低下につながる可能性があります（EWA導入時のリスクも参照）。

したがって、重要なのは「データが暗号化されているか」だけではありません。プロセス全体で、不正アクセス、不正確なデータ変更、不正取引、二重支払い、不適切な目的でのデータ利用を防止できるかが本質です。

1. セキュリティ対策を選ぶ前にデータをマッピングする

存在や保管場所を把握していない資産を保護することはできません。最初のステップは、データの生成から削除まで、EWAデータの流れをマッピングすることです。

各フローについて、次の質問に答えられるようにします。

1. どのデータが送信されるのか？

2. そのデータは何の目的で利用されるのか？

3. どのシステムが正式なデータソースなのか？

4. どの当事者が処理の目的と手段を決定するのか？

5. どの当事者が契約に基づいて処理を実行するのか？

6. データはAPI、ファイル、手入力のいずれで送信されるのか？

7. データはどこに、どのくらいの期間保存されるのか？

8. 誰が閲覧、変更、エクスポート、削除できるのか？

9. データが再委託先や定義された範囲外へ移転されることはあるか？

10. 従業員が退職した場合、またはサービス契約が終了した場合、どうなるのか？

データ台帳テンプレート

上記テンプレートは設計のための参考フレームワークです。保持期間と分類レベルは、法的根拠、契約上の要件、照合の必要性、実際のリスク評価に基づいて企業が決定する必要があります。

2. 本当に必要なデータだけを収集する

データ最小化は、リスクと保護コストの両方を削減します。システムが従業員の在籍状況と所属グループを確認するだけでよいのであれば、人事記録全体をコピーする必要はありません。

企業は各データ項目について、次の4つの質問で確認するとよいでしょう。

• この項目がなくても、EWAは業務機能を正確に実行できるか？

• 完全なデータを参照ID、トークン、または部分的にマスキングしたデータへ置き換えられるか？

• データを保持する必要があるのか、それとも処理中だけ利用すれば十分か？

• 詳細度を下げる、または保持期間を短縮できるか？

よく使われる3つの手法

データマスキング: 受取口座の下4桁だけを表示するなど、情報の一部だけを表示します。

トークン化: 機密情報を参照コードへ置き換え、完全なデータは責任を持つ処理領域にのみ保持します。

データ分離: 必要がない限り、本人確認情報、口座情報、取引履歴を同じテーブルや同じアクセス権限の下に保存しません。

最小化とは、統制に必要なデータまで不足させることではありません。二重支払いを防止し、照合を行うためには、十分な取引ID、元データのバージョン、タイムスタンプ、ログを保持する必要があります。

3. 当事者間の役割と責任を定義する

EWAプログラムには、雇用企業、EWA提供事業者、インフラ提供事業者、勤怠システム、給与システム、銀行、決済パートナーなどが関与する場合があります。責任が不明確だと、インシデントが発生した際に当事者間で責任が移転し続ける状況になりかねません。

責任分担表では、次の事項を明確に定義する必要があります。

この表は実際の契約内容に合わせて調整する必要があります。ベンダーを利用することによって、すべてのデータおよび情報セキュリティ上の責任がベンダーへ移転するわけではありません。

4. 従業員が利用しにくくならないよう、強力な認証を使用する

EWAアカウントは実際の金銭の受け取りに直接つながるため、情報閲覧だけを目的としたアカウントよりも強力な保護が必要です。

従業員向け

• アカウント有効化時に本人確認を行う。

• 取引リスクのレベルに適した認証方式を使用する。

• 端末変更、受取口座変更、異常行動の検知時には追加認証を要求する。

• 認証試行回数を制限し、コードの推測攻撃を検知する。

• 推測しやすいセキュリティ質問に依存しない。

• 新規ログイン、重要情報の変更、取引についてユーザーへ通知する。

• サポート担当者が認証手順を単純に回避できない、安全なアカウント復旧手順を提供する。

管理者・運用担当者向け

• 多要素認証を必須にする。

• 集中管理型のサインインを優先し、個人ごとのアカウントを使用する。

• 共有管理者アカウントを禁止する。

• 必要に応じて、端末、ネットワーク、リスク条件に基づきログインを制限する。

• 特別な作業には時間制限付きのアクセス権を付与する。

• データ閲覧、変更、エクスポート、設定変更を伴う操作をすべて記録する。

パスワード、OTP、認証情報をログに記録してはいけません。サポート担当者も、従業員にパスワードやOTPを読み上げてもらってはいけません。

5. 役割ベースのアクセス制御と最小権限の原則

アクセス権は、役職の上下ではなく業務上の役割に基づいて付与する必要があります。

高リスク操作には、職務分離または2名承認を適用する必要があります。例えば次のような操作です。

• 受取口座の変更

• 不正の兆候があるアカウントのロック解除

• 完了済み取引の変更

• 大量データのエクスポート

• 限度額ルールの変更

• 管理者アクセス権の付与

• ログまたは取引データの削除

アクセス権は定期的に見直し、従業員が異動、退職、または関連する責任を失った場合は直ちに撤回する必要があります。

6. データの暗号化と鍵管理

通信中および保存中のデータに暗号化を適用する必要がありますが、単に「暗号化を有効にする」だけでは十分ではありません。

企業は次を確認する必要があります。

• アプリケーション、API、SFTP、管理システム間の接続が暗号化されているか。

• データベース、バックアップ、ファイル保存領域、ログが保護されているか。

• 暗号化鍵がデータとは分離して保存されているか。

• 誰が鍵を使用、ローテーション、失効できるか。

• 鍵へのアクセス活動が記録されているか。

• 鍵を紛失または漏えいした場合、どのように対応するか。

• CSV/Excelへエクスポートしたデータが保護環境の外に残らないか。

APIキー、システムパスワード、証明書は専用のシークレット管理基盤で管理する必要があります。ソースコード、メール、教育資料、広く共有される設定ファイルにシークレットを記載してはいけません。

7. APIと統合フローを保護する

勤怠、給与、EWA、決済システム間のAPIは、データだけでなく業務命令も伝達します（勤怠・給与・ERPとEWAの統合も参照）。重要な対策には次があります。

• 呼び出し元システムを認証し、各機能を個別に認可する。

• 入力の構造、型、上限を検証する。

• リクエストレートを制限し、異常行動を検知する。

• APIのバージョンと変更プロセスを管理する。

• Webhook/Callbackに署名または検証メカニズムを使用する。

• 時刻、nonce、適切なキーなどを利用してリクエストの再送を防止する。

• 取引作成コマンドにidempotency_keyを使用する。

• システム間の追跡にcorrelation_idを使用する。

• エラーコードから内部情報が漏れないようにする。

• 特に決済結果が不明な場合、リトライ処理を管理する。

バッチファイルについては、専用SFTPアカウント、必要に応じたファイル暗号化、チェックサム、バッチ名、処理順序、重複レコード、部分エラーファイル、転送領域のファイル削除期限を管理する必要があります。

OWASP Application Security Verification Standardは、Webアプリケーションのセキュリティ対策を構築・テストするためのフレームワークとして利用できます。モバイルアプリケーションについては、OWASP MASVSが認証、ストレージ、ネットワーク、コード、プライバシー要件に関する専門的な参考基準となります。

8. ログは調査を支援しつつ、情報漏えいの原因にならないようにする

ログは不正検知、問い合わせ対応、インシデント追跡に役立ちます。一方、過剰な機密情報を含むログは、別の管理困難なデータコピーを生み出します。

記録すべき項目

• 管理されたユーザーIDまたは管理者ID

• 操作内容と対象オブジェクト

• 標準化されたタイムスタンプとタイムゾーン

• ポリシーに基づくアドレスまたは端末の指標

• 成功/失敗結果と理由コード

• transactionid、correlationid、データバージョン

• 権限、設定、限度額、受取口座の変更

• 大量データエクスポート操作

• アカウントロックイベントまたは異常検知

完全な値を記録してはいけない項目

• パスワード、OTP、アクセスキー

• 完全な口座番号または本人確認書類番号

• 従業員の完全な記録を含むリクエスト/レスポンス内容

• 無効化されていないセッショントークン

• 監視・調査目的のないデータ

重要なログは、不正な変更や削除から保護し、時刻を同期し、集中監視システムへ送信し、シナリオベースのアラートと連携させる必要があります。OWASPは、アプリケーションログがセキュリティと運用の両方を支援するべきであるとし、ログに含まれるデータ自体も保護する必要があるとしています。

9. 端末、アプリケーション、ログインセッションを管理する

従業員は個人のスマートフォンを利用したり、SIMを変更したり、端末を変更したりする場合があります。そのため、システムではセキュリティと利用しやすさのバランスを取る必要があります。

次のような状況には個別のルールを設ける必要があります。

• 新しい端末からのログイン

• 電話番号の変更

• root化/jailbreakされた端末、または改ざんの兆候

• 異常な方法で複数アカウントが同じ端末を使用している場合

• 短時間に1つのアカウントが複数の場所からログインする場合

• 受取口座情報を変更した直後に即時支払いを要求する場合

• 長時間のログインセッションまたはトークンの再利用

アプリケーションは、機密データをローカルストレージ、クリップボード、スクリーンショット、ロック画面通知に平文で保存してはいけません。ログインセッションには、有効期限、失効、機密操作前の再認証を設定する必要があります。

10. プライバシーを尊重しながら不正を検知する

不正防止には、端末、行動、取引パターンの分析が必要になる場合があります。ただし、データ収集は明確な目的、必要性、具体的な保持期間と結び付ける必要があります。

考えられる業務上のリスクシグナルには次があります。

• 受取口座を変更した直後の取引

• 認証失敗の繰り返し

• 類似内容のリクエストの繰り返し

• 限度額ルールを超える取引

• 取引前に勤怠データが異常に変更される

• 1つのアカウントが手動サポートを過度に利用する

• 管理者が勤務時間外に多数の重要変更を行う

システムは1つのシグナルだけで、特定の人物が不正を行っていると自動的に判断すべきではありません。リスクスコア、追加認証、例外処理、権限を持つ担当者による確認が必要です。すべての自動化モデルは、端末データ、位置情報、利用条件の違いによって特定の従業員グループが誤ってブロックされないようにテストする必要があります。

11. バックアップ、可用性、復旧可能性

セキュリティには可用性と完全性も含まれます。データ漏えいがなくても、取引履歴を失ったり、給与処理期間中にシステムが停止したりすれば、大きな影響が生じる可能性があります。

企業は次を要求する必要があります。

• 各データタイプの重要度に応じたバックアップ

• バックアップへの個別の暗号化とアクセス制御

• ランサムウェアの影響を抑えるための隔離コピー

• 「バックアップ成功」の確認だけでなく、実際の復旧テスト

• 両当事者が合意した復旧時間およびデータ損失の目標

• 重要コンポーネントの冗長化アーキテクチャ

• EWAまたは決済チャネルが停止した場合の代替運用手順

• 復旧後に状態が不明な取引の保存

時間目標は、実測され、正式なサービスコミットメントによって保証されていない限り、数値として広告・公表すべきではありません。

12. ベンダーおよびサプライチェーン管理

EWA提供事業者は、クラウドインフラ、OTP配信サービス、監視サービス、本人確認サービス、決済パートナーなどをさらに利用する場合があります。企業は、どの当事者がデータを受領するのか、各当事者の責任が何であるのかを把握する必要があります。

契約締結前に確認すべき質問

（詳細な基準はEWAベンダー選定チェックリストを参照してください。）

1. 提供事業者は正確にどのデータグループを処理するのか？

2. データとバックアップはどこに保存されるのか？

3. データへアクセスできる再委託先は存在するか？

4. 再委託先が変更される前に事前通知する仕組みがあるか？

5. 提供事業者の従業員はどのようにデータへアクセスするのか？

6. 暗号化、鍵管理、MFA、環境分離は導入されているか？

7. ペネトレーションテストの範囲と頻度はどうなっているか？

8. 脆弱性はどのように分類・修正されるか？

9. インシデント通知の期限と連絡窓口は何か？

10. 契約終了時、データとコピーはどのように返却または削除されるか？

11. 削除が完了したことを証明する証拠は何か？

12. 企業に検査、評価、独立報告書の確認を行う権利があるか？

認証は有用な指標ですが、対象範囲の確認に代わるものではありません。企業は、その認証がどのシステム、場所、期間を対象としているのか、実際に利用するEWAプラットフォームを含んでいるのかを確認する必要があります。

13. Go-Live前後のセキュリティテスト

リリース前に一度テストしただけでは、製品ライフサイクル全体をカバーできません（90日間のEWAパイロット計画も参照）。適切なプログラムには次のような項目が含まれます。

• アーキテクチャと脅威モデルのレビュー

• ソースコードおよび依存ライブラリのレビュー

• アプリケーション、サーバー、設定の脆弱性スキャン

• API、Web、モバイルアプリケーションのテスト

• 役割別の認可テスト

• アカウント復旧プロセスのテスト

• 二重取引や偽造コールバックに対するテスト

• Go-Live前および大規模変更後の独立したペネトレーションテスト

• インシデント対応および復旧訓練

• 問題が解決された証拠が得られるまでの是正状況の追跡

テスト結果では、重大な問題、一時的に受容可能な問題、指定された権限者が承認した残存リスクを明確に区別する必要があります。実際の決済・統合フローがテスト範囲に含まれていない場合、「重大な問題は見つからなかった」という理由だけで本番環境へリリースしてはいけません。

14. EWAデータのインシデント対応プロセス

異常な活動の兆候が検知された場合、最初の目的は証拠を破壊せずに被害を抑えることです。

プレイブックには次を定義する必要があります。

• インシデントの定義と重大度

• 誰がアカウントをロックし、APIを停止し、支払いを一時停止できるか

• ログ、システム画面、取引証拠をどのように保全するか

• 影響を受けたデータ、ユーザー、期間をどのように特定するか

• 法務、人事、広報、セキュリティ、ベンダーの連絡先

• 所管当局または影響を受けた個人へ通知する根拠、内容、時期

• サービス再開の基準

• 誤った取引が発生した場合の従業員支援方法

• 根本原因の報告と再発防止策

法的な通知期限は、インシデントの種類と各当事者の具体的な役割に応じて法務チームが判断する必要があります。すべての状況に単一の期限を一律に適用してはいけません。

15. データライフサイクル：生成から安全な削除まで

各データグループには、それぞれの保持スケジュールが必要です。「必要になったときに確認できるよう永久保存する」という方法は、追加価値を生まないままリスクを高める場合があります。

ポリシーには次を含める必要があります。

• 本番システムのデータ

• バックアップ

• 転送ファイル

• ユーザー端末へエクスポートされたデータ

• アプリケーションおよびセキュリティログ

• テストデータ

• 再委託先が保有するデータ

• サポートチケットと添付ファイル

• 退職した従業員のデータ

• サービス契約終了後のデータ

安全な削除には、削除コマンド、実行ログ、コピーの処理、完了証拠を含める必要があります。場合によっては、法的義務、紛争解決、監査要件のためにデータを引き続き保持する必要があります。その場合は、アクセスを縮小し、利用目的を制限する必要があります。

16. 留意すべきベトナムの法的枠組み

本稿作成時点で、個人データ保護法第91/2025/QH15号は2025年6月26日に公布され、2026年1月1日から施行されています。個人データ保護法を詳細に規定する政令第356/2025/ND-CP号は2025年12月31日に公布され、2026年1月1日から施行されています。

また、業務フローに応じて、電子取引法第20/2023/QH15号（2024年7月1日施行）、非現金決済に関する政令第52/2024/ND-CP号、その他の関連する業種別規制についても検討する必要があります。

コンプライアンスは単に「同意する」というチェックボックスを追加することではありません。企業は、各当事者の役割、処理目的と根拠、従業員へ提供する情報、共有範囲、データ主体の権利、必要な評価記録、保護対策、インシデント対応手順を正確に特定する必要があります。具体的な法的判断は、実際のデータフロー図と導入契約に基づいて行う必要があります。

17. EWA導入を承認する前のセキュリティチェックリスト

ガバナンスと法務

• [ ] EWAプログラム責任者と情報セキュリティ担当者が指定されている。

• [ ] データマップとデータを受領するシステム/ベンダーの一覧がある。

• [ ] 当事者の役割、目的、処理責任が特定されている。

• [ ] 通知、規約、従業員の権利行使の仕組みが確認されている。

• [ ] 各データグループの保持期間と削除手順がある。

• [ ] 契約にインシデント、再委託先、監査、サービス終了に関する条項が含まれている。

本人確認とアクセス制御

• [ ] 従業員はアカウント有効化時および機密情報変更時に本人確認を受ける。

• [ ] 管理者はMFAと個人アカウントを使用する必要がある。

• [ ] アクセス権は役割、組織範囲、業務に基づいて付与されている。

• [ ] 高リスク操作には2名承認または職務分離が適用されている。

• [ ] アクセス権は定期的に確認し、異動または退職時に撤回する。

データと統合

• [ ] 本当に必要なフィールドだけを送信する。

• [ ] 可能な場合、機密データをトークン化またはマスキングする。

• [ ] 接続と保存データが暗号化されている。

• [ ] 鍵とシークレット情報をソースコードから分離して管理する。

• [ ] API/Webhookに認証、リプレイ攻撃対策、負荷/レート制御が適用されている。

• [ ] 取引に冪等性とシステム間の追跡可能性がある。

アプリケーションと運用

• [ ] Web、API、モバイルアプリケーションが適切な範囲でセキュリティテストを完了している。

• [ ] ログが十分なイベントを記録しながら、シークレットや完全な機密データを含んでいない。

• [ ] 監視、アラート、明確なアラート受信担当者が設定されている。

• [ ] バックアップが保護され、実際の復旧テストが完了している。

• [ ] アカウント乗っ取り、データ漏えい、誤った支払いに対するプレイブックがある。

• [ ] プラットフォームまたは決済障害に対する事業継続計画がある。

Go-Liveと導入後

• [ ] すべての重大な問題が修正され、再テストされている。

• [ ] 残存リスクが権限を持つ担当者によって書面で承認されている。

• [ ] 当事者間の緊急連絡先が確認されている。

• [ ] 従業員がアカウント紛失または異常取引の報告方法を知っている。

• [ ] アクセス権、脆弱性、ベンダー、アラートの有効性を確認するスケジュールがある。

• [ ] 大規模変更後にテストを実施した証拠がある。

結論

EWAのデータセキュリティは、技術的なチェックリストからではなく、データフローと責任を理解することから始まります。信頼できるプログラムには、収集するデータの制限、適切な本人認証、適切な権限付与、APIと取引の保護、十分なログの維持、ベンダー管理、障害からの復旧、インシデント発生時の透明性ある対応が必要です。

企業がEarned Wage Accessソリューションを評価する場合は、システムマップ、連携予定のデータグループ、内部統制チェックリストを準備し、企業向けEarned Wage Accessを確認したうえで、パイロット開始前にセキュリティ文書、統合資料、技術評価の範囲を依頼することを推奨します。

参考資料

• 個人データ保護法第91/2025/QH15号

• 個人データ保護法を詳細に規定する政令第356/2025/ND-CP号

• 電子取引法第20/2023/QH15号

• 非現金決済に関する政令第52/2024/ND-CP号

• OWASP Application Security Verification Standard

• OWASP Mobile Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

著者: Nguyen Tan Loc — 戦略部門スペシャリスト, Nhan Kiet Manpower Supply Co., Ltd.

企業向けEarned Wage Accessソリューション: Hotline 0937.022.655 · Email info@nhankiet.vn · 企業向けEarned Wage Access