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

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

転送中のデータ

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

コントロール No. 1

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

• TLS 構成が TLS1.2 以降であることを検証します。

• 信頼されたキーと証明書のインベントリが保持され、維持されます。

意図: TLS

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

ガイドライン: TLS

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

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

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

証拠の例: TLS

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

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

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

証拠の例: TLS

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

意図: キーと証明書

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

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

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

証拠の例: キーと証明書

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

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

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

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

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

証拠の例: キーと証明書

信頼されたキーと証明書のインベントリは、次のスクリーンショットに示すようにインベントリ機能を提供する Microsoft 365 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 圧縮が無効になっていることを示しています。

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

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

HSTS が有効になっているチェックに使用できるその他のツールは、"HTTP ヘッダー スパイ" であり、

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

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

次のスクリーンショットは、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 暗号化が使用されていることを示す Microsoft ドキュメント ページのSQL Database、SQL Managed Instance、Azure Synapse Analytics の透過的なデータ暗号化を示しています。

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

証拠の例:

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

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

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

コントロール No. 4

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

意図:

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

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

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

ガイドライン:

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

証拠の例:

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

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

コントロール No. 5

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

意図:

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

ガイドライン:

保存されたデータ (データベース、ファイル共有、アーカイブ、バックアップを含むすべてのさまざまなデータの場所) が、定義されたデータ保持ポリシーを超えていないことを示すスクリーンショットの証拠 (またはスクリーン共有経由) を提供します。 許容されるスクリーンショットの例を次に示します。

• 日付フィールドを持つデータベース レコード、最も古いレコード順で検索されたレコード、または/または
• 保持期間内のタイムスタンプを示すファイルストレージの場所。 注: 個人または機密の顧客データは、スクリーンショットで編集する必要があります。
• 定義された保持期間内にバックアップ データが保持され、この期間後に適切に削除されることを示すバックアップ レコード。

証拠の例:

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

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

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

コントロール No. 6

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

意図:

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

ガイドライン:

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

証拠の例:

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

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

証拠の例:

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

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

証拠の例:

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

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

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

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

コントロール No. 7

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

• 自動バックアップ システムが用意されており、スケジュールされた時刻にバックアップを実行するように構成されています。

• バックアップ情報は、バックアップ スケジュール手順に沿ってテストされ、データの信頼性と整合性を確認するために定期的に復元されます。

• 適切なアクセス制御と保護メカニズム (つまり、変更できないバックアップ) は、未承認のアクセスに対してバックアップ/システム スナップショットがセキュリティで保護されていることを確認し、バックアップ データの機密性、整合性、可用性を確保するために実装されます。

意図:

この制御の目的は、organizationに自動バックアップ システムが設定されていることを確認することです。これは、事前にバックアップを実行するように構成されています。

ガイドライン:

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

証拠の例:

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

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

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

意図:

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

ガイドライン:

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

証拠の例:

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

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

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

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

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

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

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

意図:

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

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

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

ガイドライン:

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

証拠の例:

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

証拠の例:

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

データ アクセス管理

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

コントロール No. 8

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

• 一人ひとりの事業上の正当な理由を含め、維持されます。

• は、ジョブ機能に必要なアクセス特権に基づいて正式に承認されました。

• は、承認に記載されている特権で構成されます。

意図:

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

ガイドライン:

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

証拠の例:

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

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

意図:

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

ガイドライン:

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

証拠の例:

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

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

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

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

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

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

証拠の例:

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

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

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

Intent

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

ガイドライン:

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

証拠の例:

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

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

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

コントロール No. 9

次の証拠を提供します。

• データが共有されているすべてのサード パーティの一覧が保持されます。

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

意図:

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

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

• 提供されているサービス

• 共有されるデータ

• データが共有される理由

• キー連絡先情報 (プライマリ連絡先、侵害通知連絡先、DPO など)

• 契約の更新/有効期限

• 法的/コンプライアンス義務 (GDPR、HIPAA、PCI DSS、FedRAMP など)

ガイドライン:

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

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

証拠の例:

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

証拠の例:

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

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

意図:

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

ガイドライン:

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

証拠の例:

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

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

プライバシー

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

Control No. 10 – 個人データ

organizationを示す証拠を提供します。

