目次


GDPR 準拠のアプリケーションを開発する, 第 3 回

アプリケーションのプライバシー・リスクを最小限に抑える

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: GDPR 準拠のアプリケーションを開発する, 第 3 回

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:GDPR 準拠のアプリケーションを開発する, 第 3 回

このシリーズの続きに乞うご期待。

シリーズの第 3 回では、アプリケーションのプライバシー・リスクを軽減する実用的なアプリケーション開発手法について説明します。第 1 回では GDPR の要点を解説し、第 2 回では開発者がソフトウェア開発ライフサイクルの中でプライバシー・リスクを評価し、軽減するためのガイダンスを提供しています。

個人データの保護を大幅に強化するためにアプリケーションで利用できる、いくつもの技術的ソリューションがあります。GDPR では個人データの匿名化、仮名化、暗号化を要件としていませんが、このような技術的ソリューションはデータ主体のプライバシー・リスクを軽減する手法として GDPR の中で参照されています。こうした手法は GDPR 準拠の適用範囲を縮小するとともに、アプリケーションのプロビジョニング組織に対するリスクを軽減します (この場合、この組織は管理者または処理者 (ホスティング) の役割としての責任を負っています)。したがって、アプリケーション開発者は、GDPR で参照されている個人データの保護手法のそれぞれを理解し、手法の適用について検討する必要があります。

GDPR では技術的なセキュリティー要件一式を規定していませんが、アプリケーション・セキュリティーのベスト・プラクティスに従うことがデータ・プライバシーの基本的義務と見なされます。不完全アプリケーション・セキュリティーが原因で個人データが侵害された場合、かなりの数の個人に苦痛と損害を与える恐れがあります。GDPR 第 5 条の条項 (f) により、アプリケーションのセキュリティーが適切な基準に達していなかったために、悪意をもって、または偶発的にでも個人データが侵害された場合、そのアプリケーションは不法なものとみなされます。

第 5 条 (5) - 個人データは (f) 無許可の、または違法な取り扱いに対する保護、および偶発的な滅失、破壊、または損壊に対する保護を含め、適切な技術的または組織的対策を用いて、当該個人データのセキュリティーが確保される形で処理されなければならない (完全性および機密性の原則)。

セキュリティーが十分に確保されていないことが原因で大量の個人データが漏洩する結果となった場合、そのアプリケーションを開発および提供する組織 (管理者) は非常に大きなリスクにさらされます。このようなインシデントが発生した場合、データ・プライバシー監督機関によって極めて厳しい金融制裁措置が取られるだけでなく、GDPR のデータ漏洩開示義務により、組織の評判が大きく傷付くことになり兼ねません。

このガイダンスでは開発者を対象に、GDPR の中で参照されている、アプリケーションのデータ・プライバシー・リスクを軽減する手法について説明します。また、GDPR 準拠の監督機関が期待する、アプリケーション開発における適切なセキュリティー手法についても概説します。

匿名化

匿名化とは、個人データから当該個人 (データ主体) を特定できないよう、個人データを浄化して変更するプロセスのことです。データ匿名化は単方向のプロセスであり、いったん匿名化されたデータ・セットに逆のプロセスを適用しても、元の個人データに戻すことはできません。

個人データが適切に匿名化されていれば、アプリケーション・ユーザーのプライバシーが守られるだけでなく、適切に匿名化されたデータは個人データとして分類されなくなるため、GDPR によるプライバシー保護のあらゆる法的義務の適用対象外となります。このことは備考 26 で裏付けられており、データ保護の原則は、匿名化されたことによりデータ主体を特定できなくなったデータに対しては適用されないとあります。

備考 26 - 匿名情報 (すなわち、特定された、または特定可能な自然人と無関係な情報) および匿名化によってデータ主体を特定できなくなったデータに対しては、データ保護の原則は適用されないものとする。

