View on GitHub

bok

IDPro Body of Knowledgeの日本語訳を載せていきます

GDPRがアイデンティティとアクセス管理に与える影響

アンドリュー・ヒンドル（CIPP/E、CIPM、CIPT

© 2020 アンドリュー・ヒンドルとIDPro

読者への一言

私たちは、少なくともデータ保護とプライバシーに関する基本的な知識、特に GDPR 1 と OECD のプライバシーガイドライン 2 に概説されている基本的な原則を前提としています。あなたが組織のセキュリティ担当者やプライバシー担当者でなくても、規則を理解することで、プライバシー担当者とより良い会話をすることができるようになります。

プライバシー規制の状況は急速に進化しています。したがって、ここで与えられたアドバイスは包括的なものではなく、法的なアドバイスの代わりとなることを意図したものでもなければ、考慮されるべきものでもありません。プライバシーの考慮事項に対する十分な認識と感受性はデジタル ID 専門家にとって重要であるが、専門家の大多数はプライバシーの弁護士ではなさそうである。規制のどの分野でもそうであるように、不明な点があれば専門家の助言を求めることが常に最善である。

この記事全体を通して、特定の「優れた技術的実践」のアドバイスには下線が引かれている。この同じ アドバイスは、優れた IAM の実践のためのチェックリストとして、記事の最後に別のセクションにまとめられている。

序章

プライバシーに関する条約、規制、法律は、ほとんどの人が認識しているよりもはるかに長い間存在しています3。3 1948年の国連総会では、世界人権宣言の第12条にプライバシーの権利が明記されています4。4 1980 年、OECD は「個人情報の保護と国境を越えた個人データの流れに関するガイドライン」5 を発表したが、2013 年に大幅に改訂され、更新された(v.q.v.)。

個々の国や広範な貿易圏は、技術の進化を考慮して、データ保護とプライバシーに関する規制を進化させ続けている。規制の枠組みが技術の発展に遅れをとることは珍しくありませんが、インターネット、コネクティッドデバイス、人工知能、ゲノミクスがもたらす影響を考慮して、今後も変更が加えられるでしょう。さらに複雑さを増しているのは、個人のグローバルな移動性が高まっていることで、データ保護とプライバシー規制のローカルな変更が他の法域での変更に影響を与えていることを示唆していることです。ヨーロッパでの変化はさておき、近年ではブラジル、シンガポール、フィリピン、中国、米国の一部などでプライバシー規制が更新されています。

このような規制の進化は重要です。刻々と変化し、進化する規制の状況というレンズを通して見ると、GDPR（およびその他の最新のプライバシー規制）は、単にチェックボックスにチェックを入れるだけのものではなく、より良いシステムを構築するのに役立つツールのセットであると見ることができます。

たとえあなたがヨーロッパと直接取引をしていない組織で働いていたとしても、GDPR の一部の要素は世界的に影響を与えます。他のプライバシー規制にも同様の条項が含まれている場合がありますが、これらの規制を世界的に調和させるために計画を立てるのは賢明ではありませんが、地域間での共通点は増えています。また、GDPR は、企業内の従業員に関するデータであっても、顧客などの外部の個人に関するデータであっても、個人に関するあらゆるデータに等しく適用されるということも認識しておきましょう。言い換えれば、GDPRはすべての人に影響を与えるということです。

この規則には、6.デザインによるデータ保護の要件が含まれています。規制に準拠する必要性はさておき、これらは基本的に優れた設計原則です。ビジネスリスクを軽減し（例：データが少なければ少ないほど攻撃の対象となりにくく、攻撃の影響を受けにくくなります）、管理上のオーバーヘッドと無駄な労力を軽減します（例：データが少なければ少ないほど、重複や矛盾した記録を持つ可能性が低くなります）。

定義上、GDPRは個人データに関係しているため、これらの原則は、IAMシステムやプロセスを含め、そのようなデータを使用するシステムをどのように設計し、実装するかに重要な意味を持ちます。実際、規則に準拠したIAM基盤がなければ、最終製品が規則に準拠することは不可能です。(ただし、IAMシステムやプロセス自体が規制に対応していたとしても、最終的なサービスが規制に準拠していることを確認する必要があることに注意してください。)

この記事の残りの部分では、規制のニーズに準拠できるIAMプロジェクトを開発する際にチームが考慮すべき主な事項を探っていきます。

同規則は、デジタルデータと同様に、データの物理的表現（紙など）にも適用されます。ここではデジタル情報に焦点を当てますが、具体的な意味合い（例えば、デバッグや管理報告などの分野）については、適宜参照していきます。

