#author("2020-07-17T11:30:51+09:00","","")
[[セキュアコーディングガイド]]
*管理目標 [#t15c74af]
セキュリティアーキテクチャは多くの組織で失われた芸術となっています。エンタープライズアーキテクトの日々は DevSecOps の時代を通過しています。アプリケーションセキュリティの分野では、最新のセキュリティアーキテクチャの原則をソフトウェア実務者に再導入しながら、アジャイルセキュリティの原則をキャッチアップし採用する必要があります。アーキテクチャは実装ではなく、潜在的に多くの異なる答えを持ち、唯一の「正しい」答えがない問題について考える方法です。多くの場合、開発者がその問題を解決するはるかに優れた方法を知っている可能性がある場合には、セキュリティは柔軟性がなく、開発者が特定の方法でコードを修正することを要求するものとみなされます。アーキテクチャに対して唯一で単純な解決策はありません。そして、そうではないフリをすることはソフトウェアエンジニアリング分野への害となります。
&br;
ウェブアプリケーションの特定の実装はそのライフタイムを通じて継続的に改訂される可能性がありますが、全体的なアーキテクチャはほとんど変更されず、ゆっくりと進化します。セキュリティアーキテクチャも同様です。私たちは今日認証が必要ですし、明日も認証が必要でしょうし、五年後にも必要でしょう。今日、妥当な判断を下して、アーキテクチャに準拠したソリューションを選択して再利用すれば、多くの労力、時間、費用を節約できます。例えば、一昔前には、多要素認証はほとんど実装されていませんでした。
&br;
開発者が SAML フェデレーションアイデンティティなどの単一のセキュアなアイデンティティプロバイダモデルに注力した場合、元のアプリケーションのインタフェースを変更することなく、NIST 800-63 コンプライアンスなどの新しい要件を組み込むためにそのアイデンティティプロバイダを更新できることでしょう。多くのアプリケーションが同じセキュリティアーキテクチャ、つまり同じコンポーネントを共有している場合、すべてのアプリケーションが同時にこのアップグレードの利を得られます。但し、SAML は常に最良ないし最適な認証ソリューションとして残るわけではありません。要件変更に応じて他のソリューションと交換する必要があるかもしれません。このような変更は互いに入り組んでおり、完全な書き直しが必要になるほどコストがかかるか、セキュリティアーキテクチャなしではまったく不可能となります。
&br;
本章では、ASVS は妥当なセキュリティアーキテクチャの主要な側面である可用性、機密性、処理の完全性、否認防止、プライバシーをカバーしています。これらの各セキュリティ原則はすべてのアプリケーションに組み込まれ、本質的に備わったものでなければなりません。「シフトレフト」が重要です。セキュアコーディングチェックリスト、メンタリングとトレーニング、コーディングとテスティング、構築、展開、構成、運用で開発者の強化を開始します。そして、すべてのセキュリティコントロールが存在し機能していることを保証するために、フォローアップの独立テストで終了します。かつては業界として私たちが行うすべての作業が最後のステップでしたが、開発者が一日に数十回または数百回コードをプロダクションにプッシュするようになると、それだけでは不十分です。アプリケーションセキュリティの専門家はアジャイル技法に遅れずついていく必要があります。つまり、開発者ツールを採用し、コードを学び、開発者と協力することを意味します。他の全員が移動してから何か月も後にプロジェクトを批判するのではありません。
&br;
*V1.1安全なソフトウェア開発ライフサイクル要件 [#iefc3a92]
|項番|説明|L1|L2|L3|No|タイトル|STIGs|IPAガイドライン|
|1.1.1|すべての開発ステージにおいてセキュリティに対処するセキュアなソフトウェア開発ライフサイクルの使用を検証します。 (C1)||✓|✓|[[:https://cwe.mitre.org/data/definitions/]]||||
|1.1.2|脅威の特定、対策の計画、適切なリスク対応の促進、セキュリティテスティングのガイドを行うために、すべての設計変更またはスプリント計画ごとに脅威モデリングの使用を検証します。||✓|✓|[[1053:https://cwe.mitre.org/data/definitions/1053]]|デザインのドキュメントがありません||非該当|
|1.1.3|すべてのユーザーストーリーと機能に、「ユーザーとして、自分のプロファイルを閲覧および編集できる必要があります。他のユーザーのプロファイルを閲覧および編集できてはいけません」などの機能的なセキュリティ制約が含まれていることを検証します。||✓|✓|[[1110:https://cwe.mitre.org/data/definitions/1110]]|不完全な設計ドキュメント||非該当|
|1.1.4|アプリケーションのすべての信頼境界線、コンポーネント、重要なデータフローのドキュメントと正当性を検証します。||✓|✓|[[1059:https://cwe.mitre.org/data/definitions/1059]]|不完全なドキュメント||非該当|
|1.1.5|アプリケーションの上位レベルアーキテクチャと接続されているすべてのリモートサービスの定義とセキュリティ分析を検証します。 (C1)||✓|✓|[[1059:https://cwe.mitre.org/data/definitions/1059]]|不完全なドキュメント||非該当|
|1.1.6|重複、欠落、無効、非セキュアなコントロールを回避するために、一元化され、シンプル (経済的な設計) であり、承認され、セキュアであり、再利用可能なセキュリティコントロールの実装を検証します。 (C10)||✓|✓|[[637:https://cwe.mitre.org/data/definitions/637]]|保護メカニズムの不要な複雑さ（「メカニズムの経済」を使用しない）||非該当|
|1.1.7|全ての開発者およびテスト担当者に対するセキュアコーディングチェックリスト、セキュリティ要件、ガイドライン、ポリシーの可用性を検証します。||✓|✓|[[637:https://cwe.mitre.org/data/definitions/637]]|保護メカニズムの不要な複雑さ（「メカニズムの経済」を使用しない）||非該当|
|1.1.8|アプリケーションのルートまたは .well-known ディレクトリにあり、セキュリティ上の問題について所有者に連絡するためのリンクや電子メールのアドレスを明確に定義した、公開されている security.txt ファイルの可用性を検証します。||✓|✓|[[1059:https://cwe.mitre.org/data/definitions/1059]]|不完全なドキュメント|||
