データ漏洩の防止

コンピュータとネットワークのセキュリティに求められる重要な機能の一つは、不正な第三者が機密データにアクセスできないようにすることです。このドキュメントでは、データ漏洩リスクの特性について説明するとともに、データ保護のための業界全体のベスト プラクティスについて説明します。具体的には、Google Cloud のツールや機能を使用してリスクを軽減し、データの漏洩を検出して、不正行為のイベントに対処する方法について説明します。可能な場合、セキュリティの脅威と防護に対するアプローチについては、クラウドに限定しない意味合いで説明していきます。新しい規制環境、特に 2018 年に義務化される欧州の一般データ保護規則（GDPR）では、データ漏洩防止メカニズムの導入に新たな重点を置いています。

データ漏洩の定義

このドキュメントでいうデータ漏洩とは、権限のある個人が、保護されたシステムからデータを抽出し、それを権限のない第三者と共有したり、保護されていないシステムに移動させたりすることを指します。権限のある個人とは、従業員、システム管理者、信頼されたユーザーのことを指します。データ漏洩は、悪意のある個人やセキュリティ侵害された個人の行動によって起こることもあれば、事故によって起こることもあります。

データ漏洩のリスクを軽減するために、組織はセキュリティに関する意識とベスト プラクティスを組織の文化として定着させる必要があります。また、コンピュータ ネットワーク、端末、アプリケーション、データ、他のユーザーとのあらゆるやり取りに関わるリスクを、一貫性をもって評価する必要があります。定期的な監査を実施して、ベストプラクティスが準拠されているかどうかを検証することもできます。

クラウドでのデータ漏洩リスク対策

従来型のデータ セキュリティ戦略では、多くの場合、プライベート ネットワークの物理的境界の防御を強化することに重点が置かれます。しかし、クラウド コンシューマは、サービスで使用される物理的なネットワーク インフラストラクチャを制御するわけではありません。パブリック クラウドでは、ホスティング プロバイダのネットワーク ファブリックが共有されるため、従来の意味での境界は存在しません。クラウド上のデータを保護するには、新しいセキュリティ アプローチと、データアクセスを監査する方法が必要になります。

たとえば、パブリック クラウド インフラストラクチャは、データセンターにコモディティ ハードウェアを使用した業界初のサービス形態です。結果として、ハードウェアの故障率が高くなる可能性がありますが、冗長性とインテリジェントなサービス アーキテクチャによって、そのような障害による影響は最小限に抑えられます。この種の環境では、サービスが複数の障害に余裕をもって対応できなければなりません。 サービス アーキテクチャは、処理、ストレージ、認証、その他のタスクを複数のマシンや地理的領域に分散させることで、ハードウェア障害やネットワーク障害に対応できるよう設計されており、それによって、障害イベントの影響が最小限に抑えられています。データの保護においても、これと同様のアプローチをとる必要があります。つまり、ダウンタイムを最小限に抑え、セキュリティ侵害が発生した場合にもシステム全体への影響を制限できるように、アーキテクチャを設計する必要があります。

セキュリティ意識の高い顧客にも納得してもらえるよう、パブリック クラウド セキュリティ モデルにはこの考え方が導入されています。Google Cloud の Shielded VM により、Compute Engine 仮想マシン（VM）インスタンスの検証可能な整合性が提供されるので、インスタンスがブートレベルまたはカーネルレベルのマルウェアによって改ざんされていないことを確認できます。Shielded VM の検証可能な整合性は、Secure Boot、vTPM 対応のメジャード ブート、および整合性モニタリングを使用して実現されています。

さらに、クラウドベースの仮想マシン（VM）では、プロバイダが特殊なエージェントをデプロイすることで、ユーザーやホストの活動に関するテレメトリーを生成できます。これにより、セキュリティ オペレーション センター（SOC）はセキュリティ境界内やその周囲での頻繁な活動の変化を可視化できるようになります。

また、プロバイダは明示的なチョークポイントを導入することもできます（VM、ネットワーク プロキシ サーバー、ネットワーク下り（外向き）サーバー、プロジェクト間ネットワークとの通信に使用する踏み台インスタンスなど）。ただしこれらの措置では、データ漏洩のリスクを低減することはできても、完全に排除することはできません。

データ漏洩イベントを検出し、それらに対応するための強力なインフラストラクチャを構築することも、あわせて必要になります。適切なクラウド インフラストラクチャを構築すれば、リスクの高い活動や不適切な活動をすばやく検出し、活動の影響範囲を制限し、漏洩の可能性を最小限に抑えることができます。

データ漏洩イベントのカテゴリ

