2020年6月10日 (水)

ISO/IEC 27701「プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張」の解説

はじめに

 国際規格ISO/IEC 27701Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management(プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張)」が、ISO/IEC 2700127002に対する拡張規格として発行された。27001は情報セキュリティ・マネジメントシステム(ISMS)要求事項の規格であり、ISMS認証の基準となる規格である。27701は、27001への追記事項を記述したものであり、単独で認証基準として使えるものではなく、現状ではISMS認証を受ける中で拡張審査を受けることになる。

 27701の発行前も、個人情報保護に関する国際規格としては、27002の拡張規格として、ISO/IEC 29151(Code of practice for personally identifiable information protection)があるため、これまででも27001+27002+29151で個人情報保護のためのマネジメントシステムを構築することが可能である。ただ、27002の拡張としての29151では、管理策対応だけなので、リスクマネジメントを扱う27001についても、拡張規格が必要ではないか、という議論が行われて開発されたのが27701である。

 277012700127002の両方の拡張となっている。当初は、27002への拡張として既に29151があったので、27001への拡張を別に開発することで、2つに分けて開発することも検討されたが、それぞれの拡張は一体のものであるため、1つの規格として開発された。

 27701の使われ方であるが、27001に基づくISMS認証を取得している組織が、その拡張として27701を追加するというのが自然な使い方だと思われる。なぜなら、ISMS認証を取得していない組織が、27701に対応するためには、27001及び27002に対応することになるため、個人情報とは関係ない情報セキュリティ対策もしなければならなくなるからである。

 ISO/IEC 27701(以下、「27701」)について、以下のとおり解説する。

目次

1. 規格開発の背景と発行までの議論の経緯について

2. 規格のタイトル、全体構造、27001/27002との関係、適用範囲について

3. 27001/27002に関する固有要求事項とガイダンスについて

4. 27002に付加されたPII管理者・PII処理者向けのガイダンスについて

5. 附属書の活用方法について

 

この投稿は、PDFファイルをダウンロードしてご覧いただくことができます。

また、文章の概略を講演した内容を YouTube で閲覧(約15分間)していただくこともできます。

 

 

1. 規格開発の背景と発行までの議論の経緯について

 ISO/IEC JTC1/SC27委員会には5つのWG小委員会があるが、そのWG1小委員会(以下、「WG1」)はISO/IEC 27000ファミリー規格に代表される情報セキュリティ・マネジメントシステム(以下、「ISMS」)などを開発しており、2006年に設立されたWG5小委員会(以下、「WG5」)はアイデンティティ管理、バイオメトリクス、プライバシーに関する規格を開発している。筆者は、2000年からWG1に参加してISO/IEC 27002(以下、「27002」)の開発を担当した後に、WG5設立方針の審議を担当し、設立後はWG5国内小委員会の主査を務めた。

 WG5におけるプライバシー関連の規格は、「ISO/IEC 29100 Privacy framework」(以下、「29100」。)を中心にして開発されている。29110の英語版は無償で公開されており、日本語で読む場合は有償となるが「JIS X 9250プライバシーフレームワーク」としてJIS化されている。

 2020年4月時点で、WG5がプライバシー関連で発行している規格と審議中の規格の一覧を図表1に示した。

