BDDKとCBRTの規則に沿って、あなたの モバイルバンキングアプリ を毎回のリリースの前後にテストしましょう。

1. 01

   BSEBY 第18条第7項、BDDK通達BSD.2012/1（範囲および方法、トルコ語文書）

   モバイルアプリを含む年1回のペネトレーションテストを実施する

   条文の内容

   銀行は、テスト対象のシステムの設計、開発、実装、運用に関与・担当しないチームにより、少なくとも年1回ペネトレーションテストを実施させる必要があります。BDDKのペネトレーションテスト通達が枠組みを定めており、基本テストと詳細テストを、少なくともインターネット、銀行の内部ネットワーク、支店ネットワークから実施し、Webアプリケーションとモバイルアプリケーションを含む最低限の範囲を対象とします。検出結果は通達の重要度で評価し、通達の形式で報告します。どの資産を優先するかの判断は銀行に委ねられます。

   出典：BSEBY 第18条第7項、BDDK通達BSD.2012/1（範囲および方法、トルコ語文書）

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

   モバイルアプリケーションは明記されたテスト領域です。アプリとそのAPIは、WebアプリケーションやATMシステムと並んで、年次テストのうちインターネット側の部分に含まれます。

   Ostorlabによる支援

   AIエージェントによるペネトレーションテストは、ストア版のビルドとログイン後のAPIをテストし、AIエージェントによる各検出結果に再実行できる動作するエクスプロイトとカバレッジのヒートマップを付けます。通達が定めるネットワーク、支店ネットワーク、ATM、ソーシャルエンジニアリングの部分は代替しません。

   お客様が担うこと

   年次テスト全体の実施、内部ネットワークと支店ネットワークの部分、資産の優先度判断、社内プロセスへの結果の反映。

2. 02

   BSEBY 第22条第4項・第5項、第24条

   インターネット公開アプリをリリース前と更新ごとにテストする

   条文の内容

   銀行が開発したものでも外部から調達したものでも、インターネットに公開されるアプリケーションは、インストール前に、また更新のたびに、セキュリティ脆弱性のスキャンと確認を行う必要があります。認可とアクセス、本人確認、データの完全性、ログ、例外処理といったセキュリティ要件は、開発または調達の開始時から定め、変更は要求管理、リスク評価、テスト、承認を経て本番環境に投入します。

   出典：BSEBY 第22条第4項・第5項、第24条

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

   モバイルアプリの新しいバージョンは、インターネット公開アプリの更新そのものです。リリース前後の確認が最低ラインであり、その間にストアへ出る版も監視すべきです。

   Ostorlabによる支援

   Mobile SASTはソースコードなしでAPK、AAB、IPAを解析し、Mobile DASTはアプリを実行します。どちらもCI/CDに組み込めます。ストア公開版は手動トリガーなしで監視するため、スプリントの合間に出た更新も見落としません。

   お客様が担うこと

   セキュアコーディング標準、ソースコードレビュー、リリース承認、同じテストを求めるベンダー契約条項。

3. 03

   BSEBY 第34条第14項・第15項、BDDK 2023/1号通達 別紙第1節（トルコ語文書）

   アプリを強化し、侵害された端末を検知する

   条文の内容

   電子バンキングのために顧客へ提供するソフトウェアとモバイルアプリは、銀行由来であることが検証可能で、顧客の安全を脅かすコードを含まず、脆弱性を解消するパッチと更新を受け取れる必要があります。スマートフォン上の銀行アプリが使う重要なデータは、同じ端末上の他のアプリやプロセスからアクセスできないようにし、端末の紛失・盗難時に保護し、端末の奪取、信頼性の低下、OSの破壊や置き換えから生じるリスクを現行技術に適した管理策で低減する必要があります。2023/1号通達は、アプリとSDKの完全性、anti-keylogging、anti-injection、anti-debugging、anti-emulation、端末への紐付け（device-binding）、anti-malware、jailbreak検知といった管理策を詳述し、専用のセキュリティサーバーへ別の安全な経路で送信することを求めています。

   出典：BSEBY 第34条第14項・第15項、BDDK 2023/1号通達 別紙第1節（トルコ語文書）

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

   ここがroot、jailbreak、改ざんの領域です。検知は出発点にすぎず、アプリは検知した内容に応じて動作し、チェックは簡単に無効化できないようにする必要があります。

   Ostorlabによる支援

   Mobile Shielding Scanは、root化・jailbreak・計測ツール導入済みの環境でアプリを実行し、各保護の回避を試みたうえで、アプリが処理を遮断するのか、起動を拒否するのか、動作を続けるのかを示し、ハードニングスコアと回避の証拠を提供します。

   お客様が担うこと

   保護SDKの選定と設定、侵害端末の扱いに関するポリシー、セキュリティサーバーの構築。

