メールで個人識別情報（PII）を送信する際のセキュリティとコンプライアンスの考慮事項

お客様、請負業者、その他の個人からメールで個人識別情報（PII）を受け取る場合、高額な罰金を回避するために厳格な規制を遵守する必要があります。

PIIをメールで送信しても安全でしょうか？いいえ、PIIをメールで送信するべきではありません。ただし、どうしてもメールでPIIを送信する必要がある場合は、暗号化が必須であり、傍受された場合でもPIIが判読できないよう、特定のセキュリティプロトコルを満たす必要があります。

個人識別情報（PII）とは？

簡単に言えば、個人識別情報（PII）とは、他者の身元を直接または間接的に「推測」できる情報を指します。この場合の「推測」とは、誰かの身元を特定できるあらゆるものを意味します。

一見自明に思えますが、米国においてPIIの定義はあいまいです。そのため、何がPIIに該当し、何が該当しないのかを区別するのは難しい場合があります。特に、機密情報の開示の意味が状況によって変わる場合はなおさらです。

個人識別情報（PII）と保護対象保健情報（PHI）の違いは？

個人識別情報および保護対象保健情報（PII/PHI）はどちらも機密性の高いデータですが、その範囲、文脈、規制要件が異なります。

PIIは、単独または他のデータと組み合わせることで個人を特定できるあらゆる情報を指します。これには氏名、社会保障番号、住所、電話番号、メールアドレスなどが含まれます。PIIは業界や地域ごとに異なるプライバシー法（GDPR、CCPA、FISMAなど）で規制されています。

一方、PHIはPIIのうち個人の健康に関する情報に特化したサブセットです。医療記録、診断、治療情報、保険情報、健康状態やケアに紐づくあらゆるデータが含まれます。PHIは米国の医療保険の相互運用性と説明責任に関する法律（HIPAA）の下で厳格に規制されており、対象となるのはカバードエンティティ（医療提供者、保険会社など）やそのビジネスアソシエイトが取り扱う場合のみです。

主な違い：すべてのPHIはPIIですが、すべてのPIIがPHIとは限りません。PHIは健康関連データを含み、かつカバードエンティティによって作成・受領・管理されている必要があります。

この違いを理解することは、特に医療など規制業界で適切なプライバシー管理を適用する上で非常に重要です。

NIST SP 800-122によるPIIの分類ガイドライン

米国国立標準技術研究所（NIST）は、PIIを「リンク型」と「非リンク型」の2つに分類しています。リンク型情報は、誰かの身元を直接特定できる情報です。このカテゴリのPII例は以下の通りです：

• 氏名
• 自宅住所
• 勤務先住所
• 社会保障番号（SSN）
• 電話番号（勤務先、自宅、携帯）
• 個人所有物に関する情報（車両識別番号など）
• 生年月日
• クレジットカード番号やデビットカード番号
• メールアドレス
• IT関連情報（デバイス固有のMACアドレス、IPアドレス、シリアル番号など）

非リンク型情報は、外部者が2つ以上の情報を組み合わせて初めて個人を特定できるような、より間接的な情報です。非リンク型情報には以下が含まれます：

• 一般的な氏名
• 人種や性別のカテゴリ
• 年齢
• 職種
• 広範な住所情報（市区町村、州、国、郵便番号など）

非リンク型PIIはリンク型PIIより「安全」に見えるかもしれませんが、どの組み合わせが偶発的に身元を明かしてしまうかは分かりません。そのため、ビジネスケースごとにデータを保護するためのプラットフォーム、ツール、プロセスの活用が重要です。

このように、PIIは各種データプライバシー規制ごとに定義や取り扱いがやや異なります：

• 医療保険の相互運用性と説明責任に関する法律（HIPAA）では、PIIは保護対象保健情報（PHI）として理解されます。HIPAAのプライバシールールでは、患者の健康、医療・治療、請求や支払いに関するあらゆる情報がPHIと定義されています。
• ペイメントカード業界データセキュリティ基準（PCI DSS）では、カード決済データが重視されるため、メールで送信されるPIIは、クレジットカード番号や、顧客を特定できる氏名、住所、電話番号、メールアドレスの組み合わせを指すことがほとんどです。
• FedRAMPは、FedRAMP Low authorization、FedRAMP Moderate authorization、FedRAMP High authorizationの3つのインパクトレベルに分かれています。PIIの種類もレベルによって異なります。たとえば、FedRAMP Low Impactシステムにはログイン認証情報（ユーザー名とパスワード）以外のPIIが含まれない場合がありますが、FedRAMP High ImpactシステムではPHIのようなデータも扱うことがあります。ただし、FedRAMPでは暗号化されていない限り、PIIのメール送信は禁止されています。

