仮日本語訳

ICT システムのための「データプロテクション・バイ・デザイン」のガイド
Guide to Data Protection by Design for ICT Systems

２０１９年５月３１日

Personal Data Protection Commission (PDPC), Singapore
Privacy Commissioner for Personal Data (PCPD), Hong Kong

1

目次
１．はじめに
１．１ データプロテクション・バイ・デザインの概要＿＿＿＿＿＿＿＿＿＿

3

１．２ 本ガイドの目的 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

3

１．３ データプロテクション・バイ・デザインの原則 ＿＿＿＿＿＿＿＿＿＿__ 4
１．４ データプロテクション・バイ・デザインと SDLC ___＿＿＿＿＿＿＿＿＿__ 6
１．５ データプロテクション・バイ・デザインとアジャイルソフトウェア開発 _______

7

１．６ 既存 ICT システムのためのデータプロテクション・バイ・デザイン ________

8

２．ICT システムにおけるデータプロテクション・バイ・デザインのグッドプラクティス
２．１ グッドプラクティス ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_ 9
２．２ データ保護影響評価（DPIA）＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_ 10

２．３ ICT システムによる個人データの収集 ＿＿＿＿＿＿＿＿＿＿＿＿＿_ 11
２．４ 目的の提示とデータ保護方針 ＿＿＿＿＿＿＿＿＿＿＿＿＿___________ 13
２．５ ユーザの個人データの同意を取得 ＿＿＿＿＿＿＿＿＿＿＿___________ 15
２．６ ICT システムの開発 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_ 17
２．７ オンライン方式 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿___________ 18
２．８ アクセス制御 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿___________ 21
２．９ ICT システムの試験 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿___________ 25
２．１０ ICT システムにおける個人データのアクセス、訂正、正確さ _____________ 27
２．１１ ICT システムにおける個人データの管理 ＿＿＿＿＿＿＿＿＿＿____ 28
２．１２ ユーザデバイスのセキュリティ ＿＿＿＿＿＿＿＿＿＿＿＿____________ 29
２．１３ データのエクスポート ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_____＿__ 30
２．１４ ICT システムにおける個人データの保存 ＿＿＿＿＿＿_________________ 33
２．１５ 保守フェーズ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_____________________ 34
謝辞 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_________________________________ 35

2

１．はじめに
１．１ データプロテクション・バイ・デザインの概要
ICT（情報通信技術）システムのためのデータプロテクション・バイ・デザイン（DPbD）は、個人データを取り扱う ICT システムの開発において、開発プロセスの中にデータ保護対策を組み込むためのひとつのアプローチです。データ保護原則を最初から取り入れることで、個人データをより安全に保護し、優れたデータ管理を実践する文化を組織の中に醸成することができます。また、ICT システムの始
まりから終わりまでのライフサイクルを通して DPbD を実践することにより、後でデータ保護機能を追加するのに比べ、不必要な遅れやコストを抑えることにも役立ちます。DPbD を後付けで対処するのではなく、組織の実働の中に組み込むことが大切です。

１．２ 本ガイドの目的
このガイドは、ICT システムを設計および構築する際に、DPbD を適用したいと考える組織を支援することを目的としています。対象者はシステムもしくはソフトウェアの開発を実施する IT プロジェクトマネージャ、システム設計者、ソフトウェア開発者です。データ保護責任者（DPOs）は、どのように優れた実践がシステム開発
プロセスの中に適用されるのかをよく理解できるようになります。このガイドでは次の事項が記されています。
・DPbD の原則
・ソフトウェア開発ライフサイクル（SDLC；Software Development Lifecycle）の各フ
ェーズにおける DPbD の活動
・ICT システムの優れたデータ保護の取り組み
なお、このガイドで述べたヒントや優れた取り組みは網羅的なものではなく、すべての状況に関連しているわけではありません。それぞれの組織で、対象としているビジネスや運用状況に合わせて合理的かつ適切に実践することが必要です。

3

１．３ データプロテクション・バイ・デザインの原則
カナダのオンタリオ州の前情報プライバシー保護委員であるアン・カブキアン博士（Dr. Ann Cavoukian）が開発したプライバシー・バイ・デザインの７つの基本原則 1
はよく認知されており、多くのデータ保護の専門家がよく参照しています。
この７つの基本原則を参考にすると、ICT システム開発を進めるための適切かつ重要な７つの DPbD 原則は以下のようになります。
① 事前的かつ予防的データ漏えいが起こる前にデータ保護リスクの評価、特定、管理、そして予防を行います。優れたデザインやデータ管理を実践することでリスクを最小限にできます。
② デフォルトとしてのデータ保護
データ保護対策はシステムのプロセスや機能に統合されていなければなりません。個人が自分の個人データを保護するのではなく、個人データを保護する手段はデフォルト設定として自動的に提供されていることが必要です。
③ エンド・ツー・エンドのセキュリティ
セキュリティ対策はソフトウェア開発ライフサイクル（SDLC）全体にわたって配慮する必要があります。個人データが収集されてからシステムで削除されるまで、SDLC の各フェーズに優れたセキュリティの機能や実践を組み込むことができます。
組織とベンダーがどのように連携するのか、またソフトウェア、ハードウエア、製品、サービス、プラットフォームなどの ICT システムの要素がどのように連携す
るのかという観点から、ユーザは「エンド・ツー・エンド」で徹底して検討を行う
必要もあります。
この「エンド・ツー・エンド」の観点から脆弱な部分を探しだし、システムのセキ
ュリティを強化する方法を評価してください。
④ データ最小化
個人データを扱うとき、「まずはデータを集め、あとで何をするかを考える」というアプローチをしないでください。データ最小化とは、目的達成に必要なだけの個人データを収集し、保存し、使用することを意味します。

