RBIのルールに沿って、モバイルバンキングアプリをリリースの前後に評価しましょう。

1. 01

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第149～161項

   インターネットに接する重要なアプリを定期的にテストする

   条文の内容

   すべての重要かつインターネットに接するシステムについて、VAとPTを定期的に実施し、インターネットに接する重要なWebアプリケーションとモバイルアプリケーションについては、実装前、実装後、変更後を含むライフサイクル全体を通じて定期的にVAとPTを実施します。重要情報システムおよび顧客接点を持つDMZのシステムでは、VAを少なくとも6か月ごと、PTを少なくとも12か月に1回実施し、それ以外のシステムではリスクベースのアプローチを採ります。実装後のテストは本番環境で行い、テスト環境で行う場合は本番に近い構成とし、差異を文書化して承認を得ます。特定した脆弱性は期限を定めて修正し、クローズ状況を少なくとも四半期ごとにIT戦略委員会と情報セキュリティ委員会に報告します。

   出典：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第149～161項

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

   モバイルアプリは顧客接点を持つ、インターネットに接する重要なアプリケーションです。ローンチ時の1回だけでなく、6か月ごとのVA、年1回のPT、変更ごとのテストが必要です。

   Ostorlabによる支援

   Mobile SASTは組み込まれたSDKを含むバイナリを解析し、Mobile DASTは実行中のアプリをテストします。どちらもCI/CDで実行されます。AIエージェントのペネトレーションテストは、ログイン後のアプリとAPIをテストし、AIエージェントの各検出結果に再実行できるエクスプロイトを付けます。

   お客様が担うこと

   サーバーとネットワーク機器の対象範囲と頻度の設定、VA・PT監査人の選定、委員会へのクローズ報告。

2. 02

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第68項；Master Direction on Digital Payment Security Controls, 2021年2月18日, 第IV章（従来の文言）

   モバイル決済アプリの管理策を適用する

   条文の内容

   モバイル決済アプリの管理策は、取引を有効化する前にアプリのバージョンを検証できること、リスク評価に基づくデバイスポリシーの適用（脆弱なOS、脆弱または悪意のあるアプリ、安全でないWi-Fi設定の確認を含む）、アプリのサンドボックス化またはコンテナ化と暗号化、データ収集と権限の最小化、リモートアクセスアプリの特定とそこからのログイン禁止、コードの難読化を求めています。旧バージョンは段階的かつ期限を定めて（新バージョンのリリースから6か月以内に）無効化します。現行バージョンのチェックサムを公開プラットフォームで公開し、デバイスバインディングを実装し、一定期間の未使用後と起動のたびに再認証を求め、安全でないネットワークからの接続を特定する必要があります。また、デバイス、OS、アプリの安全性と互換性を検証し、インストール前に端末がroot化・脱獄されているかを確認して、その場合はアプリのインストールや実行を防ぐこともできます。

   出典：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第68項；Master Direction on Digital Payment Security Controls, 2021年2月18日, 第IV章（従来の文言）

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

   アプリが備えているかどうかが分かれる管理策であり、いずれもお客様がダウンロードするビルドでテストできます。root・脱獄の検知、リモートアクセスの検知、難読化、バージョン確認、デバイスバインディングです。

   Ostorlabによる支援

   Mobile Shielding Scanは、root・脱獄検知、改ざん防止、ピンニングを実行時にテストし、どの保護が機能し、どれが回避されたかを示します。Ostorlabはアプリのバージョン、権限、観測したネットワーク接続も報告します。

   お客様が担うこと

   デバイスポリシーの策定、チェックサムの公開、デバイスバインディング記録の保持、新しいデバイス登録の顧客への通知。

