Important
非推奨の通知: この記事は非推奨であり、更新されなくなりました。 最適なガイダンスのみが表示されるように、この記事は 2026 年 5 月に削除されます。
別のガイダンスについては、Azure アーキテクチャ センターの integration アーキテクチャ ガイダンスを参照してください。
このガイダンスを保存する場合は、このページの左下にある PDF をダウンロードするか、GitHub からファイルをダウンロードします。
優れたセキュリティは、Azureアプリケーションの基礎です。 Azure Integration Services には、アプリケーションを構成するリソースが多数あり、各リソースには独自のセキュリティに関する考慮事項があるため、特定の課題に直面しています。 各サービスの特定の考慮事項を確実に理解するには、次のセキュリティ ベースラインを参照してください。
Azure Service Bus のセキュリティ ベースライン Azure Storage のセキュリティ ベースライン
設計に関する考慮事項
セキュリティ モデルを設計するときは、設計時のセキュリティと実行時のセキュリティという 2 つの異なる設計領域があります。
デザイン時セキュリティでは、Azure ポータルまたは Resource Manager API を使用してAzure リソースの管理と作成にアクセスできます。 Azure内では、Microsoft Entra IDとロールベースのアクセス制御 (RBAC) を使用します。
Run-Time セキュリティ には、アプリケーションのフロー中にエンドポイントとリソースへのアクセスが含まれます。たとえば、ロジック アプリを呼び出すユーザーの認証と承認、API Management での API 操作などです。
必要かどうかを早い段階で決定します。
Private Cloud - すべてのリソースが Virtual Network (VNet) に存在し、パブリック インターネットとの間でアクセスできないプライベート ネットワークのみを使用し、VPN または ExpressRoute 経由でオンプレミス リソースで使用できる可能性があります。
パブリック クラウド - 公開されているすべてのリソースはパブリック インターネットにアクセスできますが、パブリック インターネットからのアクセスを制限し、特定の IP アドレス/範囲のみを許可するようにロックダウンされています。
ハイブリッド - 一部のリソースはプライベートであり、一部はパブリックです。
選択すると、リソースのコストと、アプリケーションに実装できるセキュリティの量の両方に影響します。
セキュリティに関する一般的な考慮事項は次のとおりです。
Azureネットワーク サービスを使用してイングレス トラフィックとエグレス トラフィックを保護する。
Microsoft Entra IDと OAuth 2.0 を使用して認証と承認を管理する。
Azure Policyを使用してガバナンス ポリシーを適用する。
リソースへのアクセスをロックダウンする (アクセス制御)。
転送中と保存中の両方のデータを暗号化する。
リソースへのアクセス試行をすべてログに記録します。
リソースへのアクセスの監査。
設計に関する推奨事項
ネットワーク設計に関する推奨事項
アクセス可能なエンドポイントの前に Application Gateway (Azure Application Gateway または Azure Front Door) と Web Application Firewall (WAF) を使用する方法を確認します。これは、データの自動暗号化に役立ち、データの監視と構成に役立ちますエンドポイントをより簡単に使用できます。
Front Door は、Web アプリケーションのグローバル負荷分散とサイト アクセラレーション サービスを提供するアプリケーション配信ネットワークです。 Front Door には、SSL オフロード、パスベースのルーティング、高速フェールオーバー、キャッシュなどのレイヤー 7 機能が用意されており、アプリケーションのパフォーマンスと可用性が向上します。
Traffic Manager は DNS ベースのトラフィック ロード バランサーです。これにより、グローバル Azure リージョン全体のサービスに最適なトラフィックを分散しながら、高可用性と応答性を実現できます。 Traffic Manager は DNS ベースの負荷分散サービスであるため、負荷分散はドメイン レベルでのみ行われます。 そのため、DNS キャッシュと DNS TTL を受け入れないシステムに関する一般的な課題のため、Front Door ほど迅速にフェールオーバーすることはできません。
Application Gateway は、さまざまなレイヤー 7 負荷分散機能を備えたマネージド アプリケーション配信コントローラーを提供します。 Application Gateway を使用すると、CPU を集中的に使用する SSL 終了をゲートウェイにオフロードすることで、Web ファームの生産性を最適化できます。
Azure Load Balancer は、すべての UDP および TCP プロトコルに対する、高パフォーマンスで超低待機時間のレイヤー 4 の受信および送信負荷分散サービスです。 Load Balancerは、1 秒あたり何百万もの要求を処理します。 Load Balancerはゾーンの冗長性があり、可用性ゾーン全体の高可用性を確保します。
VNet 統合を使用して分離されたサブネットに配置し、Azure PrivateLink およびプライベート エンドポイントを使用して統合サービス リソースのネットワーク分離を実装します。 この設計ガイダンスのレビューについては、このシリーズの ネットワーク トポロジと接続 に関する記事を参照してください。
Azure Firewall IP フィルタリングを使用してエンドポイントが既知のネットワーク アドレスによってのみアクセスされるようにロックダウンします (これは、VNet に統合されていないサービスとしてのプラットフォーム (PaaS) サービス (Logic Apps、Function Apps、Service Bus など) に適用されます)。
リソースが公開されている場合は、DNS 難読化を使用して攻撃者を阻止します。難読化とは、カスタム ドメイン名、またはリソースの目的や所有者を明らかにしない特定のAzureリソース名を意味します。
暗号化の設計に関する推奨事項
Azure PaaS サービスにデータ (Azure Storage や Azure SQL Server など) を格納する場合、データは静止時には常に Microsoft 管理キーを使用して暗号化されます。 データへのアクセスをロックダウンします。理想的には、サービスと限られた数の管理者に限定されます。 これはログ データにも当てはまることに注意してください。 詳細については、「Azure保存データの暗号化とAzure暗号化の概要を参照してください。 Customer マネージド キー (CMK) を使用する必要があるかどうか、またはMicrosoftマネージド キーで十分かどうかを検討します。
リソース間でデータを転送する場合は、常に 転送中の暗号化 (TLS トラフィックなど) を使用します。暗号化されていないチャネル経由でデータを送信することはありません。
TLS プロトコルを使用する場合は、常に TLS 1.2 以降を使用してください。
シークレットはAzure Key Vaultに安全に格納し、それをApp Settings（Functions、Logic Apps）、Named Values（API Management）、またはConfiguration Entries（App Configuration）としてリンクします。
危険なキーを使用した攻撃を防ぐために、環境内で使用されているすべてのキーが定期的にローテーションされるように、 キー ローテーション ポリシー を実装する
Logic Apps の場合は、 難読化を使用 して、実行履歴のデータをセキュリティで保護します。
認証とアクセスの設計に関する推奨事項
アクセスを割り当てるときは、常に最小限の特権の原則に従ってください。ID に必要な最小限のアクセス許可を付与します。 必要最小限のアクセス許可を持つ組み込みロールがない場合は、これらのアクセス許可のみを使用して カスタム ロール を作成することを検討してください。
可能な限り、リソースがサービスにアクセスする必要がある場合は、常に マネージド ID を 使用します。 たとえば、ロジック アプリ ワークフローがシークレットを取得するためにKey Vaultにアクセスする必要がある場合は、Logic Apps の Managed Identity を使用します。マネージド ID は、ユーザーに代わって ID を管理Azure、リソースにアクセスするためのより安全で管理しやすいメカニズムを提供します。
リソース エンドポイント間の認証メカニズムとして OAuth 2.0 を使用します。
Logic Apps または Functions では、すべての外部呼び出し元が OAuth ID を使用する必要がある Easy Auth を有効にします (通常はMicrosoft Entra IDが、任意の ID プロバイダーである可能性があります)。
API Management では、
validate-jwtpolicy 要素 を使用して、エンドポイントへの接続に OAuth フローを要求します。Azure StorageとKey Vaultで、特定の ID へのアクセスを制限するアクセス ポリシーを設定します。
ガバナンス設計に関する推奨事項
Azure Policyを積極的に使用して、セキュリティの問題や欠陥を探します。 たとえば、IP フィルタリングのないエンドポイントなどです。
使用可能な場合は、Microsoft Defender for Cloud を使用してリソースをスキャンし、潜在的な弱点を特定します。
監査ログ (理想的には自動ツールを使用) を定期的に確認して、セキュリティ攻撃とリソースへの不正アクセスの両方を特定します。
侵入テストを使用して、セキュリティ設計の弱点を特定することを検討してください。
自動デプロイ プロセスを使用してセキュリティを構成します。 可能であれば、
GitHub Actions やAzure DevOps Pipelines などの CI/CD パイプラインと、Bicep やTeraform を使用して、リソースをデプロイするだけでなく、セキュリティを構成することもできます。 これにより、リソースがデプロイされるたびに自動的に保護されます。
次のステップ
重要な設計領域を確認して、アーキテクチャに関する完全な考慮事項と推奨事項を作成します。