注 1: https://www.ipc.on.ca/wp-content/uploads/resources/7foundational principles.pdf
4⑤ ユーザ中心
ユーザ個人を中心にして考える、つまり個人の個人データの保護を目的としてICT システムを開発し実装してください。デフォルトを設定すると同時に、個人がその設定をカスタマイズできる機能や方法を提供してください。そのインタフ
ェースはユーザフレンドリーでなくてはいけません。例えば、必要なときに通知される「ジャストインタイム」や階層化された通知などの機能を適用することです。
⑥ 透明性
何の個人データが収集され、どのように使われているのかをユーザ個人に積極的に知らせるようにしてください。さらに、第３者がその個人データを処理していることを知らせてください。そのような情報をユーザに提供するために適切な手段を選択して使用してください。これらはユーザとのインタラクションあるいはジャストインタイムの通知とは異なる観点です。
⑦ リスク最小化
DPbD の重要なポイントはデータ保護のリスクをシステマティックに特定して軽減することです。個人データが処理される際のシステムの適切な処置と、関連する ICT セキュリティ対策が設計され実装されていることで、リスクを減らすことができるのです。

5１．４ データプロテクション・バイ・デザインと SDLC
ソフトウェア開発ライフサイクル（SDLC）の各フェーズにおける主要な DPbD の活動を以下に示します。

SDLC フェーズ

DPbD の活動
ここから DPbD が始まります。データ保護の観点から不明確な目的ある

要件

いは合理的でない要件を評価して選別してください。そのような要件を削除します。

設計

開発

試験

移行

DPｂD 原則がシステムアーキテクチャレベルの設計に組み込まれていることを保証するための重要なフェーズです。
システムが開発されるフェーズで、DPｂD 原則が考慮され、その結果としてシステムのさまざまな機能や要素に反映されます。
試験の結果から、前フェーズで定義された要件や DPｂD の考慮事項
が、システムに組み込まれていることを確認するチェックフェーズです。
システムをリリースする準備フェーズです。リリース直前にシステムの処
理や構成の最終チェックを行います。
システムのセキュリティを維持し、移行後のシステムをより堅固にするた

保守めのフェーズです。組織がシステムを見直したり更新したりするときに、引き続き DPｂD が適用されていることが必要です。

6

１．５ データプロテクション・バイ・デザインとアジャイルソフトウェア開発
前節に述べたソフトウェア開発モデルは一般に「ウォーターフォール」モデルと呼ばれています。ウォーターフォールモデルでは、システム開発のすべての要件が事前に整理され、SDLC のひとつのフェーズとして順番にかつほぼリニアにまとめて実行されます。
これに対し、アジャイルソフトウェア開発はソフトウェア開発のもうひとつの方法です。ウォーターフォールに比較すると、アジャイルソフトウェア開発はたくさんの開発サイクルがあるなかで、各サイクルに必要な要件を少しずつ満たしながら、繰り返し開発を進める方法です。
アジャイルの各サイクルは、ウォーターフォールの SDLC において部分的に関連するところがあり、このガイドで述べるグッドプラクティスはアジャイル開発モデルにも適用することができます。
実際、アジャイル開発では、基本的な機能設計や当初からの変更に対して、より柔軟により低コストで実現できる可能性があります。そのため、可能なら最初のサイクルで、すぐに構築できなくとも、DPｂD 機能が考慮され計画されることで費用対効果が高くなると考えられます。
データ保護影響評価（DPIA；Data Protection Impact Assessments）について、ア
ジャイルプロジェクトの初期段階でできるだけ多くの情報を利用して包括的なDPIA を実施することが望まれます。その後に続くサイクルのなかであるいは DPIAを繰り返し実施することで、DPIA による評価を更新することができます。

7

１．６ 既存 ICT システムのためのデータプロテクション・バイ・デザイン
新たな ICT システムに DPｂD を組み込むことが望ましいのですが、現実には少な
くともいくつかの既存 ICT システムを組織が保有していることが多いと思います。それでは、既存 ICT システムのデータ保護を改善するために、組織は何ができるのでしょうか。
マリリン・プロシュ（Marilyn Prosch）准教授とアン・カブキアン（Ann Cavoukian）博士
は既存 ICT システムのための「プライバシー・バイ・リデザイン」2 の概念を開発しました。コンセプトは３つの R です。
・再考（Rethink）は、どんな個人データが収集され、その収集がほんとに必要か否かを検討してリスクを評価するなど、システムを徹底的に見直すことです。この再考
段階で DPIA を実施するのが適切です。
・再設計（Redesign）は、個人データをより適切に保護し、以前に見つかったリスクを減らすことで、関連する DPｂD のグッドプラクティスを実装することです。
・再生（Revive）は、データ保護を強化したシステムから新たに始めることです。
組織は、リエンジニアリングのプロセスは一度に実装するか、複数フェーズに渡って段階的に実装するかを決定します。

注 2：http://www.ontla.on.ca/library/repository/mon/25005/310082.pdf
8

２．ICT システムのためのデータプロテクション・バイ・デザインのグッドプラクティス

２．１ グッドプラクティス
この章では ICT システムのための DPｂD のグッドプラクティス（優れた実践や取り組み）を紹介します。このグッドプラクティスはトピックごとにまとめられています。ユーザは関連するグッドプラクティスを選び、自分たちの ICT プロジェクトに適合させることが必要です。なお、ここにあげたグッドプラクティスはすべての領域をカバーしているわけではないので気をつけてください。
グッドプラクティスを適用する箇所を知ってもらうことでソフトウェア開発者をサポートするため、各グッドプラクティスと最も関連する SDLC のフェーズ、および一般的に使われる「3 階層（3-Tier）」のアーキテクチャ（プレゼンテーション、アプリケーシ
ョン、データ）4 において関連する層を表中のチェック印で明示しています。なお、
グッドプラクティスと SDLC や層との関連付けは規定されたものではありません。

注 3：３階層（3-Tier）のプレゼンテーション（表現）層は情報の表示やユーザとの対話を担当
し、アプリケーション（応用）層はアプリケーションのビジネスロジックを管理し、データ（DB）層
はデータを保存し管理する場所である。
訳注：本注は原文では注 4 であるが、注 3 がないために項番を繰り上げた。以降も同様。
9

