Azure パブリック クラウドでの分離

Azureは、共有の物理インフラ上でアプリケーションや仮想マシン(VM)を運用するのに役立ちます。 クラウド環境でアプリケーションを運用する主な経済的利点の一つは、共有リソースのコストを複数のテナント間で分散できることです。 このマルチテナンシーの実践は、低コストで異なるテナント間でリソースを多重化することで効率を向上させます。 しかし同時に、物理サーバーやその他のインフラリソースを共有し、任意で潜在的に悪意のあるユーザーの機密アプリケーションやVMを動かすリスクも伴います。

この記事では、Azureが悪意のあるユーザーと非悪意のあるユーザーの両方からどのように隔離を提供するかを説明します。 複数の分離オプションを提供することで、クラウドソリューションの設計ガイドとして機能します。

テナント レベルの分離

クラウドコンピューティングの主な利点の一つは、複数のテナント間で同時に共有された共通インフラを築くという概念であり、規模の経済を生み出します。 この概念はマルチテナントと呼ばれます。 Microsoftは、Microsoft Azureのマルチテナントアーキテクチャがセキュリティ、機密性、プライバシー、整合性、可用性の基準をサポートするよう継続的に取り組んでいます。

クラウド対応の職場では、テナントは、そのクラウド サービスの特定のインスタンスを所有および管理するクライアントまたは組織です。 Microsoft Azureが提供するアイデンティティプラットフォームにおいて、テナントとは、組織がMicrosoftクラウドサービスに登録した際に受け取り所有するMicrosoft Entra IDの専用インスタンスです。

各 Microsoft Entra ディレクトリは、他の Microsoft Entra ディレクトリからは独立した個別のものです。 企業のオフィスビルのように、Microsoft Entraディレクトリは組織のみが使用できる安全な資産です。 Microsoft Entra アーキテクチャは、顧客のデータや ID 情報が混合しないよう分離します。 この隔離により、あるMicrosoft Entraディレクトリのユーザーや管理者が誤って、または悪意を持って別のディレクトリのデータにアクセスすることがなくなります。

Azure テナント

Azure テナンシー(Azure サブスクリプション)とは、顧客と請求関係、そして Microsoft Entra ID における一意のテナントを指します。 Microsoft Entra IDとそのAzureロールベースのアクセス制御は、Microsoft Azureでテナントレベルの隔離を提供します。 各Azure サブスクリプションは、1 つの Microsoft Entra ディレクトリに関連付けられています。

そのディレクトリのユーザー、グループ、アプリケーションは、Azure サブスクリプション内のリソースを管理できます。 これらのアクセス権は、Azureポータル、Azureコマンドラインツール、Azure管理APIを使って割り当てます。 セキュリティ境界は論理的に Microsoft Entra テナントを分離しているため、悪意あるまたは偶然の共同テナントへのアクセスや侵害を防ぎます。 Microsoft Entra IDは、分離されたネットワーク セグメント上で分離された "ベア メタル" サーバー上で実行されます。ホスト レベルのパケット フィルター処理と Windows ファイアウォールによって、不要な接続とトラフィックがブロックされます。

• Microsoft Entra ID内のデータにAccessするには、セキュリティ トークン サービス (STS) によるユーザー認証が必要です。 認証システムは、ユーザーの存在、有効状態、役割に関する情報を用いて、このセッションでターゲットテナントへのアクセス権を有しているかどうかを判断します。

• テナントは個別のコンテナーであり、これらのコンテナー間にリレーションシップはありません。

• テナント管理者がフェデレーションを通じて、または他のテナントからユーザーアカウントをプロビジョニングすることにより付与した場合を除き、テナント間にアクセスは存在しません。

• Microsoftは、Microsoft Entraサービスを構成するサーバーへの物理的アクセスや、Microsoft Entra IDのバックエンドシステムへの直接アクセスを制限しています。

