V1: アーキテクチャ、設計、脅威モデリング

管理目標

セキュリティアーキテクチャは多くの組織で失われた技術となっています。エンタープライズアーキテクトの時代は DevSecOps で過去のものとなりました。アプリケーションセキュリティの分野では、最新のセキュリティアーキテクチャの原則をソフトウェア実務者に再導入しながら、アジャイルセキュリティの原則をキャッチアップし採用する必要があります。アーキテクチャは実装ではなく、潜在的に多くの異なる答えがあり、唯一の「正しい」答えがない問題について考える方法です。多くの場合、開発者がその問題を解決するはるかに優れた方法を知っている可能性がある場合には、セキュリティは柔軟性がなく、開発者が特定の方法でコードを修正することを要求するものとみなされます。アーキテクチャに対して唯一で単純な解決策はありません。そして、そうではないフリをすることはソフトウェアエンジニアリング分野への害となります。

Web アプリケーションの特定の実装はそのライフタイムを通じて継続的に改訂される可能性がありますが、全体的なアーキテクチャはほとんど変更されず、ゆっくりと進化します。セキュリティアーキテクチャも同様です。私たちは今日認証が必要ですし、明日も認証が必要でしょうし、五年後にも必要でしょう。今日、妥当な判断を下して、アーキテクチャに準拠したソリューションを選択して再利用すれば、多くの労力、時間、費用を節約できます。例えば、一昔前には、多要素認証はほとんど実装されていませんでした。

開発者が SAML フェデレーションアイデンティティなどの単一のセキュアなアイデンティティプロバイダモデルに注力した場合、元のアプリケーションのインタフェースを変更することなく、NIST SP 800-63 コンプライアンスなどの新しい要件を組み込むためにそのアイデンティティプロバイダを更新できることでしょう。多くのアプリケーションが同じセキュリティアーキテクチャ、つまり同じコンポーネントを共有している場合、すべてのアプリケーションが同時にこのアップグレードの利を得られます。但し、SAML は常に最適な認証ソリューションとしてあり続けるとは限りません。要件変更に応じて他のソリューションと交換する必要があるかもしれません。このような変更は互いに入り組んでおり、完全な書き直しが必要になるほどコストがかかるか、セキュリティアーキテクチャなしではまったく不可能となります。

本章では、ASVS は妥当なセキュリティアーキテクチャの主要な側面である可用性、機密性、処理の完全性、否認防止、プライバシーをカバーしています。これらの各セキュリティ原則はすべてのアプリケーションに組み込まれ、本質的に備わったものでなければなりません。「シフトレフト」が重要です。セキュアコーディングチェックリスト、メンタリングとトレーニング、コーディングとテスティング、構築、展開、構成、運用で開発者の強化を開始します。そして、すべてのセキュリティ管理策が存在し機能していることを確保するために、フォローアップの独立テストで終了します。かつては業界として私たちが行うすべての作業が最後のステップでしたが、開発者が一日に数十回または数百回コードをプロダクションにプッシュするようになると、それだけでは不十分です。アプリケーションセキュリティの専門家はアジャイル技法に遅れずついていく必要があります。つまり、開発者ツールを採用し、コードを学び、開発者と協力することを意味します。他の全員が異動してから何か月も後にプロジェクトを批判するのではありません。

V1.1 セキュアソフトウェア開発ライフサイクル

#	説明	L1	L2	L3	CWE
1.1.1	[削除, スコープ外]
1.1.2	[削除, スコープ外]
1.1.3	[削除, スコープ外]
1.1.4	アプリケーションのすべての信頼境界線、コンポーネント、および重要なデータフローのドキュメントと正当性がある。		✓	✓	1059
1.1.5	アプリケーションの高レベルアーキテクチャ、および接続されるすべてのリモートサービスの定義とセキュリティ分析がなされている。		✓	✓	1059
1.1.6	重複や欠落がある、非効果的な、もしくはセキュアでない管理策を回避するために、集中管理され、簡潔 (経済的設計) で、徹底調査され、セキュアで、再利用可能なセキュリティ管理策が実装されている。		✓	✓	637
1.1.7	[削除, スコープ外]

V1.2 認証アーキテクチャ

認証システムを設計する際、攻撃者がコールセンターに電話して一般的に知らせている質問に答えることで簡単にアカウントをリセットできる場合、ハードウェア対応の多要素認証の強度は関係なくなります。セキュアな ID 認証を確保するには、すべての認証経路が同等の強度を備えなければなりません。