２．２ データ保護影響評価（DPIA）
DPIA は SDLC のどの時点でも実行されるかもしれないが、DPｂD の本来の目的か
ら言えば、新たな ICT システムの予備設計の時点がタイミング的によい。

グッドプラクティス

SDLC フェーズ

これは個人データに関する新 ICT システム
設計のギャップやリスクを特定して評価するのに役立ちます。ICT システムの予備設計の変更や必要に応じて特定したギャップやリスクの軽減策を組み込むことも可能です。
詳しくは PDPC のデータ保護影響評価のためのガイド（Guide to Data Protection Impact
Assessments）を参照のこと。

10

要 設 開 試 移 保 表
件 計 発 験 行 守 現

〇 〇

〇

データ

新 ICT システムの目的達成に必要な個人データのタイプと処理について厳密に評価します。

アプリ

１．開発の前に DPIA を実施

３階層

２．３ ICT システムによる個人データの収集
収集しても使わない個人データを所有することで、組織は余計なリスクを背負うことになります。不必要な個人データの保護に必要なリソースは、最初から収集しないことで単純にカットすることができます。すなわち、もっとも良い収集の方法は、組織にとって真に必要な個人データは何かをまず考えることなのです。

グッドプラクティス

SDLC フェーズ

３階層

要 設 開 試 移 保 表
件 計 発 験 行 守 現・組織の機能や活動に直接的に関連する法
律的、合理的な目的があること。
・目的を逸脱しないこと。
同じ目的のために異なるタイプの個人データを使う際には、最も機密性の低い個人データを収集してください（例えば、ユーザの正確な位置ではなく、おおよその位置データを収
集）。

〇 〇

〇 〇 〇

〇 〇

〇 〇 〇

２．どうしても必要なときには、個人の識別子
情報（例えば個人識別番号）だけを収集
個人を直接識別する固有の値になるので、ほんとうに必要か否かについて、よく検討する必要があります。
シンガポールでいえば、法律で定められているとき、あるいは厳密に個人の身元を立証あるいは検証が必要なときは、国民登録番号カード (NRIC; National Registration
Identification Card)だけを収集してください。
詳細な情報は、PDPC の NRIC や他の国民識別番号のための個人データ保護法に関するアドバイザリーガイドライン（Advisory
Guidelines on the Personal Data Protection
Act for NRIC and Other National
Identification Number）を参照のこと。
11

データ

収集する明確な目的があり使用する予定のある場合をのぞき、個人データを収集しないでください。各データ項目に対し、収集時に以下のことを確認してください。

アプリ

１．最小限の個人データを収集

グッドプラクティス

SDLC フェーズ

３階層

要 設 開 試 移 保 表
件 計 発 験 行 守 現

〇 〇

〇

〇 〇

〇 〇 〇

〇 〇 〇

〇 〇 〇

〇 〇 〇

４．個人データは継続的に収集せず、必要なときに収集
例えば、モバイルアプリでは、ユーザの位置
情報を常に収集するのではなく、ほんとうに必要なときにだけユーザの位置を収集する
オプションを提供してください。
５．個人データを自動的に収集せず、ユーザの入力で収集便利さを好むユーザもいれば、介入されるのを嫌がるユーザもいる。例えば、モバイルア
プリでは、自動的に位置の追尾を行うのではなく、ユーザに自分の位置情報を示すオプ
ションを提供してください。

12

データ

メタデータ（例えば、画像ファイルの EXIF データ）として、意識せずに個人データを収集してしまうことがあります。このようなデータは収集しないか、必要がないのであれば削除することを考えてください。

アプリ

３．メタデータに注意２．４ 目的の提示とデータ保護方針
組織は、例外のない限り、個人に個人データ収集の目的を提示し、個人データを収集し、使用し、公開するための同意をとることが必要です。
組織が個人データの使用と保護だけでなく、データの収集、使用、開示などの目
的やデータ保護方針を分かりやすく説明することに、ユーザの期待が高まっています。明確で簡潔な通知は、何よりも組織が優先して実行することのひとつです。

グッドプラクティス

SDLC フェーズ

３階層

個人データの収集に際して、項目ごとに必須な否かを明確にしてください。必須の項目では、ユーザが情報を提供しなかったときの結果を説明してください。

要 設 開 試 移 保 表
件 計 発 験 行 守 現

〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

２．収集した個人データをリスト化
個人データについて「何の」情報を「どのように」収集したのかということをリスト化してくだ
さい。例えば、GPS や Wi-Fi アクセスポイントを介して収集した位置情報という具合です。
３．第３者をリスト化（もしあるのなら）個人データを処理する第３者、どの個人データを第３者に提供するのか、そしてその目的は何かをリスト化してくだ
さい。
４．DPO の連絡先をリスト化
ユーザがデータ保護に関する質問をする際に、必要な DPO の連絡先がよく分かるようにしておいてください。

13

データ

ユーザにとって個人情報の収集理由が明確でないときに特に必要になります。

アプリ

１．収集の目的を説明

５．つねにシンプル化

３階層

要 設 開 試 移 保 表

組織のデータ保護方針は簡潔にかつ読み易 件 計 発 験 行 守 現
くするようにしてください。そうすることで、読まれる可能性が高くなります。
〇 〇〇 〇６．他のデータ保護方針を単純コピーしない
データ保護方針案を作成する段階で、他の組織のデータ保護方針を参考にする際、自組織固有のニーズに合うように方針を修正することが重要です。すなわち新たな事項を追加したり、無関係な事項を削除したりすること
です。

〇 〇

〇 〇

〇 〇 〇

〇 〇

７．階層的にアプローチ
データ保護方針にたくさんの情報が入りすぎるときには、まず概要を説明し、個々の詳しい内容はユーザが選択できるように検討してください。
８．ジャストインタイムにアプローチ
情報過多を抑えるもう一つの方法は、ジャス
トインタイムあるいはダイナミックなアプローチ（個人データが収集される直前、もしくは許可 〇 〇 〇を得る直前に通知）です。まずは短文で説明
し、オプションとして全文を閲覧できるようにし
ます。