アプリケーション・プロセス、サード・パーティー製ツール、および SQL データベース・コマンドそのものによって、個人データを効果的に匿名化することができます。個人データの匿名化が成功したと見なされるには、匿名化プロセスで、直接または間接的に個人を特定できるすべてのデータをヌル化または削除する必要があります。そのようなデータには、以下があります。

  • データ主体の氏名
  • アプリケーション・アカウントおよびユーザー ID
  • e-メール・アドレス (データ主体の氏名が含まれないものも含む)
  • ニックネーム (フォーラムやオンラインのハンドルを含む)
  • 個人を特定するために検索できる識別子 (アカウント番号や参照番号、遺伝学的データを含む生体データ)
  • 位置追跡データ (住所、ジオタグ縦座標、IP アドレス、アプリケーションの Cookie)
  • 個人データが入力される可能性のあるテキスト・フィールド (例えば、ユーザー・コメント)

データの匿名化手法

データ匿名化手法のタイプによって、それぞれ異なるメリットとプライバシー・リスクがあります。以降のセクションで、最も一般的に使われている個人データの匿名化手法について説明します。

ヌル化、削除、改訂

直接および間接的に個人を特定できるフィールドをすべて削除するか、ブランクにする (ヌル化する) ことによって個人データを匿名化するという手法です。

図 1. ヌル化による匿名化の例
ヌル化による匿名化の例
ヌル化による匿名化の例
  • 利点: 匿名化解除 (匿名化プロセスをリバース・エンジニアリングして個人データに戻すこと) のリスクがほとんどありません。
  • 欠点: 本番データからテスト用データ・セットを作成しようとする開発者にとって、データ構造が失われることが問題になる可能性があります。データ・フィールドがヌル化、つまりブランクにされると、アプリケーションをテストしにくくなるためです。したがって、ヌル化による匿名化はアプリケーションでエラーが発生する原因になり得ます。

代入

個人を特定できるデータ・フィールドを偽の個人データで上書きすることによって個人データを匿名化するという手法です。代入による匿名化では、テーブルのデータをカスタマイズした偽のデータで置き換えるか、アルゴリズムを使用して、フィールドの型に期待される値と一致するランダム・データを生成する必要があります。

図 2. 代入による匿名化アルゴリズムの例
代入による匿名化アルゴリズムの例
代入による匿名化アルゴリズムの例
  • 利点: データ・セットを匿名化しても、その構造は維持されます。したがって、ソフトウェア開発ライフサイクル (SDLC) のテスト・フェーズで使用する本番品質のテスト用データを作成する場合や、サポートの一環としてアプリケーションの問題を再現する場合は、この匿名化手法が適しています。
  • 欠点: データ・セットに含まれる、直接または間接的に個人を特定できるデータ・フィールドが見落とされ、発見されないままデータ・セット内に残ってしまう可能性があります。匿名化されたデータ・セットに含まれる実際の個人データは、簡単には特定したり確認したりできません。

データ・マスキング

データ・マスキングは、フィールドの文字を「マスク」文字で置き換えるという、代入と、ヌル化による匿名化の両方を組み合わせた手法です。ペイメント・カード業界ではデータ・マスキングが広く使用されていて、ペイメント・カードの会員番号をマスキングによって部分的にだけ見えるようにしています (1234 56 XX XXXX 1234)。こうすることで、不正のリスクを伴わずにペイメント・カードを識別できるようにするためです。このようなマスキングの使用例は、領収書や取引明細書、そしてオンライン・バンキング・アプリケーション内でお馴染みのはずです。

  • 利点: 個人データを共有、表示、または印刷する必要がある場合、マスキングによってプライバシー・リスクを軽減することができます。
  • 欠点: 個人データのマスキングはアカウントや参照番号を識別できるようなフィールドには適していますが、他のタイプのフィールドには、不十分なデータ匿名化になる可能性があります。このような形式で匿名化しても、個人データを特定したり、元の個人データに戻せたりする場合があるためです。例えば、John Smith をマスキングして J*** Sm**** にしたとしても、データ主体を十分特定することはできます。

スクランブル / シャッフル

データ・スクランブルまたはシャッフルとは、個人データ・セットだけを使用してデータ「列」を入れ替えるという代入手法です。図 3 に示す単純な例では、姓をシャッフルすることで、匿名化データ・セットを作成しています。