データ漏洩イベントは、技術的、組織的、物理的な特性の共通点ごとに分類することができます。以下のセクションでは、これらのカテゴリをいくつか紹介し、それぞれの予防戦略と緩和戦略について説明します。

送信メール

これは、操作者がビジネスメールやモバイル デバイスなどの許可された通信インフラストラクチャを使用して、セキュリティ保護されたコンピュータ システムから、信頼されていない第三者のシステムや保護されていないシステムに機密データを送信するというシナリオです。機密データは、メールやテキスト メッセージ内のプレーン テキストとして送信される場合もあれば、ファイルとして添付される場合もあります。この方法は、組織のメール、カレンダー、データベース、画像、計画文書、ビジネス予測、ソースコードの内容を盗み出す目的でよく使用されます。

多くのメールシステムやメッセージング システムでは、クラウドに下書きが保存されるため、メッセージの送信時に機密データを確認するだけでは不十分です。下書きの保存をサポートしているビジネスメールやその他のメッセージング サービスに外部からアクセスできる個人は、その機能を利用してデータを盗み出すことができます。機密データにアクセスできるデバイスやネットワークから下書きを保存し、別のクライアントから下書きにアクセスすれば、操作者はロギング システムと監査システムをすり抜けることができます。

予防策と緩和策

このシナリオでは、組織によって選択され承認された通信システムを使用するため、非公開のツールやサードパーティ製のツールを使用するシナリオに比べて、データ漏洩を防止するための選択肢は多くなります。

次の予防戦略と緩和戦略の中から、実施する戦略を検討してください。

  • メールやその他の組織メッセージング ツールを使用してユーザーが実行するデータ送信の量と頻度をモニタリングする。平均的なユーザーが 1 日平均 5 MB のデータを送信する場合、送信データが 500 MB に達するユーザーについては、アラートを通知する必要があります。
  • メールの送信に使用されたアドレス、メールの送信元のデバイス、受信者のアドレスをロギングする。これらの情報は、データ漏洩イベントの性質と範囲を特定するのに役立ちます。管理者用セキュリティ チェックリストでは、Gmail Enterprise でのセキュリティ リスクについてメール アカウントを監査する方法が説明されています。
  • 機密データにアクセスできるシステムから送信されたメールをスキャンし、不正なコンテンツが含まれていないことを確認する。機密コンテンツにキーワードやハッシュなどのマーカーを付けておくと、このチェックを簡単に行えます。
  • 安全でないチャネルでメッセージを送信すること（https の代わりに http を使用するなど）を防止し、そのような操作が試行された際には、IT セキュリティ スタッフにアラートを送るようにする。

安全でないデバイスへのダウンロード

これは、ユーザーが承認済みのチャネルを通じて機密データにアクセスし、そのデータを安全でないローカル デバイスに転送した場合に発生するケースです。操作者は、ノートパソコン、スマートフォン、外付けドライブ、カメラ、専用デバイスのいずれかを使用して機密データを取得し、漏洩する可能性があります。また操作者は、クラウド内のサービスから既存のファイルをダウンロードしたり、新しいファイルにデータをコピーしたりする可能性があります。モニタリングされていないデバイスや安全でないデバイスにファイルが転送された場合、それらのファイルは漏洩するリスクが高くなります。

予防策と緩和策

クラウドベースのネットワークは、この種のイベントを防止する上で利点があります。データをローカル端末に転送する方法の多くでは、転送可能なメディアへの物理的な接続が必要となります。しかし、データがクラウドに保存されている場合は、転送の前にデータをダウンロードする必要があります。これらのダウンロードは、ホスティング サービスやクライアントのセキュリティ機能と追跡機能の対象となります。

次のポリシーと手法の実装を検討してください。

  • 機密性の高いデータのダウンロードを禁止する。クラウドでのデータの使用方法や処理方法によっては、ユーザーがローカル ハードウェアにデータをダウンロードする必要が一切生じない場合もあります。可能であれば、すべてのデータをクラウドに保存し、すべての計算処理をクラウド上で実行するようにします。データが技術的にダウンロード可能な場合は、ダウンロードを禁止するポリシーを規定し、機密データの分類とラベル付けを行います。また、セキュリティ保護されたインタラクションや API 呼び出しを通じて要求され提供されるデータのアクセスログを記録するようにしてください。詳細については、監査ロギングに関するドキュメントをご覧ください。
  • クラウド アクセス セキュリティ ブローカー（CASB）を使用して、承認済みのクライアントとクラウド サービス間の接続を、組織のセキュリティ ポリシーに従って制御する。
  • デジタル著作権管理（DRM）ツールを使用してファイルをラップする。これにより、各ファイルに権限ベースのセキュリティと暗号化を適用できます。
  • 承認済みのクライアントにダイナミック透かしを実装して、機密情報を含むスクリーンショットや写真の責任者を記録する。