まず、プロジェクト・チームの構成やプロジェクトの構造についての解説を含めて、一般的な見解を述べます。次に、個人データを含むデータがライフサイクルの中で通過する4つの段階（作成、読み込み、更新、削除）に焦点を当てます。これらの各段階について、GDPR が適用される具体的な分野をいくつか参照し、それに役立つアーキテクチャ、ツール、テクニックを特定していきます。また、お客様が「データ管理者」や「データ処理者」である場合に適用される可能性のある違いについても言及しますが、ほとんどの場合、これらの違いの影響は技術的なレベルではなく、ビジネスや法的なレベルである可能性が高いと考えられます。最後に、今後のプロジェクトやチームの導入のための簡単なメモとしても使えるように、重要なポイントをまとめておきます。

用語の説明

データマッピング - “どのようなデータを収集し、どのように使用し、どこに保存し、どのように組織全体とその先に移動するかをカタログ化するシステム” 7

データ保護責任者（DPO） - GDPR によって機密性が高いと定義されたデータを処理する組織で任命されなければならない個人。8 DPO は、「関連するすべてのデータ保護法の遵守に向けた作業、データ保護の影響評価などの特定のプロセスの監視、データ保護に対する従業員の意識の向上とそれに応じたトレーニング、監督当局との協力」に責任を負います。

個人データ - 個人データとは、特定または識別可能な自然人に関連する情報を指します。9 (詳細はGDPR第4条(1)を参照)。

デザインによるデータ保護 - 適切な技術と組織的措置によるデータ保護。10 詳細はGDPR第25条を参照。

一般的な注意事項

個人情報保護アドバイザーとの連携

GDPRの第25条で定義されている「デザインとデフォルトによるデータ保護」の原則を念頭に置いた上で、おそらく最も重要な行動は、プロジェクトの開始時にプライバシーの要件が考慮されているかどうかを確認することです。

GDPRでは、多くの（すべてではありませんが）組織にデータ保護責任者（「DPO」）を任命することが義務付けられています。大規模な組織では、プライバシーアドバイザーのチームを設置する場合もあります。もしあなたが個人に関するデータを扱うプロジェクトを指揮しているのであれば、個人情報保護担当者が関与していることを確認するのはあなたの責任です。プロジェクトの早い段階で、関係者をプロジェクトに参加させるようにしてください。あなたがそれらを言わない限り、彼らはあなたのプロジェクトについて知らないかもしれないことを覚えておいてください! たとえそうでなくても、プライバシーの観点から誰が関与しているのかを尋ねることを恐れずに、アドバイザーと協力関係を築きましょう。

個人情報保護の専門家（経験豊富なDPOがいない場合）は、深い技術的背景を持っていないかもしれませんので、完全かつ包括的なアドバイスができるように、必要な情報を彼らにとって納得のいく形で提供する必要があります。会話をより生産的で効率的なものにするために、個人情報保護に関する専門的な知識を深めたり、個人情報保護関連の業界団体や他の機関からの資格や証明書を調査したりすることを検討してみてはいかがでしょうか。

懸念事項の提起/内部告発

もしあなたのプロジェクトや組織がプライバシーに十分に真剣に取り組んでいないことを心配している場合、あるいはGDPRのコンプライアンスから外れた問題を発見したと考えている場合、あるいは最悪の場合には実際のデータ侵害が発生していると考えている場合には、そのような問題を報告するための適切な手段を知っていることを確認しておきましょう。大規模な組織では、報告/エスカレーションの仕組みが確立されているはずですし、最後の手段として内部告発の方針やプロセスを持っている可能性が高いでしょう。小規模な組織ではそうでない場合もありますので、専門家としての最善の判断で、最も効果的に懸念事項を提起する方法を検討する必要があります。このような会話の記録はしっかりと取っておくようにしてください。しかし、問題を報告する際には、個人データの具体的な例を含めないようにしてください。

最後に、組織に DPO がある場合、GDPR は DPO の独立した関係と報告ラインに非常に厳しい要件を課していることを覚えておいてください。これらの情報は、エスカレートする必要があると判断した場合に、安心感を与えてくれるでしょう。

個人データの定義とマッピング

GDPR は、何が個人データとみなされるかについて非常に広範な定義を持っています。”識別可能な自然人とは、特に名前、識別番号、位置情報、オンライン識別子などの識別子、またはその自然人の身体的、生理学的、遺伝的、精神的、経済的、文化的、社会的アイデンティティに固有の1つ以上の要素を参照することによって、直接的または間接的に識別可能な人のことを指します。12

そのためには、同じように幅広いアプローチをとることが重要です。どのようなデータが個人データの範疇に入るのか、プロジェクト全体で十分に理解しておく必要があります。集計されたデータや擬似的なデータを扱っている場合でも、そのデータが「再識別」できる場合には規制が適用されることを覚えておいてください。

プロジェクトの開始時に「データマッピング」と呼ばれるプロセスを検討し、どのような個人データがどこでどのように使用される可能性があるかを発見してマップ化し、プロジェクトのライフサイクル全体を通してこのデータマップを監視して更新することを検討してください。データマッピングとは、「どのようなデータを収集し、それがどのように使用され、どこに保存され、それが組織全体やその先にどのように移動するかをカタログ化するシステム」である13。13 このようなプロセスは、データ保護の影響評価（「DPIA」）の一部であることが多いですが、IAM アーキテクチャの全体的な設計にも役立つので、決して無駄な努力をすることはありません。

