セキュリティとプライバシーは、セキュリティで保護されたソフトウェアを開発するときに後から考えるべきではありません。 開発チームが製品のライフサイクルのすべての時点でセキュリティとプライバシーを考慮するように、正式なプロセスを実施する必要があります。 Microsoft のセキュリティ開発ライフサイクル (SDL) は、包括的なセキュリティ要件、テクノロジ固有のツール、必須プロセスを、すべてのソフトウェア製品の開発と運用に組み込みます。 Microsoft のすべての開発チームは、SDL のプロセスと要件に従う必要があります。 この準拠により、ソフトウェアの安全性が向上し、脆弱性が少なくなり、開発コストが削減されます。
Microsoft SDL は、5 つのコア フェーズと 2 つのサポート セキュリティ アクティビティを含む 7 つのコンポーネントで構成されます。 5 つのコア フェーズは、要件、設計、実装、検証、リリースです。 これらの各フェーズには、すべてのセキュリティとプライバシーの要件とベスト プラクティスが適切に対処されていることを確認するための必須のチェックと承認が含まれています。 2 つのサポート セキュリティ アクティビティであるトレーニングと対応は、コア フェーズの前後でそれぞれ実施され、それらが適切に実装され、展開後もソフトウェアが安全な状態を維持します。
トレーニング
Microsoft のすべての従業員は、一般的なセキュリティとプライバシー意識のトレーニングと、その役割に関連する特定のトレーニングを完了する必要があります。 新入社員は採用時に初期トレーニングを受け、Microsoft での雇用を通じて毎年のリフレッシュ トレーニングが必要です。
開発者とエンジニアは、セキュリティの基本とセキュリティ開発の最近の傾向に関する情報を保持するために、ロール固有のトレーニングにも参加する必要があります。 フルタイムの従業員、インターン、コンティンデント スタッフ、下請け業者、サード パーティも奨励され、高度なセキュリティとプライバシーのトレーニングを求める機会が提供されます。
要件
Microsoft が開発するすべての製品、サービス、機能は、明確に定義されたセキュリティとプライバシーの要件から始まります。 これらの要件は、セキュリティで保護されたアプリケーションの基盤を形成し、その設計を通知します。 開発チームは、製品が処理するデータの種類、既知の脅威、ベスト プラクティス、規制と業界の要件、以前のインシデントから学んだ教訓などの要因に基づいて、これらの要件を定義します。 定義が完了すると、開発チームは要件を明確に文書化して追跡します。
ソフトウェア開発は継続的なプロセスであり、関連するセキュリティとプライバシーの要件が製品のライフサイクル全体を通じて変化し、機能と脅威の状況の変化を反映することを意味します。
Design
セキュリティ、プライバシー、機能の要件を定義したら、ソフトウェアの設計を開始できます。 設計プロセスの一環として、リスクに応じて潜在的な脅威を特定、分類、評価するのに役立つ脅威モデルを作成します。 ソフトウェアを変更するときに、各製品のライフサイクル全体を通じて脅威モデルを維持および更新します。
脅威モデリング プロセスは、まず、製品のさまざまなコンポーネントと、認証などの主要な機能シナリオで相互に対話する方法を定義することから始まります。 Data Flowダイアグラム (DFD) を作成して、使用される主要なデータ フロー操作、データ型、ポート、プロトコルを視覚的に表します。 DFD を使用して、製品のセキュリティ要件に追加する軽減策の脅威を特定し、優先順位を付けます。
サービス チームは、Microsoft のThreat Modeling Toolを使用して脅威モデルを作成します。これにより、チームは次の作業を行うことができます。
- システムのセキュリティ設計について伝える
- 実証済みの手法を使用して、潜在的なセキュリティの問題のセキュリティ設計を分析する
- セキュリティの問題に対する軽減策の提案と管理
製品をリリースする前に、許容できないリスクの軽減策を含め、すべての脅威モデルで正確性と完全性を確認してください。
実装
実装は、前の 2 つのフェーズで作成した計画に従ってコードを記述する開発者から始まります。 Microsoft は、開発者が設計するソフトウェアのすべてのセキュリティ、プライバシー、および機能要件を効果的に実装するための一連の安全な開発ツールを開発者に提供します。 これらのツールには、コンパイラ、セキュリティで保護された開発環境、組み込みのセキュリティ チェックが含まれます。
検証
記述されたコードをリリースする前に、いくつかのチェックと承認を完了して、コードが SDL に準拠し、設計要件を満たし、コーディング エラーが発生しないようにする必要があります。 手動レビューは、コードを開発したエンジニアではないレビュー担当者によって行われます。 職務の分離は、偶発的または悪意のある害につながるコードが記述およびリリースされるリスクを最小限に抑えるために、この手順で重要な制御です。
また、パイプラインに組み込まれているさまざまな自動チェックを実行して、チェックイン中とビルドのコンパイル時にコードを分析する必要があります。 Microsoft で使用されるセキュリティ チェックは、次のカテゴリに分類されます。
- 静的コード分析: コードに資格情報が存在するなど、潜在的なセキュリティ上の欠陥がないかソース コードを分析します。
- バイナリ分析: バイナリ コード レベルで脆弱性を評価し、コードの運用準備ができているかどうかを確認します。
- 資格情報とシークレット スキャナー: ソース コードと構成ファイルで資格情報とシークレットが公開される可能性のあるインスタンスを識別します。
- 暗号化スキャン: ソース コードとコードの実行における暗号化のベスト プラクティスを検証します。
- ファジー テスト: 形式が正しくないデータと予期しないデータを使用して、API とパーサーを実行して脆弱性をチェックし、エラー処理を検証します。
- 構成検証: セキュリティ標準とベスト プラクティスに照らして運用システムの構成を分析します。
- コンポーネント ガバナンス (CG): オープンソース ソフトウェアの検出とバージョン、脆弱性、法的義務のチェック。
手動レビュー担当者または自動ツールがコードに関する問題を見つけた場合は、提出者に通知します。 提出者は、再びレビューのためにコードを提出する前に、必要な変更を行う必要があります。
さらに、内部プロバイダーと外部プロバイダーの両方が、Microsoft オンライン サービスに対して侵入テストを定期的に実施します。 侵入テストは、他の方法で検出されなかったセキュリティの欠陥を検出するための別の手段を提供します。 Microsoft での侵入テストの詳細については、「Microsoft 365 での攻撃シミュレーション」を参照してください。
リリース
必要なすべてのセキュリティ テストとレビューに合格すると、ビルドはすぐにすべての顧客にリリースされるわけではありません。 リリース プロセスは、安全なデプロイ プロセス (SDP) と呼ばれる大規模で大規模なグループ (リングと呼ばれます) にビルドを体系的かつ段階的にリリースします。 SDP リングは一般に、次のように定義できます。
- リング 0: サービスまたは機能を担当する開発チーム
- Ring 1: すべての Microsoft 従業員
- リング 2: Microsoft 以外のユーザーが、対象のリリース チャネルにorganizationまたは特定のユーザーを構成している
- リング3:サブフェーズでの世界的な標準リリース
ビルドは、以前のリングの安定性について適切にテストされているため、リング 3 を除き、ロード期間が長い適切な日数、これらの各リングに滞在します。
応答
リリース後、すべての Microsoft サービスが広範囲にログに記録され、監視されます。 一元化された独自のほぼリアルタイムの監視システムは、潜在的なセキュリティ インシデントを識別します。 Microsoft でのセキュリティ監視とセキュリティ インシデント管理の詳細については、「 セキュリティ監視の概要 」と「 Microsoft セキュリティ インシデント管理」を参照してください。