セキュリティドメイン: データ処理のセキュリティとプライバシー

[アーティクル]
03/05/2024

このセキュリティドメインは、Microsoft 365 から使用されるデータが転送中と保存時の両方で適切に保護されるように設計されています。また、このドメインは、GDPR (一般データ保護規則) と HIPAA (1996 年の医療保険の移植性と説明責任に関する法律) に従って、消費者 (データ主体) のプライバシーに関する懸念が ISV によって満たされていることを保証します。

転送中のデータ

Microsoft 365 で開発されたアプリ/アドインの接続要件は、パブリックネットワーク (特にインターネット) を介した通信を必要とします。そのため、転送中のデータは適切に保護する必要があります。このセクションでは、インターネット経由のデータ通信の保護について説明します。

コントロール No. 1

以下のすべての証拠を提供してください。

TLS 構成が TLS1.2 以降であることを検証します。
信頼されたキーと証明書のインベントリが保持され、維持されます。

意図: TLS

このサブポイントの目的は、組織によって使用されている Microsoft 365 データが安全に送信されるようにすることです。 TLS プロファイル構成は、中間者攻撃に対するトラフィックのセキュリティを確保するのに役立つ TLS 固有の要件を定義するために使用されます。

ガイドライン: TLS

これを証明する最も簡単な方法は、標準以外のポートで実行されるすべての Web リスナーに対して Qualys SSL Server テストツールを実行することです。

[ボードに結果を表示しない] オプションをオンにしてください。これにより、URL が Web サイトに追加されなくなります。

TLS プロファイル構成要件は、個々のチェックの証拠を提供することで示すことができます。 TLS 圧縮の無効化など、特定の設定の証拠を提供するために、構成設定、スクリプト、ソフトウェアツールを利用できます。

証拠の例: TLS

次のスクリーンショットは、Webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net の Qualys による SSL スキャンの結果を示しています。

Qualys レポートによる SSL スキャン

[プロトコル] セクションでは、TLS1.2 がサポートされている/有効な唯一のプロトコルであることを示します。

Qualys レポートによる SSL スキャン

注: 認定アナリストは、TLS プロファイル構成要件のすべての要件が満たされていることを確認するために、スキャンの完全な出力を確認します。想定されるのは、スコープ内のバックエンド環境にパブリックに公開されているすべてのエンドポイント (IP アドレスと URL) に対してスキャンが提供されることです。提供された証拠に応じて、アナリストは独自の Qualys スキャンを実行できます。

証拠の例: TLS

次のスクリーンショットは、Azure App Service の TLS の構成設定と、PowerShell 経由の TLS 列挙を示しています。

Azure Web アプリの構成設定

意図: キーと証明書

このサブポイントの目的は、信頼されたキーと証明書の包括的なインベントリを確実に維持することです。これには、これらの暗号化要素に依存するさまざまなシステム、サービス、アプリケーションの識別が含まれます。

ガイドライン: キーと証明書

証拠は、信頼されたキーと証明書のインベントリが存在し、維持されていることを示す必要があります。さらに、Azure Key Vault、HashiCorp Vault Secrets、Confluence Cloud など、実際のキーと証明書を格納するために使用されるツールの適用可能な証拠を提供できます。

証拠の例: キーと証明書

次のスクリーンショットは、Confluence Cloud でキーと証明書インベントリが維持されていることを示しています。

Confluence 証明書インベントリ。

次のスクリーンショットは、信頼されたキーと証明書の承認済みの一覧を示しています。これには、証明書、キー、サイファー、インストールされているシステムなどの詳細が含まれます。

Confluence 証明書インベントリ。

次のスクリーンショットは、HashiCorp Vault からのスクリーンショットです。インベントリ一覧にアウトライン表示され、記録されている証明書は、このオンラインコンテナーに格納されています。 HashiCorp Vault は、シークレット管理、サービスとしての暗号化、特権アクセス管理のためのオープンソースツールです。

Hashicorp Vaults ダッシュボード。

次のスクリーンショットは、実際の証明書とオンラインコンテナー内に格納されているキーの抽出です。

Hashicorp Vaults ダッシュボード。

注: キーのストレージの場所に適切なアクセス制御が設定されていることが予想されます。秘密キーが侵害された場合、正当な証明書でサーバーを偽装する可能性があります。

証拠の例: キーと証明書

信頼されたキーと証明書のインベントリは、次のスクリーンショットに示すようにインベントリ機能を提供する Microsoft 365 Defender で管理することもできます。

Microsoft Defender インベントリページ。

次のスクリーンショットは、証明書の詳細を示しています。

Microsoft Defender インベントリページ。

注: これらの例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンドプロンプトから実行できます。

コントロール No. 2

以下のすべての証拠を提供してください。

CRIME を防ぐために Web 要求を処理するすべての公開サービスに対して TLS 圧縮が無効になっていることを示します (圧縮率情報漏えいが簡単になりました)。
TLS HSTS が有効になっており、すべてのサイトで 180 日間に構成されていることを検証します。

意図: TLS

CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) 攻撃は、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) プロトコルの圧縮の脆弱性です。このため、業界の推奨事項は、SSL 圧縮を無効にすることです。
HTTP Strict Transport Security (HSTS) は、"Strict-Transport-Security" という名前の HTTPS 応答ヘッダーフィールドを使用して TLS 接続を強制することで、中間者攻撃から Web サイトを保護するように設計されたセキュリティメカニズムです。

ガイドライン: TLS

これは、Qualys SSL Labs ツールを使用して証明できます。証拠の例: TLS

次のスクリーンショットは、SSL/TLS 圧縮が無効になっていることを示しています。

Qualys SSL Labs ツールレポート。

次のスクリーンショットは、HSTS が有効になっていることを示しています。

Qualys SSL Labs ツールレポート。

注: 認定アナリストは、TLS プロファイル構成要件のすべての要件が満たされていることを確認するために、完全な出力を確認します (完全なスキャン出力のスクリーンショットを提供してください)。提供された証拠に応じて、アナリストは独自の Qualys スキャンを実行できます。

HSTS が有効になっていることを確認するために使用できるその他のツールは、"HTTP ヘッダースパイ" であり、

securityheaders.com 次の例に示すようにします。追加の証拠

セキュリティヘッダーの構成設定などのスクリーンショット、特に HSTS を使用して、パブリックフットプリントのセキュリティ態勢をさらに示すことができます。

次のスクリーンショットは、Azure Front Door の構成と、ヘッダーの書き換えに実装されたルールセットを示しています。

Azure Front Door の構成設定

次のスクリーンショットは、セキュリティヘッダースキャンが実行され、HSTS だけでなく、すべてのセキュリティヘッダーが実装されていることを示しています。

セキュリティレポートの概要

注: Qualys SSL スキャナーまたはセキュリティヘッダーを使用する場合、完全なレポートがレビュー用に提供されていることが想定されます。

保存データ

Microsoft 365 プラットフォームから使用されるデータが ISV によって格納される場合は、データを適切に保護する必要があります。このセクションでは、データベースとファイルストアに格納されるデータの保護要件について説明します。

コントロール No. 3

保存データが、AES、Blowfish、TDES、128 ビット、256 ビットの暗号化キーサイズなどの暗号化アルゴリズムを使用して、暗号化プロファイル要件に沿って暗号化されていることを実証できる証拠を提供します。

意図:

一部の古い暗号化アルゴリズムには、いくつかの暗号化の弱点が含まれていることが知られています。これにより、脅威アクターがキーを知らなくてもデータを復号化できる可能性が高くなります。このため、この制御の目的は、格納されている M365 データを保護するために、業界で受け入れられた暗号化アルゴリズムのみを使用することです。

ガイドライン:

証拠は、データベースやその他のストレージの場所内の M365 データを保護するために使用されている暗号化を示すスクリーンショットを使用して提供できます。この証拠は、暗号化構成が Microsoft 365 認定資格の暗号化プロファイル構成要件に沿った状態であることを示している必要があります。

証拠の例:

次のスクリーンショットは、Contoso データベースで TDE (Transparent Data Encryption) が有効になっていることを示しています。 2 番目のスクリーンショットは、Azure TDE に AES 256 暗号化が使用されていることを示す、 SQL Database、SQL Managed Instance、Azure Synapse Analytics の透過的なデータ暗号化に関する Microsoft ドキュメントページを示しています。

SQL Transparent Data encyption 設定

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしているユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

Microsoft learn Azure SQL ドキュメント。

証拠の例:

次のスクリーンショットは、BLOB とファイルの暗号化を使用して構成された Azure Storage を示しています。次のスクリーンショットは、Azure Storage が暗号化に AES-256 を使用していることを示す、保存データの Azure Storage 暗号化に関する Microsoft ドキュメントページを示しています。

Azure ストアアカウントの暗号化設定

Microsoft は、Azure Storage 暗号化に関するドキュメントを学習します。

データの保持、バックアップ、破棄

ISV が Microsoft 365 データを使用して格納する場合、脅威アクターが ISV 環境を侵害した場合、データ侵害のリスクがあります。このリスクを最小限に抑えるために、組織はサービスを提供するために必要なデータのみを保持し、将来使用される可能性のあるデータは保持しないようにする必要があります。さらに、データは、データがキャプチャされたサービスを提供するために必要な期間だけ保持する必要があります。データ保持を定義し、ユーザーと通信する必要があります。定義された保持期間を超えたデータは、データを再構築または回復できないように安全に削除する必要があります。

コントロール No. 4

承認されたデータ保持期間が正式に確立され、文書化されていることを証明してください。

意図:

文書化および従った保持ポリシーは、一般的なデータ保護規則 (EU GDPR) やデータ保護法 (英国 DPA 2018) などのデータプライバシーに関する法律を満たすだけでなく、組織のリスクを制限するためにも重要です。組織のデータ要件と、ビジネスが機能を実行するために必要なデータの時間を理解することで、組織は、その有用性が期限切れになるとデータが適切に破棄されるようにすることができます。格納されるデータの量を減らすことで、組織はデータ侵害が発生した場合に公開されるデータの量を減らしています。これにより、全体的な影響が制限されます。

多くの場合、組織は、念のためデータを格納します。ただし、組織がサービスまたはビジネス機能を実行するためにデータを必要としない場合は、組織のリスクが不必要に増加するため、データを格納しないでください。

このコントロールの目的は、組織が、関連するすべての種類のデータに対して承認されたデータ保持期間を正式に確立し、文書化したことを確認することです。これには、さまざまな種類のデータを格納する期間を指定するだけでなく、データの削除または期限切れ後のアーカイブの手順の概要も含まれます。

ガイドライン:

ビジネスがビジネス機能を実行できるように、(すべてのデータ型をカバーする必要がある) データを保持する必要がある期間を明確に説明する完全なデータ保持ポリシーを提供します。

証拠の例:

次のスクリーンショットは、Contoso のデータ保持ポリシーを示しています。

データ保持ポリシードキュメント。

注: これらのスクリーンショットは、ポリシー/プロセスドキュメントのスナップショットを示しています。 ISV は、実際のサポートポリシー/手順のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

コントロール No. 5

コントロール 4 で説明されているように、定義された保持期間に対してのみデータが保持されることを示します。

意図:

このコントロールの目的は、定義されたデータ保持期間が満たされていることを単に検証することです。既に説明したように、組織は、これを満たす法的義務を負うだけでなく、必要なデータを保持することで、必要な限り、データ侵害が発生した場合に組織へのリスクを軽減するのに役立ちます。これにより、データが過度に長い期間保持されることも、早期に削除されることもありません。どちらも、法律、運用、またはセキュリティに関連するさまざまな性質のリスクを引き起こす可能性があります。

ガイドライン:

保存されたデータ (データベース、ファイル共有、アーカイブなど) が定義されたデータ保持ポリシーを超えていないことを示すスクリーンショットの証拠 (またはスクリーン共有経由) を提供します。たとえば、次のスクリーンショットを示します。

日付フィールドを持つデータベースレコード、最も古いレコード順で検索されたレコード、および/または
保持期間内のタイムスタンプを示すファイルストレージの場所注: 個人または機密性の高い顧客データは、スクリーンショット内で編集する必要があります。

証拠の例:

次の証拠は、データベース内の最も古いレコードを表示するために、'DATE_TRANSACTION' フィールドで昇順で並べ替えられたデータベーステーブルの内容を示す SQL クエリを示しています。これは、定義された保持期間を超えない 2 か月未満のデータであることを示しています。

SQL クエリエディター。

注: これはテストデータベースであるため、その中に多くの履歴データはありません。

注: 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL を示す完全なスクリーンショットである必要があります。ログインしているユーザーとシステムの時刻と日付。

コントロール No. 6

保持期間後にデータを安全に削除するためのプロセスが実施されていることを示します。

意図:

このコントロールの目的は、保持期間を超えるデータを削除するために使用されるメカニズムが安全に行われるようにすることです。削除されたデータは、回復される場合があります。そのため、削除プロセスは、削除後にデータを復旧できないように十分な堅牢性が必要です。

ガイドライン:

削除プロセスがプログラムによって実行される場合は、これを実行するために使用されるスクリプトのスクリーンショットを提供します。スケジュールで実行される場合は、スケジュールを示すスクリーンショットを提供します。たとえば、ファイル共有内のファイルを削除するスクリプトを CRON ジョブとして構成し、スケジュールと実行されるスクリプトを示す CRON ジョブをスクリーンショットします。をクリックし、使用するコマンドを示すスクリプトを指定します。

証拠の例:

これは、日付に基づいて保持されているすべてのデータレコードを削除するために使用できる単純なスクリプトです。WHERE DateAdd は -30 日であり、選択したデータ保持日の 30 日を超える古い保持レコードをすべて消去します。スクリプトが必要であることに注意してください。実行されているジョブと結果の証拠。

スクリプトの行。

証拠の例:

次のスクリーンショットは、Contoso データ保持ポリシー (コントロール 4 から) から取得されています。これは、データの破棄に使用される手順を示しています。

データ保持ポリシードキュメント。

注: このスクリーンショットは、ポリシー/プロセスドキュメントのスナップショットを示しています。 ISV は、実際のサポートポリシー/手順のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

証拠の例:

この例では、Runbook が作成され、Azure で対応するスケジュールが作成され、データレコード保持ポリシーの有効期限が切れてから 30 日後に作成された終了日を持つレコードを安全に削除します。このジョブは、月の最終日に毎月実行されるように設定されます。

Azure データ保持設定。

次のスクリーンショットは、Runbook がレコードを検索するように編集され、スクリプトのような削除コマンドが表示されていないことを示しています。

Azure データ保持設定。

注: これらのスクリーンショットでは完全な URL とユーザー名が表示されている必要があり、削除前レコード数のスクリーンショットと削除後レコード数のスクリーンショットを表示するには ISV が必要です。

Azure データ保持設定。

これらのスクリーンショットは、これがアプローチできるさまざまな方法の純粋な例です。

Azure データ保持設定。

コントロール No. 7

以下を示す証拠を提出してください。

自動バックアップシステムが用意されており、スケジュールされた時刻にバックアップを実行するように構成されています。
バックアップ情報は、バックアップスケジュール手順に沿ってテストされ、データの信頼性と整合性を確認するために定期的に復元されます。
適切なアクセス制御と保護メカニズム (つまり、変更できないバックアップ) は、未承認のアクセスに対してバックアップ/システムスナップショットがセキュリティで保護されていることを確認し、バックアップデータの機密性、整合性、可用性を確保するために実装されます。