図 3. データ・シャッフルの例
データ・シャッフルの例
データ・シャッフルの例
  • 利点: データ・セットを匿名化しても、その構造は維持されることから、テスト用データとして使用するにも適しています。
  • 欠点: 匿名化されたデータ・セットをつなぎ合わせれば、個人を特定できる可能性があるため、データ・シャッフルによる匿名化が解除されるリスクはかなりあります。また、シャッフル・アルゴリズムが解読されるというリスクもあります。図 3 に示されている例の場合、匿名化されたデータ・セットをリバース・エンジニアリングするには、レコードの名と年齢のフィールドをサード・パーティーのデータ・セットと相互参照するという方法があります。あるいは、シャッフル・アルゴリズムによって姓のフィールドのそれぞれには 2 つ後のレコードが格納されていることを解読することによっても、匿名化されたデータ・セットをリバース・エンジニアリングできます。

集約 / 汎化

データ集約または汎化とは、個人データを分析してから、統計的な形式または要約形式にするプロセスの一環として個人を特定するデータを削除するというデータ匿名化手法です。

  • 利点: 調査データやビッグデータ・アナリティクスの出力といった特定のタイプのデータ・セットでは、集約によってプライバシー・リスクを軽減することができます。例えば、Web アプリケーションの要件としてユーザーの概略位置を追跡する場合、記録された各ユーザーの IP アドレスを送信元の国に汎化するアプリケーション・プロセスを設ければ、個人を特定できるデータ、つまりユーザーの IP アドレスを匿名化できると同時に、ユーザーの概略位置を要約するというアプリケーションの要件を満たすことができます。
  • 欠点: 個人データを集約および汎化することに価値があるのは、個人のグループに関する統計情報または要約情報を収集するという要件がある場合のみです。

再特定化

個人データが匿名化されていると見なされるためには、個人を再特定できる可能性が一切残されないようにする必要があります。つまり、匿名化された個人データを他の外部データ (ソーシャル・メディアや Web サイト上で一般公開されている情報や、他のデータ・セットからの情報) と突き合わせることで、個人を特定できるようであってはならないということです。

データ・マイニング手法とデータ・アナリティクスにおける進化は、匿名化された個人データを再特定できる可能性が大きくなっていることを意味します。例えば、2006 年に行われたデータ・マイニング・コンペティションの一環として、Netflix はそのユーザー 500,000 人による映画の評価レコード 1 億件を一般公開しました。このデータ・セットは、Netflix ユーザー名が乱数で置き換えられて匿名化されたものです。データ・セットが公開されてから 16 日後に、テキサス大学の 2 人の研究者が、このデータ・セットに含まれるデータ主体は、逆の匿名化プロセスを適用する以外の方法によって特定できると発表しました。それは、映画の評価とタイムスタンプを、Internet Movie Database Web サイト (IMDb.com) 上で公開されている映画の評価と相互参照するという方法です。2 人の研究者はこの再特定化手法によって、多数の Netflix ユーザーを特定しました。彼らはさらに、個々の Netflix ユーザーの視聴履歴を明らかにすることも可能であることに気付きました。個人の視聴履歴から映画の好みがわかれば、その個人の性的嗜好も明らかになる可能性があることから、このことは重大なプライバシーの侵害であるとみなされます。

再特定化テスト

個人データの匿名化プロセスのすべてについて、開発者はそのプロセスによって個人データが十分に匿名化されることを確認しなければなりません。そのためには、匿名化されたデータ・セットが、相応の資格を有する侵入テストの専門家によってテストされるよう手配する必要があります。SDLC のテスト・フェーズでアプリケーションの侵入テストを行うことは、セキュリティーのベスト・プラクティスの 1 つです。侵入テストの対象範囲には、匿名化されたすべてのデータ・セットの再特定化テストを含めるようにしてください。テスト対象となる匿名化されたデータ・セットは、アプリケーション・プロセスと開発者によって作成された匿名化データ・セットの両方です。つまり、この両方を含めてテスト用データを作成します。

匿名化データの再特定化テストには、以下のことを試す必要があります。

  • 1 つ以上の私的事実を使用して、個人を特定できるか
  • 匿名化プロセスをリバース・エンジニアリングできるかどうか
  • 匿名化されたデータ・セットに含まれる個人を、合法に入手した一般公開データを使用して特定できるかどうか

仮名化

GDPR 第 4 条で参照されている仮名化とは、個人を特定できるデータを、仮名またはトークンと呼ばれる本物そっくりの架空のデータで置き換えるプロセスを意味します。匿名化とは異なり、個人データの仮名化は、必要に応じて個人データを再特定できるようになっています。アプリケーション・データ・セット内の個人データ・フィールドが仮名の値で置き換えられると、そのデータ代入が別のルックアップ・テーブル内で追跡されます。このテーブルを使用することで、個人データを再特定できるわけです。