4. 04

   BSEBY 第34条第1項・第6項・第9項、第38条第1項

   独立した2つの要素をオンラインで検証する

   条文の内容

   顧客データの表示のような財務上の結果を生まない取引を含め、電子バンキングサービスには、顧客が知っているもの、顧客が所有するもの、生体特徴という異なるクラスから選んだ少なくとも2つの要素による認証が必要です。要素は互いに独立であること、所有する要素は顧客に固有で模倣できないものであることが求められます。顧客が知る要素は顧客自身が入力し、銀行側でオンラインに検証する必要があり、アプリやブラウザが記憶して自動送信したり、端末内の認証方法に結び付けたりしてはなりません。失敗が一定数を超えたら利用者のアクセスを遮断し、ワンタイムパスワードは推測が難しい長さで、ランダムに生成し、限られた期間だけ有効とします。

   出典：BSEBY 第34条第1項・第6項・第9項、第38条第1項

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

   MFAはサーバー側で強制されるもので、アプリが画面に描くものではありません。ロックアウトのしきい値、OTPの有効期間、アプリが手順を飛ばしたときの挙動は、テストできる振る舞いです。

   Ostorlabによる支援

   認証後のテストでは、ログインとログアウト、トークン更新、セッションのタイムアウト、MFAの強制を、ステップアップや回避の試みも含めて、テスト用アカウントと背後のAPI呼び出しとともにテストします。

   お客様が担うこと

   認証方式の選定、ロックアウトのしきい値、OTPの有効期間の設定。

5. 05

   BSEBY 第34条第7項・第8項

   SMSワンタイムコードをアプリのチャネルから外す

   条文の内容

   モバイルバンキングアプリをインストールして有効化した顧客に対して、銀行はログインやセッション中の取引検証のためにSMSによるワンタイムパスワードや確認コードを送信できず、SMSを認証要素として使うこともできません。SMSコードが認められるのは、アプリの初回インストール、有効化、再有効化、またはアプリが使用不能になった場合だけです。顧客がSIMカードを変更したり、番号ポータビリティで事業者を変更したりした場合、銀行は携帯通信事業者との連携でこれを検知する必要があり、変更が確認されるまで90日間はSIMカードに基づく要素を使用できません。

   出典：BSEBY 第34条第7項・第8項

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

   アプリにはSMS以外の第二のチャネルが必要です。SMSが例外的に使われた場合の挙動や、SIM変更と再有効化の扱いもテスト対象です。

   Ostorlabによる支援

   Ostorlabはテスト用アカウントでSMS、メール、TOTPのコードを完了させ、アプリを有効化した顧客に対してサーバーが今もSMSコードを送信・受理していないかを確認し、有効化、番号変更、ステップアップの背後にあるAPI呼び出しをテストします。

   お客様が担うこと

   通信事業者との連携、SIM変更の確認フロー、顧客への周知。

6. 06

   BSEBY 第35条、第38条第3項、BDDK 2023/1号通達 別紙第1節・第2節（トルコ語文書）

   表示された内容を顧客が承認できるよう取引に署名する

   条文の内容

   電子バンキングの取引は、否認防止と責任の所在の明確化を可能にする必要があります。顧客に割り当てられた秘密鍵で署名されるワンタイムの確認コードを生成し、コードから認証要素が分からず、既知のコードから別の有効なコードを導けず、模倣もできないようにします。財務上の結果を生む取引では、顧客が承認した金額と受取人に固有のコードとし、どちらかが変わると無効になります。2023/1号通達は、専用SDKと銀行のセキュリティサーバー、顧客の鍵を端末の暗号処理ハードウェア（Secure Enclave、ハードウェア背後のキーストア、Strong Boxなど）で生成・保管すること、アプリの通常のバックエンド通信とは別のチャネルでの相互TLS、署名要求ごとのセキュリティチェックを求めています。

   出典：BSEBY 第35条、第38条第3項、BDDK 2023/1号通達 別紙第1節・第2節（トルコ語文書）

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

   見たものに署名するという性質はバックエンドのものですが、アプリ側で破綻し得ます。オーバーレイ、注入されたコード、改ざんされた画面は、顧客が承認したつもりの内容を変えてしまいます。

   Ostorlabによる支援

   Ostorlabは、コード表示後に金額や受取人が変わった場合の挙動、コードの再利用や導出ができないか、署名フロー周辺のAPI呼び出しを含めて、アプリの取引表示と署名をテストします。

   お客様が担うこと

   セキュリティサーバー、鍵のライフサイクル、取引テンプレート、否認防止の記録。

