セキュリティログはエラー処理やパフォーマンスではなく、セキュリティ上重要なイベントが発生した時の記録に重点を置いた特定のタイプのログ記録です。
セキュリティログ記録の主な目的はユーザ、管理者、インシデント対応チームに有用な情報を提供することであり、廃棄されるノイズよりも多くのシグナルが含まれます。セキュリティ関連のイベントをログ記録する場合には、そのログに目的があり、SIEM や分析ソフトウェアによって区別できることを確認してください。
セキュリティログには機密データを含むことがよくあり、現地のデータプライバシー法や指令に従って保護しなければなりません。また、このような機密データは攻撃者にとってそれ自体がターゲットとして非常に魅力的であるため、慎重に保護する必要があります。
これとは別に、アプリケーションが安全に失敗し、エラーが不必要な情報を開示したり、アプリケーションの動作を停止することがないように確保することも重要です。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 1.7.1 | [7.1.7 へ移動] | ||||
| 1.7.2 | [7.3.5 へ移動] | ||||
| 1.7.3 | [追加] アプリケーションのテクノロジスタックの各レイヤで実行されるログ記録、ログ記録されるイベント、ログ形式、ログ記録の保存場所、ログ記録の使用方法、ログ記録へのアクセスコントロール方法、ログの保存期間を文書化したインベントリが存在している。 | ✓ | ✓ | 778 |
機密情報をログに記録するのは危険です。ログそのものが機密情報に分類されるため、暗号化する必要が生じ、保存ポリシーの対象となり、セキュリティ監査で開示する必要があります。必要な情報のみをログに保存し、支払い、クレデンシャル（セッショントークンを含む）、機密情報または個人を特定できる情報は絶対に含めないでください。
ログエントリに含める必要がある具体的な情報については、OWASP Logging Cheat Sheet などの外部の詳細なガイダンスを参照してください。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.1.1 | [修正, 7.1.2 からマージ] 機密データをログに記録する際、アプリケーションはデータの保護レベルを考慮している。たとえば、クレデンシャルや支払詳細のような特定のデータをログ記録することは許可できないことがある。セッショントークンなどのその他のデータは、ハッシュ化または、全体または一部がマスクされた状態でのみログ記録できる。 | ✓ | ✓ | ✓ | 532 |
| 7.1.2 | [削除, 7.1.1 へマージ] | ||||
| 7.1.3 | [7.2.3 へ移動] | ||||
| 7.1.4 | [修正] 各ログのエントリには、イベント発生時のタイムラインを詳細に調査するために必要なメタデータが含まれている。 | ✓ | ✓ | 778 | |
| 7.1.5 | [7.3.4 から移動] 時刻源が正しい時間と正しいタイムゾーンに同期されている。システムがグローバルである場合は、インシデント後のフォレンジック分析を支援するために UTC でのみログを記録することを強く検討する。 | ✓ | ✓ | ||
| 7.1.6 | [追加] アプリケーションはログインベントリに文書化されているファイルおよびサービスのログだけを保存またはブロードキャストしている。 | ✓ | ✓ | ||
| 7.1.7 | [修正, 1.7.1 から移動] ログは使用しているログプロセッサによって、できれば共通のログ形式を使用して、読み取りおよび関連付けできる。 | ✓ | ✓ |
セキュリティに関連するイベントのログ記録は、アプリケーション内の不審なアクティビティを調査できるようにするための重要なメカニズムです。
このセクションではログ記録するイベントの種類について簡単に説明しますが、意図的に詳細には触れません。具体的な実装の詳細については OWASP Logging Cheat Sheet や OWASP Application Logging Vocabulary Cheat Sheet などの外部の詳細なガイダンスを参照する必要があります
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.2.1 | [修正] すべての認証操作は成功した試行と失敗した試行の両方を含めてログ記録されている。使用された認証の種類や要素などの追加のメタデータも収集する必要がある。 | ✓ | ✓ | 778 | |
| 7.2.2 | [修正] すべてのアクセス制御判定は失敗した試行も含めてログ記録されている。 | ✓ | ✓ | 285 | |
| 7.2.3 | [修正, 7.1.3 から移動] アプリケーションは入力バリデーションなどの設計ドキュメントで定義されたセキュリティ制御をバイパスする試みをログ記録している。 | ✓ | ✓ | 778 | |
| 7.2.4 | [修正, 11.1.7 から移動] アプリケーションはビジネスロジックの観点から異常なイベントまたはアクティビティを監視している。 | ✓ | ✓ | 754 | |
| 7.2.5 | [修正, 11.1.8 から移動] アプリケーションは異常なアクティビティや悪意のあるアクティビティが検出されたときにアラートする設定機能がある。 | ✓ | ✓ | 390 | |
| 7.2.6 | [修正, 9.2.5 から移動] アプリケーションはバックエンド TLS 障害などのセキュリティ制御障害をログ記録している。 | ✓ | 778 | ||
| 7.2.7 | [修正, 8.3.5 から移動] 関連するデータ保護要件により必要な場合、機密データへのアクセスをログ記録している (機密データ自体はログ記録していない) 。 | ✓ | ✓ |
簡単に変更や削除が可能なログは、調査や訴追には使えません。ログの公開により、アプリケーションまたはアプリケーションに含まれるデータに関する内部の詳細が明らかになる可能性があります。不正な開示、変更、削除からログを保護する際には注意が必要です。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.3.1 | ログインジェクションを防ぐためにすべてのログ記録コンポーネントがデータを適切にエンコードしている。 | ✓ | ✓ | 117 | |
| 7.3.2 | [削除] | ||||
| 7.3.3 | [修正] ログは不正なアクセスから保護されており、改変できない。 | ✓ | ✓ | 200 | |
| 7.3.4 | [7.1.5 へ移動] | ||||
| 7.3.5 | [1.7.2 から移動] 分析、検出、警告、およびエスカレーションのために、できればリモートシステムにログがセキュアに送信されている。 | ✓ | ✓ |
エラー処理の目的は、機密情報を開示することなく、アプリケーションが適切かつ安全に失敗することを確保することです。アプリケーションはこれが常に行われるように作成する必要があります。
| # | 説明 | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 7.4.1 | 予期しないエラーまたはセキュリティ上重要なエラーが発生したときに、サポート担当者が調査に使用できる一意の ID とともに一般的なメッセージが表示される。 | ✓ | ✓ | ✓ | 210 |
| 7.4.2 | [修正] 一貫性があり標準化された例外処理メカニズム（または機能的に同等なもの）がコードベース全体で使用されている。 | ✓ | ✓ | 544 | |
| 7.4.3 | 未処理の例外をすべて捕捉する「最後の手段」となるエラーハンドラが定義されている。 | ✓ | ✓ | 431 | |
| 7.4.4 | [追加] アプリケーションは、たとえばサーキットブレーカーパターンを使用するなど、外部リソースへのアクセスに失敗してもアプリケーション全体が失敗しないように設計されている。 | ✓ | ✓ | ||
| 7.4.5 | [修正, 4.1.5 から移動, レベル L1 > L2] 例外が発生した場合など、アプリケーションは適切かつ安全に失敗し、検証ロジックの結果としてのエラーにも関わらずトランザクションを処理するようなフェイルオープン状態を防いでいる。 | ✓ | ✓ |
注：Swift や Go のような特定の言語や（および一般的な設計手法を通して）多くの関数型言語は、例外や最終手段イベントハンドラをサポートしていません。このような場合、設計者と開発者は、パターン、言語またはフレームワークで簡単に使える方法を使用して、例外や予期しないイベントまたはセキュリティ関連のイベントをアプリケーションが安全に処理できるようにする必要があります。
詳しくは以下の情報を参照してください。