意図:

このコントロールの目的は、組織に自動バックアップシステムが用意されていることを確認することです。このシステムは、事前に設定された時刻にバックアップを実行するように構成されています。

ガイドライン:

バックアップがスケジュールされた期間/間隔で実行されていることを示すバックアップソリューションの構成設定のスクリーンショットを提供してください。バックアップスケジュールがソリューションによって自動的に実行される場合は、ベンダーのドキュメントを提供することでこれをサポートできます。

証拠の例:

次のスクリーンショットは、マネージドインスタンスである Azure Database for MySQL に適用されます。これは、最初の自動バックアップが完了したことを示します。

Azure のバックアップと復元の設定。

次のスクリーンショットは、期間が経過した後に作成され、さらに完全バックアップが行われたことを示しています。フレキシブルサーバー上のバックアップはスナップショットベースであり、サーバーの作成直後に最初のスナップショットバックアップがスケジュールされ、さらにスナップショットバックアップが毎日 1 回作成されます。

Azure のバックアップと復元の設定。

次のスクリーンショットは、バックアップの頻度と自動バックアップ機能の概要を示すオンラインドキュメントのスナップショットを示しています。

自動バックアップドキュメントを learn.microsoft.com します。

意図:

この制御の目的は、バックアップ情報がスケジュールごとに生成されるだけでなく、信頼性も高く、時間の経過と同時にその整合性を維持することを実証することです。この目的を達成するために、バックアップデータに対して定期的なテストが実行されます。

ガイドライン:

このコントロールを満たす証拠は、バックアップデータをテストするための組織のプロセスと手順に依存します。過去のテスト完了の記録と共にバックアップが正常にテストされていることを示す証拠を提供できます。

証拠の例:

次のスクリーンショットは、バックアップスケジュールと復元手順が存在し、維持されていること、および Confluence プラットフォームで実行されるバックアップの頻度を含むすべての適用可能なシステムに対してバックアップ構成が定義されていることを示しています。

Confluence のバックアップと復元の設定。

次のスクリーンショットは、該当する各システムのバックアップテストの履歴レコードのページを示しています。テーブルの右側にある JIRA チケットが各テストで参照されていることを確認します。

Confluence のバックアップと復元の設定。

次の 4 つのスクリーンショットは、スナップショットから Azure Database for MySQL を復元するエンドツーエンドのプロセスを示しています。 [高速復元] オプションを使用して、SQL データベースの復元プロセスを開始できます。

Azure のバックアップと復元の設定。

次のスクリーンショットは、復元をカスタマイズできる構成ページを示しています。

Azure のバックアップと復元の設定。

データベースの復元元となるターゲットの場所、ネットワーク、スナップショットが選択されたら、デプロイを開始できます。データベースインスタンスが 'test' と呼ばれるようになったことを確認します。

Azure デプロイの概要。

次に示すように、合計 5 分後に SQL データベースが正常にバックアップスナップショットから完全に復元されました。

Azure デプロイの概要。

テストが完了すると、プロセスに沿って、実行されたバックアップテストと復元の詳細を記録するために JIRA チケットが作成されました。これにより、コンプライアンス上の目的で履歴データを使用できるだけでなく、インシデントまたは災害の最終的なレビューのために完全なレコードが存在し、組織が根本原因分析を実行できるようにします。

Jira バックアップチケット。

意図:

前の制御に進み、アクセス制御を実装して、バックアップデータを担当する個々のユーザーのみにアクセスを制限する必要があります。アクセスを制限することで、未承認の変更が実行されるリスクを制限し、安全でない変更が発生します。バックアップを保護するには、最小限の特権を持つアプローチを講じておく必要があります。

データを適切に保護するには、組織が環境やシステムで使用しているデータと、データが格納されている場所を認識する必要があります。これが完全に理解され、文書化されたら。

組織は、適切なデータ保護を実装するだけでなく、データが配置されている場所を統合して保護をより効果的に実装することもできます。さらに、データをできるだけ少ない場所に統合する場合は、適切な RBAC (ロールベースのアクセス制御) を実装して、必要に応じて少数の従業員にアクセスを制限する方がはるかに簡単です。

ガイドライン:

承認されたアクセスリストのサポートドキュメントを使用して、バックアップとバックアップソリューションへのアクセス許可を示すシステム/テクノロジから証拠を提供する必要があります。

証拠の例:

次のスクリーンショットでは、アクセス制御がデータベースインスタンスに実装され、ジョブロールに基づいて承認された個人のみにアクセスを制限していることがわかります。

Azure アクセス制御ダッシュボード。

証拠の例:

Azure SQL Database と Azure SQL Managed Instances の自動バックアップは Azure によって管理され、その整合性は Azure プラットフォームの責任です。ユーザーはそれらにアクセスできないため、ランサムウェア攻撃の可能性なく保存時に暗号化されます。また、保護のために他のリージョンにもレプリケートされます。

Azure SQL ポリシードキュメントを learn.microsoft.com します。

データアクセス管理

データアクセスでは、データが悪意を持ってまたは誤って侵害される可能性を減らすために、必要な人数に制限する必要があります。データと暗号化キーへのアクセスは、仕事の役割を果たすためにアクセスするための正当なビジネスニーズを持つユーザーに限定する必要があります。アクセスを要求するための十分に文書化された、十分に確立されたプロセスを実装する必要があります。データと暗号化キーへのアクセスは、最小限の特権原則に従う必要があります。

コントロール No. 8

データや暗号化キーへのアクセス権を持つ個人の一覧を示す証拠を提供します。

一人ひとりの事業上の正当な理由を含め、維持されます。
は、ジョブ機能に必要なアクセス特権に基づいて正式に承認されました。
は、承認に記載されている特権で構成されます。

意図:

組織は、データと暗号化キーへのアクセスをできるだけ少ない従業員に制限する必要があります。この制御の目的は、データや暗号化キーへの従業員のアクセスが、そのアクセスに対する明確なビジネスニーズを持つ従業員に制限されるようにすることです。

ガイドライン:

データや暗号化キーへのアクセス権を持つすべての従業員と、これらの個人がアクセス権を持つ理由のビジネス上の正当な理由を文書化する内部システムのドキュメントまたはスクリーンショット。この一覧は、次のコントロールのサンプルユーザーに対して認定アナリストによって使用されます。

証拠の例:

次のドキュメントは、データへのアクセス権とビジネス上の正当な理由を持つユーザーの文書化された一覧を示しています。

承認済みのユーザーアクセスドキュメント。

注: このスクリーンショットはポリシー/プロセスドキュメントを示しています。ISV が実際のサポートポリシー/プロシージャドキュメントを共有することが想定されています。

意図:

データや暗号化キーへのアクセスを許可するプロセスには、承認が含まれている必要があります。個人のアクセス権がジョブ機能に必要であることを確認します。これにより、アクセスの真の理由のない従業員が不要なアクセス権を取得しないようにします。

ガイドライン:

通常、前のコントロールに対して提供された証拠は、このコントロールをサポートするのに役立ちます。提供されたドキュメントに正式な承認がない場合、証拠は、Azure DevOps や Jira などのツール内のアクセスに対して発行および承認される変更要求で構成される場合があります。

証拠の例:

この一連の画像は、機密データや暗号化キーへのアクセスを許可または拒否するために、コントロール (i) に対して作成および承認された Jira チケットを示しています。この画像は、システムバックエンド環境で暗号化キーの Sam Daily 承認を取得するための要求が Jira で作成されたことを示しています。これは、書面による承認が得られた次の手順として行われます。

Jira 承認チケット。

これは、Sam Daily へのアクセス権を付与する要求が、Jon Smith によって管理者から承認されたことを示しています。 (承認は、変更要求を許可するための十分な権限を持つユーザーから取得する必要があります。別の開発者にすることはできません)。