• Microsoft Entraユーザーは物理的な資産や場所にアクセスできないため、以下の論理的なAzure RBACポリシーチェックを回避することはできません。

診断とメンテナンスのニーズには、Just-In-Time 特権昇格システムを使用する運用モデルを使用します。 Microsoft Entra Privileged Identity Management(PIM)は適格管理者の概念を紹介します。適格管理者とは、時折特権アクセスが必要なユーザーですが、毎日ではありません。 ユーザーがアクセスを必要とするまで、役割は非アクティブです。 ユーザーはその後、アクティベーションプロセスを完了し、あらかじめ決められた期間だけアクティブな管理者となります。

Microsoft Entra IDは、テナントによってのみ所有および管理されるコンテナーに対するポリシーとアクセス許可を持つ、独自の保護されたコンテナー内の各テナントをホストします。

テナント コンテナーの概念は、ポータルから永続的なstorageまで、すべてのレイヤーのディレクトリ サービスに深く浸透しています。

複数の Microsoft Entra テナントのメタデータが同じ物理ディスクに格納されている場合でも、ディレクトリ サービスが定義する以外のコンテナー間の関係はなく、テナント管理者によって指示されます。

Azure ロールベースのアクセス制御 (Azure RBAC)

Azureロールベースのアクセス制御(Azure RBAC)は、Azureサブスクリプション内で利用可能な複数のコンポーネントを共有することを支援し、Azure向けの細かなアクセス管理を提供します。 Azure RBAC を使用すると、組織内の職務を分離し、ユーザーがジョブを実行するために必要な内容に基づいてaccessを付与できます。 すべてのユーザーにAzureサブスクリプションまたはリソースの無制限のアクセス許可を付与する代わりに、特定のアクションのみを許可できます。

Azure RBAC には、すべてのリソースの種類に適用される 3 つの基本的なロールがあります。

• Owner には、他のユーザーにアクセス権を委任する権限を含め、すべてのリソースへの完全なアクセスが与えられています。

• Contributor は、すべての種類のAzure リソースを作成および管理できますが、他のユーザーにaccessを付与することはできません。

• Reader は、既存のAzure リソースを表示できます。

Azureの残りのAzure ロールでは、特定のAzure リソースを管理できます。 たとえば、仮想マシン共同作成者ロールを使用すると、ユーザーはvirtual machinesを作成および管理できます。 仮想マシンが接続するAzure Virtual Networkまたはサブネットへのaccessは提供されません。

Azure組み込みロールAzureで使用できるロールの一覧が表示されます。 各組み込みロールがユーザーに付与する操作とスコープを指定します。 さらに制御できるように独自のロールを定義する場合は、Azure RBAC で Custom ロールを構築する方法を参照してください。

Microsoft Entra IDのその他の機能には、次のようなものがあります。

• Microsoft Entra IDは、ホストされている場所に関係なく、SaaS アプリケーションへの SSO を有効にします。 Microsoft Entra IDとフェデレーションされているアプリケーションもあれば、パスワード SSO を使用するアプリケーションもあります。 フェデレーション アプリケーションでは、ユーザー プロビジョニングとパスワード保管もサポートできます。

• Microsoft Entra IDは、Active Directory フェデレーション サービス (AD FS)、同期、オンプレミス ディレクトリとのレプリケーションを使用してフェデレーションを通じてサービスとしての ID を提供します。

• Microsoft Entra 多要素認証では、モバイル アプリ、通話、テキスト メッセージを利用してサインインを検証することをユーザーに要求します。 Microsoft Entra IDと組み合わせてマルチファクター認証サーバーを使ったオンプレミスリソースの保護、SDKを使ったカスタムアプリケーションやディレクトリの保護に役立ちます。

• Microsoft Entra Domain Servicesは、ドメインコントローラーを展開せずにAzure仮想マシンをActive Directoryドメインに結合するのを助けます。 Group Policyを使用してすべてのAzure virtual machinesにセキュリティ ベースラインを適用することで、企業のActive Directory資格情報を使用してこれらのvirtual machinesにサインインし、ドメインに参加しているvirtual machinesを管理できます。