〇 〇

９．グラフィック情報を使用
文字ばかりのデータ保護方策で説明する代
わり、いくつかの場面ではグラフィック情報で説明できるようにしてください。

14

〇 〇

〇 〇

データ

SDLC フェーズ

アプリ

グッドプラクティス

２．５ ユーザの個人データの同意を取得
ユーザの個人データを使用するためにユーザから同意を得る際に、ICT システムを効果的に役立てることができます。加えて、ICT によって組織が同意を管理し、同意記録を容易にチェックできるようになります。

グッドプラクティス

SDLC フェーズ

３階層

要 設 開 試 移 保 表
件 計 発 験 行 守 現
〇 〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

２．合意はデフォルトのアクションではなく、ユーザに明示的なアクションを要求
ユーザが明示的な同意アクションを確実に行えるようにしてください。例えば、ユーザはチェックボックスにチェックマークをつけるようにします。（自動的にデフォルトが選択され）あらかじめチェックマークがついている方法を採用してはいけません。
３．マーケティング資料を受け取る同意とは別に要求
マーケティング資料を受け取る同意をユーザから得るときには、例えば、２番目のチェックボックスを使うなど、個人データの同意とは別に要求してください。
４．ユーザの同意内容を記録
ユーザがある項目に同意し、他の項目に同意しない場合があります。そのため、ユーザの同意内容や同意日時を記録に残すことが重要です。これは同意記録とも呼ばれます。

15

〇 〇 〇

〇 〇 〇

データ

できるだけシンプルで簡潔な言葉を使ってください。もし文章が長くなる時は、概要をまず説明し、詳細な内容を説明するオプションを提供することを検討してください。

アプリ

１．ユーザが何に同意するのかを明確に説明グッドプラクティス

SDLC フェーズ

要 設 開 試 移 保 表
件 計 発 験 行 守 現

〇 〇

〇 〇

６．合意の撤回を許可
ユーザに同意を撤回する手段を提供してください。手動による方法（例えば、メールで撤回を要求する方法）や自動的な方法によって実現できます。自動的な方法を使ったときには、同意撤回の記録を監査記録に反映させ易くなります。
ユーザが同意を撤回することがあれば、その結果をユーザに知らせることは有益です。また、組織にとっても同意撤回の要求状況をユーザに知らせることも有益です。

16

〇 〇 〇

〇 〇 〇

データ

同意を得るために組織で使われる文面は時とともに変わる可能性があります。しかし、これらの文面は体系的にアーカイブされていないことが多いのです。そのため、異なるバージョンの文面のコピーを保管する適切な方法を考えてください。バージョンごとにそれが使われ始めた日付を保管しておくと、ある期間に使われた文面を確認することができます。バージョン管理ソフトによりアーカイブが実現できるでしょう。例えば、ユーザとの訴訟にその記録が役に立ちます。

アプリ

５．同意文面のコピーを保管

３階層

２．６ ICT システムの開発
ICT プロジェクトを立ち上げる前に組織が直面するのは、新しいシステムを開発す
るのか、それとも既存システムを使用するのかという判断です。選択したアプローチ
によって、注意すべき事柄が変わってきます。

グッドプラクティス

SDLC フェーズ

データ

要 設 開 試 移 保 表
件 計 発 験 行 守 現

アプリ

１．ICT ベンダーにセキュリティ要件を詳細に説明

３階層

ICT ベンダーにオーダーメイドのソリューションを開発してもらうときは、組織のデータ保護
やセキュリティの要件をベンダーに詳細に説明することが必要です。それらの要件は開発〇 〇 〇 〇 〇 〇 〇 〇 〇作業の一部として文書化され、十分な要件であることを確認してください。
２．既製のソリューションのときは、使用する前にソリューションを理解
既製のソリューション（購入あるいはオープン
ソースのシステム）を使うときは、個人データを扱うソリューションが何をするのかを理解してください。個人データが十分に保護されることに、組織が確信を持てるときにだけソリューションの使用を開始することが重要です。

〇

〇

〇

既製のソリューションあるいはコンポーネントを選択したとき、開発者によるサポートが充実しているか否かを検討してください。サポートのないソフトウェアは修復（パッチ）できない脆弱な部分、すなわち永続的な脆弱性が存在する可能性があります。
３．パッチを適用
ICT システムの関連するコンポーネントに更新とセキュリティパッチをできるだけ早くテストして適用してください。これらをタイミングよく行うには、何らかの形で（手動あるいは自動）でモニタリングする必要があるでしょう。

17〇〇 〇 〇 〇 〇

２．７ オンライン方式
本節ではさまざまな形式のユーザが入力を行うウェブアプリケーションに関するガ
イドを述べます。主な脅威には、悪意のあるファイルのアップロード、クロスサイトス
クリプティング（XSS）、SQL インジェクション、URL 操作があります。
詳しくは、PDPC の「電子メディアのための個人データの保護に関するガイドライン（Guide to Securing Personal Data in the Electronic Medium）」の中の「ウェブサイ
トとウエブアプリケーションセキュリティ（Websites and Web Application Security）」の章を参照してください。

グッドプラクティス

SDLC フェーズ

３階層

このリストは、インジェクション、不適切なセキ
ュリティ設定、クロスサイトスクリプティング、既知の脆弱性のあるコンポーネントの使用などの一般的にもっとも重要なウェブアプリケー
ションのセキュリティリスクについて提案しています。またそれらのリスクの防御のやり方についても説明しています。例えば、SQL イン
ジェクションの防御には、クエリパラメータ化、エンコーディング、文字エンコード、文字エス
ケープ、入力検証があります。

要 設 開 試 移 保 表
件 計 発 験 行 守 現〇 〇〇 〇 〇 〇

〇 〇

〇

〇

〇

データ

HTTPS は、セキュリティ機能付きの HTTP で暗号化した情報を送ります。（セキュリティ機
能なしの）HTTP では、組織のデータをそのまま送るため、ネットワークの途中で個人データが容易に抜き取られてしまいます。
２．OWASP の最も重要なウェブアプリケーションリスク・トップ１０4 の対策を実装