A) 各データ要素の目的を含め、収集、処理、および保存されたすべての個人データの最新のインベントリを保持します。 

B) データ収集フォームは、ビジネス目的に必要なフィールドのみを含むように設計し、必須フィールドと省略可能なフィールドを適切に実装します。 

C) 収集できる個人データの種類と使用目的を指定するポリシーを開発し、適用します。 

D) ユーザーが個人の非ビジネスに不可欠なデータの処理または広範な表示をオプトアウトできるようにします。 

意図:

この制御の目的は、データの収集に関するデータ プライバシーを確実に遵守し、キャプチャされるデータの正当な理由を確保し、データが収集される内容と理由を透過的にすることです。 また、ユーザー (データ主体) が処理をオプトアウトできることも重要です。  

ガイドライン:

このコントロールは、次のように証明できます。

A) organizationの処理活動記録 (RoPA)、(GDPR 記事 30 を参照)、またはデータ要素と処理の目的を詳しく説明した同様のドキュメントを提供します (GDPR 記事 5.1.b を参照)。 

ほとんどの場合、これは Excel スプレッドシートです (OneTrust などのツールから抽出できます)。 

ファイルが大きすぎる場合、または機密データが含まれている場合は、特定のデータ サンプルのすべてのデータ フィールドを示す抜粋を提供できます。これは、証拠が RoPA が配置されていることを保証できる限り、部分的に編集できます。 

非準拠: レコードが存在しない、非常に古い、古い、またはキー フィールドがありません。 

B) 「データ最小化」を目的として ( GDPR 記事 5.1.c を参照)、データの取得に使用されるすべてのフォーム (オンライン、タブレットまたは類似のデバイス (会議など) または論文を使用して提供します。 これらは空白またはテンプレートである可能性があります。 

非準拠: フォームには、処理の目的に必要ではない必須フィールドがあります。 たとえば、電話番号、年齢、性別を問い合わせたり、メールや住所にパンフレットを送信したりします。  

C) 「適法性、公平性および透明性」を目的として ( GDPR 第 5.1.a 条を参照)、プライバシー ポリシー (従業員向け)、プライバシーに関する通知 (ユーザー/顧客向け) を設定する必要があります。 通常、プライバシーに関する通知は、organizationの Web サイトで一般公開する必要があります。  

非準拠: ポリシーが存在しないか、キー要素がありません。 

主要な要素:

プライバシー ポリシー/通知: 情報収集と使用、処理されたデータ要素、処理の目的、処理の適法性、他の国へのデータ転送、データ主体の権利、データの保存と保持。  

D) オプトアウト メカニズムについては (通常、Web ページ上の GDPR 第 4.11 条、 GDPR 第 6 条、 GDPR 第 7 条を参照)。 ユーザーがそのページにアクセスするために従う必要があるナビゲーションを確認します (たとえば、見つけやすくなりますか? 

非準拠: 明確なオプトアウト機能なし、または粒度のない "汎用" オプトアウト。 

証拠の例:

A)の場合:

B)の場合:

C)の場合:

D)の場合:

コントロール No. 11 – ユーザーの認識

ユーザーが認識している証拠を提供します。

A) データにアクセスできるユーザー

B) 作業しているスペースにアクセスできるユーザー

C) 情報に基づいた意思決定を行うことができるように、共有またはデータ フローを通じてデータにアクセスできるユーザー。

意図:

このコントロールの目的は、データ保護の "透明性" 原則 ( GDPR 記事 5.1.a を参照) が満たされていることを示すものです。

ガイドライン:

これは、理想的には何らかの形のユーザー受信確認 (プライバシー ポリシーの読み取りなど) を実施し、記録する必要があることを示す必要があります。

実際には、プライバシー ポリシー (従業員向け)、プライバシーに関する通知 (ユーザーと顧客向け) が、次に関する十分な詳細を提供するだけです。

- 個人データを共有しているユーザー (プロセッサ、サブプロセッサ、サード パーティ、請負業者など)。

非準拠: 確認が存在しないか、プライバシー ポリシー/プライバシーに関する通知が存在しません。

証拠の例:

または

制御第 12 号 – データ処理契約 (DBA)

承認されたすべてのサード パーティ/サブプロセッサの一覧が必要なデータ処理契約の証拠を提供します。