• Microsoft Entra 外部 IDは、数億件のアイデンティティにスケールする、消費者向けアプリケーション向けの非常に利用可能なグローバルアイデンティティ管理サービスです。 モバイルやウェブプラットフォームを横断して統合できます。 コンシューマーは、既に持っているソーシャル アカウントを使用するか、資格情報を作成して、すべてのアプリケーションにサインインできます。その場合のエクスペリエンスは、カスタマイズすることができます。

Microsoft 管理者からの分離とデータの削除

Microsoft は、不適切なaccessや未承認のユーザーによる使用からお客様のデータを保護するための強力な対策を講じています。 Online Services使用条件は、データへのアクセスを管理し、それらの運用プロセスと制御をサポートする契約上のコミットメントを提供します。

• Microsoft のエンジニアは、クラウド内のデータに対する既定のaccessを持っていません。 代わりに、必要な場合にのみ、管理の監視下でアクセスが付与されます。 そのaccessは慎重に制御され、ログに記録され、不要になったときに取り消されます。
• マイクロソフトは他の会社に委託して限られたサービスを提供することがあります。 下請け業者は、Microsoft が採用したサービスを提供するためにのみ顧客データをaccessすることがあり、他の目的で使用することは禁止されています。 さらに、顧客の情報の機密性を維持するために契約上の義務があります。

Microsoft および認定監査会社は、ISO/IEC 27001 などの監査認定を受けたビジネス サービスを定期的に検証しています。 これらの監査者は、サンプル監査を実行して、accessが正当なビジネス目的のみを目的としていることを証明します。 ご自身の顧客データには、どんな理由でも、いつでもアクセスできます。

データを削除すると、Microsoft Azureは、キャッシュされたコピーやバックアップ コピーを含むデータを削除します。 スコープ内サービスの場合、その削除は保持期間の終了後 90 日以内に行われます。 (Online Services Terms の [データ処理条件] セクションでは、スコープ内サービスが定義されています)。

ストレージに使用されているディスクドライブでハードウェア障害が発生した場合、Microsoftはそのドライブを安全に消去または破棄し、交換または修理のために製造元に返却します。 Microsoftは、誰にもデータを復元できないようにドライブ上のデータを上書きします。

コンピューティングの分離

Microsoft Azure は、さまざまなクラウドベースのコンピューティング サービスを提供します。これには、アプリケーションまたは企業のニーズを満たすために自動的にスケールアップおよびスケールダウンできるさまざまなコンピューティング インスタンスとサービスが含まれています。 これらの計算インスタンスやサービスは、組織が求める構成の柔軟性を犠牲にすることなく、複数のレベルでデータを保護するための隔離を提供します。

分離された仮想マシンのサイズ

Azure コンピューティングでは、特定の種類のハードウェアに分離され、1 人の顧客専用の仮想マシン サイズが提供されます。 分離されたサイズは特定のハードウェア世代で動作します。 Azureは、ハードウェア世代が終了するか新しいハードウェア世代が利用可能になった際にこれらのサイズを廃止します。

孤立した仮想マシンサイズは、他のテナントのワークロードから高い隔離が必要なワークロードに最適です。 この隔離は、コンプライアンスや規制要件を満たすために時折必要とされます。 孤立したサイズを使うことで、その特定のサーバーインスタンス上で仮想マシンだけが動作していることが保証されます。

孤立型VMは大きいため、Azure サポートでネスト仮想マシンを活用してリソースを細分化することができます。

現在の孤立仮想マシンの提供には以下が含まれます:

• Standard_E192is_v6
• Standard_E192ids_v6
• Standard_E104i_v5
• Standard_E104id_v5
• Standard_E104is_v5
• Standard_E104ids_v5
• Standard_E112ias_v5
• Standard_E112iads_v5
• Standard_E80is_v4
• Standard_E80ids_v4
• Standard_E96ias_v4
• Standard_E112ibs_v5
• Standard_E112ibds_v5
• Standard_EC96ias_v5
• Standard_EC96iads_v5
• Standard_HB120rs_v3
• Standard_HB176rs_v4
• Standard_HB368rs_v5
• Standard_HX176rs
• Standard_M832is_16_v3
• Standard_M832ids_16_v3
• Standard_M192is_v2
• Standard_M192ids_v2
• Standard_M192ims_v2
• Standard_M192idms_v2
• Standard_NC64as_T4_v3
• Standard_NC96ads_A100_v4
• Standard_NC80adis_H100_v5
• Standard_ND128isr_NDR_GB200_v6
• Standard_ND128isr_NDR_GB300_v6
• Standard_ND96isr_H100_v5
• Standard_ND96isr_H200_v5
• Standard_ND96isr_MI300X_v5
• Standard_NG32ads_V620_v1
• Standard_NG32adms_V620_v1
• Standard_NV72ads_A10_v5

孤立したVMサイズの廃止

孤立したVMサイズはハードウェアの寿命に制限されます。 Azure は、サイズの正式な廃止日の12か月前にリマインダーをお知らせし、検討のために更新されたアイソレート環境を提供します。 Azureは退役時の以下のサイズを発表しました。

これらの孤立した仮想マシンのリソースをさらに細分化するには、Azure サポート for nested virtual machinesを参照してください。

専用ホスト

前のセクションで説明した分離ホストに加えて、Azureには専用ホストも用意されています。 Azure Dedicated Hostは、1台以上の仮想マシンをホストでき、単一のAzureサブスクリプションに専用化された物理サーバーを提供するサービスです。 専用サーバーによって、物理サーバー レベルでのハードウェア分離が実現します。 ホストに他の VM は配置されません。 同じデータセンターに専用ホストをデプロイし、他の非分離ホストと同じネットワークと基になるstorage インフラストラクチャを共有します。 詳細については、Azure専用ホストの詳細な概要を参照してください。

ルート VM とゲスト VM の間の Hyper-V とルート OS の分離

Azureのコンピューティング プラットフォームは、マシンの仮想化に基づいています。 すべての顧客コードは、Hyper-V 仮想マシンで実行されます。 各Azure ノード (またはネットワーク エンドポイント) では、ハイパーバイザーがハードウェア経由で直接実行され、ノードが可変数のゲスト virtual machines (VM) に分割されます。

各ノードには、ホスト オペレーティング システムを実行する 1 つの特殊なルート VM もあります。 ハイパーバイザーとルート オペレーティング システムは、ゲスト VM からのルート VM の分離と、ゲスト VM の分離を相互に管理します。 このハイパーバイザーとルートOSの組み合わせは、Microsoftの数十年にわたるOSセキュリティ経験とMicrosoftの Hyper-V からの最近の学びを活かし、ゲストVMの強力な隔離を提供します。

Azure プラットフォームでは、仮想化された環境が使用されます。 ユーザー インスタンスは、物理ホスト サーバーにアクセスを持たないスタンドアロンの仮想マシンとして動作します。

Azureハイパーバイザーはマイクロカーネルのように機能します。 ゲスト仮想マシンからのすべてのハードウェア アクセス要求をホストに渡し、VM Bus と呼ばれる共有メモリ インターフェイスを使用して処理します。 このアーキテクチャにより、ユーザーがシステムに対して生の読み取り、書き込み、または実行accessを取得できなくなり、システム リソースを共有するリスクが軽減されます。

高度なVM配置アルゴリズムとサイドチャネル攻撃からの保護

