MASテクノロジーリスク管理：MASが示すとおりにモバイルバンキングアプリをテストしましょう。

1. 01

   MAS TRMガイドライン、14.1.4および附属書C

   モバイルアプリ特有のリスクに対処する

   条文の内容

   モバイルデバイスでオンライン金融サービスを提供する金融機関は、モバイルアプリケーションのリスクに対する具体的な対策を講じるべきです。附属書Cはそれらを列挙しています。アプリ内にデータを保存・キャッシュしないこと、暗号の秘密鍵を保護すること、アンチフッキングまたは改ざん防止の仕組み、完全性チェック、コードの難読化、証明書または公開鍵のピンニング、安全なアプリ内キーパッド、ソフトウェアトークンのデバイスバインディングを実装することです。

   出典：MAS TRMガイドライン、14.1.4および附属書C

   モバイルアプリにとっての意味

   附属書Cは、アプリのテスト計画のように読めます。各対策は、顧客がダウンロードするビルドに対して確認できます。

   Ostorlabによる支援

   Mobile Shielding Scanは、root・脱獄検知、改ざん防止、アンチインストルメンテーション、TLSピンニングの回避を試み、アプリがワークフローをブロックするのか、起動を拒否するのか、動作を続けるのかを示します。Ostorlabは、ローカルストレージ、キャッシュ、ログ、スクリーンショットにトークンや個人データがないかも調べます。

   お客様が担うこと

   シールド製品の選定と設定、アプリ内キーパッド、デバイスバインディングの設計。

2. 02

   MAS TRMガイドライン、14.1.7および14.2.8

   root化・脱獄されたデバイスを取引から遠ざける

   条文の内容

   root化または脱獄されたデバイスについては、マルウェアによる改ざんや傍受からアプリを隔離するサンドボックスやコンテナ内でアプリが保護されている場合を除き、金融機関のモバイルアプリケーションにアクセスして金融取引を行うことを禁止すべきです。ソフトトークンの発行には、顧客の本人確認、root化・脱獄されたデバイスの検知とブロック、デバイスバインディングなどの対策を含めるべきです。

   出典：MAS TRMガイドライン、14.1.7および14.2.8

   モバイルアプリにとっての意味

   検知するだけでは不十分です。デバイスが侵害されている場合、アプリは取引やトークンの設定を停止しなければならず、そのチェックは簡単に無効化できるものであってはなりません。

   Ostorlabによる支援

   Mobile Shielding Scanはroot化・脱獄済みの環境でアプリを実行し、検知の回避を試み、アプリがその後どう動作するかを示します。ハードニングスコアとバイパスの証拠が得られます。

   お客様が担うこと

   侵害されたデバイスに関するポリシーと、サンドボックスやコンテナ技術の選定。

3. 03

   MAS TRMガイドライン、14.2.1～14.2.5

   ログイン時にMFAを使い、高リスクの操作に署名する

   条文の内容

   オンライン金融サービスのログイン時に多要素認証を導入します。顧客のパスワードは、モバイルアプリまたはブラウザとそれを検証するシステムの間でエンドツーエンドで暗号化します。連絡先情報の変更、第三者の受取人の登録、高額の資金移動、振込上限の変更などの高リスクの操作には、取引署名を実装します。時間ベースのOTPの有効期間は、実務上可能な限り短くします。

   出典：MAS TRMガイドライン、14.2.1～14.2.5

   モバイルアプリにとっての意味

   受取人の変更、上限の引き上げ、連絡先情報の変更は、詐欺師が狙う操作です。アプリから何が送られてきても、署名のステップはサーバー側で機能しなければなりません。

   Ostorlabによる支援

   Ostorlabはテスト用アカウントでSMS、メール、TOTPによるワンタイムコードを入力し、攻撃者による操作の試みも含めて、MFAの強制とステップアップ認証のフローを、口座情報の変更の背後にあるAPI呼び出しとあわせてテストします。

   お客様が担うこと

   認証方式と署名方式の選定、OTPの有効期間と上限の設定。