個別のトラッキング技術

クッキーを含むがこれに限定されない個々のトラッキング技術の使用は、サービスやウェブサイトにその使用が含まれているかどうかを検討するために、GDPRだけでなく（執筆時点では）必要とされています。14 EUの各加盟国は、この指令に沿った独自のガイダンスを発行する責任があり、この分野ではいくつかの重要な相違が生じています。

しかし、クッキーの中には、例えば（他のデータと組み合わせて）個人を特定するために使用される可能性のある情報が含まれている場合、GDPRに該当するものもあります。したがって、IAMの実務者にとっては中心的な考慮事項ではないかもしれませんが、この分野の潜在的な問題を認識し、注意を払う価値はあります。

特別な状況

この記事に記載されている指針は、すべてのIAMプロジェクトに一般的に適用されることを意図している。しかし、プロジェクトの中には、追加の注意と考慮に値する特定の状況がある。このような状況には、子ども、法執行機関、特定の特別なカテゴリーのデータなどが含まれる。いずれの場合も、実務家は独立した法的ガイダンスを求めるべきです。

特別なカテゴリーのデータおよびその他の機密性の高いデータ

GDPR は、人種、性的指向、政治的・宗教的所属、健康関連データ、バイオメトリクスデータを含む（ただしこれに限定されない）、特定のよりセンシティブなタイプのデータについて特別な規定を設けています。これらの分野で特別なカテゴリーのデータを取り扱う場合は、追加の保護措置が必要です。

子供

あなたのプロジェクトに子供に関するデータが含まれている場合は、特別な注意が必要です。GDPRでは、児童を16歳未満と定義していますが、各国によっては（英国を含む一部の国では）この制限を13歳または16歳未満に引き下げている場合があることに注意してください。

法の執行と個人データ

法執行機関による個人データの使用は、個別の指令、規制、法律の対象となります。

自動処理、機械学習、人工知能

個人データの自動処理は、それ自体が特殊な状況ですが、特別な注意を払う必要があります。自動処理には、機械学習（「ML」）、アルゴリズム処理、ブロックチェーン技術の使用、人工知能（「AI」）など、あらゆるものが含まれます。特にAI/MLは、動きの速い分野であり、世界中の開発者、倫理家、法律家、規制当局が、何が可能になるかの完全な範囲を把握しようとしています。AI/MLシステムが、元のデータセットに含まれていない個人に関する「事実」を推論したり、推理したりすることができることはすでに明らかである（これはユーザープロファイリングでよく見られる）。また、元のデータセットはそれ自体が（定義上）個人データを含んでいないかもしれないが、一度処理されるとそうなる可能性があることも明らかである。

しかし、GDPRは自動意思決定とプロファイリングの場合、非常に厳しい要件を課しています。17

グリーンフィールド/ブラウンフィールド 18

GDPR自体は、グリーンフィールドアプリケーションと既存の「ブラウンフィールド」アプリケーションのリファクタリングを区別していません。実用的な観点から見ると、前者の方が最新の標準や技術を使用するための道筋が容易で、レガシーな統合/サポート要件に縛られることも少なくなります。

しかし、GDPR に準拠することで、プロジェクトの作業環境にあるすべてのアプリケーションを見直さなければならなくなる可能性があることを認識しておいてください。場合によっては、コンプライアンスを達成するための単純な技術的または手続き的な解決策が（多かれ少なかれ）存在します。しかし、他のケースでは、規制に照らし合わせて当初のビジネス目標を見直し、見直す必要があるかもしれません。

プロキシ/委任アクセス

この記事では、データ対象者が自分自身に関するデータを提供および／またはアクセスすることを一般的に想定しています。とはいえ、当然ながら、第三者のために正当にデータにアクセスしている人がいるかもしれな い様々なケースがある。

このような状況では、元のデータ対象者とその代理人の両方に対して、委任の同意とともに、認証、本人確認、および承認の適切な メカニズムを確立し、適用することが極めて重要である（この記事で後ほど様々な形で推奨される）。状況によっては、同意は委任状、裁判所の命令などの法的手段を介して得られる場合もある。これが自社のユースケースの要件であるかどうかを確認し、それに応じてプロセスを設計する。また、該当する場合には、委任の同意やその他の承認行為の記録を維持することを強く検討すべきである。UMA 19 や Consent Receipt 20 などの基準は、この点で役立つかもしれない。

バックアップ