すべてのクロスVM攻撃には2つのステップがあります。攻撃者制御のVMを被害者のVMと同じホストに配置し、その後隔離境界を突破して機密性の高い被害者情報を盗んだり、リソースの盗難や妨害のためにパフォーマンスに影響を与えたりします。 Microsoft Azure は、高度な VM 配置アルゴリズムと、ノイズの多い近隣 VM を含むすべての既知のサイド チャネル攻撃からの保護を使用して、両方の手順で保護を提供します。

Azure ファブリック コントローラー

Azureファブリック コントローラーは、インフラストラクチャ リソースをテナント ワークロードに割り当て、ホストからvirtual machinesへの一方向の通信を管理します。 VM配置アルゴリズムは非常に高度で、物理ホストレベルで予測することはほぼ不可能です。

Azureでは、ルート VM は、ファブリック エージェント (FA) をホストするルート OS と呼ばれる強化されたオペレーティング システムを実行します。 FA は、顧客の VM 上のゲスト オペレーティング システム内のゲスト エージェント (GA) を管理し、storageノードも管理します。

Azure ハイパーバイザー、ルート OS/FA、および顧客の VM/CA のコレクションは、コンピューティング ノードで構成されます。 ファブリック コントローラー (FC) は FA を管理する。 FC は、コンピューティング ノードとstorage ノードの外部に存在します。 個別の VC がコンピューティングクラスターとstorage クラスターを管理します。 お客様がアプリケーションの実行中にアプリケーションの構成ファイルを更新すると、FC は FA と通信します。 FA は、構成の変更をアプリケーションに通知する GA に連絡します。 ハードウェア障害が発生した場合、FC は使用可能なハードウェアを自動的に検出し、そこで VM を再起動します。

ファブリックコントローラからエージェントへの通信は一方向です。 エージェントは、コントローラーからの要求のみに応答する、SSL で保護されたサービスを実装します。 エージェントはコントローラーや他の特権的な内部ノードへの接続を開始することはできません。 FC は、すべての応答を信頼できないものとして扱います。

分離はルート VM からゲスト VM に及び、ゲスト VM 間にも広がります。 コンピューティング ノードは、保護を強化するために、storage ノードからも分離されます。

ハイパーバイザーとホスト OS は、ネットワーク パケット フィルターを提供します。 これらのフィルターは、信頼されていないvirtual machinesがスプーフィングされたトラフィックを生成したり、それらに対処されていないトラフィックを受信したりできないようにするのに役立ちます。 保護されたインフラストラクチャ エンドポイントにトラフィックを転送し、不適切なブロードキャスト トラフィックの送受信を防止します。

ファブリックコントローラエージェントによってVMを分離するために設定されたその他のルール

デフォルトでは、Azureは仮想マシンを作成するとすべてのトラフィックをブロックします。 次に、ファブリック コントローラー エージェントは、承認されたトラフィックを許可する規則と例外を追加するようにパケット フィルターを構成します。

ファブリックコントローラエージェントは、2つのルールカテゴリをプログラムします:

• マシン構成またはインフラストラクチャルール:デフォルトでは、Azureはすべての通信をブロックします。 例外を追加して、仮想マシンが DHCP および DNS トラフィックを送受信できるようにします。 Virtual machinesは、"パブリック" インターネットにトラフィックを送信し、同じAzure Virtual Networkと OS アクティブ化サーバー内の他のvirtual machinesにトラフィックを送信することもできます。 仮想マシンの許可された送信先のリストには、Azureルーターのサブネット、Azure管理、その他のMicrosoftプロパティは含まれていません。
• Role 構成ファイル: このファイルは、テナントのサービスモデルに基づいて受信アクセス コントロールリスト (ACL) を定義します。

VLAN の分離

各クラスターには、次の 3 つの VLAN が含まれています。

• メインVLAN:信頼できない顧客ノードを相互接続します。
• FC VLAN:信頼されたFCおよびサポートシステムを含みます。
• デバイスVLAN:信頼されたネットワークおよびその他のインフラ機器を含みます。