図 4. 仮名化
仮名化
仮名化

仮名化により、個人を特定できるデータを (通常は、アプリケーションのネットワーク環境とは分離された) 別のデータベース・サーバーに移すことで、アプリケーションのプライバシー・リスクが軽減されます。仮名化データが含まれるアプリケーション・データ・セットが侵害されたとしても、攻撃者や第三者が偽の値を検索して個人データのデータ主体を特定することはできません。

第 4 条 (5) - 「仮名化」とは、追加の情報が分離して保管され、特定された、または特定され得る自然人に個人データが帰属しないことを保証する技術的および組織的措置を取ることによって、当該追加の情報を利用せずに個人データが特定のデータ主体に帰属しなくなるような方法で、個人データを処理することを意味する。

トークン化としても知られる仮名化は、フィールドの型および期待されるデータ値に一致するトークン・データを提供するように構成できるため、レガシー・データベースにさえデータ構造を維持することができます。Apple Pay、Samsung Pay、および Android Pay では、トークン化のソリューションを使用して、ペイメント・カードの会員番号ではなくトークンの値を各スマートフォンに保管するという方法で、ペイメント・カードの不正を防いでいます。スマートフォンのペイメント・カードに支払いが要求されると、そのスマートフォンに保管されているトークンが送信され、セキュアなデータ・センター内に保管されているペイメント・カードの詳細とそのトークンが突き合わせられて、決済が処理されます。ペイメント・カード業界 (PCI) では、実証されたソリューションとしてトークン化が広く使われています。トークン化は、ペイメント・カードの不正とデータ侵害のリスクを軽減するだけでなく、組織が従わなければならない PCI データ・セキュリティー・スタンダードの多くが軽減されることから、組織にとって大幅なコスト削減となるためです。

要するに、第 32 条 (1) でリスクの軽減手法として具体的に仮名化が引用されているように、GDPR 準拠のためのオーバーヘッドとコストを削減するとともに、データ主体のプライバシー・リスクを軽減するには、その効果が実証されたテクノロジーとして、アプリケーションによるトークン化の使用を検討する必要があります。

第 32 条 (1) - 管理者および処理者はセキュリティー・レベルがリスクに見合ったものになるよう、適切な技術的および組織的対策を実施するものとする。こうした対策には、必要に応じて特に (a) 個人データの仮名化および暗号が含まれる。

ハッシュ化

ハッシュ化は、数学アルゴリズムを使用して個人データ・フィールドを変換する、一種の仮名化です。ハッシュ化の場合、個人データ・フィールドは、ハッシュ値またはメッセージ・ダイジェストと呼ばれる固定長の曖昧な英数字文字列に変換されます。ハッシュ化によるプレーン・テキスト・フィールドのハッシュ値への変換は、単方向のデータ変換プロセスになるよう意図されています。つまり、ハッシュ化アルゴリズムは可逆ではなく、ハッシュ値を元のプレーン・テキストに戻すことはできません。ハッシュ化は一般に、入力されたプレーン・テキストをアプリケーションによって検証するために使用されます。具体的に言うと、定義済みのハッシュ化アルゴリズムを使用して、プレーン・テキストの入力値をハッシュ値に変換し、そのハッシュ値を、前に計算されて保管されたハッシュ値と照合します。2 つのハッシュ値が同じであれば、プレーン・テキスト入力と前にハッシュ化されたプレーン・テキストが同じである可能性が極めて高いことになります。このように、プレーン・テキストの値をデータ・セット内で保持しなければ、プライバシー・リスクが軽減されます。

アプリケーションではプレーン・テキストのパスワードをデータベースに格納するのではなく、ハッシュ化によって変換したパスワードのハッシュ値を格納して、データベース内のパスワードを保護する必要があります。つまり、ユーザーが認証プロセスでプレーン・テキストのパスワードを入力すると、アプリケーションが定義済みのハッシュ化アルゴリズムを使用して、そのプレーン・テキストのパスワードをハッシュ値に変換してから、そのパスワードがデータベース内に保管されているパスワードのハッシュ値と一致するかどうかを確認するという仕組みにします。アプリケーション・データベースのセキュリティーが侵害されたとしたら、パスワードのハッシュ値が可視になり、アクセスすることが可能になります。けれども、そのハッシュ値を使用してアカウントを認証することはできません。さらに、ハッシュ値を元のプレーン・テキストのパスワードに戻すのはほぼ不可能です。

