次の方法で共有

いろいろな場所へ

  • [アーティクル]

携帯電話への IPsec VPN の導入

Ramon Arjona

今日の午後、オフィスを離れていたとき携帯電話に電子メールが着信しました。メッセージにはドキュメントへのリンクが含まれ、それを読んでおくよう指示されていましたが、そのドキュメントは社内のイントラネットからしかアクセスできない SharePoint サイトのドキュメントでした。これにはがっかりしました。ドキュメントを読むには、近くのカフェでラップトップを起動し、スマート カードをスマート カード リーダーに挿入し、Wi-Fi 接続 を確立して、会社の VPN にラップトップを接続し、さらにログオンできるまで待たなければなりません。

携帯電話から SharePoint サイトにアクセスできれば、事ははるかに簡単です。もちろん、そのためには携帯電話に企業ネットワークに安全に接続して認証を受ける便利な方法が必要です。つまり、ラップトップと同様に、携帯電話にもネットワークへの VPN 接続を開始する機能が必要になります。Windows phone など、多数の商用電話モデルには、VPN クライアントが組み込まれています。しかし、最も普及している VPN クライアントは、インターネット キー交換と呼ばれる仕様のバージョン 1 (IKEv1) に基づいているため弱点があります。IKEv1 は、IPsec フレームワークの中でも安定した部分で、ケーブルで接続されたデバイス、またはあまり移動されない比較的大きなバッテリを備えたデバイス (ラップトップなど) に非常に適しています。しかし、携帯電話には最適とは言えません。

もちろん、オフィスと会議室を往復するのであればラップトップでワイヤレス接続を使用します。ワイヤレス接続とケーブル接続の切り替えでは、接続は中断しないと想定されます。しかし、ラップトップを携えて移動することは、携帯電話ほど多くありません。携帯電話は、ユーザーが携行し、交通機関を利用し、建物に出入りする間、ローミング状態に移行したりそこから戻ったりします。ラップトップでは携帯電話用モデムを使用していない限り、"ローミング中" という通知を受けることはほとんどありません。一般に、携帯電話では、ラップトップでは想像できないほどの頻度と複雑さでネットワーク接続ポイントが変化します。IKEv1 仕様を検討していた頃は、こうした携帯電話のシナリオを気にすることもありませんでした。RFC 2409 が作成された 1990 年代末、スマート フォンは市場に普及していませんでした。それ以降、携帯電話の使用は急速に広まり、その重要性は、ワークステーションやラップトップなど他のもっと大型のコンピューティング デバイスの重要性に近づき始めました。

IKEv1 には、ネットワーク接続のポイントが数秒間に何回も変化するホストに対処する適切な方法がないため、機動性の高いスタイルのコンピューティングにはあまり適していません。IKEv2 の草案が作成されたとき、携帯電話のシナリオに対応するために、Mobility and Multihoming (MOBIKE: モビリティおよびマルチホーミング) プロトコルと呼ばれる拡張機能のセットの草案も作成されました。この拡張機能のセットを使用すると、携帯電話の VPN の実用性が大きく向上します。IKEv2 と MOBIKE は、Microsoft Systems Center Mobile Device Manager (SCMDM) など、いくつかの市販の製品でサポートされています。

今回のコラムでは、IKEv2 と MOBIKE の基盤となるテクノロジの基本について説明します。ここでは、IPv4 とネットワークに関する実用的な知識があり、携帯電話をある程度知っていて、暗号についての基礎知識があることを前提としています。今回は、IPsec の詳細や、SSL ベースの VPN など、その他の種類の VPN テクノロジについては説明しない予定です。また、IPv6 についても踏み込みません。IPsec と IKE は、IPv4 の拡張機能ですが、IPv6 に組み込まれているため、今回のコラムで触れるテクノロジの一部は IPv6 ネットワークにも適用できます。しかし、IPv6 を説明し始めると、ここでは十分詳しく説明できないほど複雑になり、新しい用語も必要になってしまいます。

AH

IPsec の中核部分は、認証ヘッダー (AH)、カプセル化セキュリティ ペイロード (ESP)、および IKE という 3 つのプロトコルから構成されています。IKE について説明するには、まず AH と ESP について取り上げる必要があります。

