GDPR
IBMセキュリティーが開発したGDPRフレームワークとは?
2018-03-14
カテゴリー GDPR
記事をシェアする:
何故、シンプルに設計することがそれほど難しいのか
以前のブログ記事で、Adam Nelson氏と筆者は、皆様自身が組織の他のメンバーと共に、EU一般データ保護規則(GDPR)とその要件を理解する必要性を述べました。まだ未着手であるとしても遅くはありませんが、いずれにせよ、GDPRの要件がかなり複雑になる可能性があることはすでに理解されていると思います。
昨年、読者の皆様がGDPRの本質を理解するのを支援する方法を模索していたころは、筆者も同様の状況でした。正直、261ページに及ぶ規則を繰り返し読み、膨大な法律文書を調べてわかったのは、規則の複雑さです。
何かをシンプルにつくるということが、極めて難しい試みになるのはよくあることで、目新しい話ではありません。500年以上前にも、レオナルド・ダ・ヴィンチが、「シンプルこそ究極の洗練である」と述べたと言い伝えられています。
規則には、それに取り掛かろうとする者にとって参考となる情報は書かれているものの、その実行方法については教えてくれません。そこで、筆者はまず下調べから始め、多くの同僚に相談しました。報告書を読み、ユース・ケースを調査し、アイデアを出し合い、お互いに議論を重ねました(少しだけですが)。
その時点から、何をつくるにしても、「シンプルでなければならない」という考えを持ち続けてきました。つまり、誰も理解できないような複雑な多次元マトリックスや巨大な参照アーキテクチャー図を作ってはならないということです。結局、GDPRに対応するために実行すべきことや購入すべきもののリストはないということで、意見が一致しました。GDPRに、単一の製品で対応することが不可能だったためです。
GDPR対応プロセスのためのシンプルなフレームワーク
むしろ、物事をシンプルに保つという考えに立ち戻り、その考えを何度も練りました。十数回以上も繰り返した結果、ついにプライバシーとセキュリティーの両方に対応した5段階のフレームワークの開発に至ります。同時に、GDPRに対する組織の取り組みを1つのプロセスと捉え、GDPRへの対応度評価のチェックリストとはしない、という判断も下しました。さらに、これをIBMだけの限定したものにはしたくないとも考えました。
では、どこから始めるか。 これは何度も自問した問いかけです。まず決めたことは、このフレームワークの5段階それぞれが、プライバシー問題とセキュリティー問題の両方に対処する必要があるということでした。GDPRが、組織にその両方の保証を義務づけているためです。まさにそこが、事態を複雑にしているのです。プライバシーとセキュリティーは、区別が非常に難しいためです。
そこで、どのように区別するのか、定義を明確にする必要がありました。結果は次のとおりです。プライバシーで重要なのは、どんなデータを収集して、何のために管理、共有、処理、移転を行うのかを決めることです。また、セキュリティーで重要なのは、データの管理および保護の方法です。別の見方をすれば、プライバシーのないセキュリティーはありえますが、セキュリティーのないプライバシーはありえません。
IBM GDPRセキュリティー・フレームワークの5つの段階を見れば、すべての要素がどのように組み合わさっているかが簡単に分かります。とは言え、何をいつ、どこから行うかについて多くの議論があったことは間違いありません。そこで、論理的な解釈で「始め」とされるところからスタートしました。
IBMセキュリティーGDPRフレームワーク:GDPR対応の重要なアクティビティー
プライバシー要件 | セキュリティー要件 | |
---|---|---|
評価 | 準備:
調査:
|
準備:
調査:
|
設計 | ロードマップ:
プライバシー・バイ・ デザイン:
|
ロードマップ:
プライバシー・バイ・ デザイン:
|
変革 | プロセスの変革:
|
保護:
|
運用 | GDPRプログラムの管理:
サービスの実行:
|
セキュリティー・プログラムの管理:
サービスの実行:
|
適合 | 実証:
対応:
|
実証:
対応:
|
第1段階では、状況把握に努めます。収集、保存しているデータのうち、どの部分がGDPR規則の適用を受けるかを見極め、そのデータが社内のどこにあるのかを特定する道筋をつけます。
第2段階は、自社の対策を設計する場です。データの収集、利用、保管のしっかりした計画を立てる必要があります。さらに、リスクと事業目標とのバランスを取るアーキテクチャーや戦略を策定する必要があります。
第3段階の目標は、組織を変革することです。つまり、組織にとって重要だと判断されたデータは、そのデータが示す人にとっても等しく重要であることを理解することです。持続可能なプライバシー・コンプライアンス・プログラムの作成、セキュリティー制御とガバナンス統制(TOMs-技術的かつ組織的対策)の導入、場合によってはデータ保護責任者の任命が必要になるのは、まさにこの段階です。
第4段階に到達するまでに、プログラムを運用する準備はできています。継続的にデータを検査し、個人データへのアクセスを監視して、セキュリティーをテストし、プライバシー・バイ・デザインとセキュリティー・バイ・デザインの原則に則り、不要なデータを一掃するようになっています。
第5段階、最終段階は必要なGDPR要件に準拠する準備が整った段階です。 データ主体のアクセス、訂正、削除、移転要求を満たし、アクティビティーを文書化することで監査にも対応できるようになり、情報漏洩が発生した場合の監査機関やデータ主体への通報体制も整っています。
GDPR対応への具体的な取り組み
基本のフレームワークを作成した後も適用と拡張を続け、IBMとしてのGDPRフレームワークが構築されました。その過程で、さらに詳細な機能が追加されました。例えば、情報ガバナンスを含む簡素化された機能体系や組織全体で取り組みを開始できるような、さまざまな道筋が加わりました。
さて、いよいよGDPR対応への取り組み開始です。プロセス自体は、必ずしも簡単ではないかも知れませんが、道筋は明確にしなければなりません。確かに、5つの段階それぞれで対処すべきことが非常に多くあります。途中で支援も必要でしょう。そこで、IBMの出番です。IBMセキュリティーがGDPR対応のプロセスを進めるうえで、どのようなサポートができるかの詳細はこちらをご覧ください。
注意: GDPRを含むさまざまな法律や規制に確実に準拠することはお客様の責任です。IBMが法律上のアドバイスを提供することはありません。また、IBMのサービスや製品を利用することで、お客様が何らかの法律や規制に確実に準拠するようになることを表明または保証するものでもありません。お客様のコンプライアンス・プロセスをサポートするIBM独自のGDPR対応プロセス、GDPR機能およびサービスについて詳しくは、こちらをご覧ください。
大規模言語モデル(LLM)の隠れたリスク:催眠術をかけられたAIの実状
この記事は英語版 Security Intelligenceブログ「Unmasking hypnotized AI: The hidden risks of large language models」(2023年8月8 […]
AIと人間の不正搾取対決:新時代のフィッシングの手口を解明する
※この記事は、IBM X-Force Redに所属するエシカル・ハッカーのStephanie Carruthersにより執筆された文章を翻訳しています。 攻撃者の技術革新は、テクノロジーの発展とほぼ同じスピ […]
IBM Security Trusteer Rapport (ラポート)のダウンロードおよび購入を騙る不審サイトにご注意ください
架空の団体から贈与金を受け取れる等のフィッシング・メールが届き、メール本文に記載されたリンクをクリックすると不正サイトへ誘導され、金銭を安全に受け取るためと称して IBM Security Trusteer Rappor […]