次の方法で共有


Azure Spring Apps のリファレンス アーキテクチャ

Azure Spring Apps は、Azure Spring Cloud サービスの新しい名前です。 サービスの名前は新しくなりましたが、スクリーンショット、ビデオ、図などの資産の更新に取り組んでいる間、場所によってはしばらく古い名前が表示されます。

この記事の適用対象: ✔️ Standard ✔️ Enterprise

この参照アーキテクチャは、Azure Spring Apps を使用するための一般的なエンタープライズ ハブ アンド スポーク設計を使用した基盤です。 この設計では、Azure Spring Apps は、ハブでホストされている共有サービスに依存する単一のスポークにデプロイされます。 このアーキテクチャは、 Microsoft Azure Well-Architected Framework でテネットを実現するためのコンポーネントを使用して構築されています。

Azure Spring Apps には、Standard プランと Enterprise プランの 2 種類があります。

Azure Spring Apps Standard プランは、Spring Cloud Config Server、Spring Cloud Service Registry、および kpack ビルド サービスで構成されます。

Azure Spring Apps Enterprise プランは、VMware Tanzu® Build Service™、Application Configuration Service for VMware Tanzu®、VMware Tanzu® Service Registry、Spring Cloud Gateway for VMware Tanzu®、および VMware Tanzu® 用 API ポータルで構成されています。

このアーキテクチャの実装については、GitHub の Azure Spring Apps リファレンス アーキテクチャを参照 してください。

このアーキテクチャのデプロイ オプションには、Azure Resource Manager (ARM)、Terraform、Azure CLI、Bicep があります。 このリポジトリ内の成果物は、環境に合わせてカスタマイズできる基盤を提供します。 Azure Firewall や Application Gateway などのリソースを、異なるリソース グループまたはサブスクリプションにグループ化できます。 このグループ化は、IT インフラストラクチャ、セキュリティ、ビジネス アプリケーション チームなど、さまざまな機能を分離するのに役立ちます。

アドレス空間の計画

Azure Spring Apps には、次の 2 つの専用サブネットが必要です。

  • サービス ランタイム
  • Spring Boot アプリケーション

これらの各サブネットには、専用の Azure Spring Apps クラスターが必要です。 複数のクラスターで同じサブネットを共有することはできません。 各サブネットの最小サイズは /28 です。 Azure Spring Apps でサポートできるアプリケーション インスタンスの数は、サブネットのサイズによって異なります。 詳細な仮想ネットワーク要件については、「仮想ネットワークに Azure Spring Apps をデプロイする」の「仮想ネットワーク要件」セクションを参照してください。

警告

選択したサブネット サイズは、既存の仮想ネットワーク アドレス空間と重複することはできません。また、ピアリングされたサブネットまたはオンプレミスのサブネット アドレス範囲と重複しないようにする必要があります。

活用事例

このアーキテクチャの一般的な用途は次のとおりです。

  • プライベート アプリケーション: ハイブリッド クラウド環境にデプロイされた内部アプリケーション
  • パブリック アプリケーション: 外部に接続するアプリケーション

これらのユース ケースは、セキュリティとネットワーク トラフィックの規則を除いて似ています。 このアーキテクチャは、それぞれの微妙な違いをサポートするように設計されています。

プライベート アプリケーション