機微PIIと非機微PIIの分類

機微PIIと非機微PIIの違いを理解することは、適切なデータ取扱いやリスク管理のために極めて重要です。

機微PIIとは、紛失、漏洩、無断開示された場合に、個人に重大な損害、恥、不便、不公平をもたらす可能性のある情報です。例としては、金融口座番号、社会保障番号、生体情報、医療情報、運転免許証番号などが挙げられます。この種のPIIは、GDPRの「特別なカテゴリの個人データ」（人種、宗教、健康データなど）のように、特定の規制による保護対象となることが多いです。

そのため、機微PIIの取り扱いには、保存中および転送中の強力な暗号化、厳格なアクセス制御、包括的な監査ログ、データマスキングやトークナイゼーションなど、厳重なセキュリティ対策が求められます。

一方、非機微PIIは、個人を特定できる可能性はあるものの、一般的に公開されている情報や、開示されても大きな損害をもたらさない情報です。例としては、郵便番号、公表された電話番号、一般的な職種などがあります。非機微PIIも保護は必要ですが、機微PIIほど厳格な対策は求められない場合が多いです。ただし、複数の非機微情報を組み合わせることでリスクが高まる場合もあるため、慎重な評価が必要です。

組織内のPIIを特定する方法

組織内のどこに個人識別情報（PII）が存在するかを特定することは、データプライバシー管理、規制遵守、リスク低減のための重要な第一歩です。以下のチェックリストは、システムや業務プロセス全体でPIIを発見・分類・文書化するための体系的なアプローチを示しています：

• プロジェクトの範囲と目的を定義：どの部門、システム（メールサーバー、データベース、クラウドストレージ、サードパーティアプリケーションを含む）、業務プロセスがPIIを取り扱っているかを明確にします。規制コンプライアンス、リスク低減、データ最小化など、目的も把握します。
• 関係者へのヒアリング実施：人事、財務、マーケティング、IT、法務など各部門の主要担当者にヒアリングし、PIIの収集・利用・保存・送信方法（メール送信を含む）やデータフロー、リスク認識を把握します。
• 自動検出ツールの活用：SSNやクレジットカード番号、特定キーワードなど既知のPIIパターンを検出できる専用ソフトウェアを使い、システム、データベース、ファイル共有、メールアーカイブをスキャンします。これによりインベントリ作成が大幅に効率化します。
• データフローダイアグラムの作成：PIIが組織にどのように流入し、処理され、移動し、外部に出ていくかを可視化します。メールゲートウェイ、API連携、サードパーティ共有などの転送ポイントに注目し、脆弱性を特定します。
• 特定したPIIの分類：発見したPIIを機微・非機微、GDPR、HIPAA、CCPAなどの規制関連性で分類し、可能な限りデータ分類タグをリポジトリに付与します。
• 調査結果の厳格な文書化：PIIの種類、所在、所有者、処理目的、保存期間、セキュリティ対策、データフローなどを詳細に記載したPIIインベントリを作成します。これは監査時のコンプライアンス証明やリスク評価の基礎となります。

一般データ保護規則（GDPR）はPIIをどのように定義しているか？

GDPR規則では、個人データは「識別された、または識別可能な自然人（データ主体）に関連するあらゆる情報」と明確に定義されています。GDPRはまた、氏名、ID番号、オンライン識別子、またはその自然人の身体的、生理的、遺伝的、経済的、文化的、社会的アイデンティティに特有な要素など、個人データに該当する一般的な項目も規定しています。

PIIと個人データはほぼ同義ですが、法的な影響はより多岐にわたります。誰かを特定できるあらゆる情報は個人データと見なされ、厳重に安全・秘密・機密に保たれなければなりません。これにはセキュリティログ、同意書、クッキー、オンラインプラットフォーム上で顧客の存在や体験を維持するためのタグやトークンなども含まれます。

また、GDPR違反でPIIをメール送信した場合、総収益の最大4%という高額な罰金が科される可能性もあります。

GDPR準拠でPIIを共有する方法について詳しくはこちら：GDPRに準拠したメールでのPII送信方法

PIIと個人データの違いは？

米国ではPIIの定義がやや曖昧ですが、欧州連合ではその定義をより明確にするための措置が取られています。そのため、一般データ保護規則（GDPR）フレームワークで定義される「個人データ」という概念が法的枠組みで明記され、法的文書や要件で繰り返し参照されています。

PIIを保護するための暗号化技術

