データ分類に関する推奨事項

Azure Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。

SE:03 データ処理に関係するすべてのワークロード データとシステムに対して秘密度ラベルを分類し、一貫して適用します。 分類を使用して、ワークロードの設計、実装、セキュリティの優先順位付けに影響を与えます。

このガイドでは、データ分類の推奨事項について説明します。 ほとんどのワークロードでは、さまざまな種類のデータが格納されます。 すべてのデータが等しく機密性が高いわけではありません。 データ分類は、その秘密度レベル、情報の種類、コンプライアンスの範囲に基づいてデータを分類するのに役立ちます。これにより、適切なレベルの保護を適用できます。 保護には、アクセス制御、さまざまな情報の種類の保持ポリシーなどが含まれます。 データ分類に基づく実際のセキュリティ制御は、この記事では範囲外ですが、organizationによって設定された前の条件に基づいてデータを分類するための推奨事項が提供されます。

定義

期間 定義
分類 organizationによって提供される秘密度レベル、情報の種類、コンプライアンス要件、およびその他の条件によってワークロード資産を分類するプロセス。
メタデータ 資産に分類を適用するための実装。
分類 合意された構造を使用して分類されたデータを整理するシステム。 通常は、データ分類の階層的な表現です。 カテゴリ化基準を示す名前付きエンティティが含まれます。

主要な設計戦略

データ分類は、多くの場合、レコードとその機能のシステムの構築を推進する重要な演習です。 分類は、セキュリティ保証のサイズを正しく設定するのにも役立ち、トリアージ チームがインシデント対応中に検出をエクスペディア化するのに役立ちます。 設計プロセスの前提条件は、データを機密、制限付き、パブリック、またはその他の秘密度分類として扱う必要があるかどうかを明確に理解することです。 また、データが複数の環境に分散される可能性があるため、データが格納されている場所を決定することも重要です。

データを検索するには、データ検出が必要です。 その知識がなければ、ほとんどの設計では中間的なアプローチが採用され、セキュリティ要件に対応できる場合とそうでない場合があります。 データを過剰に保護すると、コストとパフォーマンスの非効率性が生じる可能性があります。 または、十分に保護されていない可能性があります。これにより、攻撃対象領域が追加されます。

多くの場合、データ分類は面倒な演習です。 データ資産を検出し、分類を提案できるツールがあります。 ただし、ツールだけに依存しないでください。 チーム メンバーが熱心に演習を行うプロセスを整えます。 次に、ツールを使用して、それが実用的な場合に自動化します。

これらのベスト プラクティスに加えて、「 適切に設計されたデータ分類フレームワークを作成する」を参照してください。

organization定義された分類を理解する

分類 は、データ分類の階層的な表現です。 カテゴリ化条件を示すエンティティという名前が付けられています。

一般に、分類や分類の定義に関する普遍的な標準はありません。 これは、データを保護するためのorganizationの動機によって推進されます。 分類では、コンプライアンス要件、ワークロード ユーザーに対して約束された機能、またはビジネス ニーズに基づくその他の基準がキャプチャされる場合があります。

秘密度レベル、情報の種類、コンプライアンスの範囲に関する分類ラベルの例を次に示します。

感度 情報の種類 コンプライアンスの範囲
Public、General、Confidential、Highly Confidential、Secret、Top Secret、Sensitive 財務、クレジット カード、名前、連絡先情報、資格情報、銀行、ネットワーク、SSN、正常性フィールド、生年月日、知的財産、個人データ HIPAA、PCI、CCPA、SOX、RTB

ワークロード所有者は、organizationに依存して、明確に定義された分類を提供します。 すべてのワークロード ロールは、秘密度レベルの構造、命名法、定義を共有する必要があります。 独自の分類システムを定義しないでください。

分類スコープを定義する

ほとんどの組織には、さまざまなラベルのセットがあります。

organizationの秘密度ラベルの例を示す図。

各秘密度レベルのスコープ内および範囲外のデータ資産とコンポーネントを明確に識別します。 結果に関する明確な目標が必要です。 目的は、より迅速なトリアージ、高速ディザスター リカバリー、または規制監査です。 目的を明確に理解すると、分類作業のサイズを正しく設定できます。

