このレビューでは、Windows Azureプラットフォームのセキュリティのさまざまな側面がどのように提供されるかについて、できるだけ簡単に話そうとしました。 レビューは2つの部分で構成されています。 最初の部分では、Windows Azureプラットフォーム自体の機密性、ID管理、分離、暗号化、整合性、可用性といった基本情報を明らかにします。 レビューの2番目の部分では、SQLデータベース、物理的セキュリティ、クライアント側のセキュリティ機能、プラットフォームの認定、およびセキュリティの推奨事項に関する情報を提供します。
クラウドでのホスティングアプリケーションについて議論する場合、セキュリティは最も重要なトピックの1つです。 クラウドコンピューティングの人気の高まりは、特にリソースの共有とマルチテナンシーの存在に照らして、セキュリティの問題に注目を集めています。 マルチテナントおよびクラウドプラットフォームの仮想化の側面では、特にサイドチャネル攻撃（物理的な実装に関する情報の取得に基づく攻撃の種類）などの種類の攻撃を考慮すると、いくつかの独自のセキュリティメソッドが必要です。
2012年6月7日以降、Windows Azureプラットフォームは、SaaS、PaaS、または他のプラットフォームと呼ぶことはできなくなり、多くの種類のサービスを組み合わせた包括的な用語のようになりました。 マイクロソフトは、安全なランタイム環境を提供し、オペレーティングシステムとインフラストラクチャのレベルでセキュリティを提供します。 クラウドプラットフォームプロバイダーのレベルで実装されたセキュリティの側面のいくつかは、実際にはオンプレミスインフラストラクチャで利用可能なものよりも優れています。 たとえば、Windows Azureが配置されているデータセンターの物理的なセキュリティは、大多数の企業や組織のセキュリティよりもはるかに信頼性が高くなっています。 Windows Azureネットワーク保護、ランタイム環境の分離、およびオペレーティングシステムのセキュリティを確保するためのアプローチは、従来のホスティングよりもはるかに高くなっています。 したがって、アプリケーションをクラウドに配置すると、アプリケーションのセキュリティが向上します。 2011年11月、Windows Azureプラットフォームとその情報セキュリティ管理システムは、英国規格協会によってISO 27001認定を満たしていると認められました。プラットフォームの認定機能には、コンピューティング、ストレージ、仮想ネットワーク、仮想マシンサービスが含まれます。 次のステップは、Windows Azureの残りの機能（SQLデータベース、サービスバス、CDNなど）の認証です。
一般に、クラウドプラットフォームは、クライアントデータセキュリティの3つの基本的な側面を提供する必要があります。機密性、整合性、可用性です。Microsoftクラウドプラットフォームも例外ではありません。 このレビューでは、Windows Azureプラットフォームでセキュリティの3つの側面を提供するために使用されるすべてのテクノロジーと方法を可能な限り詳細に開示するようにします。
守秘義務
機密性を確保することにより、クライアントは、それに対応する権利を持つオブジェクトのみが自分のデータを利用できるようにすることができます。 Windows Azureプラットフォームでは、次のツールと方法によりプライバシーが確保されます。
- アイデンティティ管理 -認証されたプリンシパルが何かにアクセスできるオブジェクトであるかどうかを判断します。
- 分離 -物理レベルと論理レベルの両方の「コンテナー」を使用して、データの分離を保証します。
- 暗号化 -暗号化メカニズムを使用した追加のデータ保護。 暗号化は、通信チャネルを保護するためにWindows Azureプラットフォームで使用され、顧客データの保護を強化するために使用されます。
これら3つのテクノロジーすべてをさらに詳しく見てみましょう。
アイデンティティ管理
まず、サブスクリプションは、最も古く、最も信頼されているインターネット認証システムの1つである安全なWindows Live IDシステムを使用してアクセスされます。 すでに展開されているサービスへのアクセスは、サブスクリプションによって制御されます。
Windows Azureにアプリケーションをデプロイするには、Windows AzureポータルからとService Management API（SMAPI）を使用する2つの方法があります。 Service Management API（SMAPI）は、Representational State Transfer（REST）プロトコルを使用してWebサービスを提供し、開発者向けに設計されています。 プロトコルはSSLの上で実行されます。
SMAPI認証は、公開キーと秘密キーのペアと、Windows Azureポータルに登録されている自己署名証明書を作成するユーザーに基づいています。 このようにして、重要なアプリケーション管理アクティビティはすべて、独自の証明書によって保護されます。 同時に、証明書は信頼されたルート認証局（CA）に結び付けられておらず、代わりに自己署名されています。これにより、ある程度の精度で、特定のクライアント代表のみがこの方法で保護されたサービスとデータにアクセスできるようになります。
Windows Azureストレージは、2つのストレージアカウントキー（SAK）に基づく独自の認証メカニズムを使用します。これは各アカウントに関連付けられており、ユーザーがリセットできます。
したがって、Windows Azureは完全な包括的な保護と認証を実装し、その一般的なデータを表に示します。
| 科目 | 保護対象 | 認証メカニズム |
| お客さま | サブスクリプション | Windows Live ID |
| 開発者 | Windows Azureポータル/ SMAPI | Windows Live ID（ポータル）、自己署名証明書（SMAPI） |
| ロールインスタンス | 保管 | キー |
| 外部アプリケーション | 保管 | キー |
| 外部アプリケーション | 用途 | ユーザー定義 |
ストレージサービスの場合、共有アクセス署名を使用してユーザー権利を決定できることに注意してください（すべてのストレージサービス-バージョン1.7以前-BLOBのみ）。 以前は、共有アクセス署名はBLOBでのみ使用可能でした。これにより、ストレージアカウントの所有者は、BLOBへのアクセスを提供する特定の方法で署名付きURLを発行できました。 現在、BLOBおよびコンテナに加えて、テーブルおよびキューで共有アクセス署名を使用できます。 この機能を導入する前は、テーブルまたはキューを使用してCRUDから何かを達成するには、アカウントの所有者である必要がありました。 これで、他の人に共有アクセス署名で署名されたリンクを提供し、必要な権利を提供できます。 共有アクセス署名の機能はこれにあります-リソースへのアクセスの詳細な制御、共有アクセス署名を持つユーザーがリソースに対して実行できる操作を決定します。 共有アクセス署名の定義に使用できる操作のリストには、次のものが含まれます。
- コンテンツの読み取りと書き込み-BLOBの場合、それらのプロパティとメタデータ、およびブロックリストもあります。
- スナップショットBLOBの削除、リース、作成。
- コンテンツアイテムのリストを取得する。
- キュー内のメッセージの追加、削除、更新。
- キュー内のメッセージの数を含むキューメタデータの取得。
- テーブルのエンティティの読み取り、追加、更新、挿入。
共有アクセス署名パラメーターには、ストレージリソースへのアクセスを許可するために必要なすべての情報が含まれます-URLの要求パラメーターは、共有アクセス署名が「悪くなる」期間、この共有アクセス署名に許可される許可、アクセスが許可されるリソース、および、実際には、認証が発生する署名。 さらに、保存されたアクセスポリシーへのリンクを共有アクセス署名URLに含めることができます。これにより、別の制御レイヤーを提供できます。
当然、共有アクセス署名はHTTPSを使用して配布し、操作に必要な最短時間にアクセスできるようにする必要があります。
共有アクセス署名を使用する典型的な例は、アドレス帳サービスです。その開発の条件の1つは、多数のユーザーに対応できることです。 このサービスにより、ユーザーは自分のアドレス帳をクラウドに保存し、任意のデバイスまたはアプリケーションからアクセスできます。 ユーザーはサービスに登録し、アドレス帳を受け取ります。 Windows Azureロールモデルを使用してこのシナリオを実装すると、サービスはクライアントアプリケーションとクラウドプラットフォームストレージサービスの間のレイヤーとして機能します。 クライアントアプリケーションの認証後、サービスのWebインターフェイスを介してアドレス帳にアクセスし、クライアントによって開始されたリクエストをクラウドプラットフォームテーブルストレージサービスに送信します。 ただし、特にこのシナリオでは、テーブルサービスへの共有アクセス署名の使用は見栄えがよく、非常に簡単に実装されます。 テーブルサービス用のSASを使用して、アプリケーションのアドレス帳に直接アクセスできます。 このアプローチにより、サービスの形で要求を処理するレイヤーを削除することにより、システムのスケーラビリティの度合いを高め、ソリューションのコストを削減できます。 この場合のサービスの役割は、クライアントサブスクリプションの処理と、クライアントアプリケーション用の共有アクセス署名トークンの生成に限定されます。
共有アクセス署名の詳細については、このトピックに関する記事をご覧ください 。
セキュリティの追加の手段は、最小限の特権の原則であり、実際には、一般的に受け入れられている推奨プラクティスでもあります。 この原則によれば、クライアントは仮想マシンへの管理アクセスを許可されておらず（Windows Azureのすべてのサービスが仮想化されていることを思い出します）、実行するソフトウェアは特別な制限付きアカウントで実行されます。 したがって、何らかの方法でシステムにアクセスする場合は、アップグレード手順を実行する必要があります。
ネットワークを介してWindows Azureおよびプラットフォーム内に送信されるすべてのものは、SSLを使用して確実に保護され、ほとんどの場合、SSL証明書は自己署名されます。 例外は、Microsoftが発行した証明書を使用するストレージサービスやファブリックコントローラーなど、Windows Azure内部ネットワーク外へのデータ転送です。
Windows Azureアクセスコントロールサービス
たとえば、ライブIDログインだけでなく、Windows Azure認証メカニズムとクラウド（またはオンプレミス）アプリケーションの統合など、より複雑なID管理シナリオに関しては、Microsoftは独自のWindows Azureアクセス制御サービスを提供しています。 Windows Azureアクセス制御サービスは、クラウドまたはオンプレミスアプリケーションに連邦政府のセキュリティとアクセス制御を提供するサービスを提供します。 ADにはAD FS 2.0のサポートが組み込まれており、WS-Fedをサポートするすべてのプロバイダー+ LiveID、FB、Googleのパブリックプロバイダーは、ポータルで事前に構成されたプロバイダーです。 さらに、ADはOAuth、OpenId、およびRESTサービスをサポートしています。
 |