プロセスフローチャート。

前の図は、このプロセスの Jira のワークフローを示しています。承認プロセスが自動化され、バイパスできない場合を除き、[完了] として何も追加できないことに注意してください。

Jira 承認委員会。

プロジェクトボードは、Sam Daily の暗号化キーへのアクセスに対する承認が与えられていることを示しています。次のバックログは、Sam Daily の要求の承認と、作業を行うために割り当てられたユーザーを示しています。

Jira 承認委員会。

このコントロールの要件を満たすには、これらのスクリーンショットまたは類似/同等の証拠をすべて表示し、コントロール要件を満たしていることを示す説明を示す必要があります。

証拠の例:

次の例では、運用 DB に対するユーザーに対して管理者アクセス許可とフルコントロールアクセス許可が要求されています。要求は、画像の右側に表示されるように承認のために送信され、これは左側に示すように承認されています。

Jira 承認委員会。

次の画像は、アクセスが承認され、完了したとおりにサインオフされたことを示します。

Jira 承認委員会。

Intent

このサブポイントの目的は、データや暗号化キーのアクセスがドキュメントに従って構成されていることを確認することです。

ガイドライン:

証拠は、サンプリングされた個人に付与されたデータや暗号化キーのアクセス権限を示すスクリーンショットを使用して提供できます。証拠はすべてのデータの場所をカバーする必要があります。

証拠の例:

このスクリーンショットは、ユーザー "John Smith" に付与されるアクセス許可を示しています。

前のコントロールの証拠に従って、この同じユーザーの承認要求に対して参照されます。

注: 次の例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信する必要があります。ログインユーザーと証拠レビューの日時スタンプ。 Linux ユーザーの場合は、コマンドプロンプトから実行できます。

Linux クエリエディター。

コントロール No. 9

次の証拠を提供します。

データが共有されているすべてのサードパーティの一覧が保持されます。
データ共有契約は、すべてのサードパーティが使用するデータと結び付けられます。

意図:

サードパーティが Microsoft 365 データの保存または処理に使用される場合、これらのエンティティは重大なリスクを伴う可能性があります。組織は、これらの第三者がデータを安全に保存/処理し、GDPR の下でデータ処理者としてなど、法的義務を確実に遵守できるように、適切なサードパーティのデューデリジェンスと管理プロセスを開発する必要があります。

組織は、次の一部またはすべてとデータを共有するすべてのサードパーティの一覧を保持する必要があります。

提供されているサービス
共有されるデータ
データが共有される理由
キー連絡先情報 (プライマリ連絡先、侵害通知連絡先、DPO など)
契約の更新/有効期限
法的/コンプライアンス義務 (GDPR、HIPAA、PCI DSS、FedRAMP など)

ガイドライン:

Microsoft 365 データを共有するすべてのサードパーティについて詳しく説明するドキュメントを提供します。

注: サードパーティが使用されていない場合は、上級リーダーシップチームのメンバーが書面 (電子メール) で確認する必要があります。

証拠の例:

データ共有契約。

注: - 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしているユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

証拠の例:

次のスクリーンショットは、Microsoft 365 データの処理にサードパーティが使用されていないことを確認するシニアリーダーシップチームのメンバーの電子メールの例を示しています。

CEO からのメール。

注: - これらの例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしたユーザーとシステムの時刻と日付を示す完全なスクリーンショットである必要があります。

意図:

M365 データがサードパーティと共有されている場合は、データが適切かつ安全に処理されていることが重要です。第三者が必要な場合にのみデータを処理し、セキュリティ上の義務を理解するために、データ共有契約を締結する必要があります。組織のセキュリティは、最も弱いリンクと同じくらい強力です。このコントロールの目的は、サードパーティが組織の脆弱なリンクにならないようにすることです。

ガイドライン:

第三者と締結されているデータ共有契約を提供します。

証拠の例:

次のスクリーンショットは、データ共有契約の単純な例を示しています。

データ共有契約。

注: 完全な契約は、スクリーンショットではなく共有する必要があります。

プライバシー

プライバシーコンプライアンスと情報管理は、個人の権利を保護し、責任あるデータ処理を確保するために不可欠です。組織が効果的なプライバシー情報システムを確立するには、保有する個人データと、そのようなデータの処理と保存の目的を認識する必要があります。組織は、さまざまな種類の処理が発生している可能性があることを認識して、情報のフローと処理方法をマップする必要があります。

コントロール No. 10

組織には、プライバシー情報管理 (PIM) システムが確立され、実装され、維持されていますか。

ポリシーまたはその他の形式のドキュメント/コンピューター化されたシステムを使用して、プライバシー情報管理の取り組みをシステムの機密性と整合性のために維持する方法に関するリーダーシップコミットメントを保持します。
PII プロセッサやコントローラーなど、システムを保守する各ユーザーの役割、責任、権限を決定します。

意図:

この点の目的は、「プライバシーの文化」が存在し、効果的なプライバシーガバナンスプログラムを通じて組織のリーダーシップによってサポートされることを保証することです。組織の管理は、確立されたドキュメントとプロセスを通じて、効果的なプライバシー管理システムがあることを示す必要があります。プロセスは組織の戦略的目標に沿っており、組織のコンテキストと状況の中で確立され、プライバシー管理システムがビジネスプロセスに埋め込まれているようにする必要があります。

ガイドライン:

これは、プライバシー情報管理 (PIM) ポリシーと手順を示す組織の確立されたドキュメントを提供することで証明されます。認定アナリストはこれを確認して、コントロール内で提供されるすべての情報に対処します。

証拠の例:

次のスクリーンショットは、PIM ポリシーのスナップショットを示しています。

プライバシー情報管理ポリシーに関するドキュメント。

注: ISV は、実際のサポートポリシー/手順のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

Intent

アビリティは、組織が適切かつ効果的なポリシー、手順、およびプロセスを実装することで、個人データの取り扱いに関連するリスクを最小限に抑えられるようにするため、データ保護法の重要な原則の 1 つです。これらの対策はリスクに比例する必要があります。これは、処理または転送されるデータの量、その機密性、および使用中のテクノロジによって異なる場合があります。これを実現するには、各従業員が、実装を成功させるためにプライバシー管理システムのさまざまな要素を担当するユーザーを把握する必要があります。明確に定義された方法で役割、責任、権限の概要を示す確立されたドキュメントを作成し、それらのロールを適切に割り当てることで、組織はプライバシー管理システムが効果的であることを確認できます。

ガイドライン:

これは、各関係者の役割、責任、権限を示す組織の確立されたドキュメントを提供することで証明されます。認定アナリストはこれを確認して、コントロール内で提供されるすべての情報に対処します。

証拠の例:

次のスクリーンショットは、承認された従業員のリストを含むポリシーのセクションを示す PIM ポリシーのスナップショットを示しています。

プライバシー情報管理ポリシーに関するドキュメント。

注: ISV は、実際のサポートポリシー/手順のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

コントロール No. 11

次のことを示すプロセスの証拠を提供します。

PII 最小化が行われている。
PII の識別解除と削除は、処理期間の終了時に行われています。
PII 転送には、機密性を含む制御が行われます。
ある国/地域から別の国への PII の移転の記録は、同意を表明して存在します。

意図: PII

PII (個人を特定できる情報) の最小化の目的は、組織が組織のコンテキスト内およびビジネス上の正当な理由の範囲内で特定の目的を達成するために必要な最小限の個人データのみを収集、使用、保持できるようにすることです。個人データを処理する場合、組織は、その目標/タスクを達成するために必要な最小限のデータ量を特定し、必要な最小限のデータが格納されていることを確認する必要があります。不要な個人データの処理と保存を最小限に抑えることで、組織はデータの誤用、不正アクセス、データ侵害に関連するリスクのレベルを確実に軽減します。