意図:

データ主体に対して透過的であることを確認するために、データにアクセスできるサード パーティ/サブプロセッサ、処理で果たす役割 (データ コントローラー、データ プロセッサ)、それぞれの責任、セキュリティ メカニズムが確実に通知されるようにします。

また、データの共有に EU 外の地域へのデータ転送 (GDPR の下) が含まれる場合は、転送が適法であることを保証するためのメカニズムの詳細。 ( GDPR 第 5 条 および GDPR 第 44-50 条を参照)

GDPR の場合、処理対象の地域は次のいずれかの条件を満たす必要があります。

- 欧州連合加盟国である。

- 欧州委員会が「適切なセーフガード」を提供すると見なされる。 現在の一覧は、EU 以外の国のデータ保護の妥当性です。

2025年6月13^日 時点:

- データ プライバシー フレームワーク (DPF) に参加し、データ プライバシー フレームワークの一覧を次に示します。

- バインディング企業ルール (BCR) を設定します。

- 契約条項 (SCC) をStandardします。

ガイドライン:

証拠は、既存のサブプロセッサとのデータ処理契約 (DPA) のカップルをサンプリングする方法です。 場合によっては、組織に DBA がない場合もありますが、契約の補遺や "プライバシー条項" が含まれる場合があります。

非準拠:

- 3^rd パーティ/サブプロセッサの一覧がありません。

- 受信者の国に関する詳細は示されません。

- 国は "適切な国" としてリストされておらず、BCR や SCC は存在しません。

証拠の例:

この例は、IAPP の DPA の例を示しています。または、データが共有されている関係者を示す関連ドキュメントである可能性があります。

さらに、EU 外でのデータ転送のメカニズムをチェックします。

コントロール No. 13 – データ保護の影響評価 (DPIA)

organizationがデータ保護影響評価 (DPIA) を実行していることを示す証拠を提供する

     または

このプライバシー レビューが接続されているデータのプライバシーと保護に関連する評価の名前を指定します。

意図:

このコントロールの目的は、特に新しいテクノロジの導入や既存のテクノロジの新しい使用に関連する、個人の権利と自由に対する潜在的なリスクに関する評価を確実に実行することです。 ( GDPR 記事 35 を参照)

ガイドライン:

このコントロールは、最新の DPIA または関連する評価ドキュメントを確認することで評価されます。

非準拠:

DPIA には、次の要素が必要です。

- DPIA の必要性を識別します。

- スコープ、コンテキスト、目的など、想定される処理の説明。

- 必要性と比例性の評価。

- リスクの特定と評価。

- リスクを軽減するための対策の特定。

- 記録された結果。

上記のいずれかが見つからない場合、または単に機能レベルで実行された場合、このコントロールは非準拠としてマークできます。

証拠の例:

DPIAの完全なテンプレートはICOのウェブサイトで見つけることができます dpia-template.docx

コントロール No. 14 – 生体認証データ

アプリケーションは生体認証データと対話しますか? はいの場合は、

生体認証データが法的レビューに合格し、保護され、ユーザーに通知され、生体認証データ収集をオプトイン/オプトアウトするオプションが与えられているという証拠を提供します。

意図:

この制御は、 GDPR 第 9 条 に基づき、特別なカテゴリのデータとして分類される生体認証データの適切な保護を確保することに関心があります。  生体認証データの使用は、適法性分析を受けている。

ガイドライン:

生体認証データの使用は、証拠収集の一部として提供する必要があるため、法的レビューを行う必要があります。 存在しない場合は、(準備をチェックするために) 使用するテンプレートを要求します。

非準拠:

生体認証データの処理に関する法的レビューには、次のものが含まれている必要があります。

- 処理の法的根拠 (次の 1 つ以上):

同意	コントラクトのパフォーマンス	その他の法的義務
同意	コントラクトのパフォーマンス	その他の法的義務
重要な関心事	公益	正当な利益

- 生体認証データを処理するための有効な条件を一覧表示します (次の 1 つ以上)。

ユーザーからの明示的な同意	雇用または社会保障
ユーザーからの明示的な同意	雇用または社会保障
重要な利益の保護	正当な活動
データ主体によって明らかに公開される個人データ	法的請求の確立、行使、または防御
大きな公共の関心	予防・産業医学
公衆衛生分野に対する国民の関心	公共の利益、科学的または歴史的研究のアーカイブ目的

