このセキュリティ ドメインは、Microsoft 365 から使用されるデータが転送中と保存中の両方で適切に保護されるように設計されています。 また、このドメインは、GDPR (一般データ保護規則) および HIPAA (1996 年の医療保険の相互運用性と説明責任に関する法律) に沿って、ISV が消費者 (データ主体) のプライバシーに関する懸念を満たしていることを保証します。
転送中のデータ
Microsoft 365 で開発されたアプリ/アドインの接続要件では、パブリック ネットワーク、特にインターネット経由での通信が必要です。 そのため、転送中のデータを適切に保護する必要があります。 このセクションでは、インターネット経由のデータ通信の保護について説明します。
コントロールNo.1
ハード フェイル
次の証拠を提出してください。
すべての TLS 構成は、TLS プロファイル構成要件で強調表示されているように TLS1.2 以上です。
信頼されたキーと証明書のインベントリは保持され、維持されます。
目的: TLS
このサブポイントの目的は、organization によって使用されている Microsoft 365 データが安全に送信されるようにすることです。 TLS プロファイル構成は、中間者攻撃からトラフィックのセキュリティを確保するのに役立つ TLS 固有の要件を定義するために使用されます。
ガイドライン: TLS
これを証明する最も簡単な方法は、標準以外のポートで実行されているものを含むすべての Web リスナーに対して Qualys SSL サーバー テスト ツールを実行することです。
忘れずに [ボードに結果を表示しない] オプションをオンにすると、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 は、シークレット管理、サービスとしての暗号化、特権アクセス管理のためのオープンソース ツールです。
次のスクリーンショットは、実際の証明書と、オンライン コンテナー内に格納されているキーの抜粋です。
注: キーの格納場所に適切なアクセス制御が適用されていることが前提とされます。 秘密キーが侵害された場合、誰かが正当な証明書を使用してサーバーを偽装する可能性があります。
証拠の例: キーと証明書
次のスクリーンショットは、Azure KeyVault に格納されている証明書の証拠の例を示しています。
証拠の例: キーと証明書
信頼できるキーと証明書のインベントリは、次のスクリーンショットに示すようにインベントリ機能を提供する Microsoft 365 Defender で管理することもできます。
![Microsoft Defender の [インベントリ] ページ。](media/data/image018.jpg)
次のスクリーンショットは、証明書の詳細を示しています。
![Microsoft ルート証明機関 2010 が表示された [Microsoft Defender インベントリ] ページがポップアップ表示されます。](media/data/image020.jpg)
注意: これらの例は全画面のスクリーンショットではありません。証拠レビューのために、任意の URL、ログイン ユーザー、日時スタンプを含む全画面のスクリーンショットを送信する必要があります。 Linux ユーザーの場合、これはコマンド プロンプトを使用して実行できます。
コントロール No. 2
次の証拠を提出してください。
TLS 圧縮は、圧縮率情報漏洩が容易になった (CRIME) を防ぐために、Web 要求を処理するすべての公開サービスに対して無効になっています。
TLS HTTP Strict Transport Security (HSTS) が有効になっており、すべてのサイトで最小経過期間が 180 日になるように構成されています。
目的: TLS
CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) 攻撃は、Secure Sockets Layer (SSL)/トランスポート層セキュリティ (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
ハード フェイル
次の証拠を提出してください。
保存データは、次のような暗号化アルゴリズムを使用して、暗号化プロファイルの要件に従って暗号化されます。Advanced Encryption Standard (AES)、Blowfish、XChaCha20。
暗号化キーのサイズは 128 ビット以上です。
意図: 一部の古い暗号化アルゴリズムには、暗号化上の弱点が含まれていることが知られており、脅威アクターがキーを知らずにデータを復号化できる可能性が高くなります。 このため、この制御の目的は、業界で認められている暗号化アルゴリズムのみを使用して、格納されている M365 データの保護です。
ガイドライン: 証拠はスクリーンショットを使用して提供でき、データベースやその他の保存場所内の M365 データを保護するために暗号化が採用されていることを示しています。 証拠は、暗号化構成が Microsoft 365 認定の 暗号化プロファイル構成要件 に準拠していることを証明する必要があります。
証拠の例: 次のスクリーンショットは、Contoso データベースで TDE (透過的なデータ暗号化) が有効になっていることを示しています。 2 番目のスクリーンショットは、Microsoft ドキュメント ページ「SQL Database、SQL Managed Instance、および Azure Synapse Analytics の透過的なデータ暗号化」を示しています。AES 256 暗号化が TDE に使用されていることAzure示しています。
注: 前の例では完全なスクリーンショットは使用されていませんが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログインしているユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。
証拠の例: 次のスクリーンショットは、BLOB とファイルの暗号化で構成された Azure Storage を示しています。 次のスクリーンショットは、保存データのストレージ暗号化Azure Microsoft ドキュメント ページを示しています。このスクリーンショットは、Azure Storage が暗号化に AES-256 を使用していることを示しています。
データの保持、バックアップ、および廃棄
ISV が Microsoft 365 データを使用して格納する場合は、脅威アクターが ISV 環境を侵害した場合にデータ侵害のリスクがあります。 このリスクを最小限に抑えるために、組織はサービスを提供するために必要なデータのみを保持し、将来「役立つ」可能性のあるデータは保持しないでください。 さらに、データを保持するのは、データがキャプチャされたサービスを提供するのに必要な期間のみです。 データ保持について定義し、ユーザーに伝える必要があります。 データが定義された保持期間を超えたら、データを再構築または回復できないように、これを安全に削除する必要があります。
コントロール No. 4
次の証拠を提出してください。
承認されたデータ保持期間が正式に確立され、文書化されます。
目的: 文書化され、従われた保持ポリシーは、一般データ保護規則 (EU GDPR) やデータ保護法 (UK DPA 2018) などのがこれらに限定されないデータ プライバシー法などの一部の法的義務を満たすだけでなく、組織のリスクを制限するためにも重要です。 組織のデータ要件と、ビジネスがその機能を実行するために必要なデータ期間を理解することで、組織はデータの有用性が切れた後にデータが適切に廃棄されるようにすることができます。 保存されるデータの量を減らすことで、組織はデータ侵害が発生した場合に公開されるデータの量を減らしています。 これにより、全体的な影響は制限されます。
多くの場合、組織は万が一に備えてデータを保存しておくことができます。 ただし、organization がサービスまたはビジネス機能を実行するためにデータを必要としない場合は、organization のリスクが不必要に増大するため、データを保存しないでください。
このコントロールの目的は、organization がすべての関連データの種類について承認されたデータ保持期間を正式に確立し、文書化していることを確認することです。 これには、さまざまな種類のデータが保存される期間を指定するだけでなく、データの削除または有効期限後のアーカイブの手順の概要も含まれます。
ガイドライン: ビジネスがビジネス機能を実行できるように、データを保持する必要がある期間 (すべてのデータの種類をカバーする必要があります) を明確に詳細に示した完全なデータ保持ポリシーを提供します。 保持ポリシーは、認定を受けるアプリケーションのバックエンド環境内に格納されているすべての顧客データを明確にカバーする必要があります。
証拠の例: 次のスクリーンショットは、Contoso のデータ保持ポリシーを示しています。
注: これらのスクリーンショットは、ポリシー/プロセス ドキュメントのスナップショットを示しています。 ISV には、単にスクリーンショットを提供するだけでなく、実際のサポート ポリシー/手順のドキュメントを共有することが期待されています。
コントロール No. 5
次の証拠を提出してください。
データは、コントロール 4 で説明したように、定義された保持期間のみ保持されます。
目的: このコントロールの目的は、定義されたデータ保持期間が満たされていることを検証することです。 すでに説明したように、組織にはこれを満たす法的義務がある場合がありますが、必要なデータを必要な限り保持することで、データ侵害が発生した場合のorganizationへのリスクを軽減するのに役立ちます。 これにより、データが過度に長期間保持されたり、時期尚早に削除されたりすることがなくなります。これらのリスクは、法的、運用上、またはセキュリティ関連など、さまざまな性質のリスクを引き起こす可能性があります。
ガイドライン: 保存されたデータ (データベース、ファイル共有、アーカイブ、バックアップなど、さまざまなデータの場所すべて) が定義されたデータ保持ポリシーを超えないことを示すスクリーンショットの証拠を (または画面共有を介して) 提供します。 許容されるスクリーンショットの例は次のとおりです。
日付フィールドを持つデータベース レコード。レコードの最も古い順に検索されます。
ファイル ストレージ: 保持期間内にあるタイムスタンプを示す場所。 注: スクリーンショットでは、顧客の個人データや機密データを編集する必要があります。
バックアップ データが定義された保持期間内に保持され、この期間後に適切に削除されることを示すバックアップ レコード。
証拠の例: 次の証拠は、データベース内の最も古いレコードを表示するために、データベース テーブルの内容を 'DATE_TRANSACTION' フィールドで昇順に並べ替えた SQL クエリを示しています。 これは、データが 2 か月未満であり、定義された保持期間を超えないことを示しています。
注: これはテスト データベースであるため、履歴データはあまりありません。
注: 前の例では完全なスクリーンショットは使用されませんでしたが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログイン ユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。
コントロールNo.6
次の証拠を提出してください。
保持期間後にデータを安全に削除するためのプロセスが設置されています。
目的: この制御の目的は、保存期間を超えるデータを削除するために使用されるメカニズムが安全に削除できるようにすることです。 削除されたデータは回復できる場合があります。そのため、削除プロセスは、一度削除するとデータを回復できないように十分に堅牢である必要があります。
ガイドライン: 削除プロセスがプログラムで実行される場合は、このプロセスを実行するために使用するスクリプトのスクリーンショットを提供します。 スケジュールに従って実行する場合は、スケジュールを示すスクリーンショットを提供します。 たとえば、ファイル共有内のファイルを削除するスクリプトを CRON ジョブとして構成する場合、スケジュールと実行されるスクリプトを示す CRON ジョブのスクリーンショット。使用したコマンドを示すスクリプトを入力します。
証拠の例: これは、日付に基づいて保持されているすべてのデータ レコードを削除するために使用できる単純なスクリプトです。ここで、DateAdd は -30 日であり、選択したデータ保持日から 30 日以上経過したすべての保持レコードがパージされます。 スクリプトが必要になることに注意してください。実行中のジョブの証拠と結果。
注: 前の例では完全なスクリーンショットは使用されていませんが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログインしているユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。
証拠の例: 次のスクリーンショットは、Contoso データ保持ポリシー (コントロール 4 から) から取得されています。これは、データの破棄に使用される手順を示しています。
注: このスクリーンショットは、ポリシー/プロセス ドキュメントのスナップショットを示しています。 ISV には、単にスクリーンショットを提供するだけでなく、実際のサポート ポリシー/手順のドキュメントを共有することが期待されています。
証拠の例: この例では、データ レコード保持ポリシーの有効期限が 30 日後に終了日が作成されたレコードを安全に削除するために、Runbook と対応するスケジュールが Azure で作成されています。 このジョブは、毎月の月の最終日に実行されるように設定されています。
次のスクリーンショットは、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
次の証拠を提出してください。
データや暗号化キーにアクセスできるユーザーのリストが保持されます。これには、各ユーザーのビジネス上の正当性が含まれます。
このユーザーのリストは、その職務に必要なアクセス権限に基づいて正式に承認されました。
ユーザーは、承認に記載されている権限で構成されます。
注: ポイント B と C を実演するために、ユーザーのサンプルが選択されます。
目的:
組織は、データと暗号化キーへのアクセスをできるだけ少数の従業員に制限する必要があります。 この制御の目的は、データや暗号化キーへの従業員のアクセスが、そのアクセスに対する明確なビジネス ニーズを持つ従業員に制限されるようにすることです。
ガイドライン:
データや暗号化キーにアクセスできるすべての従業員を文書化する内部システムのドキュメントまたはスクリーンショットと、これらの個人がアクセスできる理由に関する業務上の正当性を提供します。 このリストは、証明書アナリストが次のコントロールのユーザーをサンプリングするために使用します。
証拠の例:
次のドキュメントは、データへのアクセス権を持つユーザーの文書化されたリストとビジネス上の正当性を示しています。
注: このスクリーンショットはポリシー/プロセス ドキュメントを示しています。ISV が実際のサポート ポリシー/手順ドキュメントを共有することが期待されます。
目的: データや暗号化キーへのアクセスを許可するプロセスには承認を含める必要があり、個人のアクセスが職務に必要であることを確認します。 これにより、真のアクセス理由のない従業員が不必要なアクセスを得ないようにします。
ガイドライン: 通常、前のコントロールに対して提供される証拠は、このコントロールをサポートするのに役立ちます。 提供されたドキュメントに正式な承認がない場合、Azure DevOps や Jira などのツール内でアクセスに対する変更要求が送信され、承認されたという証拠が含まれる場合があります。
証拠の例: この一連の画像は、制御 (i) 機密データや暗号化キーへのアクセスを許可または拒否するために作成および承認された Jira チケットを示しています。 この画像は、システム バックエンド環境で暗号化キーの Sam Daily 承認を取得するための要求が Jira で作成されたことを示しています。 これは、書面による承認を得た次のステップとして行われます。
![[承認者] が強調表示されている Jira 承認チケット。](media/data/image068.jpg)
これは、Sam Daily にアクセス権を付与する要求が、経営陣の担当者である Jon Smith によって承認されたことを示しています。 (承認は、変更要求を許可するのに十分な権限を持つユーザーから取得される必要があることに注意してください。別の開発者は許可できません)。
上記は、このプロセスのための Jira のワークフローを示しています。 承認プロセスが自動化されているため、バイパスできない承認プロセスを経ていない限り、何も [完了] として追加できないことに注意してください。
プロジェクトボードは現在、サム・デイリーの暗号化キーへのアクセスが承認されたことを示しています。 次のバックログには、Sam Daily のリクエストの承認と、作業を行うように割り当てられたユーザーが表示されます。
このコントロールの要件を満たすには、これらすべてのスクリーンショット、または該当する類似/同等の証拠を、コントロール要件を満たしていることを示す説明と共に提示する必要があります。
注: 前の例では完全なスクリーンショットは使用されていませんが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログインしているユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。
証拠の例: 次の例では、運用 DB に対してユーザーに対して管理者アクセス権とフル コントロール アクセス許可が要求されています。 画像の右側に示すように、要求は承認のために送信されました。左側に示すように、これは承認されています。
次の画像は、アクセスが承認され、完了としてサインオフされたことを示します。
注: 前の例では完全なスクリーンショットは使用されていませんが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログインしているユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。
目的 このサブポイントの目的は、データや暗号化キーのアクセスが文書化されたとおりに構成されていることを確認することです。
ガイドライン: 証拠は、サンプル化された個人に付与されたデータや暗号化キーのアクセス特権を示すスクリーンショットによって提供できます。 証拠はすべてのデータの場所をカバーする必要があります。
証拠の例: このスクリーンショットは、ユーザー "John Smith" に付与されたアクセス許可を示しています。これは、クロス
前のコントロールの証拠に従って、この同じユーザーの承認要求に対して参照されます。
注: 次の例は全画面のスクリーンショットではありません。任意の URL、ログインしているユーザー、証拠レビュー用の日時スタンプを含む全画面表示のスクリーンショットを送信する必要があります。 Linux ユーザーの場合、これはコマンド プロンプトを使用して実行できます。
コントロールNo.9
次の証拠を提出してください。
データが共有されるすべてのサード パーティのリストが維持されます。
データを使用するすべてのサード パーティとデータ共有契約が締結されます。
目的: Microsoft 365 データの保存または処理にサード パーティが使用されている場合、これらのエンティティは重大なリスクをもたらす可能性があります。 組織は、適切なサード パーティのデュー デリジェンスと管理プロセスを開発して、このようなサード パーティがデータを安全に保存/処理していることを確認し、GDPR に基づくデータ処理者としてなど、法的義務を確実に尊重する必要があります。
組織は、以下の一部またはすべてとデータを共有するすべてのサード パーティのリストを維持する必要があります。
どのようなサービスが提供されているのか
共有されるデータ
データが共有される理由
主要な連絡先情報 (つまり、主要連絡先、違反通知連絡先、DPO など)
契約の更新/有効期限
法的/コンプライアンス義務 (GDPR、HIPAA、PCI DSS、FedRAMP など)
ガイドライン: Microsoft 365 データが共有されるすべてのサード パーティを詳しく説明したドキュメントを提供します。
注: サード パーティを使用していない場合は、シニア リーダーシップ チームのメンバーによる書面 (電子メール) による確認が必要です。
証拠の例:
![[データ処理の詳細] ページ。](media/data/image080.jpg)
ご注意ください: - 前の例では、完全なスクリーンショットは使用されませんでしたが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログインしているユーザー、システムの時刻と日付を示す完全なスクリーンショットである必要があります。
証拠の例:
次のスクリーンショットは、Microsoft 365 データの処理にサード パーティを使用していないことを確認する上級リーダーシップ チームのメンバーのメールの例を示しています。
ご注意ください: - これらの例では、完全なスクリーンショットは使用されていませんが、ISV が提出したすべての証拠のスクリーンショットは、URL、ログインしているユーザー、システムの日時を示す完全なスクリーンショットである必要があります。
目的: M365 データがサード パーティと共有されている場合、データが適切かつ安全に処理されていることが重要です。 サード パーティが必要な場合にのみデータ処理を行い、サード パーティが自社のセキュリティ義務を理解していることを保証するために、データ共有契約を締結する必要があります。 組織のセキュリティは、最も弱いリンクと同じくらい強力です。 この制御の目的は、サード パーティが組織の弱いリンクにならないようにすることです。
ガイドライン: サード パーティと締結しているデータ共有契約を提供します。
証拠の例: 次のスクリーンショットは、データ共有契約の簡単な例を示しています。
注: 契約書全体は、スクリーンショットではなく共有する必要があります。
プライバシー
プライバシー、コンプライアンス、情報管理は、個人の権利を保護し、責任あるデータ処理を確保するために不可欠です。 organization が効果的なプライバシー情報システムを確立するためには、どのような個人データを保持しているか、およびそのようなデータを処理および保存する目的を知る必要があります。 organization は、いくつかの異なるタイプの処理が発生している可能性があることを認識して、情報の流れとこれが処理される方法をマッピングする必要があります。
コントロール No. 10 – 個人データ
Your organization が次のことを示す証拠を提供する:
収集、処理、保存されるすべての個人データ (各データ要素の目的を含む) の最新のインベントリを維持します。
ビジネス目的に必要なフィールドのみを含むデータ収集フォームを設計し、必須フィールドとオプション フィールドを適切に実装します。
収集できる個人データの種類とそれらを使用する目的を指定するポリシーを策定し、適用します。
ユーザーは、ビジネス以外の個人データの処理や広範な表示をオプトアウトできます。
目的: この制御の目的は、データの収集に関するデータ プライバシーを確実に遵守し、キャプチャされるデータに正当性があることを確認し、収集されるデータについて透明性を保つことです。 ユーザー (データ主体) が処理をオプトアウトできることも重要です。
ガイドライン: このコントロールは次のように証明できます。
A) organization's Record of Processing Activities (RoPA) の最新版 (GDPR 第 30 条を参照)、またはデータ要素および処理の目的を詳しく説明した同様の文書 (GDPR 第 5.1.b 条を参照) を提供します。
ほとんどの場合、これは Excel スプレッドシートです (OneTrust などのツールから抽出できます)。
ファイルが大きすぎる場合、または機密データが含まれている場合は、特定のデータ サンプルのすべてのデータ フィールドを示す抜粋を提供することができます。
非準拠: レコードが存在しないか、非常に古くなっているか古いか、キー フィールドがありません。
B) 「データの最小化」( GDPR 第 5.1.c 条を参照) の目的で、オンライン、タブレットまたは同様のデバイス (会議など)、または紙を使用した場合にかかわらず、データの取得に使用されるすべてのフォームを提供します。 これらは空白/テンプレートでもかまいません。
非準拠: フォームには、意図された処理目的には必要のない必須フィールドがあります。 たとえば、電話番号、年齢、性別を尋ねたり、パンフレットをメールや郵便の住所に送信したりする場合などです。
c) 「合法性、公平性、透明性」( GDPR 第 5.1.a 条を参照) の目的で、プライバシー ポリシー (従業員を対象)、プライバシー通知 (ユーザー/顧客を対象) を制定する必要があります。 通常、プライバシー通知は organization の Web サイトで公開する必要があります。
非準拠: ポリシーが存在しないか、重要な要素がありません。
主要な要素:
プライバシーポリシー/通知:情報の収集と使用、処理されるデータ要素、処理の目的、処理の合法性、他の国へのデータ転送、データ主体の権利、データの保存と保持。
D) オプトアウト メカニズム ( GDPR 第 4.11 条、 GDPR 第 6 条、 GDPR 第 7 条を参照) については、通常は Web ページ上に記述します。 ユーザーがそのページにアクセスするために従う必要があるナビゲーションを確認します (例: 見つけやすいか?)。
非準拠: 明確なオプトアウト機能、または "汎用的な" オプトアウトを、粒度なしでありません。
証拠の例:
A)の場合:
B)の場合:
For C):
D)の場合:
コントロール No. 11 – ユーザーの認識
ユーザーが認識している証拠を提供する:
データにアクセスできるユーザー。
作業しているスペースにアクセスできるユーザー。
共有やデータ フローを通じてデータにアクセスして、情報に基づいた意思決定を行える人。
目的: このコントロールの目的は、データ保護の "透明性" の原則 (GDPR 第 5.1.a 項を参照) が満たされていることを示すことです。
ガイドライン: これが実施されていることを示すには、理想的には、何らかの形式のユーザーの確認 (プライバシー ポリシーを読んだことなど) を設定し、記録する必要があります。
実際には、プライバシーポリシー(従業員向け)、プライバシー通知(ユーザーおよび顧客向け)が、以下について十分な詳細を提供することだけです。
- 個人データの共有先(処理者、復処理者、第三者、請負業者など)。
準拠していない: 謝辞がないか、プライバシー ポリシー/プライバシー通知が存在しません。
証拠の例:
または
コントロール No. 12 – データ処理契約 (DPA)
データ処理契約の証拠を提供する。これには、承認されたすべてのサード パーティ/復処理者のリストが含まれている必要があります。
目的: データ主体に対して透明性を確保し、どのサード パーティ/サブプロセッサーがデータにアクセスできるか、処理で果たす役割 (データ コントローラー、データ処理者)、それぞれの責任、およびセキュリティ メカニズムについて確実に通知します。
また、データの共有に EU 外の地域へのデータ転送が含まれる場合 (GDPR に基づく)、転送が合法であることを保証するメカニズムの詳細。 ( GDPR 第 5 条 および GDPR 第 44-50 条を参照)
GDPR の場合、処理する地域は次のいずれかの条件を満たしている必要があります。
- 欧州連合加盟国であること。
- 欧州委員会によって「適切な保護措置」を提供していると見なされること。 最新のリストはこちらにあります: EU 以外の国におけるデータ保護の妥当性
2025 年 6 月 13 日現在:
データ プライバシー フレームワーク (DPF) に参加し、以下に記載されています: データ プライバシー フレームワーク
拘束力のある企業規則 (BCR) を制定します。
Standard Contractual Clauses (SCC) を設定してください。
ガイドライン: 証拠は、既存の復処理者とのいくつかのデータ処理契約 (DPA) をサンプリングすることによって行うことができます。 場合によっては、組織には DPA がなくても、契約の補遺、つまり「プライバシー条項」があります。
非準拠:
サード パーティ/サブプロセッサのリストがありません。
受領国の詳細は明らかにされていません。
これらの国は「適切な国」としてリストされておらず、BCR や SCC もありません。
証拠の例: この例は IAPP の DPA の例を示しています。または、データが共有されている関係者をリストした関連ドキュメントが証拠である可能性があります。
さらに、EU 外へのデータ転送のメカニズムをチェックします。
コントロール No. 13 – データ保護影響評価 (DPIA)
organizationがデータ保護影響評価 (DPIA) を実施しているという証拠を提供する
または
このプライバシー レビューが関連付けられているデータ プライバシーと保護に関連する評価の名前を入力します。
目的: このコントロールの目的は、個人の権利と自由に対する潜在的なリスク、特に新しいテクノロジの導入や既存のテクノロジの新たな使用に関連して、評価を確実に実行することです。 ( GDPR の第 35 条を参照)
ガイドライン: このコントロールは、最新の DPIA または関連する評価ドキュメントを確認することによって評価されます。
非準拠:
DPIA には、次の要素が必要です。
DPIA の必要性の特定。
範囲、コンテキスト、目的を含む、想定される処理の説明。
必要性と比例性の評価。
リスクの特定と評価。
リスクを軽減するための対策の特定。
記録された結果。
上記のいずれかが欠落している場合、またはおざなりなレベルで実行された場合、このコントロールは非準拠としてマークできます。
証拠の例:
DPIAの完全なテンプレートは、ICOのWebサイトで見つけることができます 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) を満たす必要があります。 これは、データ管理者 (当該データを直接取得する) またはデータ処理者 (データ管理者に代わってこのデータを処理する) の両方に適用されます。 このセクションでは規制全体を網羅しているわけではありませんが、GDPR の重要な要素のいくつかを取り上げ、organizationが GDPR を真剣に受け止めていることをある程度保証するのに役立ちます。
コントロール No. 16
以下を示すことによって、データ主体の権利の遵守を証明する証拠を提供する。
サブジェクト アクセス要求 (SAR) ファシリテーション: データ主体が個人データにアクセスする権利を通知され、サブジェクト アクセス要求 (SAR) をorganizationに送信できることを確認するドキュメント。
データ検出とSARフルフィルメント:SARに対応して、すべてのシステムとリポジトリで個々のデータ主体に関連するすべての個人データを検索して取得するorganizationの能力の証拠。
目的: この制御の目的は、データ主体が organization によって保持されている個人データについて要求を行うための適切なメカニズムが整備され、正当な要求が徹底されるようにすることです。 ( GDPR の第 15 条を参照してください)。
ガイドライン: A) プライバシーに関する通知には、SAR を作成する方法に関する詳細を含める必要があります。SAR には、次の方法を使用できます。
組織が提供する Web フォームを使用する organization
organization から提供されたメール アドレスを使用する
organization が提供する電話番号/Web チャットを使用する
監督機関の使用 (英国の ICO など)
実施されている方法の証拠を要求します。画面キャプチャで十分です。
B) RoPA または同様のドキュメントを使用して、デジタルまたはファイリング システムの一部 (物理) として、データ主体に関する個人データが存在する場所を特定できます。
あるいは、電子情報開示演習でも同じ結果を達成できます。
SAR を満たすために使用されるプロセス/ワークフローの証拠と、プロセスが徹底しており、データ主体に関連する個人データを見逃さないと判断された経緯についての説明を要求します。
非準拠:
A) organization の Web サイト (通常はプライバシーに関する通知) には情報が提供されていません。
B) 個人データを収集するプロセスが完全ではないか、技術的な詳細が欠けている可能性があることを示す証拠 (データベースの名前/場所が指定されていないなど)。
証拠の例:
A) 以下は、ポイント A) をカバーするために提供できる証拠の例です。
- Web フォーム:
出典: サブジェクト アクセス要求 - Police Care UK
- Email address/phone number:
- Web チャット:
ソース: HMRC にサブジェクト アクセス要求を行う - GOV.UK
- 監督機関 (ICO など) 経由:
B) 提供された証拠アーティファクト SAR を満たすためにもっともらしく使用できる、十分な技術的詳細を含むワークフローまたはプロセスの説明を詳述する。 次のスクリーンショットは、サブジェクト アクセス要求 (SAR) に応答して、Azure SQL Database から特定のデータ主体に関連するすべての個人データを検索して取得する組織の機能の証拠の例を示しています。 この例では、管理者がAzure SQL クエリ エディター内で事前定義されたストアド プロシージャを実行して、複数の運用データベース表にわたって一意のデータ主体 ID に関連付けられたレコードを取得する様子を示しています。
次のスクリーンショットは、サブジェクト アクセス要求 (SAR) に応答して、Azure ストレージ アカウントから特定のデータ主体に関連するすべての個人データを検索して取得するorganizationの機能の証拠の例を示しています。 この例では、管理者が Azure Blob Storage 内で一意のデータ主体識別子に関連付けられているすべてのドキュメントを検索する様子を示しており、環境内に格納されている非構造化個人データを識別して取得する organization の能力を示しています。
コントロール No. 17
ハード フェイル
次のすべての必要な要素を含むプライバシーに関する通知を提供します。
organization の ID と連絡先の詳細、および該当する場合はデータ保護責任者 (DPO)。
organization が処理する個人データの種類 (名前、姓、顧客番号、電子メール アドレス、電話番号など)。 また、organizationがデータ主体から直接取得していない場合の個人データソース(個人データの取得元など)。
個人データを処理する目的。
個人データの処理の法的根拠 (該当する場合は正当な利益を含みます)。
あなたの organization が個人データを共有する当事者。
個人データが保持される期間の詳細。
データ主体の権利の詳細:
情報を得る権利
アクセス権
是正する権利
消去する権利
処理を制限する権利
データの移植性に対する権利
異議を申し立てる権利
プロファイリングを含む自動化された意思決定に関連する権利
第三国への個人データの転送および講じられた安全対策に関する詳細。
監督当局 (英国の ICO など) の連絡先の詳細を提供して、監督当局に苦情を申し立てる権利。
目的: GDPR 第 3 章に従って、上記の要素と原則を含めることにより、公開されたプライバシー通知に十分な詳細が含まれていることを確認するための目的です。
ガイドライン: コントロール 10.c に従って、Microsoft 365 認定に含まれるサービスを対象とするプライバシー通知を公開する必要があります。 このプライバシー通知には、上記で強調した要素と原則が含まれている必要があります。
非準拠:
Control 10.cを参照してください。
証拠の例:
メモ: お客様ご自身のプライバシーに関する通知は、実際のアプリケーションおよび Web サイトを正確に反映している必要があります。 通知は会社の Web サイトで公開され、一般公開されている必要があります。
HIPAA (医療保険の相互運用性と説明責任に関する法律)
1996 年の医療保険の相互運用性と説明責任に関する法律 (HIPAA) は、米国市民と医療機関に適用される連邦法です。 この法律は、米国国民の医療データを処理する米国外の組織にも適用されていることに注意することが重要です。 この法律の導入により、米国保健社会福祉省 (HHS) 長官は、特定の医療情報のプライバシーとセキュリティを保護する規制を策定することが義務付けられました。 組織によっては、保護される可能性のある医療情報 (ePHI) として扱われるデータを処理する場合があります。ePHI とは、電子メディアで送信される、電子メディアで維持される、またはその他の形式や媒体で送信または維持される、個人を特定できる健康情報を意味します。 いずれかのデータ主体の正常性データが処理される場合、組織は HIPAA を満たす必要があります。
HIPAA には、検討する必要がある 2 つの法律があります。特定の健康情報を保護するための国家基準を概説した「プライバシー ルール」または個人を特定できる健康情報のプライバシー基準と、「セキュリティ ルール」とも呼ばれる電子保護医療情報の保護に関する「セキュリティ基準」です。 後者は、電子形式で保持または転送される特定の健康情報を保護するための一連のセキュリティ基準を確立します。
大まかに言うと、「セキュリティ ルール」は、「プライバシー ルール」によって提供される保護の実際的な実装です。 これは、「対象となるエンティティ」が個人の「電子的に保護された健康情報」(e-PHI)のセキュリティを確保するために実施しなければならない技術的および非技術的対策の概要を示しています。 このセクションでは規制全体を網羅しているわけではありませんが、HIPAA の重要な要素のいくつかを取り上げ、organization が要件への準拠を満たしていること、および organization が処理する医療情報を保護していることをある程度保証するのに役立ちます。
コントロール No. 18
次の証拠を提供することにより、お客様のorganizationが医療保険の相互運用性と説明責任に関する法律 (HIPAA) に準拠していることを証明する証拠を提供します。
プライバシー慣行通知 (NPP) と従業員トレーニング: プライバシー慣行通知が制定され、HIPAA に基づく保護医療情報 (PHI) の取り扱いに関する従業員トレーニング プログラムが、従業員、請負業者、ベンダー、およびその他の関係者向けに確立されます。
電子保護医療情報 (ePHI) の保護対策: お客様のorganizationは、HIPAA セキュリティ規則で要求されている管理上、物理的、および技術的な保護手段を実装して、作成、受信、維持、または送信するすべての電子 PHI (ePHI) の機密性、整合性、および可用性を確保しています。
リスク管理ポリシー: organization には、ePHI のセキュリティまたは完全性に対する合理的に予想される脅威や危険から保護するためのリスク管理ポリシーと対策があります。
目的: このサブポイントの目的は、組織が医療情報の管理、緊急事態やサービスの中断への対処、および医療情報とトレーニングへのスタッフのアクセスのための標準的な手順として機能するプロトコルを確立できるようにすることです。 さらに、組織は HIPAA セキュリティ プログラムの一環として、これらの管理上の保護措置を維持し、概要を説明することが期待されています。 これは、HIPAA 規制に準拠する上で重要な側面です。
ガイドライン: これは、HIPAA のポリシーと手順を概説する organization の確立された文書を提供することによって証明されます。 認証アナリストはこれをレビューして、コントロール内で提供されたすべての情報が確実に対処されていることを確認します。
証拠の例: スクリーンショットは、HIPAA ポリシーのスナップショットを示しています。 注: ISV は、単にスクリーンショットを提供するのではなく、実際のサポート ポリシー/手順のドキュメントを共有することが期待されています。
注: ISV は、単にスクリーンショットを提供するのではなく、実際の包括的なサポート ポリシー/手順のドキュメントを共有することが期待されます。
目的:
このサブポイントの意図を理解し、セキュリティ ルールへの準拠を確保するために、「対象となるエンティティ」は、まず、機密性、完全性、可用性の条件が § 164.304 でどのように定義されているかを知る必要があります。
機密性: "データまたは情報が権限のない人やプロセスに利用または開示されないというプロパティ。"
整合性: "データまたは情報が不正な方法で変更または破壊されていないというプロパティ。"
可用性: "承認された人物の要求に応じてデータまたは情報にアクセスでき、使用できるプロパティ。"
この要件の目的は、組織が IT インフラストラクチャ内にアクセス、監査、整合性、および送信制御などの技術的な保護手段/対策を実装して、ePHI の機密性を確保しながら、許可されたユーザーへの整合性と可用性を維持することです。
ガイドライン:
証拠は、ePHIデータが制御要件に沿って保護されることを保証するために使用される保護メカニズムの構成設定によって提供される場合があります。 このようなメカニズムには、アクセス制御、緊急アクセス手順、RBAC、暗号化などが含まれる場合があります。
証拠の例: アクセスと整合性の制御
次のスクリーンショットは、ePHI ストレージの場所を処理するアクセス許可を持つ個人の承認されたアクセス リストが存在し、HIPAA ポリシー ドキュメント内で維持されていることを示しています。 さらに、承認されたインベントリ リストに続くスクリーンショットでは、クラスター全体の書き込みアクセスが制限されており、管理者とデータベース メンテナンス アナリストだけがクラスターを読み書きできることがわかります。
Atlas Mongo の ePHI ストレージ データベースの 1 つから取得した次のスクリーンショットは、許可されたユーザーのみがアクセスを文書化し、すべてのアカウントに一意のユーザー ID があり、アカウンタビリティが確保されていることを示しています。
最初のスクリーンショットは、ePHI の主な保存場所/データベース クラスターを示しています。
2 番目のスクリーンショットは、承認されたユーザーが文書化されたロールとアクセスだけを持っていることを示しています。
次の 2 つのスクリーンショットは、割り当てられた各ロールと、上記のアクセス承認に沿った関連するすべてのアクセス許可のより詳細なビューを示しています。
各カスタム ロールには、一連のアクセス許可とアクセス範囲があります。
最後に、次のスクリーンショットは、ネットワークの観点から、セキュリティで保護された企業ネットワークである承認された IP 範囲のみがクラスターへのアクセスを許可されていることを示しています。
証拠の例: 監査コントロール
これらのスクリーンショットは、データベース クラスターに対してログとアラートが実装されていることを示しています。 最初のスクリーンショットは、アラートが有効になっていることを示しています。 提供された証拠には、organization's need/implimentationに基づいて設定されたアラートルールも示されていることが期待されていることに注意してください。 2 番目のスクリーンショットは、データベース監査が有効になっていることを示しています。
次のスクリーンショットは、記録されるデータベース クラスターへのアクセス履歴を示しています。 アラートが設定され、監査ログに基づいてアラートが設定され、事前定義された条件を満たしていない不正アクセスがアラートをトリガーすることが想定されます。
最後の 2 つのスクリーンショットは、データベース クラスターの監査ログが生成され、分析用にログをエクスポートできることを示しています。
生成された監査ログを分析するためのプロセスが用意されており、レビュー プロセスの証拠も提供する必要があることに注意してください。 これがプログラムで実現されている場合は、使用するプラットフォーム/ログ ソリューションへのログ インジェストの構成設定のスクリーンショットと、ルールのスクリーンショットをレビュー用に提供する必要があります。
証拠の例: 暗号化と伝送の制御
次のスクリーンショットは、保存場所で保存データが既定で暗号化されていることを示しています。 既定で使用されるプラットフォームで暗号化が実行されず、独自の暗号化キーが使用されている場合は、それらのキーが適切にセキュリティで保護され、これを実証する証拠が提供されていることが期待されることに注意してください。
次の 2 つのスクリーンショットは、保存場所で転送中のデータが既定で暗号化されていることを示しています。 最初のスクリーンショットは、データ API が "読み取りと書き込み" のアクセス許可で有効になっていることを示しています。
エンドポイントの SSL スキャンにより、転送中のデータが TLS 1.2 経由で暗号化されていることがわかります。
証拠の例: 可用性と回復制御
次のスクリーンショットは、可用性を確保するためにデータベース クラスターが 3 つのリージョンにレプリケートされていることを示しています。 これは、Mongo Atlas によってデフォルトで実行されます。 さらに、バックアップは有効でアクティブです。
次のスクリーンショットは、クラスターのバックアップ ダッシュボードを示しています。このダッシュボードは、スナップショットがすでに作成されていることも示しています。
次の 2 つのスクリーンショットは、異なる時点 (PIT) にスケジュールされたバックアップを実行するためのバックアップ ポリシーが設定されていることを示しています。
次に示すのは、スナップショットとポイントインタイムリストア (PIT) の両方に保持ポリシーがあることを示しています。
目的: このサブポイントの意図は、柔軟性とスケーラビリティを確保するために開発されたセキュリティ ルールと一致しており、「対象となるエンティティ」は、エンティティの規模、組織構造、特定のリスク、およびリスク選好度に適したポリシー、手順、および技術的ソリューションを実装できます。 実際的な観点から見ると、これは、実施される適切なセキュリティ対策が「対象エンティティ」のビジネスの性質、およびその規模とリソースに依存することを意味します。
すべてのorganizationが包括的なリスク分析を実施して、e-PHIの機密性、完全性、可用性に対する潜在的なリスクと脆弱性を明らかにすることが重要です。 このリスク分析を通じて、組織は適切なセキュリティ制御を実装して、これらの特定されたリスクを軽減できます。
ガイドライン: 証拠は、リスク分析の出力によって提供される場合があります。 リスク分析がオンライン プラットフォームを介して実行および維持される場合は、出力全体のスクリーンショットを提供する必要があります。
証拠の例: 次のスクリーンショットは、リスク評価プロセスのスナップショットと、その後に制御が正しく実装され、ePHI を保護するために意図どおりに動作している程度を判断するために実行されたリスク分析を示しています。 2 番目のスクリーンショットは、リスク評価で特定されたリスクのリスク分析と、リスク レベルを下げるために実装された補正コントロールと軽減策を示しています。
例 1 – HIPAA ポリシー内のリスク評価プロセスのスナップショットと実行されたリスク分析
注: このスクリーンショットはリスク分析ドキュメントのスナップショットを示しています。これは単なる例であり、ISV は単にスクリーンショットを提供するのではなく、実際のドキュメントを共有することが期待されます。
例 2 – HIPAA ポリシー内のリスク評価プロセスと実行されたリスク分析のスクリーンショット (Confluence Cloud Platform で維持)
2 番目のスクリーンショットは、リスク評価で特定されたリスクのリスク分析と、リスク レベルを下げるために実装された補正コントロールと軽減策を示しています。 これは Confluence クラウド プラットフォームに存在し、維持されていることがわかります。
コントロール No. 19
次の証拠を提出してください。
Your organization is is set and implement a data backup plan and a data backup plan (英語情報) 45 CFR §164.308(a)(7)(ii)(B) (データ バックアップ計画) および 45 CFR §164.308(a)(7)(ii)(B) (ディザスター リカバリー計画) に基づく HIPAA セキュリティ規則の管理保護に従って、緊急時対応計画の一部としてデータ バックアップ計画とディザスター リカバリー計画を確立し、実装しました。
目的: プライバシー規則は、保護された医療情報 (PHI) の一部が法律の対象となるかを定義し、PHI の不適切な使用と開示を禁止します。 このサブポイントの意図は、organizationがe-PHIへのアクセスと使用を、許可された目的でそれを必要とする人のみに制限し、意図された目的を達成するために必要な最小限の量のe-PHIのみを使用または開示することを要求する最低限必要な規則に準拠する必要があるということです。
ePHIの使用を制限し、ePHIの開示のリスクを確実に軽減するために、技術的および管理的な保護措置を組み合わせて実施する必要があります。
ガイドライン: 提供された証拠は、e-PHI を保護するために使用されている技術やメカニズムなど、実施されている技術的な保護手段や、organization がそのようなデータのアクセスと移動をどのようにチェックするかを示す必要があります。
証拠の例: 次のスクリーンショットは、組織が DLP ポリシーを 1 か所で管理できるようにする統合プラットフォームである Microsoft Purview データ損失防止 (DLP) を示しています。
以下では、"米国 HIPAA 拡張" ポリシーが有効になっていることがわかります。これにより、サポートされている Web ブラウザーからアクセスしたときに、ユーザーが個人用メール、生成 AI プロンプト、ソーシャル メディア サイトなど、機密データを特定の Web サイトに貼り付けることができないようにすることができます。
次のスクリーンショットは、適用されるスコープなど、ポリシーのより包括的な概要を示しています。 ポリシーは、SharePoint、デバイス、OneDrive などの場所のすべてのアカウントに設定されています。
[ポリシーの編集] オプションを選択すると、使用可能な特定の構成に関するより詳細なビューが表示されます。
次の 2 つのスクリーンショットは、ポリシーを適用するために満たす必要があるコンテンツ定義と条件を示しています。
このポリシーは、さまざまな機密データ型と一連の分類器を対象としています。
次のセクションでは、前のスクリーンショットに示した条件が満たされたときに実行されるように構成されたアクションを示します。
次のスクリーンショットは、ユーザーが organization の内部データベースからサポートされているブラウザー上の個人用メール アカウント、チャットボット、ソーシャル メディア サイトに、個人識別情報 (PII) などの機密情報をコピーして貼り付けないように DLP ポリシーが設定されていることを示しています。
最後に、ユーザ通知は、ePHIデータを処理しているユーザに通知し、ガイダンスを提供するように設定されています。
次のスクリーンショットは、インシデント発生時にアラートを生成するための構成パネルを示しています。
意図: このサブポイントの目的は、organization が e-PHI を安全かつ適切に処理する方法についてスタッフをトレーニングし、セキュリティ ルールへの準拠を確保するためにポリシーと手順を適用する必要があるということです。
ガイドライン: 提供される証拠は、ePHI の処理方法に関する HIPAA トレーニングが実施され、出席とトレーニング完了の記録が存在することを証明する必要があります。 該当する場合は、ポリシー ドキュメントとトレーニング資料を使用してこれをサポートできます。
証拠の例: 次の例は、ポリシーに沿って適切な 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) ブルー チーム ハンドブック: インシデント対応版: サイバー セキュリティ インシデント対応対応者向けの要約フィールド ガイド。 第 2 版、出版社: 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 インストーラー) 入手可能: イベント ログ (アクセス: 2024 年 3 月 5 日)。
ポジティブなテクノロジー。 (2020) セキュアなソフトウェア開発へのアプローチ方法: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023).
個人データの処理およびそのようなデータの自由な移動に関する自然人の保護に関する2016年4月27日の欧州議会および理事会の規則(EU)2016/679、および指令95/46 / EC(一般データ保護規則)(EEAに関連するテキスト)(2016年)の廃止: https://www.legislation.gov.uk/eur/2016/679/contents (アクセス:2023年12月10日)。
セキュリティ メトリック。 (2020) PCI DSS コンプライアンスのセキュリティ メトリック ガイド。 入手可能: https://info.securitymetrics.com/pci-guide-2020(アクセス: 2023 年 12 月 10 日)。
Williams J. OWASP Risk Rankingは、 https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (アクセス: 2023 年 12 月 10 日) で入手できます。
Qualys. (2014) SSL Labs: New grades for Trust (T) and Mismatch (M) issues available at https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accessed: 12/10/2023).
NIST SP800-61R2: コンピューター セキュリティ インシデント処理ガイドは、 https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (アクセス: 2023 年 12 月 10 日) で入手できます。
Azure Pipelines と Google Kubernetes Engine を使用した CI/CD パイプラインの作成 | .NET
Google Cloud (アクセス: 2023 年 10 月 10 日)。
ディザスター リカバリー プラン: https://www.sans.org/white-papers/1164/ (アクセス: 2023 年 10 月 10 日)。
https://github.com/ (アクセス:2023年10月10日)。
セキュリティ ポリシー テンプレート: https://www.sans.org/information-security-policy/ (アクセス: 2023 年 10 月 10 日)。
https://www.openedr.com/ (アクセス日:02/10/23)。
https://www.atlassian.com/software/confluence (アクセス:2023年10月10日)。
https://www.atlassian.com/software/jira (28/09/23アクセス)。
ビジネス継続計画 (BCP) テーブルトップ演習テンプレート: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (アクセス: 2023 年 10 月 10 日)。
HIPAA セキュリティ ルールの概要 | HHS.gov (アクセス: 2023 年 10 月 18 日)。
デジタル時代の医療情報プライバシー法: HIPAA は適用されません - PMC (nih.gov) (アクセス: 2023 年 10 月 18 日)。
HIPAA の目的は何ですか? 更新 2023 (hipaajournal.com) (アクセス日:2023年10月18日)。
HIPAA の下で PHI と見なされるものは何ですか? 2023 年の更新 (hipaajournal.com) (アクセス日:2023年10月18日)。
HIPAA ポリシーと手順 (hipaajournal.com) (アクセス: 2023 年 10 月 18 日)。
HIPAA ポリシー & 管理ポリシーの設計 |ダッシュソリューションズ(dashsdk.com)( アクセス:2023年10月18日)。
/ 法務情報研究所 (cornell.edu) (アクセス: 2023 年 10 月 18 日)。
HIPAA コンプライアンスとは? HIPAA 法 & 規則 |Proofpoint UK (アクセス日:2023年10月18日)。
HIPAA セキュリティ規則、規制、標準 (training-hipaa.net) (アクセス: 2023 年 10 月 18 日)。
HIPAA セキュリティ ルールの概要 | HHS.gov (アクセス: 2023 年 10 月 18 日)。
SP 800-66 Rev. 1、医療保険の相互運用性と説明責任に関する法律 (HIPAA) セキュリティ ルールの実装のための入門リソース ガイド |CSRC (nist.gov) (アクセス: 2023 年 10 月 18 日)。
セキュリティルール | HHS.gov (アクセス: 2023 年 10 月 18 日)。
https://www.hipaajournal.com/hipaa-encryption-requirements (アクセス日:2023年10月19日)。
https://www.hipaajournal.com/hipaa-privacy-rule/ (アクセス日:2023年10月19日)。
https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (アクセス日:2023年10月19日)。
https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (アクセス: 2023 年 10 月 19 日)。
暗号化の構成 — MongoDB マニュアル (アクセス: 2023 年 10 月 19 日)。
https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (アクセス日:2023年10月19日)。
Microsoft コミュニティ ハブ (アクセス: 2023 年 10 月 24 日)。
|米国法 |LII /法的情報研究所> (cornell.edu)( アクセス:2023年10月24日)。
プライバシー情報を提供すべき時期 |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)。
行動分析と異常検出を取得する(アクセス日:2024/03/05)。
Azure Monitor アラートとは (アクセス:03/05/24)。
(アクセス:03/05/24)。
Microsoft Defender for Cloud でセキュリティ アラートの管理と対応を行います (アクセス日:2024 年 3 月 5 日)。
Microsoft Defender for Cloud でセキュリティ アラートの管理と対応を行います (アクセス日:2024 年 3 月 5 日)。
https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (アクセス:09/10/23)。
SQL Database、SQL Managed Instance、および Azure Synapse Analytics の透過的なデータ暗号化 (アクセス日:2024 年 3 月 5 日)。
クイックスタート: ポリシーの割り当てを作成して、準拠していないリソースを特定する (アクセス日:2024 年 3 月 5 日)。
Azure SQL Database の 高度な脅威保護 を構成する (アクセス日:2024 年 3 月 5 日)。
Azure Database for MySQL - フレキシブル サーバーでのバックアップと復元 (アクセス済み:2024 年 3 月 5 日)。
証明書のインベントリ (アクセス日:2024 年 3 月 5 日)。
Azure Database for MySQL でのバックアップと復元 (アクセス日:2024 年 3 月 5 日)。
https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (アクセス: 2023 年 8 月 11 日)。