4. 04

   MAS TRMガイドライン、14.2.6、14.2.9、14.2.11

   セッションと認証情報を保護する

   条文の内容

   やり取りの間中、認証済みセッションとその暗号化を維持し、乗っ取られたセッションを検知して終了させ、あらかじめ定めた無操作時間が経過したらオンラインセッションを自動的に終了します。生体情報と認証情報は保存時も通信時も暗号化し、認証情報はリバースエンジニアリングに耐える形式で保存します。

   出典：MAS TRMガイドライン、14.2.6、14.2.9、14.2.11

   モバイルアプリにとっての意味

   セッションの有効期限、ログアウト時のトークンの無効化、デバイス上での認証情報の保存方法は、アプリとそのバックエンドの具体的でテスト可能な挙動です。

   Ostorlabによる支援

   認証後のテストでは、ログインとログアウト、トークンの更新、タイムアウト、セッションの無効化、MFAの強制を確認し、通信の解析によって認証情報がアプリからバックエンドへどのように送られるかを示します。

   お客様が担うこと

   タイムアウトの値、生体認証の調整、認証情報の失効手続き。

5. 05

   MAS TRMガイドライン、6.4.4～6.4.7

   本番環境の前にAPIを保護し、テストする

   条文の内容

   APIキーとアクセストークンを保護するAPIのセキュリティ標準を定め、アクセストークンには妥当で強制される有効期限を設けます。APIで送信する機密データには強力な暗号化を使用します。APIを本番環境に導入する前に堅牢なセキュリティ審査とテストを実施し、APIの利用状況を監視して不審な活動を検知し、侵害の発生後には速やかにキーやトークンを失効できるようにします。

   出典：MAS TRMガイドライン、6.4.4～6.4.7

   モバイルアプリにとっての意味

   アプリが呼び出すAPIは、アプリと同じデータを扱います。そのアクセス制御とトークンの扱いは、一度だけでなくリリースごとにテストする必要があります。

   Ostorlabによる支援

   OstorlabはTLSピンニングがあってもアプリの通信を傍受し、認可の不備（BOLA、BFLA、IDOR）、トークンとセッションの悪用、列挙、リプレイ、自動化などの不正利用についてAPIをテストし、各検出結果にリクエストとレスポンスの証拠を付けます。

   お客様が担うこと

   APIの設計、サードパーティの審査、APIのリアルタイム監視、キーの失効。

6. 06

   MAS TRMガイドライン、6.1～6.3および附属書A

   開発しながらアプリケーションのセキュリティをテストする

   条文の内容

   セキュアコーディング、ソースコードレビュー、アプリケーションセキュリティテストに関する標準を採用します。サードパーティ製およびオープンソースのコードは組み込む前にレビュー・テストし、その更新と報告された脆弱性を追跡します。静的、動的、対話型のテスト手法を組み合わせて使用します。見つかったすべての問題を追跡し、重大な問題は本番環境への導入前に修正します。アジャイルやDevSecOpsでも同じ標準を適用します。

   出典：MAS TRMガイドライン、6.1～6.3および附属書A

   モバイルアプリにとっての意味

   アプリの各リリースは、組み込まれたSDKやライブラリを含め、ストアに公開される前に自動セキュリティテストを通過すべきです。

   Ostorlabによる支援

   Mobile SASTはAPK、AAB、IPAを直接解析し、ソースコードは不要で、組み込まれたSDK全体にわたるテイント解析も行います。Mobile DASTはアプリを実行し、SCAは静的にコンパイルされたライブラリを識別します。いずれもビルドごとにCI/CDパイプラインから実行できます。

   お客様が担うこと

   セキュアコーディング標準、開発者のトレーニング、手動のコードレビュー、職務の分離。