かいつまんで言うと、AH は送信したパケットが改ざんされていないことを確認し、パケットの整合性を保護します。また、パケットの送信元を主張する送信者から実際にパケットが送信されていることも保証し、パケットの信頼性を確保します。ただし、AH には、プライバシーや暗号化に関する対策はまったく用意されていません。ネットワークへのアクセスに成功した攻撃者が AH で保護されたパケットを傍受して、コンテンツを抽出する危険性は残っています。しかし、攻撃者は認証済みのいずれかの当事者を偽装することも、転送中のパケットを変更することもできません。AH は RFC 4302 で定義されています。

たとえば、Alice と Bob が互いの間で VPN 接続を確立し、パケットを AH で保護することにしたとしましょう。Charlie がネットワークに侵入し、パケットの傍受を開始します。Charlie は、パケットのコンテンツを確認して 2 人の間で送信されているトラフィックの種類を把握できるため、Alice と Bob のやり取りを再構築できます。しかし、Charlie は正体を隠して Alice から Bob へのメッセージを偽造することはできず、Bob から Alice へのメッセージを改ざんすることもできません。どちらの行為も、AH によって阻止されます。

AH は、トランスポート モードまたはトンネル モードで使用できます。トランスポート モードでは、パケットのペイロードが保護され、パケットはホスト間で直接ルーティングされます。トンネル モードでは、パケット全体が AH で保護され、パケットは IPsec トンネルの片側から相手側にルーティングされます。トンネリングは、元のパケットをカプセル化することで行われます。トンネルのいずれか一方はセキュリティ ゲートウェイです。パケットの送信側ゲートウェイでは、"外部" の IP ヘッダーとアドレスが追加され、送信対象のパケットがカプセル化されます。この外部アドレスによって、パケットがトンネルの相手側にあるセキュリティ ゲートウェイにルーティングされます。パケットの受信側ゲートウェイでは、AH が処理されて、パケットが有効な送信者から送信されたことと改ざんされていないことが確認されてから、そのパケットが最終的な送信先にルーティングされます。

トランスポート モードでは、AH はパケットの IP ヘッダーの直後に追加されます。AH の追加場所は、パケットの次の層のプロトコル (UDP、TCP など) より前で、かつパケット内の他の IPsec ヘッダー (ESP ヘッダーなど) よりも前です。AH の前の IP ヘッダーには、51 という値が設定されている必要があります。この値は IANA によって AH に割り当てられた特殊な数値であり、パケットを処理するアプリケーションに対し、次に指定されているヘッダーが AH であることを通知します。図 1 は、AH を追加した後のパケットの構造を示しています。

トンネル モードでは、AH は新しい IP ヘッダーの後に追加されます。カプセル化された IP ヘッダーは、他のすべての要素と共にペイロードの一部として処理されます。これを図 2 に示します。AH で保護されているパケットの最初の 8 ビットは、AH の次に指定されるペイロードのプロトコル ID を指定します。プロトコル ID では、AH ペイロードの後に想定されるペイロードを受信側に通知します。たとえば、次の層のプロトコルが TCP の場合、プロトコル ID は 6 に設定されます。このフィールドは、"次のヘッダー" と呼ばれます (このフィールドがどうして IPv4 の他のヘッダーと一貫性のある "プロトコル" という名前で呼ばれないのか、疑問に思う方もいらっしゃるでしょう。その理由は、IPv6 との一貫性と互換性を確保するためです。さいわい、IPv4 での AH のしくみを理解するには IPv6 についてそれほど知る必要はありませんが、このフィールドが "次のヘッダー" と呼ばれている理由が気になった方のために補足しました)。

次の 7 ビットに指定されるのは、AH ペイロードの長さです。7 ビットしかないため、ペイロードのサイズは 128 バイトに制限されます。AH ペイロードの次は、0 の長い文字列です （実際には 2 バイトあります）。この 2 バイトは、RFC での将来の使用に備えて予約されているため、将来の使用法が定義されるまでは何も指定しない空の 2 バイトを追加します。

この 2 バイトの次は、セキュリティ パラメーター インデックス (SPI) です。これは 32 ビットの数値で、AH を関連付ける IPsec セキュリティ アソシエーション (SA) を定義するために使用されます。SA の詳細については、IKEv2 に関するセクションで説明します。この数値の次には、32 ビットのシーケンス番号が指定されます。シーケンス番号は、送信される各パケットに実装され、リプレイ攻撃を防ぐために使用されます。

