V16: セキュリティログ記録とエラー処理
管理目標
セキュリティログは、エラーログやパフォーマンスログとは異なり、認証の判定、アクセス制御の判定、入力バリデーションやビジネスロジックバリデーションなどのセキュリティコントロールのバイパスの試行など、セキュリティ関連イベントを記録するために使用されます。その目的は、SIEM などの分析ツールに高信号の構造化されたデータを提供することで、検知、対応、調査を支援することです。
法的に要求されない限り、ログは機密性の高い個人データを含むべきではなく、ログ記録されたデータは高価値資産として保護する必要があります。ログ記録はプライバシーやシステムのセキュリティを侵害してはいけません。また、アプリケーションは安全に失敗し、不必要な開示や中断を避ける必要もあります。
詳細な実装ガイダンスについては、参考情報セクションの OWASP Cheat Sheet を参照してください。
V16.1 セキュリティログ記録ドキュメント
このセクションではアプリケーションスタック全体にわたるログ記録の明確で完全なインベントリを確保します。これは、効果的なセキュリティ監視、インシデント対応、コンプライアンスに不可欠です。
16.1.1
アプリケーションのテクノロジスタックの各レイヤで実行されるログ記録、ログ記録されるイベント、ログ形式、ログ記録の保存場所、ログ記録の使用方法、ログ記録へのアクセスコントロール方法、ログの保存期間を文書化したインベントリが存在している。
2
V16.2 一般的なログ記録
このセクションでは、セキュリティログが一貫して構造化され、期待されるメタデータを含むことを確保するための要件を提供します。その目標は、分散したシステムやツール間でログを機械可読かつ分析可能にすることです。
当然のことながら、セキュリティイベントには機密データを含むことがよくあります。そのようなデータが考慮なしにログ記録されると、ログ自体が機密扱いとなり、暗号要件、より厳密な保有ポリシー、監査時の開示の可能性の対象となります。
したがって、必要なものだけをログ記録して、ログデータを他の機密資産と同じように慎重に扱うことが重要です。
以下の要件は、ログ記録のメタデータ、同期、フォーマット、コントロールに関する基本的な要件を確立します。
16.2.1
各ログエントリにはイベント発生時のタイムラインを詳細に調査するために必要なメタデータ (いつ、どこで、誰が、何を、など) を含んでいる。
2
16.2.2
すべてのログ記録コンポーネントのタイムソースが同期され、セキュリティイベントメタデータのタイムスタンプは UTC を使用するか、明示的なタイムゾーンオフセットを含む。分散システム間の一貫性を確保し、夏時間への移行時の混乱を防ぐため、UTC が推奨される。
2
16.2.3
アプリケーションはログインベントリに文書化されているファイルおよびサービスのログだけを保存またはブロードキャストしている。
2
16.2.4
ログは使用しているログプロセッサによって、できれば共通のログ形式を使用して、読み取りおよび関連付けできる。
2
16.2.5
機密データをログ記録する際、アプリケーションはデータの保護レベルに基づいてログ記録を実施している。たとえば、クレデンシャルや支払詳細など、特定のデータをログ記録することは許可できないことがある。セッショントークンなどのその他のデータは、ハッシュ化または、全体または一部がマスクすることによってのみログ記録できる。
2
V16.3 セキュリティイベント
このセクションでは、アプリケーション内のセキュリティ関連イベントをログ記録するための要件を定義します。これらのイベントを捕捉することは、不審な動作の検出、調査のサポート、コンプライアンス義務の履行に不可欠です。
このセクションはログ記録する必要があるイベントの種類を概説しますが、網羅的な詳細を提供するものではありません。各アプリケーションには固有のリスク要因と運用上のコンテキストがあります。
ASVS にはセキュリティイベントのログ記録をスコープに含みますが、アラートと相関 (SIEM ルールや監視インフラストラクチャなど) はスコープ外とみなされ、運用システムと監視システムによって処理されることに注意してください。
16.3.1
すべての認証操作は成功した試行と失敗した試行を含めてログ記録されている。使用された認証の種類や要素などの追加のメタデータも収集する必要がある。
2
16.3.2
失敗した認可の試行をログ記録している。L3 では、これは、機密データへのアクセス時のログ記録 (機密データ自体はログ記録しない) を含む、すべての認可判定のログ記録を含む必要がある。
2
16.3.3
アプリケーションはドキュメントで定義されているセキュリティイベントをログ記録し、入力バリデーション、ビジネスロジック、アンチオートメーションなどのセキュリティ制御をバイパスする試みもログ記録している。
2
16.3.4
アプリケーションは、予期しないエラーや、バックエンド TLS 障害などのセキュリティ制御障害をログ記録している。
2
V16.4 ログ保護
ログはフォレンジックにおける貴重な資料であり、保護する必要があります。ログが簡単に変更または削除できる場合、ログの完全性が失われ、インシデント調査や法的手続きにおいて信頼性を失うことになります。ログは、内部アプリケーションの動作や機密性の高いメタデータを露出する可能性があり、攻撃者にとって魅力的な標的となります。
このセクションでは、ログが不正アクセス、改竄、開示から保護され、安全に分離されたシステムに安全に送信および保存することを確保するための要件を定義します。
16.4.1
ログインジェクションを防ぐためにすべてのログ記録コンポーネントがデータを適切にエンコードしている。
2
16.4.2
ログは不正なアクセスから保護されており、改変できない。
2
16.4.3
分析、検出、警告、エスカレーションのために、ログが論理的に分離されたシステムに安全に送信されている。これはアプリケーションが侵害されたとしても、ログが侵害されないことを保証することを目的としている。
2
V16.5 エラー処理
このセクションでは、機密性の高い内部詳細を開示することなく、アプリケーションが正常かつ安全に失敗することを確保するための要件を定義します。
16.5.1
予期しないエラーやセキュリティ上重要なエラーが発生した際、スタックトレース、クエリ、秘密鍵、トークンなどの機密性の高い内部システムデータを開示しない、一般的なメッセージをコンシューマに返している。
2
16.5.2
外部リソースへのアクセスが失敗した場合でも、たとえば、サーキットブレーカーやグレースフルデグラデーションなどのパターンを使用することで、アプリケーションは安全に動作し続ける。
2
16.5.3
例外が発生した場合など、アプリケーションは適切かつ安全に失敗し、検証ロジックの結果としてのエラーにも関わらずトランザクションを処理するようなフェイルオープン状態を防いでいる。
2
16.5.4
未処理の例外をすべてキャッチする「最終手段」のエラーハンドラが定義されている。これは、ログファイルに記録する必要があるエラー詳細を失わないようにするためであり、エラーがアプリケーションプロセス全体を停止して可用性が失われないようにするためである。
3
注: 特定の言語 (Swift、Go、一般的なデザインプラクティスによって多くの関数型言語を含む) は、例外や最終手段イベントハンドラをサポートしていません。このような場合、アーキテクトと開発者は、パターン、言語、フレームワークに適した方法を使用して、例外イベント、予期しないイベント、セキュリティ関連のイベントをアプリケーションが安全に処理できるようにする必要があります。
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?