3. 03

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第27～39項；Cybersecurity Directions, 2026, 第83～87項

   セキュリティを設計に組み込み、リリースの前後にテストする

   条文の内容

   セキュア・バイ・デザインを採用し、要件定義、設計、開発、テスト、実装、廃止の各段階でセキュリティ目標を定め、脅威モデリング、セキュアコーディング、OWASPやOWASP MASVSなどの国際標準に沿ったセキュリティテストをアプリケーションのライフサイクル全体に組み込みます。デジタル決済アプリについては、ソースコードレビュー、VA、PTを含むセキュリティテストを実施します。VAは少なくとも半年ごと、PTは少なくとも年1回、加えて新しいアプリやインフラの導入時、重大な変更時に実施します。ソースコードを保有していない場合は、既知の脆弱性、マルウェア、隠れたチャネルがないことの証明書を開発者から取得します。以前のスキャン結果と比較して再発がないことを確認し、脆弱性は期限を定めて修正します。サイバーセキュリティ指針はさらに、Webアプリとモバイルアプリのライフサイクル全体を通じたアプリケーションセキュリティテストを、本番に近い環境で求めています。

   出典：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第27～39項；Cybersecurity Directions, 2026, 第83～87項

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

   リリースはすべて、インターネットに接するチャネルの変更です。パイプラインの自動テストが「前」を、ストア公開版のスキャンが「後」をカバーします。

   Ostorlabによる支援

   OstorlabはCI/CDパイプラインからビルドごとに自動スキャンを実行し、ストア公開版を手動トリガーなしで監視します。Mobile SASTはAPK、AAB、IPAで動作し、ソースコードは不要です。

   お客様が担うこと

   セキュリティ要件、脅威モデル、セキュアコーディング基準、ソースコードレビュー、リリース承認。

4. 04

   RBI (Authentication mechanisms for digital payment transactions) Directions, 2025, 第6項、第8項、第9項

   二要素認証、そのうち少なくとも1つは動的

   条文の内容

   すべてのデジタル決済取引は、免除される場合を除き、少なくとも2つの異なる認証要素で認証する必要があります。カード present 取引以外では、少なくとも1つの要素を動的に生成または証明する必要があり、取引とともに送信される証明はその取引に固有でなければなりません。要素は堅牢である必要があり、一方の要素が侵害されても他方の信頼性に影響してはなりません。発行者は要素の選択肢を提供でき、場所やデバイス属性などの行動・文脈に基づくリスクベースの追加確認を行えますが、展開前にメカニズムの堅牢性と完全性を確保する必要があります。準拠しない取引による損失が生じた場合、発行者は顧客に全額を無条件で補償する必要があります。対応期限は2026年4月1日でした。

   出典：RBI (Authentication mechanisms for digital payment transactions) Directions, 2025, 第6項、第8項、第9項

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

   2つ目の要素は、すべての支払いでサーバー側が強制し、動的でなければなりません。SMS OTPは選択肢の1つですが、デバイスバインディング、生体認証、PKIなども認められています。

   Ostorlabによる支援

   認証後のテストでは、テスト用アカウントでSMS、メール、TOTPのワンタイムコードを入力し、MFAの適用、ステップアップ認証、支払いの背後にあるAPI呼び出しをテストします。

   お客様が担うこと

   要素の選定、免除の検討、顧客への説明、補償プロセス。

5. 05

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第107項、第110項、第115項；Digital Payment Security Controls Directions, 2026, 第46項

   顧客と特権ユーザーを認証する

   条文の内容

   銀行は、すべての提供チャネルでサービスにアクセスする顧客の本人確認を確実にする認証フレームワークを実装し、安全な認証技術を用いて、パートナーシステムへの顧客アクセスのためのIDプロバイダーとして機能する必要があります。リスク評価に基づき、二要素または多要素認証を実装し、重要情報システムと重要業務の特権ユーザーにはMFAを必須とし、ログオンID、認証情報、トークンなどのユーザー資格情報を漏えいや攻撃から保護します。デジタル決済セキュリティ指針はさらに、すべての決済取引（デビットとクレジットの両方）、新しい口座の紐付け、口座情報の変更、送金限度額の変更にMFAとアラートを求めています。

   出典：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第107項、第110項、第115項；Digital Payment Security Controls Directions, 2026, 第46項

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

   ログイン、出金、受取人の変更、限度額の変更はすべて、バックエンドが適切な要素を要求すべき場面です。端末上のトークン処理も同じ管理策の一部です。

   Ostorlabによる支援

   Ostorlabはアプリパッケージ内のAPIキー、トークン、資格情報を検出して有効性を検証し、APIの認可の不備（BOLA、BFLA、IDOR）やトークン・セッションの不正利用をテストします。

   お客様が担うこと

   本人確認、特権アクセス管理、アクセスレビュー、認証技術の選定。

