Azure 統合サービス ランディング ゾーン アクセラレータのセキュリティに関する考慮事項
優れたセキュリティは、すべての Azure アプリケーションの基礎です。 アプリケーションを構成するリソースは多数存在し、これらの各リソースに独自のセキュリティに関する考慮事項があるため、Azure 統合サービスは、特有の課題に直面します。 各サービスの特有の考慮事項を確実に理解するには、次のセキュリティ ベースラインを参照してください。
設計上の考慮事項
セキュリティ モデルを設計する際には、設計時セキュリティと実行時セキュリティという 2 つの異なる設計領域があります。
設計時セキュリティには、Azure portal または管理 API を使用した Azure リソースの管理と作成へのアクセスが含まれます。 Azure 内では、Microsoft Entra ID とロールベースのアクセス制御 (RBAC) を使用してこれを実現します。
実行時セキュリティには、アプリケーションのフロー中のエンドポイントとリソースへのアクセスが含まれます。たとえば、ロジック アプリを呼び出すユーザーの認証と承認や API Management での API 操作などです。
必要であれば、以下について早い段階で決定します。
プライベート クラウド - すべてのリソースが VNet 内に存在し、プライベート アドレス指定のみを使用します。パブリック インターネットとの間のアクセスはありません。VPN または ExpressRoute を介したオンプレミス リソースで利用できる可能性があります。
パブリック クラウド - パブリックに接続されているすべてのリソースは、パブリック インターネットからのアクセスを制限するためにロックされますが、パブリック インターネットにアクセスできます。
ハイブリッド - 一部のリソースはプライベートであり、一部はパブリックです。
行う選択は、リソースのコストと、アプリケーションにどの程度のセキュリティを実装できるかの両方に影響します。
一般的なセキュリティに関する考慮事項には次のものが含まれます。
イングレス トラフィックとエグレス トラフィックを保護するための Azure サービスの使用。
認証を管理するための Microsoft Entra ID および OAuth 2.0 の使用。
Azure Policy を使用したガバナンス ポリシーの実施。
リソースへのアクセスのロック (アクセス制御)。
転送中と保存の両方でのデータの暗号化。
リソースへのすべてのアクセス試行のログ記録。
リソースへのアクセス権の監査。
設計の推奨事項
ネットワーク設計に関する推奨事項
アクセス可能なエンドポイントの手前での Web Application Firewall (WAF) を使用した Application Gateway (Azure Application Gateway または Azure Front Door) の使用を検討します。これは、データの自動暗号化に役立ち、エンドポイントをより簡単に監視および構成できるようにします。
Front Door は、Web アプリケーション向けのグローバル負荷分散およびサイト アクセラレーション サービスを提供するアプリケーション配信ネットワークです。 Front Door は、SSL オフロード、パスベースのルーティング、高速フェールオーバー、キャッシュなどのレイヤー 7 機能を提供して、アプリケーションのパフォーマンスと可用性を向上させます。
Traffic Manager は、世界中の Azure リージョン間でサービスへのトラフィックを最適に配分しつつ、高可用性と応答性を実現する DNS ベースのトラフィック ロード バランサーです。 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 秒あたり数百万の要求を処理します。 Azure Load Balancer は、ゾーン冗長であるため、Availability Zones 全体で高可用性を確保します。
VNet 統合を使用して統合サービス リソースを、Azure プライベート リンクとプライベート エンドポイントの使用によって結合される分離サブネットに配置することで、リソースのネットワーク分離を実装します。 この設計ガイダンスのレビューについては、このシリーズのネットワーク トポロジと接続に関する記事を参照してください。
Azure Firewall を使用してエグレス トラフィックを保護する
エンドポイントが既知のネットワーク アドレスからのみアクセスできるように、IP フィルタリングを使用してエンドポイントをロックします (これは、VNet に統合されていないロジック アプリに対して適用できます)。
一般に公開されているリソースがある場合は、DNS 難読化を使用して何らかの攻撃者を阻止します。難読化とは、カスタム ドメイン名、またはリソースの目的や所有者を明らかにしない特定の Azure リソース名を意味します。
暗号化の設計に関する推奨事項
(たとえば、Azure Storage や Azure SQL Server などに) データを保存する場合は、常に保存時の暗号化を有効にします。 データへのアクセスをロックし、理想的にはサービスと限られた数の管理者にのみ許可します。 これはログ データにも適用されることを覚えておいてください。 詳細については、「保存 時の Azure データの暗号化 」と「Azure の暗号化の概要」を参照してください。
リソース間でデータを転送する場合は、常に転送中の暗号化 (たとえば、TLS トラフィックなど) を使用します。暗号化されていないチャネル経由でデータを送信することはありません。
TLS プロトコルを使用する場合は、常に TLS 1.2 以降を使用します。
シークレットを Azure Key Vault に保持してから、これらをアプリ設定 (Functions、Logic Apps)、名前付きの値 (API Management)、または構成エントリ (App Configuration) にリンクします。
危険なキーを使用した攻撃を防ぐために、環境内で使用されているすべてのキーが定期的にローテーションされるように、キー ローテーション ポリシーを実装する
ロジック アプリに対しては、難読化を使用して、実行履歴内のデータをセキュリティで保護します。
認証とアクセスの設計に関する推奨事項
アクセスを割り当てる際には、常に最小限の特権の原則に従ってください。ID にはそれが必要とする最小限の権限を付与します。 これには、カスタム Microsoft Entra ロールの作成が含まれる場合があります。 自分が必要とする最小限の権限を持つ組み込みロールがない場合は、これらの権限のみを持つカスタム ロールを作成することを検討してください。
リソースがサービスにアクセスする必要がある場合は、可能な限り、常にマネージド ID を使用します。 たとえば、ロジック アプリ ワークフローがシークレットを取得するために Key Vault にアクセスする必要がある場合は、ロジック アプリのマネージド ID を使用してこれを実現します。マネージド ID は、Azure がユーザーに代わって ID を管理するため、リソースにアクセスするためのより安全で管理しやすいメカニズムを提供します。
次のようにリソース エンドポイント間の認証メカニズムとして OAuth 2.0 を使用します。
Logic Apps または Functions で Easy Auth を有効にします。これにより、すべての外部呼び出し元が OAuth ID を使用する必要があります (通常は Microsoft Entra ID ですが、任意の ID プロバイダーでもかまいません)。
API Management で、jwt-validation ポリシー要素を使用して、エンドポイントへの接続に OAuth フローを要求します。
Azure Storage と Key Vault で、特定の ID へのアクセスを制限するアクセス ポリシーを設定します。
ガバナンスの設計に関する推奨事項
Azure Policy を積極的に使用して、セキュリティの問題や欠陥を探します。 たとえば、IP フィルタリングのないエンドポイントなどです。
使用可能な場合は、Microsoft Defender for Cloud を使用してリソースと ID の潜在的な弱点をスキャンします。
監査ログを定期的に確認して (自動化されたツールを使用するのが理想的)、セキュリティ攻撃とリソースへの未承認のアクセスの両方を特定します。
侵入テストを使用して、セキュリティ設計の弱点を特定することを検討してください。
自動デプロイ プロセスを使用してセキュリティを構成します。 可能であれば、Azure DevOps のような CI/CD パイプラインを Terraform で使用して、リソースをデプロイするだけでなく、セキュリティの構成も行います。 これにより、リソースはデプロイされるたびに自動的に保護されることが保証されます。
次のステップ
重要な設計領域を確認し、アーキテクチャの完全な考慮事項と推奨事項を作成します。