暗号化は、メール送信前に個人識別情報（PII）を保護するために広く利用されている技術です。PIIは、万が一悪意ある第三者の手に渡った場合、なりすましやクレジットカード詐欺など深刻な被害につながるため、保護が不可欠です。暗号化は、PIIを含むメールの機密性と安全性を確保する追加のセキュリティ層を提供します。メール暗号化は、組織が顧客の機密情報を転送中に保護するための重要なツールです。PIIを暗号化することで、情報が安全に保たれ、権限のない者がアクセスできなくなります。PIIを暗号化する一般的な方法は以下の通りです：

PII保護のための共通鍵暗号方式

共通鍵暗号方式は、1つの秘密鍵で暗号化と復号の両方を行う技術です。この方式は、PIIの機密性と真正性を保証するために最適です。鍵は秘密に保持され、認可されたユーザーのみがアクセスできます。

PII保護のための公開鍵暗号方式

公開鍵暗号方式は、暗号化用と復号用の2つの鍵を使用します。送信者は受信者の公開鍵で暗号化し、受信者は自分の秘密鍵で復号します。この方式は、PIIを転送中に保護するのに特に有効です。

PII保護のためのハッシュ化

ハッシュ化は、PIIの内容から元に戻せない一意のデジタル指紋を生成する技術です。攻撃者がハッシュ化された内容にアクセスしても、元の情報を復元することは事実上不可能なため、PII保護に有効です。

PII保護のためのトークナイゼーション

トークナイゼーションは、機微な内容をシステム内でのみ意味を持つ一意の識別子（トークン）に置き換える技術です。この方式は、システムが侵害された場合でも機微な内容が保護されるため、保存や取引時のPII保護に特に有効です。また、トークナイゼーションは取引処理の効率化やデータ漏洩リスクの低減にも寄与します。

PII保護のための暗号鍵管理

適切な暗号鍵管理は、暗号化された内容のセキュリティ維持に不可欠です。鍵は安全に保管し、認可された関係者のみに提供する必要があります。鍵のローテーションや失効も、鍵が漏洩した場合に暗号化データの安全性を維持するために重要です。

これらの暗号化技術を組み合わせて導入することで、PII保護のための強固かつ包括的なセキュリティ戦略を構築できますが、暗号化手法が最新かつ新たな脅威にも有効であることを定期的に見直し・更新することが重要です。

PII送信のためのメール以外の代替手段

PII保護には「送らない」ことが最善策となる場合もあります。

PIIを適切に取り扱うには、セキュアサーバー、暗号化、ポリシー、手順、監査など多くの要素が必要です。したがって、メールプラットフォームも厳格なセキュリティ要件を満たす必要があります。パブリックなメールでPIIを送信することは、いかなるデータプライバシー規制や要件にも準拠せず、顧客のプライバシーも守れません。

どうしてもPIIを共有する必要がある場合は、いくつかの主要な代替手段を検討してください。転送中・保存中の暗号化は大前提ですが、GDPR、HIPAA、CCPAなどの規制に準拠してPIIをやり取りするために、次のような代替手段を推奨します：

SFTPやその他のファイル転送

SFTPを適切に設定すれば、データの安全かつコンプライアンスに準拠した共有・転送が可能です。セキュアマネージドファイル転送（MFT）も選択肢の一つです。ただし、受信者側の負担が大きくなるリスクもあります。顧客がこのようなソリューションを利用するのは、業界標準となっている場合に限られるでしょう。

セキュアメールリンク

セキュアメールリンクは、セキュアサーバーとメールの利点を組み合わせた方法です。暗号化データを直接送信する代わりに、組織は暗号化サーバー上のメッセージへのセキュアメールリンクをメールで送信します。ユーザーは認証を行い、そのサーバー上のPIIを含むメッセージにアクセスします。

この方法は、メールでPIIを保護する最もシンプルかつ管理しやすい方法です。ユーザーが新しい技術を学ぶ・導入する負担を減らし、責任をユーザーからITインフラへ移行できます。セキュアメールリンクを使えば、メールコンプライアンス要件（監査ログやユーザーアクセス管理など）も満たせます。

PIIを安全にメール送信するための許容手段

個人識別情報（PII）のメール送信は、適切なセキュリティ対策がなければ本質的にリスクを伴います。データ保護と規制コンプライアンスを確保するため、組織は自社の運用ニーズやリスク許容度に合わせた安全な手段を採用すべきです。以下は、PIIをメールで送信する際に認められる主な方法で、それぞれセキュリティ、利便性、実装の複雑さが異なります：

