Microsoft 365 for enterprise は、サービス内の多層防御、顧客制御、セキュリティ強化、運用のベスト プラクティスを通じて、サービス レベルのセキュリティなど、すべてのセキュリティのベスト プラクティスと手順に従います。 詳細については、 Microsoft セキュリティ センター と Microsoft コンプライアンスに関するページを参照してください。
設計による高い信頼性
Microsoft 365 は、Microsoft セキュリティ開発ライフサイクル (SDL) で説明されている Microsoft 信頼できるコンピューティング セキュリティ開発ライフサイクル (SDL) に準拠して設計および開発されています。 より安全なユニファイド コミュニケーション、コラボレーション、生産性システムを作成する最初の手順は、脅威モデルを設計し、設計どおりに各機能をテストすることでした。 複数のセキュリティ関連強化機能がコーディング過程と実践に組み込まれています。 コードが最終的な製品にチェックインされる前に、ビルド時ツールにより、バッファー オーバーランおよびその他のセキュリティ脅威の可能性を検出します。 未知のセキュリティ上の脅威に対して設計することは不可能です。 完全なセキュリティを保証できるシステムはありません。 ただし、製品開発では最初から安全な設計原則が採用されているため、Microsoft 365 では、アーキテクチャの基本的な部分として業界標準のセキュリティ テクノロジが組み込まれています。
Microsoft 365 用セキュリティ フレームワーク
Microsoft 365 は、ゼロ トラストなどのセキュリティアイデアと最小特権アクセスの原則を支持しています。 このセクションでは、Microsoft 365 のセキュリティ フレームワークを形成する基本的な要素の概要について説明します。
コア要素は次のとおりです。
- Microsoft Entra ID。これは、ユーザー アカウントに対して単一の信頼されたバックエンド リポジトリを提供します。 ユーザー プロファイル情報は、Microsoft Graph のアクションを通じてMicrosoft Entra IDに格納されます。
- 複数のトークンが発行されている可能性があり、ネットワーク トラフィックをトレースするかどうかが表示される場合があります。
- トランスポート層セキュリティ (TLS) は、動作中のチャネルを暗号化します。 認証は、相互 TLS (MTLS) を使用するか、証明書に基づいて、またはMicrosoft Entra IDに基づくサービス間認証を使用して行われます。
- ポイントツーポイントのオーディオ、ビデオ、アプリケーション共有ストリームは暗号化され、Secure Real-Time Transport Protocol (SRTP) を使用して整合性がチェックされます。
- トレースに OAuth トラフィックが表示されます。特に、Teams のタブを切り替えながらトークン交換やアクセス許可のネゴシエートを行う場合 (たとえば、投稿からファイルに移動する場合)。 タブの OAuth フローの例については、 このドキュメントを参照してください。
- Microsoft 365 では、可能な限り業界標準のプロトコルをユーザー認証に使用します。
Microsoft Entra ID
Microsoft Entra IDは、Microsoft 365 および Office 365 のディレクトリ サービスとして機能します。 すべてのユーザーとアプリケーションのディレクトリ情報とポリシーの割り当てが格納されます。
Microsoft 365 での暗号化
Microsoft 365 内では、organizationのコンテンツを保護するために、複数の暗号化レイヤーが使用されています。 Microsoft 365 での暗号化の概要については、「Microsoft 365 での暗号化」を参照してください。
ユーザーとクライアントの認証
信頼されたユーザーとは、資格情報が Microsoft 365 またはOffice 365のMicrosoft Entra IDによって認証されたユーザーです。
認証は、信頼されたサーバーまたはサービスへのユーザー資格情報のプロビジョニングです。 Microsoft 365 では、ユーザーの状態と場所に応じて、次の認証プロトコルが使用されます。
- 先進認証 (MA) は、クライアントとサーバー間の通信のための OAUTH 2.0 の Microsoft 実装です。 これにより、多要素認証や条件付きアクセスなどのセキュリティ機能が有効になります。 MA を使用するには、オンライン テナントとクライアントの両方が MA に対して有効になっている必要があります。 PC とモバイル全体の Microsoft 365 クライアントと Web クライアントは、すべて MA をサポートします。
注:
Microsoft Entra認証と承認方法の詳細については、この記事の「概要」と「Microsoft Entra IDでの認証の基本」セクションを参照してください。
Microsoft 365 認証は、Microsoft Entra IDと OAuth を通じて実現されます。 認証のプロセスは、次の方法で簡略化できます。
- ユーザー サインイン トークン発行>の次の要求では>、発行されたトークンを使用します。
クライアントからクラウド サービスへの要求は、OAuth を使用してMicrosoft Entra IDによって認証および承認されます。 フェデレーション パートナーによって発行された有効な資格情報を持つユーザーは信頼され、ネイティブ ユーザーと同じプロセスを通過します。 ただし、管理者は、さらに制限を適用できます。
メディア認証の場合、ICE プロトコルと TURN プロトコルでは、IETF TURN RFC の説明に従ってダイジェスト チャレンジも使用されます。
エンドポイントのセキュリティ
Microsoft では、ユーザー向けの Microsoft 365 アプリとサービスを 1 つの一貫性のあるドメインに統合しています。 **cloud.microsoft**
Microsoft クラウド サービスの成長により、占有するドメイン領域が拡大し、何百ものドメインが発生しました。 この断片化は、エンド ユーザーのナビゲーション、管理の簡素化、アプリ間エクスペリエンスの開発の課題です。
*.microsoft*最上位ドメインは Microsoft 専用です。 新しいドメインには、最後に .com や .net などの従来のサフィックスがありません。 この動作は仕様です。
cloud.microsoft は、Microsoft が .microsoft レジストリオペレーターであり、唯一の登録者であるトップレベル ドメインの下に存在します。 このドメインを使用すると、そのドメイン内のアプリと対話するときに、スプーフィングに対するセキュリティ、プライバシー、保護を強化できます。 終了 cloud.microsoft する Web サイトまたはアプリが公式の Microsoft 製品またはサービスであることを信頼できます。
詳細については、「 Microsoft 365 アプリ用の統合 cloud.microsoft ドメイン」を参照してください。
関連記事
セキュリティ チームが自宅での作業をサポートするための上位 12 のタスク
VPN 分割トンネリングを使用してリモート ユーザーの Microsoft 365 またはOffice 365接続を最適化する
Microsoft Vivaでのセキュリティのしくみを理解する