外部サービスへのアップロード

上記のイベント カテゴリと同様、このカテゴリでは多くの場合、機密データがローカル インフラストラクチャにダウンロードされます。操作者はその後、ウェブブラウザ クライアントやモニタリングされていないその他のソフトウェアを通じて、第三者にデータをアップロードします。サードパーティのサービスがソーシャル ネットワークなどの無害なウェブサイトであったとしても、操作者が間違った画像を誤ってアップロードする可能性や、間違ったテキストを貼り付ける可能性があります。悪意のある操作者が高度なスキルを持っている場合は、少量の機密データ（ユーザー認証情報や暗号化キーなど）を URL パラメータとして特殊なウェブ アプリケーションに渡す可能性もあります。

予防策と緩和策

この種のイベントのリスクは、機密データのローカルコピーを防止するダウンロード制限と同じポリシーによって軽減できます。ただし、スクリーンショットやコピーされたテキストが、ソーシャル メディア、ファイル共有ウェブサイト、またはその他のクラウド サービスにアップロードされるリスクをポリシーで排除することはできません。

この種のリスクに対処するには、次のセキュリティ プラクティスを検討してください。

  • すべてのデータのダウンロードを禁止する。すべてのデータをクラウドに保存し、すべての計算処理をクラウドで実行します。データの要求と提供は、セキュリティ保護とロギングを有効にした API インタラクションによって実行します。詳細については、監査ロギングに関するドキュメントをご覧ください。
  • 機密データにアクセスできるデバイスに、安全でないサードパーティ ソフトウェア（ソーシャル メディアアプリや未承認のブラウザ プラグインなど）をインストールすることを禁止する。
  • CASB を使用して、クラウド アクセス ポイントからのトラフィックを規制し、クライアントに送信されるすべてのデータに対して暗号化ポリシーを適用する。

安全でないクラウド動作

クラウド サービスを使用する場合、IT セキュリティの専門家は、新しいデータ漏洩リスクのカテゴリについて意識する必要があります。これには、従業員、ユーザー、または管理者が安全でない方法でクラウド プロバイダ スイートの機能を使用する、さまざまなケースが含まれます。仮想マシン（VM）を使用または変更したり、コードをデプロイしたり、クラウドのストレージ サービスやコンピューティング サービスに要求を送ったりすることができる操作者からは、データが漏洩する可能性があります。

クラウド ネットワークにはパブリックなフロントエンドがあるため、より広範囲なインターネットと通信することが可能です。そのため、クラウド上で実行されるサービスの動作をセキュリティで保護し、権限を管理することは、データ セキュリティを提供する上で不可欠です。十分な権限がある場合、操作者は、機密データのアウトバウンド送信を開始したり、安全なコンテナ内の機密データを安全性の低いコンテナへと移動させたり、組織の代表として不正なクラウド サービスを作成することもできてしまいます。

予防策と緩和策

クラウド サービスの安全な動作を維持するには、範囲を限定した厳密な権限管理と、包括的なロギングが必要になります。可能であれば、組織のサービスのバックエンドに操作者がアクセスすることを禁止してください。従業員や管理者が VM 上で完了する必要があるほとんどのタスクについては、セキュリティで保護された、モニタリング可能な自動化エージェントとフロントエンド クライアントがあります。これらは、クラウドマシンに直接 SSH アクセスできるユーザーの数を制限することが可能な場合に使用してください。可能であれば、広範なインターネットに送信されたすべてのデータをスキャンして、機密情報を特定します。外部のユーザーやシステムからの情報を処理するアプリケーションの場合は、その情報をスキャンして、個人情報（PII）などの機密データが誤って収集、保存、共有されないようにすることを検討してください。