Sharedscreenshot1

 

 27701の開発経緯には、「ISO/IEC 29151 Code of practice for personally identifiable information protection」(以下、「29151」。日本語対訳は発行されていない)が関係する。そこで、まず、29151の開発経緯を紹介する。

 WG5では、WG1におけるISMSに相当するプライバシー保護のマネジメントシステムをどのように規定するかの検討が、2011年から始まった。

 その審議の初期において、当時から存在していた日本の「JIS Q 15001個人情報保護マネジメントシステム−要求事項」(以下、「15001」)を参考資料として提供することが国際会議で求められ、英語の仮訳まで準備したが、日本としては、内容が日本固有であり、15001を国際規格化する方向性がないことから提出しないことになった。このため、審議では、15001の規格が参照されることはなかったが、その規格名を英訳したPersonal information protection management systemという言葉だけは残り、その略語であるPIMSが「ピムズ」と呼ばれた。WG5では、個人情報のことを当初は、Personal informationとしていたが、その後、米国で使われていたPII (Personally identifiable information)として定義したため、29151は、もはや、PIMSではなくなっていたが、その後もPIMSが使われ続けた。

 審議はWG1と合同で行われ、新しいマネジメントシステム規格を開発するのか、既存の27001又は27002の拡張とするのかを検討した。情報管理に関するマネジメントシステムは、基本的にISMSに集約し、個別にマネジメントシステム規格を開発しないことが合意され、PIMSは、ISMSの下で構築することになった。次に、27001と27002のどちらか又は両方を拡張するのかが検討されたが、ちょうどその時期にWG1で27002に分野別に追加事項を規定するISMSセクター規格という考え方ができたため、それと同じ位置付けで開発することにして、27002に対する拡張規格として29151を開発することが決まった。そして、2013年に開発が始まり2017年に発行された。

 29151が完成に近づくと、27002の拡張だけではなく、27001への拡張も必要であることがわかり、2017年から新たに審議が行われた。個別のマネジメントシステムを開発しないという方針を維持して、27001に対する拡張規格として27552という規格の開発を始めたが、利用者がより利用しやすくするために、27002に対する拡張も統合して、27001と27002の両方の拡張を27552で規定することになった。27552は、発行の直前で、マネジメントシステムの要求事項規格であることから、規格番号の末尾を01として発行されることになった。それが、27701である。

 

2. 規格のタイトル、全体構造、27001/27002との関係、適用範囲について

 27701のタイトル「Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management」には、privacy information managementとあるが、これは本来正しくない。なぜなら、privacy informationという情報は扱っていないし、規格本文で使ってもいない。保護の対象はPIIであり、本文で使っているPII protection又はprotection of PIIが正しいだろう。しかし、WG5の内部ではPIMSが既に10年間近くも定着してしまっていた。そのため、略語をPIMSになるように合わせるために、Privacy information management systemをPIMSと定義し、そこから切り取られて、タイトルに、privacy information managementという造語ができあがっている。

 もしも、27701のタイトルを見て、「privacy informationって何?」と思われたなら、このような経緯で名付けられただけであり、この規格が何のための拡張であるかを正しく表すならば、PII protection managementであり、ISMSに習うならば、Information privacy managementが正しい。

 27701は、そのタイトルのとおり、27001と27002のそれぞれに対応した拡張規格と関連する附属書から構成されている。(図表2を参照)

Sharedscreenshot2


 27701を理解するためには、引用規格である、27001と27002、29100について理解している必要がある。27701については、本書執筆時点では、JIS化の予定は決まっていないが、日本語対訳書「セキュリティ技術―プライバシー情報マネジメントのためのISO/IEC 27001及びISO/IEC 27002への拡張―要求事項及び指針」が2020年3月25日に出版された。

 27001と27002については、それぞれに対応しているJIS規格解説本によって理解を深めることができる。29100については、JIS X 9250を参照することができる。

 ISMSにおいては、27001でマネジメントシステムを規定し、その附属書Aで管理策を示し、それらの管理策に対応する実施の手引きが27002で規定されている。27001におけるリスクアセスメントの必須事項を27001の附属書Aで規定し、その判断や管理策を採用した場合の手引きとして27002が管理策を補足するという構成になっている。いわば、27001と27002の橋渡しとして、27001の附属書Aは重要な役割を果たしている。

 27701においては、27001の要求事項に対するPIMSの追加事項を箇条5で規定し、27002の実施の手引きに対するPIMSの追加事項を箇条6で規定している。そのため、箇条5は、shall(しなければならない)で書かれ、箇条6は、should(することが望ましい)で書かれた規定が一つの規格内で混在しているのに違和感があるかもしれない。これについては、それぞれ27001と27002の関係に対応しているものと考えればよい。すなわち、27701の箇条5は27001を引用しており、その中で27001附属書Aが参照されることで、27002が紐付けられ、それを拡張した27701の箇条6は、また27001附属書Aから紐付けられているという構造をなしている。したがって、27701の箇条5は、27001の附属書Aを介して、箇条6を従属させている。

 以上に引き続いて、27701では、いわば本体となるPIMS固有の管理目的と管理策を附属書A,Bで規定し、それらのガイダンスを箇条7と箇条8で規定している。

 附属書C、D、Eは、他の規格・規則への対応表を、附属書Fは、27001と27002への適用方法についての参考情報を提供している。

 次に、27701の本文の内容であるが、27701の適用範囲は、図表3のように書かれている。

