iCloud Private Relayの準備

♪ （iCloud Private Relayの準備） トミー・ポーリーです 同僚のデルジールと一緒に 今回はインターネット上の プライバシーを守るための エキサイティングな 新機能をご紹介します iCloud Private Relayは ネットワークやサーバーによる インターネット上でのユーザーの アクティビティの監視を 防ぐ新しいサービスです 全てのiCloud+サブスクリプションの 一部として利用可能です Private Relayは Web閲覧中のユーザーを 保護するだけでなくAppが 生成するトラフィックを保護して ユーザー情報を意図せずに 漏えいしたり ユーザーをセキュリティ攻撃に さらしたりしないようにします 今日はiCloud Private Relay とは何か Appにどのような影響を 与えるかを説明します AppをPrivate Relayと 連携させる方法 Webサイトとサーバーを 準備する方法 そして最後に Private Relayが有効な場合に ネットワークを管理しトラフィックを 監視する方法について説明します では始めましょう Private Relayは iOSとmacOSに 組み込まれているのでAppで 導入のために何かをする必要はありません また 常にAppに影響を 与えるわけではないことを 理解することも重要です この機能が適用されるのはユーザーが iCloud+ユーザーで Private Relayが 有効になっている場合だけです 実際には何をするのでしょうか Private Relayがない場合の 現状をここで説明します 誰かがインターネットに アクセスするとローカル ネットワーク上の誰でも DNSクエリの検査に基づいて アクセスする全てのWebサイトの 名前を確認できます この情報を使用してユーザーの フィンガープリントを作成し 時間の経過に伴うアクティビティの 履歴を作成できます 公共Wi-Fi事業者であれ ネットワーク上の 別のユーザーであれ インターネットサービス プロバイダーであれ 誰もこれらの情報をすべて黙って 収集するべきではないはずです 接続がWebサイトを実行する サーバーに到達すると それらのサーバーはユーザーの IPアドレスを参照できます これにより サーバーは明示的な許可なしに ユーザーの場所を判別できます さらに悪いことに SafariのITPのような ツールがクッキーによる 相関付けを防いでいる場合でも サーバはユーザーの身元を フィンガープリントで識別し 異なるWebサイトのユーザーを 認識することができます これらはユーザーのプライバシーに とって大きな問題であり それを解決するためには プライバシーがそのデザインに 組み込まれた新しいアプローチが必要です iCloud Private Relayは 複数のセキュアなプロキシを追加して プライベートな状態をキープしながら ユーザートラフィックをルーティングします プロキシは別々の エンティティによって実行されており 1つはAppleでもう1つは コンテンツプロバイダーです これで誰かがインターネットに アクセスすると クライアントのIPアドレスだけが ネットワークプロバイダと 最初のプロキシの両方に 表示されます 2番目のプロキシはユーザーが 要求している名前だけを確認し その名前を使用してサーバーへの 接続を構築します このチェーン内の誰も Appleでさえも クライアントのIPアドレスと ユーザーがアクセスしているものの 両方を見ることができないことに 注意してください フィンガープリントの 機会がなくなります これがデザインとして組み込まれた プライバシーです Private Relayは 最新のトランスポートプロトコルと プライバシー保護認証を使用して すべてのトランザクションが安全 かつ高速であることを保証します この技術の詳細については 「Appleがフォーカスする プライバシーの柱」を参照してください Private Relayは ユーザー体験に影響を与えずに システム上で最もセンシティブな トラフィックを保護することに 重点を置いています iOS 15とmacOS 12 では Private Relayは Safariの全てのWebブラウジング すべてのDNS名前解決クエリ Appからのトラフィックの 一部に適用されます 具体的には全ての保護 されていないHTTP通信に適用されます 例えばTCP Port 80などです Appが コンテンツフィルタ または保護者による制限 フィルタを提供している場合 Private Relayを通過する前に トラフィックが表示されるため 以前と同じようにフィルタを 適用できます 詳細については 「Screen Time APIについて」 を参照してください Appによって行われる すべてのネットワーキングが パブリックインターネット上で 行われるわけではないため Private Relayの 影響を受けない 通信にはいくつかの カテゴリーがあります Appがローカルネットワーク または プライベートドメイン名で行う 接続は影響を受けません 同様にAppが VPNまたはAppプロキシ機能を 追加するための ネットワークExtensionを提供する場合 ExtensionはPrivate Relayを使用せず Extensionを使用する Appの通信も同様です プロキシを使用する トラフィックも免除されます 次にAppが Private Relayと うまく連携するために 必要なことを説明します 素晴らしいことに ほとんど全てのAppで 新しいことをする必要はありません Private Relayがそのまま機能します ただし知っておくべきベスト プラクティスがいくつかあります Private Relayは 使用しているネットワーク APIに関係なく動作します 数年前から URLSessionや NWConnectionなどの 最新APIを使用を推奨しています これでApp全体に 採用する理由が1つ増えました これらのAPIは Private Relayが 通信にどのように適用しているかを 理解する最適なツールを提供します URLSessionを使用すると プライベートリレーを 使用している場合でも Network Xcode Instrumentを 使用してタスクを検査できます この方法の詳細については 「InstrumentsでのHTTPトラフィックの解析」 セッションを参照してください また URLSessionと Network.frameworkの 両方でmetrics APIを 使用して 接続がPrivate Relayを 使用している場合を把握できます TaskTransactionMetrics では タスクでプロキシが使用 されているかどうかを確認できます NWConnectionの EstablishmentRePortでは DNS名前解決のタイミングと プロキシ接続確立の各段階も 検査できます Private Relayは 暗号化されていない安全でない HTTP接続を過去のものにする 大きな一歩を踏み出しています この取り組みにも ご参加いただけます まだセキュアでないHTTP TCP Port 80での接続を 使用しているのであれば 今こそ変更すべき時です Private Relayを有効化すると これらの安全でない 接続がプロキシされ クライアントとプロキシ間の ローカルネットワーク上の 攻撃者から保護されます しかしすべてのユーザー に対してエンドツーエンドの 安全な接続を確立することを 依然としてお勧めします これを行うにはサーバーがTLSを サポートしていることを確認し URLをhttp://から https://に変更します Appには 安全でない通信を許可する App Transport Securityの 例外の場合があるかもしれません このリストを見てAppが 使用する安全でない通信を監査し これらの例外を削除できます Appが位置情報に基づく機能を 提供しているのであれば IPアドレスから位置情報を 推測するサーバに頼るのではなく Core Locationから APIを使用していることを 確認するのにも良いタイミングです IPアドレスの位置情報は信頼性が 低く不正確なことがよくあります Core Locationを使用すると 必要なロケーションの精度を 指定できます この精度は 明示的なユーザー権限に基づきます 位置情報へのアクセスに 関する最新の機能強化については 「Appleがフォーカスする プライバシーの柱」 セッションを参照してください Private Relayに対して Appの準備が整っていることを確認して 試してみてください iCloud+に登録して iPhone iPad またはMacにサインインし 設定Appの iCloud セクション またはシステム環境設定で Private Relayが 有効になっていることを確認します フィードバックAppで 「iCloud Private Relay」 というタグを付けて フィードバックを提供できます 同僚のデルジールにつなげます トミー ありがとう デルジール・フェルナンデス です Private Relayを 使ってサーバを準備し ネットワークを管理する 方法についてお話しします Appが依存するサーバや Safariでユーザーが アクセスするサーバがある場合 Private Relayに備えるために することがいくつかあります サーバはプロキシIPアドレスを 認識することによって Private Relayを 使用している 接続を識別できます これらのプロキシIPアドレスは 地域の中の多くの ユーザーで共有される場合が考えられます 各アドレスは特定の都市または 地域にマッピングされます 従って正しいgeoIPマッピング データベースを適用すれば サーバには関連性の高い情報が 残ることになります Private Relayは ユーザーがシステムを使用して 別のリージョンのユーザー であるかのように 見せかけることができないことを 保証するため 引き続きリージョンベースの アクセス制限を適用できます プロキシIPアドレスの 詳細については このセッションに関連づけられた 記事を参照してください 次に Private Relayを 使用するデバイスからの ネットワーク接続についてです デバイスがサーバに アクセスしようとすると 最初にIngressプロキシへの ネットワーク接続が設定されます この接続はネットワーク プロバイダによって 割り当てられたIPアドレスを 使用して設定されます 次に デバイスはIngressプロキシを使用して IngressプロキシIPアドレスを 使用してネットワークリクエストを Egressプロキシに転送します 次に Egressプロキシはデバイスの 都市またはリージョンにマッピング されたIPアドレスを選択して これらのリクエストを 宛先のサーバに転送します 一般に サーバーとWebサイトは ユーザーの場所やIDを 判断するために クライアントIPアドレスだけに 依存するのをやめる必要があります ロケーションアクセスが必要な場合は ユーザーのロケーションを 明示的に要求し 必要な粒度でのみ要求することを 検討してください ユーザーを識別する必要がある場合 IPアドレスがIDに関連付けられ ていると仮定するのではなく ログインまたはその他の形式の 明示的なIDを要求します 最後にPrivate Relay を使用しているときに ネットワークを管理するための ヒントをいくつか紹介します Private Relayの使用中に ローカルネットワークで パケットトレースを実行している 場合は いくつかの新しい通信パターンが 表示されます UDP Port 443で より多くの通信が実行されています これは QUICまたは HTTP/3の Private Relay プロキシとの 通信に使用される トラフィックです。 ネットワークで UDP Port 443を許可し ルータ又は Network Address Translatorsが 適切に処理されるように 調整することで 確実に通信が正常に動作します ネットワーク上のclearText UDP DNS クエリも少なくなります こちらは Private Relayが 使用されていない場合の デバイスからの一般的な ネットワーク接続リクエストです デバイスがサーバに アクセスしようとすると まずサーバのホスト名の DNSクエリが送信されます ホスト名がIPアドレスに 解決されると デバイスはTCPなどの トランスポートプロトコルで サーバのIPアドレスに接続します 次にデバイスはサーバとの TCP 3ウェイハンドシェイクを 実行し 続いてTLS交換を 実行して サーバとのセキュアな接続を 設定します ただし Private Relayを 使用しない場合 サーバのホスト名とサーバに 接続するデバイスのIPアドレスは ネットワーク上のパケットを 監視するだけで表示されます Private Relayでは デバイスは最初にQUICまたは HTTP/3を使用して Ingressプロキシへの接続を 設定します パケットキャプチャでは UDPパケットがIngressプロキシの Port 443に送信されます ネットワーク接続が Ingressプロキシに対し確立されると サーバへのアクセスは Ingressプロキシへの接続内で 保護されます サーバ側では プロトコルに変更はありません TCP/TLS交換は Private Relayを使用しない 場合の通信と似ています 唯一の違いは サーバがデバイスの IPアドレスではなく プロキシIPアドレスからの 着信接続を認識することです ほとんどのネットワークでは 全てのユーザートラフィックを監査 またはモニタする必要はありません 但しエンタープライズネットワーク 又は学校ネットワークを 実行している場合はすべての 通信の代行受信を必要とする ポリシーがネットワークに存在する 可能性があります このユースケースをサポート するためにiCloud Private Relay プロキシサーバのホスト名を ブロックできます その後デバイスが ネットワークに接続すると 現在のネットワークで Private Relayが ブロックされていることを示す プロンプトが表示されます その後そのネットワークで Private Relayを無効にするか ネットワークを切り替えるか を選択できます プロキシのホスト名に関する情報は このセッションに関連する記事 にて参照できます ペアレンタルコントロールを 設定する場合は NetworkExtension フレームワークが提供する コンテンツフィルタAPIを 使用することをお勧めします これにより Private Relayが 有効になっている場合でも デバイス上の通信を監査できます Content Filter APIの詳細については 「Screen Time APIについて」 および 「最新のMacのためのNetwork Extension」 を参照してください まとめます URLSessionなどの 最新の安全なネットワークAPIを Appで使用してください Private Relayで Appをテストし またサーバーとWebサイトが Private Relay経由で ルーティングされた接続を受信した 時に正常な動作を確認します ご覧くださり ありがとうございました ♪