次の一覧では、プライベート アプリケーションのインフラストラクチャ要件について説明します。 これらの要件は、厳しく規制された環境で一般的です。

  • サブネットには、Azure Spring Apps のインスタンスが 1 つだけ必要です。
  • 少なくとも 1 つのセキュリティ ベンチマークへの準拠を適用する必要があります。
  • アプリケーション ホスト ドメイン ネーム サービス (DNS) レコードは、Azure プライベート DNS に格納する必要があります。
  • Azure サービスの依存関係は、サービス エンドポイントまたは Private Link を介して通信する必要があります。
  • 保存データは暗号化する必要があります。
  • 転送中のデータは暗号化する必要があります。
  • DevOps デプロイ パイプライン (Azure DevOps など) を使用でき、Azure Spring Apps へのネットワーク接続が必要です。
  • エグレス トラフィックは、中央のネットワーク仮想アプライアンス (NVA) (Azure Firewall など) を経由する必要があります。
  • Azure Spring Apps Config Server を使用してリポジトリから構成プロパティを読み込む場合、リポジトリはプライベートである必要があります。
  • Microsoft のゼロ トラスト セキュリティ アプローチでは、シークレット、証明書、資格情報をセキュリティで保護されたコンテナーに格納する必要があります。 推奨されるサービスは Azure Key Vault です。
  • オンプレミスおよびクラウド内のホストの名前解決は双方向にする必要があります。
  • コントロール プレーン トラフィックを除き、パブリック インターネットへの直接エグレスはありません。
  • Azure Spring Apps デプロイによって管理されるリソース グループは変更しないでください。
  • Azure Spring Apps デプロイによって管理されるサブネットは変更しないでください。

次の一覧は、設計を構成するコンポーネントを示しています。

  • オンプレミス ネットワーク
    • ドメイン ネーム サービス (DNS)
    • ゲートウェイ
  • ハブ サブスクリプション
    • Application Gateway サブネット
    • Azure Firewall サブネット
    • 共有サービス サブネット
  • 接続されているサブスクリプション
    • Azure Bastion サブネット
    • 仮想ネットワーク ピア

次の一覧では、この参照アーキテクチャの Azure サービスについて説明します。

  • Azure Key Vault: Microsoft ID サービスとコンピューティング リソースとの緊密な統合を備えた、ハードウェアベースの資格情報管理サービス。

  • Azure Monitor: Azure とオンプレミスの両方にデプロイされるアプリケーション向けの包括的な監視サービス スイート。

  • Azure Pipelines: 更新された Spring Boot アプリを Azure Spring Apps に自動的にデプロイできる、完全な機能を備えた継続的インテグレーション/継続的開発 (CI/CD) サービス。

  • Microsoft Defender for Cloud: オンプレミス、複数のクラウド、Azure にまたがるワークロード向けの統合されたセキュリティ管理と脅威保護システム。

  • Azure Spring Apps: Java ベースの Spring Boot アプリケーション用に特別に設計および最適化されたマネージド サービスです。NET ベースの Steeltoe アプリケーション。

次の図は、上記の要件に対応する適切に設計されたハブとスポークの設計を表しています。

パブリック アプリケーション

次の一覧では、パブリック アプリケーションのインフラストラクチャ要件について説明します。 これらの要件は、厳しく規制された環境で一般的です。

  • サブネットには、Azure Spring Apps のインスタンスが 1 つだけ必要です。
  • 少なくとも 1 つのセキュリティ ベンチマークへの準拠を適用する必要があります。
  • アプリケーション ホスト ドメイン ネーム サービス (DNS) レコードは、Azure プライベート DNS に格納する必要があります。
  • Azure DDoS Protection を有効にする必要があります。
  • Azure サービスの依存関係は、サービス エンドポイントまたは Private Link を介して通信する必要があります。
  • 保存データは暗号化する必要があります。
  • 転送中のデータは暗号化する必要があります。
  • DevOps デプロイ パイプライン (Azure DevOps など) を使用でき、Azure Spring Apps へのネットワーク接続が必要です。
  • エグレス トラフィックは、中央のネットワーク仮想アプライアンス (NVA) (Azure Firewall など) を経由する必要があります。
  • イングレス トラフィックは、少なくとも Application Gateway または Azure Front Door によって管理する必要があります。
  • インターネット ルーティング可能なアドレスは、Azure パブリック DNS に格納する必要があります。
  • Microsoft のゼロ トラスト セキュリティ アプローチでは、シークレット、証明書、資格情報をセキュリティで保護されたコンテナーに格納する必要があります。 推奨されるサービスは Azure Key Vault です。
  • オンプレミスおよびクラウド内のホストの名前解決は双方向にする必要があります。
  • コントロール プレーン トラフィックを除き、パブリック インターネットへの直接エグレスはありません。
  • Azure Spring Apps デプロイによって管理されるリソース グループは変更しないでください。
  • Azure Spring Apps デプロイによって管理されるサブネットは変更しないでください。

