Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

汎用認証サイトで対応を予定しています。

  • 欧州では2018年5月に「GDPR」が施行される。
  • GDPRは「General Data Protection Regulation」の略。
  • 現行法であるデータ保護指令(Directive 95/46/EC)の
    • ルールの統一
    • 「指令」から「規則」に格上げ(欧州法として加盟国に直接適用)
  • 「一般データ保護規則」とも呼ばれる個人情報保護の法律。
  • 内容は、端的に言えば「個人データ」の「処理」と「移転」に関する法律。

登場人物

データ主体(本人)

個人データに関連する当該個人

データ保護機関

EU加盟国が設置した、データ保護に関する調査・是正権限を持つ機関

コントローラー(管理者)

  • 個人データ処理の目的と手段を決定する。
  • GDPR違反の責任を負う。
  • データ保護機関との協力義務がある。

プロセッサー(処理者)

  • 個人データの処理を行う当該個人・法人
  • データ保護機関との協力義務がある。

対象

対象データ

具体的なガイドラインは第29条作業部会(Article 29 Working Party)が作成中であり、
定義の詳細や業種業態ごとの管理手法について不明点がまだ多い段階

個人データ

自然人(データ主体)に関するあらゆる情報

もしくは複数の要素を参照することによって、
直接的にまたは間接的に、識別され得る者

  • 氏名
  • 識別番号
    • クレジットカード番号
    • メールアドレス
  • 技術的な情報
    オンライン識別子
    • IPアドレス
    • クッキー
    • 位置データ(GPS)
  • パスポート情報
  • 固有性に関する要因
    当該自然人に関する、社会的アイデンティティに特有な情報
    • 物理的
      • 身体的
    • 生理的
      • 生理学的
      • 遺伝子的
    • 精神的
    • 経済的
    • 文化的
    • 社会的

法人データ

企業などの法人データ

死者のデータ

・・・

対象外

完全に匿名化されたデータは対象外。

適用対象

組織の規模、公的機関、非営利団体等関係なく対象となる
(中小零細企業でも対象だが一部例外措置あり)

域内

EU内(欧州経済領域EAA)に拠点を置く、

  • データの主体(個人)
  • データ管理者(EU居住者からデータを収集する組織)
  • データ処理者(データ管理者の委託先としてデータを処理する組織)

域外

EU内(欧州経済領域EAA)に

  • データ管理者(EU居住者からデータを収集する組織)
  • データ処理者(データ管理者の委託先としてデータを処理する組織)

がなくても、

  • EU居住者に商品やサービスを提供する場合
  • 個人データを処理、または監視する管理者(Controller)、処理者(Processor)する場合

には適用される。

域外でも適用されるケース

域外でも、以下のようなケースには適用される。

  • 人が日本 -> EEAへ移動
    • 短期出張や短期旅行でEEA内に所在する日本人の個人データを日本に移転する場合
    • 日本企業から EEA内に出向した従業員の個人データ(元は日本から EEA内に移転した情報)
  • データの日本 ⇔ EEA間の行き来
    • 日本から EEA 内に個人データを送付する場合(基準に沿って EEA内において処理されなければならない)
    • 日本から EEA 内に個人データが送付され、EEA内で処理された個人データを日本へ移転する場合

義務

処理

処理には、収集・保管・変更・開示・閲覧・削除など、
個人データに対して行われるほぼすべての行為が該当する

処理過程の特定

処理対象の個人データおよびその処理過程を特定しなければならない

  • 個人データの収集および利用目的について、有効な同意が明示的に行われなければならない
  • 個人データの処理および保管に当たり、適切な安全管理措置を講じなければならない
  • 個人データの処理を行う目的の達成に必要な期間を超えて、個人データを保持し続けてはならない
  • 個人データの侵害(情報漏えい)が発生した場合、企業はその旨を監督機関に対し、
    72時間以内に通知しなければならない。また、データ主体にも遅滞なく通知しなければならない。

データ主体の権利の尊重

(第13条~22条)

管理者は次のデータ主体の権利を尊重しその行使を円滑にする必要がある。

  • 情報権(情報の通知を受ける権利)(第13条、14条)
    管理者はデータ主体から個人データを収集する場合、
    個人データ入手時に、データ主体に一定の情報を提供しなければならない。
  • アクセス権(第15条)
    管理者はデータ主体から個人データへのアクセスの請求があればそのコピーを提供しなければならない。
  • 訂正権(第16条)
    不正確な自己の個人データに関する訂正を管理者に求める権利を有する。
  • 削除権(忘れられる権利)(第17条)
    一定の場合、データ主体は自分に関する個人データの削除を遅滞なく管理者から得る権利を有する。
  • 制限権(処理を制限する権利)
  • 携行権(データ携行の権利)
  • 異議権(処理に対して異議を述べる権利)
  • 自動処理による決定の対象とならない権利。

データ保護責任者