災害時にデータを安全に保護するための信頼性の高いメカニズムを持つことは、一般的に良い習慣であるだけでなく、基本的にはGDPRで要求されています。しかし、不適切に設計されたバックアップメカニズムは、侵害のリスクを高める可能性があることを覚えておいてください。バックアップ内のデータは、強力な暗号化や、特権アクセスやユーザー管理などのツールで保護されていることを確認してください。セクターやアプリケーションによっては、物理的または紙ベースのバックアップメカニズムが必要な場合もあります。これはデジタル ID 専門家の直接的な責任範囲外である可能性が高いが、GDPR の要件は物理的な形式のデータにも等しく適用されることを心に留めておくこと。バックアップはまた、保持の分野でもさらに複雑さを増します。

データの旅

ステップ1 - 作成

データの旅の第一段階である「作成」は、個人データの収集に着手した瞬間から始まります。これをデータベース（またはその他のストレージメカニズム）にデータを書き込む瞬間と混同しないようにしてください。データ対象者に（またはデータ対象者について）データを要求する前に、データ対象者の権利の概要を説明するとともに、何を収集するのか、なぜ収集するのかを明確に理解し、相手に伝える必要があります。これらは、最も一般的には、明確で平易な言葉を使用した個人情報保護に関する通知を介して表現されます。

関連するデータを処理するための合法的な根拠によっては、データ対象者の情報を収集し処理するために、データ対象者の同意を得る必要がある場合があります。同意を得る方法は、どのようなデータが収集され、どのような目的で使用されるかによって、プロジェクトごとに異なります。個人情報保護アドバイザーがガイダンスを提供することができます。

監査の観点からは、同意の記録を残すこと、および／またはデータ対象者自身のために記録を提供することを検討してください。ただし、このような領収書や記録には、それ自体が個人データを含んでいる可能性があることを覚えておいてください。

最小限の作成

設計とデフォルトによるデータ保護がプロジェクトの最初の指針となった場合、2 番目の指針となるのがデータの最小化です。データの最小化は、コンプライアンスの要件に関係なく、良い実践となります。これはまた、GDPRが個人データの取り扱いについて定めた7つの原則の1つでもあります。21

最重要事項です。データ対象者からデータを収集する際には、要件を満たすために可能な限り少ないデータを収集し、保持してください。同様に、ブラウザの指紋など、データ対象者に関する間接的なデータについても、できる限り少ないデータを収集して保管してください。つまり、プロジェクトのビジネス上の理由を十分に理解して、その正当性を明確にし、ビジネス側の同僚が義務を 果たすことができるようにする必要があります。

GDPR はデータを総合的に見ていることを忘れないでください。あなたのプロジェクトが収集しているデータが、組織が保有する他のデータと結合して、個人を特定できる可能性があるかどうかを検討してください（下記の「読み取り」も参照してください）。組織が既に保有している個人に関するデータを繰り返し収集することは避けてください。利用者にとってイライラするだけでなく、記録の重複や矛盾が生じ、データの正確性、対象者へのアクセス要求、削除などの問題を引き起こす可能性があります。大規模でばらばらなデータマップがある場合は、データディスカバリーやメタディレクトリツールの使用を検討し、可視化と統合を支援してください。

暗黙のデータや推測されるデータを収集している可能性がありますが、これも個人データとみなされる可能性があることに注意してください。例えば、IP アドレスやシステム分析などです。これらのデータは、データ対象者から、またはデータ対象者に代わって明示的に要求したデータと同様の注意を払って取り扱う必要があります。これらのデータが一過性のものとして収集・使用されている場合でも、正しく取り扱う必要があります。

収集するデータの量を制限するための創造的な方法も検討してください。単に収集量を減らすだけでなく、「データ対象者は 18 歳以上ですか」などの質問への回答に属性サービスを使用して、対象者の生年月日を収集して保存したり、クレジットカード情報の開示を要求したりする代わりに、組織はデータ対象者の生年月日を収集して保存したり、クレジットカード情報の開示を要求したりすることもできます。情報そのものを明らかにすることなく、当局が特定の情報を知っているという証拠を提供できる技術、例えばゼロ知識証明 23 も調査の価値がある。しかし、既存の法的要件はそのような技術をまだ考慮に入れていないかもしれないことに注意すること。

前述したように、この記事では主に GDPR のデジタル ID への影響を考慮している。しかし、データの収集／作成の瞬間には、紙ベースのプロセスが発生することがよくあります。これらが直接の関心事ではないとしても、紙の記録がどのように処理されているかを理解しておくことは悪いことではありません。

フェデレーションの可能性

基本的なことを扱った後は、重要な質問をする必要があります。長年の経験から生まれた傾向として、どのようなアイデンティティ・プロジェクトでも、これを最初の呼び水にしようとする傾向があります。しかし、多くの場合、これは不要なものであったり、カスタマージャーニーの後半になってから必要になるものであったりします。SAML や OpenID Connect のような確立された標準は、一時的な ID 連帯をサポートしており、これが必要なすべてであることが多い。このような場合、個人データを扱うのは（全くない場合は）短期間だけなので、通常のデータ最小化の原則と輸送中のデータに対する注意事項で十分かもしれません。( 最新バージョンのTLSを使用し、必要に応じてデータの暗号化を追加してください)