アプリ

１．HTTP でなく HTTPS を使用

OWASP トップ１０プロアクティブコントロール 5は、防御の技法と制御に焦点をあてた別の関連文書です。制御の各項目ではトップ１０リ
スクのひとつ以上のリスクの防御策を説明しています。
訳注：OWASP(オワスプ：The Open Web Application Security Project) https://www.owasp.org
注 4: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
注 5: https://www.owasp.org/index.php/OWASP_Proactive_Controls

18

SDLC フェーズ

要 設 開 試 移 保 表
件 計 発 験 行 守 現

WAF は SQL インジェクションやクロスサイト
スクリプティングのような典型的なウェブアプリ
ケーション攻撃に対抗することが目的です。
つまり、アプリケーションのコードレベルの対〇 〇策に加えて、WAF はもうひとつのセキュリティ
層として機能することができます。

アプリ

３．ウェブアプリケーションファイアウォール（WAF）を使用

３階層

データ

グッドプラクティス〇

４．アップロードファイルをマルウェアスキャン
ユーザがアップロードしたファイルには、故意か無意識かにかかわらず、マルウェアが入っているかもしれません。ファイルを何かに使う
前には、ファイルにマルウェア対策が施されていることを確認してください。

〇 〇 〇

〇 〇

〇

〇 〇 〇

〇

〇

・データをデータベースに保存する前にアプ
リケーションで暗号化する。データベースから〇 〇 〇引き出したデータはアプリケーションで復号化する必要があります。

〇 〇５．ユーザ入力を検証
ユーザが入力したデータが有効であることを確認するとともに、データ検証によって URL
操作や SQL インジェクションやバッファオー
バーフロー攻撃などのセキュリティ侵害を防ぐことができます。
６．保存データを暗号化
セキュリティ強化のために保存する個人デー
タを暗号化してください。保存データを暗号化する方法は：・データベースで暗号化（アプリケーションでは処理しません）

鍵の管理が効果的な暗号化のために重要になります。
さらに、産業界が適切かつ安全な方法として認識していることを確認するために、定期的に暗号化の方法（例えば、アルゴリズムや鍵の長さなど）を見直してください。
19〇 〇グッドプラクティス

SDLC フェーズ

データ

十分なセキュリティ機能による保護の強化が必要なときは、個人データの分離を検討してください。データを分離して付加的な保護を行う例として、以下のようなものがあります。

要 設 開 試 移 保 表
件 計 発 験 行 守 現

アプリ

７．より保護が必要な個人データを分離して保護

３階層

・少数の選ばれたユーザグループのみにアクセス許可（いわゆる「知る必要性」原則（“need to know”basis）に基づく）
・高度な監視、警報、監査証跡、監査などの採用
・より厳重なパスワードの要請（例えば、長いパスワードや頻繁なパスワードの変更）
リレーショナルデータベースでは、一つの分離方法に水平分離があります。すなわちデータベースのレコードあるいは行でデータを分離します。もう一つの方法は、データベー
スのフィールドあるいは列の分離による垂直分離です。異なるデータベースに分けて保存する方法はより強固な保護になるかもしれません。また、同じデータベースでも異なるテーブルにするのがいいでしょう。

〇 〇 〇

〇

〇 〇

〇

〇

〇

データ全体の量に比較してセンシティブな個
人データが少数になるときには分離はより効果的になる可能性があります。
８．自由記述欄の情報を注意して使用
ユーザが個人データを自由記述欄に常に書き込むことができることに注意してください。
データ検証とともに、このような形式の個人データを検出するのは難しくはないでしょう。

20

２．８ アクセス制御
ユーザが要求する個人データのアクセスを許可すべきか？認証され承認されたユーザだけが当該情報にアクセスを許可されていることを、組織がどのように確認できるのか？本節のグッドプラクティスはこれらの質問に対処するのに役立ちます。
詳しくは、PDPC の「電子メディアのための個人データの保護に関するガイドライン（Guide to Securing Personal Data in the Electronic Medium）」の中の「認証と承認とパスワード（Authentication, Authorisation and Passwords）」を参照してください。

グッドプラクティス

SDLC フェーズ

３階層〇

データ項目や DPIA の詳細な情報は、本ガイドの前節を参照してください。
２．アプリケーションのアクセス制御を実装
セキュリティ技法であるアクセス制御は個人
データを保護する基本的な方法です。これは多くの場合、認証（ユーザであることを確認）と承認（ユーザが要求されたリソースにアクセスする権限を持っているか否かを確認）のことです。
適切なアクセス制御の手段を使用してください。これは多くの場合、個人データの保存場所に依存します。例えば、アプリケーションからアクセスされる個人データの多くはデータ
ベースに保存されており、その場合はアプリ
ケーションでアクセス制御を実装します。
組織は、個人データへのアクセスについて、
例えば、いくつかの属性だけはあるユーザのみがアクセスでき、他の属性は別のユーザだ
けがアクセスできるように、きめ細かく制御することを検討してください。
21

〇 〇 〇

〇

データ

要 設 開 試 移 保 表

保存場所が分からないと保護することができ
件 計 発 験 行 守 現ません。データベースの他に、個人データは一時ファイル、生成したレポート、他 ICT シス
テムとの通信ファイル、バックアップ等にあります。これはシステムデザインの一部で、システムの設計者が、あるいはシステム仕様書が〇 〇〇有用な情報を提供することが必要です。

アプリ

１．個人データの保存場所と流れを認識〇

SDLC フェーズ

バックドアは、アプリケーションからアクセス制
御を介さず個人データにアクセスする代替手段です。組織は、試験や一時的な目的でバックドアをつくることがあります。ただ残念なことに、バックドアを消し忘れたときは、ハッカーにとってはとても嬉しいニュースになります。ハッカーでなくとも、検索エンジンが見つけたバックドアからサーバーに入り、結果としてインターネットユーザが簡単に個人データにアクセスできるようになってしまいます。

要 設 開 試 移 保 表
件 計 発 験 行 守 現

