V8: データ保護
管理目標
堅実なデータ保護には機密性、完全性、可用性 (CIA) という三つの重要な要素があります。この標準規格では、堅牢化され十分な保護が施されているサーバなど、信頼できるシステムでデータ保護が実施されていることを前提としています。
アプリケーションはすべてのユーザデバイスが何らかの方法で危殆化されていると想定する必要があります。共有コンピュータ、スマホ、タブレットなどのセキュアでないデバイスにアプリケーションが機密情報を転送または保存する場合、アプリケーションはこれらのデバイスに保存されたデータが暗号化され、容易かつ不正に入手、改竄、開示されないようにする責任があります。
検証対象のアプリケーションが以下の上位のデータ保護要件を満たすことを確認します。
機密性: データは転送時および保存時のいずれにおいても不正な閲覧や開示から保護されるべきです。
完全性: データは認可されていない攻撃者による偽造、改竄、削除から保護されるべきです。
可用性: データは認可されたユーザに必要に応じて利用可能であるべきです。
V8.1 一般的なデータ保護
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
8.1.1 | [修正, 8.1.2 からマージ] アプリケーションは機密データをロードバランサやアプリケーションキャッシュなどのサーバコンポーネントにキャッシュされないように防止している、もしくはデータを使用後に安全に削除している。 | ✓ | ✓ | 524 | |
8.1.2 | [削除, 8.1.1 へマージ] | ||||
8.1.3 | [削除, 不十分な影響] | ||||
8.1.4 | アプリケーションが、IP 、ユーザ、1時間または1日あたりの合計数、またはアプリケーションにとって意味のあることなど、異常な数の要求を検出および警告できる。 | ✓ | ✓ | 770 | |
8.1.5 | [削除, スコープ外] | ||||
8.1.6 | [削除, スコープ外] | ||||
8.1.7 | [追加] 正しいコンテンツタイプを持ち、機密性の高い動的コンテンツを含まないレスポンスのみをキャッシュするように、キャッシュメカニズムが設定されている。存在しないファイルがアクセスされる場合、Web サーバーは有効な別のファイルを返すのではなく 404 または 302 レスポンスを返す必要がある。これにより Web Cache Deception 攻撃を防ぐことができる。 | ✓ | ✓ | 444 | |
8.1.8 | [追加] アプリケーションの制御外で望ましくないデータ収集を防ぐために、定義された機密データは信頼できないパーティ (ユーザトラッカーなど) には送信されない。 | ✓ | ✓ | 200 |
V8.2 クライアント側のデータ保護
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
8.2.1 | [修正] 機密データがブラウザでキャッシュされないように、アプリケーションは十分なキャッシュ防止ヘッダ (つまり Cache-Control: no-store) を設定している。 | ✓ | ✓ | ✓ | 525 |
8.2.2 | [修正, 3.2.3 からマージ] ブラウザストレージ (localStorage, sessionStorage, IndexedDB, Cookie など) に保存されているデータに、Cookie または sessionStorage に保存する必要があるセッショントークンを除いて、機密データが含まれていない。 | ✓ | ✓ | ✓ | 922 |
8.2.3 | [修正] クライアントやセッションが終了した後、ブラウザ DOM などのクライアントストレージから認証データがクリアされる。"Clear-Site-Data ヘッダ" で対応できるかもしれないが、サーバ接続が失われた場合にはクライアント側でもクリアできるようにしておく必要がある。 | ✓ | ✓ | ✓ | 922 |
V8.3 機密性の高い個人データ
このセクションは、特に大量の場合に、機密データを許可なく作成、読み取り、更新、削除することから保護するのに役立ちます。
このセクションへの準拠は V4 アクセス制御、特に V4.2 への準拠を意味します。例えば、許可されていない更新や機密性の高い個人情報の開示から保護するには V4.2.1 を順守する必要があります。完全に網羅するにはこのセクションと V4 に従ってください。
注意: オーストラリアのプライバシー原則 APP-11 や GDPR などのプライバシー規制や法令は、機密性の高い個人情報の保存、使用、および転送の実装にアプリケーションがどのようにアプローチする必要があるかに直接影響します。これには厳しいペナルティから簡単なアドバイスまであります。地域の法令や規制を調べ、必要に応じて資格のあるプライバシーの専門家または弁護士に相談してください。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
8.3.1 | [修正, 3.1.1, 13.1.3 からマージ] 機密データが HTTP メッセージボディまたはヘッダでのみサーバに送信され、URL とクエリ文字列には API キーやセッショントークンなどの機密データが含まれていない。 | ✓ | ✓ | ✓ | 598 |
8.3.2 | [修正, 8.3.9 へ分割, レベル L1 > L3] ユーザが自分のデータをオンデマンドで削除する方法を持っている。 | ✓ | |||
8.3.3 | [修正, レベル L1 > L3] アプリケーションは個人データの収集および利用する方法に関するガイダンスを提供している。ユーザはこの利用についてオプトインの同意を提供する必要がある。 | ✓ | |||
8.3.4 | [削除, 1.8.1 へマージ] | ||||
8.3.5 | [7.2.7 へ移動] | ||||
8.3.6 | [削除, 非実用的] | ||||
8.3.7 | 暗号化を必要とする機密情報や個人情報は、機密性と完全性の両方を提供する承認済みアルゴリズムを使用して暗号化されている。 | ✓ | ✓ | 327 | |
8.3.8 | 機密性の高い個人情報は、古いデータや期限切れのデータが自動的、定期的、または状況に応じて削除される、データ保持分類の対象となっている。 | ✓ | ✓ | ||
8.3.9 | [追加, 8.3.2 から分割] ユーザが自分のデータをオンデマンドでエクスポートする方法を持っている。 | ✓ | |||
8.3.10 | [追加] ユーザーが保存に同意しない限り、ユーザーが送信したファイルのメタデータから機密情報が削除されている。 | ✓ | ✓ | ✓ | 212 |
8.3.11 | [修正, 10.2.2 から移動, レベル L2 > L1] アプリケーションがカメラ、マイク、位置情報などのプライバシー関連機能やセンサーに対する不要な許可や過剰な許可を要求していない。 | ✓ | ✓ | ✓ | 272 |
データ保護を検討する際には、主に一括抽出、一括変更、過度の使用について考慮すべきです。例えば、多くのソーシャルメディアシステムではユーザは1日に新しい友人を100人しか追加できませんが、これらの要求がどのシステムから来たのかは重要ではありません。銀行のプラットフォームでは、1000ユーロを超える資金を外部の機関に転送することは、1時間当たり5つの取引まででブロックすることが期待されています。各システムの要件は大きく異なることがあるため、「異常」を判断するには脅威モデルとビジネスリスクを考慮する必要があります。重要な基準はそのような異常な大量アクションを検出、阻止、または可能であればブロックする能力です。
参考情報
詳しくは以下の情報を参照してください。
Last updated