7. 07

   MAS TRMガイドライン、13.1、13.2、13.6

   脆弱性評価とペネトレーションテストを実施する

   条文の内容

   アプリケーションの脆弱性を含め、システムの重要度と露出度に応じた頻度で定期的に脆弱性評価を実施します。オンライン金融サービスには、ブラックボックスとグレーボックスのペネトレーションテストを組み合わせます。グレーボックスとは、通常の顧客と同じ権限でテストすることを意味します。インターネットから直接アクセス可能なシステムについては、少なくとも年1回、または大きな変更や更新があるたびにペネトレーションテストを実施します。深刻度の評価と修正期限を定めて問題を追跡し、解決します。

   出典：MAS TRMガイドライン、13.1、13.2、13.6

   モバイルアプリにとっての意味

   モバイルバンキングアプリとそのAPIはインターネットに公開されています。年に少なくとも1回のペネトレーションテストを計画し、大きなリリースのたびに再度テストし、ログイン後のテストも含めてください。

   Ostorlabによる支援

   AIエージェントによるペネトレーションテストは、リリースするビルドを対象に、アプリとそのAPIをログインの先までテストし、AIエージェントによる各検出結果に、再実行できる動作するエクスプロイトが付きます。検出結果はクリティカル、高、中、低で評価され、チケットとして追跡され、修正のリリース後に再テストされます。

   お客様が担うこと

   年次ペネトレーションテストの実施者の選定、本番環境でのテスト、バグバウンティ、レッドチーム演習。

8. 08

   MAS Notice FSM-N05、第9項、MAS Notice FSM-N06、第4.2項、第4.3項、第4.6項

   銀行向けの拘束力のあるNoticeに対応する

   条文の内容

   Notice FSM-N05は、顧客情報を不正なアクセスや開示から保護するためのIT管理策の実装を銀行に義務付けています。Notice FSM-N06は、各脆弱性のリスクに見合った期間内でのセキュリティパッチの適用、すべてのシステムに対する文書化されたセキュリティ標準、そしてインターネット経由で顧客情報にアクセスするために使われるすべてのシステムの全アカウントへの多要素認証を義務付けています。

   出典：MAS Notice FSM-N05、第9項、MAS Notice FSM-N06、第4.2項、第4.3項、第4.6項

   モバイルアプリにとっての意味

   これらはガイダンスではなく義務です。顧客が自分の情報にアクセスする場所はアプリとそのAPIであるため、その管理策は証拠の一部になります。

   Ostorlabによる支援

   Ostorlabは、アプリとそのAPIで顧客情報を保護する管理策をテストし、SCAは各リリースのコンポーネントを既知の脆弱性と対応付けて、その解消を追跡します。

   お客様が担うこと

   サーバーとインフラのパッチ適用、すべてのシステムのセキュリティ標準、管理者アカウント。

9. 09

   Guidelines on Shared Responsibility Framework、4.2および6.2

   詐欺対策の義務をアプリに組み込む

   条文の内容

   責任共有フレームワークの下で、責任を負う金融機関は、デジタルセキュリティトークンがデバイスで有効化された際に、高リスクの操作を行えない少なくとも12時間のクーリングオフ期間を設けなければなりません。また、トークンの有効化と高リスクの操作についてリアルタイムのアラートを送信し、モバイルとオンラインのアクセスをブロックするセルフサービス機能を提供し、リアルタイムの不正監視を行わなければなりません。これらの義務を果たさなかったことで生じた損失は、金融機関が負担することが想定されています。

   出典：Guidelines on Shared Responsibility Framework、4.2および6.2

   モバイルアプリにとっての意味

   これらの義務のいくつかはアプリの中にあります。クーリングオフ期間、アラート、キルスイッチです。アプリやそのAPIを通じてこれらを回避できる場合、損失はお客様の負担になる可能性があります。

   Ostorlabによる支援

   AIエージェントによるペネトレーションテストは決済と口座のフローのビジネスロジックをテストし、APIのテストでは口座情報の変更の背後にある呼び出しについて認可とリプレイを確認します。

   お客様が担うこと

   不正監視、アラートの配信、報告窓口、損失の評価。

公開されているMASの文書の要約です（2026年9月27日時点で確認）。TRMガイドラインはガイダンスであり、MASは金融機関の監督にあたり、その趣旨がどの程度遵守されているかを考慮します。本ページは法的助言ではありません。