FC VLANはメインVLANと通信できますが、メインVLANはFC VLANとの通信を開始することはできません。 メインVLANもデバイスのVLANと通信できません。 このVLANアーキテクチャにより、顧客コードを実行するノードが侵害されても、FCやデバイスVLAN上のノードを攻撃できないことが保証されます。

ストレージの分離

コンピューティングとstorage間の論理的な分離

Microsoft Azure は、基本的な設計の一環として、VM ベースの計算をstorageから分離します。 この設計により、計算とストレージが独立してスケールでき、マルチテナンシーや隔離の提供が容易になります。

そのため、Azure Storageは、論理接続を除き、Azure Compute へのネットワーク接続なしで個別のハードウェア上で実行されます。 このストレージ設計では、仮想ディスクを作成する際に、システムはその全容量分のディスク領域を確保しません。 代わりに、仮想ディスク上のアドレスを物理ディスク上の領域にマップするテーブルが作成されます。 このテーブルは最初は空です。 仮想ディスクにデータを初めて書き込む場合、システムは物理ディスク上の領域を割り当て、そのディスクへのポインターをテーブルに配置します。

storage access controlを使用した分離

Azure Storageのアクセス制御は、単純なアクセス制御モデルを使用します。 各Azure サブスクリプションでは、1 つ以上のstorage アカウントを作成できます。 各storage アカウントには、そのstorage アカウント内のすべてのデータに対するaccessを制御するために使用する 1 つの秘密鍵があります。

Azure Storage データ (Tablesを含む) へのアクセスは、スコープを指定してアクセス権を付与する SAS (Shared Access Signature) トークンを使用して制御することができます。 クエリ テンプレート (URL) を使用して SAS を作成し、SAK (Storage アカウント キー) で署名します。 署名済みのURLを別のプロセス(委任)に渡すことができます。 その後、委任されたプロセスでクエリの詳細を入力し、storage サービスの要求を行うことができます。 SAS を使用すると、storage アカウントの秘密鍵を明らかにすることなく、時間ベースのaccessをクライアントに付与できます。

SASでは、クライアントにストレージアカウント内のオブジェクトに対して、一定期間および特定の権限セットに限定的な権限を与えることができます。 アカウントaccessキーを共有することなく、これらの制限付きアクセス許可を付与します。

IPレベルのストレージ隔離

ファイアウォールを設定し、信頼されたクライアントの IP アドレス範囲を定義できます。 IP アドレス範囲を使用すると、定義された範囲内の IP アドレスを持つクライアントのみが Azure Storage に接続できます。

IPストレージに専用のトンネルを割り当てるネットワーク機構を使い、未承認ユーザーからIPストレージデータを保護しましょう。

暗号化

Azureでは、データを保護するために次の種類の暗号化が提供されます。

• 転送中の暗号化
• 保存時の暗号化

転送中の暗号化

転送中の暗号化は、ネットワーク経由でデータが送信されるときにデータを保護します。 Azure Storageを使用すると、次の方法でデータをセキュリティで保護できます。

• Transport レベルの暗号化 (Azure Storageにデータを転送するときに HTTPS など)。
• Azure ファイル共有の SMB 3.0 暗号化など、Wire 暗号化。
• Client 側の暗号化。データがstorageに転送される前にデータを暗号化し、storageから転送された後でデータを復号化します。

保存時の暗号化

多くの組織にとって、静止データ暗号化はデータプライバシー、コンプライアンス、データ主権に向けた必須のステップです。 保存データの暗号化を提供するAzure機能は次のとおりです。

• ストレージサービスの暗号化は、データをAzure Storageに書き込む際に自動的に暗号化します。
• クライアント側暗号化 は、データをストレージに転送する前に暗号化します。
• ホストでの暗号化は、VM データのエンドツーエンドの暗号化を提供します。

ホストでの暗号化