次の一覧は、設計を構成するコンポーネントを示しています。

  • オンプレミス ネットワーク
    • ドメイン ネーム サービス (DNS)
    • ゲートウェイ
  • ハブ サブスクリプション
    • Application Gateway サブネット
    • Azure Firewall サブネット
    • 共有サービス サブネット
  • 接続されているサブスクリプション
    • Azure Bastion サブネット
    • 仮想ネットワーク ピア

次の一覧では、この参照アーキテクチャの Azure サービスについて説明します。

  • Azure Application Firewall: 一般的な悪用や脆弱性からアプリケーションを一元的に保護する Azure Application Gateway の機能です。

  • Azure Application Gateway: トランスポート層セキュリティ (TLS) オフロードがレイヤー 7 で動作するアプリケーション トラフィックを担当するロード バランサー。

  • Azure Key Vault: Microsoft ID サービスとコンピューティング リソースとの緊密な統合を備えた、ハードウェアベースの資格情報管理サービス。

  • Azure Monitor: Azure とオンプレミスの両方にデプロイされるアプリケーション向けの包括的な監視サービス スイート。

  • Azure Pipelines: 更新された Spring Boot アプリを Azure Spring Apps に自動的にデプロイできる、完全な機能を備えた継続的インテグレーション/継続的開発 (CI/CD) サービス。

  • Microsoft Defender for Cloud: オンプレミス、複数のクラウド、Azure にまたがるワークロード向けの統合されたセキュリティ管理と脅威保護システム。

  • Azure Spring Apps: Java ベースの Spring Boot アプリケーション用に特別に設計および最適化されたマネージド サービスです。NET ベースの Steeltoe アプリケーション。

次の図は、上記の要件に対応する適切に設計されたハブアンドスポーク設計を表しています。 ハブ仮想ネットワークのみがインターネットと通信します。

Azure Spring Apps のオンプレミス接続

Azure Spring Apps のアプリケーションは、さまざまな Azure、オンプレミス、および外部リソースと通信できます。 ハブアンドスポーク設計を使用することで、アプリケーションは Express Route またはサイト間仮想プライベート ネットワーク (VPN) を使用して、外部またはオンプレミス ネットワークにトラフィックをルーティングできます。

Azure Well-Architected Framework に関する考慮事項

Azure Well-Architected Framework は、強力なインフラストラクチャ基盤の確立に従う一連の指針です。 フレームワークには、コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率、信頼性、セキュリティのカテゴリが含まれています。

コストの最適化

分散システム設計の性質上、インフラストラクチャの拡大は現実です。 この現実により、予期しない、制御不能なコストが発生します。 Azure Spring Apps は、需要を満たし、コストを最適化できるようにスケーリングするコンポーネントを使用して構築されています。 このアーキテクチャの中核となるのは、Azure Kubernetes Service (AKS) です。 このサービスは、Kubernetes の管理の複雑さと運用上のオーバーヘッドを削減するように設計されています。これには、クラスターの運用コストの効率が含まれます。

さまざまなアプリケーションとアプリケーションの種類を Azure Spring Apps の 1 つのインスタンスにデプロイできます。 このサービスでは、使用状況とコスト効率を向上できるメトリックまたはスケジュールによってトリガーされるアプリケーションの自動スケーリングがサポートされています。

Application Insights と Azure Monitor を使用して運用コストを削減することもできます。 包括的なログ ソリューションによって提供される可視性を使用すると、自動化を実装してシステムのコンポーネントをリアルタイムでスケーリングできます。 また、ログ データを分析して、システムの全体的なコストとパフォーマンスを向上させるために対処できるアプリケーション コードの非効率性を明らかにすることもできます。

オペレーショナルエクセレンス

