Microsoft セキュリティ開発ライフサイクル (SDL)
セキュリティとプライバシーは、セキュリティで保護されたソフトウェアを開発するときに後から考えるべきではありません。製品のライフサイクルのすべての時点で考慮されるように、正式なプロセスを実施する必要があります。 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 セキュリティ インシデント管理に関するページを参照してください。