シーケンス番号の次は、整合性チェック値 (ICV) です。ICV は、送信側で SHA-2 などのハッシュ関数を IP ヘッダー、AH、およびペイロードに適用することで計算されます。受信側では、同じハッシュ関数を適用して同じハッシュが生成されることを確認されて、パケットが改ざんされていないことがチェックされます。

ESP

AH と同様、カプセル化セキュリティ ペイロード (ESP) でも、整合性と認証が提供されます。ただし AH とは異なり、ESP ではパケット ペイロードに対してのみ認証と整合性が提供され、パケット ヘッダーに対しては提供されません。ESP を使用すると、パケット ペイロードを暗号化して機密性を確保することもできます。ESP のこのような機能は個別に有効にできるため、理論上、認証と整合性を確保せずに暗号化することも、暗号化せずに認証と整合性を確保することもできます。しかし実際には、他の機能を有効にせずにある機能だけを有効にしても、あまり意味がありません。たとえば、送信されたメッセージの機密性が保証されても、そのメッセージの送信者について完全に確信できなければ、受信者にとってメリットはありません。ESP は RFC 4303 で定義されています。

ESP は、AH と同様にトンネル モードまたはトランスポート モードで有効にできます。ESP ヘッダーは、AH の後に挿入する必要があります。トランスポート モードでは、ESP によって IP パケットのペイロードが暗号化されます。トンネル モードでは、カプセル化されたパケット全体が ESP によってペイロードとして処理され、暗号化されます。これを示したものが図 3 です。

暗号化アルゴリズムは、IPsec SA を構成するピア間のネゴシエーション処理を通じて選択されます。高度暗号化標準 (AES) は、最新の実装でよく選択される暗号化アルゴリズムです。もちろん、AES を使用するには、まずセキュリティ保護された通信を開始する 2 つのホスト間で、共有シークレットを設定する必要があります。ホストに手動で共有キーを付与する手法は、規模を拡大できないので実用的ではありませんが、Diffie-Hellman (DH) キー交換を使用してシークレットをプロビジョニングできます。

Diffie-Hellman グループ

DH は、セキュリティ保護されていないチャネル経由で 2 人の当事者がシークレットを共有できるようにするプロトコルで、IKE で実行されるネゴシエーションに不可欠な要素です。DH 経由で通信される共有シークレットを使用すると、安全に暗号化された通信チャネルを作成できます。DH に使用される計算は複雑なので、ここでは詳しく説明しません。DH のしくみの詳細について関心のある方は、べき乗剰余 (MODP) グループ、および MODP グループの DH への適用に関するリソースを参照してください。ここでは、DH グループは、数学的関係と一意グループ ID が設定された数値の特定のコレクションだと説明するだけにとどめます。

DH グループは、セキュリティ保護された接続が IKE ネゴシエーションの間で IPsec によって確立されるときに指定されます。このネゴシエーションでは、セキュリティ保護された接続を確立しようとしている 2 つのピアで、両方のピアでサポートされる DH グループを特定する必要があります。ID 値が大きい DH グループほど、暗号の強度が高まります。たとえば、最初の IKE 仕様で触れられていた最初の DH グループの暗号強度は、70 ～ 80 ビットの対称キーと同程度でした。AES などのさらに強力な暗号化アルゴリズムが開発されると、DH グループが一連の暗号化処理の弱点とならないよう、さらなる強度が求められるようになりました。このため、RFC 3526 で指定された新しい DH グループでは、90 ～ 190 ビット相当と見積もられている強度が確保されます。

これらの新しい DH グループの弱点は、強度を向上するのにコストがかかることです。グループが強化されるほど、必要な処理時間が長くなります。これは、両方のピアが許容できる DH グループについて相互にネゴシエートが必要になる一因となっています。たとえば、手元の携帯電話には DH グループ 15 に対処できるほどの処理能力がなく、DH グループ 2 をサポートすることを希望するとします。サーバーとの IPsec 接続を確立しようとするときに、携帯電話からは DH グループ 2 が提示されます。サーバーで DH グループ 2 がサポートされていれば、サーバーでより強力な DH グループを使用できたとしても、そのグループが使用されます。もちろん、2 つのピアで共通の DH グループを決定できない場合、これらのピア間では通信できません。

背景については以上で十分でしょう。IKE の説明に移りましょう。

IKE

