この記事では、Azure のアーキテクチャと管理の一般的な説明について説明します。 Azure システム環境は、次のネットワークで構成されています。
- Microsoft Azure 運用ネットワーク (Azure ネットワーク)
- マイクロソフト社内ネットワーク(corpnet)
これらのネットワークは別々のITチームが運用・維持しています。
Azure アーキテクチャ
Azure は、データセンターのネットワークを通じてアプリケーションとサービスを構築、デプロイ、管理するためのクラウド コンピューティング プラットフォームおよびインフラストラクチャです。 Microsoft は、これらのデータセンターを管理します。 指定したリソースの数に基づいて、Azureはリソースニーズに基づいて仮想マシン(VM)を作成します。 これらのVMは、Microsoftがクラウド用に設計したAzureハイパーバイザー上で動作しており、一般には公開されていません。
各 Azure 物理サーバー ノードには、ハードウェア上で直接実行されるハイパーバイザーがあります。 ハイパーバイザーは、ノードを可変数のゲスト VM に分割します。 各ノードには、ホストオペレーティングシステムを実行するルートVMも1つあります。 Azureは各VMでWindowsファイアウォールを有効にします。 アドレス指定可能なポートを定義するには、サービス定義ファイルを構成します。 これらのポートは、内部または外部で開いてアドレス指定可能なポートのみです。 ハイパーバイザーとルートOSが、ディスクとネットワークへのすべてのトラフィックとアクセスを仲介します。
ホスト レイヤーでは、Azure VM は、最新の Windows Server のカスタマイズおよび強化されたバージョンを実行します。 Azure では、VM をホストするために必要なコンポーネントのみを含む Windows Server のバージョンが使用されます。 この構成はパフォーマンスを向上させ、攻撃面を削減します。 ハイパーバイザーはマシンの境界を強制し、OSのセキュリティに依存しません。
ファブリック コントローラーによる Azure 管理
Azureは物理サーバー(ブレード/ノード)上で動作するVMを約1,000個のクラスタにまとめています。 拡張され冗長化されたプラットフォームソフトウェアコンポーネントであるファブリックコントローラー(FC)がVMを独立して管理しています。
各 FC は、そのクラスターで実行されるアプリケーションのライフサイクルを管理し、その制御下にあるハードウェアの正常性をプロビジョニングおよび監視します。 サーバーが故障したと判断した場合、健康なサーバー上でVMインスタンスを再生するなどの自律操作を実行します。 また、FC は、アプリケーションのデプロイ、更新、スケールアウトなどのアプリケーション管理操作も実行します。
Azureはデータセンターをクラスタに分割します。 クラスタは、障害を FC レベルで分離し、特定のクラスのエラーが、エラーが発生したクラスタ以外のサーバに影響を及ぼさないようにします。 Azureは特定のAzureクラスタにサービスを提供するFCをFCクラスタにまとめます。
ハードウェア インベントリ
FC は、ブートストラップ構成プロセス中に Azure ハードウェアとネットワーク デバイスのインベントリを準備します。 Azure 運用環境に入る新しいハードウェアとネットワーク コンポーネントは、ブートストラップ構成プロセスに従う必要があります。 FCは datacenter.xml 設定ファイルに記載された全在庫を管理します。
FC 管理の OS イメージ
オペレーティングシステムチームは、Azure本番環境のすべてのホストおよびゲストVMに対して仮想ハードディスクイメージを提供しています。 チームは、自動化されたオフライン ビルド プロセスを通じてこれらの基本イメージを構築します。 ベースイメージは、Microsoftがカーネルやその他のコアコンポーネントをAzure環境をサポートするために修正・最適化したオペレーティングシステムのバージョンです。
ファブリック管理型オペレーティングシステムのイメージには3種類存在します:
- ホスト: ホスト VM で実行されるカスタマイズされたオペレーティング システム。
- ネイティブ: テナント (Azure Storage など) で実行されるネイティブ オペレーティング システム。 このオペレーティング システムにはハイパーバイザーがありません。
- ゲスト: ゲスト VM で実行されるゲスト オペレーティング システム。
MicrosoftはホストおよびネイティブのFC管理OSをクラウド上で使用するために設計しており、公開はしていません。
ホストおよびネイティブオペレーティングシステム
ホストおよびネイティブOSは、ファブリックエージェントをホストし、計算ノードおよびストレージノード上で動作するハード化されたオペレーティングシステムイメージです。 ホストおよびネイティブOSの最適化されたベースイメージは、APIや未使用コンポーネントによって露出する表面積を削減します。 これらのAPIやコンポーネントは高いセキュリティリスクを伴い、OSのフットプリントを増加させる可能性があります。 低フットプリントOSはAzureに必要なコンポーネントのみを含みます。
ゲスト オペレーティング システム
ゲストOSのVM上で動作するAzure内部コンポーネントはリモート デスクトップ Protocolを使えません。 ベースライン構成設定の変更は、変更およびリリース管理プロセスを経る必要があります。
Azure データセンター
Microsoft Cloud Infrastructure and Operations (MCIO) チームは、すべての Microsoft オンライン サービスの物理インフラストラクチャとデータセンター施設を管理します。 MCIO は、主にデータセンター内の物理的および環境的制御の管理と、外部境界ネットワーク デバイス (エッジ ルーターやデータセンター ルーターなど) の管理とサポートを担当します。 MCIOはまた、データセンター内のラックに最小限のサーバーハードウェアを設置する責任も担っています。 Azureの顧客はAzureインフラストラクチャと直接やり取りすることはありません。
サービス管理チームとサービスチーム
サービス チームと呼ばれるさまざまなエンジニアリング グループが、Azure サービスのサポートを管理します。 各サービス チームは、Azure のサポート領域を担当します。 各サービスチームは24時間体制でエンジニアを配置し、サービスの故障を調査・解決しなければなりません。 既定では、サービス チームは Azure で動作するハードウェアに物理的にアクセスできません。
サービスチームは次のとおりです。
- アプリケーション プラットフォーム
- Microsoft Entra ID
- Azure Compute
- Azure ネット
- クラウドエンジニアリングサービス
- ISSD:セキュリティ
- 多要素認証
- SQL Database
- Storage
ユーザーの種類
Microsoftの従業員や契約社員は社内ユーザーです。 その他のユーザーは外部ユーザーです。 すべての Azure 内部ユーザーの従業員ステータスは、顧客データへのアクセス (アクセスまたはアクセスなし) を定義する感度レベルで分類されています。 Azure に対するユーザー特権 (認証が行われた後の承認アクセス許可) については、次の表で説明します。
| 役割 | 内部または外部 | 感度レベル | 許可された特権と実行された機能 | アクセスの種類 |
|---|---|---|---|---|
| Azure データセンター エンジニア | 内部 | 顧客データへのアクセスなし | 施設の物理的なセキュリティを管理します。 データセンター内外のパトロールを実施し、すべてのエントリ ポイントを監視します。 一般サービス(食事や清掃など)やIT業務を提供する非クリアランスの人員をデータセンターの出入りに案内します。 ネットワークハードウェアの定期的な監視と保守を実施します。 インシデント管理と障害修正作業をさまざまなツールを使用して実行します。 データセンター内の物理ハードウェアの定期的な監視と保守を実施します。 物件所有者に環境へのアクセスをオンデマンドで要求できます。 フォレンジック調査を実施し、インシデント報告を記録し、必須のセキュリティ研修および方針要件を完遂します。 スキャナーやログ収集などの重要なセキュリティツールを所有・維持しましょう。 | 環境への永続的なアクセス。 |
| Azure インシデント トリアージ (迅速な対応エンジニア) | 内部 | 顧客データへのアクセス | MCIO、サポート、エンジニアリングチーム間のコミュニケーションを管理します。 トリアージプラットフォームのインシデント、展開の問題、サービス要請。 | 環境へのジャストインタイムアクセス、非顧客システムへの永続的なアクセスは制限付き。 |
| Azure デプロイ エンジニア | 内部 | 顧客データへのアクセス | Azure をサポートするためのプラットフォーム コンポーネント、ソフトウェア、およびスケジュールされた構成変更をデプロイおよびアップグレードします。 | 環境へのジャストインタイムアクセス、非顧客システムへの永続的なアクセスは制限付き。 |
| Azure 顧客向け障害サポート (テナント) | 内部 | 顧客データへのアクセス | 個々のコンピューティング テナントと Azure アカウントのプラットフォームの停止と障害をデバッグおよび診断します。 障害を分析します。 プラットフォームやお客様に対して重要な修正を推進し、サポート全体で技術的な改善を推進します。 | 環境へのジャストインタイムアクセス、非顧客システムへの永続的なアクセスは制限付き。 |
| Azure ライブ サイト エンジニア (監視エンジニア) とインシデント | 内部 | 顧客データへのアクセス | 診断ツールを使用してプラットフォームの正常性を診断し、軽減します。 ボリューム ドライバーの修正を推進し、停止によって障害が発生したアイテムの修理、および停止時の復元アクションの支援を行います。 | 環境へのジャストインタイムアクセス、非顧客システムへの永続的なアクセスは制限付き。 |
| Azure のお客様 | 外部 | なし | なし | なし |
Azure では、一意の識別子を使用して、組織のユーザーと顧客 (または組織のユーザーに代わって動作するプロセス) を認証します。 このアプローチは、Azure環境に属するすべての資産やデバイスに適用されます。
Azure 内部認証
TLS暗号化はAzure内部コンポーネント間の通信を保護します。 ほとんどの場合、X.509 証明書は自己署名されています。 Azureネットワーク外からアクセス可能な接続を持つ証明書は例外であり、FCの証明書も例外です。 信頼されたルート CA を基盤とする Microsoft の証明機関 (CA) が、FC 用の証明書を発行します。 この構成により、FC公開鍵のロールオーバーが可能です。 Microsoftの開発者ツールもFC公開鍵を使用しています。 開発者が新しいアプリケーションイメージを提出すると、Microsoftは埋め込まれた秘密を保護するためにFC公開鍵で画像を暗号化します。
Azure ハードウェア デバイス認証
FCは、制御下にあるさまざまなハードウェアデバイスに対して認証を行うための認証情報(鍵またはパスワード)のセットを管理しています。 Microsoft は、これらの資格情報へのアクセスを防止するシステムを使用しています。 具体的には、Microsoftはこれらの認証情報の転送、永続性、使用を設計し、Azureの開発者、管理者、バックアップサービス、スタッフが機密情報や機密情報にアクセスするのを防ぐよう設計しています。
Microsoft は、FC のマスター ID 公開キーに基づく暗号化を使用します。 この暗号化は、ネットワーク機器へのアクセスに使われる認証情報を転送するために、FCの設定および再設定時に行われます。 FC がクレデンシャルを必要とする場合、FC はクレデンシャルを取得して復号化します。
ネットワークデバイス
Azureネットワークチームは、ネットワークサービスアカウントを設定し、Azureクライアントがネットワークデバイス(ルーター、スイッチ、ロードバランサー)に認証できるようにします。
安全なサービス管理
Azure運用担当者は、セキュア管理ワークステーション(SAW)を使用しなければなりません。 特権アクセスワークステーションを使って同様の制御を実装しましょう。 SAWを使用することで、管理者はユーザーの標準アカウントとは別に個別に割り当てられた管理アカウントを使用します。 SAWは、機密性の高いアカウントに信頼できるワークステーションを提供することにより、そのアカウント分離の実践に基づいています。
次のステップ
Microsoft が Azure インフラストラクチャのセキュリティ保護を支援するために行っていることの詳細については、以下を参照してください。