技術的な理由でユーザアカウントが必要な場合、例えばセッションデータの永続化などの理由でユーザアカウントが必要な場合、(例えば)仮名のフェデレーションを使用して本質的に「非個人的」なものにすることはできますか? 疑似匿名化では、既知の個人と容易に関連付けることができない識別子を使用して、ユーザの身元を照合することができます。ただし、この場合は注意が必要です。情報を再識別するような方法でデータを結合することが可能な場合があり、仮名化の目的を打ち破ることになります。仮名データは依然として個人データとみなされるため、GDPRの要件に照らし合わせて検討する必要があります。

データの保存

仮名であろうとなかろうと、データを永続化する必要があることがわかった場合、データをどこにどのように保存するかを考える必要があります。休止中のデータに対する通常の保護が重要です。暗号化技術は急速に発展している分野です（特に量子暗号の出現や「量子安全」なアルゴリズムや技術の進化を考えると）。また、サポートするシステム、アプリケーション、ライブラリを最新の状態に保ち、パッチを当てるための適切なプロセスを確保する必要があります。

GDPR のその他の要件はともかく、最新のアプリケーション設計パターンでは、ほぼ確実に個人データを扱うための API を提供することになるでしょう。このような場合、そのような API へのアクセスは、理想的には OAuth のようなプロトコルを使用して保護されなければなりません。API の保護については、データの旅の後半で再度説明します。

分散型台帳を使用したストレージソリューションを検討している場合は、特に注意が必要です。このような台帳に個人データを直接保存することは良い習慣ではないという明確なコンセンサスがあります。現在開発中のソリューションの中には、この特定の落とし穴を回避しているものもありますが、特に独自に構築している場合は、まだ心に留めておく価値があります。この分野の技術がより安定するまでは、慎重に進めることが最善のアドバイスです。このようなプロジェクトは、導入後も定期的に定期的に見直しを行い、必要に応じて台帳ベースのソリューションを使用していない状態に戻す方法を十分に文書化し、簡単に実装できるようにすることです。

クラウドベースのデータストアやユーザーストアを使用することは、リスク管理とプライバシーの観点からメリットがある場合があります。個人情報保護に関する通知が、お客様とプロバイダーとの関係を正確に反映するように、お客様の個人情報保護チームと協力して作業することを確認してください。

データ保管場所

GDPR はデータの地域性の要件を課しているわけではありません。つまり、他の法域の規制ではデータを特定の地域に保存することを要求しているわけではありません。少なくとも、必要になった場合には、地域ごとにデータを分離できるような柔軟なアーキテクチャを開発する必要がありますが、これは必要ないかもしれない個人データを追加で収集することになりかねないことを念頭に置いてください。

とはいえ、GDPRにはEU域外へのデータ転送に関する要件があります。第三国への個人データの転送は、GDPRの観点からも常に重要な懸念事項であり、解決策を考案することは可能ですが、これは現在進行中の規制の発展の領域です。この問題が正しく処理されているかどうかを確認するためには、個人情報保護アドバイザーと慎重に話し合う必要があります。

ステップ2 - 読む

お客様が保有する個人データへのあらゆるアクセスは、安全に管理されていなければなりません。最も基本的なレベルでは、このようなアクセスを最小限に抑えることを意味します。まだそうしていない場合は、該当する場合は、特権アクセス/ユーザー管理ソリューションの導入を検討してください。また、データベースやシステム管理者を含む、権限のある特権ユーザーであっても、個人データに明確な形でアクセスできないようにしなければなりません。個人データへの不正アクセスは、潜在的なデータ侵害を構成することを忘れないでください。このような違反は、多かれ少なかれ深刻であり、その結果が大きかったり小さかったりしますが…それでも違反であることに変わりはありません。

潜在的なデータ侵害を回避しつつ、有用な機能を提供するためには、内部および外部のユーザーを認証し、承認するために、安全な最新の方法を使用するようにしてください。XACMLのような確立されたプロトコルや、ユーザ管理型アクセス（「UMA」）のような新しい規格、トランザクション認証のような新しいアプローチを含む、最新の認証規格（およびそれをサポートする製品）を検討してください。

認証」は必ずしも「検証」と同じではないことに注意してください。ユーザーの要求を安全に満たすためには、ユーザーの実際の物理的な身元をどのレベルの保証でも確立する必要はないかもしれません。ただし、実世界の ID に対するある程度のレベルの保証が必要な場合は、ユーザの ID を検証するために使用されるデータを適切なレベルのセキュリティで扱うことを忘れないでください。

クライアントから見えるフォームを事前に入力している場合は、そのようなデータが正しく承認されたユーザにのみ表示され、異なるユーザの訪問にまたがってキャッシュされないように特に注意してください。