ガイドライン: PII

証拠は、自動化されたプラットフォームを介して行われる場合、または手動の管理プロセスの場合、個人情報の使用を最小限に抑えるために使用されるソリューションの構成設定によって提供される場合があります。その後、最小化プロセスの証拠と発生したプロセスの記録の証拠をアナリストに提供してレビューを行う必要があります。

証拠の例: PII

次のスクリーンショットは、その期間内に組織内で受信したすべての新しいデータがレビューされ、該当する場合は不要と見なされる個人情報が削除される、定期的な毎月の会議がスケジュールされていることを示しています。

Outlook の定期的なイベントリマインダー。

次のスクリーンショットでは、プラットフォーム内の新しい顧客のオンボードに使用される入力されたユーザー登録フォームの例を示します。

新しい顧客登録フォーム。

次のスクリーンショットは、PII 最小化会議とレビューに基づいて、フォーム内で収集された機密情報の一部が、ユーザーにサービスを提供するために不要になったと見なされたことを示しています。次の画像では、レフリーの PII と電子メールアドレスが削除されています (各組織は、その情報を保持または削除するためのビジネス上の正当な理由を持つことになります)。

新しい顧客登録フォーム。

注: 前の例は、1 つの潜在的なシナリオの例です。それは決して包括的なものであり、証拠を提供する場合、PIIを最小限に抑えるためのプロセスを明確に実証し、組織の特定のコンテキストに適用する必要があります。

意図: データのプライバシー

このサブポイントの目的は多面的であり、いくつかの手法と異なる概念について説明しますが、全体的な目標は、組織全体のデータプライバシーが強化されることによって、組織がデータ保護規制に準拠できるようにすることです。

識別解除とは、個人をデータから識別するために使用できる特定の情報を削除するプロセスから始まり、電子メールアドレス、生年月日など、機密性の高いと見なされる情報が (仮名化やマスクなど、さまざまな手法を使用して) 変更/変換され、個人に直接リンクできないようにする形式に変換することです。このプロセスの目的は、データのユーティリティを保持するだけでなく、データの誤用、未承認のアクセス、およびデータ侵害に関連するリスクのレベルを確実に減らすことです。

組織は、処理期間の終了時にデータ保持を定義し、不要なデータを削除する必要があります。定義されたデータ保持期間を超えたデータは、再構築または回復できないように安全に削除する必要があります。必要なデータを保持し、必要な限り保持することで、データ侵害が発生した場合の組織のリスクを軽減できます。これにより、データが過度に長い期間保持されることも、早期に削除されることもありません。どちらも、法律、運用、またはセキュリティ関連の性質が異なるリスクを引き起こす可能性があります。

ガイドライン: データのプライバシー

証拠は、PII データが制御要件に沿って匿名化および削除されるようにするために使用されるメカニズムや手法の構成設定によって提供される場合があります。

証拠の例: データのプライバシー

次のスクリーンショットに示す例では、テンプレートギャラリーの一部である Azure Data Factory の組み込みのデータ匿名化テンプレートを使用し、コンテンツを匿名化しながら、一連のテキストファイルをある場所から別の場所に移動できます。これは、AZURE のデータファクトリが PII 匿名化のために存在することを示しています。

Azure Data Factory ダッシュボード。

次のスクリーンショットは、PII 匿名化パイプラインの構成を示しています。 Azure App Service で Presidio を使用して、Azure Data Factory パイプラインの HTTP REST エンドポイントとして Presidio を呼び出し、各ファイルを Azure Blob Storage として解析して格納するためのコードを利用します。

Azure Data Factory ダッシュボード。

次のスクリーンショットは、パイプラインの手順とロジックを示しています。

ワークフローパイプラインの図。

最後のスクリーンショットは、PII を匿名化するためのパイプラインの正常な実行を示しています。

ワークフローパイプラインの図。

注: 前の例は、1 つの潜在的なシナリオの例です。それは決して包括的なものであり、証拠を提供する場合、PIIを匿名化するためのプロセスを明確に実証し、組織の特定のコンテキストに適用する必要があります。

証拠の例: データのプライバシー

次のスクリーンショットは、PII が保持されている Azure のストレージアカウントのライフサイクル管理ポリシーを有効にすることで、処理期間の終了時に PII の削除に対処する例を示しています。

Azure ライフサイクル管理ページ。

次のスクリーンショットは、データが自動的に削除された後の定義済みの期間にリテンション期間が設定されていることを示しています。

Azure ライフサイクル管理ページ。

注: 前の例は、1 つの潜在的なシナリオの例です。これは決して包括的なものであり、証拠を提供する場合は、PII データを削除するためのプロセスと該当する特定の保持期間を明確に示し、組織の特定のコンテキストに適用する必要があります。

証拠の例: データのプライバシー

最後のスクリーンショットは、SharePoint、OneDrive、デバイス、メールボックスなど、組織内のさまざまな場所で PII データ転送とストレージに対してデータライフサイクル管理保持ポリシーが実施されていることを示しています。このポリシーは、Microsoft Purview を使用して有効になっています。アイテム保持ポリシーは、定義済みの保持期間が経過すると、PII を自動的に削除するように構成されます。

Microsoft Purview ライフサイクル管理ページ。

意図: コントロール

このサブポイントの目的は、処理中および転送中に PII を保護するために、組織が適切な技術的および管理上または運用上のセーフガードを確実に実施できるようにすることです。機密性に重点を置いているのは、保存中および転送中のデータの暗号化、文書化されたアクセス制御リスト、定期的な監査など、技術的および管理上の制御を通じて、不正なアクセスや開示からデータをセキュリティで保護することです。

ガイドライン: コントロール

証拠は、PII データが制御要件に沿って保護されるようにするために使用される保護メカニズムの構成設定によって提供される場合があります。このようなメカニズムには、アクセス制御、RBAC、暗号化、データ損失防止などが含まれます。

免責事項: 示されている例は、PII が保護されるようにコントロールが適用される可能性のあるシナリオをいくつか示しています。実施される保護メカニズムの種類は、組織のコンテキストと PII の使用方法、保存方法などに依存します。

証拠の例: 暗号化

次の例は、PII が保持されているストレージの場所での PII の暗号化と、ユーザーがアプリケーションのバックエンドに格納されている個人情報を入力する Web アプリケーション/プラットフォーム経由での転送中の暗号化を示しています。

スクリーンショットは、保存場所に保存データが既定で暗号化されていることを示しています。

暗号化が既定で使用されるプラットフォームと独自の暗号化によって実行されない場合は、注意してください

キーが使用されている場合、それらのキーが適切にセキュリティで保護され、これを示す証拠が提供されていることが期待されます。

Azure 暗号化管理ページ。

2 番目のスクリーンショットは、PII が収集されるアプリケーションに対して TLS1.2 が転送中に適用されることを示しています。

Azure 暗号化管理ページ。

証拠の例: アクセス制御

次のスクリーンショットは、ネットワークの観点から、PII ストレージの場所へのアクセスが許可されている、セキュリティで保護された企業ネットワークである承認された IP 範囲のみを示しています。

Azure ネットワーク管理ページ。

次のスクリーンショットは、Azure PIM の例と、適格な割り当てを持つユーザーリストを示しています。 Just-In-Time (JIT) アクセスを使用することで、ユーザーは特権ロールまたはリソースへの一時的なアクセスを一時的に取得できます。これにより、特権ユーザーが侵害されたり、環境やデータの場所に変更が加えられたりするリスクが減少します。

Microsoft Entra 管理センター。

証拠例: PII 伝達と開示防止

これらのスクリーンショットは、組織が 1 つの一元化された場所から DLP ポリシーを管理できる統合プラットフォームである Microsoft Purview データ損失防止 (DLP) を示しています。

