最低限検討すべきデフォルト緩和策 セキュリティ仕様・Webアプリケーション編 のバックアップ(No.1)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- 最低限検討すべきデフォルト緩和策 セキュリティ仕様・Webアプリケーション編 へ行く。
- 1 (2020-07-16 (木) 10:11:26)
- 2 (2020-07-16 (木) 10:34:00)
- 3 (2020-08-30 (日) 14:45:49)
情報システム開発契約のセキュリティ仕様作成のためのガイドライン（案）?
暗号化 †
アプリケーションは、暗号で保護されたパスワードのみを送信すること。 †
パスワードを送信するときにパスワードを暗号化するようにアプリケーションを構成する。
アプリケーションは、送信される情報の機密性と整合性を保護すること。 †
データ保護要件に従ってTLS暗号化を要求するように、すべてのアプリケーションシステムを構成する。
脆弱性管理 †
アプリケーションは、オーバーフロー攻撃に対して脆弱であってはいけない。 †
自動境界チェックを実行する言語またはコンパイラを使用するようにアプリケーションを設計する。 抽象化ライブラリを使用して、危険なAPIを抽象化する。 StackGuard、ProPolice、Microsoft Visual Studio / GSフラグなどのコンパイラベースのカナリアメカニズムを使用する。 OSレベルの保護機能を使用し、ユーザー入力の検証を制御する。 ベンダー製品でオーバーフローが特定された場合、アプリケーションにパッチを適用する。
システムの初期化が失敗した場合、シャットダウンが失敗した場合、またはアプリケーション中止処理が失敗した場合、アプリケーションは安全な状態に失敗させる。 †
初期化、シャットダウン、中止などで、アプリケーションが安全でない状態があった場合、その脆弱性を修正する。
アプリケーションは、入力処理の脆弱性の影響を受けない。 †
ユーザー入力を受け入れるときはベストプラクティスに従い、アプリケーションが入力を処理する前にすべての入力が検証されることを確認する。特定された脆弱性を修正し、すぐに修正できない問題について文書化されたリスク許容度を取得する。
すべての製品は、ベンダーまたは開発チームによってサポートされること。 †
アプリケーション内のサポートされていないすべてのソフトウェア製品を削除または使用停止にする。
メンテナンスまたはサポートが利用できなくなったら、アプリケーションを廃止する。 †
アプリケーションのメンテナンスが継続されていることを確認する。
アプリケーションは、XML指向の攻撃に対して脆弱であってはならない。 †
XML攻撃に対して脆弱ではないコンポーネントを利用するようにアプリケーションを設計する。 脆弱性が発見されたら、アプリケーションコンポーネントにパッチを適用する。
アプリケーションは、SQLインジェクションに対して脆弱であってはならない。 †
アプリケーションを変更し、SQLインジェクションの脆弱性を削除する。
アプリケーションは、コマンドインジェクションから保護する。 †
特殊文字入力をエスケープ/サニタイズするようにアプリケーションを変更するか、アプリケーションアーキテクチャに基づいてコマンドインジェクション攻撃から保護するようにシステムを構成する。
アプリケーションは、クロスサイトスクリプティング（XSS）脆弱性から保護する。 †
ユーザー入力が検証されていることを確認し、ユーザー入力をエンコードまたはエスケープして、埋め込みスクリプトコードが実行されないようにする。 独自のエスケープロジックを構築するのではなく、Webテンプレートシステムまたは自動エスケープ機能を提供するWebアプリケーション開発フレームワークを使用して、アプリケーションを開発する。
セッション管理 †
アプリケーションは、ログオフ時またはブラウザーのクローズ時にセッションID値やCookieを破棄する。 †
アプリケーションセッションが終了したら、セッションID Cookieを破棄するようにアプリケーションを構成する。
アプリケーションはセッションIDを公開しない。 †
セッションIDを傍受または改ざんから保護するようにTLS、VPN等でアプリケーションを構成する。
アプリケーションは、非表示フィールドに機密情報を保存しない。 †
非表示フィールドに機密情報を保存しないようにアプリケーションを設計および構成する。ユーザーセッション管理にサーバー側セッション管理技術を使用する。
属性管理 †
アプリケーションには、必要に応じて機密属性を表示する機能が必要。 †
アプリケーションは、データの機密属性（個人情報、機微情報等）を、画面や印刷物に適切に表示する。
認証**認可 †
アプリケーションは、ユーザーによる15分間の無効なログオン試行を3回連続して制限する。 †
15分間に3回ログオンに失敗すると、アカウントロックを強制するようにアプリケーションを構成する。
アプリケーションに埋め込み認証データを含めることはできない。 †
コード、構成ファイル、スクリプト、HTMLファイル、またはASCIIファイルに認証データを埋め込まない。
SAMLアサーションでSubjectConfirmation要素を使用する場合、アプリケーションはNotOnOrAfter条件を使用する。 †
SAMLアサーションで<SubjectConfirmation>要素を使用するときに、<NotOnOrAfter>条件を使用するようにアプリケーションを設計および構成する。
WS-SecurityまたはSAMLアサーションを使用して、すべてのアプリケーションメッセージで有効期間を検証する。 †
すべてのWS-SecurityトークンプロファイルおよびSAMLアサーションで有効期間が検証されるようにする。
SAMLアサーションでConditionsエレメントを使用する場合、アプリケーションはNotBeforeエレメントとNotOnOrAfterエレメントの両方、またはOneTimeUseエレメントを使用する。 †
SAMLアサーションで<Conditions>要素を使用するときに、<NotBefore>および<NotOnOrAfter>または<OneTimeUse>の使用を実装するようにアプリケーションを設計および構成する。
WS-Securityで保護されたメッセージは、作成および有効期限付きのタイムスタンプを使用する。 †
WS-Securityメッセージを使用してアプリケーションを設計および構成し、作成および有効期限のタイムスタンプとシーケンス番号を使用する。
アプリケーションは、PKIベースの認証を使用する場合、対応する秘密キーへの承認されたアクセスを強制する。 †
アプリケーションまたは関連するアクセス制御メカニズムを構成して、アプリケーション秘密鍵への許可されたアクセスを強制する。
アプリケーションは、パスワード/ PINをクリアテキストとして表示しない。 †
入力時にパスワードとPINが難読化され、読み取れないようにアプリケーションを構成する。 難読化されたパスワードをコピーしてクリアテキストとして貼り付けることができないように、アプリケーションを設計する。
アプリケーションは、PKIベースの認証を利用する場合、受け入れられたトラストアンカーへの証明書パス（ステータス情報を含む）を構築することにより証明書を検証する。 †
PKIベースの認証を使用する場合、受け入れられたトラストアンカーへの証明書パスを構築するようにアプリケーションを設計する。
アプリケーションは、15文字以上のパスワード長を強制する。 †
パスワードに15文字を要求するようにアプリケーションを構成する。
アプリケーションは、過度のアカウント権限なしで実行する。 †
最小限の特権でアプリケーションアカウントを構成する。アプリケーションが管理者資格情報で動作することを許可しない。
デフォルトのパスワードを変更する。 †
可能な場合、パスワードの代わりに強力な認証システムを使用するようにアプリケーションを構成する。そうでない場合は、デフォルトのパスワードを承認済みの強度のパスワードに変更し、パスワードに関するすべてのガイダンスに従う。
アプリケーションは、アクセス制御ポリシーに従って、情報およびシステムリソースへの論理アクセスに対して承認を実施する。 †
アプリケーションリソースへのアクセス承認を強制する。
アプリケーションは、組織ユーザー（または組織ユーザーに代わって動作するプロセス）を一意に識別して認証する。 †
ユーザーおよびユーザープロセスを一意に識別および認証するようにアプリケーションを構成する。
アプリケーションは、パスワードの暗号表現のみを保存する。 †
パスワードハッシュ値を作成するときは、強力な暗号化ハッシュ関数を使用する。 パスワードハッシュの作成時にランダムなソルト値を使用する。 認証データを含むデータファイルの強力なアクセス制御許可を確認する。
ネットワーク構成 †
アプリケーションWebサーバーは、DMZで動作する階層型アプリケーションである場合、アプリケーションサーバーおよびデータベースサーバーとは別のネットワークセグメントに存在する必要がある。 †
他のアプリケーション層からWebサーバーを分離し、DMZデータアクセス制御要件に従って、アプリケーションサーバーおよびデータベースサーバーとは別のネットワークセグメントに配置する。