Azureでは、共有物理インフラストラクチャでアプリケーションとvirtual machines (VM) を実行できます。 クラウド環境でアプリケーションを実行する主な経済的利点の 1 つは、共有リソースのコストを複数の顧客に分散できることです。 このマルチテナントのプラクティスでは、低コストで異なる顧客間でリソースを多重化することで、効率が向上します。 残念ながら、任意の悪意のあるユーザーに属している可能性のある機密性の高いアプリケーションや VM を実行するために、物理サーバーやその他のインフラストラクチャ リソースを共有するリスクも発生します。
この記事では、Azureが悪意のあるユーザーと悪意のないユーザーの両方に対して分離を提供する方法について説明します。 これは、さまざまな分離の選択肢をアーキテクトに提供することで、クラウド ソリューションを設計するためのガイドとして機能します。
テナント レベルの分離
クラウド コンピューティングの主な利点の 1 つは、多数の顧客間で同時に共有される共通インフラストラクチャの概念であり、規模の経済につながります。 この概念はマルチテナントと呼ばれます。 Microsoft は、Microsoft Cloud Azureのマルチテナント アーキテクチャがセキュリティ、機密性、プライバシー、整合性、可用性の標準をサポートするように継続的に取り組んでいます。
クラウド対応の職場では、テナントは、そのクラウド サービスの特定のインスタンスを所有および管理するクライアントまたは組織です。 Microsoft Azure によって提供される ID プラットフォームを使用することで、テナントは、組織が Microsoft クラウド サービスにサインアップするときに受け取って所有するMicrosoft Entra IDの専用インスタンスです。
各 Microsoft Entra ディレクトリは、他の Microsoft Entra ディレクトリからは独立した個別のものです。 会社のオフィス ビルが組織のみに固有のセキュリティで保護された資産であるのと同様に、Microsoft Entra ディレクトリは組織でのみ使用できるセキュリティで保護された資産です。 Microsoft Entra アーキテクチャは、顧客のデータや ID 情報が混合しないよう分離します。 この設計は、ある Microsoft Entra ディレクトリのユーザーと管理者が、誤ってまたは悪意を持って別のディレクトリにデータをaccessできないことを意味します。
Azure テナント
Azure テナンシー (Azure サブスクリプション) は、顧客および課金に関する関係と、Microsoft Entra ID での一意のテナントに関連しています。 Microsoft Entra IDとAzureロールベースのアクセス制御は、Microsoft Azureでテナントレベルの分離を提供します。 各Azure サブスクリプションは、1 つの Microsoft Entra ディレクトリに関連付けられています。
そのディレクトリのユーザー、グループ、アプリケーションは、Azure サブスクリプション内のリソースを管理できます。 これらのaccess権限は、Azure portal、Azureコマンドライン ツール、および Azure Management API を使用して割り当てることができます。 セキュリティ境界は論理的に Microsoft Entra テナントを分離しているため、悪意あるまたは偶然の共同テナントへのアクセスや侵害を防ぎます。 Microsoft Entra IDは、分離されたネットワーク セグメント上で分離された "ベア メタル" サーバー上で実行されます。ホスト レベルのパケット フィルター処理と Windows ファイアウォールによって、不要な接続とトラフィックがブロックされます。
Microsoft Entra ID内のデータにAccessするには、セキュリティ トークン サービス (STS) によるユーザー認証が必要です。 承認システムは、ユーザーの存在、有効な状態、およびロールに関する情報を使用して、ターゲット テナントに対して要求されたaccessがこのセッションでこのユーザーに対して承認されているかどうかを判断します。
テナントは個別のコンテナーであり、これらのコンテナー間にリレーションシップはありません。
テナント管理者がフェデレーションを通じて、または他のテナントからユーザーアカウントをプロビジョニングすることにより付与した場合を除き、テナント間にアクセスは存在しません。
Microsoft Entra サービスを構成するサーバーへの物理accessと、Microsoft Entra IDのバックエンド システムへの直接accessは制限されます。
Microsoft Entra ユーザーは物理的な資産や場所にaccessがないため、次に示す論理的なAzure RBAC ポリシー チェックをバイパスすることはできません。
診断とメンテナンスのニーズには、Just-In-Time 特権昇格システムを使用する運用モデルを使用します。 Microsoft Entra Privileged Identity Management (PIM) には、対象管理者の概念が導入されています。対象管理者 は、必要に応じて特権アクセスを持つユーザーですが、毎日必要とは限りません。 ロールは、ユーザーがアクセスを必要とするまで非アクティブであり、その後ユーザーはアクティベーションプロセスを完了し、所定の時間アクティブな管理者になります。
Microsoft Entra IDは、テナントによってのみ所有および管理されるコンテナーに対するポリシーとアクセス許可を持つ、独自の保護されたコンテナー内の各テナントをホストします。
テナント コンテナーの概念は、ポータルから永続的なstorageまで、すべてのレイヤーのディレクトリ サービスに深く浸透しています。
複数の Microsoft Entra テナントのメタデータが同じ物理ディスクに格納されている場合でも、ディレクトリ サービスが定義する以外のコンテナー間の関係はなく、テナント管理者によって指示されます。
Azure ロールベースのアクセス制御 (Azure RBAC)
Azureロールベースのaccess control (Azure RBAC) を使用すると、Azureの詳細なaccess管理を提供することで、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 で
Microsoft Entra IDのその他の機能には、次のようなものがあります。
Microsoft Entra IDは、ホストされている場所に関係なく、SaaS アプリケーションへの SSO を有効にします。 Microsoft Entra IDとフェデレーションされているアプリケーションもあれば、パスワード SSO を使用するアプリケーションもあります。 フェデレーション アプリケーションでは、ユーザー プロビジョニングとパスワード保管もサポートできます。
Microsoft Entra IDは、Active Directory Federation Services、同期、オンプレミス ディレクトリとのレプリケーションを使用してフェデレーションを通じてサービスとしての ID を提供します。
Microsoft Entra 多要素認証では、モバイル アプリ、通話、テキスト メッセージを利用してサインインを検証することをユーザーに要求します。 これは、Microsoft Entra IDと共に使用して、Multi-Factor Authentication Server を使用してオンプレミスのリソースをセキュリティで保護するのに役立ちます。また、SDK を使用してカスタム アプリケーションとディレクトリを使用することもできます。
Microsoft Entra Domain Services を使用すると、ドメイン コントローラーを展開せずにAzure virtual machinesをActive Directory domainに参加させることができます。 Group Policyを使用してすべてのAzure virtual machinesにセキュリティ ベースラインを適用することで、企業のActive Directory資格情報を使用してこれらのvirtual machinesにサインインし、ドメインに参加しているvirtual machinesを管理できます。
Microsoft Entra External ID は、数億個の ID にスケーリングされるconsumer向けのアプリケーション用の高可用性グローバル ID 管理サービスを提供します。 モバイルと Web の両方のプラットフォームにわたる統合を実現できます。 コンシューマーは、既に持っているソーシャル アカウントを使用するか、資格情報を作成して、すべてのアプリケーションにサインインできます。その場合のエクスペリエンスは、カスタマイズすることができます。
Microsoft 管理者からの分離とデータの削除
Microsoft は、不適切なaccessや未承認のユーザーによる使用からお客様のデータを保護するための強力な対策を講じています。 Online Services使用条件は、データへのアクセスを管理し、それらの運用プロセスと制御をサポートする契約上のコミットメントを提供します。
- Microsoft のエンジニアは、クラウド内のデータに対する既定のaccessを持っていません。 代わりに、必要な場合にのみ、管理の監視下でアクセスが付与されます。 そのaccessは慎重に制御され、ログに記録され、不要になったときに取り消されます。
- マイクロソフトは他の会社に委託して限られたサービスを提供することがあります。 下請け業者は、Microsoft が採用したサービスを提供するためにのみ顧客データをaccessすることがあり、他の目的で使用することは禁止されています。 さらに、顧客の情報の機密性を維持するために契約上の義務があります。
Microsoft および認定監査会社は、ISO/IEC 27001 などの監査認定を受けたビジネス サービスを定期的に検証しています。 これらの監査者は、サンプル監査を実行して、accessが正当なビジネス目的のみを目的としていることを証明します。 ご自身の顧客データには、どんな理由でも、いつでもアクセスできます。
データを削除すると、Microsoft Azureは、キャッシュされたコピーやバックアップ コピーを含むデータを削除します。 スコープ内サービスの場合、その削除は保持期間の終了後 90 日以内に行われます。 (Online Services Terms の [データ処理条件] セクションでは、スコープ内サービスが定義されています)。
ストレージに使用されているディスクドライブでハードウェア障害が発生した場合、Microsoftはそのドライブを安全に消去または破棄し、交換または修理のために製造元に返却します。 ドライブ上のデータは上書きされ、どのような手段でもデータを回復できないようにされます。
コンピューティングの分離
Microsoft Azure は、さまざまなクラウドベースのコンピューティング サービスを提供します。これには、アプリケーションまたは企業のニーズを満たすために自動的にスケールアップおよびスケールダウンできるさまざまなコンピューティング インスタンスとサービスが含まれています。 これらのコンピューティング インスタンスとサービスは、顧客が要求する構成の柔軟性を損なうことなく、データをセキュリティで保護するために複数のレベルで分離を提供します。
分離された仮想マシンのサイズ
Azure コンピューティングは、特定の種類のハードウェアに分離され、1 人の顧客専用の仮想マシン サイズを提供します。 分離されたサイズは、特定のハードウェア世代上に存続して動作し、そのハードウェア世代が廃止される、または新しいハードウェア世代が利用可能になると非推奨となります。
分離された仮想マシンのサイズは、他の顧客のワークロードからの高度な分離を必要とするワークロードに最適です。 これは、コンプライアンスと規制の要件を満たすために必要になる場合があります。 分離されたサイズを利用することで、お使いの仮想マシンがその特定のサーバー インスタンス上で実行されている唯一のマシンであることが保証されます。
さらに、分離サイズの VM が大きいため、Azure の入れ子仮想マシンのサポートを使用して、これらの VM のリソースを分割することもできます。
現在の分離された仮想マシンのプランには、以下が含まれます。
- Standard_E80ids_v4
- Standard_E80is_v4
- Standard_E104i_v5
- Standard_E104is_v5
- Standard_E104id_v5
- Standard_E104ids_v5
- Standard_M192is_v2
- Standard_M192ims_v2
- Standard_M192ids_v2
- Standard_M192idms_v2
- Standard_F72s_v2
- Standard_M832ids_16_v3
- Standard_M832is_16_v3
- Standard_M896ixds_24_v3
- Standard_M896ixds_32_v3
- Standard_M1792ixds_32_v3
注
分離された VM サイズは、ハードウェアの廃止により有効期間が制限されます。
分離された VM サイズの非推奨化
分離された VM サイズには、ハードウェアによって限定される有効期間があります。 Azure は、サイズの正式な廃止日の12か月前にリマインダーをお知らせし、検討のために更新されたアイソレート環境を提供します。 次のサイズは廃止が発表されました。
| サイズ | 分離の廃止日 |
|---|---|
| Standard_DS15_v2 | 2021 年 5 月 15 日 |
| Standard_D15_v2 | 2021 年 5 月 15 日 |
| スタンダード_G5 | 2022 年 2 月 15 日 |
| Standard_GS5 | 2022 年 2 月 15 日 |
| Standard_E64i_v3 | 2022 年 2 月 15 日 |
| Standard_E64is_v3 | 2022 年 2 月 15 日 |
| Standard_M192is_v2 | 2027 年 3 月 31 日 |
| Standard_M192ims_v2 | 2027 年 3 月 31 日 |
| Standard_M192ids_v2 | 2027 年 3 月 31 日 |
| Standard_M192idms_v2 | 2027 年 3 月 31 日 |
Azureの入れ子仮想マシンのサポートを使用して、これらの分離仮想マシンのリソースをさらに細分化することもできます。
専用ホスト
前のセクションで説明した分離ホストに加えて、Azureには専用ホストも用意されています。 Azureの専用ホストは、1 つ以上のvirtual machinesをホストできる物理サーバーを提供し、1 つのAzure サブスクリプション専用のサービスです。 専用サーバーによって、物理サーバー レベルでのハードウェア分離が実現します。 ホストに他の VM は配置されません。 同じデータセンターに専用ホストをデプロイし、他の非分離ホストと同じネットワークと基になるstorage インフラストラクチャを共有します。 詳細については、Azure専用ホストの詳細な概要を参照してください。
ルート VM とゲスト VM の間の Hyper-V とルート OS の分離
Azureのコンピューティング プラットフォームは、マシンの仮想化に基づいています。 すべての顧客コードは、Hyper-V 仮想マシンで実行されます。 各Azure ノード (またはネットワーク エンドポイント) では、ハイパーバイザーがハードウェア経由で直接実行され、ノードが可変数のゲスト virtual machines (VM) に分割されます。
各ノードには、ホスト オペレーティング システムを実行する 1 つの特殊なルート VM もあります。 ハイパーバイザーとルート オペレーティング システムは、ゲスト VM からのルート VM の分離と、ゲスト VM の分離を相互に管理します。 このハイパーバイザーとルート オペレーティング システムのペアリングは、Microsoft の数十年にわたるオペレーティング システムのセキュリティ エクスペリエンスと、Microsoft の Hyper-V からのより最近の学習を活用して、ゲスト VM を強力に分離します。
Azure プラットフォームでは、仮想化された環境が使用されます。 ユーザー インスタンスは、物理ホスト サーバーにアクセスを持たないスタンドアロンの仮想マシンとして動作します。
Azureハイパーバイザーはマイクロカーネルのように機能します。 ゲスト仮想マシンからのすべてのハードウェア アクセス要求をホストに渡し、VM Bus と呼ばれる共有メモリ インターフェイスを使用して処理します。 このアーキテクチャにより、ユーザーがシステムに対して生の読み取り、書き込み、または実行accessを取得できなくなり、システム リソースを共有するリスクが軽減されます。
高度な VM 配置アルゴリズムとサイド チャネル攻撃からの保護
すべてのクロス VM 攻撃には 2 つの段階があります。標的となる VM の 1 つと同じホストに敵が制御する 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 を分離するようにファブリック コントローラー エージェントによって構成された追加の規則
既定では、仮想マシンの作成時にすべてのトラフィックがブロックされます。 次に、ファブリック コントローラー エージェントは、承認されたトラフィックを許可する規則と例外を追加するようにパケット フィルターを構成します。
2 つのカテゴリのルールをプログラムします。
- マシン構成またはインフラストラクチャの規則: 既定では、すべての通信がブロックされています。 例外を追加して、仮想マシンが DHCP および DNS トラフィックを送受信できるようにします。 Virtual machinesは、"パブリック" インターネットにトラフィックを送信し、同じAzure Virtual Networkと OS アクティブ化サーバー内の他のvirtual machinesにトラフィックを送信することもできます。 許可される発信先のvirtual machinesの一覧には、Azureルーター サブネット、Azure管理、およびその他の Microsoft プロパティは含まれません。
- Role 構成ファイル: このファイルは、テナントのサービスモデルに基づいて受信アクセス コントロールリスト (ACL) を定義します。
VLAN の分離
各クラスターには、次の 3 つの VLAN が含まれています。
- メイン VLAN – 信頼されていない顧客ノードを相互接続します。
- FC VLAN – 信頼されている FC やサポート システムが含まれています。
- デバイス VLAN – 信頼されているネットワークおよびその他のインフラストラクチャ デバイスが含まれています。
FC VLAN からメイン VLAN への通信は許可されますが、メイン VLAN から FC VLAN への通信を開始することはできません。 メイン VLAN からデバイス VLAN への通信もブロックされます。 このアーキテクチャにより、顧客コードを実行しているノードが侵害された場合でも、FC またはデバイス VLAN のノードを攻撃できなくなります。
ストレージの分離
コンピューティングとstorage間の論理的な分離
Microsoft Azure は、基本的な設計の一環として、VM ベースの計算をstorageから分離します。 この分離により、計算と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 を使用すると、storage アカウント内のオブジェクトに対する制限付きアクセス許可を、指定された一連のアクセス許可を持つ、指定した期間にわたってクライアントに付与できます。 アカウントaccessキーを共有することなく、これらの制限付きアクセス許可を付与します。
IPレベルのストレージ隔離
ファイアウォールを設定し、信頼されたクライアントの IP アドレス範囲を定義できます。 IP アドレス範囲を使用すると、定義された範囲内の IP アドレスを持つクライアントのみが Azure Storage に接続できます。
IP storageにトラフィックの専用トンネルを割り当てるネットワーク メカニズムを使用して、承認されていないユーザーから IP storage データを保護できます。
暗号化
Azureでは、データを保護するために次の種類の暗号化が提供されます。
- 転送中の暗号化
- 保存時の暗号化
転送中の暗号化
転送中の暗号化は、ネットワーク経由でデータが送信されるときにデータを保護します。 Azure Storageを使用すると、次の方法でデータをセキュリティで保護できます。
- Transport レベルの暗号化 (Azure Storageにデータを転送するときに HTTPS など)。
- Azure ファイル共有の SMB 3.0 暗号化など、Wire 暗号化。
- Client 側の暗号化。データがstorageに転送される前にデータを暗号化し、storageから転送された後でデータを復号化します。
保存時の暗号化
多くの組織にとって、データ プライバシー、コンプライアンス、データ主権を確保する上で保存時のデータの暗号化は欠かせません。 保存データの暗号化を提供するAzure機能は次のとおりです。
- Storage Service Encryption はAzure Storageに書き込むときにデータを自動的に暗号化します。
- Client-side Encryption はstorageに転送される前にデータを暗号化します。
- ホストでの暗号化は、VM データのエンドツーエンドの暗号化を提供します。
ホストでの暗号化
Important
Azure Disk Encryptionは、2028 年 15 月 15 日 に提供終了する予定です。 その日まで、中断することなくAzure Disk Encryptionを引き続き使用できます。 2028 年 9 月 15 日に、ADE 対応ワークロードは引き続き実行されますが、暗号化されたディスクは VM の再起動後にロック解除に失敗し、サービスが中断されます。
新しい 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 マネージド キー: キー制御のための Azure Key Vault または Managed HSM とのオプションの統合
- 既定ではプラットフォームで管理されるキー: 暗号化に追加の構成は必要ありません
詳細については、「ホストでの暗号化とマネージド ディスク暗号化オプションの概要を参照してください。
SQL Database の分離
Microsoft SQL Database は、Microsoft SQL Server エンジンに基づいて構築されたクラウドベースのリレーショナル データベース サービスです。 アカウント レベルでの予測可能なデータ分離、地域/リージョン ベース、ネットワーク ベースの可用性と拡張性に優れたマルチテナント データベース サービスを提供し、すべてほぼゼロの管理を実現します。
SQL Database アプリケーション モデル
アプリケーションの観点から見ると、SQL Database には次の階層が用意されています。各レベルには、以下のレベルの 1 対多の包含があります。
アカウントとサブスクリプションは、課金と管理を関連付ける Microsoft Azure プラットフォームの概念です。
論理 SQL サーバーとデータベースは SQL Database 固有の概念であり、SQL Database が提供する OData および TSQL インターフェイス、または Azure portal を使用して管理されます。
SQL Database のサーバーは、物理インスタンスまたは VM インスタンスではなく、管理およびセキュリティ ポリシー ("論理マスター" データベースに格納されている) を共有するデータベースのコレクションです。
論理マスター データベースには以下が含まれます。
- サーバーへの接続に使用される SQL ログイン
- ファイアウォール規則
同じサーバーのデータベースに関する課金と使用状況の情報は、クラスター内の同じ物理インスタンスに存在する保証はありません。代わりにアプリケーションでは、接続時に接続先データベース名を指定する必要があります。
顧客の観点ではサーバーは地理的なリージョンに作成されますが、サーバーの実際の作成はリージョン内のクラスターの 1 つで行われます。
ネットワーク トポロジによる分離
サーバーを作成してその DNS 名を登録すると、DNS 名は、サーバーを配置する特定のデータ センター内のいわゆる ゲートウェイ VIP アドレスを指します。
VIP (仮想 IP アドレス) の背後には、ステートレス ゲートウェイ サービスのコレクションがあります。 一般に、ゲートウェイは、複数のデータ ソース (マスター データベース、ユーザー データベースなど) 間の調整が必要な場合に関係します。 ゲートウェイ サービスは、次の機能を実装します。
- TDS 接続のプロキシ化。 この関数には、バックエンド クラスター内のユーザー データベースの検索、認証シーケンスの実装、バックエンドとバックエンドへの TDS パケットの転送が含まれます。
- データベースの管理。 この関数には、CREATE、ALTER、DROP データベース操作を処理するワークフローのコレクションの実装が含まれます。 データベース操作は、TDS パケットのスニッフィングまたは明示的な OData API によって呼び出すことができます。
- CREATE、ALTER、DROP 認証とユーザー操作
- OData API を使用したサーバー管理操作
ゲートウェイの背後にある層は バックエンドと呼ばれます。 このレベルでは、すべてのデータが高可用性の方法で格納されます。 各データは パーティション または フェールオーバー ユニットに属し、各パーティションには少なくとも 3 つのレプリカがあります。 SQL Server エンジンはレプリカを格納およびレプリケートし、フェールオーバー システムは多くの場合、fabric と呼ばれるシステムがそれらを管理します。
一般に、バックエンド システムは、セキュリティ上の理由から他のシステムへのアウトバウンド通信を行いません。 この通信は、フロントエンド (ゲートウェイ) 層のシステムに予約されています。 ゲートウェイ層のマシンには、多層防御メカニズムとして攻撃surfaceを最小限に抑えるために、バックエンド マシンに対する特権が制限されています。
マシン機能とアクセスによる分離
SQL Database は、さまざまなマシンの機能に対して実行するサービスで構成されます。 SQL Database は バックエンド の Cloud Database と フロントエンド (ゲートウェイ/管理) 環境に分割され、トラフィックの一般的な原則はバックエンドにのみ送信され、送信は行われません。フロントエンド環境は他のサービスの外部と通信でき、一般に、バックエンドのアクセス許可は制限されています (呼び出す必要があるエントリ ポイントを呼び出すには十分です)。
ネットワークの分離
Azureデプロイには、複数のネットワーク分離レイヤーがあります。 次の図は、お客様に提供Azureさまざまなネットワーク分離レイヤーを示しています。 これらのレイヤーには、Azure プラットフォーム自体のネイティブ機能と、顧客が定義した機能の両方が含まれます。 インターネットからの受信では、Azure DDoS protectionはAzureに対する大規模な攻撃に対する分離を提供します。 次の分離レイヤーは、顧客が定義したパブリック IP アドレス (エンドポイント) です。これは、クラウド サービスを経由してvirtual networkに通過できるトラフィックを決定するために使用します。 ネイティブAzure virtual network分離により、他のすべてのネットワークからの完全な分離が保証され、トラフィックはユーザーが構成したパスと方法のみを通過します。 これらの経路と方法が次の層となります。次の層では、NSG、UDR、ネットワーク仮想アプライアンスを使用して DMZ などの分離境界を構築し、保護されているネットワークにおけるアプリケーションのデプロイを保護することができます。
Traffic isolation:virtual network は、Azure プラットフォーム上のトラフィック分離境界です。 1 つのvirtual network内の Virtual machines (VM) は、両方の仮想ネットワークが同じ顧客によって作成されている場合でも、別のvirtual network内の VM と直接通信することはできません。 分離は、お客様の VM と通信がvirtual network内でプライベートなままであることを保証する重要なプロパティです。
Subnet は、IP 範囲に基づいてvirtual network内の分離層を追加します。 virtual networkを複数のサブネットに分割して、組織とセキュリティを確保できます。 virtual network内のサブネット (同じまたは異なる) にデプロイされた VM と PaaS ロール インスタンスは、追加の構成なしで相互に通信できます。 また、セキュリティ規則に基づいて VM インスタンスへのネットワーク トラフィックを許可または拒否するようにネットワーク セキュリティ グループ (NSG) を構成することもできます。 NSG は、VM に接続されているサブネットまたは個々のネットワーク インターフェイスに関連付けることができます。 NSG をサブネットに関連付けると、そのサブネット内のすべての VM インスタンスにセキュリティ規則が適用されます。
次のステップ
ネットワーク セキュリティ グループについて学びます。 ネットワーク セキュリティ グループは、virtual network内Azureリソース間のネットワーク トラフィックをフィルター処理します。 セキュリティ規則を使用して、送信元、宛先、ポート、プロトコルに基づいて、サブネットまたはvirtual machinesへのトラフィックを制限できます。
Azure での仮想マシンの分離について学ぶ。 Azure コンピューティングでは、特定の種類のハードウェアに分離され、1 人の顧客専用の仮想マシン サイズが提供されます。