以下では、"英国の PII データ" ポリシーが有効になっていることを確認できます。これにより、ユーザーが、サポートされている Web ブラウザーを介してアクセスしたときに、個人のメール、生成的な AI プロンプト、ソーシャルメディアサイトなど、特定の Web サイトに機密データを提供できないようにすることができます。これにより、すべての職場デバイス/ユーザーに組織ポリシーが適用されるため、従業員による PII の潜在的な機密性侵害や不正な開示のリスクが軽減されます。

Microsoft Purview ポリシー設定。

次のスクリーンショットは、適用されるスコープを含むポリシーの包括的な概要を示しています。ポリシーは、SharePoint、デバイス、OneDrive などの場所のすべてのアカウントに設定されます。

Microsoft Purview ポリシー設定。

前と次のスクリーンショットは、ユーザーが個人を特定できる情報 (PII) などの機密情報をコピーして貼り付けないように DLP ポリシーが設定されていることを示しています

組織の内部データベースから、サポートされているブラウザー上の個人用メールアカウント、チャットボット、ソーシャルメディアサイトに移動します。

Microsoft Purview ポリシー設定。

意図: レコード

このサブポイントの意図は 2 つあります。これにより、データガバナンスとデータ保護を容易にするために効果的なレコード管理が確実に行われる一方で、各国間で個人を特定できる情報を転送する際に、法的要件の移動が含まれるため、法的コンプライアンスとアビリティが確保されます。 PII 移転を開始する前に、組織は、所属するデータ主体から明示的に同意していることを確認する必要があります。移転の目的、および関連するリスクについて、当該個人に通知する必要があります。取得される同意のレコードは、譲渡の承認を検証します。転送のレコードには、転送、リスク評価、データ保護への影響、保持期間の詳細も含める必要があります。

ガイドライン: レコード

PII 転送のレコードと明示的な同意の記録に対して提供できる証拠は、転送プロセスとレコード管理が組織レベルでどのように実装されているかによって異なります。これには、同意がサービスのプラットフォーム、使用条件、または各ユーザーによって入力された同意の形式を通じて取得されるかどうかが含まれます。提供される証拠は、一定期間に完了した移転の履歴レコードが存在し、これが追跡される方法と、明示的な同意が得られた記録を示す必要があります。

証拠の例: レコード

次のスクリーンショットは、組織のサービスのいずれかのユーザーが同意フォームに入力した例を示しています。明示的な同意、確認、および条件の理解がユーザーによって提供されたことがわかります。

同意フォームドキュメント。

次のスクリーンショットは、PII 転送の履歴レコードが存在し、交換される特定の PII データの詳細、転送の目的、配信元の国、転送先の国、転送中のデータの保護、承認などが含まれていることを示しています。

PII の転送のコンフルエンスレコード。

注: 上記は 1 つの潜在的なシナリオの例であり、決して包括的ではありません。証拠を提供する場合、PII データ、レコード管理などを転送するプロセスを明確に示し、組織の特定のコンテキストに適用する必要があります。

ほとんどの組織は、ヨーロッパ市民 (データ主体) データの可能性があるデータを処理します。任意のデータ主体のデータが処理される場合、組織は一般データ保護規則 (GDPR) を満たす必要があります。これは、データコントローラー (ユーザーが直接データをキャプチャしている) またはデータプロセッサ (データコントローラーの代わりにこのデータを処理している) の両方に適用されます。このセクションでは、規制全体については説明しませんが、組織が GDPR を真剣に受け止めているという保証を得るために、GDPR の重要な要素の一部に取り組んでいます。

コントロール No. 12

以下を示す証拠を提供します。

データ主体は SA を発生できます。
SA 要求に応答するときに、ユーザー (ISV) がデータ主体のデータのすべての場所を識別できることを検証します。
バックアップには保持期間があること。これにより、一定期間のローリングバックアップが削除されるときに SA を介してデータの削除を要求するクライアントを削除できます (最も古いバックアップの削除/書き換えのライフサイクル)。

意図:

GDPR には、データ主体のデータを処理する組織が満たす必要がある特定の義務が含まれています。組織がサブジェクトアクセス要求 (SA) を管理する義務は、記事 12.3 の下で、要求に応答するために SAR を受け取ってから 1 か月のデータコントローラーを提供する記事 12 に含まれています。延長は、必要に応じてさらに 2 か月間許可され、その理由がある場合にのみ許可されます。組織がデータプロセッサとして機能している場合でも、顧客 (データコントローラー) が SA の義務を果たすのに役立つ必要があります。

ガイドライン:

SA を処理するための文書化されたプロセスを指定してください。証拠の例:

次の例は、SA の処理に関する文書化されたプロセスを示しています。

サブジェクトアクセス要求の手順に関するドキュメント。

意図:

このコントロールの目的は、組織がすべてのデータ主体のデータを識別するための堅牢なメカニズムを確保することです。これは、すべてのデータストレージが十分に文書化されているため、手動プロセスである場合もあれば、SA プロセスの一部としてすべてのデータを確実に配置するために他のツールを使用することもできます。

ガイドライン:

証拠は、すべてのデータの場所の一覧と、データのすべてのデータの場所を検索するための文書化されたプロセスによって提供される場合があります。これには、データを検索するために必要なコマンドが含まれます。つまり、SQL の場所が含まれている場合は、特定の SQL ステートメントが詳細に表示され、データが正しく見つかることを確認します。

証拠の例:

次のスクリーンショットは、前の SAR の手順のスニペットで、データがどのように見つかるかを示しています。

サブジェクトアクセス要求の手順に関するドキュメント。

次の 4 つの画像は、ISV データの場所がどのようにクエリされたかを示しており、ストレージエクスプローラーを使用して、SAR 要求に準拠するためにストレージから削除する必要があるファイルまたは BLOB にドリルダウンしました。

注: これらの例は全画面表示のスクリーンショットではないため、すべての URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンドプロンプトから実行できます。

[Microsoft Azure ストレージアカウント] ページ。

Microsoft Azure リソースグラフエクスプローラー。

このクエリは、使用中のストレージアカウントを確認します。 Resource Graph Explorer (Kusto) または PowerShell (次を参照) を使用して、ストレージ、BLOB、またはファイルのクエリを実行して削除できます。

Kusto エクスプローラー。

Powershell クエリ。

注: - このセクションの例では、完全なスクリーンショットは使用されませんでしたが、ISV で送信されたすべての証拠のスクリーンショットは、URL、ログインしているユーザーとシステムの時刻と日付を示す全画面表示のスクリーンショットである必要があります。

Microsoft Azure ストレージエクスプローラー。

次の画像は、削除する必要があるクライアントの BLOB コンテナー内で見つかったデータを示し、次の図は、BLOB 内の情報を削除または論理的に削除するアクションを示しています。

Microsoft Azure ストレージエクスプローラー。

注: この例は全画面表示のスクリーンショットではないため、任意の URL を含む全画面表示のスクリーンショットを送信し、ユーザーにログインし、証拠の確認のために時刻と日付スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンドプロンプトから実行できます。

意図:

このコントロールの目的は、SAR に従ったデータの削除に対応するように設計された、バックアップの正式な保有期間が存在することを示することです。リテンション期間フレームワークでは、定義された期間にわたって古いバックアップを段階的に削除し、SAR によって削除されたデータが最終的にすべてのバックアップから消去されるようにする必要があります。これは、組織のバックアップとデータ保持のプラクティスを SA に起因する義務と整合させ、消去する権利に関する規制要件を満たすために重要です。

ガイドライン:

バックアップが実行される期間と手法を示すバックアップ構成設定を示すスクリーンショットを使用して、証拠が提供される場合があります。バックアップ頻度期間に重点を置く必要があります。

証拠の例:

次のスクリーンショットは、マネージドインスタンスである Azure Database for MySQL からの構成設定のスニペットです。

Microsoft Azure SQL の概要。

