生成日時: 2026年05月22日 対象期間: 過去 24 時間以内 処理モード: 詳細モード 更新件数: 5 件
公開日時: 2026年05月21日 22:00:20 UTC リンク: Generally Available: Entra-only identities with Azure Files
アップデートID: 562359 情報源: Azure Updates API
カテゴリ: Launched, Storage, Azure Files, Features, Microsoft Build, Security
要約:
何が更新されたか
Azure Filesで「Entra-only identities」（Microsoft Entra IDのみのID）によるSMBアクセスが一般提供（GA）されました。
主な変更点や新機能
これまでAzure FilesのSMBアクセスにはActive DirectoryやハイブリッドIDインフラが必要でしたが、今回のアップデートにより、クラウドネイティブなEntra IDのみでファイル共有へ安全にアクセスできるようになりました。これにより、オンプレミスのAD環境を持たない組織でも、Azure Filesを利用したファイル共有が容易になります。
影響を受ける対象
Azure Filesを利用している、または今後利用を検討している組織やユーザーが対象です。特に、オンプレミスのActive Directoryを持たず、クラウドベースのID管理を希望する企業にとって大きなメリットとなります。
注意点があれば記載
Entra-only identitiesによるSMBアクセスを利用する場合、既存のActive Directory連携やハイブリッドID構成とは異なる設定や運用が必要になる場合があります。詳細な要件や制限事項については公式ドキュメントを確認してください。
詳細:
Azure Filesにおいて、SMBアクセスのためのEntra-onlyアイデンティティが一般提供（GA）となりました。このアップデートの背景には、従来Azure FilesのSMBアクセスにはActive DirectoryやハイブリッドIDインフラストラクチャが必要であったことが挙げられます。多くの組織がクラウドネイティブな運用へ移行する中で、オンプレミスのActive Directoryを維持せずに、Azure上でセキュアかつシンプルにファイル共有を利用したいというニーズが高まっていました。今回のアップデートは、こうした要望に応えるものです。
具体的な機能としては、Azure Entra ID（旧称Azure Active Directory）上のクラウドネイティブユーザーやグループを用いて、Azure FilesのSMBファイル共有へ直接アクセスできるようになりました。これにより、オンプレミスやAzure AD DS（Domain Services）などの追加的なIDインフラストラクチャを構築・管理する必要がなくなります。ユーザーはEntra IDの認証情報のみで、Azure FilesのSMB共有にアクセス可能となります。
技術的な仕組みとしては、Azure FilesがEntra IDと連携し、SMBプロトコルでの認証時にクラウドネイティブIDを利用できるようになっています。従来のKerberos認証やNTLM認証の代わりに、Entra IDベースの認証フローが用いられ、Azure Filesが直接Entra IDのトークンを検証することでアクセス制御を実現します。これにより、オンプレミスのドメインコントローラーやAD DSの同期設定が不要となります。
主な活用シナリオとしては、完全クラウドベースで運用される組織や、オンプレミスのActive Directoryを廃止したい企業、またはリモートワーク環境で迅速にファイル共有を展開したいケースが挙げられます。たとえば、Azure上にのみ存在する仮想マシンや、Entra IDで管理されるユーザーがSMB経由でファイル共有を利用する場合に有効です。
注意点としては、Entra-onlyアイデンティティによるSMBアクセスは、現時点でサポートされる認証方式やクライアントOSのバージョン、機能範囲に制限がある可能性があります。たとえば、特定のSMB機能や一部のレガシークライアントでは利用できない場合がありますので、公式ドキュメントでの事前確認が推奨されます。
関連するAzureサービスとしては、Azure Entra IDが必須となるほか、Azure Filesのストレージアカウント設定やアクセス制御（RBAC）との連携が重要です。これにより、細かなアクセス権管理や監査もクラウド上で一元的に実施できます。
詳細は公式アップデートページ（https://azure.microsoft.com/updates?id=562359）を参照してください。
公開日時: 2026年05月21日 21:45:32 UTC リンク: Generally Available: Azure NetApp Files object REST API
アップデートID: 562254 情報源: Azure Updates API
カテゴリ: Launched, Storage, Azure NetApp Files, Features
要約:
何が更新されたか
Azure NetApp Filesで、S3互換のObject REST APIが一般提供（GA）されました。
主な変更点や新機能
このアップデートにより、Azure NetApp Files上のデータに対してS3互換のREST APIを利用したオブジェクトストレージアクセスが可能になりました。従来のファイルベースストレージとクラウドネイティブなオブジェクトストレージの両方の利点を活用でき、既存データを新たなクラウドサービスやアプリケーションと連携しやすくなります。
影響を受ける対象
Azure NetApp Filesを利用しているユーザーや、S3 APIを用いたアプリケーションとの連携を検討している技術者が対象です。特に、オンプレミスや他クラウドからのデータ移行や、ハイブリッドクラウド環境でのデータ活用を検討している場合に有用です。
注意点があれば記載
S3互換APIの利用には、API仕様や認証方式などの詳細を事前に確認することを推奨します。また、既存のファイルベースアクセスとの違いに注意し、アプリケーションの動作検証を十分に行ってください。
詳細:
Azure NetApp Files Object REST API（S3互換REST API）の一般提供が開始されました。本アップデートの背景には、従来のファイルベースストレージとクラウドサービスの間に存在するギャップを埋め、既存データをより柔軟かつ多様な方法で活用できるようにする目的があります。これまでAzure NetApp Filesは主にNFSやSMBなどのファイルプロトコルを通じてデータアクセスを提供していましたが、今回のObject REST APIの導入により、オブジェクトストレージとしてのアクセスが可能となります。
具体的な機能として、Object REST APIはAmazon S3互換のREST APIを提供し、既存のS3対応アプリケーションやツールからAzure NetApp Files上のデータに対してオブジェクトストレージ的な操作を行うことができます。これにより、ファイルストレージ上のデータをクラウドネイティブなワークロードやモダンなアプリケーションとシームレスに統合することが可能となります。
技術的な仕組みとしては、Azure NetApp FilesがS3互換のREST APIエンドポイントを提供し、HTTPベースでオブジェクトのアップロード、ダウンロード、削除、リストなどの操作を実行できます。これにより、従来のファイルアクセスに加え、オブジェクトストレージのAPIによるアクセスもサポートされるため、アプリケーションの設計やデータ管理の柔軟性が向上します。
活用シナリオとしては、既存のファイルストレージに保存されたデータを、S3互換APIを利用するクラウドアプリケーションやデータ分析基盤から直接参照・操作するケースが考えられます。例えば、オンプレミスからクラウドへの移行時や、ハイブリッドクラウド環境でのデータ連携、バックアップやアーカイブ用途など、多様な場面で活用できます。
注意点や制限事項については、現時点で提供された情報が限定的であるため、詳細な制約や推奨事項は公式ドキュメントを参照する必要があります。特に、APIの対応範囲やパフォーマンス、セキュリティ設定、既存ファイルストレージとの整合性など、運用上の注意点を事前に確認することが重要です。
関連するAzureサービスとの連携については、Azure NetApp Files自体がAzureのストレージサービス群と密接に連携しており、今回のObject REST APIの追加により、Azure Blob Storageや他のS3互換サービスとのデータ移行や連携が容易になる可能性があります。公式アップデートページ（https://azure.microsoft.com/updates?id=562254）を参照し、最新の機能や連携方法を確認することを推奨します。
公開日時: 2026年05月21日 21:45:32 UTC リンク: Retirement: TLS 1.0 and TLS 1.1 in Azure App Service, Azure Functions, and Azure Logic Apps
アップデートID: 557852 情報源: Azure Updates API
カテゴリ: Compute, Mobile, Web, Containers, Internet of Things, Integration, App Service, Azure Functions, Logic Apps, Retirements
要約:
何が更新されたか
Azure App Service、Azure Functions、Azure Logic Appsにおいて、TLS 1.0およびTLS 1.1のサポートが2027年5月31日をもって廃止されることが発表されました。
主な変更点や新機能
2027年5月31日以降、これらのサービスはTLS 1.0およびTLS 1.1による接続を受け付けなくなります。TLS 1.2以降のみがサポートされるようになります。
影響を受ける対象
Azure App Service、Azure Functions、Azure Logic Appsを利用しているすべてのクライアント、アプリケーション、サービスが対象です。これらのサービスにTLS 1.0または1.1で接続している場合、接続ができなくなります。
注意点があれば記載
既存のシステムやクライアントがTLS 1.2以上に対応しているかを早急に確認し、必要に応じてアップグレードを行ってください。特にレガシーシステムや外部連携のあるサービスは影響範囲の洗い出しが重要です。今後のセキュリティ要件に備え、早めの対応を推奨します。
詳細:
本アップデートは、Azureのセキュリティ強化施策の一環として、Azure App Service、Azure Functions、Azure Logic AppsにおいてTLS 1.0およびTLS 1.1による接続のサポートを2027年5月31日をもって終了することを告知するものです。TLS（Transport Layer Security）はインターネット上でのデータ暗号化通信を実現するプロトコルであり、TLS 1.0および1.1は古いバージョンであるため、既知の脆弱性やセキュリティリスクが指摘されています。これらのバージョンの廃止は、より安全な通信を実現するための措置です。
今回の変更により、2027年5月31日以降、Azure App Service、Azure Functions、Azure Logic AppsはTLS 1.0およびTLS 1.1を利用したクライアントやアプリケーションからの接続を受け付けなくなります。これにより、これらのサービスにアクセスする際はTLS 1.2以降のバージョンを利用する必要があります。既存のアプリケーションやクライアントがTLS 1.0または1.1を使用している場合、アップデート後は通信が確立できなくなるため、事前にTLS 1.2以上への対応が必須となります。
技術的には、Azure側でTLSバージョンのサポート設定が変更され、TLS 1.0および1.1によるハンドシェイク要求が拒否される仕組みとなります。アプリケーション開発者や運用担当者は、利用しているフレームワークやライブラリ、ミドルウェアがTLS 1.2以上に対応していることを確認し、必要に応じてアップグレードを行う必要があります。また、外部システムやクライアントとの連携部分についても、TLSバージョンの互換性を事前に検証することが推奨されます。
このアップデートは、WebアプリケーションやAPI、サーバーレスアーキテクチャをAzure上で運用しているシナリオ全般に影響します。たとえば、レガシーなクライアントやIoTデバイス、古いSDKを利用している場合、TLS 1.2以上への対応が遅れるとサービス利用に支障が生じる可能性があります。特に、外部ベンダーや顧客と連携するシステムでは、相手側のTLS対応状況も含めて早期に調整を進めることが重要です。
注意点として、TLSバージョンの切り替えはアプリケーションの動作や外部連携に影響を及ぼすため、十分な検証と段階的な移行計画が必要です。また、Azure App Service、Functions、Logic Apps以外のサービスとの連携部分についても、TLSバージョンの整合性を確認することが求められます。今回のアップデートは、Azureのセキュリティポリシーに基づくものであり、今後も他のサービスで同様の措置が講じられる可能性があるため、常に最新のセキュリティガイドラインを参照することが推奨されます。
関連する詳細情報や移行ガイドについては、公式のAzureアップデートページ（https://azure.microsoft.com/updates?id=557852）を参照してください。
公開日時: 2026年05月21日 18:45:42 UTC リンク: Generally Available: User Groups and IP address pools for P2S connections
アップデートID: 564460 情報源: Azure Updates API
カテゴリ: Launched, Networking, Security, VPN Gateway, Feature
要約:
何が更新されたか
Azure VPN GatewayのPoint-to-Site（P2S）接続において、「ユーザーグループ」と「IPアドレスプール」の機能が一般提供（GA）となりました。
主な変更点や新機能
このアップデートにより、リモートユーザーをユーザーグループ単位で整理し、各グループごとに異なるIPアドレスプールを割り当てることが可能になりました。ユーザーの認証情報に基づいて、接続時に自動的に適切なIPアドレスプールが割り当てられます。
影響を受ける対象
Azure VPN GatewayのPoint-to-Site接続を利用している組織や管理者が対象です。特に、リモートワークや多様なユーザー管理が必要な環境で有用です。
注意点があれば記載
本機能を利用するには、ユーザーグループの設定やIPアドレスプールの構成が必要です。既存のP2S構成に変更を加える際は、設定ミスによるアクセス制御の問題に注意してください。
詳細:
Azure VPN GatewayのPoint-to-Site（P2S）接続において、「User Groups」と「IP Address Pools」の機能が一般提供（GA）となりました。このアップデートの背景には、リモートユーザーの管理とセキュリティ強化、ネットワーク設計の柔軟性向上という目的があります。従来のP2S接続では、全てのリモートユーザーに対して単一のIPアドレスプールが割り当てられていましたが、今回のアップデートにより、ユーザーの認証情報に基づいて異なるIPアドレスプールを割り当てることが可能となりました。
具体的な機能としては、管理者がリモートユーザーをグループ化し、各グループごとに専用のIPアドレスプールを設定できます。これにより、例えば部署や役割ごとにネットワークアクセスを分離したり、セキュリティポリシーに応じたIPアドレス管理が実現できます。ユーザーグループの定義は、Azure ADや他の認証プロバイダーの認証情報を利用して行われ、VPN Gateway側でグループごとのIPアドレスプールの割り当てが自動的に適用されます。
技術的な仕組みとしては、P2S接続時にユーザーの認証情報が検証され、その情報に基づいて所属グループが判定されます。VPN Gatewayはグループごとに事前に設定されたIPアドレスプールからアドレスを割り当て、ユーザーごとのネットワーク分離やアクセス制御が容易になります。これにより、ネットワーク管理者は複数のユーザーグループに対して異なるセグメントを提供でき、アクセスログや監査にも役立ちます。
活用シナリオとしては、例えば複数のプロジェクトチームや部門が同一VPN Gatewayを利用する場合、各チームごとに異なるIPアドレスプールを割り当てることでネットワークトラフィックの分離やセキュリティ強化が可能です。また、特定のユーザーグループに対してアクセス制限や監査要件を適用する際にも有効です。
注意点としては、IPアドレスプールの設定やユーザーグループの管理は、適切な認証情報の整備とAzure VPN Gatewayの設定が必要です。また、既存のP2S接続環境から移行する場合は、IPアドレスプールの重複やグループ設定の整合性に注意が必要です。
この機能はAzure VPN GatewayのP2S接続に特化したものであり、Azure ADなどの認証サービスと連携してユーザー管理を行います。これにより、Azure上の他のネットワークサービスやセキュリティサービスとも組み合わせて、より高度なアクセス制御やネットワーク設計が可能となります。
公開日時: 2026年05月21日 18:45:42 UTC リンク: Public Preview: TLS/SSL certificate support for Azure Functions Flex Consumption
アップデートID: 562808 情報源: Azure Updates API
カテゴリ: In preview, Compute, Containers, Internet of Things, Azure Functions, Features
要約:
何が更新されたか
Azure Functions Flex Consumptionプランにおいて、TLS/SSL証明書のサポートがパブリックプレビューとして提供開始されました。
主な変更点や新機能
これまでの他のホスティングプランでは、証明書は同一リージョンかつリソースグループ内のアプリ間で共有される「webspace-scoped」モデルでしたが、Flex Consumptionでは「サイトスコープ」の証明書モデルが導入されました。これにより、各アプリごとに個別のTLS/SSL証明書を割り当てることが可能になります。
影響を受ける対象
Azure Functions Flex Consumptionプランを利用している、または利用を検討している開発者や運用担当者が対象です。Flex Consumptionが利用可能なすべてのリージョンで適用されます。
注意点があれば記載
本機能はパブリックプレビュー段階であり、運用環境での利用には十分な検証が推奨されます。また、従来のwebspace-scoped証明書との違いに注意し、証明書管理の運用設計を見直す必要があります。
詳細:
Azure Functions Flex ConsumptionにおけるTLS/SSL証明書サポートのパブリックプレビューについて説明します。本アップデートは、Flex Consumptionプランが利用可能な全リージョンにおいて、サイト単位で管理される証明書モデルを導入するものです。従来の他のホスティングプランでは、証明書はウェブスペース単位で管理されており、同一リージョンかつ同一リソースグループ内の複数アプリ間で共有されていました。しかし、Flex Consumptionでは、証明書が各サイトごとにスコープされるため、アプリごとに独立した証明書管理が可能となります。
具体的な機能としては、各Azure Functionsアプリケーションが独自のTLS/SSL証明書を持つことができ、これによりセキュリティや運用の柔軟性が向上します。証明書の導入や更新は、AzureポータルやAPIを通じてサイト単位で行うことができ、他のアプリケーションと証明書を共有する必要がなくなります。技術的な仕組みとしては、証明書のスコープがサイト単位であるため、証明書の管理やバインドは各Functionアプリの設定内で完結します。
活用シナリオとしては、複数のFunctionアプリを運用する際に、アプリごとに異なる証明書を適用したい場合や、証明書の更新やローテーションをアプリ単位で実施したい場合に有効です。また、セキュリティ要件が高い環境において、証明書の分離管理によるリスク低減が期待できます。
注意点としては、Flex Consumptionプランでのみ利用可能な機能であり、他のホスティングプランでは従来通りウェブスペース単位の証明書管理となります。また、パブリックプレビュー段階であるため、運用上の制限や今後の仕様変更が発生する可能性があります。
関連するAzureサービスとしては、Azure Key Vaultによる証明書管理や、Azure App Serviceとの連携が考えられますが、本アップデートはFlex ConsumptionプランのAzure Functionsに特化した証明書管理機能の提供となります。
このレポートは自動生成されました - 2026-05-22 12:01:24 JST