クラウド内の VM については、次のセキュリティ原則を考慮してください。

  • 不明なアドレスへの発信接続を禁止する IP テーブルを VM 上に設定する。これにより、操作者が組織のネットワークから機密データを成功裏に送信するリスクを軽減できます。
  • VM にパブリック IP アドレスを割り当てることを避け、送受信接続の処理に NAT（Network Address Translation）サービスを使用する。Compute Engine について詳しくは、NAT ゲートウェイの設定に関するこちらのガイドをご覧ください。
  • クラウド内で踏み台インスタンスを使用して、他のホストへの接続を仲介およびモニタリングすることを検討する。
  • リモート デスクトップ プロトコル（RDP）や Windows リモート管理（WinRM）エージェントなどのリモート管理ソフトウェアは、それを必要としないマシンでは無効にする。
  • 限定公開の Google アクセスを使用して、サブネットワーク上の仮想マシン（VM）インスタンスが、外部 IP アドレスではなく内部 IP アドレスを使用して Google の API やサービスにアクセスできるようにする。
  • クロス プロジェクト ネットワーク（XPN）を使用し、Cloud 組織内のプロジェクト間で Google Cloud の仮想ネットワークを共有することを検討する。
  • VM への直接 SSH アクセスは、不可欠かつ不可避な必要性があるユーザーのみに制限する。Google Compute Engine では、VM へのアクセスを制御するための包括的な SSH 認証鍵管理ツールが提供されています。

Cloud Storage や Cloud Bigtable などのクラウド ストレージ サービスについては、次のプラクティスによって漏洩リスクを低減できます。

  • Identity and Access Management（IAM）を使用して、データへのアクセスに必要な最小限の権限セットをユーザーとアプリケーションに提供する。機密性やアクセス要件ごとに分類された複数のコンテナにデータを格納して、権限をできるだけ細かく管理します。
  • ストレージ リソースからのデータ読み取り速度をモニタリングし、制限する。モニタリング エージェントを使用して、通常のユースケースよりも大量のデータ移動が試行された際には、セキュリティ チームにアラートが送られるようにします。
  • 機密性の高いデータへの権限は一時的に付与し、見直しと失効処理を頻繁に行うようにする。たとえば、App Engine の割り当てを使用すると便利です。
  • 機密性の高いコンテナにアクセスできる一連のユーザーに対し、担当のチームが定期的に監査を行うようにする。
  • ストレージ サービスへのすべてのアクセスに関する詳細なログを保管する。ストレージ サービスへのアクセスを許可されたユーザー グループは、なるべく、ログにアクセスできるユーザー グループとは隔離されるようにしてください。そうすれば、悪意のある操作者によってログが改ざんされるリスクを軽減できます。Cloud Storage のアクセスログ ユーティリティを使用して、ログデータを別のストレージ バケットに書き込むことを検討してください。

セキュリティ ポリシー遵守の徹底

Google Cloud が提供する豊富なインフラストラクチャは、お客様が独自のニーズを満たすソリューションを開発するためのさまざまな機会を生み出します。ただしこの豊富なインフラストラクチャは同時に、組織内のさまざまなプロジェクトに対して望ましいセキュリティ ポリシーを適用するといった、新たな課題ももたらします。セキュリティ管理を簡素化するため、Google Cloud ではすべてのリソースが属するエンティティ階層を導入しました。この階層は組織というコンセプトに根ざしています。組織にはオプションで、フォルダまたはプロジェクトが含まれる場合があります。フォルダにはオプションで、サブフォルダまたはプロジェクトが含まれる場合があります。すべての Google Cloud Service リソースはプロジェクトに属します。

この、組織 -> フォルダ -> プロジェクト -> Google Cloud サービス -> リソースという階層を使用すると、階層のどのレベルにでもセキュリティ ポリシーを設定でき、そのポリシーが階層の下位レベルに継承されます。セキュリティ ポリシーはリソース階層の上から順に評価され、「許可」の回答が得られるとすぐに、リソースへのアクセスが許可されます。

コンプライアンスの徹底

リソース階層およびセキュリティ ポリシーの継承を使用すると、望ましいセキュリティ ポリシーの一貫した遵守を確認するための監査が容易になります。継承プロパティを使用することで、管理者はたとえば、すべてのプロジェクトで同じ監査者がデータを検査できることを実証できます。これを行うには、組織レベルでそうしたセキュリティ ポリシーを設定し、それを絶対に下位レベルでオーバーライドしないことです。こうしたセキュリティ ポリシーはソフトウェアの監査アクティビティで指定し、検証は自動化することができます。

機密データの特定と修正

機密データを管理するための最初のステップの一つは、データの場所を把握することです。これを把握すれば、アクセス制御を設定して適切なアクセスと処理を実現することや、機密性を下げる手法（データ修正、マスキング、匿名化）を活用することが容易になります。データは編集済みの形式になると、具体的な社会保障番号、有効なクレジット カード番号、個人情報（PII）などという機密性を示さなくなります。