最近のアプリケーションの設計パターンでは、「読み込み」操作のための API を持つことになるでしょう。前述したように、そのようなAPIは適切に保護されていなければなりません。プログラムやシステムレベルでの保護を追加することも検討してください。例えば、追加の認証を要求したり、総読み取り制限や繰り返し時間の制限を課すことで、複数の連続した読み取りから保護することができます。

個人データにアクセスできる可能性のある他のシステム、例えば、セキュリティアプリケーション（特にMLやAI駆動型ソリューション）やデータマイニングツールなどを意識してください。また、場合によっては、そのようなアクセスが自動化された意思決定やプロファイリング（前述のとおり）を構成する可能性があることに注意してください。

意図しない結果も考慮してください。(a) データのExcelスプレッドシートを生成して電子メールで送信できるレポートツールを使用している場合は、(a) すべてのPIIがそこに含まれている必要があるかどうか、(b) 事前に何らかの自動化された方法で保護を提供できるかどうか（例えば、暗号化されたシートを自動的に作成することで、ユーザー自身が暗号化されたシートを作成するように頼るのではなく）を検討して、さらに下のラインで偶発的な違反のリスクを減らすことができます。

データ主体へのアクセス要求とデータのポータビリティ

個人データの対象者は、GDPRに基づき、あなたが保有する個人データにアクセスする権利を有しています。24 これは明らかな侵害リスクを提示しています。データ対象者からのアクセス要求への応答を処理している場合、またはそのような場合に使用されるシステムを設計している場合は、ユーザーを正しく認証および／または確認していること、ユーザーが適切に権限を与えられていること、そして共有しているデータ自体が他のデータ対象者の個人データを含んでいないことを確認するために、特に注意しなければなりません。

また、GDPRの下では、データのポータビリティのために、データ対象者のすべての個人データを機械読み取り可能な形式で提供することが求められています。この場合も同様のセキュリティ上の考慮事項が適用されます。

少し変な言い方ですが、これらの要件の一部を満たすためには、必要以上に個人データを収集する必要があるかもしれません（または推論する必要があるかもしれません）。例えば、どのような法律が適用されるかを確認するために、特定のユーザーがどの国に住んでいるか、どの国に住んでいるか、どの国の国民であるかを確認する必要があるかもしれません。システム設計にもよりますが、この情報を保存しないようにして、決定が必要なときにリアルタイムで要求することもできます（必要に応じて検証もします）。

データ侵害報告

違反報告は、「読む」という文脈では特殊なケースです。違反や違反の可能性を報告する必要がある場合は、違反報告の一部として個人データを送信しないようにしなければなりません。自動化された違反やセキュリティ報告ツールを使用している場合は、これらのツールが誤って個人データを報告に含めることで違反を発生させたり、悪化させたりしないようにしなければなりません。また、データセットを安全に横断的に検索できるプライバシーソフトウェアソリューションの利用も検討してください。

ステップ3 - アップデート

GDPRは、データ対象者が自分について保持している個人データを簡単に修正できるようにすることを義務付けています。システムにそのような仕組みがあることを確認してください。ユーザーセルフサービスソリューションは、適切に見つけやすく、使いやすいものであれば、この点で特に役立ちます。繰り返しになりますが、適切な認証と、場合によっては検証が、偶発的な違反の可能性を軽減するために非常に重要です。

同規則の「更新」要件は、分散型台帳ベースのソリューションにも影響を及ぼす可能性があることに注目すべきである。特に、そのようなソリューションが台帳内（またはチェーン上）の履歴記録の修正を可能にするかどうかを確認すべきである。単に履歴レコードを「もうアクティブではない」とマークするだけでは十分ではないでしょう。

ステップ4 - 削除

場合によっては、GDPRはデータ対象者に、お客様が保有するデータの削除を要求する権利を与えています。これを行うための簡単な方法があることを確認する必要があります。また、このメカニズムが偶発的または意図的な誤用から保護されており、必要なレベルや認証・認可の方法などの適切な保護措置が講じられていることを確認する必要があります。このような取引の監査ログを管理し（実際の個人データをログ記録から除外することを念頭に置いてください）、エラーが発生した場合に時間制限のある「ロールバック」メカニズムを持つことを検討してください。

また、同規則はデータを実際に必要とされる期間だけ保存することも要求しています。保存期間の長さは、プライバシーのニーズに基づいたビジネス要件によって決定されますが、この期間の終了時にデータを簡単に消去できるようにシステムを設計する必要があります。問題のデータがいつ作成されたかを示す別の記録を維持し、自動タスクを実行して、保存期間に達したデータを報告するか（手動で削除するようにフラグを立てる）、または直接削除することを検討してください。

大規模な導入やブラウンフィールドでの導入では、特定のデータ対象について実際にどのようなデータを保持しているのかを確認するために、発見プロセスを実行する必要があるかもしれません。これを容易にする様々なソフトウェアソリューションが存在します。