Sharedscreenshot3
 PIMSという表現については、既に説明したとおりである。ここでは、「privacy managementって何?」と思われるだろうが、この箇所にしか出てこない表現で、規格本文では使われていない。これもPIMSと同じで、PII protection managementと考えればよい。

 

3. 27001/27002に関する固有要求事項とガイダンスについて

 「箇条6 ISO/IEC 27002に関連するPIMS固有の手引」は、「ISO/IEC 27009 Sector-specific application of ISO/IEC 27001」(以下、「27009」)に基づくISMSセクター規格として開発されている。すなわち、27002の構成を引用した上で、PIMS固有の事項がある箇所にだけ、追加や改定(refine)の実施の手引きを規定している。

 「箇条5 ISO/IEC 27001に関連するPIMS固有の要求」は、27000シリーズ規格において、27001を拡張した初めてのものとなる。規定の方法は、27009に準じるものとして、27002への拡張と同じ体裁を使い、追加や改定事項がある箇所に、追加や改定の要求事項を規定している。

 27001に対する固有要求事項で、最初に必要なことは、PIMSをISMSに組み込むことである。

 箇条5と箇条6は、27001の附属書Aを介して紐付けられていることを前節で説明したが、それだけでは、認証規格である27001から見ると、情報セキュリティマネジメントの範囲を超えることができないため、27701の5.1 Generalにおいて、図表4のように規定している。

Sharedscreenshot4
 そして、5.1にあるとおり、附属書Fにおいて、図表5のような読み替え表を示している。

Sharedscreenshot5

 

 つまり、27001におけるinformation securityをすべて、information security and privacyと読み替えよという規定である。

 このような読み替えを認証基準規格で行うことは稀であり、これを実際の認証でどのように行うかについては、図表1の「プライバシー関連で規格を開発する投票が行われている案件」にある「Requirements for bodies providing audit and certification of PIMS according to 27701 in combination with 27001」という審議案件で、2020年4月から検討が始まる予定である。基本的には、「ISO/IEC 27006 Requirements for bodies providing audit and certification of ISMS」に組み込むか拡張して対応することが予想される。

 次に必要なことは、PIMS固有の管理策をISMSに従属させることである。

 それをするために、27701の「5.4.1.3 情報セキュリティリスク対応」は、27001の「6.1.3 情報セキュリティリスク対応のc)及びd)」による27001附属書Aを使った管理策の確認について、27701の附属書AとBをそれに加えるように改定している。この改定によって、27701の附属書Aが箇条7を、附属書Bが箇条8を活性化している。

 箇条6における27002の拡張は、基本的に29151による27002の拡張内容を継承し、さらに新たに検討された内容を追加している。

 以上の関係を、図表6に示す。

 

Sharedscreenshot6

 

図6「27701と関連規格の関係」(動画版)

 

 4. 27002に付加されたPII管理者・PII処理者向けのガイダンスについて

  27701の適用範囲には、図表3の文に続いて、図表7のように書かれている。

Sharedscreenshot7


 27701におけるPIMS固有の事項を理解するための基本となるのは、「PII controller(PII管理者)」と「PII processor(PII処理者)」というアクターの区別である。これらは、29100で定義されており、JIS X 9250では図表8のとおりに書かれている。

