2018年に新しいソフトウェアソリューションを生み出しますか? もしそうならば、この記事を読んだほうがいいでしょう。EU一般データ保護規則(GDPR)は、移行期間を経て、この夏に施行されます。この規則に違反すると、2,000万ユーロ以下の制裁金が課されるでしょう。大企業の場合は、さらに高額になります。この規則に記載された制裁に加え、大きな不注意やデータ侵害に対して責任のある個人は、刑務所に送られる可能性もあります。
明らかにこれは深刻です。私は、2つの極端なGDPRへのアプローチを見てきました。1つは、自分には当てはまらないふりをして無視します。もう1つは、空が落ちて、どんな開発も個人データに注目できないと言い放ちます。どちらのアプローチも間違って誤解しているものであり、大きな損失を生み出すかもしれません。GDPRは、すべての個人データが終わるシナリオを作るのではなく、代わりに、個人データを透明で安全に扱える規則を決めて、多額の制裁金により、それらの規則を無視する人たちを脅かします。
GDPRは、リスクベースの考え方を特に強調します。リスクが許容できるものになるまで、プライバシのリスクを軽減するためのあらゆる手段を取ります。私は、この規則に感謝します。設計時に、まったくセキュリティやプライバシが組み込まれていないソフトウェアはたくさんあります。このようなソフトウェアやその違反している部分は、個人データがどのように使われるのか、ユーザに不信感を抱かせます。これを変える時が来たのです。
理解すべき重要点
このテーマは大きいので、私は、新しいソフトウェアソリューションを作るプロセスに、純粋に集中したいと思います。組織的なサポートとレガシシステムについてはいろいろと言われていますが、それらは出発点に非常に依存しています。GDPRは規則にあまり例外を認めません。大企業から中小企業、非営利団体、政府機関まで、重要な点を知る必要があります。
新しい規則の重要な点の1つは、データ主体に対する透明性です。例えば、データベースのようなレジストリを持っていて、個人識別データが含まれている場合、GDPRでは、そのデータの使用はデータ主体に透明であるべきだとしています。これは、つまり、データを収集している人は、収集しているデータ、目的、誰がデータにアクセスするか、そして、データがシステムにどのくらい存在するかを分かるようにしなければなりません。この要求に対処するには、当然、これらのことをすべて知り、記述しなければなりません。透明性に関して、当該データにより簡単にアクセスできるようにする必要があります。データ主体は、最初にそのデータを提供したのと同じくらい簡単に、データを確認、修正、出力、移動、消去できなければなりません。
もう1つの重要なテーマは、プライバシバイデザインとプライバシバイデフォルトです。これは、今後、すべてのアーキテクチャへ実際に統合されるべきです。この規則以前は、プライバシバイデザインとプライバシバイデフォルトは、設計の自動的要素でしたが、人々は何かが起きるまで、セキュリティやプライバシにお金を払いたくありませんでした。GDPRは、今、これに対処する強力な動機付けになります。2,000万ユーロまでの価値を動機付けます。プライバシバイデフォルトはいろいろなことを意味しますが、本来、個人識別データとそのプライバシを適切に管理して、保護することを目的とします。これが一般的に要求するのは、例えば、特に個人識別情報の読み取りアクセスを含む、誰がいつ何をしたかという明白な監査証跡です。さらに、そのデータがいつ保存され、様々なレイヤを移動したかに注意を払い、システムからデータが漏洩するのを避けるために、適切な暗号化を適用すべきです。
また、その情報を収集して処理する権利を明確に与えることを表す、個人データを処理する正当な基準を持たなければなりません。この基準は、例えば、一定期間、個人の情報を収集して、保存する必要があることを示す法になるでしょう。個人データを処理する基準は、契約、取り決め、または、取引かもしれません。
個人データを収集して処理する同意を求めることはできますが、GDPRは簡単にそうさせてくれません。「私の情報をマーケティグの目的で使うことに同意します」という文言をチェックしたチェックボックスを置くことでは受け入れられません。同意は、明確で正確に書かれていて、理解できるものでなければならず、あらかじめ設定することはできません。最初に同意したのと同じくらい簡単に、その同意を取り消せるようにすべきです。これは、ソフトウェア設計者 が自分たちで決定できることではありませんが、そのソフトウェアを所有する人と議論する必要があります。
興味深い点があります。ソフトウェアを構築するチームメンバが、構築中に実際の個人データにアクセスできる場合、そのメンバは、データ処理者になり、同様の制裁規定と責任を負います。運用チームも同様です。運用チームがデータベースとデータにアクセスできる場合、彼らが責任を負います。このことについて、よく考えてください。実際の顧客データにアクセスしなくても、大抵のシステムは構築して運用できます。
個人識別情報(PII)を認識する
GDPRは、個人識別情報にしか関心がありません。GDPRは、製品や会計情報等、個人に属しないデータには適用されません。あなたは、それでもそれらの情報を機密として分類し、保護したいと思うかもしれませんが、GDPRでは、それらをPIIデータではないとみなし、その状況を無視します。
GDPRは2種類のPIIデータを識別します。社会保障番号、Eメールアドレス、購入履歴等の識別子に直接結び付けられるもののように、個人を一意的に識別するために使われるデータがあります。それから、医療/健康情報、宗教、性的指向、些細なことから収集した情報のように、特別な機密データがあります。
GDPRによると、別々であれば固有情報でなくても、組み合わせることで、個人を識別できるようになりますので、注意してください。そのため、PIIは、郵便番号、旅行、そして、購入場所のような様々な場所の値から導き出される識別子も含みます。小さなデータセットと、値の珍しい組み合わせによって、簡単に個人が識別されます。
個人に属する、または、個人から収集された情報は、プライバシ規則によって保護されるため、いくつかの例外を除き、大抵のデータベースはPIIを含みます。私は、典型的なシステムデータの70%-80%はPIIだと予測します。保護すべきなのは、社会保障番号やクレジットカード番号だけではありません。
IPアドレスやサロゲートキーを含む、アクセスログ、監査ログ等は、様々な議論があります。これらは個人データでしょうか? これらはレジスタでしょうか? これらのデータに、すべての個人の権利が及ぶでしょうか? これらのデータは、どのくらい強く保護されるべきでしょうか? 専門家たちの意見は様々なようです。私たちは、このことがどのように発展するか様子をみなければなりません。いずれにしろ、過剰に反応せず、グレーゾーンに常識を使うことをお勧めします。この種の情報は、データ侵害がどのくらい危害を加えるかによって、ある程度、保護されるでしょう。また、保護されるべきものです。しかし、率直に言って、もっとも厳しい定義で見ても、世界のすべてのウェブサーバがPIIレジストリになるとは思えません。
プライバシのための設計
ソフトウェアをGDPRに準拠させるもっとも安価な方法は、要求を正しく構築することです。どのくらい徹底的にするかは、問題になっている特定のシステムのリスクの程度によります。
- システムは、特別な機密情報を含みますか?
- システムは、GDPRの目的では機密ではないが、公表するときまりの悪い思いをするか、危険なものを含みますか?
- 誰かがデータベースの内容を公表した場合、あなたのビジネスにどれほど大きなリスクがありますか?
- ユーザのデータベースは、どのくらいの大きさですか?
ユーザが少なく、収集したデータが機密でも、有害でもない場合、システムはリスクの低い環境であると考え、そのデータを保護するために、費用対効果の高い管理方法を使うとよいでしょう。反対に、システムが多数のユーザの機密データを含んでいる場合、より強力な保護を適用したいと思うでしょう。
よい監査証跡は、最小の要求であることです。監査証跡は、管理していることを示すだけでなく、データ侵害の場合に被害を抑えるのに役立ちます。内部、または、外部によるデータ侵害の後、最初にしなければならないのは、どのユーザに影響するのか、また、どのデータにアクセスされたのかを示せるフォレンジックを見つけることです。これは、データ保護機関に報告しなければならない情報です。さらに、これらはデータ侵害について通知しなければならないユーザです。フォレンジックがなければ、侵害がすべてのユーザとすべての記録に影響すると想定しなければなりません。
よい監査証跡は否認防止の特徴もあります。言い換えれば、システムアドミニストレータでさえ、変更したり、破壊したりすることはできません。例えば、システムアドミニストレータがどのデータを侵害しているのかを見るために、監査証跡を使いたいかもしれません。これは以前あったことで、これからもあるでしょう。また、監査証跡はPIIとして分類されます。固有のアイデンティティと、そのアイデンティティに直接つながるデータがあります。
監査証跡の後、次のタスクは、データの露出を制限することです。このための最善の方法は、収集するデータと保存する期間を制限することです。最初からソフトウェアに、ある種のアーカイブと削除の仕組みを導入することで、ユーザに対して、そのことを詳細に記述できます。データ侵害が発生した場合、その時点でターゲットにされたシステムの中に実際にあったデータが、影響を受けるだけです。多くのシステムはすべてのデータを収集し続け、データが陳腐化しても、処分することはありません。GDPRは、データのライフサイクルを明確に定義し、それを記述するように促します。また、本当に必要なデータにだけアクセスするように制限すべきです。これは、特に機密データに当てはまります。
データベースやファイルシステムにあるデータや、ネットワーク上、特に別の関係者へ移動するデータに対して、十分に保護する仕組みを持つべきことは、すでに言いました。暗号化は有効ですが、弱点もあります。最強の暗号化技術は、早く暗号化してキーを安全にし、遅く解読します。残念なことに、これは複雑で、実装するには費用がかかる解決策です。クラウドサービスは、その対極として、安価で簡単にチェックボックスを使ってデータベース全体を暗号化したり、キーと暗号化の管理を提供したりします。これは簡単ですが、これらの仕組みには弱点があります。リスクやデータの感度に基づいて、何がうまく行くのかを見つけなければなりません。
匿名化と仮名化の仕組みは、テストデータや分析データ等で役立つでしょう。匿名化は、基本的に、フィールドを削除するか、隠すことで、すべての識別可能な情報を取り除きます。仮名化は、識別可能な情報を仮名で置き換え、一般的にはデータ内で識別情報を分離しておきます。しかし、どちらのプラクティスも、適切に実施するのは難しく、GDPRの互換性を助ける完璧な手段を提供するものではないかもしれません。それでも、これらはツールキットの中で価値のあるツールです。
ロギング規格やガイドラインを、もう一度確認するとよいでしょう。ログにPIIが含まれていないことを確認できるならば、もっとも簡単です。そうでなければ、ログがPIIレジストリになるということです。例えば、アクセスログや監査ログ等、すでに個人に結び付けられたログがあります。しかし、ユーザID、名前、または、同じような値を持つものによって、操作上のデバッグログを汚さないでください。個人に関連しないけれども、一般的なシステム情報を持つログから、個人に関連するログを明瞭に分けるとよいでしょう。
システムを記録する
GDPRは記録が大好きです。この規則の重要な点の1つは、コンプライアンスを証明できることです。証明書を示して証明でき、同様に、システムを記録することで得をします。必要であれば、提供するのに慣れている記録のレベルから構築できますが、それは、多くの要素に基づいて異なっているかもしれません。しかし、今後は、あると役に立つ、追加の記録があります。こちらは、簡単なチェックリストです。
- システムに個人データを記録する。
- 収集したデータのライフサイクルを記録する。
- データを処理するすべての関係者を記録する。
- データを収集する基準を記録する。
- データ主体に権利を知らせ、その権利をどのように行使するか説明する。
収集するデータ、収集の目的、データの保存期間、このデータを処理する基準を記録すべきです。記録の種類の組み合わせで、うまくできるでしょう。規則を説明する一般政策文書がすでにあるかもしれませんし、あるべきですが、多くのソフトウェアデザイナがGDPRの分類が述べる基盤の目のようなデータ列を作成し始めるのを見てきました。基本的に、ドメインモデルとして一般的に使っている文書があって、そこからプライバシ情報を拡張します。これらの文書は、ユーザに提供するデータ保護方針文書の基本となります。ユーザの権利を保証する最初のステップは、どの情報をシステムが収集するのか理解することです。
もう1つの興味深い一面は、データがどのようにネットワークを移動するか、そして、どの関係者がそのデータにアクセスして、処理するかということです。このため、関係者、階層、そして、プロトコルも文書化するデータフロー図を作成しなければなりません。データ侵害の場合、素早く理解して、露出を制限するために、この図を使うことができます。
さらに、望むならば、データを保護し、十分なレベルのプライバシに達するために、どのように管理したのか文書化するといいでしょう。
拡大したユーザの権利をサポートする
ユーザ/データ主体のほとんどの権利は、EUで制定されたデータ保護指令にあります。これは、GDPRで、それらの権利がどのように見えるかを示す簡単な一覧です。
- アクセス権
- 修正権
- 削除権
- 処理を制限する/反対する権利
- データ携行権
- データ侵害を通知される権利
あらゆる種類の非現実的なAPIとそれをサポートするシステムを設計し始める前に、GDPRでは、自動化したリアルタイムの運用を必要としないことに注目すべきです。実際に必要なのは、30日以内に要求に回答するだけです。データを削除したり、エクスポートしたりする基準がないこと(法律のため、または、進行中の契約のため等)を回答するのは、合法的な回答です。ある人が要求した時に、他の人のデータを操作したり、エクスポートしたりして、新しいデータ侵害を作り出さないように、適切にデータを識別することがとても重要です。30日以内の回答窓口によって、様々な方法でデータを削ったり、削除したりできます。また、簡単に統合できないシステムにおいて、データを処理することもできます。
そうは言っても、企業がすでに顧客/ユーザ/データ主体に対してデジタルアイデンティティの概念を持っていて、なんらかのセルフサービスを提供する場合、セルフサービスのユーザインタフェースにこれらの識別権を付ける方がよいでしょう。あなたが自動処理で多くの文書化を扱えれば扱えるほど、より安価になるでしょう。また、処理に30日かかる要求をするよりも、リアルタイムでアクセスできる方が、ユーザは喜びます。
新しいソフトウェアを設計する時に、データ削除やエクスポートの機能の準備をしたほうが賢明かもしれません。情報を削除することで、削除は達成できますが、部分的にそれを上書きして、事実上、それを匿名化した方が簡単です。データエクスポートの形式は、今のところ、問題ではありませんが、あなたのドメインでGDPRユーザインタフェースを含んでいなくても、あらかじめ計画を立てておくとよいでしょう。
正しく実施するためにもっとも重要なことは、要求を識別して検証するプロセスへ、そして、データを削除するかエクスポートする仕組みへと導くように、データ主体が権利を行使できるところを一箇所にすることです。
データ処理者かどうか?
GDPRの責任のもとでソフトウェアプロジェクトに取り組む場合、重要な質問に応える必要があります。データ処理者であろうとしていますか? 最初から、制裁の責を負うデータ処理者にはなりたくないかもしれません。GDPRの責任を避けるには、単にどのような状況下でも個人を特定できるデータにアクセスしない、また、できないようにすることです。また、そのことがどの契約にも明確に述べられているようにする必要があります。PIIの処理を避けるのは難しいかもしれません。個人データは、ひどく書かれたログファイル、テスト環境、製品環境への緊急パッチの中に隠れているかもしれません。しかし、もし責任を避けたいなら、これらすべてを解決する必要があります。データから自分自身を守りなさい。データをあなたから守るのです。
もう1つの進むべき道は、データ処理者であると認めることです。これにより、個人データに自由にアクセスできるようになります。アクティビティを文書化する限り、処理は正当な基準であり、アクセスは定義された境界の中で起こります。こうして、明らかに責任を負い、どのような制裁にも注意しなければなりません。しかし、これは、PIIデータベースに絶対にアクセスする必要がある時に、取るべきルートです。
大抵のソフトウェアプロジェクトは、実際のPIIデータにさらされることを求めていません。これは、確かに進むべき道としてお勧めします。しかし、これには、新しいスキルやツールが必要かもしれません。
GDPRの神話を壊す
いいえ、データ主体は、ユーザの権利を行使して、借金や前科を消さないかもしれません。
いいえ、データ主体は、自分のデータのエクスポートを要求する時に、身元と結びつく全てを手に入れる訳ではありません。直接収集された情報のみ含まれているべきです。この規則の精神は、透明性であり、サービスプロバダを変化させる選択肢です。
ユーザの権利は、自動的に行使されません。データを処理する前に、最初に、ユーザの身元と要求の正当性を確認することは重要です。データベースが唯一の安全な識別子を持たない場合、これは難しいかもしれません。要求を拒否する、様々な正当な理由があるかもしれません。
いいえ、GDPRは、停止中や転送中に2048ビットキーですべてを暗号化することを必要としません。データを保護するための制御は、アクセス可能になるまでのリスクを軽減するために使われるだけであり、リスクはシステムや状況によって様々です。
いいえ、GDPRは、あなたがユーザのデータを収集して処理することを止めるものではありません。透明性、データの安全性、法的根拠に注意して、必要以上にデータを集めなければ、あなたは大丈夫です。
いいえ、データ侵害によって、自動的に2,000万ユーロの罰金が課せられるのではありません。そうなるかもしれませんが、この記事を読んで、アドバイスに従うならば、罰金を課せられる可能性を下げるところまで来ています。最初から、今できることを直して、残りの計画を持つことはとても役に立ちます。GDPRは、その時が来たら、罰金の範囲を決めるために使う多数の質問を一覧表にしています。
いいえ、制裁は、データプライバシについて何かし始めるための主な理由ではありません。この規則ができたのは、毎日、ますます多くのデータが収集され、ますます多くのデータ侵害が発生しているからです。システムにデータ侵害が発生すると、手数料や制裁金よりもずっと多くの費用がかかり、顧客の信頼を失う可能性があります。しかし、制裁金は、ソフトウェアや情報システムを構築して購入する時に、セキュリティやプライバシに多少のユーロを支払うことを企業に動機付けるよい方法です。
いいえ、クラウドサービスは、GDPRで絶対にやってはいけないことではありません。実際に、従来の多くのデータセンタよりも、プライバシバイデフォルトの要求に、より多く同期しているかもしれません。もちろん、サードパーティに機密データを転送すると、契約や文書に関して少し複雑になります。
いいえ、GDPRは、すべて監査してログをとり、侵入検出とテストデータ管理のツールを持つことを必要としません。そのようなツールをうまく利用すれば、楽になりますが、アプローチの中心は、リスクベースの評価と適切な管理であるべきです。
結論
GDPRが施行されるまでに、それほど時間はありません。もはや、新しいシステムは、GDPRと互換性があるように構築すべきです。これは正確な定義ではなく、特に、解釈は進化し続け、それらの多くはデータ侵害、監査、制裁が将来起きるものとして、明らかにされるだけです。私の望みは、あなたが最初に代償を払う人にならないように、この記事が役立つことです。
来るべきデータ保護規則は、非常に建設的で、驚くほどの望みがあると思います。最後に、あなたがセキュリティとプライバシをより重視するのには理由があります。透明性とプライバシを改善し、より管理できるようになると、システムのユーザにより信頼され、ユーザの多くは、多分、今誰も気づいていない、新しい種類の分析やマーケティングの情報を喜んで使わせてくれるでしょう。おそらく、2018年の夏には、いくつかの規則が明らかになって、大騒動が起こりますが、GDPRによって、長期的により安全で透明性があるようになると私は信じています。私はそれに大賛成です。
規則のグレーゾーンにいると分かって、何をすべきか確信が持てない時は、常識が役に立ちます。混乱の原因は、詳細に記述し、きまり悪かったり、恥ずかしく思ったりせずに、ソフトウェアソリューションのユーザ/データ主体に、正直に説明できるものでしょうか? もしそうならば、たぶん大丈夫でしょう。データ漏洩のような最悪のシナリオを考えましょう。データベース、スナップショットコピー、または、Excelのエクスポートが、どこかで公表されるような悪人の手に渡った場合、誰が何を侵害したか、そして、どのユーザに知らせる必要があるかを正確に見つけられますか? データがどのように保護されていたかを説明するのは、きまり悪いことではありませんか? そうでないならば、おそらく、あなたは人として可能なことをしているので、もし制裁があっても、多分軽減されるでしょう。最前を尽くして、後は計画を立てましょう。より透明性を持ち、もっと安全な世界を構築しましょう。最後には、みんなもっと幸せになるでしょう。
著者について
Arto Santala氏は、Solita Oyのソフトウェアアーキテクトです。Santala氏は、明日の世界を可能にするためのソフトウェアソリューションを作り出す、20年以上の経験を持ちます。Santala氏の最大の情熱は、すべてのものを自動化することと、正しいことを正しい時に終わらせるために、アジャイルの方法を使うことに向けられています。