• エンドツーエンド暗号化メール： S/MIMEやPGPなどのプロトコル、またはKiteworks プライベートデータネットワークのような統合プラットフォームを利用し、送信者から受信者までメッセージ内容を暗号化します（エンドツーエンド暗号化）。GDPRやHIPAAの暗号化要件にも強く適合します。メール暗号化には設定（鍵交換）や両端での対応ソフトウェアが必要です。構成、鍵管理ポリシー、ユーザートレーニングが求められます。
• セキュアウェブポータル： 受信者は、PIIを含むメッセージやファイルを閲覧・ダウンロードするためのセキュアなオンラインポータルへのリンク付き通知メールを受け取ります。優れたコントロール、認証、監査ログによる規制コンプライアンス対応を実現します。受信者は追加の手順（多要素認証（MFA）など）を踏む必要があり、直接メールより手間がかかります。専用ポータル、ユーザー登録、明確な利用案内が必要です。
• パスワード保護付き添付ファイル： PIIを含む個別ファイル（PDFやZIPなど）を暗号化し、強力なパスワードで保護してメール添付します。基本的な暗号化要件は満たしますが、パスワードの安全な伝達が不可欠で、パスワード管理が不十分だと厳格な規制には不十分です。使い方は比較的簡単ですが、パスワードのやり取りで送信者・受信者の連携が必要です。ファイル暗号化の知識と、パスワードを別の安全なチャネル（電話、SMSなど）で送る必要があります。同じメールや別メールでパスワードを送るとセキュリティが損なわれます。
• ゼロトラストファイルリンク（セキュアリンク）： ポータルと似ていますが、ファイル共有に特化しています。メールには一意で有効期限付きのリンクが記載され、受信者は認証後にPIIを含むファイルをセキュアサーバーからダウンロードします。強力なセキュリティ、可監査性、アクセス制御を提供し、コンプライアンス要件にも適合します。ユーザーフレンドリーで、セキュアファイル共有やコンテンツネットワークプラットフォームに統合されていることが多いです。Kiteworksのようなセキュアファイル転送ソリューションやプライベートデータネットワークの一部として実装され、プラットフォーム設定やポリシー構成が必要です。

メールでPIIを送信する際の法的・コンプライアンス上の問題

PIIをメールで送信することは安全性に欠け、プライベートかつ機密性の高いデータへの不正アクセスにつながる可能性があります。多くのメールサービスは暗号化されておらず、転送中に傍受されることでハッカーに機微なデータが漏洩するリスクがあります。PIIをメールで送信する際、組織は以下のようなリスクにも直面します：

1. データ保護： メールでPIIを送信することは、送信者がデータを受け取る管轄区域のデータプライバシー法に違反する可能性があります。データ保護規制や基準により、メールの安全性確保や不適切なデータ開示防止のための追加措置が求められる場合があります。
2. プライバシーと同意： メールでPIIを送信することは、送信者がデータを受け取る管轄区域のプライバシー・同意法に違反する可能性があります。場合によっては、個人データ送信前にユーザーの許可が必要です。
3. 迷惑メール法： メールでPIIを送信することは、送信者がデータを受け取る管轄区域の迷惑メール法に違反する可能性があります。未承諾メールは禁じられている場合があり、PIIを含むメールは法令に従って送信しなければなりません。
4. 国際間転送： メールでPIIを送信することは、国をまたいだデータ移転となる場合があり、EU一般データ保護規則（GDPR）など追加の法的・コンプライアンス義務が発生します。

PIIメールコンプライアンスチェックリスト

メールは依然としてPII送信の一般的な手段ですが、リスクも高いチャネルです。リスク低減と規制遵守のため、組織は厳格なメール取扱手順を徹底する必要があります。以下のチェックリストは、PIIを含むメールコミュニケーションを安全に管理するための必須ステップをまとめています。データの最小化から暗号化、同意取得、適切な監督までを網羅しています：