Sharedscreenshot8

 日本の個人情報保護法であれば、PIIは個人情報に、PII管理者は個人情報取扱事業者に、PII処理者は個人情報取扱事業者からの委託先に、それぞれ概ね対応することになる。

 例えば、A社がセミナー開催にあたって受講者を募集する場合に、受講申込者の氏名や連絡先などの個人情報を取得する場合には、A社が個人情報の利用目的を決定するので、PII管理者となる。この時、受講申し込みを受け付けるために、B社が運営する受講者管理サービスを利用する場合には、B社はA社に代わって個人情報を取得し、A社の指示に従って受講申込者名簿などをA社がアクセスできるように処理するので、PII処理者となる。27701の箇条8は、B社がA社のために取得する個人情報の保護について規定するものとなる。仮に、B社が自社のためのセミナー開催をする場合は、それに関連する個人情報の取扱いについてB社は、PII処理者ではなくPII管理者となる。PII管理者として取り扱う個人情報の保護については、箇条8ではなく、箇条7で規定されている。

 日本の個人情報保護法では、委託先の安全管理措置(情報セキュリティ対策と同義)については、委託元が監督することになっているが、委託先が講じる対策を限定的には定めていない。しかし、上記の例のとおり、B社は、A社との関係においては委託先であるが、B社はもともと個人情報取扱事業者でもあるはずである。なぜなら、B社は、B社自身の利用目的で取り扱う個人情報をA社とは無関係に保有しているはずだからである。そのため、B社において安全管理措置の内容は、もとからあると想定することができる。その上で、A社はB社に対して善管義務を求める(B社自身の個人情報に対する安全管理措置を、A社から委託する個人情報にも準用させる)ことがあり得るが、ISMSの観点からすると、それはA社が管理すべき個人情報をB社のリスクマネジメントに委ねることになってしまう。これらの関係をPII管理者とPII処理者に分けた上で、PII処理者としてなすべきことを箇条7で規定することにより、A社のリスクマネジメントの下で、B社におけるA社の個人情報の保護を求めやすくなる。

 上記の例では、委託先が実施すべき事項を規定すれば、PII処理者としての規定が示されていることと同等の効果があるように思われるかもしれない。しかし、このことは実施すべき事項を怠ることがないようにする対策として有効であるが、実施してはいけないこと又は実施することを予見できなかったことが実施されてしまうことを防ぐ対策として違いが出てくる。

 例えば、B社がA社のセミナー受講者に、B社のセミナー案内を配信してしまうということを考えてみる。この場合、A社がその禁止を業務委託契約で明記していればB社が契約に違反したことは明白である。それに加えて、PII処理者が、そのような違反をすることは、PIIを処理するための目的及び手段をB社が決定したことになり、B社は、直ちにPII管理者の立場になる。その結果、利用目的について事前の同意を得ることになっていれば、B社はPII管理者としての義務を怠ったことになる。つまり、事業者はPII管理者の立場かPII処理者の立場かが区別されて順守事項が定められているために、PII処理者がPII管理者の立場のことをした場合には、直ちにPII管理者としての義務が発生する。

 一方で、日本の場合には、委託によるものか否かという違いにしているため、上記のような違反は日本においても委託先は個人情報取扱事業者としての義務を負うことになるが、現状の日本法では、利用目的は通知だけで同意を求めておらず、さらに直接取得の場合の通知には公表を含んでいることから、仮に利用目的が公表されていれば、違法になるとは言い切れない。もちろん、そのようなことを契約で禁止していれば契約違反であるが、個人情報保護法違反になるとは限らないということである。

 つまり、A社とB社の義務を日本では、委託の範囲とその条件は何であったかという2社間の関係性で整理するしかないが、29100の下では、事業者が個人情報をどの立場で取り扱うかによって明確に区別しているために、関係性とは独立しても各社の義務が定まる点が異なる。

 以上のように、PII管理者とPII処理者を区別した上で、PII管理者を対象に附属書Aと箇条7で規定し、PII処理者を対象に附属書Bと箇条8で規定している。

 

5. 附属書の活用方法について

 附属書A及びBは、それぞれ、箇条7及び箇条8に対応するものである。

 附属書C「ISO/IEC 29100への対応付け」は、WG5におけるプライバシー関連規格の中心となる29100との対応について示しており、図表9はその一部である。

Sharedscreenshot9

 

 WG5では、図表1に示したとおり、様々なプライバシー関連規格を議論しているが、27701によってPIMSを構築する際に、どのような関連規格が役に立つかを知ることができる。

 附属書E「ISO/IEC 27018及びISO/IEC 29151への対応付け」は、既に発行している規格の要求事項との対応を示している。29151については、本来、27701の箇条6のうちPII管理者への規定と同様の内容であるべきもので、今後の改訂によって整合がとられる予定である。「ISO/IEC 27018 Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors」(日本語対訳は発行されていない)は、「PII処理者としてパブリッククラウド内のPIIを保護するための実践の規範」であり、タイトルにあるとおり、パブリッククラウドにおいて、PII処理者としての役割に絞って規定している。

 附属書F「ISO/IEC 27701をISO/IEC 27001及びISO/IEC 27002に適用する方法」は、先述したとおり、5.1 GeneralによるISMSをPIMSに拡張するための包括的な読み替えのための表などを示している。

 特筆すべきは、附属書D「一般データ保護規則への対応付け」である。これは、EUのGDPR(一般データ保護規則)への対応を示したものであり、図表10はその一部である。

