C2: 暗号を使用してデータを保護する (Use Cryptography to Protect Data)

説明

パスワード、クレジットカード番号、医療記録、個人情報、企業秘密などの機密データは、特にそのデータがプライバシー法 (EU の一般データ保護規則 GDPR)、PCI データセキュリティ標準 (PCI DSS) などの金融データ保護規則、またはその他の規制に該当する場合、特別な保護が必要です。

攻撃者はさまざまな方法でウェブアプリケーションやウェブサービスアプリケーションからデータを窃取できます。たとえば、機密情報を通信セキュリティなしでインターネット経由で送信すると、共有ワイヤレス接続上の攻撃者が他のユーザーのデータを捕捉して窃取するかもしれません。また、攻撃者は SQL インジェクションを使用して、アプリケーションデータベースからパスワードやその他のクレデンシャルを窃取し、その情報を一般に公開するかもしれません。

プライバシーとは、ある主体に関する特定の情報の機密性とその情報へのアクセスが保護されることを保証することです。開発者が構築するもののユーザーは自分の情報が開示されないように保護されることを望んでいます。

パスワード、クレジットカード番号、医療記録、個人情報、企業秘密などの機密データを保護します。

企業に対してユーザーの個人情報を保護するように強制するための規制が存在します。欧州連合は個人のプライバシーを重視しており、EU 一般データ保護規則 GDPR を制定しました。PCI データセキュリティ標準 (PCI DSS) などの金融データ保護規則もカード所有者のプライバシーを保護するために存在します。

暗号技術とは、平文の情報を判読不能にし、暗号化された情報を判読可能な形式に復元するための原理、手段、手法に関する技術や化学です。個々のユーザーデータは、保存時に適切に管理されるように暗号化が必要です。

アプリケーションのデータ型を分類する

システム内のデータを分類し、各データがどの機密レベルに属するかを判断することが重要です。そうすることで、各データカテゴリは各機密レベルに必要な保護ルールにマップできます。たとえば、機密ではない公開マーケティング情報は公開データとして分類され、公開ウェブサイトに掲載しても問題ありません。クレジットカード番号は保存時、処理時、転送時に暗号化する必要があるプライベートユーザーデータとして分類されるかもしれません。

データ分類は、たとえば欧州連合のユーザーにサービスを提供する場合の GDPR のように、法律によって義務付けられることもあります。

システムで送信、処理、保存されるデータを分類し、データがどの機密レベルに属するかを判断します。データを分類して、タイプごとに特定の保護ルールを定義します。ルールの作成により、チームはデータの最小化を実行し、可能な限り機密データを保存しないようにできます。

たとえば、機密性のない公開マーケティング情報は公開データとして分類され、公開ウェブサイトに掲載しても問題ないため、暗号化する必要はありません。クレジットカード番号は保存時、処理時、転送時に暗号化する必要があります。

脅威

  • 攻撃者は脆弱な暗号アルゴリズムや古い暗号アルゴリズムを悪用して、機密情報を復号化する可能性があります。

  • 不適切に保存された暗号鍵が侵害され、認可されていないデータアクセスにつながる可能性があります。

  • 攻撃者は SQL インジェクション攻撃を実行して、データベースから暗号化されたデータを盗む可能性があります。

  • 適切な鍵管理を実装しないと、暗号化されたデータへの認可されていないアクセスにつながる可能性があります。

実装

暗号に関しては、いくつかのシンプルなルールがあります。

  • 決してプレーンテキストデータを送信してはいけません。A と B 地点の間で送信されるすべてのデータを簡単に暗号化できる技術的能力が存在します。暗号化を使用して、保存時および転送時のすべてのデータを保護します。

  • 独自の暗号プロトコルを作成してはいけません。暗号プロトコルの作成は難しい課題です。NIST が AES を作成した時、世界中の優秀な暗号技術者が提案を提出し、他の提案の欠陥を探す公開コンペを行いました。開発者サイクルを使用して新しい暗号プロトコルを作成するのではなく、既存の実践テスト済みの標準を使用してください。機能や製品を改善することにイノベーションを集中しましょう。

  • 暗号ルーチンを実装してはいけません。暗号ルーチンを実装する既存のライブラリを使用します。

保存時のデータを保護する

機密データ管理の第一のルールは、可能な限り機密データを保存しないことです。機密データを保存しなければならない場合は、不正な開示や改変を避けるために、何らかの方法で暗号化保護されていることを確認してください。

暗号技術 (または暗号化) は情報セキュリティのより高度なトピックのの一つであり、その理解には最も多くの学識と経験が必要です。暗号化には多くのアプローチがあり、それぞれに長所と短所があり、ウェブソリューションアーキテクトと開発者がそれを十分に理解する必要があるため、正しく理解するのは困難です。さらに、本格的な暗号技術の研究は、一般的に高度な数学と数論に基づいており、参入への大きな障壁となっています。

暗号アルゴリズムの設計や構築は非常にエラーを起こしやすいものです (サイドチャネル攻撃を参照) 。暗号機能をゼロから構築するのではなく、Google Tink プロジェクト、Libsodium、多くのソフトウェアフレームワークやクラウドサービスに組み込まれている安全なストレージ機能など、ピアレビュー済みのオープンなソリューションを使用することを強くお勧めします。

パスワードを安全に保存する