6. 06

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第48～51項

   セッション、失敗した試行、アラート

   条文の内容

   認証済みセッションとその暗号化プロトコルは、やり取りの間ずっと維持される必要があります。干渉があった場合や顧客がアプリを閉じた場合は、セッションを終了し、影響を受ける取引を解決または取り消し、顧客に速やかに通知します。銀行は、ログインまたは認証の失敗が何回続いたらアクセスをブロックするかを定め、安全な再開手順を用意し、失敗した試行を顧客に通知する必要があります。また、中間者攻撃、中間ブラウザ攻撃、中間アプリ攻撃への対策を実装し、転送中のデータを保護し、正規の送信元またはプロセスからのみ取引を認証する必要があります。

   出典：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第48～51項

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

   セッション処理はテスト可能な動作です。タイムアウト、トークン更新、ログアウトやアプリ終了時の無効化、失敗試行後のロックアウト、そしてそれぞれの背後にあるAPI呼び出しです。

   Ostorlabによる支援

   認証後のテストは、ログインとログアウト、トークン更新、タイムアウト、セッション無効化、ロックアウトを、その背後のAPI呼び出しとともにテストし、各検出結果の再現手順を報告します。

   お客様が担うこと

   アラートチャネル、再開プロセス、アラートを消費する不正監視ルール。

7. 07

   RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第22項、第24項、第68(10)～68(13)項；Digital Lending Directions, 2025, 第12項、第13項

   端末上と転送中のデータを保護する

   条文の内容

   Webアプリケーションは、HTMLの隠しフィールド、Cookie、その他のクライアント側ストレージに機密情報を保存してはなりません。暗号管理は、非推奨や安全でないと証明されたものではない強力な鍵長、アルゴリズム、暗号スイート、プロトコルを使用する必要があります。モバイルアプリは、ユーザーID、パスワード、キー、ハッシュ、ハードコードされた参照などの機密の個人情報や認証情報を端末に保存・保持してはならず、顧客がアプリを終了したら機密情報をメモリから安全に消去する必要があります。一時ファイルへの書き込みを制限して保護し、生のSQLクエリとSQLインジェクションを避け、SSL/TLSネゴシエーションのエラーを検知した場合はWebコンテンツを読み込まないようにします。アプリのデータベースに書き込む機密情報は暗号化する必要があります。融資アプリについては、Digital Lending Directionsが、ファイルやメディア、連絡先、通話履歴、電話機能などの端末リソースへのアクセスを禁止し、デジタルレンディングのデータをインド国内のサーバーに保存することを求めています。

   出典：RBI (Commercial Banks – Digital Payment Security Controls) Directions, 2026, 第22項、第24項、第68(10)～68(13)項；Digital Lending Directions, 2025, 第12項、第13項

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

   パスワード、トークン、個人データは、端末上や一時ファイル、ログ、スクリーンショットの中に平文で存在してはならず、バックエンドへ無保護で送信されてはなりません。

   Ostorlabによる支援

   Ostorlabは、ローカルストレージ、キャッシュ、ログ、一時ファイル、スクリーンショットの中のセッショントークンと個人データを探し、転送とセッションの保護を弱める設定ミスを確認し、何がどこにいつ書き込まれたかを示すファイルシステムの証拠を取得します。

   お客様が担うこと

   データ分類、鍵管理、バックアップ、プライバシー通知、データ漏えい防止。

8. 08

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第47項、第126～135項；Digital Payment Security Controls Directions, 2026, 第32項

   コンポーネントと第三者を把握する

   条文の内容

   業務アプリケーション、支援するITインフラ、ハードウェア、ソフトウェア、サービスを含む情報資産の最新のインベントリを、業務上の重要度とともに維持します。デジタル決済セキュリティ指針は、コードに重大な変更を加えるたびに、アプリケーションが既知の脆弱性、マルウェア、隠れたチャネルを含まないことを示す証明書または書面による確認を開発者またはベンダーから取得すること、第三者からライセンスを受けたアプリケーションにはソースコードエスクローなどの措置を講じることを求めています。第三者との取り決めには、リスクと重要性に見合ったベンダーリスク評価、デューデリジェンスと監督、監査権を定めた契約、インフラの所在地と国境を越えるデータ移転への注意が必要です。

   出典：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第47項、第126～135項；Digital Payment Security Controls Directions, 2026, 第32項

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

   モバイルバンキングアプリには、自社のバックエンドと通信する第三者のSDKが組み込まれています。それらは資産インベントリ、SBOM、第三者リスクの視点に含めるべきです。

   Ostorlabによる支援

   Ostorlabは、各リリースのSDKとネイティブライブラリをバージョンとアプリバンドル内の位置とともに一覧化し、リリースごとに既知の脆弱性と突き合わせ、アプリとSDKがネットワーク上でバックエンドと何をやり取りするかを示します。

   お客様が担うこと

   資産台帳、ベンダーのデューデリジェンス、サプライヤー証明書、エスクロー契約、契約書。