Azure Spring Apps は、オペレーショナル エクセレンスの複数の側面に対処します。 次の一覧で説明するように、これらの側面を組み合わせて、運用環境でサービスが効率的に実行されるようにすることができます。

  • Azure Pipelines を使用すると、デプロイの信頼性と一貫性を確保しながら、人為的なエラーを回避できます。
  • Azure Monitor と Application Insights を使用して、ログとテレメトリ データを格納できます。 収集されたログとメトリック データを評価して、アプリケーションの正常性とパフォーマンスを確認できます。 アプリケーション パフォーマンス監視 (APM) は、Java エージェントを介してサービスに完全に統合されています。 このエージェントは、追加のコードを必要とせずに、デプロイされたすべてのアプリケーションと依存関係を可視化します。 詳細については、ブログ記事「 Azure Spring Apps でアプリケーションと依存関係を簡単に監視する」を参照してください。
  • Microsoft Defender for Cloud を使用して、提供されたデータを分析および評価するプラットフォームを提供することで、アプリケーションがセキュリティを維持できるようにします。
  • このサービスでは、さまざまなデプロイ パターンがサポートされています。 詳細については、「Azure Spring Apps でステージング環境を設定する」を参照してください。

信頼性

Azure Spring Apps は AKS 上に構築されています。 AKS はクラスタリングを通じて一定の回復性を提供しますが、この参照アーキテクチャは、コンポーネントの障害が発生した場合にアプリケーションの可用性を向上させるためにサービスとアーキテクチャの考慮事項を組み込むことでさらに進みます。

明確に定義されたハブ アンド スポーク設計を基に構築することで、このアーキテクチャの基盤により、複数のリージョンにデプロイできるようになります。 プライベート アプリケーションのユース ケースでは、アーキテクチャは Azure プライベート DNS を使用して、地理的障害時に継続的な可用性を確保します。 パブリック アプリケーションのユース ケースでは、Azure Front Door と Azure Application Gateway によって可用性が確保されます。

安全

このアーキテクチャのセキュリティは、業界で定義された制御とベンチマークへの準拠によって対処されます。 このコンテキストでは、"制御" とは、簡潔で明確に定義されたベスト プラクティスを意味します。たとえば、「情報システム アクセスを実装するときに最小限の特権原則を採用する」などです。 IAM-05" このアーキテクチャのコントロールは、Cloud Security Alliance (CSA) と Microsoft Azure Foundations Benchmark (MAFB) by the Center for Internet Security (CIS) の Cloud Control Matrix (CCM) から取得されています。 適用されるコントロールでは、ガバナンス、ネットワーク、アプリケーションセキュリティの主要なセキュリティ設計原則に焦点を当てています。 ターゲット インフラストラクチャに関連する ID、アクセス管理、ストレージの設計原則を処理するのは、お客様の責任です。

ガバナンス

このアーキテクチャが対処するガバナンスの主な側面は、ネットワーク リソースの分離による分離です。 CCM では、DCS-08 はデータセンターのイングレスおよびエグレス制御を推奨します。 この制御を満たすために、アーキテクチャでは、ネットワーク セキュリティ グループ (NSG) を使用してハブ アンド スポーク設計を使用して、リソース間の東西トラフィックをフィルター処理します。 このアーキテクチャでは、ハブ内の中央サービスとスポーク内のリソース間のトラフィックもフィルター処理されます。 このアーキテクチャでは、Azure Firewall のインスタンスを使用して、インターネットとアーキテクチャ内のリソース間のトラフィックを管理します。

次の一覧は、このリファレンスのデータセンターのセキュリティに対応するコントロールを示しています。

CSA CCM コントロール ID CSA CCM コントロール ドメイン
DCS-08 データセンターのセキュリティ無断侵入

ネットワーク

