Skip to content

Latest commit

 

History

History
84 lines (60 loc) · 12.1 KB

0x22-V14-Config.md

File metadata and controls

84 lines (60 loc) · 12.1 KB

V14 構成

管理目標

検証対象のアプリケーションが以下を備えていることを確認します。

  • 安全で、再現性があり、自動化可能なビルド環境
  • サードパーティのライブラリ、依存関係、構成管理を強化し、アプリケーションに古いコンポーネントや安全でないコンポーネントが含まれないようにします

既定のアプリケーションを構成することは、インターネット上で安全である必要があり、安全に構成する必要があります。

V14.1 ビルドとデプロイ

ビルドパイプラインは再現性のあるセキュリティの基盤です。安全でない何かが発見されるたびに、それをソースコード、ビルドまたはデプロイスクリプトで解決し、自動的にテストが可能。既知のセキュリティの問題が本番環境に展開されないようにビルドを警告または中断する自動セキュリティおよび依存関係のチェックを備えたビルドパイプラインの使用を強く勧めます。不規則に実行される手動手順は、回避可能なセキュリティのミスに直結します。

業界として DevSecOps モデルに移行するにつれ、「Known good（既知の良好な）」状態を実現するには、デプロイメントと構成の継続的な可用性と整合性を確保することが重要。以前はシステムがハッキングされた場合に、それ以上の侵害が生じていないことを証明するのに数日から数か月かかりました。今日では、ソフトウェア定義のインフラストラクチャ、ダウンタイム無しでの迅速な A/B デプロイメント、そして自動化コンテナ化されたビルドでは、侵害された「既知の良好な」代替品を自動的かつ継続的にビルド、強化、デプロイすることができます。

もし従来のモデルがまだ存在する場合は、その構成を強化してバックアップするために手動の手順を実行し、侵害されたシステムを整合性の高い妥協のないシステムに迅速に交換できるようにする必要があります。

このセクションに準拠するには、自動ビルドシステムと、ビルドおよびデプロイスクリプトへのアクセスが必要です。

# 説明 L1 L2 L3 CWE
14.1.1 アプリケーションのビルドおよびデプロイプロセスが、CI / CD の自動化、自動構成管理、自動デプロイスクリプトなどの安全で再現性のある方法で実行されている。 ✓ ✓
14.1.2 コンパイラフラグが、スタックのランダム化、データ実行防止などの利用可能なすべてのバッファオーバーフローの保護と警告を有効にし、安全でないポインタ、メモリ、フォーマット文字列、整数、または文字列操作が見つかった場合にビルドを中断するように構成されている。 ✓ ✓ 120
14.1.3 使用しているアプリケーションサーバとフレームワークの推奨事項に従って、サーバ構成が強化されている。 ✓ ✓ 16
14.1.4 アプリケーション、構成、およびすべての依存関係が、自動でデプロイスクリプトを使用して再度デプロイできるか、文書化およびテストされた Runbook から妥当な時間で構築できるか、またはバックアップからタイムリーに復元できる。 ✓ ✓
14.1.5 許可された管理者が、セキュリティ関連のすべての構成の整合性を検証して改ざんを検出できる。 ✓

V14.2 依存関係

依存関係の管理は、あらゆる種類のあらゆるアプリケーションの安全な運用に欠かせません。 古くなった、または安全でない依存関係で最新の状態を維持できないことは、これまでで規模が大きく、とても高くつく攻撃の根本的な原因です。

注：レベル 1 では、14.2.1 の準拠は、より正確なビルド時の静的コード分析または依存関係分析ではなく、クライアント側およびその他のライブラリとコンポーネントの観察または検出に関係します。 これらのより正確な手法は、必要に応じてインタビューによって発見できる場合があります。

# 説明 L1 L2 L3 CWE
14.2.1 すべてのコンポーネントが最新となっている。できればビルド時またはコンパイル時にディペンデンシチェッカを使用する。 (C2) ✓ ✓ ✓ 1026
14.2.2 不要な機能、ドキュメント、サンプルアプリケーション、およびコンフィギュレーションがすべて削除されている。 ✓ ✓ ✓ 1002
14.2.3 JavaScript ライブラリ、CSS、Web フォントなどのアプリケーション資産がコンテンツ配信ネットワーク（Content Delivery Network, CDN）または外部プロバイダで外部的にホストされている場合、資産の整合性を検証するためにサブリソース完全性（SRI）が使用されている。 ✓ ✓ ✓ 829
14.2.4 サードパーティのコンポーネントが、事前に定義され、信頼され、継続的に維持されるリポジトリからのものとなっている。 (C2) ✓ ✓ 829
14.2.5 使用しているすべてのサードパーティライブラリのソフトウェア部品表 (SBOM) が維持されている。 (C2) ✓ ✓
14.2.6 サードパーティのライブラリをサンドボックス化またはカプセル化して、必要な動作だけをアプリケーションに公開することで、攻撃対象領域を最小化する。 (C2) ✓ ✓ 265