〇

〇 〇

アプリ

３．アクセス制御をバイパスするバックドアの
作成を回避

３階層

データ

グッドプラクティス〇

４．ICT システムの他の部分でもアクセス制
御を設定
アプリケーション以外に、ウェブサーバやデータベースやファイルシステム、および ICT
システムの他の部分でも、適切なアクセス制
御を実装することが必要です。
例えば、構成の設定にもよりますが、ウェブサ
ーバのファイルは、ファイルへのリンクが公開されていなくとも、そしてウェブサイトやウェブ
アプリケーションがリンクしていなくとも、インタ
ーネットから（誰でも）アクセスできるようになるかもしれません。ロボットを排除するプロトコ
ル（robots.txt）を使用していても、検索エンジンによってそのようなウェブページや文書が見つからないとは保証できません。

〇〇

５．ログイン失敗回数を制限
これはブルートフォース攻撃（総当たり攻撃）に対抗する手段です。以下のようなさまざまな仕組みを実装することができます。
・X 回ログイン間違いするとアカウントをロック〇 〇 〇・再ログインするまでの時間を長く・ブルートフォース攻撃防止のためにキャプ
チャ（訳注：Captcha は Completely
Automated Public Turing test to tellComputers and Humans Apart）を使用
22

〇 〇 〇

SDLC フェーズ

要 設 開 試 移 保 表
件 計 発 験 行 守 現

これはブルートフォース攻撃や他のハッキングに対抗する手段です。特に、管理者アカウ
ントの保護やログイン後にアクセスできる個人〇 〇 〇データの機密性が高いと考えられる場合に
有効です。

アプリ

６．ワンタイムパスワード（OPT）あるいは多要素認証を使用

３階層

データ

グッドプラクティス〇 〇 〇７．パスワードの複雑さの規則使用されるパスワードが業界推奨の複雑さの規則に準拠することを確認してください。例えば、パスワードの長さが８文字で、少なくとも１
文字は大文字、１文字は数字、１文字は記号 〇 〇 〇にするなど。

〇 〇 〇また、以前使っていたｘ個のパスワードの再利用を禁止することも検討してください。
８．パスワードの保護
送信中（HTTPS のように暗号通信の使用により）や蓄積中（ハッシュ値のみでの記憶形
態により）は、パスワードを保護してください。
定期的に暗号化の方法（アルゴリズムや鍵の長さなど）を見直し、適切で安全であることを業界に認識してもらうようにします。

〇 〇 〇〇 〇 〇 〇

〇 〇 〇〇画面でのパスワード表示は、アステリスクやドットのようなプレイスホルダー記号を見せるよ
うにしてください。いくつかのアプリケーション
では、パスワード入力が安全に行われる（自分の他に画面を見る人がいない）ときに、パスワードそのものを見せるオプション機能を提供しています。
９．定期的なパスワードの変更
パスワード変更の頻度を決める際には、個人
データの機密性を考慮してください。また、ユーザに高頻度でパスワード変更を要求すると、「パスワード疲れ」になることもありますので注意してください。

23〇

SDLC フェーズ

要 設 開 試 移 保 表
件 計 発 験 行 守 現

アプリ

１０．ユーザの役割あるいはユーザのグループを決めて適切なアクセス権限を付与

３階層「最小権限（least privilege）」原則を使用し、できるだけ少ないアクセス権限を付与するよ
うに、ユーザに適切な役割を割り当ててくだ
さい。ガイドラインとしては、ユーザは知る必
要性のない情報を見ることができないように設定する必要があります。例えば、・人事（HR）部のユーザは、従業員の記録のみを閲覧できるが、顧客の記録を見ることが
できない。

〇 〇 〇

〇

〇

〇 〇 〇

〇

〇

・人事部内では上級ユーザのみが従業員の機微情報を閲覧することができる。
これらはきめ細かな個人データへのアクセス制御の例です。
１１．ログインの成功と失敗の履歴を記録
ログイン失敗の記録はハッキング未遂の検出や調査に役立ちます。ハッキング検出には何らかの形でのログ監視が必要になります。
１２．ユーザアカウントを定期的に見直し
すべてのユーザアカウントが正規のアカウン
トであることを保証することです。例えば、あるユーザが組織をやめると、そのユーザアカ
ウントを更新あるいは削除する処理が必要になります。テストが終了したら、テストアカウン
トを削除することが必要です。

〇

それとは別に、ユーザアカウントを定期的に見直すことも重要です。見直しでは、ユーザに付与された権限がほんとうにすべて必要なのか否かを確認することも重要です。
１３．機微データへのアクセスを記録
組織では個人データへのアクセス記録、特に機密度の高いデータへのアクセスを記録することを検討してください。

24

〇 〇 〇

〇 〇 〇

データ

グッドプラクティス

２．９ ICT システムの試験
アプリケーションが機能面で期待通りに動作することを確認するとともに、適切なリソースを考慮して、関連するセキュリティ試験を実施し、データ保護対策が意図したように動作していることを保証することが重要です。

SDLC フェーズ

要 設 開 試 移 保 表

開発者は利便性のあることから、本番データ 件 計 発 験 行 守 現（よく個人データが含まれている）を使って試験を行う可能性があります。しかし、試験環境
は本番に比べて安全性が低くなることが多く、個人データをリスクにさらすことになります。
組織は本番データの代わりに試験用のデー
タを新たに作ることを検討してください。

〇 〇

〇

〇 〇 〇

〇

アプリ

１．試験環境では本番データの使用を回避

３階層

データ

グッドプラクティス〇

詳しくは、PDPC の基本データ匿名化技法のガイド（Guide to Basic Data Anonymisation
Techniques）を参照してください。
２．SQL join を確認
長いステイトメントの SQL もあり、複雑な join
命令で構成されています。Join 命令に関するエラーは不明確なことがあり、結合される異なるデータサブジェクトに起因する可能性もあります。これによりデータ漏えいになりかねません。

〇