更新」と同様に、データ削除を実行できるAPI（またはその他の機能）を持っている場合、特に一括削除を許可している場合は、誤用から保護していることを確認してください。例えば、一括削除の前に追加の(手動の)チェックを追加したり、一定のレコード数を超えるリクエストに対して追加の承認を要求したりします。また、定期的にデータをバックアップし、ミス(または故意にデータを破損させようとした場合)が発生した場合に復元する方法があることを確認し、削除処理が実行される前にAPIコードを介して強制的にバックアップを取ることを検討してください。このようなバックアップコピーの保持は制限されなければならないことを覚えておいてください。

まとめ

GDPRやその他の最新のデータ保護およびプライバシーに関する法律や規制は、IAMソリューションの設計、開発、維持に細心の注意を払わなければならないことを意味しています。具体的には

必要なデータのみを収集する

必要とされる限り、それを保管してください。

私たちの世話をしているときにそれを見てください。

アクセスできる人だけがアクセスできるようにしてください。

適切に更新できるようにする

時期が来たら安全に処分する

これを行うために必要なツールはすでに用意されていますが、それらのツールを適切な方法で適用し、ビジネスオーナーが行うべきではないことを私たちに求めていないことを確認するように注意する必要があります。

絶対に必要な場合のみアカウントを作成する。可能な場合は、フェデレーション（SAML、OpenID Connect）やその他の一時的な情報や識別できない情報を使用する（ユーザー情報、ゼロ知識証明）。

ユーザーを認証し、好ましくは強力な多要素認証（FIDO）でユーザーを認証する

最新のプロトコル（XACMLとUMA）を使用してユーザーを認可することが望ましい

API の保護 (OAuth)

私たちがやらなければならないことの多くは新しいものではありませんし、その多くは常に良い練習になっています。ただ、必ずしも標準的な実践ではなかったり、プロジェクトのリストのトップにすら入っていなかったりします。新しいプライバシー規制は、正しい方法で物事を行う機会を与えてくれます。

IAMプロジェクトのチェックリスト

プロジェクトの開始時からプライバシー要件が考慮され、アプリケーションの寿命を通じて定期的に再評価されるようにする。

関係者（IAM データを消費する組織の代表者、および IAM データの真実の情報源としての役割を果たす者、およびプライバシーの仲間）を、プロジェクトの最 早の段階で参加させる。

潜在的なデータ侵害に関する会話の記録をしっかりと取っておくが、問題を報告する際には、個人データの具体的な例を含めないようにする。

個人データが何に、どこで、どのように使用される可能性があるかをマップ化してください。

GDPRおよび/または地域や部門別のプライバシー規制で定義された特別なカテゴリーのデータを扱う場合は、追加の保護措置が必要になります。

プロジェクトに子供に関するデータが含まれている場合も、特別な注意が必要です。

あなたの組織やサービスのプライバシー通知が、システムが実際にどのように機能するかを正確に反映していることを確認してください。

データ対象者の情報を収集し、処理するために、データ対象者の同意を収集する。

その同意の記録を保管し、データ対象者自身のために記録を提供しましょう。

同意書の仕様や新たな実装を検討してください。

可能な限りデータを収集する（データの最小化）。

データの繰り返し収集を避ける。

データの可視化と統合を支援するために、データ発見ツールやメタディレクトリツールの使用を検討する。

ゼロ知識証明技術と実装を検討し、そのようなソリューションを導入の一部にすべきかどうかを調査する。

アカウントを作成する代わりに、一時的な ID フェデレーションおよび/またはシングルサインオンの使用を検討してください。アカウントの作成が避けられない場合は、仮名のフェデレーションやシングルサインオンの使用を検討して、保有する個人データの量を減らす。

最新バージョンの TLS に加えて、必要に応じて追加の特定データ暗号化を使用する。

適切な暗号化技術を使用し、定期的に見直しを行う。

サポートするシステム、アプリケーション、およびライブラリを最新の状態に保ち、パッチを適用する。

個人データを扱う API へのアクセスを保護し、理想的には OAuth などのプロトコルを使用する。

個人データを直接分散型台帳に保存することは、良い習慣ではありません。

地域ごとにデータを分離できるような柔軟なアーキテクチャを開発する。

個人データの第三国への転送（規制で定義されている）は、常に重要な懸念事項でなければなりません。

保有する個人データへのアクセス（物理的、デジタル的）は、安全に保たれなければなりません。

特権アクセス/ユーザー管理ソリューションの導入を検討してください。

データベースやシステム管理者を含む、権限のある特権ユーザーであっても、明確な形で個人データにアクセスできないようにします。

XACML のような確立されたプロトコル、UMA のような新しい規格、およびトランザクション認証のような新しいアプローチを含む最新の認証規格（およびそれをサポートする製品）を検討する。

個人データが正しく認証されたユーザーにのみ表示され、異なるユーザーの訪問にまたがってキャッシュされないように注意してください。