多様性に富む大量のデータを修正する際の従来からの課題は、認識、分類、そして適切な修正を自動化する必要があることです。進歩した点は、データ フィールドの内容について自動的に推測できるシステムのサポートがあることです。任意のデータ ストリームに対するこのレベルでの自動化された可視性により、アプリケーションはどのエンドポイントにどのデータを送信するか、管理するさまざまな種類のデータをどのシステムに保存するか、特定の種類のデータが送信される際にいつ警告を発するかといったことを決定できます。

予防策と緩和策

Google Cloud では、Sensitive Data Protection を使用して機密データを把握し、管理できます。これは、クレジット カード番号、氏名、社会保障番号、パスポート番号、米国および一部諸国の運転免許証番号、電話番号などの機密データ要素について、迅速でスケーラブルな分類とオプションでの修正を可能にします。Sensitive Data Protection は、テキスト、構造化データ、画像をサポートしています。Sensitive Data Protection にデータを送信するか、Cloud Storage、BigQuery、Datastore インスタンスに保存されているデータを指定するだけでご利用いただけます。Sensitive Data Protection から得られた情報は、IAM 設定、データ保管場所、その他のポリシーの構成を自動的にモニタリングまたは通知するために使用できます。また Sensitive Data Protection を使用すれば、データの機密性を下げるためにその一部を編集またはマスクできるほか、最小権限ポリシーや need-to-know ポリシーの一環としてデータを最小化することも可能です。利用可能な手法には、マスキング、フォーマット保持暗号化、トークン化、および構造化データやフリーテキスト データのバケット化があります。

不正な管理者

設計上、ほとんどのコンピュータ システムでは、指定された管理者に全面的な権限が付与されます。そのような場合、悪意のある管理者やセキュリティ侵害された管理者は、このドキュメントで説明されているシナリオを実行するのに十分な権限を持つことになり、さらには、ログや自分の操作の証拠を抹消するための最大限の権限を持つことになります。これらのリスクを軽減するには、ネットワーク内の部分ごとに権限を分離し、管理者が互いをモニタリングできるようにする必要があります。

予防策と緩和策

個々の操作者の権限を制限することは、不正な管理者によるリスクを軽減する上で不可欠です。

担当のタスクを遂行できるようにする必要上、管理者はデータ漏洩にも悪用可能な権限を持つことになりますが、そのような事象が発生した場合でも、次の原則を適用することで、その範囲と規模を軽減できます。

  • 管理者の操作を、管理者がアクセスできない場所にロギングすることで、大規模なネットワークを管理者の不正行為から保護する。モニタリング サービスとロギング サービスの管理は、別のセキュリティ チームが担当するようにします。
  • すべての管理者に、有効期間の短い一時的なアクセス権を付与することを検討する。多くのネットワークでは、管理者に永続的なアクセス権を付与する必要はありません。
  • 管理操作の承認を、複数の操作者が行うようにする。すべての管理操作を、承認が必要なソースコードなどと同様に処理することで、操作者が 1 人である場合のリスクを減らすことができます。

従業員の退職

カーネギー メロン大学のソフトウェア工学研究所におけるコンピュータ緊急対応チーム（CERT）が作成した 2011 年のレポートによると、企業の従業員は、自分が近々解雇されることを予期したときに、データ漏洩に関与する可能性が高くなります。従業員の解雇を保留している期間中はリスクが高まるため、IT セキュリティ チームにおいては特別な注意が必要となります。

予防策と緩和策

機密性の高いデータがあるネットワークについては、今後の退職情報を記録する HR ソフトウェアにログシステムとモニタリング システムを接続して、それらのユーザーの異常行動をセキュリティ チームに警告するための、より厳格なしきい値を設定することを検討してください。

まとめ

パブリック クラウド インフラストラクチャを使用して、システムの柔軟性、コスト性能、処理パワーを高めるには、データの漏洩を防ぐための警戒体制と、新しいアプローチが必要になります。このドキュメントで説明した手法を使用すれば、環境を考慮しながら組織のポリシーと実装を設計できます。

  • データの区画化によって、データ漏洩イベントの影響範囲を最小限に抑える。
  • システム管理者のワークフローに冗長性と承認体制を組み込み、アカウンタビリティを向上させる。
  • 細分化された権限を使用し、機密データへのアクセス権は、その職務機能を必要とするユーザーにのみ付与する。
  • ロギングを使用して、組織内のデータのアクセスや移動に関する透明性を高める。
  • ネットワーク ルール、Identity and Access Management（IAM）、および踏み台インスタンスを使用して、組織内のマシンへの入出力を制限し、モニタリングする。
  • アクセスまたは転送されたデータの量や、アクセスの地理的場所など、通常のデータフローの基準値を作成して、異常な動作と比較できるようにする。

次のステップ