図 5. パスワードのハッシュ化
パスワードのハッシュ化
パスワードのハッシュ化

ハッシュ化は不可逆になるように意図されているものの、レインボー・テーブルを使用してハッシュ値の解読を試みることは可能です。レインボー・テーブルとは、プレーン・テキストの値とその値から算出される可能性がある、あらゆるハッシュ値からなる大規模なリストのことです。ただし、ハッシュ化式に「ソルト」として固有のレコードのパラメーターを追加し、さらに SHA-512 などの強力なアルゴリズムを適用することで、ハッシュ値がその対応するプレーン・テキスト値にリバース・エンジニアリングされる可能性が大幅に小さくなります。ソフトを使用すると、攻撃者は固有のレインボー・テーブルを事前に計算しなければならなくなります。さらに、512 ビットを使用する SHA-512 のような強力はハッシュ化アルゴリズムを適用するということは、レインボー・テーブルを作成しようとすれば膨大な計算能力と時間が必要になることを意味するため、この攻撃手法は実現不可能になります。

図 6. ソルトを追加したパスワードのハッシュ化
ソルトを追加したパスワードのハッシュ化
ソルトを追加したパスワードのハッシュ化

データ・セットのセキュリティーが侵害された場合に、そこに含まれるハッシュ化されたパスワードが保護されるようにするためには、アプリケーションで強力なユーザー・パスワードを強制することも重要な要素になります。辞書攻撃や総当たり攻撃では、不正に手に入れたハッシュ値を使ってパスワードを特定することが可能ですが、8 文字以上の複雑なユーザー・パスワードを使用しなければならないようにしてあれば、このような攻撃によるリスクを大幅に削減することができます。