次の簡単な質問から始め、システムの複雑さに基づいて必要に応じて拡張します。

  • データと情報の種類の原点は何ですか?
  • アクセスに基づく予期される制限は何ですか? たとえば、公開情報データ、規制、またはその他の予想されるユース ケースですか?
  • データフットプリントは何ですか? データはどこに格納されているか データを保持する必要がある期間はどのくらいですか?
  • アーキテクチャのどのコンポーネントがデータと対話しますか?
  • データはどのようにシステム内を移動しますか?
  • 監査レポートにはどのような情報が必要ですか?
  • 実稼働前データを分類する必要がありますか?

データ ストアのインベントリを取得する

既存のシステムがある場合は、スコープ内にあるすべてのデータ ストアとコンポーネントのインベントリを取得します。 一方、新しいシステムを設計する場合は、アーキテクチャのデータ フロー ディメンションを作成し、分類定義ごとに最初の分類を行います。 分類はシステム全体に適用されます。 構成シークレットと非シークレットの分類とは明らかに異なります。

スコープを定義する

スコープを定義するときは、細かく明示的にする。 データ ストアが表形式システムであるとします。 テーブル レベルまたはテーブル内の列でも秘密度を分類する必要があります。 また、データの処理に関連している、または一部が含まれている可能性がある非データ ストア コンポーネントに分類を拡張してください。 たとえば、機密性の高いデータ ストアのバックアップを分類しましたか? ユーザーに依存するデータをキャッシュする場合、キャッシュ データ ストアはスコープ内にありますか? 分析データ ストアを使用する場合、集計データはどのように分類されますか?

分類ラベルに従って設計する

分類は、アーキテクチャの決定に影響を与える必要があります。 最も明白な領域は、さまざまな分類ラベルを考慮する必要があるセグメント化戦略です。

たとえば、ラベルはトラフィックの分離境界に影響します。 エンド ツー エンドのトランスポート層セキュリティ (TLS) が必要な重要なフローが存在する場合がありますが、他のパケットは HTTP 経由で送信できます。 メッセージ ブローカー経由で送信されるメッセージがある場合は、特定のメッセージに署名する必要がある場合があります。

保存データの場合、レベルは暗号化の選択に影響します。 二重暗号化を使用して機密性の高いデータを保護することもできます。 異なるアプリケーション シークレットでは、さまざまなレベルの保護を使用した制御が必要になる場合もあります。 ハードウェア セキュリティ モジュール (HSM) ストアにシークレットを格納することを正当化できる場合があります。これにより、より高い制限が提供されます。 コンプライアンス ラベルでは、適切な保護基準に関する決定も決定されます。 たとえば、PCI-DSS 標準では、HSM でのみ使用できる FIPS 140-2 レベル 3 保護の使用が義務付けられています。 それ以外の場合は、他のシークレットを通常のシークレット管理ストアに格納できます。

使用中のデータを保護する必要がある場合は、コンフィデンシャル コンピューティングをアーキテクチャに組み込むことができます。

分類情報は、システムを介してワークロードのコンポーネント間で遷移するにつれて、データと共に移動する必要があります 。 機密としてラベル付けされたデータは、それを操作するすべてのコンポーネントによって機密として扱われる必要があります。 たとえば、あらゆる種類のアプリケーション ログから個人データを削除または難読化することで、個人データを保護してください。

分類は、データを 公開する方法でレポートの設計に影響します。 たとえば、情報型ラベルに基づいて、情報型ラベルの結果として難読化用のデータ マスク アルゴリズムを適用する必要がありますか? 生データとマスクされたデータを可視化する必要があるロールはどれですか? レポートのコンプライアンス要件がある場合、データは規制と標準にどのようにマップされますか? この理解があれば、特定の要件への準拠を示し、監査者向けのレポートを生成する方が簡単です。

また、データの保持や使用停止のスケジュールなど、データ ライフサイクル管理操作にも影響します。

クエリに分類を適用する

分類ラベルを識別されたデータに適用するには、さまざまな方法があります。 ラベルを示す最も一般的な方法は、メタデータで分類スキーマを使用することです。 スキーマを使用した標準化により、レポートが正確であり、バリエーションの可能性を最小限に抑え、カスタム クエリの作成を回避できます。 無効なエントリをキャッチするための自動チェックを作成します。

ラベルは、手動で、プログラムで適用することも、両方の組み合わせを使用することもできます。 アーキテクチャの設計プロセスには、スキーマの設計を含める必要があります。 既存のシステムがある場合でも、新しいシステムを構築する場合でも、ラベルを適用する場合は、キーと値のペアの一貫性を維持します。