このアーキテクチャをサポートするネットワーク設計は、従来のハブ アンド スポーク モデルから派生しています。 この決定により、ネットワーク分離が基本的なコンストラクトであることが保証されます。 CCM コントロール IVS-06 では、ネットワークと仮想マシン間のトラフィックを制限し、信頼された環境と信頼されていない環境の間で監視することをお勧めします。 このアーキテクチャでは、("データ センター" 内の) 東西トラフィック用の NSG と、南北トラフィック用の Azure Firewall ("データ センター" の外部) の実装による制御が採用されています。 CCM コントロール IPY-04 では、サービス間のデータ交換にセキュリティで保護されたネットワーク プロトコルをインフラストラクチャで使用することをお勧めします。 このアーキテクチャをサポートする Azure サービスはすべて、HTTP および SQL 用の TLS などの標準的なセキュリティで保護されたプロトコルを使用します。

次の一覧は、このリファレンスのネットワーク セキュリティに対応する CCM コントロールを示しています。

CSA CCM コントロール ID CSA CCM コントロール ドメイン
IPY-04 ネットワーク プロトコル
IVS-06 ネットワークのセキュリティ

ネットワーク実装は、MAFB からの制御を定義することによってさらにセキュリティ保護されます。 この制御により、環境へのトラフィックがパブリック インターネットから制限されます。

次の一覧は、このリファレンスのネットワーク セキュリティに対処する CIS コントロールを示しています。

CIS コントロール ID CIS コントロールの説明
6.2 SSH アクセスがインターネットから制限されていることを確認します。
6.3 イングレス 0.0.0.0/0 (ANY IP) を許可する SQL データベースがないことを確認します。
6.5 Network Watcher が [有効] になっていることを確認します。
6.6 UDP を使用するイングレスがインターネットから制限されていることを確認します。

Azure Spring Apps では、セキュリティで保護された環境にデプロイされた場合、管理トラフィックが Azure から送信される必要があります。 仮想ネットワークで Azure Spring Apps を実行する場合は、お客様の責任に記載されているネットワークとアプリケーションの規則を許可する必要があります。

アプリケーションのセキュリティ

この設計原則では、ID、データ保護、キー管理、およびアプリケーション構成の基本的なコンポーネントについて説明します。 設計上、Azure Spring Apps にデプロイされたアプリケーションは、機能するために必要な最小限の特権で実行されます。 一連の承認制御は、サービスを使用する場合のデータ保護に直接関連します。 キー管理により、この階層化されたアプリケーション セキュリティ アプローチが強化されます。

次の一覧は、このリファレンスのキー管理に対応する CCM コントロールを示しています。

CSA CCM コントロール ID CSA CCM コントロール ドメイン
EKM-01 暗号化とキー管理の権利
EKM-02 暗号化とキー管理キーの生成
EKM-03 暗号化とキー管理の機密データ保護
EKM-04 暗号化とキー管理のストレージとアクセス

CCM、EKM-02、EKM-03 では、キーを管理し、暗号化プロトコルを使用して機密データを保護するためのポリシーと手順が推奨されています。 EKM-01 では、すべての暗号化キーの所有者を特定して管理できるようにすることをお勧めします。 EKM-04 では、標準アルゴリズムを使用することをお勧めします。

次の一覧は、このリファレンスのキー管理に対応する CIS コントロールを示しています。

CIS コントロール ID CIS コントロールの説明
8.1 すべてのキーに有効期限が設定されていることを確認します。
8.2 すべてのシークレットに有効期限が設定されていることを確認します。
8.4 キーボールトが復旧可能であることを確認します。

CIS コントロール 8.1 および 8.2 では、ローテーションが確実に適用されるように、資格情報の有効期限を設定することをお勧めします。 CIS コントロール 8.4 は、ビジネス継続性を維持するために、キー ボールトの内容が復元できることを保証します。

アプリケーション セキュリティの側面は、この参照アーキテクチャを使用して Azure の Spring ワークロードをサポートするための基盤を設定します。

次のステップ

Azure Spring Apps リファレンス アーキテクチャ リポジトリで利用できる ARM、Terraform、Azure CLI のデプロイを使用して、この参照アーキテクチャについて説明します。