9. 09

   RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第37項、第98～103項、第153項

   脆弱性とパッチを期限付きで管理する

   条文の内容

   パッチの業務影響を評価し、必要な承認を得て安全かつ適時に適用し、適用失敗から回復する手段を備えた、文書化された変更・パッチ管理方針を整備します。パッチ適用が必要なコンポーネントのインベントリを維持し、該当するパッチを特定して期限内に適用し、脆弱なシステムの数と露出期間を最小化する、文書化されたリスクベースの戦略を採用します。ソフトウェアのサポート終了日を監視し、古い、またはサポートされていないソフトウェアを避けます。特定した脆弱性は期限を定めて修正し、CVEデータベースにあるような既知の脆弱性が再発しないことを確認します。

   出典：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第37項、第98～103項、第153項

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

   アプリ内のライブラリとSDKは、お客様が提供するソフトウェアです。それぞれに既知のバージョン、脆弱性が現れたときの深刻度、証明できる修正期限が必要です。

   Ostorlabによる支援

   SCAは静的にコンパイルされたライブラリを特定し、リリースごとに既知の脆弱性と突き合わせます。検出結果はクリティカル、高、中、低に評価され、プラットフォームまたはJira、ServiceNowのチケットとして追跡され、修正のリリース後に再テストされます。

   お客様が担うこと

   サーバーとインフラのパッチ適用、ベンダー保守契約、リスク受容の判断。

10. 10

    RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第182項；CERT-In指示 No. 20(3)/2022-CERT-In, 2022年4月28日；Digital Personal Data Protection Rules, 2025, 第6規則・第7規則

    インシデントと漏えいを報告し、ログをインド国内に保存する

    条文の内容

    サイバーインシデントは、検知から6時間以内にRBIの先進的な監督モニタリングシステムであるDAKSHプラットフォームに報告し、CERT-Inにも通知する必要があります。CERT-Inの2022年指示では、指定されたインシデントは認知から6時間以内にCERT-Inへ報告し、ICTシステムのログをインドの管轄内で安全に180日間（ローリング）保存し、システム時計をNICまたはNPLの時刻に同期する必要があります。DPDP Rules 2025では、個人データ漏えいは、影響を受けるデータ主体に遅滞なく、データ保護委員会にも遅滞なく通知し、72時間以内に詳細情報を提出する必要があり、セキュリティログは1年間保存する必要があります。

    出典：RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, 第182項；CERT-In指示 No. 20(3)/2022-CERT-In, 2022年4月28日；Digital Personal Data Protection Rules, 2025, 第6規則・第7規則

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

    アプリやAPIを通じて見つかった漏えいでは、時間との勝負になります。6時間と72時間の期限は検知から始まり、証拠をすぐに用意できる必要があります。

    Ostorlabによる支援

    OstorlabはRBI、CERT-In、データ保護委員会への報告を行いません。報告に必要な、再実行できるエクスプロイト、リクエストとレスポンスのログ、ファイルシステムの証拠などの技術的証拠を提供し、検出結果をクローズまで追跡して、何をいつ修正したかを示せるようにします。

    お客様が担うこと

    検知と監視、DAKSHとCERT-Inへの報告、漏えい通知、法的評価。

RBI、MeitY、CERT-Inの公開文書の要約です（2026年9月27日時点で確認）。2026年7月の指針は商業銀行に適用されます。RBIは他の規制対象にも同様のエンティティ別指針を公表しており、本ページで引用する2021年と2023年の文書は、商業銀行について2026年7月31日に廃止されました。これは法的助言ではありません。