Sharedscreenshot10

 
 国際規格において、特定の国や地域の法令を具体的に引用することは稀であるが、GDPRはEU以外の他国にも適用を求めているため、国際的に順守する必要がある場合があることから、その対応表が作成された。

 このような対応表は、自分でも作成することができるが、附属書Dの作成においては、EU規制当局の作業部会がWG5のリエゾンとしてレビューしているため、公式に認められるものではないもののEUのお墨付きがあると言えるものであり、紐付け及び網羅性の観点で、組織がGDPRに対応する取組みをする時に有用なものである。

 また、27701の規格本文では、「in some jurisdictions(法域によっては)」という但し書に続けて、法令による要求事項に触れている箇所がある。これらは、GDPRに対する網羅性を高めるためのものであり、いわば、GDPRのマーカーのようになっている。組織が27701に準拠する時に、これらのマーカーをたどることによって、GDPRへの対応に役立てることができる。

 

謝辞

 本稿は「月刊誌アイソス 2020年05月号 特集 プライバシー保護の国際規格 ISO/IEC 27701」に寄稿したものを書き改めたものです。株式会社システム規格社の中尾優作様による丁寧な編集と校正に感謝いたします。

  執筆担当箇所の抜き刷りはこちらからダウンロードできます。

 ISO/IEC 27001に関する表現については、一般財団法人日本情報経済社会推進協会(JIPDEC)の畔津布岐様によるご指導に感謝いたします。

6月 10, 2020 | | コメント (0)

2005年4月21日 (木)

ディスク修理・廃棄時の機密保護

機密データの入ったディスクを修理や廃棄する際のセキュリティ対策について、まちがった慣行が日本にはある。
それは、交換パーツや廃棄パーツとして持ち帰るデータの消去について、修理などをするベンダーにだけ頼ろうとすることだ。

 

 

そもそも、多くのベンダーは、保守契約のサービスメニューの中で、交換修理と買取修理を設けている。
交換修理は、壊れた部品や装置を、正常なものに交換して、もともと使われていたものは、ベンダーが持ち帰るものだ。通常は再利用することで、修理のコストの軽減に利用する。
買取修理とは、部品交換などは、行なわず、もともと使われていたものは、ベンダーは引き取らずに使用者のもとに置き去る。
一般的に、交換修理よりも買取修理の方が価格が高いことが多い。

 

日本では、この交換修理において、持ち帰ったディスク内の機密データを完全消去することの徹底を、保守契約の発注者がベンダーに対して求めようとする。

 

そもそも、保守契約の発注者は、機密データの格納されているディスク装置については、交換修理の保守契約を禁止するような、システム・セキュリティポリシーを制定していなければおかしい。
もしも、費用の軽減が目的で、交換修理を選択したいのであれば、システムのアプリケーションなどの設計において、ディスク内のデータが暗号化されるようにするなどして、ディスクが交換修理で持ち出されても、情報にはアクセスできないようにすべきである。
多くのコンピューターベンダーにおいては、そのようなディスク内の暗号化に CPU の負荷がかからないようにするための、ディスク・バスに直結する暗号化アクセラレータカードなども提供している。

 

保守契約の発注者が;

 

・買取修理の費用を惜しむ
・アプリケーションレベルでの暗号化開発費用を惜しむ
・暗号化カードの購入費用を惜しむ

 

という身勝手な状況において、ディスク内に機密情報を保護されない状態で蓄積し、そのディスクを修理するときの、セキュリティ対策をすべてベンダーに、交換修理という安易な契約のもとで要求するのは、無責任としかいいようがない。

 

このとき、日本では不思議なことが起こっている。

 