すべてのデータを明確に分類できるわけではないことに注意してください。 分類できないデータをレポートで表現する方法について明示的に決定します。

実際の実装は、リソースの種類によって異なります。 特定の Azure リソースには、組み込みの分類システムがあります。 たとえば、Azure SQL Server には分類エンジンがあり、動的マスクをサポートし、メタデータに基づいてレポートを生成できます。 Azure Service Busでは、メタデータを添付できるメッセージ スキーマを含めることができます。 実装を設計するときは、プラットフォームでサポートされている機能を評価し、それらを利用します。 分類に使用されるメタデータが分離され、データ ストアとは別に格納されていることを確認します。

ラベルを自動的に検出して適用できる特殊な分類ツールもあります。 これらのツールは、データ ソースに接続されています。 Microsoft Purview には自動検出機能があります。 同様の機能を提供するサードパーティ製のツールもあります。 検出プロセスは、手動検証によって検証する必要があります。

データ分類を定期的に確認します。 分類のメンテナンスは操作に組み込む必要があります。そうしないと、古いメタデータによって、特定された目的とコンプライアンスの問題に対して誤った結果が発生する可能性があります。

トレードオフ: ツールのコストのトレードオフに注意してください。 分類ツールにはトレーニングが必要であり、複雑になる可能性があります。

最終的には、分類は中央のチームを通じてorganizationにロールアップする必要があります。 予想されるレポート構造に関する入力を取得します。 また、一元化されたツールとプロセスを利用して組織を調整し、運用コストも軽減します。

Azure ファシリテーション

Microsoft Purview は、Azure Purview と Microsoft Purview ソリューションを統合して、organization全体のデータ資産を可視化します。 詳細については、「Microsoft Purview とは」を参照してください。

Azure SQL Database、Azure SQL Managed Instance、Azure Synapse Analytics には、組み込みの分類機能が用意されています。 これらのツールを使用して、データベース内の機密データの検出、分類、ラベル付け、レポートを行います。 詳細については、「データの 検出と分類」を参照してください。

この例は、 セキュリティ ベースライン (SE:01) で確立された情報技術 (IT) 環境に基づいています。 次の図の例は、データが分類されるデータ ストアを示しています。

organizationのデータ分類の例を示す図。

  1. データベースとディスクに格納されているデータには、管理者、データベース管理者など、少数のユーザーのみがアクセスできる必要があります。 通常、一般的なユーザーまたは顧客の最終クライアントは、アプリケーションやジャンプ ボックスなど、インターネットに公開されているレイヤーにのみアクセスできます。

  2. アプリケーションは、オブジェクト ストレージやファイル サーバーなど、ディスクに格納されているデータベースまたはデータと通信します。

  3. 場合によっては、オンプレミス環境とパブリック クラウドにデータが格納される場合があります。 どちらも一貫して分類する必要があります。

  4. オペレーターのユース ケースでは、リモート管理者は、クラウドまたはワークロードを実行している仮想マシン上のジャンプ ボックスにアクセスする必要があります。 アクセス許可は、データ分類ラベルに従って付与する必要があります。

  5. データは仮想マシンを介してバックエンド データベースに移動し、データはトラバーサル ポイント全体で同じレベルの機密性で処理する必要があります。

  6. ワークロードでは、仮想マシン ディスクにデータが直接格納されます。 これらのディスクは分類の対象になります。

  7. ハイブリッド環境では、異なるペルソナがさまざまなメカニズムを介してオンプレミスのワークロードにアクセスして、異なるデータ ストレージ テクノロジまたはデータベースに接続する場合があります。 分類ラベルに従ってアクセス権を付与する必要があります。

  8. オンプレミス サーバーは、ファイル サーバー、オブジェクト ストレージ、さまざまな種類のデータベース (リレーショナル、SQL なし、データ ウェアハウスなど) など、分類および保護する必要がある重要なデータに接続します。

  9. Microsoft Purview コンプライアンスは、ファイルとメールを分類するソリューションを提供します。

  10. Microsoft Defender for Cloud は、上記のケースで説明したデータの格納に使用されるサービスの多くを含め、会社が環境内のコンプライアンスを追跡するのに役立つソリューションを提供します。

組織の配置

クラウド導入フレームワークは、ワークロード チームが組織の分類に従うことができるようにデータを分類する方法に関するガイダンスを中央チームに提供します。

詳細については、「データ分類とは - クラウド導入フレームワーク」を参照してください。

次のステップ

推奨事項の完全なセットを参照してください。