読者です 読者をやめる 読者になる 読者になる

sos の 作業メモ

プログラミングや英会話学習、マイルや旅行、日常生活など。最近はWebFormなASP.NETのお守りがお仕事です。

日々の生活にhappyをプラスする|ハピタス Gポイント

「Androidアプリ テスト技法」第2章後編

読書 android

Androidアプリテスト技法

Androidアプリテスト技法

前回の続き

プライバシーとセキュリティのテスト

プライバシーとセキュリティの関係

プライバシーとは

  • 個々に関わる個々の情報、個人式別情報
  • 管理者が管理・保持する情報
プライバシーと個人情報

単独で特定の個人を識別するものではないが、何かと関連づけることで個人情報となるデータ(名前と住所、購買履歴等)の扱いをどうするか、国内外で議論が行われている。

プライバシーと行動追跡

個人を行動追跡するID(3rd party cookieや広告のTrackingID、携帯電話の端末ID等)の登場により、プライバシーに対する懸念や議論が発生した。

IDの活性期間を時間と空間の二つの軸で考えた場合に、どちらかが著しく大きい場合、社会的に認められない風潮になってきている(AppleのUDIDの使用禁止など)

プライバシーと匿名性

位置情報や行動履歴のような情報を扱う場合、容易に個人を特定されないようにデータを加工することが求められる。

  • k-匿名化

    年齢等や郵便番号等の各属性情報をグルーピングした際に、k人未満になるものを取り除いたり一般化して特定を防止する。(kが4で、郵便番号が600-8815が1人, 600-8816が3人なら、これらを600-88**とする)

  • l-多様化

    趣味や行動履歴といった情報の種類をl個以上に増やすことで特定を防止する。

セキュリティとは

以下の維持と定義されている

  • 可用性

    正当な利用者に対して、情報と機能の利用を保証する

  • 完全性

    情報と機能を利用する際に、改竄や改変がないことを保証する

  • 機密性

    暗号化などを行って、認可された第三者以外がアクセスできないことを保証する

利用許諾契約とセキュリティ技術

現在、プライバシー権個人情報保護法という新しい課題に対して、アプリ開発者が対応を迫られている。 こうした中、有識者による研究会で、ガイドラインの検討が行われている。

利用者視点を踏まえたICTサービスに関わる諸問題に関する研究会「スマートフォン プライバシー イニシアティブ」

プライバシーポリシーに基づく利用許諾の合意形成が、プライバシー問題への対策に有効とされるが、法的文章のEULAは、ユーザーには読みにくく、システムにも内容を認識しづらいという問題がある。

合意形成のための仕組み

著作権やプライバシー権に関わらず、利用者許諾とセキュリティ連携に関する問題を解決するには、提供者、利用者、プラットフォームが相互に利用可能な共通仕様に基づいたルール作りが必要。

テスト手法

プライバシーに対するテスト

実際のセキュリティ問題のほとんどは「アクセス制限の不備」。この様な基本的な問題は、十分な仕様の定義と仕様に基づいたテストによって対応が可能。

PbD(Privacy by Design)

近年、プライバシー情報について「使う段階になって考える」のではなく「設計段階から織り込む」べきという思想が、PbDとして世界的に合意を得て来ている。

PbDの7原則

  • 事前的/予防的
  • 初期設定としてのプライバシー
  • デザインに組込む
  • ゼロサムではなくポジティブサム
  • 徹底したセキュリティ(ライフサイクル全体を通じての保護)
  • 可視性/透明性
  • 利用者のプライバシーの尊重

この原則に従って、設計に組込んで行く。

  • プライバシー要求の洗い出し
  • 個人を識別するデータフローの分析
  • プライバシー保護の要求仕様の策定
  • プライバシー要求をデザインに組込む
  • FIPsの考え方に基づいて開発
  • テスト / 確認

FIPs(Fair Information Practices)とは、米国の個人情報取り扱いの原則

  • 通知: 個人情報を集めるものは、情報の取り扱いについて、事前に当事者に開示すること
  • 選択: 個人時右方を収集しても良いかと、その使用方法について、当事者に選択権を与えること
  • アクセス: 収集した個人情報を、当事者が参照及び訂正が可能なこと
  • セキュリティ: 情報の不正利用に対して、妥当な手段を図ること
セキュリティ要求の洗い出し例

セキュリティ対象資産の分類

アプリユーザーの資産 アプリベンダーの資産
情報 ユーザーの個人情報 - 電話帳、メール、端末ID、各アカウント アプリを構成するリソース - ソースコード、アルゴリズム、画像や音楽
機能 ユーザーの利用端末機能 - 電話、カメラ、ネットワーク、NFC アプリの提供する機能 - アプリの機能、クラウド

守るべきものと守らなくても良いものを整理する。PbDはガイドラインなので、プロセスに厳密な定義はない。

セキュリティに対するテスト

アプリケーション資産への脅威

利用する情報や機能といった資産にたいして起こりうる脅威人ついて考える。悪意のある攻撃より、盗難や紛失の可能性の方が高いことを考慮する。

セキュリティ技術による防衛
  • ユーザー個人情報

    脅威 対策例
    プライバシー情報を不正に取得される、漏洩する、改変される 個人情報を暗号化、アクセス権を限定、セキュアなクラウドにデータを退避
  • ユーザー端末機能

    不正な権限でアプリの各機能を利用される アクセス権を限定、機器の利用の監視
  • ベンダーアプリリソース

    著作権情報を不正に取得される、漏洩する、改変され流通される。アルゴリズムを盗用される DRM、電子透かしを利用する、ソースコードを難読化する
  • ベンダーアプリサービス

    不正な権限でアプリやサービスを利用される 署名検証を行う、ID認証する

セキュリティテストの種別

ファズテスト(ファジング)

機械的な方法でランダムに生成した値をつかって脆弱性をあぶり出す自動テスト。

ペネトレーションテスト

悪意を持った相手(クラッカー)を想定した疑似侵入テスト。Androidの脆弱性は、脆弱性対策データベースにまとまっている。


これで座学の部分は終了。ちっとも身に付いていない気もしますが、次章で実際に手を動かして楽しんでみます

次回へ続く