・無償で消去に責任を持ちます。という無責任なことをベンダーが約束する。
・ベンダーに責任を押し付けたから、自分に責任はなくなったと、保守契約の発注者が思っている。

 

ベンダーとしては、データ消去に「努める」ことを無償で実施するのは、ビジネスの差別化として前向きなことだろう。ただし、そのことが、ディスク修理時の機密情報の漏えい防止に責任を持っていることでないのは確かだ。
あくまでも、「データの消去」という作業の実施に責任を持っただけだ。
ディスク修理時の漏えいは、「データの消去」が徹底されれば完全に防げるものではないことは、考えればすぐにわかることだ。
ベンダーが何を約束したとしても、事故が起きたときには、一次的な責任は、保守契約の発注者になるのは当然である。
もちろん、「無責任に約束するベンダー」と付き合っていれば、その損害を補償してもらえるかもしれない。

 

保守契約の発注者が、「自社の機密情報」をそのように無責任に管理するのは、その企業の自由だ。

 

しかし、それと同じポリシーによって、お客様の個人情報など人様から預かっている機密情報を管理するとしたら、大きな間違えだ。
データを暗号化などせず交換修理にして、ベンダーにだけ契約条件として、データ消去を義務付けて損害リスクを転嫁するだけのような企業や組織に、個人情報を預かる資格はない。
そのことの認識が、多くの日本の企業や組織において不足している。

 

個人情報は、企業や組織における機密情報のうち、「預かり機密情報」なのだから。

 

4月 21, 2005 | | コメント (0) | トラックバック (0)

2005年1月 5日 (水)

情報戦略の一環として個人情報保護を位置づけよ

あけましておめでとうございます。

その後、ココログ記事の投稿をできておらず、心苦しい限りです。
そんな中、年末に、勤め先の季刊誌で対談をしたものが発刊されていました。



HP Enterprise Magazine [WINTER 2004 No.2]
特集: 待ったなしの情報リスクマネジメントの取り組み
~情報戦略の一環として個人情報保護を位置づけよ

2005年4月の個人情報保護法施行を目前に控え、企業の情報リスクマネジメントに対する意識が問われる今、トップマネジメントが真剣に取り組むべき経営課題=情報リスクマネジメントの現状について、3人の専門家が語る。

以下のページから PDF でダウンロードできますので、よろしければ参照ください。

http://h50146.www5.hp.com/enterprise/magazine/index.html

昨年中に発刊に気づいて紹介していれば、アンケートに答えて、iPAQ などが抽選でもらえたようなのですが、すでに申し込み期限をすぎてます。すみません。

この中でも、預かり機密情報についてふれているのですが、この対談内容について、ココログ記事を書いてみようかなと思います。

※上記リンクがアクセスできない場合は、http://www.hp.com/jp/enterprise のページの左側にある「法人向け情報誌」というリンクにアクセスしてください。

1月 5, 2005 | | コメント (0) | トラックバック (0)

2004年12月18日 (土)

機密情報とは

ここでは企業における機密情報について、自社機密情報と預かり機密情報という2種類に分けて考えてみる。

自社機密情報とは、自社が著作権を持っているような、自らの情報である。たとえば、製品の設計図や、コストの原価表、営業戦略の内容などで非公開としているものなどである。
預かり機密情報とは、自社ではない誰か、たとえば、お客様や取引先から秘密保持契約などを締結して預かっている情報である。

どちらも、機密として扱わなければならないが、いろいろな面でこれら2つは異なる。

コントロール権

自社機密情報は、どの程度の機密度合いかは、自社で決めてよいものである。
機密度合いを会社の都合で途中で変更することもできる。
たとえば、製品の設計図が極秘だとしても、その設計図を高額で買いたいという取引先が現れれば、その会社にそれを売るということもあるし、同様の要求が多ければ、そもそも機密をやめてその内容を商品にしてしまうこともできる。
つまり、自社のビジネスの要求によって、その機密性は自社でコントロールすることができる。

その点において、預かり機密情報は、その情報の持ち主が指定したとおりの機密度合いを守りぬかなければならない。
その情報をいくら高く買いたいという人が現れても、それらを勝手に売ることはできないのは当然である。
自社のビジネスの都合では、最初に指定された保護策を持ち主の了解もなく変えることはできない。
自社にコントロール権はなく、預け主にコントロール権がある。