IKE は、ピア間で IPsec 接続を確立するために使用されます。この接続は、セキュリティ アソシエーション (SA) と呼ばれます。SA には、IKE_SA と CHILD_SA の 2 種類があります。先に設定されるのは、IKE_SA です。これは、共有シークレットが DH を介してネゴシエートされる場所であり、暗号化アルゴリズムとハッシュ アルゴリズムがネゴシエートされる場所でもあります。CHILD_SA は、ネットワーク トラフィックが送信されて、AH、ESP、またはその両方で保護される場所です。

IKE のすべての要求には応答が必要なので、メッセージのペアを単位として考えるとわかりやすくなります。最初のメッセージのペアは IKE_SA_INIT と呼ばれ、ピアで使用する暗号アルゴリズムと DH グループを決定するために使用されます。このメッセージ交換ではまだ暗号の決定中なので、このメッセージ ペアは暗号化されません。メッセージの次のペアは、IKE_SA_AUTH と呼ばれます。この交換では、IKE_SA_INT 中に送信されたメッセージが認証され、イニシエーターとレスポンダーが本物であることが証明されます。最初のメッセージが暗号化されずに送信されているため、この手順は不可欠です。つまり、セキュリティ保護されたチャネルが確立されたら、ピアでは互いに、本当に相手に名乗っているとおりのピアであること、および本当にこのメッセージ交換を開始しようとしていることを証明する必要があります。IKE_SA_AUTH メッセージ交換では、最初の CHILD_SA も設定されます。この CHILD_SA は、多くの場合、ピア間で作成される唯一の CHILD_SA です。

CHILD_SA は、シンプレックス (一方向) 接続なので、CHILD_SA は必ずペアで設定されます。ペアの一方の SA が削除されると、もう一方の SA も削除されます。IKE では INFORMATIONAL メッセージを通じてこの処理が実行されます。RFC 4306 に従い、INFORMATIONAL メッセージには 0 以上の Notification メッセージ、Delete メッセージ、または Configuration メッセージが含まれます。たとえば、PC をイニシエーター、サーバーをレスポンダーとしましょう。PC では、CHILD_SA 接続を閉じて VPN を終了することに決めたとします。PC からサーバーに Delete ペイロードを含む INFORMATIONAL メッセージが送信され、削除対象の SA が SPI によって特定されます。続いて、サーバーでこの着信 SA が削除され、PC 側に残っている SA を削除するよう求める応答が PC に送信されます。PC がこのメッセージを受信すると、SA の PC 側の残りの部分が削除されて、すべての処理が完了します。

もちろん、必ずこのように機能するとは限りません。イニシエーターとレスポンダーのいずれかで SA が "半分閉じた" 状態 (SA ペアの一方のメンバーが閉じ、もう一方が開いたままになっている状態) になることがあります。RFC では、これは異常状態に指定されていますが、このような半開接続をピアで独自に閉じることは許可されていません。その代わり、接続状態がある程度不安定になった場合にピアで IKE_SA を削除するよう指定されています。ただし、IKE_SA を削除すると、その IKE_SA の子として作成されたすべての CHILD_SA が削除されます。携帯電話にとっては、IKE_SA を削除して再構築するのも、CHILD_SA を開いたままにしても少ないシステム リソースを消費するのも厄介です。

また、SA の一方のピアからもう一方のシステムに終了を通知しないで、そのピアが完全に見えなくなる可能性があります。これは、携帯電話の場合に特に発生しやすい状況です。たとえば、携帯電話のユーザーがサーバーとの間に IPsec VPN 接続を確立したシナリオを考えてみましょう。携帯電話のユーザーが地下に移動すると、そのユーザーの無線信号が途切れます。サーバーには携帯電話がブラック ホール内に消えたことを検出する手段がないため、サーバーから CHILD_SA にメッセージが送信され続けますが、応答は受信されません。同様に、移動体通信ネットワークのルーティングに関する問題が原因で、携帯電話からブラック ホールにメッセージが送信され始めることも考えられます。一方のピアがもう一方のピアを追跡できなくなるあらゆる状況からこのような問題が発生する可能性がありますが、携帯電話はサーバーよりリソースが少ないので、携帯電話のコストはサーバーのコストよりも大きくなります。

SA を破棄して再構築することが望ましくない理由

