目次
関連ブログ
現代のモバイルアプリはこれまで以上に保護されています。これは良いことです。
しかし、多くのチームが手遅れになるまで気づかない副作用があります。 セキュリティが強くなるほど、アプリを自動化してテストすることが難しくなります。
アプリシールド、改ざん防止、証明書ピンニング、ランタイムチェックは、攻撃者を阻止するために設計されています。しかし、多くの場合、これらの機能はテスト自動化ツールの停止も引き起こします。しかも、明確なフィードバックなしに、サイレントに停止させてしまうのです。テストは不安定になり、自動化の開始時にアプリがクラッシュしたり、CIパイプラインが明確な理由もなく失敗したりします。
これは 見えない壁 モバイル テスト: 最も重要で最も安全なアプリが、結局は最も自動化されていないアプリになってしまうのです。
「セキュリティ保護されたアプリ」とはどういう意味ですか?
この文脈では、セキュリティ保護されたアプリとは、次のような保護機能を備えたモバイル アプリケーションを指します。
- 改ざん防止とデバッグ防止
- コードの難読化
- ルート化と脱獄の検出
- 証明書の固定
- ランタイムアプリケーション自己保護 (RASP)
これらの保護は、銀行、フィンテック、ヘルスケア、政府、および機密性の高いユーザーデータを扱うあらゆるアプリで一般的です。
これらの防御機能は、内部的に「疑わしい」動作(デバッガー、フレームワークのフック、コードの変更、信頼できないデバイス、予期しないランタイムアクセスなど)を常に監視しています。何か問題が見つかった場合、アプリは機能をブロックしたり、完全にシャットダウンしたりする可能性があります。
問題は、テスト自動化ツールは、その設計上、疑わしいものになりやすいことです。
セキュリティを有効にすると自動化が機能しなくなる理由
強力な保護を有効にすると、使い慣れたテスト パターンが失敗し始めます。
- UI 自動化フレームワークは、ブロックされる可能性のあるインストルメンテーションとアクセシビリティ フックに依存しています。
- 証明書のピン留めにより、テスト中に使用されるトラフィック検査が中断されます。
- ルート化とジェイルブレイクの検出により、多くのラボやクラウド環境でテストが実行されなくなります。
- デバイス クラウドでは、企業のセキュリティ シナリオに必要な詳細なシステム構成が制限されることがよくあります。
テスターの観点から見ると、ランダムな感じがします。
- 自動化が開始されるとすぐにアプリは閉じます。
- ログインは手動では機能しますが、CI では失敗します。
- テストはローカルでは合格しますが、ラボでのみ失敗します。
ログは限られており、エラーは曖昧です。セキュリティチームは自動化がブロックされていることにすら気付かないかもしれません。
これが生み出すギャップ(そしてそれがなぜ重要なのか)
自動化とセキュリティが共存できない場合、チームは通常、次の 3 つのパターンのいずれかに陥ります。
- 保護されていないビルドをテストし、本番環境でも同様に動作すると想定します。
- テスト環境での保護を無効にするか弱めます。
- 安全なフローについては手動テストに大きく依存します。
これら 3 つはすべて、信頼が最も重要となるところでリスクを生み出します。
皮肉なことに、アプリに対する敏感さが増すほど、大規模なアプリの実際の動作に対するチームの可視性は低下する傾向があります。
本当の緊張:テスターと攻撃者は同じように見える
ここに不快な真実があります:
- 攻撃者はフック、インストルメンテーション、ランタイム検査を使用します。
- セキュリティ チームは同じ手法を使用して防御を検証します。
- テスト自動化フレームワークは、アプリを駆動するために同様のメカニズムに依存しています。
アプリに、 誰もが攻撃者のように見えます。
ほとんどのモバイル保護機能は、危険な環境を検知するのに非常に優れていますが、不正な計測機器と信頼できる自動化機器を自然に区別することができません。すべてがデフォルトで危険なものとして扱われると、自動化機器が巻き添え被害に遭うことになります。
目に見えない壁はここから生じます。
今日の市場の動向
業界は分裂している:
- セキュリティベンダーは、強力なランタイム保護、アンチフック、整合性チェックに重点を置いています。
- テスト プラットフォームは、デバイスの範囲、速度、CI/CD 統合に重点を置いています。
どちらの側も実際の問題を解決しますが、多くの場合は独立して解決します。
その結果、チームは、安全でテスト可能なアプリがどのようなものであるべきかという共有モデルがないまま、セキュリティ SDK、デバイス クラウド、社内ラボ、手動の回避策を組み合わせます。
より良い未来への道:テスト可能性を考慮したセキュリティ
私たちが実際に目にした変化は、概念はシンプルですが、その影響は強力です。 セキュリティとテスト可能性は一緒に設計する必要があります。
「テストのセキュリティをどう回避するか」と尋ねる代わりに、チームは次のように尋ね始めます。
- 弱体化されたビルドではなく、保護されたビルドをテストできますか?
- セキュリティは、新たな攻撃経路を開くことなく、信頼できるテスト環境を認識できますか?
- セキュリティが何かをブロックした場合、テスターは明確で実用的なシグナルを確認できますか?
環境を考慮したポリシー、バックエンド主導の決定、CI パイプラインで自然に機能する短命の信頼メカニズムなど、いくつかの最新のアプローチはすでにこの方向に進んでいます。
鍵となるのは意図です。 テストを理解しているセキュリティは敵ではありません。
実際に「良い」とはどういうことか
バランスが適切であれば、いくつかのことが実現します。
- テストと本番環境では同じセキュリティ保護されたビルドが使用されます。
- 保護は継続されます – ショートカットや特別なコード分岐はありません。
- 自動化の失敗は、セキュリティ ルールが原因であるのか、機能上のバグが原因であるのかを明確に示します。
- CI パイプラインは、セキュリティの結果を、不可解なクラッシュではなく、第一級のシグナルとして扱います。
セキュリティチームが制御を維持し、テスターが可視性を獲得します。 Release遅くなるのではなく、自信が増します。
機能性を超えて:壁が崩れたら何が可能になるのか
保護されたアプリのテストという課題を解決することは、機能の自動化を回復するだけでなく、品質と信頼性のまったく新しい可能性を切り開きます。
保護されたアプリがテスト プラットフォーム内で確実に実行できるようになると、チームはさらに次のことを行うことができます。
- セキュリティ保護のパフォーマンスへの影響を検証する
セキュリティガードは無料ではありません。保護されたビルドでパフォーマンステストを実行できれば、ランタイムチェック、暗号化、整合性制御が起動時間、応答性、ユーザーエクスペリエンスにどのような影響を与えるかを、ユーザーが実感する前にチームが理解できるようになります。 - セキュリティ保護をより迅速かつ大規模にテスト
自動化により、様々な保護シナリオを繰り返し、一貫して検証することが可能になります。少数のケースを手動でテストする代わりに、チームはデバイス、OSバージョン、ワークフロー全体にわたって保護を実施できるため、カバレッジの向上と盲点の削減が可能になります。 - セキュリティ動作をテスト可能な動作として扱う
保護機能はもはやブラックボックスではありません。チームは、アプリの他の部分と同様に、ガードがいつどのようにトリガーされるかを観察し、期待どおりに動作することを確認し、リグレッションを早期に発見できます。
言い換えれば、セキュリティ保護されたアプリがテスト可能になると、セキュリティ自体が単なる想定ではなく、観察、測定、改善可能になります。
好奇心旺盛なテスターが今日から試せること
このトピックに共感する方は、次の実用的な最初のステップを実行してください。
- 保護されたビルドでのみ自動化が失敗する場所を特定します。
- 次のような共通言語を使ってセキュリティ担当者と会話を始める OWASP モバイル Application Security 検証基準 (MASVS)。
- 「あらゆるデバイス上のあらゆるアプリ」ではなく、セキュリティ保護されたアプリをどのようにサポートしているかをベンダーに直接問い合わせてください。
セキュリティの専門家である必要はありません。適切な質問をするだけの好奇心があれば十分です。
安全かつテスト可能な未来
セキュリティと自動化の間には目に見えない壁が確かに存在しますが、それは避けられないものではありません。
適切なマインドセット、共有されたオーナーシップ、そして現実世界の保護のために設計されたプラットフォームがあれば、チームはセキュリティと品質のどちらかを選ぶ必要がなくなります。保護されたアプリを弱体化させることなくテストし、盲点なく自動化を拡張し、機能性だけでなく、実際の状況におけるセキュリティの挙動についても自信を持つことができます。
At Digital.aiまさにこれが、私たちが日々解決に注力している課題です。チームが、保護機能を無効化することなく、また速度や可視性を犠牲にすることなく、本番環境で実際に実行されるセキュアなモバイルアプリをテストできるよう支援することです。セキュリティとテストが競合するのではなく連携することで、品質が向上し、リスクが早期に顕在化し、リリースの予測可能性が向上します。
さらに詳しく知りたいですか?
安全なモバイル アプリのテストをさらに詳しく知りたい場合は、次の実用的なリソースを活用してください。