Microsoft セキュリティ開発ライフサイクル (SDL)

セキュリティとプライバシーは、セキュリティで保護されたソフトウェアを開発するときに後回しにすべきではありません。製品のライフサイクルのすべての時点で確実に考慮されるように、正式なプロセスを実施する必要があります。 Microsoft のセキュリティ開発ライフサイクル (SDL) は、すべてのソフトウェア製品の開発と運用に、包括的なセキュリティ要件、テクノロジ固有のツール、必須プロセスを組み込んでいます。 Microsoft のすべての開発チームは、SDL のプロセスと要件に準拠する必要があり、その結果、開発コストが削減され、より少ない重大な脆弱性を持つソフトウェアの安全性が向上します。

Microsoft SDL は、5 つのコア フェーズと 2 つのサポートセキュリティ アクティビティを含む 7 つのコンポーネントで構成されています。 5 つのコア フェーズは、要件、設計、実装、検証、およびリリースです。 これらの各フェーズには、すべてのセキュリティとプライバシーの要件とベスト プラクティスが適切に対処されるようにするための必須のチェックと承認が含まれています。 2 つのサポートされているセキュリティ アクティビティ (トレーニングと対応) は、コア フェーズの前後にそれぞれ実施され、それらが適切に実装され、展開後もソフトウェアのセキュリティが維持されます。

トレーニング

すべての Microsoft 従業員は、一般的なセキュリティ認識トレーニングと、その役割に適した特定のトレーニングを完了する必要があります。 最初のセキュリティ意識トレーニングは、採用時に新入社員に提供され、Microsoft での雇用全体を通じて毎年更新されるトレーニングが必要です。

開発者とエンジニアは、セキュリティの基礎とセキュリティ開発の最近の傾向について情報を得るために、ロール固有のトレーニングにも参加する必要があります。 すべての正社員、インターン、コンティンジェント スタッフ、下請け業者、およびサード パーティも奨励され、高度なセキュリティとプライバシーのトレーニングを求める機会が提供されます。

要件

Microsoft が開発するすべての製品、サービス、機能は、明確に定義されたセキュリティとプライバシーの要件から始まります。セキュリティで保護されたアプリケーションの基盤であり、設計を通知します。 開発チームは、製品が処理するデータの種類、既知の脅威、ベスト プラクティス、規制、業界の要件、以前のインシデントから得た教訓などの要因に基づいて、これらの要件を定義します。 定義されると、要件が明確に定義され、文書化され、追跡されます。

ソフトウェア開発は継続的なプロセスであり、関連するセキュリティとプライバシーの要件は、機能と脅威の状況の変化を反映するために、製品のライフサイクル全体で変化することを意味します。

デザイン

セキュリティ、プライバシー、機能の要件が定義されたら、ソフトウェアの設計を開始できます。 設計プロセスの一環として、リスクに応じた潜在的な脅威の特定、分類、および評価に役立つ脅威モデルが作成されます。 脅威モデルは、ソフトウェアに変更が加えられるので、各製品のライフサイクル全体を通じて維持および更新する必要があります。

脅威モデリング プロセスは、製品のさまざまなコンポーネントを定義し、認証などの主要な機能シナリオで相互に対話する方法から始まります。 Data Flow図 (DFD) は、使用される主要なデータ フローの相互作用、データ型、ポート、およびプロトコルを視覚的に表すために作成されます。 DFD は、製品のセキュリティ要件に追加される軽減策の脅威を特定し、優先順位を付けるために使用されます。

開発者は、すべての脅威モデルに対して Microsoft のThreat Modeling Toolを使用する必要があります。これにより、チームは次のことが可能になります。

• システムのセキュリティ設計について伝える
• 実証済みの手法を使用して、潜在的なセキュリティ問題のセキュリティ設計を分析する
• セキュリティの問題に対する軽減策の提案と管理

製品がリリースされる前に、許容できないリスクの軽減策を含め、すべての脅威モデルの正確性と完全性が確認されます。

実装

実装は、開発者が前の 2 つのフェーズで作成した計画に従ってコードを記述することから始まります。 Microsoft は、開発者に、設計するソフトウェアのすべてのセキュリティ、プライバシー、機能要件を効果的に実装するための一連の安全な開発ツールを提供します。 これらのツールには、コンパイラ、セキュリティで保護された開発環境、組み込みのセキュリティ チェックが含まれます。

検証

記述されたコードをリリースする前に、コードが SDL に準拠し、設計要件を満たし、コーディング エラーが発生しないようにするために、いくつかのチェックと承認が必要です。 SDL では、開発したコードの担当者とは別のレビュー担当者が手動レビューを行う必要があります。 職務の分離は、偶発的または悪意のある害につながる可能性のある同じユーザーがコードを記述およびリリースできないようにするために、この手順で重要な制御です。

さまざまな自動チェックも必要であり、チェックイン中とビルドのコンパイル時にコードを分析するためにコミット パイプラインに組み込まれています。 Microsoft で使用されるセキュリティ チェックは、次のカテゴリに分類されます。

• 静的コード分析: コード内に資格情報が存在するなど、潜在的なセキュリティ上の欠陥がないかソース コードを分析します。
• バイナリ分析: バイナリ コード レベルで脆弱性を評価し、コードが運用環境の準備ができているかどうかを確認します。
• 資格情報とシークレット スキャナー: ソース コードと構成ファイルで資格情報とシークレットの公開の可能性があるインスタンスを特定します。
• 暗号化スキャン: ソース コードとコード実行における暗号化のベスト プラクティスを検証します。
• ファジー テスト: 不正な形式と予期しないデータを使用して、API とパーサーを実行して脆弱性を確認し、エラー処理を検証します。
• 構成の検証: 運用システムの構成をセキュリティ標準とベスト プラクティスに照らして分析します。
• コンポーネント ガバナンス (CG): オープンソースソフトウェアの検出とバージョン、脆弱性、法的義務のチェック。

手動の校閲者または自動化されたツールによってコード内の問題が見つかると、提出者に通知が送られ、再確認のために送信する前に必要な変更を加える必要があります。

また、侵入テストは、内部プロバイダーと外部プロバイダーの両方によって Microsoft オンライン サービスで定期的に実施されます。 侵入テストは、他の方法で検出されないセキュリティの欠陥を検出するための別の手段を提供します。 Microsoft での侵入テストの詳細については、「 Microsoft 365 の攻撃シミュレーション」を参照してください。

Release

必要なすべてのセキュリティ テストとレビューに合格した後、ビルドはすぐにすべての顧客にリリースされるわけではありません。 ビルドは、安全なデプロイ プロセス (SDP) と呼ばれる大規模なグループ (リングと呼ばれる) に体系的かつ段階的にリリースされます。 SDP リングは次のように定義されます。

• リング 0: サービスを担当する開発チーム
• リング 1: すべての Microsoft 従業員
• リング 2: 組織または特定のユーザーを対象のリリース チャネルに構成した Microsoft 以外のユーザー
• リング 3: サブフェーズでの世界標準リリース

ビルドは、以前のリングの安定性について適切にテストされているため、リング 3 を除き、ロード期間が長い適切な日数、これらの各リングに残ります。

応答

すべての Microsoft サービスは、リリース後に広範にログに記録および監視され、一元的な独自のほぼリアルタイム監視システムを使用して潜在的なセキュリティ インシデントを特定します。 Microsoft でのセキュリティ監視とセキュリティ インシデント管理の詳細については、「 セキュリティ監視の概要 」と「 Microsoft セキュリティ インシデント管理」を参照してください。