- 生体認証データではなく、代替手段の使用に関する考慮事項。

上記のいずれかが見つからない場合、または単に機能レベルで実行された場合、このコントロールは非準拠としてマークできます。

証拠の例:

ソース:

- GDPR 第 9 条 – データの特殊なカテゴリの処理: アート。 9 GDPR – 個人データの特殊なカテゴリの処理 - 一般的なデータ保護規則 (GDPR)

- ICO 「生体データを合法的に処理する方法」: 生体データを合法的に処理する方法 |ICO

 

コントロール No. 15 – Data Insights

メトリックには、個別に識別可能なデータのない集計データと匿名化されたデータのみが表示されるという証拠を提供します。 テナントは、推奨される集計レベルの下限を構成でき、製品で許可される絶対最小値は 5 である必要があります。

意図:

このコントロールの目的は、データライフ サイクル全体を通じて、匿名化および仮名化されたデータの状態を確実に実装し、維持することです。 (「」を参照)

ガイドライン:

この制御が実施されていることを示すために、GUI または CLI を使用した証拠は、以下を示すために提供する必要があります。

- 集計レベルの最小制限に対するユーザー レベルの構成。

- メトリックのサンプル。

ユーザーが優先する集計レベルのしきい値を 5 以上に構成できるかどうかを評価します。 証拠は、メトリックのサンプルに匿名化のみが存在することを示す必要があります。

非準拠:

- ユーザーは集計レベルを少なくとも 5 にカスタマイズできないか、必要な技術スキルが一般的なユーザーには期待できません。

- 個人データはメトリック サンプルに存在します。たとえば、名前、姓、ID、顧客番号、電話番号、電子メール アドレス、住所、銀行の詳細、近親者など。

証拠の例:

特定の詳細を示す構成設定の画面キャプチャ。

収集されたメトリックのサンプル。 匿名化を実現するためのプロセスについて質問する場合があります。

GDPR

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

コントロール No. 16

以下を示すことによって、データ主体の権利の遵守を示す証拠を提供します。

A) サブジェクト アクセス要求 (SAR) の円滑化:

データ主体が個人データにアクセスする権利を通知し、サブジェクト アクセス要求 (SA) をorganizationに送信できることを確認するドキュメント。

 

B) データ検出と SAR フルフィルメント:

SAR に応答して、すべてのシステムとリポジトリ全体で個々のデータ主体に関連するすべての個人データを検索して取得するorganizationの機能の証拠。

意図:

この制御の目的は、データ主体がorganizationが保有する個人データに関する要求を行う適切なメカニズムを確保し、正当な要求を満たすことを保証することです。 ( GDPR 第 15 条を参照)。

ガイドライン:

A) プライバシーに関する通知には、SAR を作成する方法の詳細が含まれている必要があります。これは、次の方法を使用する可能性があります。

- organizationによって提供される Web フォームの使用

- organizationによって提供される電子メール アドレスの使用

- organizationによって提供される電話番号/Web チャットを使用する

- 監督機関 (英国の ICO など) を使用する

メソッドの証拠を要求します。画面キャプチャで十分です。

B) RoPAまたは同様の文書を使用して、データ主体に関連する個人データが存在する場所を、デジタルまたはファイリングシステム(物理的)の一部として識別することができます。

または、e-discovery 演習でも同じ結果を達成できます。

SAR を満たすために使用されるプロセス/ワークフローの証拠と、プロセスが完全であり、データ主体に関連する個人データを見逃さないと判断された方法についての説明を要求します。

非準拠:

A) organizationの Web サイト (通常はプライバシーに関する通知) に情報は提供されません。

B) 証拠は、個人データを収集するプロセスが完全ではないか、技術的な詳細が不足している可能性があることを示しています (データベースに名前や場所が指定されていないなど)。

証拠の例:

A) ポイント A をカバーするために提供できる証拠の例を次に示します。

– Web フォーム:

ソース: サブジェクト アクセス要求 - 警察ケア英国

- Emailアドレス/電話番号:

ソース: どれですか?プライバシー ポリシー - どれですか?

- Webchat:

ソース: HMRC へのサブジェクト アクセス要求を行う - GOV.UK

- 監督機関 (ICO など) を介して:

ソース: サブジェクト アクセス要求を行う |ICO

B) 提供された証拠アーティファクト 十分な技術的な詳細を持つワークフローまたはプロセスの説明を詳述し、SAR を達成するために十分に使用できる。

コントロール No. 17

次のように、必要なすべての要素を含める必要があるプライバシーに関する通知を提供します。

A) organizationおよびデータ保護責任者 (DPO) の ID と連絡先の詳細 (該当する場合)。

B) organizationが処理する個人データの種類 (名前、姓、顧客番号、電子メール アドレス、電話番号など)。 また、organizationがデータ主体から直接取得していない場合は、個人データ ソース (個人データの送信元など)。

C) 個人データの処理の目的。

D) 個人データを処理する法的根拠 (関連する正当な利益を含む)。

E) organizationが個人データを共有する当事者。

F) 個人データが保持される期間の詳細。

G) データ主体の権利の詳細:

• 通知を受ける権利

• アクセス権

• 修正する権利

• 消去する権利

• 処理の制限を受ける権利

• データの移植性に対する権利

• オブジェクトに対する権限

• プロファイリングを含む、自動化された意思決定に関連する権利

H) 第三国への個人データの移転に関する詳細および取られた保護策。

I) 監督機関に苦情を申し立てる権利,監督機関の連絡先の詳細を提供する (例: 英国のICO).

意図:

この目的は、 GDPR 第 3 章に従って、上記の要素と原則を含めることにより、公開されたプライバシー通知に十分な詳細が含まれていることを確認することです。

ガイドライン:

Control 10.c に従って、Microsoft 365 認定資格に含まれるサービスをカバーするプライバシーに関する通知を公開する必要があります。 このプライバシーに関する通知には、上記で強調表示されている要素と原則が含まれている必要があります。

非準拠:

コントロール 10.c を参照してください。

証拠の例:

コントロール 10.c を参照してください。

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

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

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

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

コントロール No. 18

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

• スタッフ、請負業者などのために、organization内の HIPAA および HIPAA 処理にポリシーが存在します。

• ISV は、ePHI が作成、受信、維持、または送信する ePHI の機密性、整合性、可用性を確保しています。

• ePHI のセキュリティまたは整合性に対して、合理的に予想される脅威や危険から保護します。

意図:

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

ガイドライン:

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

証拠の例:

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

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

意図:

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

• 機密性: "データまたは情報が未承認の人やプロセスに提供または開示されていないプロパティ。

• 整合性: "データまたは情報が未承認の方法で変更または破棄されていないプロパティ。

• 可用性: "データまたは情報にアクセスでき、承認されたユーザーが要求に応じて使用できるプロパティ。

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

ガイドライン:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

意図:

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

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

ガイドライン:

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

証拠の例:

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

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

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

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

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

コントロール No. 19

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

• プライバシー規則で許可されていない、合理的に予想される使用または開示から保護します。そして

• 従業員がセキュリティ 規則に準拠していることを確認します。

• 164..308 (a)(7)(ii)(A) および 164.308 (a)(7)(ii)(B) の下のデータ バックアップとディザスター リカバリー計画。

Intent

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

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

ガイドライン:

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

証拠の例:

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

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

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

[ポリシーの編集] オプションを選択すると、使用可能な特定の構成に対するより詳細なビューが表示されます。

次の 2 つのスクリーンショットは、ポリシーを適用するために満たす必要があるコンテンツの定義と条件を示しています。

このポリシーでは、さまざまな機密データ型と分類子のセットについて説明します。

次のセクションでは、前のスクリーンショットに示した条件が満たされたときに実行されるように構成されたアクションを示します。

次のスクリーンショットは、DLP ポリシーが設定されており、ユーザーがorganizationの内部データベースから、サポートされているブラウザー上の個人用メール アカウント、チャットボット、ソーシャル メディア サイトに個人を特定できる情報 (PII) などの機密情報をコピーして貼り付けないように設定されていることを示しています。

最後に、ユーザー通知は、ユーザーが ePHI データを処理するときに通知し、ユーザーにガイダンスを提供するように構成されます。

次のスクリーンショットは、インシデントが発生したときにアラートを生成するための構成パネルを示しています。

