データ保護コンプライアンスの本質とは？可視性と保証の重要性

データ保護コンプライアンスについて考えるとき、企業は個人情報保護法、PCI DSS、ISO 27001、業界ごとのセキュリティガイドライン、取引先からのセキュリティ要件など、さまざまな法令、規制、基準への対応を求められます。適用される要件は業界や組織によって異なりますが、それらには一つの共通点があります。

それは、企業に革新的な取り組みを求めているわけではないということです。求められているのは、「どのように取り組んだのかを示すこと」です。

学校の算数で、答えが合っていても計算過程を書くよう求められた経験を思い出してみてください。監査人や規制当局が確認したいのも、まさにそれと同じです。「十分なレジリエンスを備えたインフラを構築している」と説明するだけでは不十分です。どのようなプロセスで運用しているのか、どのようなポリシーを適用しているのか、そしてそれらが実際に機能していることを証明できるのかが問われています。

計画が現実に直面したとき、壊滅的な失敗を回避し、適切に機能することを示せるかどうか。この変化は、データ保護コンプライアンスへの取り組み方そのものを変えています。

データ保護コンプライアンスが本当に求めていること

略語やコンプライアンスフレームワーク、業界固有の要件をいったん脇に置いて考えてみましょう。あらゆるデータ中心の規制が本質的に問いかけていることは、次の二つです。

自社が何を保有しているか把握しているか
それに対して何を行ったかを証明できるか

この二つを表す言葉が、「可視性」と「保証」です。派手な言葉ではありませんが、データ保護コンプライアンスの本質を表しています。

可視性

氏名、メールアドレス、取引情報、決済情報、顧客データなど、規制や契約上の管理対象となる情報が、自社環境のどこに存在しているかを把握できているでしょうか。

保証

データを保護するポリシーが存在するとして、そのポリシーが実際に機能していることを証明できるでしょうか。重要なのは、ポリシーを作成したことではありません。ポリシーが実際に機能していることです。

多くの組織は、「何を保有しているかを把握する」という点では一定の成果を上げています。しかし、多くの場合、課題となるのは「それが本当に機能していることを証明する」方です。

「スキップ列」: データ保護コンプライアンスが破綻する場所

データ保護コンプライアンスを考えるうえで、よく見られるケースがあります。例えば、次のようなポリシーを想定してみます。

「組織の外部に送信されるファイルには、Microsoft Information Protection の秘密度ラベルを付与する。」

「制限付き」「認証必須」などの設定も適切に行われています。一見すると理想的なポリシーです。ガバナンスとしても堅実で、監査人にも説明しやすいように見えます。

しかし現実には、すべてのファイルが .docx や .xlsx ではありません。CSV ファイルもあります。テキストファイルもあります。何年も前に作成された PowerPoint ファイルもあります。こうしたファイル形式には、秘密度ラベルを適用できない場合があります。つまり、そのポリシーの対象外になってしまうのです。

一般的な運用では、こうしたファイルは「スキップ」されます。そこで生まれるのが「スキップ列」です。監査人から「これらのファイルはどう処理されましたか」と質問されたとき、「スキップしました」という回答は説明になりません。それはリスクであり、監査上の問題になります。

もしラベル付与できない場合に、自動で暗号化する、または機密情報をマスキングするといった代替措置を実施できたらどうでしょうか。その場合、監査時には次のように説明できます。

対象ファイルは 100 件
75 件はラベル付与済み
25 件はラベル付与できなかったため暗号化済み

スキップされたファイルはありません。これが保証です。そして、これこそが実践的なデータ保護コンプライアンスです。

難しいのは「移動中のデータ」

保存中データ (Data at Rest) の保護は新しい考え方ではありません。DLP は長年にわたり利用されてきた成熟した技術です。それにもかかわらず、現代の規制やセキュリティ要件が「移動中のデータ (Data in Motion)」を重視するようになったのには理由があります。

それは、監査人や規制当局が「データは置いた場所にそのままとどまる」という前提をやめたからです。実際には、ユーザーがファイルを共有し、データが別システムへ移行され、クラウドへ保管され、委託先がデータを取り扱うこともあります。

委託先が侵害を受けた場合、ニュースの見出しや顧客から見えるのは、多くの場合、委託先の名前ではありません。データを預けた企業の名前です。たとえ法的責任の範囲が限定的であっても、説明責任や信用への影響は避けられません。

そのため、問いは「データは保存時に暗号化されているか」から、「データはどこへ移動しても保護されているか」へと変わりました。そして、この二つの問いはまったく異なるアーキテクチャを必要とします。

正しく語られるべき量子コンピューティングの問題

量子コンピューティングのリスクとしてよく語られるのは、「既存の暗号アルゴリズムが破られる」という点です。これは事実です。しかし、問題はそれだけではありません。もう一つの重要なテーマが、俊敏性 (アジリティ) です。

暗号鍵はますます大きくなっています。そして現在の耐量子暗号が将来破られた場合、どれだけ迅速に鍵をローテーションできるかが重要になります。鍵のローテーションは、もはや単なる運用管理ではありません。緊急対応能力そのものです。

これから重要になるのは、今日最良のアルゴリズムを選ぶことだけではありません。明日、新しいアルゴリズムへ移行できる基盤を構築しているかどうかです。耐量子暗号に関する標準化や各国のセキュリティ要件も、変化に備えることの重要性を示しています。

ハンマーではなくツールベルト

PKWARE 製品は、しばしば「暗号化製品」として認識されます。もちろん、それは間違っていません。しかし、それだけでは PKWARE の全体像を表しているとは言えません。

PKWARE は暗号化だけでなく、