1. 必要性の確認とデータ最小化： メールでPIIを送信する前に、本当に必要かを確認し、代替手段を検討します。メール送信が不可避な場合は、目的に必要最小限のPIIのみを送信します（データ最小化の原則）。
2. 明示的な同意の取得（該当する場合）： GDPRなどの規制下では、PIIをメール送信するためにデータ主体の明示的な同意を取得し、記録に残します（他の合法的根拠がある場合を除く）。
3. 受信者の身元とアドレスの確認： 受信者のメールアドレスを正確に確認し、特に機微なPIIの場合は受信者の身元確認措置を講じます。可能な限り汎用アドレスやグループアドレスへの送信は避けます。
4. 承認済みセキュア手段の利用徹底： エンドツーエンド暗号化付きメール、セキュアポータル、セキュアファイルリンクなど、組織が承認した特定の安全な送信手段の利用を義務付けます。標準的な暗号化されていないメールで機微PIIを送信することは禁止します。
5. 強力な暗号化の適用： 転送中・保存中ともに最新の暗号化でPIIを保護します。転送中の暗号化にはTLSが標準ですが、機微データには不十分です。保存時の暗号化にはAES 256暗号化が高く評価されています。メール本文やPIIを含む添付ファイルにはエンドツーエンド暗号化を使用します。
6. 添付ファイルの適切な保護： PIIを添付ファイルで送信する場合は、AES 256暗号化など強力な暗号化と堅牢なパスワードを使用します。パスワードは必ず別の安全なチャネル（電話、セキュアメッセージングアプリなど）で伝え、同じメールや別メールで送らないようにします。
7. データ損失防止（DLP）の実装： DLPツールを活用し、送信メールを監視してPIIを検出し、ポリシーに従って自動的にブロックや暗号化を行い、偶発的な漏洩を防止します。
8. 定期的なユーザートレーニングの実施： PIIメール送信に伴うリスク、関連規制、組織ポリシー、安全な手順について従業員を教育します。セキュリティ意識向上トレーニングでは、「適切な対策なしに機密情報をメールで送っても安全か？」という問い（答え：NO）を徹底します。
9. 包括的な監査ログの維持： メールセキュリティソリューションで、送信者・受信者・タイムスタンプ・PII検出（該当時）・実施したセキュリティ措置（暗号化など）をすべて記録します。監査ログは規制や社内ポリシーに従って保管します。
10. 暗号鍵の安全な管理： S/MIMEやPGPなど鍵管理が必要な手段を使う場合は、鍵の生成・配布・保管・ローテーション・失効の安全なプロセスを確立します。

PII保護に関するNISTの基準

米国国立標準技術研究所サイバーセキュリティフレームワーク（NIST CSF）およびNISTプライバシーフレームワークは、個人のPIIを保護するための基準を提供しています。このフレームワークは、情報セキュリティプログラムの設計・実装時に組織へ指針を与えます。PII基準には、データ収集、データ保存、データ転送、ソフトウェア開発、物理的アクセス制御、アクセス制御リスト、暗号化など、PII保護のための管理策が含まれています。また、監査や報告の要件も規定されています。

組織は、NIST CSFとそのPII基準の導入を検討すべきです。なぜなら、これらは信頼性の高い権威ある機関が策定した包括的かつ実践的なガイドラインであり、機微な顧客データの安全かつ責任ある取り扱いのための堅固な基盤を提供するからです。これらの基準に従うことで、組織はセキュリティリスクやデータプライバシー侵害から自社を守ることができます。さらに、HIPAAなどのデータプライバシー規制は、NIST CSFのPII基準をPII取扱組織の最低限のセキュリティ要件と位置付けているため、NIST CSFのPII基準に準拠することで、これらの規制違反による高額な罰金も回避できます。

Kiteworksでセキュアメールを送信

Kiteworksのプライベートデータネットワークは、個人識別情報（PII）などの機密性の高いコンテンツや、企業が信頼できるパートナーとさまざまなコミュニケーションチャネルで共有するその他の機密情報に対して、高度な保護とコンプライアンスを提供します。

KiteworksセキュアメールおよびKiteworksセキュアファイル共有は、使いやすさやエンタープライズ機能を損なうことなく、主要な規制コンプライアンス要件に対応しています。

Kiteworksはまた、強化された仮想アプライアンス、エンドツーエンド暗号化、監査ログを組み合わせ、従業員がどのデバイス・場所からでもPIIやその他の機密情報を安全に共有・コラボレーション・管理できるようにします。

さらに、Kiteworksのメール保護ゲートウェイは、エンドツーエンド暗号化によるメール保護を自動化し、クラウドサービスプロバイダーやマルウェア攻撃からプライベートなメール内容を守ります。

Kiteworksはまた、すべてのファイルアクティビティ（誰が、いつ、誰に、どのように送信したか）に関する詳細な可視性を提供し、業界規制やGDPR、HIPAA、サイバーセキュリティ成熟度モデル認証（CMMC）などの規格への準拠を確実にします。これにより、KiteworksはPII保護や関連規制へのコンプライアンス証明が必要な組織にとって不可欠なツールとなります。

追加リソース

• 記事 PCIデータコンプライアンスとは？
• ブログ HIPAA準拠のメールとは？
• ブログ メール購読フォームをGDPR準拠にする方法
• ブログ コンプライアンスメールとは？
• ウェビナー アーカイブプラットフォーム間での暗号化メールのシームレスな電子証拠開示