意図:

このサブポイントの目的は、organizationが電子PHIを安全かつ適切に処理する方法についてスタッフをトレーニングし、セキュリティ規則に準拠するためにポリシーと手順を適用する必要があるということです。

ガイドライン:

提供された証拠は、HIPAA トレーニングが ePHI の処理方法に対して実行されていること、および出席とトレーニング完了の記録が存在することを示す必要があります。 該当する場合は、使用されるポリシー ドキュメントとトレーニング資料でサポートできます。

証拠の例:

次の例は、ポリシーに従って適切な HIPAA トレーニングが行われることを示すために提出できる潜在的な証拠を示しています。

次のスクリーンショットは、HIPAA ポリシーのスナップショットと、トレーニングの要件を示す特定のセクションを示しています。 これは単なる例であり、包括的なドキュメント/実装ではありません。ISV には、そのorganizationに適用できる確立されたプロセスが必要です。

例 1 – 管理プロセスを使用した HIPAA ユーザー トレーニング

次のスクリーンショットでは、コースの概要スライドにコース目標の概要が表示されます。 トレーニングが家に組み込まれている場合は、トレーニング資料をレビューのために提供する必要があります。要約のスクリーンショットだけでなく、完全な資料を提出する必要があることに注意してください。

次のスクリーンショットは、トレーニングに参加した従業員の出席記録を示しています。 このレコードには、パス スコアと次のトレーニングスケジュール日も表示されます。

2 番目の例では、Microsoft 365 Defender を使用してトレーニング キャンペーンを設定および開始する方法を示します。

例 2 – Microsoft 365 Defender 攻撃シミュレーション プラットフォームを使用した HIPAA ユーザー トレーニング (すべてのユーザー)

前のスクリーンショットは、HIPAA セキュリティ トレーニング キャンペーン、合計時間 (分単位)、完了状態を示しています。 次のスクリーンショットは、トレーニングが割り当てられたユーザーの概要と、正常な完了を示すトレーニング状態を示しています。

例 3 – Microsoft 365 Defender 攻撃シミュレーション プラットフォームを使用した HIPAA ユーザー トレーニング (個々のユーザー)

前の例では、すべてのユーザーが年次トレーニング キャンペーンを完了したことを示することに重点を置いていますが、最後の例では、1 人の従業員の完了を示すターゲット証拠が示されています。

前の 2 つのスクリーンショットでは、トレーニング キャンペーンが開始されるとすぐに、すべての従業員がトレーニングの割り当てと期限、割り当てられたモジュール、期間などを確認するメールを受信したことを確認できます。

電子メール通知で使用できるリンクを使用して、次のスクリーンショットは、ユーザーの [トレーニングの割り当て] ページと、完了した 2 つのモジュールを示しています。

意図:

HIPAA セキュリティ 規則では、電子保護された正常性情報 (ePHI) を処理する "対象エンティティ" には、データ バックアップ 計画とディザスター リカバリー 計画が必須です。 このような計画は、ePHIを含むシステムに損害を与える緊急またはその他の発生が発生した場合にePHIの可用性とセキュリティを確保することを目的としたコンティンジェンシー戦略の一部です。

データ バックアップ 計画の目的は、取得可能な ePHI の同一のコピーを作成して維持することです。これには、データの復旧を確実にするためにバックアップの定期的なテストも含める必要があります。 ディザスター リカバリー 計画の目的は、障害発生時に失われた可能性のあるデータを復元することです。これにより、バックアップからファイルを復元する方法など、データへのアクセスを復元するために実行する必要がある手順を指定する必要があります。

ガイドライン:

バックアップ 計画と復旧計画をカバーする必要があるディザスター リカバリー 計画/手順の完全版を指定してください。 デジタル バージョンの場合は、実際の PDF/Word ドキュメントを指定します。または、オンライン プラットフォームを介してプロセスが維持されている場合は PDF エクスポートを提供するか、プラットフォームの制限のためにエクスポートできない場合は、ポリシー全体をカバーするスクリーンショットを提供してください。

証拠の例:

次のスクリーンショットは、一般的で高度なバックアップ手順とディザスター リカバリー 計画の概要を含む HIPAA セキュリティ ポリシーのスナップショットを示しています。

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