Windows Azureおよびアクセス制御サービス（Windows Azure Active Directoryを含む）は、クレームベース認証を使用します。 これらのステートメントには、この情報を提供するIDプロバイダーが許可するオブジェクト情報が含まれる場合があります。 アサーションベースの認証を使用することは、複雑な認証シナリオを解決するための最も効果的な方法の1つです。 そのため、多くのWebプロジェクトでは、Google、Yahoo、Facebookなどのクレームを使用しています。 選択したIDプロバイダーを使用した認証後、クライアントはWS-フェデレーションまたはセキュリティアサーションマークアップ言語（SAML）を使用して承認を受け取り、必要に応じてセキュリティトークン（ステートメントを含むコンテナー）に転送します。 クレームを使用すると、たとえば組織の資格情報でログインしたユーザーがすべてのリソースに自動的にアクセスするときに、シングルサインオンの原則を効果的に実装できます。
たとえば、クライアントには、認証のためにローカルデータセンターにある認証用のユーザー情報の特定のリポジトリを使用するアプリケーションがあります。 このため、特定の標準を実装する特別な認証モジュールが使用されます。 ある時点で、単一のプロバイダーでフォールトトレラント認証メカニズムを実装するだけでなく、Windows Live Id、FacebookなどのパブリックIDプロバイダーを介して認証する機会をユーザーに提供する必要が生じます。 認証モジュールは、これらのIDプロバイダーと連携するためのロジックを追加します。 ただし、IDプロバイダーの認証ロジック、標準、または構文に、最も軽微な変更が発生した場合でも、開発者はこの変更を手動でエンコードする必要がありますが、これはビジネスにとって非効率的なアプローチです。 このアプリケーションをクラウドに移行すると、問題はさらに深刻になります。 Windows Azureアクセス制御サービスでは、エレガントに構築されたインフラストラクチャを提供することにより、この特定のシナリオを解決できます。ユーザーがWebアプリケーションページに入ると、ユーザーはまずWindows Azureアクセス制御サービスに転送され、そこで必要な認証プロバイダーを選択してから、ヘルプで認証してシステムにログオンします。 この場合、開発者は内部認証メカニズム、トークン、クレームなどから完全に切り離すことができます。MicrosoftとWindows Azureアクセスコントロールサービスがすべての作業を行います。 したがって、クラウドに移行した既製のアプリケーションがある状況でID管理を提供する必要がある場合に、一般的なシナリオを実装することができます。
また、よくある質問は、「ドメイン資格情報を使用してユーザーを認証する既製のアプリケーションがある場合はどうなりますか？」です。 この質問には答えがあります-クラウドにあるアプリケーションとローカルのActive Directoryインフラストラクチャを統合するための作業スクリプトを取得するには、Active Directory Federation Services 2.0要素を+ AD + Windows Azureアプリケーションバンドルに追加するだけで十分です。 この場合のユーザーにとって、認証は引き続き透過的なプロセスです。 さらに、資格情報はクラウドに転送されません。ADFS 2.0は、一部の資格情報でユーザー資格情報を受け取り、これらのクレームからセキュリティトークンを生成し、安全なアクセス制御サービスチャネルを介して送信する認証プロバイダーとして機能します。 アプリケーションは引き続きWindows Azureアクセスコントロールサービスのみを信頼し、そこからのクレームのみを受け取りますが、これらのクレームは完全に異なるソースから取得できます。承認のリクエスト、トークンの作成など、またはASP.NETメンバーシッププロバイダーを独自のクレームプロバイダーとして使用します。
Windows Azure Active Directory
Windows Azureで認証シナリオを実装するための最新のサービスは、Windows Azure Active Directoryです。 このサービスはローカルActive Directoryの完全な類似物ではなく、「ミラー」を使用してローカルディレクトリをクラウドに拡張することをすぐに言及する価値があります。
Windows Azure Active Directoryは、3つの主なコンポーネントで構成されています。カタログから情報を作成、受信、更新、削除でき、SSOを使用できるRESTサービス（Office 365、Dynamics、Windows Intuneなどと統合する場合）。 FacebookやGoogleなどのさまざまなIDプロバイダーとの統合、およびWindows Azure Active Directoryの機能へのアクセスを簡素化するライブラリ。 当初、Office 365にはWindows Azure Active Directoryが使用されていました。WindowsAzure Active Directoryは、次の情報への便利なアクセスを提供します。
ユーザー ：パスワード、セキュリティポリシー、ロール。
グループ ：セキュリティ/配布グループ。
その他の基本情報（たとえば、サービスに関する）。 これらすべては、Windows Azure AD Graphを使用して提供されます。これは、RESTをサポートするインターフェイスを備えた革新的なソーシャル企業グラフであり、情報と接続を簡単に発見するためのエクスプローラービューを備えています。
アクセス制御サービスと同様に、ADを実行しているオンプレミスインフラストラクチャと統合する場合、Active Directoryフェデレーションサービスバージョン2をインストールおよび構成する必要があります。
したがって、Windows Azure Activeを使用すると、たとえばOffice 365を使用する内部およびパブリックプランアプリケーションの両方を作成できるだけでなく、オンプレミスのActive DirectoryインフラストラクチャとWindows Azureの間にフェデレーション認証および同期シナリオを実装できます。
分離
クライアントによって定義されたロールインスタンスの数に応じて、Windows Azureはロールインスタンス（クラウドサービス用）と呼ばれる同じ数の仮想マシンを作成し、これらの仮想マシンにデプロイされたアプリケーションを起動します。 これらの仮想マシンは、クラウドで動作するように特別に設計されたハイパーバイザー（Windows Azure Hypervisor）で実行されます。
もちろん、効果的なセキュリティメカニズムを実装するには、個々のクライアントにサービスを提供するサービスインスタンスを相互に適切に分離し、ストレージサービスに格納されるデータを適切に分離する必要があります。
。
プラットフォーム上のあらゆるもののすべての仮想「起源」を考えると、いわゆるルートVM（Fabric Controllerが独自のFabric Agentをホストし、クライアント仮想マシンでホストされるGuest Agentを制御する安全なシステム）をゲスト仮想から分離することが重要ですマシンとゲスト仮想マシンは離れています。 Windows Azureは、Hyper-Vに基づいて開発された仮想化レイヤーである独自のハイパーバイザーを使用します。 機器で直接実行され、各ノードを特定の数の仮想マシンに分割します。 各ノードには、ホストオペレーティングシステムが実行されているルートVMがあります。 Windows Azureは、オペレーティングシステムとして、高度にトリミングされたバージョンのWindows Serverを使用します。WindowsServerでは、ホスト仮想マシンにサービスを提供するために必要なサービスがインストールされます。 さらに、クラウドでの仮想化により、次のような新しいタイプの脅威が出現しています。
•物理ホストまたは別の仮想マシン上の仮想マシンからの攻撃による権限昇格
•仮想マシンの制限を超えて、OS制御（ジェイルブレイキング、ハイパージャッキング）をキャプチャして、物理ホストのOSのコンテキストでコードを実行する
すべてのネットワークアクセスとディスク操作は、ルートVMのオペレーティングシステムによって制御されます。 ハイパーバイザーの仮想ネットワーク上のフィルターは、仮想マシンとの間のトラフィックを制御し、スニッフィングに基づくさまざまな攻撃も防ぎます。 さらに、ブロードキャストとマルチキャストをブロックする他のフィルターがインストールされます（もちろん、DHCPリースを除く）。 さらに、接続ルールは累積的です-たとえば、ロールAとBのインスタンスが異なるアプリケーションに属している場合、Aはインターネット接続（設定が必要）を開くことができ、Bはからの接続を受け入れることができる場合にのみ、Bへの接続を開くことができますインターネット。
パケットフィルターについては、役割のリストを持つコントローラーがこのリストを取得してこれらの役割のインスタンスのリストに変換し、リストをIPアドレスに変換してから、エージェントが使用してアプリケーション内接続を許可するパケットフィルターを構成しますこれらのIPアドレス。
Fabric Controller自体は、ホスト上の潜在的にハッキングされたFabric Agentから最大限に保護されていることに注意してください。 コントローラーとエージェント間の通信チャネルは双方向です。一方、エージェントは、コントローラーで使用されるSSL保護サービスを実装し、リクエストにのみ応答できますが、コントローラーへの接続を開始することはできません。 さらに、SSLを認識しないコントローラーまたはデバイスがあることが判明した場合、それらは別のVLANに配置されます。
Windows AzureのVLANは非常に積極的に使用されています。 まず第一に、それらはコントローラーと他のデバイスの分離を確実にするために使用されます。 VLANは、ルーター経由以外の2つのVLAN間で「会話」ができないようにネットワークを分割し、トラフィックのスプーフィングや表示など、侵害されたノードの悪意のある操作を防ぎます。 各クラスターには3つのVLANがあります。
1）プライマリVLANは、信頼できないクライアントノードを接続します。
2）コントローラーのVLAN-信頼できるコントローラーとサポートされているシステム。
3）VLANデバイス-信頼できるインフラストラクチャデバイス（ネットワークなど）。
注：コントローラーVLANとプライマリVLAN間の通信は可能ですが、コントローラーのみがプライマリへの接続を開始できますが、その逆はできません。 同様に、プライマリVLANからデバイスVLANへの通信はブロックされます。
暗号化
効果的なセキュリティツールは、もちろんデータの暗号化です。 すでに何度も述べたように、可能なことはすべてSSLで保護されています。 クライアントは、Windows Azure SDKを使用できます。WindowsAzure SDKは、Windows Azureの.NET Cryptographic Service Providers（CSP）の統合機能でベース.NETライブラリを拡張します。たとえば、次のとおりです。
1）MD5やSHA-2などの暗号関連機能の完全なセット。
2）RNGCryptoServiceProvider-暗号化に十分なエントロピーを実装するのに十分な乱数を生成するためのクラス。
3）長年の実使用で検証された暗号化アルゴリズム（AESなど）。
4）など
プラットフォーム内の通信チャネルを介して送信されるすべての制御メッセージは、最小長が128ビットの暗号化キーを使用したTLSプロトコルによって保護されます。
Windows Azureへのすべての操作呼び出しは、SOAP、XML、RESTベースの標準プロトコルを使用して行われます。 通信チャネルは、設定に応じて暗号化される場合とされない場合があります。
ストレージサービスレベルでは、クライアントデータはデフォルトでは暗号化されません -つまり、BLOBまたはテーブルストレージに保存される方法、つまり、この形式で保存される方法です。 データを暗号化する必要がある場合は、クライアント側でこれを行うか、Trust Services機能（ http://www.microsoft.com/en-us/sqlazurelabs/labs/trust-services.aspx ）を使用できます。サーバー側の暗号化。 Trust Servicesを使用する場合、データは承認されたユーザーのみが復号化できます。
Microsoftコードネーム「Trust Services」は、Windows Azureに保存されているクラウドベースのアプリケーション内の機密データを保護するためにアプリケーションレベルで使用される暗号化フレームワークです。 フレームワークによって暗号化されたデータは、許可されたクライアントによってのみ復号化でき、暗号化されたデータの配布が可能になります。 同時に、暗号化されたデータ、ストリームの暗号化、およびデータ管理と公開のための役割の分離に関する検索がサポートされています。
特に重要なデータについては、重要なデータがローカルに保存されているときにハイブリッドソリューションを使用できますが、Windows AzureストレージまたはSQLデータベースには重要ではありません。
誠実さ
クライアントが電子形式でデータを使用する場合、彼は当然、このデータが意図的および偶発的な変更から保護されることを期待しています。 Windows Azureでは、第1に、クライアントがコンピューティングノード上の仮想マシンに対する管理者特権を持たないという事実によって整合性が保証されます。第2に、コードは最小限の特権を持つWindowsアカウントで実行されます。 VMに永続的なストレージはありません。 各VMは3つのローカル仮想ディスク（VHD）に接続されています。
*ディスクD：Windowsのいくつかのバージョンの1つが含まれています。 WAはさまざまなイメージを提供し、それらをタイムリーに更新します。 クライアントは最適なバージョンを選択し、新しいバージョンのWindowsが利用可能になり次第、それに切り替えることができます。
*ディスクE：コントローラーによって作成されたイメージと、クライアントなどのアプリケーションが提供するコンテンツが含まれています。
*ディスクC：構成情報、スワップファイル、およびその他のサービスデータが含まれています。
D：およびE：ドライブは、もちろん仮想ディスクであり、読み取り専用です（ACL、アクセスリスト、クライアントプロセスからのアクセスを拒否する特定の権限が含まれます）。 ただし、オペレーティングシステムには抜け穴が残っていました。これらの仮想ディスクはVHD +デルタファイルとして実装されています。 たとえば、オペレーティングシステムを含むVHD D：をプラットフォームが更新すると、このディスクのデルタファイルは消去され、新しい方法で書き込まれます。 他のディスクでも。 ロールのインスタンスが別の物理マシンに転送されると、すべてのディスクが元の状態に戻ります。
在庫状況
クラウドにサービスを提供するビジネスクライアントまたは単純な個人は、消費者と実際にはクライアントの両方の最大の可用性のために非常に重要です。Microsoftクラウドプラットフォームは、冗長性を実装する機能の特定のレイヤーを提供し、それにより、顧客データの最大限の可用性を実現します。
Windows Azureの基本的なアクセシビリティメカニズムを明らかにする最も重要な概念は、レプリケーションです。新しいメカニズムを見てみましょう（そして、それらは本当に新しいものです-公式発表は2012年6月7日に行われました）。
ローカル冗長ストレージ（LRS）は、1つの地理的な場所（地域）内で高度な耐久性と可用性を備えたストレージを提供します。プラットフォームは、各データ項目の3つのレプリカを1つの主要な地理的場所に保存します。これにより、ストレージアカウントがアイドル状態にならず、したがって、一般的な障害（ディスク、ノード、バスケットなどの障害）ストアの可用性と耐久性に影響します。リポジトリへのすべての書き込み操作は、3つの異なるフォールトドメイン（フォールトドメイン）の3つのレプリカで同期的に実行され、3つすべての操作が正常に完了すると、コードはトランザクションの正常な完了を返します。ローカル冗長ストレージを使用する場合、データレプリカが配置されているデータセンターの場合、何らかの理由で完全に無効になります。マイクロソフトはクライアントに連絡し、クライアントのサブスクリプションで提供された連絡先を使用して、情報とデータの損失の可能性について報告します。
Geo Redundant Storage（GRS）は、データレプリカを主要な地理的場所だけでなく、同じ地域の数百キロメートル離れた場所に配置することにより、はるかに高い耐久性とセキュリティを提供します。 BLOBおよびテーブルストレージサービスのすべてのデータは地理的に複製されます（ただし、キューはありません）。地理的に冗長なストレージを使用すると、プラットフォームは再び3つのレプリカを2つの場所に保存します。したがって、データセンターが機能しなくなった場合、データは2番目の場所から利用できます。最初の冗長オプションの場合と同様に、システムが正常終了コードを返す前に、主要な地理的位置でのデータ記録操作を確認する必要があります。非同期モードでの操作の確認時に、別の地理的な場所への複製が発生します。もっと詳しく見てみましょう地理的複製はどのように行われますか。
データウェアハウスで作成、削除、更新などの操作を実行すると、トランザクションはメインの地理的場所にある3つの異なるエラーおよび更新ドメインでストアの3つの完全に異なるノードに完全に複製され、その後クライアントは操作が正常に完了したことを示すコードを返し、非同期で確認されますトランザクションは2番目の場所に複製され、異なるエラードメインと更新ドメイン内の3つの完全に異なるストレージノードに完全に複製されます。すべてが非同期に行われるため、全体的なパフォーマンスは低下しません。
地理的な耐障害性と、深刻な混乱が発生した場合のすべての復元方法について。主要な地理的場所で重大なグリッチが発生した場合、企業が結果を最大限になめらかにしようとするのは当然です。ただし、すべてが完全に不良でデータが失われた場合、地理的フォールトトレランスのルールを適用する必要がある場合があります-クライアントはメインロケーションで災害を通知され、その後、対応するDNSレコードがメインロケーションから2番目（account.service.core.windows.net）に書き換えられます）もちろん、DNSレコードを変換するプロセスでは、何かが機能する可能性は低いですが、完了すると、既存のBLOBとテーブルがURLで利用可能になります。翻訳プロセスが完了すると、2番目の地理的な場所がメインの場所にアップグレードされます（データセンターの次の障害まで）。また、データセンターのステータスを上げるプロセスが完了した直後に、同じ地域に新しい2番目の地理的な場所を作成し、さらにデータを複製するプロセスが開始されます。
これらはすべて、ファブリックコントローラーによって制御されます。仮想マシンにインストールされたゲストエージェント（GA）が応答を停止した場合、コントローラーはすべてを別のノードに転送し、ネットワーク構成を再プログラムして完全な可用性を確保します。
また、Windows Azureプラットフォームには、更新ドメインやエラードメインなどのメカニズムがあり、オペレーティングシステムまたはハードウェアエラーを更新する場合でも、展開されたサービスの継続的な可用性を保証します。
エラードメインは物理ユニット、展開コンテナであり、通常はラックに限定されます。なぜrecomに限定されているのですか？ドメインが異なる川にある場合、インスタンスは一般的な障害の十分な確率がないように配置されることが判明したためです。また、あるエラードメインでエラーが発生しても、他のドメインでエラーが発生することはありません。したがって、エラードメインで何かが壊れると、ドメイン全体が壊れているとマークされ、展開は別のエラードメインに転送されます。現在、エラードメインの数を制御することはできません-これはFabric Controllerが行うことです。
更新ドメインは、より制御されたエンティティです。更新ドメインに対する一定レベルの制御があり、ユーザーはサービスのインスタンスのグループの増分更新またはローリング更新を一度に実行できます。更新ドメインはエラードメインとは異なりますが、エラードメインは物理エンティティです。更新ドメインはロールを論理的にグループ化するため、1つのアプリケーションを複数の更新ドメインに配置でき、同時に2つのエラードメインにのみ配置できます。この場合、更新は最初に更新ドメインNo. 1で、次に更新ドメインNo. 2で、というように行えます。
各データセンターには、自律電源を含む少なくとも2つの電源があります。環境制御は自律的であり、システムがインターネットに接続されている限り機能します。