３．コードを見直し
大きな影響があると評価されたセクションのソースコードは少なくともコードの見直しが必要です。もし、手作業で行うのであれば、経験豊かな開発者に見直しをしてもらうのが賢明
です。

25

〇 〇

〇 〇 〇 〇

グッドプラクティス

SDLC フェーズ

３階層

要 設 開 試 移 保 表
件 計 発 験 行 守 現

データ

脆弱性が既知であり、新たなパッチを適用していないコンポーネントなど、何らかの脆弱性をシステムが含んでいるか否かを確認してください。これは通常、ソフトウェアツールを用いて行います。

アプリ

４．脆弱性を評価〇 〇 〇 〇 〇 〇５．侵入試験を実施
侵入試験には特別な技能が必要ですが、組織は必要なら外部の関係者に支援してもらうことができます。この目的は ICT システムにどのように侵入するかを見極め、システムの脆弱性を見つけて修正することです。

〇〇 〇 〇 〇

６．ユーザ受容試験（UAT）を実施
システムの機能性を検証するとともに、システムが提示するデータ保護対策の使いやすさ、データ保護指針や実践の分かりやすさを検証するために、UAT を実施することも必要です。

26〇 〇 〇 〇 〇 〇２．１０ ICT システムにおける個人データのアクセス、訂正、正確さ
個人情報保護法（PDPA；Personal Data Protection Act）との整合性とともに、アクセスや修正に関する組織の義務についても、ICT システムを役立てることができます。

グッドプラクティス

SDLC フェーズ

３階層

例えば、これはポータル（訳注：サイトの入口）で実行することもできます。なお、ユーザが自分の個人データにアクセスする前、ポー
タルでユーザにログインしてもらうことが重要
です。

〇 〇 〇

〇 〇 〇

〇 〇 〇

〇 〇 〇

２．ユーザによる更新の確認
次のステップはユーザが自己管理機能を確実に使うようにしてもらうことです。これにはいろいろな方法があります。例えば、定期的にユーザに使ってもらうように仕向けたり、詳細な情報を見せて正しいことを確認してもらったりします。

27

データ

要 設 開 試 移 保 表

可能であれば、従業員が援助せずにユーザ 件 計 発 験 行 守 現が個人データを管理できるようにしてください。これによりヒューマンエラーの発生が最小限になるとともに、従業員の手間と時間を節約できます。

アプリ

１．ユーザに自己管理機能を提供

２．１１ ICT システムにおける個人データの管理組織は主に個人データのメイン記憶（例えば、そのデータベース）の保護に力を入れるのですが、一時的なあるいは１回だけ使われる個人データの 2 次記憶媒体の保護を省略してしまうこともあります。そのため、システムの管理（ハウスキープ）は特に 2 次記憶に関連しています。

グッドプラクティス

SDLC フェーズ

データ

一時ファイルが生成されることがあります。例
えば、他システムとやりとりするための中間ファイルなどです。この一時ファイルが存在している間はそのファイルを保護し、不要になったら削除するようにしてください。ハウスキー
プが自動的に削除を行うようにスケジュール
しておいてください。

要 設 開 試 移 保 表
件 計 発 験 行 守 現

アプリ

１．個人データを含む一時ファイルが恒久的になることを防止

３階層

〇 〇

〇 〇

〇 〇

〇 〇

〇 〇

〇

２．データの移行ファイルに注意
移行ファイルは個人データがより脆弱な形式になるために特に注意が必要です。例えば、（通常は）セキュリティ層で保護されているデータベースのファイル形式の代わりに、CSV
形式のファイルを用いるときなどです。また、移行期間が長引き、結果として長期間にわたって脆弱性が生じるというリスクもあります。移行が終わったら移行ファイルの存在を忘れてしまい、恒久的な脆弱性につながってしまいます。

28

２．１２ ユーザデバイスのセキュリティ
従業員が使うコンピュータデバイスのセキュリティはますます重要になってきました。というのはラップトップやタブレットのようにコンピュータデバイスをどこにでも持ち歩くのが一般的になってきたからです。（従業員がどこにでも持参する）組織のコ
ンピュータデバイスは、組織の ICT システムやそこに入っている個人データへの入口になってしまいます。
詳しくは、PDPC の「電子メディアのための個人データの保護に関するガイドライン（Guide to Securing Personal Data in the Electronic Medium）」の中の「ポータブル
コンピュータデバイスとリムーバブルな記憶メディア（Portable Computing Devices& Removable Storage Media）」の節を参照してください。

グッドプラクティス

SDLC フェーズ

３階層

・デバイス使用を管理する方針を策定
・モバイルデバイスマネジメントを採用（例えば、遠隔データ消去）
・デバイス上のデータを暗号化
・データのセキュアな消去を実施〇 〇 〇・マルウェア対策のソフトウェアを使用
・デバイス上の個人データ保存を最小化
・強制的なデバイスへのログインを実施
・不使用中にスクリーンロックを使用

29

データ

要 設 開 試 移 保 表

検討にあたいするグッドプラクティスは以下の 件 計 発 験 行 守 現
通りです。

アプリ

１．従業員のコンピュータデバイスを保護

２．１３ データのエクスポート
データを単独のファイル（例えば、PDF フォーマットの報告書）に移行したり、他のICT システムにデータを転送したりするデータのエクスポートがよくあります。デー
タが一度エクスポートされると「オフライン」の状態になってしまい、もともとのアプリ
ケーションに具備したアクセス制御ではデータの保護ができなくなります。そのためエクスポートされた形態でもデータを保護する必要があります。

SDLC フェーズ

さまざまな暗号のアルゴリズムを使うことができます。暗号化の強さはアルゴリズムや暗号鍵の長さによって異なります。

要 設 開 試 移 保 表
件 計 発 験 行 守 現

大事なことは、暗号鍵の安全を確保し暗号化したデータとは別にするなど、暗号鍵を適切に管理し保護することです。
〇 〇 〇

アプリ

１．エクスポートするデータを暗号化

３階層

〇

〇

〇 〇

〇