ブック

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: Cyber Security Incident Responding Responder の要約フィールド ガイド。 2nd Edition、Publisher: CreateSpace Independent Publishing Platform。

関連情報

• アクション詐欺サイバー犯罪の報告: https://www.actionfraud.police.uk/ (アクセス日: 2023 年 12 月 10 日)。

• EU。 (2021) データ コントローラーの GDPR チェックリスト使用可能な時点: https://gdpr.eu/checklist/ (アクセス日: 2023 年 12 月 10 日)。

• Microsoft。 (2018) イベント ログ (Windows インストーラー) で利用可能: イベント ログ (アクセス: 03/05/2024)。

• 肯定的なテクノロジ。 (2020) セキュリティで保護されたソフトウェア開発にアプローチする方法: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023) で入手できます。

• 欧州議会および2016年4月27日の理事会の2016/679は、個人データの処理およびそのようなデータの自由な移動に関する自然人の保護に関する規制(EU)、 および廃止ディレクティブ 95/46/EC (一般的なデータ保護規則) (EEA の関連性を持つテキスト) (2016) で利用可能: https://www.legislation.gov.uk/eur/2016/679/contents (アクセス: 12/10/2023)。

• セキュリティ メトリック。 (2020) PCI DSS コンプライアンスのセキュリティ メトリック ガイド。 利用可能: https://info.securitymetrics.com/pci-guide-2020(Accessed: 12/10/2023)。

• ウィリアムス・J・OWASP リスク・ランキング: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (アクセス日: 12/10/2023)。

• Qualys。 (2014) SSL Labs: 新しい信頼グレード (T) と不一致 (M) の問題が利用可能です: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (アクセス済み: 12/10/2023)。

• NIST SP800-61r2: コンピューター セキュリティ インシデント処理ガイドは、 https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (アクセス日: 12/10/2023) にあります。

• Azure Pipelines と Google Kubernetes エンジンを使用した CI/CD パイプラインの作成 | .NET

• Google Cloud (アクセス済み: 2023 年 10 月 10 日)。

• ディザスター リカバリー 計画: https://www.sans.org/white-papers/1164/ (アクセス日: 2023 年 10 月 10 日)。

• https://github.com/ (アクセス: 10/10/23)。

• セキュリティ ポリシー テンプレート: https://www.sans.org/information-security-policy/ (アクセス: 10/10/23)。

• https://www.openedr.com/ (アクセス: 02/10/23)。

• https://www.atlassian.com/software/confluence (アクセス: 10/10/23)。

• https://www.atlassian.com/software/jira (28/09/23 にアクセス)。

• 事業継続計画 (BCP) テーブルトップ演習テンプレート: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (アクセス: 10/10/23)。

• HIPAA セキュリティ規則の概要 | HHS.gov (アクセス日: 2023 年 18 月 10 日)。

• デジタル時代の医療情報プライバシー法: HIPAA は適用されません - PMC (nih.gov) ( アクセス日: 18/10/2023)。

• HIPAA の目的は何ですか? Update 2023 (hipaajournal.com) (アクセス: 2023 年 18 月 10 日)。

• HIPAA で考慮PHIとは 2023 更新プログラム (hipaajournal.com) (アクセス: 2023 年 18 月 10 日)。

• HIPAA ポリシーと手順 (hipaajournal.com) (アクセス日: 2023 年 18 月 10 日)。

• HIPAA ポリシー & 管理ポリシーの設計 |Dash Solutions (dashsdk.com) (Accessed: 18/10/2023)。

• 45 CFR § 164.304 - 定義。 |連邦規制電子コード (e-CFR) |米国法 |LII

• / 法務情報研究所 (cornell.edu) (アクセス: 18/10/2023)。

• HIPAA コンプライアンスとは HIPAA 法 & 規則 |Proofpoint UK (アクセス: 2023 年 18 月 10 日)。

• HIPAA セキュリティ規則、規制および標準 (training-hipaa.net) ( アクセス日: 2023 年 18 月 10 日)。

• HIPAA セキュリティ規則の概要 | HHS.gov (アクセス日: 2023 年 18 月 10 日)。

• SP 800-66 Rev. 1 医療保険の移植性と説明責任に関する法律 (HIPAA) セキュリティ 規則を実装するための入門リソース ガイド |CSRC (nist.gov) (アクセス: 2023 年 18 月 10 日)。