スクリーンショットでは、バックアップ保有期間が 28 日間設定されていることがわかります。

Microsoft Azure SQL の概要。

バックアップセクションに基づいて、フレキシブルサーバー上のバックアップは、最初のスナップショットバックアップに基づくスナップショットであることがわかっています。これは、サーバーが作成された直後にスケジュールされ、さらにスナップショットバックアップが毎日 1 回作成されます。

28 日間のバックアップ保有期間とバックアップ頻度の組み合わせにより、SAR が実行されると、すべてのユーザーデータが削除されるまで、ローリングバックアップは保持期間によって適用される最大 27 日間のローリングと減少を続けます。

Control No. 13

次のように、必要なすべての要素を含むプライバシーに関する通知を提供してください。

エンティティの詳細 (名前、住所など)
処理される個人データの種類の詳細。
個人データの保持期間の詳細。
個人データの処理の適法性の詳細。
データ主体の権利の詳細:
- 通知を受ける権利
- データ主体によるアクセス権
- 消去する権利
- 処理の制限を受ける権利
- データの移植性に対する権利
- オブジェクトに対する権限
- プロファイリングを含む、自動化された意思決定に関連する権利

意図:

GDPR 第13条には、個人データの取得時にデータ主体に提供しなければならない特定の情報が含まれます。この制御の目的は、組織のデータプライバシーに関する通知で、第 13 条に含まれる重要な情報の一部をデータ主体に確実に提供することです。

ガイドライン:

これは通常、データのプライバシーに関する通知を提供することによって提供されます。認定アナリストはこれを確認して、コントロール内で提供されるすべての情報がデータプライバシー通知に含まれていることを確認します。

証拠の例:

次のスクリーンショットは、プライバシーポリシーのスナップショットを示しています。

注: これらの例は全画面表示のスクリーンショットではありません。すべての URL を含む全画面表示のスクリーンショットを送信する必要があります。ログインユーザーと証拠レビューの日時スタンプ。 Linux ユーザーの場合は、コマンドプロンプトから実行できます。

プライバシーに関する通知に関するドキュメント。

プライバシーに関する通知の画像は、GDPR の第 13 条を含むオンラインプライバシーポリシーの例を示しています。

プライバシーに関する通知に関するドキュメント。

前に示したプライバシー通知と組み合わせて使用できるデータ保護ポリシーを次に示します。

データ保護ポリシードキュメント。

[Azure ポリシーの割り当て] ページ。

Azure の前の画像は、バックエンド環境に格納されているデータに対する GDPR のコンプライアンス要件を満たすように Azure がどのように構成されているかを示しています。ポリシー (Azure Blueprints からカスタム作成または構築できます) を使用すると、ISV はクライアントのデータが正しく格納され、指定されたメトリックによってのみアクセスできることを確認できます。また、コンプライアンスを確保するようにアラートが設定され、コンプライアンスマネージャーダッシュボードに非準拠データまたはユーザーアクセスが表示されます。

注: 前の例は全画面表示のスクリーンショットではないことに注意してください。すべての URL を含む全画面表示のスクリーンショットを送信する必要があります。ユーザーにログインし、証拠の確認のために日時スタンプを送信する必要があります。 Linux ユーザーの場合は、コマンドプロンプトから実行できます。

HIPAA (医療保険の移植性と説明責任に関する法律)

1996年の医療保険の移植性と説明責任に関する法律(HIPAA)は、米国市民や医療機関に適用される連邦法です。この法律は、米国市民の医療データを処理する米国外の組織にも適用されることに注意することが重要です。この法律の導入により、米国保健福祉省(HHS)の長官は、特定の健康情報のプライバシーとセキュリティを保護する規制を開発することを義務付けた。一部の組織では、保護される可能性のある健康情報 (ePHI) であるデータを処理する場合があります。これは、電子メディアによって送信される個人を特定できる健康情報、電子メディアで管理される、または他の形式または媒体で送信または維持されることを意味します。任意のデータ主体の正常性データが処理される場合、組織は HIPAA を満たす必要があります。

HIPAA には、特定の健康情報の保護に関する国の基準を概説する「プライバシー規則」または個人を特定できる健康情報のプライバシーに関する標準、および電子保護医療情報の保護に関する「セキュリティ基準」という 2 つの法律が含まれています。これは「セキュリティ規則」とも呼ばれます。後者は、電子形式で保持または転送される特定の健康情報を保護するための国家のセキュリティ基準のセットを確立します。

概要から、"セキュリティ規則" は、"プライバシー規則" によって提供される保護の実用的な実装です。個人の "電子保護された健康情報" (e-PHI) のセキュリティを確保するために、"対象エンティティ" が実装する必要がある技術的および非技術的な対策について概説します。このセクションでは、規制全体については説明しませんが、HIPAA の重要な要素の一部に取り組み、組織が要件への準拠を満たしていること、および組織が処理する正常性情報を保護するという保証を得るのに役立ちます。

Control No. 14

以下の実証可能な証拠を提供してください。

組織のスタッフ、請負業者などのために、HIPAA と HIPAA の処理にポリシーが存在します。
ISV は、ePHI が作成、受信、維持、または送信する ePHI の機密性、整合性、可用性を確保しています。
ePHI のセキュリティまたは整合性に対して、合理的に予想される脅威や危険から保護します。

意図:

このサブポイントの目的は、組織が健康情報を管理するための標準的な手順として機能するプロトコルを確立し、緊急やサービスの中断に対処し、スタッフが健康情報とトレーニングにアクセスできるようにすることです。さらに、組織は、HIPAA セキュリティプログラムの一環として、これらの管理上のセーフガードを維持し、概要を示す必要があります。これは、HIPAA 規制に準拠するための重要な側面です。

ガイドライン:

これは、HIPAA ポリシーと手順を示す組織の確立されたドキュメントを提供することで証明されます。認定アナリストはこれを確認して、コントロール内で提供されるすべての情報に対処します。

証拠の例:

スクリーンショットには、HIPAA ポリシーのスナップショットが示されています。注: ISV は、実際のサポートポリシー/手順のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

HIPAA ポリシードキュメント。

注: ISV が実際の包括的なサポートポリシー/手順ドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

意図:

このサブポイントの意図を理解し、セキュリティ規則に確実に準拠するには、"対象となるエンティティ" は、まず、機密性、整合性、および可用性に関する用語が§ 164.304 で定義されている方法を理解する必要があります。

機密性: "データまたは情報が未承認の人やプロセスに提供または開示されていないプロパティ。
整合性: "データまたは情報が未承認の方法で変更または破棄されていないプロパティ。
可用性: "データまたは情報にアクセスでき、承認されたユーザーが要求に応じて使用できるプロパティ。

この要件の目的は、組織が、承認されたユーザーに対する整合性と可用性を維持しながら、ePHI の機密性を確保するために、IT インフラストラクチャ内でアクセス、監査、整合性、転送制御などの技術的な保護/対策を実装することです。

ガイドライン:

証拠は、ePHI データが制御要件に沿ってセキュリティで保護されるようにするために使用される保護メカニズムの構成設定によって提供される場合があります。このようなメカニズムには、アクセス制御、緊急アクセス手順、RBAC、暗号化などが含まれます。

証拠の例: アクセスと整合性の制御

次のスクリーンショットは、ePHI ストレージの場所を処理するアクセス許可を持つ個人の承認されたアクセスリストが存在し、HIPAA ポリシードキュメント内に保持されていることを示しています。さらに、承認済みのインベントリリストに続くスクリーンショットでは、クラスター上で読み取りと書き込みが可能な管理者およびデータベースメンテナンスアナリストのみがクラスター全体で書き込みアクセスが制限されていることが確認できます。

HIPAA ポリシードキュメント。

