V13: 構成

管理目標

アプリケーションのデフォルト構成はインターネット上での使用に安全である必要があります。

この章では開発、ビルド、デプロイメント時に適用されるものを含む、これを実現するために必要なさまざまな構成に関するガイダンスを提供します。

カバーされるトピックには、データ漏洩の防止、コンポーネント間の通信の安全な管理、シークレットの保護などを含みます。

V13.1 構成ドキュメント

このセクションでは、アプリケーションが内部および外部のサービスと通信する方法についてと、これらのサービスにアクセスできないことによる可用性の損失を防ぐための技法についてのドキュメント要件を提供します。また、シークレットに関するドキュメントも扱います。

#
説明
レベル

13.1.1

アプリケーションのすべての通信が文書化されている。これには、アプリケーションが依存する外部サービスや、アプリケーションが接続する外部ロケーションをエンドユーザが提供できる可能性がある場合を含む必要がある。

2

13.1.2

アプリケーションが使用する各サービスについて、ドキュメントでは同時接続最大数 (接続プールの制限など) と、その制限に達した際のアプリケーションの動作 (フォールバックやリカバリのメカニズムを含む) を定義し、サービス拒否状態を防いでいる。

3

13.1.3

アプリケーションドキュメントでは、使用するすべての外部システムやサービス (データベース、ファイルハンドル、スレッド、HTTP 接続) のリソース管理戦略を定義している。これには、リソース解放手順、タイムアウト設定、障害処理、再試行ロジックが実装されている場合、再試行制限、遅延、バックオフアルゴリズムの指定を含む。同期 HTTP リクエストレスポンス操作では、短いタイムアウトを義務付け、再試行を無効にするか、再試行回数を厳しく制限して、連鎖的な遅延やリソース枯渇を防ぐ必要がある。

3

13.1.4

アプリケーションのドキュメントでは、組織の脅威モデルとビジネス要件に基づいて、アプリケーションのセキュリティにとって重要なシークレットとそれらを入れ替えるスケジュールを定義している。

3

V13.2 バックエンド通信構成

アプリケーションは、API、データベース、その他のコンポーネントを含む複数のサービスとやり取りします。これらはアプリケーションの内部にあるとみなされるかもしれませんが、アプリケーションの標準アクセス制御メカニズムに含まれていないこともあれば、完全に外部にあることもあります。いずれの場合も、これらのコンポーネントと安全にやり取りするようにアプリケーションを構成し、必要に応じて、その構成を保護する必要があります。

注: 「安全な通信」の章では転送時の暗号化に関するガイダンスを提供しています。

#
説明
レベル

13.2.1

API、ミドルウェア、データレイヤなど、アプリケーションの標準ユーザセッションメカニズムをサポートしていないバックエンドアプリケーションコンポーネント間の通信は認証されている。認証は、パスワード、API キー、特権アクセスを備えた共有アカウントなどの不変のクレデンシャルではなく、個別のサービスアカウント、短期トークン、証明書ベースの認証を使用する必要がある。

2

13.2.2

ローカルまたはオペレーティングシステムのサービス、API、ミドルウェア、データレイヤなどのバックエンドアプリケーションコンポーネント間の通信は最小限の権限が割り当てられたアカウントで実行されている。

2

13.2.3

サービス認証にクレデンシャルを使用する必要がある場合、コンシューマが使用するデフォルトクレデンシャル (root/root や admin/admin など) ではない。

2

13.2.4

許可リストを使用して、アプリケーションが通信 (アウトバウンドリクエスト、データロード、ファイルアクセスなど) を許可される外部のリソースやシステムを定義している。この許可リストは、アプリケーション層、Web サーバ、ファイアウォール、または複数の層の組み合わせで実装できる。

2

13.2.5

Web サーバまたはアプリケーションサーバはサーバがリクエストを送信したり、データやファイルをロードできるリソースやシステムの許可リストで構成されている。

2

13.2.6

アプリケーションが個別のサービスに接続する場合、最大並列接続数、最大許容接続数に達した際の動作、接続タイムアウト、再試行戦略など、各接続について文書化された構成に従っている。

3

V13.3 シークレット管理

シークレット管理は、アプリケーションで使用されるデータの保護を確保するために不可欠な構成タスクです。暗号に関する具体的な要件は「暗号化」の章にありますが、このセクションではシークレットの管理と取り扱いの側面に焦点を当てています。

#
説明
レベル

13.3.1

key vault などのシークレット管理ソリューションは、バックエンドシークレットを安全に作成、保管、アクセス制御、破棄するために使用している。これには、パスワード、鍵マテリアル、データベースやサードパーティシステムとの統合、時間ベースのトークンのための鍵やシード、その他の内部セキュリティ、API キーなどを含む。シークレットはアプリケーションのソースコードやビルド成果物に含めてはいけない。L3 アプリケーションでは、これには HSM などのハードウェア支援のソリューションを含む必要がある。

2

13.3.2

シークレット資産へのアクセスは最小権限の原則に従っている。

2

13.3.3

すべての暗号操作は、隔離されたセキュリティモジュール (vault やハードウェアセキュリティモジュールなど) を使用して実行され、鍵マテリアルがセキュリティモジュールの外部へ漏れないように安全に管理および保護している。

3

13.3.4

シークレットはアプリケーションのドキュメントに基づいて有効期限が切れて入れ替えるように構成されている。

3

V13.4 意図しない情報漏洩

不要なデータの開示を避けるために、本番用の構成を堅牢化する必要があります。これらの問題の多くは重大なリスクとして評価されることはほとんどありませんが、他の脆弱性と連鎖することがよくあります。これらの問題がデフォルトで存在しない場合、アプリケーションを攻撃するハードルが上がります。

たとえば、サーバサイドコンポーネントのバージョンを非表示にしても、すべてのコンポーネントにパッチを適用する必要性がなくなるわけではありませんし、フォルダの一覧表示を無効にしても、認可コントロールを使用したり、パブリックフォルダからファイルを遠ざける必要性がなくなるわけではありませんが、ハードルが上がります。

#
説明
レベル

13.4.1

アプリケーションは .git や .svn フォルダなどのソース管理メタデータなしでデプロイされるか、またはこれらのフォルダが外部からもアプリケーション自体からもアクセスできない方法でデプロイされる。

1

13.4.2

デバッグ機能の露出や情報漏洩を防ぐため、本番環境ではすべてのコンポーネントでデバッグモードが無効になっている。

2

13.4.3

Web サーバは、明示的に意図されていない限り、ディレクトリリストをクライアントに公開していない。

2

13.4.4

潜在的な情報漏洩を避けるため、本番環境では HTTP TRACE メソッドの使用はサポートされない。

2

13.4.5

ドキュメント (内部 API など) および監視エンドポイントは明示的に意図されない限り公開していない。

2

13.4.6

アプリケーションはバックエンドコンポーネントの詳細なバージョン情報を公開していない。

3

13.4.7

意図しない情報、構成、ソースコードの漏洩を防ぐために、Web 層が特定のファイル拡張子を持つファイルのみを処理するように構成されている。

3

参考情報

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

Last updated

Was this helpful?