Skip to content

Latest commit

 

History

History
76 lines (57 loc) · 10.6 KB

0x16-V8-Data-Protection.md

File metadata and controls

76 lines (57 loc) · 10.6 KB

V8 データ保護

管理目標

データ保護を適切に行うには次の 3 つの要素を考慮する必要があります。機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）の CIA です。この標準ではデータ保護が、強固かつ十分な保護を備えるサーバなど信頼できるシステム上でデータ保護が行われていることを想定しています。

アプリケーションは「ユーザデバイスはどれも完全には信頼できない」ことを前提にする必要があります。共有コンピュータや電話、タブレット等の安全でないデバイスに対してセンシティブなデータの送信や保存を行う場合、アプリケーション側が責任を持って、デバイス上に保存するデータを保護し、不正な取得や変更、開示が容易にはできないよう保護する必要があります。解決策としては、永続化されないようにすることや、暗号化された形で保存されるようにすることなどが考えられます。

この章には、どのようなデータを保護する必要があるのか、どのように保護すべきなのか、実装すべき具体的なメカニズム、回避すべき落とし穴といった定義に関連する要件を含んでいます。

V1.8 データ保護とプライバシードキュメント

# 説明 L1 L2 L3 CWE
1.8.1 [修正, 8.3.4, 6.1.1, 6.1.2 からマージ] アプリケーションにより作成および処理されるすべての機密データが特定され、保護レベルに分類されている。機密データの取り扱い方法に関するポリシーが整備されている。これは Base64 や JWT などの復元可能な形式でエンコードされている機密データを含むことに注意する。保護レベルでは、アプリケーションが準拠する必要のあるデータ保護やプライバシー規制を考慮する必要がある。 ✓ ✓ 213
1.8.2 [修正, 8.1.9 へ分割] 文書化された保護要件一式がすべての保護レベルにある。これには一般的な暗号化、完全性検証、リテンション、データのログ記録方法、ログ内の機密データに関するアクセス制御、データベースレベルの暗号化、プライバシー、使用されるプライバシー強化技法に関連する要件、およびその他の機密性要件が含まれている (ただし、これらに限定されない) 。 ✓ ✓

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
8.1.9 [追加, 1.8.2 から分割] 機密データに関するコントロールは特定のデータの保護レベルに対するドキュメントで定義されているとおりに実装されている。 ✓ ✓
8.1.10 [追加] アプリケーションは、アプリケーションの機能に必要な最小限の機密データのみを返している。たとえば、クレジットカード番号の一部の数字のみを返しており、番号全体は返していない。完全なデータが絶対に必要な場合は、ユーザが明示的に表示しない限り、ユーザインタフェースでマスクする必要がある。 ✓

V8.2 クライアントサイドのデータ保護

# 説明 L1 L2 L3 CWE
8.2.1 [修正] ブラウザで機密データがキャッシュされないように、アプリケーションは十分なキャッシュ防止 HTTP レスポンスヘッダフィールド (つまり Cache-Control: no-store) を設定する。 ✓ ✓ ✓ 525
8.2.2 [修正, 3.2.3 からマージ] ブラウザの記憶域（localStorage、sessionStorage、IndexedDB、Cookie など）に保存されるデータに、セッション識別子を除いて、センシティブなデータが含まれていない。 ✓ ✓ ✓ 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.3 [削除, スコープ外]
8.3.4 [削除, 1.8.1 へマージ]
8.3.5 [7.2.7 へ移動]
8.3.6 [削除, 非実用的]
8.3.7 [削除, 1.8.2 と重複]
8.3.8 [レベル L2 > L3] センシティブな個人情報は、古いデータや期限切れのデータが、自動的、定期的、または状況に応じて削除されるなど、データ保持分類の対象となっている。 ✓ ✓
8.3.9 [追加] ユーザーが保存に同意しない限り、ユーザーが送信したファイルのメタデータから機密情報が削除されている。 ✓ ✓ ✓ 212

データ保護を検討する際には、主に一括抽出、一括変更、過度の使用について考慮すべきです。例えば、多くのソーシャルメディアシステムではユーザは 1 日に新しい友人を 100 人しか追加できませんが、これらのリクエストがどのシステムから来たのかは重要ではありません。銀行のプラットフォームでは、1000 ユーロを超える資金を外部の機関に転送することは、1 時間当たり 5 つの取引まででブロックすることが期待されています。各システムの要件は大きく異なることがあるため、「異常」を判断するには脅威モデルとビジネスリスクを考慮する必要があります。重要な基準はそのような異常な大量のアクションを検出、阻止、または可能であればブロックする能力です。

参考情報

詳しくは以下の情報を参照してください。