V14: 構成
管理目標
検証対象のアプリケーションが以下を備えていることを確認します。
セキュアで、再現性があり、自動化されたビルド環境。
古くなったコンポーネントやセキュアでないコンポーネントがアプリケーションに含まれないような、堅牢なサードパーティライブラリ、依存関係、構成管理。
箱から出してすぐのアプリケーションの構成はインターネット上で安全であるべきです。つまり、そのままで安全な構成であるということです。
V14.1 ビルドとデプロイ
ビルドパイプラインはリピート可能なセキュリティの基盤です。セキュアではないものが発見されるたびに、ソースコード、ビルド、またはデプロイメントスクリプトで解決され、自動的にテストされます。既知のセキュリティ問題が本番環境にデプロイされることを防ぐために、ビルドを警告または中断する自動セキュリティおよび依存関係チェックを備えたビルドパイプラインの使用を強くお勧めします。手動で不規則に実行された手順は回避できないセキュリティ上の誤りに直接つながります。
業界が DevSecOps モデルに移行するにつれて、「既知の良好な」状態を達成するために、デプロイメントと構成の継続的な可用性と完全性を確保することが重要です。これまで、システムがハックされた場合、それ以上の侵入が行われていないことを証明するのに数日から数か月かかりました。今日では、ソフトウェア定義のインフラストラクチャ、ダウンタイムゼロでの迅速な A/B デプロイメント、自動コンテナ化ビルドの出現により、危殆化されたシステムに代わる「既知の良好な」代替品を自動的かつ継続的に構築、堅牢化、デプロイできます。
従来のモデルがまだ存在している場合は、手動で手順を実行してその構成を堅牢化およびバックアップし、危殆化されたシステムをタイムリーに完全性が高く危殆化されていないシステムに迅速に置き換えることができる必要があります。
このセクションに準拠するには自動ビルドシステムと、ビルドおよびデプロイメントスクリプトへのアクセスが必要です。
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 順守はより正確なビルド時の静的コード解析や依存関係解析よりも、クライアント側および他のライブラリやコンポーネントの監視や検出に関連します。これらのより正確なテクニックは、必要に応じてインタビューにより発見可能です。
14.2.1
✓
✓
✓
1026
14.2.2
すべての不要な機能、ドキュメント、サンプルアプリケーション、構成が削除されている。
✓
✓
✓
1002
14.2.3
JavaScript ライブラリ、CSS 、Web フォントなどのアプリケーション資産がコンテンツ配信ネットワーク (Content Delivery Network, CDN) や外部のプロバイダで外部的にホストされている場合には、サブリソース完全性 (Subresource Integrity, SRI) を使用して資産の完全性を確認している。
✓
✓
✓
829
14.2.4
✓
✓
829
14.2.5
✓
✓
14.2.6
✓
✓
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 セキュリティヘッダ
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 リクエストヘッダバリデーション
14.5.1
アプリケーションサーバが、アプリケーションや API によって使用されている HTTP メソッドのみ (pre-flight OPTIONS を含む) を受け入れ、アプリケーションコンテキストに対する無効な要求についてログ出力やアラート発行する。
✓
✓
✓
749
14.5.2
Origin ヘッダは攻撃者によって簡単に変更される可能性があるため、提供された Origin ヘッダが認証またはアクセス制御判定に使用されていない。
✓
✓
✓
346
14.5.3
クロスオリジンリソース共有 (CORS) Access-Control-Allow-Origin ヘッダが信頼できるドメインおよびサブドメインの厳密な許可リストを使用して照合し、"null" オリジンをサポートしていない。
✓
✓
✓
346
14.5.4
信頼できるプロキシまたは SSO デバイスにより追加されたベアラトークンなどの HTTP ヘッダがアプリケーションにより認証されている。
✓
✓
306
参考情報
詳しくは以下の情報を参照してください。
Last updated
Was this helpful?