特に、ユーザーを正しく認証し、そのユーザーが適切に認証されていることを確認するように注意してください。

個人を特定できる情報を保存しないようにし、決定が必要な場合にはリアルタイムで要求するようにします（必要に応じて検証も行います）。

システムの違反を発見した場合は、違反報告の一部として個人データを送信しないようにします。

ユーザーの個人データの修正および/または削除をサポートするセルフサービスの仕組みがシステムにあることを確認してください。

このようなトランザクションの監査ログを維持することを検討してください（実際の個人データをログ記録から除外することを念頭に置いてください）。

問題のデータがいつ作成されたかを示す別の記録を維持し、保存期限に達したデータを報告するための自動タスクを実行する（したがって、手動で削除するためのフラグを立てる）か、またはプライバシーポリシーと通知に沿って直接削除することを検討してください。

一括削除を行う前に確認し、一定のレコード数を超えるリクエストに対しては追加の権限を要求します。

また、削除処理が実行される前にAPIコードを介して強制的にバックアップを取ることを検討してください。

  1. 概要については、IDPro Body of KnowledgeのGDPRの記事をお読みください。規制の全文は https://eur-lex.europa.eu/eli/reg/2016/679/oj でご覧いただけます。

  2. 経済協力開発機構（Organisation for Economic Co-operation and Development）、「The OECD Privacy Framework」、2013、https://www.oecd.org/sti/ieconomy/oecd_privacy_framework.pdf。

  3. GDPR の歴史の概要は https://cloudprivacycheck.eu/latest-news/article/a-brief-history-of-data-protection-how-did-it-all-start/ を参照してください。

  4. 国連『世界人権宣言』（1948 年） https://www.un.org/en/universal-declaration-human-rights/

  5. 経済協力開発機構（Organisation for Economic Co-operation and Development）、「個人データのプライバシー保護と越境フローに関するOECDガイドライン」、2013年。 http://www.oecd.org/sti/ieconomy/oecdguidelinesontheprotectionofprivacyandtransborderflowsofpersonaldata.htm

  6. 規則第25条参照

  7. KJディアリー「データマッピングとは？GDPR準拠のためのデータマッピングの重要性」Termly, 2018年10月30日, https://termly.io/resources/articles/gdpr-data-mapping/

  8. “GDPR. データ保護責任者」、インターソフトコンサルティング、https://gdpr-info.eu/issues/data-protection-officer/

  9. “GDPR. 個人データ」、インターソフト・コンサルティング、https://gdpr-info.eu/issues/personal-data/

  10. “GDPR。プライバシー・バイ・デザイン」、インターソフト・コンサルティング、https://gdpr-info.eu/art-25-gdpr/

  11. 特に規則の第38条を参照のこと。

  12. 規制の第4条

  13. ディアリー「データマッピングとは？GDPRコンプライアンスのためのデータマッピングの重要性」https://termly.io/resources/articles/gdpr-data-mapping/

  14. 欧州議会、欧州連合理事会。 “欧州議会および理事会の指令 2009/136/EC” 2009 年 11 月, http://data.europa.eu/eli/dir/2009/136/oj

  15. 規則第9条参照。

  16. 規則第8条参照。

  17. 規則第22条参照。

  18. グリーンフィールドとは、開発に制約を与えるような作業が事前に行われていないプロジェクトを指す言葉である。対照的に、ブラウンフィールドとは、既存のプラットフォームで作業をしなければならないことや、既存の制約の下で作業をしなければならないことに基づいて、あらかじめ制限が設けられているプロジェクトを指す。

  19. 仕様書と補助資料、ユーザー・マネージド・アクセス作業部会、カンタラ・イニシアティブ、https://kantarainitiative.org/confluence/display/uma/Specifications+補助資料、https://kantarainitiative.org/confluence/display/uma/Specifications+Auxiliary+Documents

  20. リザール、マーク、デビッド・ターナー編。”Consent Receipt Specification” Consent & Information Sharing Working Group, Kantara Initiative https://kantarainitiative.org/file-downloads/consent-receipt-specification-v1-1-0/

  21. “The Principles” Information Commissioner’s Office Guide to the General Data Protection Regulation（GDPR）, https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/.

  22. Katarzyna Szymielewicz, Bill Budington, “The GDPR and Browser Fingerprinting. How it Changes the Game for the Sneakiest Web Trackers, Electronic Frontier Foundation, 2018年6月19日, https://www.eff.org/deeplinks/2018/06/gdpr-and-browser-fingerprinting-how-it-changes-game-sneakiest-web-trackers

  23. “ゼロ知識証明”、ウィキペディア、最終更新2020年1月24日、https://en.wikipedia.org/wiki/Zero-knowledge_proof .

  24. “GDPR 第 15 条 データ対象者によるアクセス権」インターソフト・コンサルティング、https://gdpr-info.eu/art-15-gdpr/ .