ExpressRouteを用いないAzureとM365テナント間の通信におけるセキュリティ対応

Please find the details below

1. "No ExpressRoute" ≠ "traffic goes over the Internet"

• ExpressRoute secures your corporate network → Microsoft. It has nothing to do with Microsoft service → Microsoft service traffic. Microsoft documents that traffic between Microsoft services (explicitly naming Azure and Microsoft 365) "routes within our global network and never over the public Internet." Power Platform states the same: internal communication between Microsoft services uses the Microsoft backbone and "isn't exposed to the public internet." That traffic already carries two encryption layers, both on by default:
  • TLS 1.2 at transport ("All traffic leaving a datacenter is encrypted in transit")
  • MACsec (IEEE 802.1AE) at the data-link layer between datacenters — "you don't need to take action to enable it"
  So your "HTTPS/TLS" bullet is understated, not wrong. 2. Your list is correct but incomplete — here's what's missing a) VNet support for Power Platform — the AI Search connector is now GA for this This is the single biggest gap. Subnet delegation lets Power Platform make outbound calls from your delegated subnet, so you can disable public network access on Azure AI Search entirely and reach it via private endpoint — no ExpressRoute needed. Key constraints before you commit:
  • Not supported on Trial or Dataverse for Teams environments
  • Region pairs are fixed — Japan → japaneast + japanwest (two VNets required)
  • Size subnets at 25–30 IPs per production env, 6–10 per non-prod, +5 reserved per subnet (docs' example: 4 prod × 30 + 5 = 125 → a /25)
  • Subnet must be new and dedicated; IP range and VNet DNS cannot be changed after delegation
  • "The calls to publicly available resources start to break" — audit connector/plugin URLs first
  • Endpoints must present a complete TLS cert chain; custom root CAs cannot be added
  Run Get-EnvironmentRegion from the subnet diagnostics PowerShell module first. b) Use Entra ID auth on the knowledge connection — not the admin key The docs are blunt: "You must add Azure AI Search through a formal data connection. Don't manually configure an endpoint and API key." Choose Microsoft Entra ID Integrated or Service principal. This matters more than it looks: a broken AI Search data connection is stored at the environment level, can break the connection dialog for all agents in that environment, and there is no UI to delete it. Recovery = reset the agent's external access, or delete and recreate the agent. c) RBAC at the data plane, not just the control plane Set AI Search Keys → Role-based access control (or Both), then grant Search Index Data Reader to Entra groups. Not Contributor, not admin keys. d) Privatize the ingestion path separately Ingestion (ADLS Gen2 → indexer → embeddings) is a different trust boundary from query time:
  • System-assigned managed identity on AI Search
  • ADLS Gen2 → Selected networks + "Allow Azure services on the trusted services list"
  • Disable public network access on Storage / Search / OpenAI + private endpoints
  • Shared private link for outbound AI Search calls (Azure OpenAI target: resource type Microsoft.CognitiveServices/accounts, group ID openai_account)
  Tier gates: indexers without skillsets = Basic+; embedding skills / integrated vectorization = Basic+ and high-capacity region and service created after April 3, 2024; other built-in/custom skills = S1+, also post-April 3, 2024. e) Governance controls people usually miss Power Platform DLP data policies (restrict which knowledge sources makers can attach) · customer-managed keys (Managed Environments only) · data movement across geographies toggle · continuous access evaluation · sharing rules / viewer limits · Customer Lockbox · Key Vault-backed environment variables. For inbound IP firewall, use service tags PowerPlatformInfra / PowerPlatformPlex (preview). Do not try to allowlist Copilot Studio in your AI Search firewall — those published outbound IP tables are for Bot Framework skills only, and agent egress addresses are dynamic and not reliably allowlistable.

  3. Your second question — yes, there IS an asymmetry

  The two hops are not equivalent, and knowing this will save you schedule time:

  	Path	Boundary	Control
  	Query — agent → your AI Search index	Terminates on a resource you own	VNet support + private endpoint + Entra ID auth
  	Response/generation	Microsoft-managed Azure OpenAI inside the Power Platform service boundary	Tenant policy only — data-movement-across-geographies toggle, geo data residency

  Your own Azure OpenAI resource sits on the ingestion/vectorization path (embeddings), which is Azure-internal and privatized via shared private link. Bottom line: one hop to harden with network controls, not two. Don't spend a week trying to put a private endpoint in front of the Copilot Studio generation path — that's not where the boundary is. Documents:
  • Microsoft global network — Get the premium cloud network
  • About data encryption — In-transit data protection
  • Double encryption — Data in transit
  • Azure VNet support overview — supported services / regions / subnet sizing
  • Add Azure AI Search as a knowledge source
  • Shared private link · Network and access configuration
  • Enable RBAC on Azure AI Search · Copilot Studio security FAQs