ほとんどのウェブアプリケーションは認証サービスをセットアップするためにユーザーのパスワードを保存するという課題に直面します。パスワードを安全に保存して、攻撃者がパスワードをすぐに入手できないようにします。 パスワードをデータベースのどこにもプレーンテキストで保存してはいけません。パスワードを保存するには常にハッシュ関数を使用します。各アイテムにランダムソルトを追加してハッシュ関数を強化し、ハッシュのランダム性を高めます。

特殊なケース: アプリケーションシークレット管理

アプリケーションはセキュリティ運用に必要な多数の「シークレット」を持っています。これらには、証明書、SQL 接続パスワード、サードパーティのサービスアカウントクレデンシャル、パスワード、SSH キー、暗号鍵などがあります。これらのシークレットの不正な開示や変更はシステムの完全な侵害につながるかもしれません。アプリケーションシークレットを管理するには、以下を考慮します。 シークレットをコードや設定ファイルに保存したり、環境変数を介して渡したりしてはいけません。GitRob や TruffleHog などのツールを使用して、コードリポジトリをスキャンしてシークレットを探します。たとえコードが公開されたとしても、たとえば github リポジトリの設定に不備があるとしても、実行中のアプリケーションが依然として安全であるようにコードを記述すべきです。 キーや他のアプリケーションレベルのシークレットは、安全なストレージを提供する KeyWhiz や Hashicorp の Vault プロジェクト、Amazon KMS、AWS Secrets Manager などのシークレットボールトに保管し、実行時にアプリケーションレベルのシークレットにアクセスできるようにします。Ruby on Rails などの多くのウェブフレームワークではシークレットとクレデンシャルを統合的に扱う方法を提供しています。

鍵のライフサイクル

秘密鍵は多くの機密性の高い機能を備えたアプリケーションで使用します。たとえば、秘密鍵は、JWT を署名したり、クレジットカードを保護したり、さまざまな形式の認証を提供したり、その他の機密性の高いセキュリティ機能を促進するために使用できます。鍵を管理するには、以下のようにいくつかのルールに従うべきです。

  • すべての秘密鍵が認可されていないアクセスから保護されていることを確保します

  • 秘密鍵へのすべての認可されていないアクセスはフォレンジック目的のためにログ記録します

  • 下記のように適切なシークレットボールトに鍵を保管します

  • 複数の鍵が必要な場合は独立した鍵を使用します

  • 暗号アルゴリズムの変更に対するサポートを構築して、将来必要とされる変更に備えます

  • 鍵のローテーションを適切にサポートおよび処理するアプリケーション機能を構築します。これは定期的に、あるいは鍵が侵害された後に実行できます。

転送時のデータを保護する

パスワード、クレジットカード番号、医療記録、個人情報、企業秘密などの機密データは、特にそのデータはプライバシー法 (EU の一般データ保護規則 GDPR)、PCI データセキュリティ標準 (PCI DSS) などの金融データ保護規則、その他の規制に該当する場合、特別な保護が必要です。 攻撃者はさまざまな方法でウェブアプリケーションやウェブサービスアプリケーションからデータを窃取できます。たとえば、機密情報が通信セキュリティなしでインターネット経由で送信されると、共有されたワイヤレス上の攻撃者が他のユーザーのデータを捕捉して窃取するかもしれません。また、攻撃者は SQL インジェクションを使用して、アプリケーションデータベースからパスワードや他のクレデンシャルを窃取し、その情報を一般に公開するかもしれません。

現行の暗号プロトコルを使用する

ウェブアプリケーションを開発する際には、通常、転送時の暗号化には トランスポート層セキュリティ (TLS) を使用します。TLSv1.2 または TLSv1.3 を使用します。できれば TLSv1.3 が望ましい。可能であれば、セキュリティ TLS バージョンやアルゴリズムの使用を保証する HTTP/2 や HTTP/3 の使用を調査してください。

  • 他の古いプロトコルを直接無効にして、プロトコルダウングレード攻撃を防ぎます。

  • HTTP を提供してはいけません。HTTP と SSL 圧縮の両方を無効にします。

  • 常に安全な乱数生成器 (RNG) を使用します。

クライアントにトランスポートレベルの暗号化を実施するように指示する

ウェブサーバーはウェブブラウザに最小限のトランスポートレベルのセキュリティを維持するように指示できます。

  • Strict-Transport-Security ヘッダを使用して、便宜主義的に暗号化と証明書バリデーションチェックを適用します。

  • Content-Security-Policy はクライアントサイドで HTTP から HTTPS に自動アップグレードできます。

  • Cookie を設定する際には、常に "secure" フラグを利用して、HTTP での送信を防ぎます。

暗号の俊敏性をサポートする: 暗号技術は時間とともに変化する

暗号技術の推奨は時間とともに変化します。これを可能にするには、使用するアルゴリズムや鍵サイズなどの暗号の選択を設定可能にします。これを 暗号の俊敏性 と呼びます。

アプリケーションが高い可用性をサポートする必要がある場合、鍵のロールオーバー手順を設計します。

防止される脆弱性

参考情報

ツール

PreviousC1: アクセス制御を実装する (Implement Access Control)NextC3: 信頼できないデータを検証、エスケープ、サニタイズ、パラメータ化する (Validate, Escape, Sanitize or Parameterize Untrusted Data)

Last updated