[W3C PING]Self-Review Questionnaire: Security and Privacy の要点まとめ
W3CのPrivacy Interest Group(PING)が公開している、「Self-Review Questionnaire: Security and Privacy(自己評価質問集: セキュリティーとプラバシー)」というGroup Noteの大事なところを日本語でまとめていきます。英語の原文は以下です。
この文書は、W3Cの中のグループが最初のPublic Working Draftのレビュー依頼をする前に、セキュリティー・プライバシーに関する確認事項をまとめたものになります。Horizontal reviewに関しては以下のページがまとまっています。
概要
本文書はウェブプラットフォーム技術のセキュリティ・プライバシーに関して評価する際に使われる一連の質問集をまとめています。
はじめに
ウェブプラットフォームにおいて新機能を設計する際に常にセキュリティとプライバシーについて考慮しなければなりません。設計のプロセスの変更がしやすい早期の段階でこの質問集を参照しましょう。プライバシーやセキュリティーの問題は機能がリリースされた後に見つかると設計を変えるのが遥かに難しくなります。
質問集
どのような種類の情報が他者から参照することができますか？
必要最低限の情報のみが参照できるようになっていますか？
個人情報、個人を識別できる情報(personally-identifiable information / PII)、それらから派生した情報をどのように扱うのでしょうか？
機密情報をどのように扱うのでしょうか？
セッションを超えて状態を保持するような設計をしていますか？
基盤プラットフォームに関する情報がオリジンから参照可能でしょうか？(基盤プラットフォームの情報とは、ユーザーの設定データ、センサーなどの入出力端末のハードウェアの有無と属性、様々なソフトウェア機能の有無と挙動などの情報のこと)
オリジンから基盤プラットフォームにデータを送ることが可能でしょうか？
センサー端末等にアクセス可能でしょうか？
新たなスクリプトの実行・読み込みを許可するでしょうか？
オリジンに対して他の端末にアクセスするのことを許可するでしょうか？
オリジンに対してユーザーエージェントのネイティブUIの制御を許可するでしょうか？
どのような一時的な識別子を作成、そしてウェブ上から閲覧できますか？
ファーストパーティとサードパーティをどのように見分けますか？
ブラウザのプライベートモードやIncognitoモードでどのように挙動しますか？
仕様内にセキュリティ・プライバシーの懸念事項の記述はありますか？
実装しようとしている機能によって、オリジンのセキュリティレベルを引き下げることはありますか？
実際の仕様から古くなってしまったドキュメンテーションに対し、どのように対処しますか？
さらにどんなプライバシーに関する懸念があるか考えてみましょう
懸念事項
以下はウェブプラットフォーム上の機能を構築する上で、考慮すべき具体的なプライバシーの懸念事項です。
監視(Surveillance): 個人のコミュニケーションや活動を観測したり、モニタリングすること
保存されたデータの漏洩(Stored Data Compromise): 認証されていなかったり、適切でないアクセスからの適切なデータの保護方法を講じていないエンドシステム
侵入(Intrusion): 人々の生活や活動を妨げたり、中断させるような侵略的な行為を意味する
誤属性(Misattribution): 個人に関するデータやコミュニケーションが他人に帰属してしまうこと
相関(Correlation): 個人に関する情報を集めた様々な組み合わせや、組み合わせた時に個人が分かること
識別(Identification): 個人の身元情報を紐付け個人を推定することや、個人特定を可能にすること
二次利用(Secondary Use): 情報が収集された元の目的とは違う用途で個人の許可なしに使用すること
情報漏洩(Disclosure): 他人が個人を判断する際に影響を与えるような情報の暴露のこと
除外(Exclusion): 他者が持っている自分自身のデータに対して知ることができず、取り扱いや使用に関して関与できないこと
セキュリティ・プライバシーリスクへの緩和策
1. 参照できるデータを最低限のものにする
ユーザーを介したアクセスで得られた情報以上の権限を与えない、または、ユーザーがどの情報を提供するか制御する権限を与えます。
例えば、とあるファイルに対してユーザーがアクセス権限があるとします。 この時、そのファイルの親ディレクトリや関係のない情報は閲覧できないようにするべきです。
2. デフォルトのプライバシー設定
ユーザはあまりデフォルトの設定を変更しません。 デフォルトの状態の使用が、最小限のデータの量・識別可能性・永続性を考慮することが重要です。
3. ユーザーの仲介をする(Explicit user mediation)
もし仕様だけでプライバシー等のリスクを防げないのであれば、ユーザーに対して何かしらのアクションを促すことを実装者に推奨しても良いでしょう。
例えばGEOLOCATION API(位置情報API)の場合は、ユーザーに対して「許可をしますか？」といったお知らせが出ます。これでユーザーは自由に位置情報の共有に関して選択ができます。
4. ファーストパーティオリジンのみに機能制限をする
Webページは一つのアプリケーションにファーストパーティとサードパーティのコンテンツを混ぜて表示します。これにより、ファーストーパーティの内容をサードパーティ側が悪用する場合があります。
5. セキュアな通信
オリジンがセキュアでないと、攻撃者が任意のコードをインジェクションできてしまいます。暗号化・認証された通信を行うようにしましょう。
6. 機能実装の取りやめ
セキュリティ・プライバシーの問題の一番シンプルな改善策は、その機能を実装しないことかもしれません。
7. プライバシー影響評価の実施
実装する機能によっては、そもそもデータ自体が機密データの可能性があります。そのような機能においては、実装者に対し、データのプライバシーの影響評価を行う勧告を行うべきです。
まとめ
Web仕様を決める際にどんなことを考慮すれば良いかがわかりました。扱うデータそのものが機密かどうか、誰からそのデータが参照可能か、などさまざまなことを検討しました。