暗号化の方法（アルゴリズムや暗号鍵の長さ）を定期的に見直し、それが適切で安全であることを業界に認識してもらうようにします。
２．暗号鍵とは別に送信
エクスポートしたファイルを受け取った相手にその暗号鍵を送る必要があるときは、ファイルとは別に鍵を送信してください。例えば、もし電子メールで暗号化したファイルを送るときは、暗号鍵はファイル送信とは別のメールで送るようにしてください。あるいは、もっと良い
方法は別の通信方法を使うことです。

30

〇 〇 〇

データ

グッドプラクティス

SDLC フェーズ

オリジナルのデータの代わりに、匿名化したデータを送ることで十分な場合もあります。匿
名化の技法には、文字のマスキング、仮名化、一般化、データの集約などがあります。
例えば、ある組織では、GIRO（訳注：シンガ
ポールのインターネット送金のひとつ）控除に使うために、月次計算書で部分的にマスクした口座番号をリスト化します。

要 設 開 試 移 保 表
件 計 発 験 行 守 現

アプリ

３．匿名化の技法を適用

３階層

〇 〇 〇

〇 〇 〇

〇 〇 〇

〇 〇 〇

詳しくは、PDPC の基本データ匿名化技法（Guide to Basic Data Anonymisation
Techniques）を参照してください。
４．新たなプライバシー保護技術を活用
個人データの共有や活用を行うとともに、保護も行う新しい技術が登場している。例えば、差分プライバシー（differential privacy）、
準同型暗号（Homomorphic Encryption）、秘密計算（secure multi-party computation）な
どがあります。ただ、このガイドを発行した時
点では、いくつかの技術だけがソフトウェア製品の形として使われ始めた段階です。

31

データ

グッドプラクティス

SDLC フェーズ

個人データを含む電子メールを送るアプリケーションを使う前には、組織は徹底した試験を行う必要があります。というのも、自動送信
では瞬く間に大量の電子メールが送られてしまい、個人データが間違った相手の送られたことを気が付いても、メールの送信を止めた
り、送られたメールを回収したりすることが困難だからです。
同じメールを複数の相手に送るとき、特に何か機密性のある場合は、相手先を BCC にして送るようにしてください。

要 設 開 試 移 保 表
件 計 発 験 行 守 現〇 〇 〇 〇〇

アプリ

５．電子メールの送付

３階層

データ

グッドプラクティス〇

電子メールで直接個人データを送る代わりに、ユーザが情報を見る際に認証を必要とするリンク先を送ることもできます。
６．データのエクスポートを監視
データのエクスポートが可能な限度を設定することを検討してください。またデータの不正流出を摘発するためにデータのエクスポートを監視してください。

32

〇

〇

２．１４ ICT システムにおける個人データの保存
電子的なデータ形式では、ICT システムを使うことで保存期間が終了になった個人データの検出をより容易に組織で実現できるようになります。これを実現するには、最初からシステムの設計要素に組み込んで込んでおくことが必須になります。

グッドプラクティス

SDLC フェーズ

３階層

33

要 設 開 試 移 保 表
件 計 発 験 行 守 現

〇 〇 〇

データ

ICT システムにより保存期間の終了したレコードにフラグを立てることができます。これらのレコードを削除する、もしくは組織のポリシーにしたがって処理（例えば、匿名化）することが必要です。

アプリ

１．期限切れの個人データを適切に管理〇 〇 〇 〇

２．１５ 保守フェーズ
ICT システムが稼働し安定した後、技術チームは人員やその他のリソースに関して縮小されるのが一般的です。しかし、個人データ保護については十分なリソースを確保することが大切です。このフェーズにおけるシステムの機能強化は、「ミニ SDLC」としてとらえることができます。つまり、保守フェーズでの機能強化は保守よりも前のフェーズで実施されてきたことを見直すことなのです。

グッドプラクティス

SDLC フェーズ

３階層

要 設 開 試 移 保 表
件 計 発 験 行 守 現

データ

法律は時とともに変わります。そのため個人
データに関する要求や義務も変わります。

アプリ

１．新しい法律あるいは法律改正に注意〇 〇 〇 〇
２．技術の変化に注意
同様に、技術の変化によってシステムの設計や実装で調整が必要になる可能性があります。例えば、現在安全な暗号化の標準でも、将来ずっと安全でグッドプラクティスであるとは限りません。

〇 〇 〇 〇

３．データ目録の更新システムに変更が生じたときに、個人データの目録を更新してください。

〇 〇 〇 〇

４．定期的にセキュリティ試験を継続
システムが動いている限り、セキュリティ試験に終わりはありません。たとえシステムに変更が生じなくとも、新たな脆弱性が出現することがあります。システム構成の変化も、結果として脆弱性を生むことになります。

34〇 〇 〇 〇

謝 辞
本ガイドの作成に関して貴重なご意見を頂いた以下の組織に感謝の意を表します。
AsiaDPO
Cyber Security Agency of Singapore (CSA)
Government Technology Agency (GovTech)
The Law Society of Singapore
SGTechSingapore Computer Society (SCS)The Software Alliance (BSA)35

本ガイドラインは以下の組織により作成された。
Personal Data Protection Commission (PDPC), Singapore
Privacy Commissioner for Personal Data (PCPD), Hong Kong
Copyright 2019- Personal Data Protection Commission, Singapore (PDPC) andPrivacy Commissioner for Personal Data, Hong Kong (PCPD)

本出版物は、ソフトウェア開発のさまざまなフェーズにおいて個人データを保護するためのグッドプラクティスを一般的に紹介しています。ここに記載されている内容は、法律の正式な陳述もしくは法律その他の専門家による見解の代替を意図しているものではありません。PDPC、PCPD およびそれらのメンバー、役員、職員は、この出版物のあらゆる不正確さ、誤り、漏れについて責任を負わず、また本出版物の使用あるは信頼の結果として生じるあらゆる損
害についても責任を負いません。
本出版物の内容は著作権、商標、あるいはその他の所有権による保護されており、書面による許可なしには、その全部または一部をいかなる形式あるいは手段であれ複製、再発行、転載することは禁じられています。

36