答えをひと言で言えば、SA を破棄して再構築すると、携帯電話では受け入れられないほど大量のリソースが使用されるためです。具体的には、暗号化処理を実行する場合や大量のデータの送受信に無線を使用している場合は、CPU が消費されます。どちらの状況でも、バッテリの寿命が短くなります。大量のデータを転送している場合は、帯域幅も消費されるので費用がかかります。特に、KB 単位で課金されるデータ プランの場合は多くの費用がかかります。

メッセージを無線で送信するには処理能力がかかり、しかも携帯電話の処理能力は限られているため、携帯電話ではこのようなブラック ホールの状況を検出して対処し、システム リソースを節約する必要があります。通常、この機能は Dead Peer Detection (DPD: 停止しているピアの検出) というプロセスによって処理されます。DPD では、ブラック ホールと通信していると疑われるピアから、機能している証拠を要求するメッセージが送信されます。この要求の相手が適切な時間内に応答しなければ、送信側ピアでは、適切な処理を実行して IKE_SA を削除し、この接続に使用されていたリソースを再利用できます。一般に、他にSA を通じて送受信されているトラフィックがなく、SA の相手側が存在しなくなったと疑う根拠がピアにある場合にのみ、DPD メッセージを送信することをお勧めします。この方法で DPD を実装する際の要件はありませんが、その他の種類のネットワーク トラフィックを現在送信しているピアが機能しているかどうかを確認してもあまり意味はありません。

VPN 接続で問題の原因となる別の状況としては、IP アドレスが変化するホストがあります。ホストの IP アドレスは、32 ビットの SPI と共に、特定のホストを識別して SA と関連付けるために使用されます。ホストで IP アドレスが失われると、この関連付けも失われるので、SA を破棄して新しい IP アドレスで再作成する必要があります。

既に説明したように、この状況はデスクトップやラップトップではそれほど問題になりません。PC では、DHCP リースが失われて新しい IP アドレスが取得される場合もありますが、ほとんどの DHCP 実装では、それまで割り当てられていた IP アドレスと同じ IP アドレスが高い確率で PC に割り当てられます。つまり、デスクトップ PC では IP アドレスはあまり変化しません。ラップトップはモバイル デバイスなので、ネットワーク接続のポイントが変更されて新しい IP アドレスが取得されることがあります。この結果、開かれていたすべての SA が破棄されて再作成されます。しかし、携帯電話に比べれば、ラップトップの IP アドレスが切り替わる頻度はやはり比較的低いと言えます。たとえば、Wi-Fi チャネルと移動体チャネル経由のデータ転送機能がある携帯電話では、ユーザーがオフィス ビルを出入りして携帯電話が Wi-Fi から GPRS 接続に変化したり戻ったりするたびに、ネットワークが切り替わることがあります。オフィス ビルの周囲を移動するラップトップは同じネットワーク リンクにとどまるので、正しいトポロジのネットワーク アドレスが変更されることなく継続して保持されますが、携帯電話は 2 つの根本的に異なるネットワーク間で切り替わるので、ほぼ確実に IP アドレスが変更されます。そのため、ネットワーク間のハンドオフが発生するたびに携帯電話の接続が中断されます。携帯電話が移動体通信ネットワークだけに接続している場合でも、同様の問題が発生します。携帯電話がローミング モードになると、その携帯電話のホーム ネットワークから別の携帯電話会社が所有する外部ネットワークに切り替わることがあります。また、携帯電話があるサービス エリアから別のサービス エリアに移動すると、携帯電話会社のネットワークのまったく異なる部分に接続されることもあります。

携帯電話会社が制御している、接続が中断される原因となる要因は、他にも多数あります。このように SA が頻繁に破棄されて再構築されるため、MOBIKE という IKEv2 の拡張機能がなければ、モバイル VPN を扱うのは難しかったでしょう。

MOBIKE

IKEv2 MOBIKE プロトコルは RFC 4555 で定義されています。RFC 4555 では、IPsec VPN のピアで、複数の IP アドレスがそのピアにあることをアドバタイズすることを許可しています。このようなアドレスの 1 つが、そのピアの SA に関連付けられます。ネットワーク接続が変化することでピアの IP アドレスが切り替わると、SA を破棄して再構築しなくても、既に特定されていた IP アドレスの 1 つ、または新しく割り当てられたアドレスに変更できます。