以下の文字の 1 つ以上が含まれた 8 文字以上パスワードは、複雑なパスワード文字列と見なされます。

  • 大文字
  • 小文字
  • 数字
  • 特殊文字 (#、$、*、%)

ハッシュ化は暗号化の管理に伴うオーバーヘッドを回避し、パスワードを保護してプライバシー・リスクを軽減する役割を果たしますが、通常、アプリケーションに必須となるほとんどの個人データ・フィールドには、ハッシュ化による仮名化手法は適していません。

個人データの暗号化

データ暗号化は、プライバシー・リスクを大幅に軽減する手法です。したがって、アプリケーションで処理する個人データを保護するために匿名化や仮名化を適用できない場合には、データ暗号化の使用を検討してください。ただし個人データを暗号化する場合、鍵管理のオーバーヘッドが生じるだけでなく、開発者が個人データの暗号化を設計して実装する前に、考えられるセキュリティー上の弱点を評価しなければなりません。

GDPR では明示的に個人データの暗号化を要件としていないにせよ、第 6 条、第 32 条、第 34 条、備考 83 では、暗号化の使用について言及しています。第 34 条によると、アプリケーション・データが暗号化されている場合、そのデータが失われるか盗まれたとしても、それを復号する手段 (秘密鍵) がなければ、データ損失はユーザー (データ主体) にとって大きなリスクにならないはずであり、そのようなインシデントは報告する必要がないとあります。つまり、暗号化された個人データは、それを復号する手段がなければ、個人データとは見なされません。

第 6 条 (4) - 個人データを取り扱う目的が、データ主体の同意に基づいていない、そのデータが収集された目的とは異なる場合、または第 23 条 (1) で定める目的を達成するために民主主義社会において必要な、かつリスクに見合った措置からなる、EU 法または加盟国の国内法に基づいていない場合、管理者は、目的外の処理が個人データの当初の収集目的と合致することを確実にするために、特に次に挙げる項目を考慮しなければならないものとする。(e) 暗号化または仮名化を含む、適切な保護措置の存在。

第 32 条 (1) - 管理者および処理者はセキュリティー・レベルがリスクに見合ったものになるよう、適切な技術的および組織的対策を実施しなければならない。こうした対策には、必要に応じて、特に (a) 個人データの仮名化および暗号化を含むものとする。

備考 82 (1) - 個人データ侵害が自然人の権利および自由に対して高リスクを引き起こし得る場合、管理者は、不当な遅滞なしにデータ主体に個人データ侵害について通知するものとする。(3) - 次のいずれかの状況に合致する場合、第 1 項で定めるデータ主体への通知は要件とされないものとする。(a) 管理者が適切な技術的および組織的保護対策を講じており、当該対策が個人データ侵害によって影響を受ける個人データに適用されていた場合。特に、当該個人データにアクセスが許可されていないあらゆる人に対して個人データが判読できないようにする、暗号化などの対策が講じられている場合。

第 34 条 - セキュリティーを確保し、この備考に違反する個人データの取り扱いを防ぐために、管理者または処理者は個人データの取り扱いに内在するリスクを評価し、それらのリスクを軽減する特に暗号化などの対策を実装する必要がある。

暗号化の概要

データ暗号化では数学的暗号アルゴリズムを適用し、秘密鍵のコードを使って個人データを「プレーン・テキスト」から「暗号文」に変換します。秘密鍵を知らなければ、逆の暗号化プロセスを適用してこの暗号文を解読することはできません (図 7 を参照)。最近の暗号アルゴリズムは攻撃される恐れがないと考えられていますが、暗号化ではシークレットまたは秘密鍵がアキレス腱となります。攻撃者が不正に秘密鍵を入手したとすれば、データを復号することが可能になります。

図 7. 対称暗号方式
対称暗号方式
対称暗号方式

個人データを暗号化するためにアプリケーションによって利用できるソフトウェアおよびハードウェアのソリューションは多岐にわたります。暗号化をアプリケーションで完全に管理することも、データベース・サーバーで直接実行することもできます。あるいは、ハードウェア・セキュリティー・モジュール (HSM) と呼ばれる専用の暗号化管理デバイスを利用するという手もあります。データベース暗号化に加え、ファイル・システムを暗号化して、アプリケーション・サーバーの一時ファイル、監査ログ、データ・バックアップに含まれる個人データを保護することもできます。

暗号化方式

大きく分けて、暗号化方式には対称鍵暗号方式と非対称鍵暗号方式の 2 つがあります。対称鍵暗号化では、例えば AES-256 などの秘密鍵だけを使用します。非対称鍵暗号化では、共有される公開鍵と秘密鍵の両方を使用して、信頼されていない接続経由でも、デジタル証明書や RSA アルゴリズムを使って暗号化したデータを二者間で送信できるようにします。アプリケーションでの個人データの暗号化には、一般に対称鍵暗号化方式が使用されます。対称鍵暗号化方式では、秘密鍵のみを保護してセキュアに管理することが要件となるためです。

秘密鍵の管理

データ暗号化を使用する予定のアプリケーションの設計には、暗号化の秘密鍵を管理する上で、以下のプロセスを考慮に入れなければなりません。このことは、サード・パーティーに依存して暗号化を実行または管理するアプリケーションにも当てはまります。

  • 鍵の生成: 新しく作成する秘密鍵は、ランダムに生成する必要があります。秘密鍵の作成を、パスワードやパスフレーズの作成と混同しないでください。暗号鍵は、通常は 128 ビット以上の長さであり、乱数ジェネレーターや疑似乱数ジェネレーターを使用して生成しなければなりません。こうすることにより、完全にランダムな形で秘密鍵が生成されて、鍵が推測されたりリバース・エンジニアリングされたりするリスクが軽減されます。
  • 鍵の保管: 秘密鍵は常にセキュアに保管および保持する必要があります。アプリケーションで個人データを暗号化および復号するために秘密鍵を使用するときも、その例外ではありません。
    • 秘密鍵をアプリケーションに「ハードコーディング」すること、つまりアプリケーション・コード内に秘密鍵を組み込むことは、絶対に避けなければなりません。秘密鍵のハードコーディングは、暗号化が解読される可能性を著しく高めることになるためです。暗号鍵をハッシュ化またはエンコーディングして、暗号鍵の値をコード内に隠蔽することも禁物です。
    • アプリケーションが暗号化や復号のために秘密鍵にアクセスして、たとえ一時的にでも秘密鍵を保管しなければならない場合は、暗号化が解読されるリスクが大いに生じます。そのような場合のソリューションは、秘密鍵自体も暗号化することです。秘密鍵を暗号化するには、鍵暗号化鍵 (KEK) を使用できます。このプロセスは一般に、HSM などのアプリケーション外部のコンポーネントによってサポートされます。KEK には、少なくとも個人データの暗号化と同等の強度が必要なことに注意してください。それだけの強度がなければ、個人データ暗号化の強度は KEK の強度と同程度であると見なされることになります。
    • 別の暗号化プロセスによって保護された、セキュアなパスワード・ボールトに秘密鍵を格納して、そこから鍵を呼び出すことも可能です。
    • 秘密鍵を保管する場所は、できるだけ少なくしてください。
  • 鍵の配布: アプリケーションとの間で秘密鍵を受け渡しする際は、セキュリティーが確保された方法で暗号鍵を送信する必要があります。秘密鍵にアクセスできるかどうかを、「知る必要性」を基準として厳重に制御し、それに従って、不必要には鍵にアクセスできないようにします。
  • 鍵の変更/ローテーション (暗号期間): 対称暗号方式でベスト・プラクティスとなっているのは、秘密鍵を定期的に変更することです。こうすれば、攻撃者にとって秘密鍵の価値が下がります。暗号期間と呼ばれる、秘密鍵の変更が必要になるまでの期間は、リスクに応じて設定する必要があります。1 年に少なくとも 2 回は鍵を変更することが、機密データを保護する際のベスト・プラクティスと見なされています。固有の暗号化を管理するアプリケーションには、管理者が定期的に秘密鍵を変更するために使用できる機能を組み込まなければなりません
  • 鍵の削除: 使用されなくなったか不要になった秘密鍵は、暗号化された古いバージョンの個人データを復号するために使われないよう、削除する必要があります。古くなったバックアップや、いつの間にか失われたか侵害されたままになっているデータ・セットに、暗号化された古いバージョンの個人データが存在する可能性があるためです。

GDPR のアプリケーション・セキュリティーの要件

GDPR では具体的に説明された IT セキュリティーまたはアプリケーション・セキュリティーに管理に関する要件を規定していませんが、第 32 条で、「適切なレベルの情報セキュリティーを適用すること」が規定されています。アプリケーションに適切なレベルのセキュリティーを決定するには、業界でのセキュリティーのベスト・プラクティスに従うとともに、リスク評価手法を採用することになります。後者については、この GDPRガイダンス・シリーズの第 2 回で詳しく説明するデータ保護影響評価で取り上げられています。

第 32 条 (1) - 到達水準、実装のコストと性質、適用範囲、処理のコンテキストおよび目的、並びに処理によって引き起こされる自然人の権利および自由に対するリスクを考慮して、管理者および処理者はリスクに見合った適切なレベルの技術的および組織的保護対策を実施するものとする。特に、必要に応じて以下の手法を適用するものとする。
(a) 個人データの仮名化および暗号化
(b) 処理システムおよびサービスの現行の機密性、完全性、可用性、並びに回復力を確保する能力
(c) 物理的または技術的インシデントが発生した場合、時宜を得た方法で可用性を復旧し、個人データにアクセスする能力
(d) 処理のセキュリティーを確保するための技術的および組織的対策の効果を定期的にテスト、審査、および評価するプロセス

アプリケーション・セキュリティーのベスト・プラクティス

第 32 条 (1c) に準拠して、アプリケーションで管理する個人データの機密性、完全性、可用性を確保するには、開発者が業界で認められたアプリケーション・セキュリティーのベスト・プラクティスに従わなければなりません。これらのベスト・プラクティスには、Open Web Application Security Project (OWASP) Top 10 として挙げられている原則に従って開発することも含まれます。

OWASP Top 10 2017:

  1. インジェクション
  2. 認証とセッション管理の不備
  3. 機密データの露出
  4. XML 外部エンティティー (XXE)
  5. アクセス制御の不備
  6. セキュリティー設定のミス
  7. クロスサイト・スクリプティング (XSS)
  8. 安全でないデシリアライズ
  9. 既知の脆弱性を持つコンポーネントの使用
  10. 不充分なロギングとモニタリング

アプリケーション・セキュリティーと OWASP Top 10 の詳細なガイダンスについては、このリンク先の記事「Scan your app to find and fix OWASP Top 10 - 2017 vulnerabilities」を参照してください。

IBM Security AppScan を使用してアプリケーション・セキュリティーの GDPR 準拠を確実にする

第 33 条 (1d) に従って、アプリケーションによって安全に個人データを処理するための技術的対策について、この効果をテスト、審査、評価するには、開発者が SDLC のテスト・フェーズで徹底的なアプリケーション・セキュリティーのテストと脆弱性スキャンを行う必要があります。IBM Security AppScan という Web アプリケーションの脆弱性スキャン・ツールを使用すると、アプリケーション・セキュリティーが OWASP Top 10 と GDPR の両方に準拠していることを確認し、報告することができます。詳しいガイダンスについては、このリンク先の AppScan に関するチュートリアルを参照してください。また、このリンク先のページから IBM Security AppScan の無料トライアルをダウンロードすることもできます。

IoT アプリケーション・セキュリティーの GDPR 準拠

モノのインターネット (IoT) デバイスを管理するために開発されたアプリケーションは、個人データを処理することがよくあります。そのようなアプリケーションは、GDPR 準拠の適用対象となります。IoT アプリケーション開発での詳しいセキュリティー・ガイダンスについては、このリンク先の記事「IoT サイバー攻撃の脅威に立ち向かう」を参照してください。

データ違反の開示

GDPR 第 33 条と第 34 条では、堅牢なアプリケーション・セキュリティーの必要性を強調し、アプリケーションのセキュリティーに問題があることが原因で個人データが侵害された場合、管理者は不当な遅延なく、72 時間以内に監督機関とデータ主体に報告することを義務付けています。

第 33 条 (1) - 個人データの侵害が発生した場合、管理者は、不当な遅滞なしに、可能であれば、侵害に気が付いてから 72 時間以内に、個人データの侵害を監督機関に通知しなければならない。

第 34 条 (1) - 個人データの侵害が自然人の権利および自由に対して高リスクを引き起こし得る場合、管理者は、不当な遅滞なしにデータ主体に個人データ侵害について通知しなければならない。

アプリケーションを開発する組織が管理者の役割を負っていない場合でも、アプリケーションのセキュリティーが不十分なために大規模な、または重大な個人データ侵害が発生した場合、その開発組織に対する世間およびクライアントからの評判が大きく傷付くリスクがあります。

まとめ

アプリケーションのプライバシー・リスクを大幅に軽減し、組織の GDPR 準拠を容易にする技術的ソリューションはさまざまにありますが、このようなソリューションのそれぞれに、セキュリティー上の弱点とトレードオフがあります。したがって、アプリケーションを開発する際は、ソリューション固有の弱点とトレードオフを完全に理解し、考慮する必要があります。例えば、データの匿名化と仮名化にはリバース・エンジニアリングのリスクが伴う一方、データ暗号化では厳重な鍵管理に必要となるプロセスにより、オーバーヘッドが生じます。アプリケーションの設計でプライバシー・リスクを軽減するための対策を決定した後は、その対策を精査して、アプリケーションがデータ保護の水準を満たし、GDPR 監督機関が適切と考えるレベルのプライバシー・リスク保護対策を講じていることを確認してください。

GDPR では IT およびアプリケーションの具体的なセキュリティー要件を規定していませんが、「適切なレベルの情報セキュリティー」を適用することは、この規制での要件となっています。アプリケーション・セキュリティーが不十分だと、大量のデータ漏洩を含め、多大な影響を伴う個人情報の侵害が発生する可能性が高くなります。このことを前提に、実証されたアプリケーション・セキュリティー手法に従ってアプリケーションを開発およびテストすることが、GDPR 準拠のアプリケーション実現に向けたベンチマークとなるはずです。OWASP Top 10 の原則に従ったアプリケーションを開発し、IBM Security AppScan を使用してアプリケーション・セキュリティーの脆弱性をテストすることが、組織の DPR 非準拠のリスクを軽減するだけでなく、さらに重要なことに、アプリケーション・ユーザーのプライバシーを守る上で必須の SDLC 手法となります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=セキュリティ
ArticleID=1062202
ArticleTitle=GDPR 準拠のアプリケーションを開発する, 第 3 回: アプリケーションのプライバシー・リスクを最小限に抑える
publish-date=08092018