定期的に大量の個人データを取扱う組織は、
データ保護責任者や欧州における代理人を任命しなければならない。

  • データ保護影響評価(DPIAs)
    データ処理が個人の権利および自由に高い危険を生じさせるおそれがある場合、
    処理を行う前に、処理操作がデータ保護に対して及ぼす影響の評価が必要。
  • データ保護byデザイン・byデフォルト
    データ処理のシステムを設計し、このシステムをデータ処理に利用する場合、
    • データ主体の権利を保護する、技術的・組織的措置を講じる必要がある。
    • 初期設定で、データ処理行為が処理目的に必要な最小限に限定されるようにする義務がある。

移転

個人情報の移転

  • EU(欧州経済領域EAA)から域外(第三国)への個人データの移転は原則として禁止。
  • 域外移転が可能なのは、データの保護措置が「十分なレベル」にあると認められる国のみ。
  • 例えば、日本のように欧州委員会によって、適切な個人情報保護制度を有している
    と認められていない国への情報移転は、以下のいずれかの要件を満たしに行く必要がある。
    • 本人同意を得る
    • 拘束的企業準則(binding corporate rules)を策定する
    • 標準契約条項(SCC:Standard Contractual Clauses)を締結する

※ 殆どの日本企業は、標準契約条項(SCC)で対応。

制裁

  • 違反行為の種類
    • 管理者および処理者の義務違反
    • 認証機関の義務違反
    • 監視機関の義務違反
  • 以下の高い方が制裁金として課される。
    • 企業の全世界年間売上高(グループ連結)の2%以下
    • または1000万ユーロ(1ユーロ125円とすると25億円)

  • 違反行為の種類
    • 処理の基本原理の違反
    • データ主体の権利の侵害
    • 個人データの移転に関する違反
    • 構成国法に基づく義務の違反
    • 監督機関の命令または制限の不遵守
    • 監督機関の命令の不遵守
  • 以下の高い方が制裁金として課される。
    • 企業の全世界年間売上高(グループ連結)の4%以下、
    • または2000万ユーロ(1ユーロ125円とすると25億円)

ポイント

今後とも、動向をウォッチする必要がある。

リスク

以下のケースはリスクが大 EAA内の個人データを直接使用するサービス

  • モニタリング、プロファイリングに個人データを利用
  • 当該組織のコア・ビジネスに関わる個人データ利用

留意点

  • 明確な同意取得
  • 機能提供
    • プライバシー・ポリシー
    • 削除権(忘れられる権利)
    • 携行権(データ携行の権利)
  • データ保護責任者
    • データ保護責任者や欧州における代理人を任命
    • 下記の導入・実施の義務
      • データ保護 by デザイン・by デフォルト
      • データ保護影響評価(DPIAs)

侵害対応

  • 72時間以内の報告
  • 通知内容・通知方法の検討
    • データ保護機関
    • データ主体
  • 救済実施
    • データ主体の救済
    • データ保護機関への対応

参考

スラド

@IT

  • GDPR初歩の初歩

InfoQ

理解すべき重要点

  • データ主体に対する透明性
  • データ保護 by デザイン・by デフォルト

個人識別情報(PII)を認識する

  • 個人を一意的に識別するために使われるデータ
  • 別々であれば固有情報でなくても、組み合わせることで、個人を識別できるデータ

プライバシのための設計

  • GDPRに準拠させるもっとも安価な方法は、要求を正しく実装すること。
  • 徹底の度合いはシステムのリスクの程度による。
  • 監査証跡
    • 最小の要求(データ保護機関に報告する必要がある)
    • 管理だけでなく侵害の被害を抑える(デジタル・フォレンジック)。
    • システム・アドミニストレータの否認防止の特徴
  • データ露出の制限
    最善の方法は、収集するデータと保存する期間を制限
    • 本当に必要なデータだけ収集・アクセスするように制限
    • データのライフサイクルを明確に定義し、それを記述する
      (ある種のアーカイブと削除の仕組みを導入する。)
  • 移動データ保護の仕組み
  • 暗号化
  • 匿名化と仮名化
    • 匿名化
      フィールドを削除するか、隠すことで、識別可能な情報を取り除く。
    • 仮名化
      識別可能な情報を仮名で置き換え、データ内で識別情報を分離。
  • ロギングの規格・ガイドライン
    ログにPIIが含まれていないことを確認する。

システムをチェックする

簡単なチェックリスト。

  • 収集するデータと目的
  • データの保存期間
    収集したデータのライフサイクルを記録する。
  • データを処理する基準
    データを収集する基準を記録する。
  • データフロー図
    • 関係者
    • 階層
    • プロトコル
  • ユーザの権利
    データ主体に権利を知らせ、その権利をどのように行使するか説明する。

拡大したユーザの権利をサポートする

  • 自動化したリアルタイムの運用を必要としない。
    (実際に必要なのは、30日以内に要求に回答するだけ)
  • しかし、セルフサービスのユーザインタフェースを実装したほうが安価になる。
  • 情報を削除することで、削除は達成できるが、
    部分的にそれを上書きし、事実上、それを匿名化した方が簡単。