#	説明	L1	L2	L3	CWE
1.2.1	[1.14.7 へ移動]
1.2.2	[修正] API、ミドルウェア、データ層などのバックエンドアプリケーションコンポーネント間の通信が認証され、個々のユーザアカウントを使用している。		✓	✓	306
1.2.3	[修正] アプリケーションが、セキュアであることが確認されており、強力な認証を含むように拡張でき、アカウントの悪用や違反を検出するための十分なログ記録と監視を備えている、単一の承認済みユーザ認証メカニズムを使用している。		✓	✓	306
1.2.4	[修正, 2.2.11 へ分割] アプリケーションに複数の認証経路がある場合、それらすべてに一貫して適用されるべきセキュリティ制御と認証強度がともに文書化されている。		✓	✓	306
1.2.5	[追加] コンテキスト固有の単語のリストが文書化されており、パスワードでの使用を防いでいる。		✓	✓	521

V1.3 セッション管理アーキテクチャ

これは将来のアーキテクチャ要件のためのプレースホルダです。

V1.4 アクセス制御アーキテクチャ

#	説明	L1	L2	L3	CWE
1.4.1	[削除, 4.1.1 と重複]
1.4.2	[削除]
1.4.3	[削除, 4.1.3 と重複]
1.4.4	保護されたデータおよびリソースにアクセスするために、アプリケーションが単一で十分に吟味されたアクセス制御メカニズムを使用している。コピー＆ペーストやセキュアではない代替パスを回避するために、すべてのリクエストはこの単一のメカニズムを通過する必要がある。		✓	✓	284
1.4.5	[文法] 属性または機能ベースのアクセス制御が使用されていることにより、コードが単に役割ではなく機能やデータ項目に対するユーザの認可を確認している。権限は役割を使用して割り当てる必要がある。		✓	✓	275
1.4.6	[追加] API、ミドルウェア、データ層などのバックエンドアプリケーションコンポーネント間の通信が最小限の権限で実行されている。		✓	✓	272

V1.5 入力および出力アーキテクチャ

4.0 では、ロードされた信頼境界線の用語として「サーバサイド」という用語から離れました。信頼境界線は依然として懸念されています。信頼できないブラウザやクライアントデバイスでの決定はバイパス可能です。しかし、今日の主流のアーキテクチャ展開では、信頼実施ポイントが劇的に変わりました。したがって、ASVS で「信頼できるサービスレイヤ」という用語が使用されている場合、マイクロサービス、サーバレス API、サーバサイド、セキュアブートを備えたクライアントデバイス上の信頼された API、パートナー API や外部 API など、場所に関係なく、信頼された実施ポイントを意味します。

ここでの「信頼できないクライアント」という用語はプレゼンテーション層を提供するクライアントサイドのテクノロジを指し、一般に「フロントエンド」テクノロジと呼ばれます。この文脈での「シリアル化」という用語は値の配列などをネットワーク経由でデータを送信することや JSON 構造体を処理することだけでなく、ロジックを含む可能性のある複雑なオブジェクトの処理も意味します。

#	説明	L1	L2	L3	CWE
1.5.1	[修正, レベル L2 > L1] 入力および出力要件がタイプおよびコンテンツに基づいて、データを対処および処理する方法を明確に定義している。	✓	✓	✓	20
1.5.2	[削除, 5.5.3 へマージ]
1.5.3	[5.6.2 へ移動]
1.5.4	[5.6.3 へ移動]

V1.6 暗号アーキテクチャ

アプリケーションはデータ資産を分類に従って保護するために強力な暗号化アーキテクチャで設計する必要があります。すべてを暗号化することは無駄であり、なにも暗号化しないことは法的に過失となります。通常、アーキテクチャ設計や高レベル設計、デザインスプリントやアーキテクチャスパイクの際に、バランスをとる必要があります。暗号を自ら設計したり追加導入したりすることは、最初から単純に組み込むよりも、セキュアに実装するために必然的により多くのコストがかかります。

アーキテクチャ要件はコードベース全体に内在するため、単体テストや統合テストは困難です。アーキテクチャ要件はコーディングフェーズを通じてコーディング標準を考慮する必要があり、セキュリティアーキテクチャ、ピアレビューやコードレビュー、振り返りの際にレビューする必要があります。

#	説明	L1	L2	L3	CWE
1.6.1	暗号化鍵の管理に明示的なポリシーがあり、暗号化鍵ライフサイクルが NIST SP 800-57 などの鍵管理標準に準拠している。		✓	✓	320
1.6.2	暗号化サービスの利用者が鍵マテリアルおよびその他のシークレットを key vault や API ベースの代替手段を使用して保護している。		✓	✓	320
1.6.3	すべての鍵およびパスワードは置き換え可能であり、機密データを再暗号化するための明確に定義されたプロセスの一部である。		✓	✓	320
1.6.4	[文法] アーキテクチャがクライアントサイドのシークレット (対称鍵、パスワード、API トークンなど) を安全でないものとして扱い、機密データの保護やアクセスにそれらを使用していない。		✓	✓	320