MOBIKE を使用できることを示すために、ピアの IKE_AUTH 交換には MOBIKE_SUPPORTED 通知が含まれます。IKE_AUTH 交換には、イニシエーターとレスポンダーの追加アドレスも含まれています。イニシエーターは、最初の IKE メッセージを送信して VPN の設定を開始したデバイスです。イニシエーターでは、イニシエーターで使用できる IP アドレス、およびレスポンダーから提供された IP アドレスの中から使用する IP アドレスを決定します。

RFC に述べられているように、通常、イニシエーターはモバイル デバイスです。これは、モバイル デバイスはサーバよりもネットワーク上の位置を認識しやすいので、使用するアドレスの決定により適しているためです。しかし、RFC にはこのような決定を下す方法が指定されていません。一般には、IPsec VPN の一方がモバイル デバイスになり、もう一方が据え置き型のセキュリティ ゲートウェイ サーバーになります。仕様では、このような実装は要求されておらず、ゲートウェイの両側をモバイル デバイスにすることも許可されています。しかし、ゲートウェイの両側のデバイスが同時に移動した場合に互いを検出する手段は提供されていません。つまり、一方のピアのアドレスが更新されると同時にもう一方のピアでもアドレスが更新された場合、どちらのピアにもこの変更を通知できないので、VPN 接続が中断されます。

イニシエーターでは、レスポンダーのアドレス一覧が使用されて、SA に使用するのに最適なアドレスのペアが決定されます。レスポンダーでは、レスポンダーのアドレスが変更されたことをイニシエーターに通知する場合を除いて、イニシエーターのアドレスは使用されません。

たとえば、イニシエーターでは、イニシエーターのアドレスが変化したことを認識した場合、UPDATE_SA_ADDRESSES 通知を含む INFORMATIONAL メッセージを使用してこの情報をレスポンダーに通知します。INFORMATIONAL メッセージには新しいアドレスが使用され、ピアの ESP メッセージでこのアドレスが使用されるようになります。更新通知の受信側では、新しいアドレスが記録されます。また、必要に応じて、往復経路確認がチェックされて、通知のとおりにアドレスが相手側のモバイル ノードに属していることが確認されます。その後、レスポンダーで新しいアドレスが発信 ESP トラフィックに使用されるようになります。

もちろん、イニシエーターやレスポンダーでは、SA の有効期間中に使用される IP アドレスすべてが把握されてはいないこともあります。ピアでは、NFORMATIONAL メッセージを使用して、サポートするアドレスの一覧が変更されたことを通知できます。ピアのアドレスが 1 つだけの場合は、このアドレスがヘッダーに記述され、INFORMATIONAL メッセージには NO_ADDITIONAL_ADDRESSES 通知が含まれます。それ以外の、ピアに複数のアドレスがある場合は、これらのアドレスのいずれかが INFORMATIONAL メッセージのヘッダーに記述され、他のアドレスは ADDITIONAL_IP4_ADDRESS 通知に含まれます。

この一覧は、更新内容ではなく、その時点でピアから通知されるアドレスの完全な一覧です。つまり、毎回完全な一覧が送信されますが、そのコストは、携帯電話でネットワーク接続のポイントが変化するたびに SA を破棄して再構築するコストよりも低くなります。

まとめ

これで、IPsec VPN と MOBIKE の組み合わせが携帯電話で機能するしくみの概要を理解いただけたことでしょう。

スマート フォンが家庭や職場に普及するにつれ、ユーザーはリソースが豊富なコンピューティング デバイスに匹敵するエクスペリエンスを求めるようになっているため、このようなソリューションの重要性は増しつつあります。今のところは、ユーザーは企業ネットワークに接続できない携帯電話、バッテリの寿命が 1 日しかない携帯電話、および現在すべてのユーザーにおなじみの、スマート フォンのその他の弱点がある携帯電話を許容しています。この状況が長続きすることはありません。競争とより優れたハードウェアの出現によって、ラップトップやデスクトップと同等のエクスペリエンスを実現する、完成度がより高いエンド ツー エンド ソリューションがますます採用されるようになるでしょう。

そして、すべてのユーザーは携帯電話のリンクをクリックするだけで、企業の SharePoint サイトを参照できるようになるでしょう。

今回のコラムに対する提案とテクニカル レビューに協力してくれた Melissa Johnson に感謝します。

Ramon Arjona は、マイクロソフトの SDET リードです。