データ処理者かどうか?

  • データ処理者は、制裁の責を負う。
  • 責任を避けるには、単にどのような状況下でも、
    • PIIデータにアクセスしない、
    • また、できないようにすること。
    • そのことがどの契約にも明確に述べられているようにする。
  • PIIデータの処理を避けるのは難しい場合、
    • ログファイル、テスト環境、製品環境への緊急パッチにPIIデータが潜む注意をする。
    • PIIデータベースに絶対にアクセスする必要がある場合、データ処理者であると認める。

GDPRの神話を壊す

  • ユーザのデータを収集して処理することを止めるものではない。
  • 「クラウドサービスをやってはいけない。」ということではない。
  • エクスポート時に、
    • 身元と結びつく全てを手に入れる訳ではない。
    • 直接収集された情報のみ含まれているべき。
  • 対策
    • データ保護
      停止中や転送中に2048ビットキーですべてを暗号化することを必要としない。
    • 監査ログ、侵入検出など。
      すべて監査ログをとり、侵入検出とテストデータ管理のツールを持つことを必要としない。
  • 制裁(罰金)
    • 制裁は、データ・プライバシについて何かし始めるための主な理由ではない。
    • その時が来たら、罰金の範囲を決めるために使う多数の質問を一覧表にしている。
  • ユーザの権利
    • 必ずしも、自動的に行使する必要はない。
    • しかし、その場合は、ユーザの身元と要求の正当性を確認することが重要。

結論

  • データ保護規則は、建設的で、
    • 透明性とプライバシを改善は、ユーザの信頼に繋がる。
    • 新しいシステムは、GDPRと互換性があるように構築すべき。
  • 解釈は進化し続け、
    • データ侵害、監査、制裁が将来起きる。
    • グレーゾーンには、常識が役に立つ。

Information Law 情報法 > EUデータ保護規則(GDPR)

http://informationlaw.jp/category/world-data-protection/eu-data-protection/

個人データの処理に関する7つの原則

http://informationlaw.jp/2016/09/28/eugdpr-principles/

  1. 合法性、公正性および透明性
  2. 目的制限
  3. データ最小限性
  4. 正確性
  5. 保管制限
  6. 完全性および機密性保持
  7. 責任

EU域外への個人データ移転

データ主体の8つの権利

  • 8つの権利

管理者

処理者

データ保護担当者

フジイユウジ::ドットネット

  1. 欧州圏からアクセスできるとかユーザー1人いるとGDPR対象事業者になる、わけじゃない
  2. プライバシーポリシー更新してるだけで対応済みとしている企業も多い

欧州連合に向けてのサービス提供の意思が明白か。

  • 99.9%日本向けサービスだけど

    「何か間違って欧州にいるユーザーが混ざる可能性が微粒子レベルで存在する」

くらいなら対象外と考えても良さそう。

  • 以下のような条件を全て満たすなど、
    • 客観的に見ても明らかに日本国内向けのサービス
    • 日本語のみでサービス提供している
      (英語版もあるサービスは判断が難しくなります。)
    • 決済手段が日本向け(日本円のみなど)であることがわかる
    • 欧州へのサービスの提供について特段の記載がない
    • 実態としても欧州ユーザーがほぼいない(例外レベルの数はいるとしても)

簡易なGDPR対応は難しくはない。

  • プライバシーポリシーにGDPRの権利を実行するときの窓口を書く。
  • できるだけ使ってるサード・パーティー・サービスを書く。

清水誠メモ

データ管理者 (Controller)

Webの運営者(事業会社・団体)

  • 事業に必要なデータの用途と処理過程を定義する
  • それを訪問者へ分かりやすく説明する
    (プライバシーポリシーやCookieポリシー、入力フォーム掲載ページで)
  • GDPRに対応できる体制やルール、機能を持ったツールや委託先を選ぶ
  • データ取得と用途について、訪問者から事前の明示的な同意を得る
  • 訪問者からデータの確認や削除要求を受けた場合は対応する
  • 目的達成に必要な保管期間を過ぎたデータは削除する

データ処理者 (Processor)

Google:Google Analytics, Adobe:Adobe Analytics

  • データをセキュアに保管・処理する
  • GDPR対応に必要な機能を実装する
  • 指定IDのデータを表示・エクスポート・削除できる機能
  • 用途に不要なデータの匿名(仮名)化
  • 保管期限を過ぎたデータの自動削除機能

まとめ

  • 不要な個人データの取得停止や匿名化
  • 保管期間を過ぎたデータの削除
  • データ取得ツールをオプトイン対応する
    (オプトイン : 広告メールの配信や、個人情報の利用など、利用者の承諾を得ること)
    • プライバシーポリシーやCookieポリシーを更新
    • データ取得の同意を得るUIを実装する
  • オプトアウトの方法を説明する
    (オプトアウト : 個人データの第三者への提供を本人の求めに応じて停止すること)
    • 取得されることを拒否する権利(同意)
  • 個人データの確認や修正、エクスポート、削除に対応する
    • アクセスする権利(内容確認・修正)
    • 消去する権利(削除)
    • 持ち運ぶ権利(エクスポート)

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-06-26 (火) 09:15:47 (147d)