機密情報のマスキング (Redaction)
ラベル付与 (Labeling)
データの削除 (Deletion)
適切な保存先への移動 (Movement)

などにも対応しています。なぜなら、データ保護コンプライアンスにおいて、常に同じ対処が正解とは限らないからです。

例えば、すべてを暗号化するという方針は一見合理的に見えます。しかし、状況によっては暗号化ではなく削除が適切な場合もあります。また、すべてをマスキングするという方針も、パートナー企業とのファイル共有のようにデータの完全性を維持する必要があるケースには適していません。

重要なのはワークフローや利用シーンに応じて適切な対処方法を選択することです。一つの方法だけであらゆる課題を解決しようとするのではなく、状況に応じて複数の選択肢を使い分けることが求められます。

さらに、多くの企業ではデータ保護対策として複数の製品を組み合わせて利用しています。

例えば、

エンドポイントやファイルサーバー向けの PKWARE
クラウドリポジトリ向けの BigID
アクセス制御を担う Varonis
CASB

などです。

そのような環境で監査対応が必要になった場合、各製品から個別にレポートを取得し、それぞれのポリシーや運用状況を突き合わせながらコンプライアンス状況を説明しなければなりません。

これはセキュリティ上の課題というより、限られた人員で運用するチームにとって大きな負担となります。

こうした課題に対する考え方が、「データ中心 (Data-firs)」のアーキテクチャです。

ネットワーク、ファイアウォール、クラウドストレージといった保管場所ではなく、データそのものを保護の中心に据えます。

その結果、データが

Amazon S3
Google Cloud
Microsoft Azure
エンドポイント
メインフレーム

のどこへ移動しても、保護ポリシーを維持できます。

重要なのは、保護が保存場所に依存するのではなく、データそのものに結び付いていることです。

データ中心アーキテクチャという考え方

多くの企業では、PKWARE、BigID、Varonis、CASB など複数の製品を組み合わせて運用しています。監査時には、複数のレポートを集め、複数のポリシーを照合し、複数の製品から証跡を収集する必要があります。これはセキュリティの問題というよりも、すでに逼迫しているチームにとっての運用負荷の問題です。

データ中心アーキテクチャは、この課題を解決するアプローチです。セキュリティをネットワーク、ファイアウォール、クラウドの保存場所ではなく、データそのものに結び付けます。その結果、データが S3、Google Cloud、Azure、エンドポイント、メインフレームのどこへ移動しても、保護ポリシーはデータとともに維持されます。

保護の対象は場所ではありません。データそのものです。

PKWARE がデータ保護コンプライアンスのために行うこと

規制当局や監査人が本当に必要としているものを突き詰めると、次の三つになります。

何を持っているか把握する
重要なものに対処する
それが機能したことを証明する

つまり、発見、是正措置、報告です。そして重要なのは、柔軟な是正措置です。多くのベンダーは一つの答えしか持っていません。

PKWARE は、データが移動することを前提にポリシーを設計します。そのため、データが実際に移動したときにも、すでに動き出しているデータに後から保護を追加しようとして慌てる必要がありません。移動する前から備えることができます。

すでに DLP ツールを利用している場合でも、それは競合ではありません。DLP が検出したシグナルを受け取り、PKWARE がスキャンし、暗号化し、メタデータヘッダーに「PKWARE がスキャン済みであり、ポリシーに適合している。再スキャンは不要である」と記録することができます。暗号化されたファイルは、そのまま通過させることができます。内容は読めなくても、適切に処理されたことは確認できます。

これは置き換えではありません。強化です。データ中心の企業が、ネットワーク中心のセキュリティ基盤にもたらせる価値がここにあります。

規制環境をより深く理解したいチームにとっては、自社の業界で求められるフレームワークとあわせて、各種データセキュリティガイダンスを参照することが有効です。

クローゼットのたとえ

最後に、次のような例えで考えてみましょう。クローゼットを整理するとき、最初からシャツを一枚ずつ見て、その場で判断する人はあまりいません。まずは分類します。ワイシャツ、普段着、T シャツ。まず、何を持っているかを把握します。

在庫が見えれば、判断は速くなり、根拠も明確になります。残す、寄付する、処分する。ポリシーを適用できるからです。

規制がデータに対して求めていることも同じです。把握する。ポリシーを適用する。そして、その取り組みを証明する。

もし今、あらゆるデータについて「何を保有しているのか」「どのように保護しているのか」「それを証明できるのか」を明確に説明できないのであれば、まず見直すべきは規制対応そのものではないかもしれません。

データの所在や状態を把握するための「可視性」が、最初の一歩になるのではないでしょうか。

自社のデータ保護状況を把握できていますか？

データ保護コンプライアンスで重要なのは、対策の有無だけではなく、「何を保有しているか」「どのように保護しているか」「それを証明できるか」を把握することです。

データ保護や暗号化運用の見直しをご検討中の方は、エクセルソフトまでお気軽にご相談ください。

お問い合わせはこちら

世界の人気ソフトウェアを提供するエクセルソフトのメールニュース登録はこちらから。

記事参照: Data Protection Compliance Isn’t What You Think — A Field CTO’s Take

注記:

本記事で紹介している考え方や見解は、原著者および PKWARE 社の見解に基づくものです。
現時点 (2026年 7月)、PKWARE ソリューションは、日本語データに対するデータ検知 (Discovery)、分類 (Classification)、マスキング (Redaction) 機能には対応していません。
本記事で紹介している規制やコンプライアンス要件は、データ保護に関する考え方を説明するための例であり、特定の法令、規制への適合を保証するものではありません。
コンプライアンス要件への適合可否については、お客様ご自身による評価、および必要に応じて法務、監査、セキュリティ部門への確認を推奨します。