7. 07

   UKTY（銀行が使用する遠隔本人確認の方法に関する規則）第4条、第6条、第7条、第8条、第10条、第11条

   遠隔での口座開設を管理されたプロセスとして運用する

   条文の内容

   遠隔本人確認は、訓練を受けた顧客担当者と本人との、リアルタイムで中断のないビデオ通話で行います。本人確認書類は可能な限りNFCで検証し、セキュリティ要素、写真、署名を白色光の下で確認し、セッション全体を監査できるよう記録します。ライブネス検知を行い、偽の顔技術への追加対策を講じ、本人の顔と書類の写真を照合し、疑わしい場合はプロセスを中止します。本人確認に使用できるのは、特別カテゴリの個人データである生体データのみで、明示的な同意を電子的に記録します。プロセスは導入前にテストし、年2回以上見直します。責任は銀行に残り、遠隔で獲得した顧客には追加のセキュリティ対策を適用します。

   出典：UKTY（銀行が使用する遠隔本人確認の方法に関する規則）第4条、第6条、第7条、第8条、第10条、第11条

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

   口座開設フローは高リスクです。カメラ、NFC、生体認証、稼働中のバックエンドが関わります。攻撃者が最初に狙うフローでもあり、偽の顔、エミュレーター、傍受が使われます。

   Ostorlabによる支援

   Ostorlabは口座開設のAPIとアプリ側のチェックをテストします。エミュレーターやroot化端末での挙動、録画や合成の顔でライブネスを欺けるか、セッションが保護されているか、本人確認の要素を端末側でどう保存するかを確認します。

   お客様が担うこと

   顧客担当者のプロセス、ビデオ基盤、書類検証の判断、保存期間、規制当局への届出。

8. 08

   KVKK法第6698号 第4条・第12条、KVKK「モバイルアプリにおけるプライバシー保護のための勧告」2025年3月（トルコ語文書）

   端末上でKVKKのセキュリティ義務を満たす

   条文の内容

   個人データ保護法第6698号により、データ管理者は、個人データの違法な処理と違法なアクセスを防ぐために必要なすべての技術的・組織的措置を講じ、必要な監査を実施する必要があります。個人データが第三者に違法に取得された場合、データ管理者は本人に通知し、できるだけ速やかに理事会へ届け出なければなりません。KVKKは2025年に更新したモバイルアプリ向けの勧告で、プライバシー・バイ・デザインとプライバシー・バイ・デフォルト、通信中および保存時の個人データの暗号化、パスワードのハッシュ化、定期的なパッチ管理とソフトウェア更新、公開前のソフトウェアテスト、ログイン失敗回数の制限、権限・通知・プライバシー設定に対する利用者の制御を求めています。

   出典：KVKK法第6698号 第4条・第12条、KVKK「モバイルアプリにおけるプライバシー保護のための勧告」2025年3月（トルコ語文書）

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

   KVKKの義務は、アプリが何を収集し、どう保護するかに関わります。権限、SDKのデータフロー、ローカル保存、ログ、スクリーンショットがテストされる場所です。

   Ostorlabによる支援

   Ostorlabはビルドに含まれるSDKを一覧化し、それらがアクセスできる範囲を整理し、保存領域、キャッシュ、ログ、スクリーンショットに個人データやトークンがないか調べます。通信の保護を確認し、何がどこで露出しているかを報告します。

   お客様が担うこと

   データ分類、法的根拠、同意記録、保存期間、データ侵害の通知。

9. 09

   BSEBY 第16条、CBRT「決済機関および電子マネー機関の情報システムに関するTebliğ」第12条（トルコ語文書）

   脆弱性を期限付きで管理する

   条文の内容

   銀行は、脆弱性情報の収集、影響評価、修正方法と期限の定義、記録の保持、パッチを適用できない場合の代替管理策の設定を含む、脆弱性およびパッチ管理プロセスを運用する必要があります。自動脆弱性スキャンツールは、最も重要な検出結果を優先度付きで情報セキュリティ責任者と対象システムの管理者に報告します。決済機関と電子マネー機関に対しては、CBRTのTebliğがより具体的に、サーバーと通信ネットワークを年6回以上かつ初回稼働前に脆弱性スキャンし、テスト対象システムのセキュリティに関与しない、国内または国際的なペネトレーションテストの資格を持つ個人または企業による年1回以上のペネトレーションテストを求めており、検出結果は理事会承認の行動計画のもとで可能な限り速やかに修正し、侵害、テスト結果、重大な脆弱性を含む報告書を年1回以上CBRTへ提出します。

   出典：BSEBY 第16条、CBRT「決済機関および電子マネー機関の情報システムに関するTebliğ」第12条（トルコ語文書）

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

   ここでは2つの期限の考え方が交わります。BSEBYに基づく銀行自身のパッチ期限と、決済機関に対するCBRTの年6回のスキャンと年1回のテストです。どちらも追跡可能な修正と再テストのループを必要とします。

   Ostorlabによる支援

   検出結果は critical、high、medium、low で評価し、プラットフォーム内またはJiraやServiceNowのチケットにまとめ、影響を受けるコンポーネントとリリースに対応付け、修正が届いたら再テストします。履歴は行動計画と年次報告に使えます。

   お客様が担うこと

   サーバーとネットワーク機器へのパッチ適用、理事会承認の行動計画、CBRTへの提出。

公開されているBDDK、CBRT、KVKKの文書の要約です（2026年9月27日時点で確認）。BSEBYの条文は、特に断りのない限りBDDKの英訳に基づきます。2023/1号通達、2012年のペネトレーションテスト通達、CBRTのTebliğはトルコ語の文書から要約しています。本ページは法的助言ではありません。