V14.3 意図しないセキュリティの開示

本番環境の構成を強化して、デバッグコンソールなどの一般的な攻撃から保護し、クロスサイトスクリプティング（Cross-site Scripting, XSS）とリモートファイルインクルード（Remote File Inclusion, RFI）攻撃の基準を引き上げ、歓迎されない多くのペネトレーションテストの報告の特徴である発見された些細な脆弱性を排除します。これらの問題の多くはめったに重大なリスクとして評価されませんが、他の脆弱性と連鎖します。これらの問題がデフォルトで存在しない場合、ほとんどの攻撃が成功する前にレベルが引き上げられます。

| :---: | :--- | :---: | :---:| :---: | :---: | | 14.3.1 | [削除, 7.4.1 と重複] | | | | | | 14.3.2 | Web またはアプリケーションサーバとアプリケーションフレームワークのデバッグモードが運用環境で無効になっていることを確認して、デバッグ機能、開発者コンソール、および意図しないセキュリティ開示を排除する。 | ✓ | ✓ | ✓ | 497 | | 14.3.3 | HTTP ヘッダまたは HTTP レスポンスの一部がシステムコンポーネントの詳細なバージョン情報を公開していない。 | ✓ | ✓ | ✓ | 200 |

V14.4 HTTP セキュリティヘッダ

# 説明 L1 L2 L3 CWE
14.4.1 すべての HTTP レスポンスに Content-Type ヘッダが含まれている。またコンテンツタイプが text/*, /+xml および application/xml の場合には安全な文字セット (UTF-8, ISO-8859-1 など) を指定する。コンテンツは提供された Content-Type ヘッダと一致する必要がある。 ✓ ✓ ✓ 173
14.4.2 すべての API レスポンスに Content-Disposition:attachment; filename="api.json" ヘッダが含まれている（または他のコンテントタイプの適切なファイル名）。 ✓ ✓ ✓ 116
14.4.3 HTML、DOM、JSON、JavaScript インジェクションの脆弱性などの XSS 攻撃の影響を軽減するのに役立つ Content Security Policy (CSP) レスポンスヘッダが配置されている。 ✓ ✓ ✓ 1021
14.4.4 すべてのレスポンスに X-Content-Type-Options: nosniff ヘッダが含まれている。 ✓ ✓ ✓ 116
14.4.5 Strict-Transport-Security ヘッダがすべてのレスポンスとすべてのサブドメインに含まれている。例えば、Strict-Transport-Security：max-age=15724800; includeSubdomains ✓ ✓ ✓ 523
14.4.6 URL 内の機密情報が Referer ヘッダを介して信頼できない関係者に公開されないように、適切な Referrer-Policy ヘッダが含まれている。 ✓ ✓ ✓ 116
14.4.7 Web アプリケーションのコンテンツはデフォルトでサードパーティのサイトに埋め込むことができない、および適切な Content-Security-Policy: frame-ancestors と X-Frame-Options レスポンスヘッダを使用して必要な場所でのみ正規のリソースの埋め込みが許可されている。 ✓ ✓ ✓ 1021

V14.5 HTTP リクエストヘッダのバリデーション

# 説明 L1 L2 L3 CWE
14.5.1 アプリケーションサーバが、pre-flight OPTIONS を含む、アプリケーションまたは API で使用されている HTTP メソッドのみを受け入れる。アプリケーションコンテキストに対する無効なリクエストについてログ出力やアラート発行する。 ✓ ✓ ✓ 749
14.5.2 提供された Origin ヘッダは、攻撃者によって簡単に変更できるため、認証やアクセス制御の判断に使用されていない。 ✓ ✓ ✓ 346
14.5.3 オリジン間リソース共有（Cross-Origin Resource Sharing, CORS）の Access-Control-Allow-Origin ヘッダが信頼できるドメインの厳密な許可リストを使用して照合し、「null」オリジンをサポートしていない。 ✓ ✓ ✓ 346
14.5.4 信頼できるプロキシまたは bearer トークンのような SSO デバイスによって追加された HTTP ヘッダがアプリケーションによって認証されている。 ✓ ✓ 306

参考情報

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