推察可能性

会社の外からこれら2つを考えるのもおもしろい。

自社機密情報については、どんなものをその会社が持っているのかは、概ね察しがつく。
ものによっては、社内のどの部署にそれがあるかも想像ができる。

それに対して、預かり機密情報は、どんなものを持っているのかが、外からではわかりにくい。
業種、業態などにより、その取引先がわかっている場合には、少しは想像することができることもある。

人への依存性

企業にとって、自社機密情報と預かり機密情報は、どちらも漏洩などがないように管理しなければならない。
それらへの保護策はどちらも共通のルールが設けられるだろう。
ただ、自社機密情報に比べると、預かり機密情報は、それを知る必要性のある人達に管理が任されることも多いと思われる。
逆に、預かり機密情報は、特定の秘密保持契約などで預かっているわけであるから、もともと関係者は少ない。
さらに、そのような預かり機密情報の存在自体を、関係者以外に教える必要もない。
存在自体を秘密にしておいた方が安全かもしれない。
また、何らかの業務の必要で預かっているわけであるから、その業務に適した保護策にした方がよいので、その管理がそれを取り扱う関係者に委ねられるのは自然なこととも言える。

情報漏洩の動機

機密情報の狙われやすさについても考えてみる。
それは、盗む動機を考えるということになる。

自社機密情報は、意外と本当は秘密ではなかったりする。
単に、よそ様に見られると恥ずかしいので機密にしよう。ということはよくあることだ。
もちろん、製造業などの設計図面など、それが漏れるとビジネスに被害が出るような本当の秘密もある。
そういう場合も、その設計図面が競合の会社に見られたら、模倣品を作られたりして初めてビジネスの被害になる。
そのとき、競合会社がそれを直接盗みにくるということは考えにくい。
誰か悪い人が情報を盗み出して、買いそうな企業を探して、売りつけるという構図が思い浮かぶ。
そういう場合に、その情報は狙われることになるのだろう。
悪い人とは、社内で悪いことを思いついた人であるかもしれないし、社外の悪い稼業の人かもしれない。あるいは、社外の悪い稼業の人に誘惑されて社内の人が共謀するかもしれない。

預かり機密情報についてはどうだろうか。
そもそも、外からは、その存在そのものについての推察可能性が低いため、狙われて盗まれるということは低いかもしれない。
狙われるとすると、その情報の持ち主が狙われていて、それを預かっていることが何らかの理由で知られたときに、持ち主から盗むのではなくて、預かっている企業から盗もうとするかもしれない。
内部の関係者はどうだろうか。かれらは、当事者であるのでその存在を知っている。その情報が価値あるものだとも知っている。
しかし、関係者の人数が少なければ、情報の漏洩が発生した場合に、疑われやすい立場にいるので、そうしょっちゅうそのような漏洩には至らないのかもしれない。

自社機密情報、預かり機密情報とも、その情報を対価を得て入手したいと思う相手は限られている。
一般の誰にでも売りつけやすいものではなさそうだ。
仮に、外部の悪い人が、多くの情報にアクセスできる状態になったとしても、その中でどれが売れそうな機密情報かを見分けることも大変そうである。

そんなことから、関係者による漏洩の方が多く発生するのだろう。
ただ、漏洩の流れ全体を見れば、外部の悪い人に入れ知恵されて、悪い行為になるのだろう。

外部の悪い人が悪いことを考えて、内部の者に実際の悪いことをさせる。という組み合わせなのだろう。

これまで、預かり機密情報に対する企業の対策は、いささか具体性を欠いていたり、明確ではなかったりしたかもしれない。
だからといって、頻繁に問題が起きているということもなさそうである。
おそらく、以下の点で、狙われにくいものだったようにも思う。
・何を持ってるかわかりにくい
・情報を見つけ出しにくい
・関係者が限られている

しかし、逆に言うと、上記のような狙われにくい条件に該当しない、預かり情報があったとしたら、いままでのようなことでは済まされなくなることが予想される。

結論は特にないまま、今回は、これでおしまい。
とりあえず、考えてみただけなので。。

12月 18, 2004 | | コメント (0) | トラックバック (1)