妥協のないエアギャップテスト：安全かつスケーラブル

セキュリティは速度低下を意味するものではない：エアギャップ環境におけるアプリケーションテストの近代化

規制対象企業におけるソフトウェアエンジニアリングの文化には、セキュリティの代償はスピードであるという根強い誤解がつきまとっている。つまり、データをオンプレミス（ネットワーク境界内、ファイアウォールの内側、コンプライアンス管理の対象となる場所）に保持することを選択すると、構築に時間がかかり、拡張が困難で、常に最新のエンジニアリング動向に遅れをとるテストインフラストラクチャを受け入れることになる、という誤解である。 

その神話はもう終わりにすべき時だ。 

エアギャップ環境やネットワーク制限環境で運用されている組織（PCI-DSSおよびSOC 2に準拠する金融機関、HIPAAおよびFDAのソフトウェア検証要件に準拠する医療システム、FedRAMPまたはCMMCに準拠する連邦政府機関など）にとって、オンプレミスでのデバイスラボテストに関する議論は、これまでセキュリティと俊敏性、コンプライアンスとスピード、あるいは制御と最新のツールとの間のトレードオフとして捉えられてきました。 

その考え方は間違っています。そして、その考え方を乗り越えたエンジニアリングチームは、真に強力なものを提供しています。それは、テストデータを外部サービスに1バイトも送信することなく、自社内で完全に実行される、フルスタックで自動化された、観測可能なテストパイプラインです。 

SaaSテストツールが建物内に入り込めない場合 

エアギャップされた、あるいは高度に制限されたネットワーク環境は、単なる好みの問題ではなく、規制上およびアーキテクチャ上の現実です。病院システムが臨床機器に接続するモバイルアプリを実行する場合、検証サイクルを流れるテストデータには、保護された医療情報が含まれる可能性があります。銀行がコアバンキングプラットフォームのモバイルフロントエンドをテストする場合、トランザクションデータは、決して機関の管理された環境から外に出てはなりません。  

SaaSテストプラットフォームを便利にしているアーキテクチャ、すなわちリモートデバイスクラウド、共有インフラストラクチャ、外部エンドポイントを経由するトラフィックルーティングは、まさにこれらの環境ではSaaSプラットフォームが機能しない原因となるアーキテクチャと同じです。解決策はツールを妥協することではなく、エンタープライズクラスのデバイスラボインフラストラクチャをネットワーク内に取り込むことです。 

既に所有しているハードウェア 

見落とされがちな点として、規制対象企業のほとんどは、世界レベルのデバイスラボを構築するために必要な機器を既に保有しているということが挙げられる。 

小売銀行は、モバイルバンキングアプリをスマートフォンでテストするだけでなく、既存のATMインターフェース、支店のPOS端末、現場担当者が使用するBluetooth接続のカードリーダーなど、あらゆる機器との取引フロー全体を検証する必要があります。看護師向けのiOSアプリを検証する病院システムは、臨床現場に既に設置されている携帯型診断機器とのBluetoothペアリングをテストする必要があります。モバイル認証ソリューションを展開する連邦政府機関は、既存のアクセス制御ハードウェアとのNFCおよびBluetoothの連携をテストする必要があります。 

このインフラストラクチャは既に企業内に存在します。オンプレミスのデバイスラボは必ずしも調達を必要とするわけではなく、チームが既に業務で使用しているハードウェアを接続して一元化するだけで済みます。スマートフォン、タブレット、臨床周辺機器、決済ハードウェア、IoTエンドポイントなど、デバイスラボプラットフォームをネットワークに導入した瞬間から、これらは一流のテスト対象となります。また、テストセッションがATMや臨床周辺機器から物理的に隔離されているリモートデバイスラボとは異なり、オンプレミスラボでは、Bluetooth、USB、NFC、ローカルWi-Fiを介して、周囲の運用ハードウェアとテスト自動化が直接接続できます。  

その結果、アプリ単体だけでなく、インタラクションスタック全体を検証するテストカバレッジが実現します。 

クイック Deployスケールに合わせて構築 

オンプレミスインフラストラクチャに関する最も根強い誤解の一つは、導入に数ヶ月かかるというものです。実際には、エンジニアリングチームは数日（四半期ではなく）で物理デバイスの登録、並列テスト実行の設定、ラボとCI/CDパイプラインの接続を行い、自動テストスイートの実行を開始できます。  

実際にそれがもたらすもの： 