V1.7 エラー、ログ記録および監査アーキテクチャ

#	説明	L1	L2	L3	CWE
1.7.1	[7.1.7 へ移動]
1.7.2	[7.3.5 へ移動]
1.7.3	[追加] アプリケーションのテクノロジスタックの各レイヤで実行されるログ記録、ログ記録されるイベント、ログ形式、ログ記録の保存場所、ログ記録の使用方法、ログ記録へのアクセスコントロール方法、ログの保存期間を文書化したインベントリが存在している。		✓	✓	778

V1.8 データ保護およびプライバシーアーキテクチャ

#	説明	L1	L2	L3	CWE
1.8.1	[修正, 8.3.4 からマージ, レベル L2 > L1] アプリケーションにより作成および処理されるすべての機密データが特定され、保護レベルに分類されている。機密データの取り扱い方法に関するポリシーが整備されている。	✓	✓	✓	213
1.8.2	[修正] すべての保護レベルには関連する一連の保護案件があり、これらがアーキテクチャに適用されている。これには暗号化、完全性検証、リテンション、プライバシー、使用されるプライバシー強化技法に関連する要件、およびその他の機密性要件が含まれている (ただし、これらに限定されない) 。		✓	✓

V1.9 通信アーキテクチャ

#	説明	L1	L2	L3	CWE
1.9.1	[削除, 9.1.1, 9.2.2, 9.3.1 と重複]
1.9.2	[削除, 9.2.3, 9.3.2 と重複]

V1.10 悪意のあるソフトウェアアーキテクチャ

#	説明	L1	L2	L3	CWE
1.10.1	[削除, スコープ外]

V1.11 ビジネスロジックアーキテクチャ

#	説明	L1	L2	L3	CWE
1.11.1	提供するビジネスやセキュリティ機能の観点で、すべてのアプリケーションコンポーネントの定義とドキュメントがある。		✓	✓	1059
1.11.2	[修正] 認証、セッション管理、アクセス制御などのすべてのアプリケーションフローが一貫したアプリケーションとユーザの状態を維持し、競合状態やビジネスロジックの欠陥を防止している。		✓	✓	362
1.11.3	認証、セッション管理、アクセス制御など、価値の高いビジネスロジックフローのすべてがスレッドセーフであり、time-of-check time-of-use 競合状態に耐えられる。			✓	367
1.11.4	[追加] ビジネスロジックの制限とバリデーションに対する期待は、ユーザーごと、およびアプリケーション全体にもわたって明確に文書化されている。		✓	✓

V1.12 セキュアなファイルアップロードアーキテクチャ

#	説明	L1	L2	L3	CWE
1.12.1	[削除, 12.4.1 と重複]
1.12.2	[50.5.2 へ移動]

V1.13 API アーキテクチャ

これは将来のアーキテクチャ要件のためのプレースホルダです。

V1.14 構成アーキテクチャ

#	説明	L1	L2	L3	CWE
1.14.1	[修正] 明確に定義されたセキュリティコントロール、ファイアウォールルール、API ゲートウェイ、リバースプロキシ、クラウドベースのセキュリティグループ、または同様のメカニズムを通じて、異なる信頼レベルのバックエンドコンポーネントを分離している。		✓	✓	923
1.14.2	[削除, スコープ外]
1.14.3	[削除, 14.2.1 と重複]
1.14.4	[削除, スコープ外]
1.14.5	[修正] 特に逆シリアル化などの機密性の高いまたは危険なアクションを実行している場合、攻撃者が他のアプリケーションを攻撃するのを遅延および阻止するために、アプリケーションのデプロイメントが適切にサンドボックス化またはネットワークレベルで分離されている。		✓	✓	265
1.14.6	[50.7.2 へ移動]
1.14.7	[修正, 1.2.1 から移動] すべてのバックエンドアプリケーションコンポーネント、サービス、サーバに対して、一意または特別な低権限のオペレーティングシステムアカウントが使用されている。		✓	✓	250
1.14.8	[追加] アプリケーションはレート制限やログ記録などの機密性の高い機能を提供するためにユーザーの真の IP アドレスを識別および利用している。		✓	✓	348

参考情報

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

• OWASP Threat Modeling Cheat Sheet

• OWASP Attack Surface Analysis Cheat Sheet

• OWASP Threat modeling

• OWASP Software Assurance Maturity Model Project

• Microsoft SDL

• NIST SP 800-57

• More information on security.txt including a link to the RFC