Atlas Mongo の ePHI ストレージデータベースの 1 つから取得した次のスクリーンショットは、承認されたユーザーのみがアクセス権を文書化していることと、すべてのアカウントに一意のユーザー ID があり、責任を確保できることを示しています。

最初のスクリーンショットは、ePHI のメインストレージの場所/データベースクラスターを示しています。

MongoDB クラウドクラスターページ。

2 番目のスクリーンショットは、承認されたユーザーがロールとアクセスのみを文書化していることを示しています。

MongoDB Cloud データベースページ。

次の 2 つのスクリーンショットは、割り当てられた各ロールと、上記のアクセス承認に沿った関連するすべてのアクセス許可のより詳細なビューを示しています。

MongoDB Cloud データベースページ。

各カスタムロールには、一連のアクセス許可とアクセス範囲があります。

MongoDB Cloud データベースページ。

最後に、次のスクリーンショットは、ネットワークの観点から、セキュリティで保護された企業ネットワークである承認された IP 範囲のみがクラスターへのアクセスを許可されていることを示しています。

MongoDB クラウドネットワークページ。

証拠の例: 監査コントロール

これらのスクリーンショットは、データベースクラスターに対してログ記録とアラートが実装されていることを示しています。最初のスクリーンショットは、アラートが有効になっていることを示しています。提供された証拠には、組織のニーズ/実装に基づいて設定されたアラートルールも示されていることが期待されます。 2 番目のスクリーンショットは、データベース監査が有効になっていることを示しています。

MongoDB クラウドクラスターページ。

MongoDB Cloud データベースページ。

次のスクリーンショットは、記録されているデータベースクラスターへのアクセス履歴を示しています。予想されるのは、アラートが設定され、監査ログに基づいて行われ、事前に定義された条件を満たしていない承認されていないアクセスによってアラートがトリガーされます。

MongoDB Cloud データベースページ。

最後の 2 つのスクリーンショットは、データベースクラスターに対して監査ログが生成され、分析のためにログをエクスポートできることを示しています。

MongoDB Cloud データベースページ。

MongoDB Cloud ログのダウンロード。

生成された監査ログを分析するためのプロセスが用意されていることに注意してください。レビュープロセスの証拠も提供する必要があります。これをプログラムで実現する場合は、使用されるプラットフォーム/ログソリューションへのログインジェストの構成設定のスクリーンショットと、ルールのスクリーンショットを確認するために提供する必要があります。

証拠の例: 暗号化と転送の制御

次のスクリーンショットは、ストレージの場所に保存データが既定で暗号化されていることを示しています。既定で使用されるプラットフォームによって暗号化が実行されず、独自の暗号化キーが使用されている場合は、それらのキーが適切にセキュリティで保護され、これを実証するための証拠が提供されることを想定しています。

MongoDB Cloud データベースページ。

次の 2 つのスクリーンショットは、ストレージの場所に転送中のデータが既定で暗号化されていることを示しています。最初のスクリーンショットは、データ API が "読み取りと書き込み" アクセス許可で有効になっていることを示しています。

MongoDB Cloud データベースページ。

エンドポイントの SSL スキャンは、転送中のデータが TLS 1.2 を介して暗号化されていることを示しています。

Qualys SSl レポート。

証拠の例: 可用性と回復の制御

次のスクリーンショットは、可用性を確保するために、データベースクラスターが 3 つのリージョン間でレプリケートされていることを示しています。これは、Mongo Atlas によって既定で実行されます。さらに、バックアップは有効であり、アクティブです。

MongoDB Cloud データベースページ。

次のスクリーンショットは、クラスターのバックアップダッシュボードを示しています。これは、スナップショットが既に作成されていることを示しています。

MongoDB Cloud データベースページ。

次の 2 つのスクリーンショットは、スケジュールされたバックアップを異なる時点 (PIT) で実行するためのバックアップポリシーが設定されていることを示しています。

MongoDB Cloud データベースページ。

スナップショットとポイントインタイムリストア (PIT) の両方に保持ポリシーがあることを示します。

MongoDB Cloud データベースページ。

意図:

このサブポイントの意図は、柔軟性とスケーラビリティを確保するために開発されたセキュリティルールと一致し、"対象エンティティ" が、エンティティのサイズ、組織構造、および特定のリスクに対する意欲に合ったポリシー、手順、技術ソリューションを実装できるようにします。実用的な観点から見ると、実装される適切なセキュリティ対策は、"対象となるエンティティ" ビジネスの性質と、そのサイズとリソースに依存することを意味します。

すべての組織が包括的なリスク分析を行い、e-PHI の機密性、整合性、可用性に対する潜在的なリスクと脆弱性を明らかにすることが不可欠です。このリスク分析を通じて、組織は、これらの特定されたリスクを軽減するための適切なセキュリティ制御を実装できます。

ガイドライン:

証拠は、リスク分析の出力によって提供される場合があります。リスク分析がオンラインプラットフォームを介して実行および維持される場合は、出力全体のスクリーンショットを提供する必要があります。

証拠の例:

次のスクリーンショットは、リスク評価プロセスのスナップショットを示しています。続いて、ePHI を保護するために意図したとおりにコントロールが正しく実装され、動作する程度を判断するために実行されたリスク分析が続きます。 2 番目のスクリーンショットは、リスク評価で特定されたリスクのリスク分析と、リスクレベルを低下させるために実装された補正コントロールと軽減策を示しています。

例 1 – HIPAA ポリシー内のリスク評価プロセスのスナップショットと実行されたリスク分析

HIPAA ポリシードキュメント。

注: このスクリーンショットはリスク分析ドキュメントのスナップショットを示しています。これは単なる例であり、ISV が実際のドキュメントを共有し、単にスクリーンショットを提供する必要はありません。

例 2 – HIPAA ポリシー内のリスク評価プロセスと実行されたリスク分析のスクリーンショット (Confluence Cloud Platform で管理)

Confluence HIPAA ポリシーページ。

2 番目のスクリーンショットは、リスク評価で特定されたリスクのリスク分析と、リスクレベルを低下させるために実装された補正コントロールと軽減策を示しています。これは存在し、Confluence クラウドプラットフォームで維持されていることがわかります。

Confluence リスク分析レポート。

コントロール No. 15

お客様 (ISV) の証拠を提供してください。

プライバシー規則で許可されていない、合理的に予想される使用または開示から保護します。そして
従業員がセキュリティ規則に準拠していることを確認します。
164..308 (a)(7)(ii)(A) および 164.308 (a)(7)(ii)(B) の下のデータバックアップとディザスターリカバリー計画。

Intent

プライバシー規則は、保護された健康情報 (PHI) の一部が法律の対象となるものを定義し、PHI の不適切な使用と開示を禁止します。このサブポイントの目的は、組織が e-PHI のアクセスと使用を、承認された目的で必要とするユーザーのみに制限し、必要な最低限の規則に従う必要があり、目的を達成するために必要な最小限の e-PHI のみを使用または開示する必要があるということです。

ePHIの使用を制限し、ePHIの開示リスクを軽減するために、技術的および管理上のセーフガードを組み合わせて実施する必要があります。

ガイドライン:

提供される証拠は、e-PHI を保護するために使用されているテクノロジやメカニズムなどの技術的なセーフガードを示す必要があり、組織がそのようなデータのアクセスと移動を制御する方法を示す必要があります。

証拠の例:

次のスクリーンショットは、組織が 1 つの集中管理された場所から DLP ポリシーを管理できる統合プラットフォームである Microsoft Purview データ損失防止 (DLP) を示しています。

以下では、"米国 HIPAA Enhanced" ポリシーが有効になっていることを確認できます。これにより、ユーザーが、サポートされている Web ブラウザーを介してアクセスしたときに、個人のメール、生成 AI プロンプト、ソーシャルメディアサイトなど、特定の Web サイトに機密データを貼り付けるのを防ぐことができます。