大規模な並列実行。 手動のデバイスキューで何時間も連続して実行される可能性のあるモバイルテストスイートを、さまざまなOSバージョン、フォームファクター、ハードウェア構成など、あらゆるデバイスマトリックスに分散させ、結果を数分で集計できます。チームがどのようなテスト自動化フレームワークを使用していても、スイートはキューの優先順位とデバイスの可用性を尊重する中央スケジューラによって制御され、並列で実行されます。 

構造化された結果と一元化されたスケジュール管理。 構造化されていないアドホックなテストは、決定論的なスケジューリングに置き換えられます。CIコミットごとに自動的にトリガーされるテスト、夜間に実行される回帰テストスイート、そしてTestRail、Xray、あるいは社内管理システムなど、テスト管理プラットフォームに直接フィードされる構造化された結果成果物などが含まれます。 

完全な可視性と監査対応設計。 すべてのテストセッションでは、デバイスログ、スクリーンショット、ビデオレポート、フレームワークレベルの実行ログ、クラッシュレポート、ネットワークキャプチャなど、完全な監査証跡が生成されます。FDA規制対象のソフトウェア検証を実施する医療機関にとって、これはIQ/OQ/PQ検証記録の証拠となります。PCI DSS準拠を実証する金融サービスチームにとっては、すべてのテスト実行の改ざん防止ログとなります。根本原因分析に注力するエンジニアリングチームにとっては、「テストが失敗した」という結果と「失敗発生時にデバイスが正確に何をしていたか」という結果の違いを生み出すものとなります。 

チームが既に利用しているツールを活用する 

オンプレミス型デバイスラボの導入において最も重要なアーキテクチャ上の決定事項は、ハードウェアではなく、統合サーフェスです。規制対象企業は、JenkinsやGitLab CIを実行するCI/CDパイプライン、pytest、TestNG、Cucumberなどのフレームワークによるテストオーケストレーション、Splunk、ELKスタック、Grafanaを中心とした監視インフラストラクチャなど、社内ツールチェーンに多額の投資を行っています。 

適切に設計されたオンプレミスのデバイスラボは、それらすべてに接続できます。  

金融サービス機関にとって、これがどのように展開するかを考えてみましょう。  

彼らの Jenkins パイプラインは、リリース ブランチへのマージのたびにトリガーされ、アプリケーションの新しいバージョンをビルドしてクラウドにアップロードし、組織独自の在庫から取得した iOS および Android デバイスのプール全体に自動テストを分散します。テスト結果は Jenkins に公開され、デバイスごとの内訳とビデオ レポートを含む Allure レポートの生成がトリガーされます。その他のテスト実行ログは、既存の Splunk インスタンスに直接転送されます。本番環境のアプリケーションの状態を監視するのと同じダッシュボードで、テスト実行のテレメトリが表示されます。不安定性の傾向、デバイス固有の失敗率、OS バージョン間のテスト期間の回帰などです。ネットワークから何も外部に出ません。そして、エンジニアリング チームは、ほとんどの SaaS ベースのサービスが提供するような、テスト実行に関するより詳細な可視性を得ることができます。 

エンジニアリングチームが実際に得ているもの 

こうした取り組みを正しく行っている組織は、セキュリティとエンジニアリングの卓越性を相反するものとして捉えることをやめています。モバイルアプリのビルドをプルリクエストごとにデバイスマトリックス全体でテストする、シフトレフト検証サイクルを採用しています。回帰テストスイートの実行時間を1桁時間以内に抑える並列化ポリシーを徹底しています。デバイスラボのテレメトリデータを監視プラットフォームに転送し、品質指標をインフラストラクチャやアプリケーションの健全性指標と並べて表示できるようにしています。これは未来的なビジョンではありません。規律あるチームが、銀行、病院システム、連邦政府機関など、自社のネットワーク内で既に構築しているものです。 

正しい質問は決して「社内にとどまることで、私たちは何を失うのでしょうか？" その "デバイスラボがネットワークの一部となることで、私たちはどのようなメリットを得られるのでしょうか？その答えは、外部環境では到達できないハードウェアカバレッジ、コンプライアンス対応のテスト成果物、より高度な可観測性、エンドツーエンドの統合検証であり、テストデータ、デバイスログ、セッション記録のパケットが一切お客様の管理下から離れることはありません。 

セキュリティ対策自体がチームの作業を遅らせるのではなく、設計の不十分なシステムが作業を遅らせるのです。適切なツールを用いて構築された安全な環境は、テストの実施方法を現代化することができます。