ホストでの暗号化は、VM ホスト レベルでデータを暗号化することで、VM データのエンドツーエンドの暗号化を提供します。 既定ではプラットフォーム マネージド キーが使用されますが、必要に応じて、Azure Key Vault または Azure Key Vault Managed HSM に格納されているカスタマー マネージド キーを使用できます。

ホストでの暗号化は、FIPS 140-2 に準拠している AES 256 暗号化を使用して、VM ホスト レベルでサーバー側の暗号化を提供します。 この暗号化は、VM CPU リソースを使用せずに行われ、次の場合にエンドツーエンドの暗号化が提供されます。

• 一時ディスク
• OS とデータ ディスクのキャッシュ
• Azure Storageへのデータ フロー

ホストでの暗号化の主な利点:

• パフォーマンスへの影響なし:暗号化はVMのCPUリソースを使わずにホストレベルで行われます。
• 幅広いVMサポート:ほとんどのVMシリーズとサイズでサポートされています。
• Customer-managed keys:鍵管理のためのAzure Key VaultまたはManaged HSMとのオプション統合。
• プラットフォーム管理鍵はデフォルトで使用:暗号化に追加の設定は不要です。

詳細については、「ホストでの暗号化とマネージド ディスク暗号化オプションの概要を参照してください。

SQL Database の分離

Azure SQL Databaseは、Microsoft SQL Serverエンジンを基に構築されたクラウドベースのリレーショナルデータベースサービスです。 Azure SQL Databaseは、アカウント、地理、地域、ネットワークレベルで予測可能なデータ分離を備えた、非常に利用可能でスケーラブルなマルチテナントデータベースサービスです。 このサービスは、ほぼ管理不要でこのデータベース隔離を提供します。

SQL Database アプリケーション モデル

アプリケーションの観点から見ると、SQL Database には次の階層が用意されています。各レベルには、以下のレベルの 1 対多の包含があります。

アカウントとサブスクリプションは、課金と管理を関連付ける Microsoft Azure プラットフォームの概念です。

論理SQLサーバーとデータベースは、SQLデータベース固有の概念です。 管理はSQL Databaseが提供するODataおよびT-SQLインターフェース、またはAzureポータルを使って行います。

SQL Database内のサーバーは物理的なインスタンスでもVMでもありません。 代わりに、管理やセキュリティポリシーを共有するデータベースの集合体であり、いわゆる論理マスターデータベースに保存されています。

論理マスター データベースには以下が含まれます。

• サーバーへの接続に使用される SQL ログイン
• ファイアウォール規則

同じサーバーのデータベースの請求や使用情報が、必ずしも同じ物理インスタンスに存在するわけではありません。 アプリケーションは接続時にターゲットデータベース名を指定しなければなりません。

あなたの視点では、地理的なリージョンにサーバーを作成しますが、Azureはそのリージョン内のクラスタの一つにサーバーを作成します。

ネットワーク トポロジによる分離

サーバーを作成しDNS名を登録すると、そのDNS名はサーバーを設置する特定のデータセンターの Gateway VIP アドレスを指しています。

VIP (仮想 IP アドレス) の背後には、ステートレス ゲートウェイ サービスのコレクションがあります。 一般に、ゲートウェイは、複数のデータ ソース (マスター データベース、ユーザー データベースなど) 間の調整が必要な場合に関係します。 ゲートウェイ サービスは、次の機能を実装します。

• TDS 接続のプロキシ化。 この関数には、バックエンド クラスター内のユーザー データベースの検索、認証シーケンスの実装、バックエンドとバックエンドへの TDS パケットの転送が含まれます。
• データベースの管理。 この関数には、CREATE、ALTER、DROP データベース操作を処理するワークフローのコレクションの実装が含まれます。 サービスはTDSパケットのスニッフィングや明示的なOData APIのいずれかによってデータベース操作を呼び出すことができます。
• CREATE、ALTER、DROP 認証とユーザー操作
• OData API を使用したサーバー管理操作

