Azure Public Cloud での分離

Azure を使用すると、共有物理インフラストラクチャでアプリケーションと仮想マシン (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 ディレクトリのユーザーや管理者が、別のディレクトリ内のデータに誤って、または悪意を持ってアクセスすることはできません。

Azure テナント

Azure テナント (Azure サブスクリプション) は、"顧客/課金" の関係と、Microsoft Entra ID 内の一意のテナントを示します。 Microsoft Azure でのテナント レベルの分離は、Microsoft Entra ID と、それによって提供される Azure ロールベースのアクセス制御を使用して実現されます。 各 Azure サブスクリプションは、1 つの Microsoft Entra ディレクトリに関連付けられています。

そのディレクトリに登録されたユーザー、グループ、およびアプリケーションのみが、Azure サブスクリプションでリソースを管理できます。 このためのアクセス権は、Azure ポータル、Azure コマンドライン ツール、および Azure 管理 API を使用して割り当てることができます。 Microsoft Entra テナントは、どの顧客も (悪意を持って、あるいは誤って) 共同テナントにアクセスしたり進入したりできないように、セキュリティ境界を使用して論理的に分離されています。 Microsoft Entra ID は、隔離されたネットワーク セグメントに分離された "ベア メタル" サーバーで実行されます。ここでは、ホスト レベルのパケット フィルタリングと Windows ファイアウォールによって、望ましくない接続やトラフィックがブロックされます。

• Microsoft Entra ID 内のデータへのアクセスには、セキュリティ トークン サービス (STS) によるユーザー認証が必要です。 承認システムでは、ユーザーの存在、有効状態、ロールに関する情報を使用して、ターゲット テナントへのアクセス要求を当該セッションの当該ユーザーに対して承認するかどうかを決定します。

• テナントは個別のコンテナーであり、これらの間に関係はありません。

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

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

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

診断と保守のニーズのため、Just-In-Time 特権昇格システムを採用している運用モデルを使用する必要があります。 Microsoft Entra Privileged Identity Management (PIM) によって、臨時管理者の概念が導入されています。管理者候補とは、常にではなく時折特権アクセスを必要とするユーザーのことです。 このロールは、このユーザーがアクセス権を必要とするまで非アクティブ化されています。そして、ユーザーがアクティブ化プロセスを完了すると、所定の時間の間だけ有効な管理者になります。

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

テナント コンテナーの概念は、ポータルから永続的ストレージまですべてのレイヤーでディレクトリ サービスと密接に関連しています。

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

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

Azure ロールベースのアクセス制御 (Azure RBAC) では、Azure のきめ細かいアクセス管理が提供され、Azure サブスクリプションで使用可能なさまざまなコンポーネントの共有に役立ちます。 Azure RBAC を使用すると、組織内での仕事を切り分けて、ユーザーが業務を遂行するために必要な操作に基づいてアクセス権を付与できます。 すべてのユーザーに Azure サブスクリプションまたはリソースで無制限のアクセス許可を付与するのではなく、特定の操作のみを許可することができます。

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

• 所有者 は、他のユーザーへアクセス権を委任する権限を含め、すべてのリソースへのフル アクセス権を持ちます。

• 共同作成者 は、Azure リソースのすべてのタイプを作成および管理できますが、他のユーザーへアクセス権を付与することはできません。

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

Azure の残りの Azure ロールでは、特定の Azure リソースの管理が許可されます。 たとえば、仮想マシンの共同作成者ロールが割り当てられたユーザーには、仮想マシンの作成と管理が許可されます。 その仮想マシンが接続する Azure Virtual Network やサブネットへのアクセス権は許可されません。

「Azure 組み込みのロール」に、Azure で使用できる RBAC ロールが記載されています。 各組み込みロールによってユーザーに付与される操作とスコープが説明されています。 制御を強化するために独自のロールを定義する場合は、 Azure RBAC でカスタム ロールを作成する方法を参照してください。

Microsoft Entra ID のその他のいくつかの機能として、次のものがあります。

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

• Azure Storage のデータへのアクセスは、認証によって制御されます。 各ストレージ アカウントには、プライマリ キー (ストレージ アカウント キー (SAK)) とセカンダリ秘密キー (Shared Access Signature (SAS)) があります。

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

• Microsoft Entra 多要素認証では、ユーザーがモバイル アプリ、通話、またはテキスト メッセージを使用してサインインを検証する必要があります。 これを Microsoft Entra ID と共に使用すると、Multi-Factor Authentication Server でオンプレミス リソースをセキュリティ保護するのに役立ちます。また、SDK を使用するカスタム アプリケーションやディレクトリで使用することもできます。

• Microsoft Entra Domain Services を使用すると、ドメイン コントローラーをデプロイすることなく、Azure 仮想マシンを Active Directory ドメインに参加させることができます。 ユーザーは会社の Active Directory 資格情報を使用してこれらの仮想マシンにサインインし、グループ ポリシーによってすべての Azure 仮想マシンにセキュリティ基準を適用することで、ドメインに参加している仮想マシンを管理できます。

• Azure Active Directory B2C は、数億個の ID を扱うコンシューマー向けアプリケーション用の高可用性グローバル ID 管理サービスを提供します。 モバイルと Web の両方のプラットフォームにわたる統合を実現できます。 コンシューマーは、既に持っているソーシャル アカウントを使用するか、資格情報を作成して、すべてのアプリケーションにサインインできます。その場合のエクスペリエンスは、カスタマイズすることができます。

Microsoft 管理者およびデータ削除からの分離

マイクロソフトは、許可されていない人物による不適切なアクセスや使用からデータを保護するために強硬な手段を取ります。 このような運用プロセスと管理は、データへのアクセスを管理する契約責任を提供するオンライン サービス条件によって裏付けされます。

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

ISO/IEC 27001 など監査済み認証を備えたビジネス サービスは、マイクロソフトおよび認可された監査機関によって定期的に検証されます。これらは、サンプル監査を実行して、正当なビジネスの目的のみでアクセスが行われていることを証明します。 自らの顧客データにはいつでもどのような理由でもアクセスできます。

お客様がデータを削除すると、Microsoft Azure によって、キャッシュされたデータやバックアップ コピーも含めて、データが削除されます。 対象サービスでは、この削除はリテンション期間終了後 90 日以内に行われます (対象サービスは、オンライン サービス条件の「データ処理条件」セクションで定義されています)。

格納のために使用されているディスク ドライブでハードウェア障害が発生した場合は、Microsoft が交換または修理のために製造元に返す前に、そのディスク ドライブは確実に消去または破棄されます。 そのドライブ上のデータは、どのような手段でも回復できないように上書きされます。

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

Microsoft Azure ではクラウドベースのコンピューティング サービスが提供されます。これには、アプリケーションまたはエンタープライスのニーズを満たすために自動的にスケールアップとスケールダウンを行うことができる、コンピューティング インスタンスとサービスの多様な選択肢が含まれます。 これらのコンピューティング インスタンスおよびサービスでは、複数のレベルで分離が提供され、お客様が求める構成の柔軟性を損なわずにデータを保護することができます。

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

Azure Compute では、特定のハードウェアの種類に分離される、単一顧客専用の仮想マシン サイズを提供します。 分離されたサイズは、特定のハードウェア世代上に存続して動作し、そのハードウェア世代が廃止される、または新しいハードウェア世代が利用可能になると非推奨となります。

分離された仮想マシン サイズは、他の顧客のワークロードからの高いレベルの分離を必要とするワークロードに最適です。 これは、コンプライアンスと規制の要件を満たすために必要になる場合があります。 分離されたサイズを利用することで、お使いの仮想マシンがその特定のサーバー インスタンス上で実行されている唯一のマシンであることが保証されます。

お客様は、入れ子になった仮想マシンの 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_M128ms

Note

分離された VM サイズは、ハードウェアの廃止により有効期間が制限されます。

分離された VM サイズの非推奨化

分離された VM サイズには、ハードウェアによって限定される有効期間があります。 そのサイズの正式な廃止日の 12 か月前に Azure からリマインダーを出し、お客様の検討用に、更新された分離オファリングを提供します。 次のサイズは廃止が発表されました。

サイズ	分離の廃止日
Standard_DS15_v2	2021 年 5 月 15 日
Standard_D15_v2	2021 年 5 月 15 日
Standard_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 日

よく寄せられる質問

Q:廃止される予定なのはサイズですか、それともその "分離" 機能のみですか?

A: 分離として公開されているが、VM サイズの分離機能を示す "i" が名前に含まれていないサイズは、別途通知されない限り廃止されます。 名前に "i" を含むサイズは非推奨になります。

Q: 分離されていないハードウェアに VM がある場合、ダウンタイムは発生しますか?

A: 分離のみが非推奨になり、サイズは非推奨にならない VM サイズの場合、アクションは必要なく、ダウンタイムも発生しません。 分離が必要な場合とは対照的に、発表には推奨される置換サイズが含まれます。 置換サイズを選択するには、お客様による VM のサイズ変更が必要です。

Q: 分離されていない仮想マシンに移行する場合、コスト差分がありますか?

A: いいえ

Q:他の分離されたサイズはいつ廃止される予定ですか?

A: 分離されたサイズが正式に非推奨となる 12 か月前に通知が送付されます。 最新の発表には、Standard_G5、Standard_GS5、Standard_E64i_v3、および Standard_E64i_v3 の分離機能の提供が含まれています。

Q:シルバーまたはゴールドの持続性層を利用している Azure Service Fabric ユーザーです。 この変更の影響はありますか?

A: いいえ。 Service Fabric の持続性層で提供されている保証は、この変更の後も引き続き機能します。 その他の理由で物理的なハードウェアの分離が必要な場合、上記のいずれかのアクションを実行する必要があります。

Q:D15_v2 や DS15_v2 の分離に関する廃止のマイルストーンはどのようになっていますか?

A:

Date	アクション
2020 年 5 月 15 日1	D/DS15_v2 分離の提供終了に関するお知らせ
2021 年 5 月 15 日	D/DS15_v2 分離保証が削除されます

¹ これらのサイズを使用している既存のお客様には、次の手順に関する詳細な手順が記載されたお知らせのメールが届きます。

Q: G5、Gs5、E64i_v3 および E64is_v3 分離の廃止のマイルストーンはどのようなものですか?

A:

Date	アクション
2021 年 2 月 15 日1	G5/GS5/E64i_v3/E64is_v3 分離の提供終了に関するお知らせ
2022 年 2 月 28 日	G5/GS5/E64i_v3/E64is_v3 分離保証が削除されます

¹ これらのサイズを使用している既存のお客様には、次の手順に関する詳細な手順が記載されたお知らせのメールが届きます。

次のステップ

お客様は、入れ子になった仮想マシンの Azure サポートを使用して、これらの分離された仮想マシンのリソースをさらに分割することもできます。

専用ホスト

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

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

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

また、各ノードには 1 つの特別なルート VM があり、ホスト OS を実行しています。 重要な境界は、ルート VM とゲスト VM の分離と、ハイパーバイザーとルート OS によって管理される各ゲスト VM の分離です。 ハイパーバイザー/ルート OS のペアは、Microsoft のオペレーティング システム セキュリティに関する数十年の経験と、Microsoft Hyper-V の最近の研究を活用したものであり、ゲスト VM の強力な分離を提供します。

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

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

高度な VM 配置アルゴリズムとサイド チャネル攻撃に対する保護

すべてのクロス VM 攻撃には 2 つの段階があります。標的となる VM の 1 つと同じホストに敵が制御する VM を配置します。その後、分離境界に侵入して、標的の機密情報を盗んだり、利益や迷惑行為を目的としてパフォーマンスに悪影響を及ぼしたりします。 Microsoft Azure では、高度な VM 配置アルゴリズムや、既知のすべてのサイド チャネル攻撃の対策 (ノイズの多い VM を近くに置く方法など) を使用して、両方の段階を保護します。

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

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

Azure ハイパーバイザーは、仮想マシン間のメモリおよびプロセスの分離を強制し、ネットワーク トラフィックをゲスト OS テナントに安全にルーティングします。 これにより、VM レベルでのサイド チャネル攻撃の可能性がなくなります。

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

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

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

分離は、ルート VM とゲスト VM の分離や各ゲスト VM の分離だけでなく、さらに拡大します。 コンピューティング ノードを記憶域ノードから分離すると、保護が強化されます。

ハイパーバイザーとホスト OS は、ネットワーク パケット フィルターを提供します。これによって、信頼されていない仮想マシンによる、なりすましトラフィックの生成、アドレスが指定されていないトラフィックの受け取り、保護されたインフラストラクチャ エンドポイントへのトラフィックの転送、不適切なブロードキャスト トラフィックの送信/受信が行われないようにすることができます。

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

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

プログラムされるルールには、次の 2 つのカテゴリがあります。

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

VLAN の分離

各クラスターには、次の 3 つの VLAN があります。

• メイン VLAN – 信頼されていない顧客ノードを相互接続します。
• FC VLAN – 信頼されている FC やサポート システムが含まれています。
• デバイス VLAN – 信頼されているネットワークおよびその他のインフラストラクチャ デバイスが含まれています。

通信が許可されているのは、FC VLAN からメイン VLAN です。メイン VLAN から FC VLAN に対して通信を開始することはできません。 メイン VLAN からデバイス VLAN への通信もブロックされます。 これにより、顧客ノードを実行するノードが侵入された場合でも、FC VLAN またはデバイス VLAN 上のノードを攻撃することはできません。

記憶域の分離

コンピューティングと記憶域の論理的な分離

Microsoft Azure では、基本設計において VM ベースのコンピューティングを記憶域と切り離しています。 このように分けることで、コンピューティングと記憶域を個別に拡張することができ、マルチテナント機能と分離を容易に提供できます。

したがって、Azure Storage は別のハードウェアで稼働し、Azure コンピューティングとのネットワーク接続はありません (論理的な接続のみ)。 つまり、仮想ディスクが作成されたとき、その容量全体にディスク領域は割り当てられません。 代わりに、仮想ディスク上のアドレスを物理ディスク上の領域にマップするテーブルが作成されます。このテーブルは最初は空です。 顧客が初めて仮想ディスクにデータを書き込むと、物理ディスク上の領域が割り当てられ、そこへのポインターがテーブル内に配置されます。

記憶域アクセス制御を使用する分離

Azure Storage のAccess Control のアクセス制御モデルは単純です。 ストレージ アカウントは、各 Azure サブスクリプションにつき 1 つまたは複数作成できます。 各ストレージ アカウントには、そのストレージ アカウント内のすべてのデータへのアクセスを制御するために使用される 1 つの秘密鍵があります。

Azure Storage データ (テーブルを含む) へのアクセスは、スコープ アクセスを付与する SAS (Shared Access Signature) トークンを介して制御できます。 SAS は、クエリ テンプレート (URL) を使用して作成され、SAK (ストレージ アカウント キー) で署名されます。 この署名付き URL は他のプロセスに与えることができます (委任)。そのプロセスがクエリの詳細を設定し、記憶域サービスの要求を作成できます。 SAS を使用すると、ストレージ アカウントの秘密キーを公開せずに、時間ベースのアクセス権をクライアントに付与することができます。

SAS により、ストレージ アカウントのオブジェクトへの制限付きアクセス許可を、期間とアクセス許可セットを指定してクライアントに付与できます。 この制限付きアクセス許可を付与するとき、アカウント アクセス キーを共有する必要はありません。

IP レベルでの記憶域の分離

ファイアウォールを設定し、信頼されたクライアントの IP アドレス範囲を定義できます。 IP アドレス範囲が定義されていると、IP アドレスがその範囲に該当するクライアントだけが Azure Storage に接続できます。

IP ストレージ データは、IP ストレージにトラフィックの専用トンネルを割り当てるために使用されるネットワーク メカニズムを使用して、認可されていないユーザーから保護できます。

暗号化

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

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

転送中の暗号化

転送中の暗号化は、ネットワーク間でデータを転送するときにデータを保護するメカニズムです。 Azure Storage では、以下を使用してデータをセキュリティ保護できます。

• トランスポートレベルの暗号化(Azure Storage の内外にデータを転送する場合の HTTPS など)。
• ワイヤ暗号化 (Azure ファイル共有の SMB 3.0 暗号化など)。
• クライアント側暗号化。データをストレージへの転送の前に暗号化したり、データをストレージからの転送の後に暗号化解除したりするため。

保存時の暗号化

多くの組織にとって、データ プライバシー、コンプライアンス、データ主権を確保するうえで 保存データの暗号化 は欠かせません。 "保存時" のデータの暗号化を提供する Azure 機能には、次の 3 つがあります。

• Storage Service Encryption を使用すると、ストレージ サービスが Azure Storage にデータを書き込むときに自動的に暗号化するように要求できます。
• クライアント側の暗号化 には、保存時の暗号化機能もあります。
• Linux VM に対する Azure Disk Encryption および Windows VM 用の Azure Disk Encryption

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

Azure Disk Encryption

Linux VM に対する Azure Disk Encryption および Windows VM 用の Azure Disk Encryption は、Azure Key Vault で管理するキーとポリシーを使用して VM ディスク (ブート ディスクとデータ ディスクを含む) を暗号化するソリューションです。組織のセキュリティとコンプライアンスの要件に対処する際に大きな効果を発揮します。

Windows 向けの Disk Encryption ソリューションのベースは Microsoft BitLocker ドライブ暗号化であり、Linux 向けソリューションは dm-crypt がベースになっています。

このソリューションでは、Microsoft Azure で IaaS VM が有効になっている場合、IaaS VM の以下のシナリオがサポートされます。

• Azure Key Vault との統合
• Standard レベルの VM: A、D、DS、G、GS などの IaaS VM シリーズ
• Windows および Linux IaaS VM の暗号化を有効にする
• Windows IaaS VM の OS およびデータ ドライブの暗号化を無効にする
• Linux IaaS VM のデータ ドライブの暗号化を無効にする
• Windows クライアント OS を実行している IaaS VM の暗号化を有効にする
• ボリュームのマウント パスの暗号化を有効にする
• mdadm を使用してディスク ストライピング (RAID) が構成されている Linux VM の暗号化を有効にする
• データ ディスクの LVM (論理ボリューム マネージャー) を使用して Linux VM の暗号化を有効にする
• ストレージ スペースを使用して構成されている Windows VM の暗号化を有効にする
• Azure のすべてのパブリック リージョンがサポートされる

このソリューションのリリースでは、次のシナリオ、機能、テクノロジはサポートされていません。

• Basic レベルの IaaS VM
• Linux IaaS VM の OS ドライブの暗号化を無効にする
• 従来の VM の作成方法を使用して作成された IaaS VM
• オンプレミス キー管理サービスとの統合
• Azure Files (共有ファイル システム)、ネットワーク ファイル システム (NFS)、ダイナミック ボリューム、およびソフトウェアベースの RAID システムで構成されている Windows VM

SQL Database の分離

SQL Database は、市場をリードする Microsoft SQL Server エンジンとミッション クリティカルなワークロードを処理する機能を基盤とする、Microsoft Cloud のリレーショナル データベース サービスです。 SQL Database では、アカウント レベル、地理/リージョン ベース、およびネットワーキング ベースで、予測可能なデータ分離が提供され、いずれも管理はほとんど必要ありません。

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

Microsoft SQL Database は、SQL Server テクノロジに基づいて構築されたクラウドベースのリレーショナル データベース サービスです。 マイクロソフトによってホストされる、スケーラブルな高可用性マルチテナント データベース サービスをクラウドで提供します。

アプリケーションの観点では、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 エンジンによって保存されてレプリケートされ、"ファブリック" と呼ばれるフェールオーバー システムによって管理されます。

一般に、バックエンド システムは、セキュリティ上の予防措置として他のシステムへの送信通信を行いません。 これは、フロントエンド (ゲートウェイ) 層のシステムにまかされます。 高度な防御メカニズムとして、攻撃対象領域を最小限に抑えるため、ゲートウェイ層のマシンがバックエンド マシンに対して持つ権限は制限されます。

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

SQL Database は、さまざまなマシン機能に対して実行されるサービスで構成されています。 SQL Database は "バックエンド" のクラウド データベースと "フロントエンド" (ゲートウェイまたは管理) 環境に分けられ、一般原則としてトラフィックはバックエンドのみに送信され、逆方向はありません。フロントエンド環境は外部の他のサービスと通信できます。通常、バックエンドに対しては限られたアクセス許可 (起動に必要なエントリ ポイントを呼び出すために十分なもの) しかありません。

ネットワークの分離

Azure デプロイでは、複数の層でネットワークの分離を行うことができます。 次の図は、Azure が顧客に提供するさまざまなネットワーク分離の層を示しています。 これらの層は、Azure プラットフォーム自体とユーザー定義機能の両方でネイティブです。 インターネットから受信する場合は、Azure DDoS が Azure に対する大規模な攻撃に対して分離を提供します。 次の分離の層は、顧客が定義したパブリック IP アドレス (エンドポイント) です。これらのエンドポイントは、クラウド サービスを通過して仮想ネットワークに到達できるトラフィックを決定するために使用されます。 ネイティブの Azure Virtual Network の分離により、その他すべてのネットワークから完全に分離されると、そのトラフィックだけが、ユーザーが構成した経路と方法を介して流れます。 これらの経路と方法が次の層となります。次の層では、NSG、UDR、ネットワーク仮想アプライアンスを使用して DMZ などの分離境界を構築し、保護されているネットワークにおけるアプリケーションのデプロイを保護することができます。

トラフィックの分離: 仮想ネットワークは、Azure プラットフォームでのトラフィックの分離境界となります。 ある仮想ネットワーク内の仮想マシン (VM) と別の仮想ネットワーク内の VM は、両方の仮想ネットワークを同じ顧客が作成した場合でも、直接通信することはできません。 分離は、顧客の VM と通信が仮想ネットワーク内でプライベートであることを保証する重要な特性です。

サブネットによって、IP 範囲に基づいて仮想ネットワーク内に分離の層がさらに提供されます。 仮想ネットワーク内の IP アドレスを使用して、仮想ネットワークを組織とセキュリティ用に複数のサブネットに分割することができます。 VNet 内の (同じまたは異なる) サブネットにデプロイした VM と PaaS ロール インスタンスは、追加の構成をしなくても互いに通信できます。 また、ネットワーク セキュリティ グループ (NSG) を構成し、NSG のアクセス制御リスト (ACL) に構成した規則に基づいて VM インスタンスに対するネットワーク トラフィックを許可または禁止することもできます。 NSG は、サブネットまたはそのサブネット内の個々の VM インスタンスと関連付けることができます。 NSG がサブネットに関連付けられている場合、ACL 規則はそのサブネット内のすべての VM インスタンスに適用されます。

次の手順

• Windows Azure Virtual Network 内のマシンのためのネットワーク分離のオプションについて確認します。 これには、従来のフロントエンドとバックエンドのシナリオが含まれます。特定のバックエンド ネットワークまたはサブネットワーク内のマシンでは、IP アドレスの許可リストに基づいて、特定のクライアントまたは他のコンピューターに、特定のエンドポイントへの接続だけを許可できます。

• Azure における仮想マシンの分離性について確認します。 Azure Compute では、特定のハードウェアの種類に分離される、単一顧客専用の仮想マシン サイズを提供します。