• セキュリティ規則 | HHS.gov (アクセス日: 2023 年 18 月 10 日)。

• https://www.hipaajournal.com/hipaa-encryption-requirements (アクセス: 2023 年 19 月 10 日)。

• https://www.hipaajournal.com/hipaa-privacy-rule/ (アクセス: 2023 年 19 月 10 日)。

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (アクセス: 2023 年 19 月 10 日)。

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Accessed: 19/10/2023)。

• 暗号化の構成 — MongoDB Manual (アクセス済み: 2023 年 19 月 10 日)。

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (アクセス: 2023 年 19 月 10 日)。

• Microsoft Purview データ損失防止: いくつかの機能の一般提供の発表

• Microsoft Community Hub (Accessed: 24/10/2023)。

• 45 CFR § 164.308 - 管理上のセーフガード。 |連邦規制の電子コード (e-CFR)

• |米国法 |LII/ Legal Information Institute> (cornell.edu) (Accessed: 24/10/2023)。

• プライバシー情報はいつ提供すればよいですか? |ICO (アクセス: 2023 年 8 月 11 日)。

• プライバシー情報を下書きする方法 |ICO (アクセス: 2023 年 8 月 11 日)。

• アビリティ フレームワーク |ICO (アクセス: 2023 年 8 月 11 日)。

• ISO 27001 要件 5.1 - リーダーシップ & コミットメント | ISMS.online (アクセス日: 2023 年 8 月 11 日)。

• オンライン閲覧プラットフォーム (OBP) (iso.org) (アクセス: 2023 年 8 月 11 日)。

• 第 5.3 条 組織の役割、責任および権限 - ISO トレーニング (アクセス: 2023 年 8 月 11 日)。

• 5.3 ロール、責任、権限 (iso9001help.co.uk) ( アクセス日: 2023 年 8 月 11 日)。

• 機密データ保護を使用した大規模データセットでの PII の識別解除と再識別|クラウド アーキテクチャ センター |Google Cloud (アクセス日: 2023 年 8 月 11 日)。

• 機密データの識別解除 |機密データ保護に関するドキュメント |Google Cloud (アクセス日: 2023 年 8 月 11 日)。

• データ セキュリティのガイド |ICO (アクセス: 2023 年 8 月 11 日)。

• 国際データ転送 |ICO (アクセス: 2023 年 8 月 11 日)。

• レコードの管理とセキュリティ |ICO (アクセス: 2023 年 8 月 11 日)。

• ISO 27701 - プライバシー情報管理 (アクセス日: 2023 年 8 月 11 日)。

• ISO 27701 プライバシー情報管理システム (PIMS) | ISMS.Online (アクセス日: 2023 年 8 月 11 日)。

Microsoft ドキュメントから取得した画像/テキスト

• https://www.sans.org/information-security-policy/ (アクセス: 18/02/21)。

• 行動分析と異常検出を取得 します (Accessed:03/05/24)。

• Azure Monitor アラートとは (Accessed:03/05/24)。

• 行動分析と異常検出を取得する

• (Accessed:03/05/24)。

• Microsoft Defender for Cloud でのセキュリティ アラートの管理と対応 (Accessed:03/05/24)。

• Microsoft Defender for Cloud でのセキュリティ アラートの管理と対応 (Accessed:03/05/24)。

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (アクセス: 09/10/23)。

• Azure Information Protection とは

• SQL Database、SQL Managed Instance、Azure Synapse Analytics の透過的なデータ暗号化 (Accessed:03/05/24)。

• クイック スタート: ポリシー割り当てを作成して、準拠していないリソースを識別 します (Accessed:03/05/24)。

• Azure SQL データベースの Advanced Threat Protection を構成します (Accessed:03/05/24)。

• Azure Database for MySQLでのバックアップと復元 - フレキシブル サーバー (Accessed:03/05/24)。

• 証明書インベントリ (Accessed:03/05/24)。

• Azure Database for MySQLでのバックアップと復元 (Accessed:03/05/24)。

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Accessed: 08/11/2023)。

詳細情報

• サンプル証拠ガイド - 概要
• サンプル証拠ガイド - 操作