ゲートウェイの背後にある層は バックエンドと呼ばれます。 バックエンド層はすべてのデータを高可用性で保存します。 各データは パーティション または フェールオーバー ユニットに属し、各パーティションには少なくとも 3 つのレプリカがあります。 SQL Server エンジンはレプリカを格納およびレプリケートし、フェールオーバー システムは多くの場合、fabric と呼ばれるシステムがそれらを管理します。

一般に、バックエンド システムは、セキュリティ上の理由から他のシステムへのアウトバウンド通信を行いません。 Azureはフロントエンド(ゲートウェイ)層のシステムへのアウトバウンド通信を予約しています。 ゲートウェイ層マシンはバックエンドマシンに対して限定的な権限を持っています。 この制約は、防御の深層メカニズムとして攻撃面を最小化します。

マシン機能とアクセスによる分離

SQLデータベースは、異なるマシン関数上で動作するサービスで構成されています。 SQL Databaseはこれらのサービスを バックエンド のクラウドデータベースと フロントエンド のゲートウェイおよび管理環境に分けており、一般的な原則としてトラフィックはバックエンドにのみ送られ、外部には流れません。フロントエンド環境は他のサービスの外部と通信でき、一般的にバックエンドでの権限は限定的(呼び出すためのエントリポイントを呼び出す程度)しか持たない。

ネットワークの分離

Azureの展開には複数のネットワーク隔離層があります。 以下の図は、Azureが提供するさまざまなネットワーク分離層を示しています。 これらの層には、ネイティブのAzureプラットフォーム機能や顧客定義の機能が含まれます。 インターネットからの受信では、Azure DDoS protectionはAzureに対する大規模な攻撃に対する分離を提供します。 次の分離レイヤーは、顧客が定義したパブリック IP アドレス (エンドポイント) です。これは、クラウド サービスを経由してvirtual networkに通過できるトラフィックを決定するために使用します。 ネイティブのAzure仮想ネットワーク隔離により、他のすべてのネットワークから完全に隔離されます。 トラフィックはユーザーが設定した経路やメソッドのみを経由して流れます。 これらの経路や手法は次の層であり、NSG、UDR、ネットワーク仮想アプライアンスを使って保護されたネットワーク内のアプリケーション展開を保護するための隔離境界を作成できます。

Traffic isolation:virtual network は、Azure プラットフォーム上のトラフィック分離境界です。 1 つのvirtual network内の Virtual machines (VM) は、両方の仮想ネットワークが同じ顧客によって作成されている場合でも、別のvirtual network内の VM と直接通信することはできません。 隔離は、仮想ネットワーク内で顧客のVMや通信がプライベートなままであることを保証する重要な特性です。

サブネットは IP範囲に基づく仮想ネットワーク内の別の隔離層を提供します。 virtual networkを複数のサブネットに分割して、組織とセキュリティを確保できます。 virtual network内のサブネット (同じまたは異なる) にデプロイされた VM と PaaS ロール インスタンスは、追加の構成なしで相互に通信できます。 また、セキュリティ規則に基づいて VM インスタンスへのネットワーク トラフィックを許可または拒否するようにネットワーク セキュリティ グループ (NSG) を構成することもできます。 NSG は、VM に接続されているサブネットまたは個々のネットワーク インターフェイスに関連付けることができます。 NSG をサブネットに関連付けると、そのサブネット内のすべての VM インスタンスにセキュリティ規則が適用されます。

次のステップ

• ネットワーク セキュリティ グループについて学びます。 ネットワーク セキュリティ グループは、virtual network内Azureリソース間のネットワーク トラフィックをフィルター処理します。 セキュリティ規則を使用して、送信元、宛先、ポート、プロトコルに基づいて、サブネットまたはvirtual machinesへのトラフィックを制限できます。

• Azure での仮想マシンの分離について学ぶ。 Azure コンピューティングでは、特定の種類のハードウェアに分離され、1 人の顧客専用の仮想マシン サイズが提供されます。