AppとサーバのDNSセキュリティの改善

AppとサーバのDNSセキュリティの改善

App内において、インターネットアドレスの基盤であるDNSの安全性を確保する方法に関する最新情報をご確認ください。DNSSECを使用してAppでのDNSレスポンスを認証し、Discovery of Designated Resolvers（DDR）を使用してDNS暗号化を自動的に有効化する方法を紹介します。

リソース
- - HDビデオ
  - SDビデオ
関連ビデオ

WWDC20
- 暗号化DNSの有効化
ダウンロード

こんにちは「AppとサーバーのDNS セキュリティの改善」へようこそ私はQiaoyu Dengですこのビデオでは DNSがしばしば安全でない理由と DNSSECとDDRによる暗号化DNSを使って保護する方法についてご説明しますまずなぜDNSは安全でないのかお話します
DNSはインターネットの電話帳です人間が読みやすく覚えやすいドメイン名を機械用に作られた IPアドレスに変換しているのです TCP TLS QUICなどの他のインターネットプロトコルは IPアドレスを持つことに依拠するためすべてはDNSから始まります現在 TLSはインターネット通信の安全性を確保するために広く利用されていますそれはいいのですが基盤となるレイヤである DNSにはセキュリティ上の問題があります DNSは歴史的に安全とは言えません 1983年当時セキュリティを考慮せずに設計されましたそれ以来多数のDNS攻撃が生み出されました例えば DNSキャッシュポイズニングは攻撃者がDNSリゾルバの欠陥を利用して不正なIPアドレスをキャッシュさせクライアントが悪意のあるホストに接続するよう仕向けるものですこれは DNSの脆弱性をひとつ明らかにしました：認証されないということです従来のDNSクライアントは回答を検証する方法がなく簡単になりすましができます DNSスニッフィングもよくある攻撃で攻撃者はクライアントとDNSサーバー間の DNSトラフィックを監視し　クライアントの履歴を収集しますユーザーのプライバシーに関わる重大な問題ですこの攻撃が可能な理由はもともと DNSのトラフィックは暗号化されていないからです DNSはその上に構築されるプロトコルの安全な出発点となるために認証と暗号化の両方が必要です DNSSECを使用して DNSレスポンスに署名すると認証が提供されます TLSとHTTPSを使用して DNSの解決を暗号化するとプライバシーが確保されます次に DNSSECについてお話しします DNSSECは IETFが策定した拡張仕様のスイートですすでに多くのDNSサービスプロバイダが対応済みですがクライアント側の対応はまだこれからです iOS 16とmacOS Venturaがクライアント側の DNSSEC検証に対応しています DNSSECはデジタル署名の追加によってデータの認証を保証するのでデータの整合性を保護します答えが存在しないときに存在を否定することを認証するのですまた暗号による認証も可能です DNSSECは応答に署名を添付することでデータの整合性を保護します攻撃者によって応答が改ざんされた場合改ざんされたデータの署名は元の署名と一致しませんクライアントは変更された応答を検出し破棄できますまた DNSSECは NSECレコードのような特殊なDNSレコードを用いることでゾーン内のレコードの存在や非存在を主張します NSECレコードは次のレコード名が何かアルファベット順に安全に教えてくれますリストアップされた名前は存在するものでありされていない名前は存在しないものとみなします例えばここに3つの NSECレコードがありますレコードセットからゾーンorgには A.org C.org E.orgの 3つのレコード名しかないとわかります「A.orgは存在しない」という攻撃者がいた場合クライアントはこの攻撃を検知できます A.orgは最初のNSECレコードに載っているため存在します同様に攻撃者が「D.orgが存在する」と言った場合 2つ目の NSECレコードによれば D.orgはC.orgとE.orgの間にあり 2つの名前の間には名前が存在しないためクライアントも攻撃を検知できます DNSSECは信頼の連鎖の確立でレコードを認証しますこれはその一例ですあるデバイスが DNSSEC検証を有効にして www.example.org を解決したがっています IPアドレス署名鍵を要求するクエリを送信しますその応答により IPアドレスから鍵番号1までの信頼関係が構築できますそしてクライアントは親ゾーンのorgに問い合わせ鍵番号1を認証できるレコードを要求することで鍵番号1から鍵番号2への信頼関係を構築しますそのためデバイスはルートに到達するまでこのプロセスを再帰的に繰り返しますここで図中の鍵番号3であるルートキーが信頼できれば IPアドレスから鍵番号3までの信頼関係が認証できますルートキーのハッシュは常にデバイスに安全に保存されます DNSSECではルートトラストアンカーと呼ばれています鍵番号3のハッシュがプリインストール済みのアンカーと一致すれば安全に信頼の連鎖が構築できますトラストチェーンによりこれで www.example.orgの IPアドレスは認証されます AppでDNSSEC検証を必要とする場合必要なことは次の通りですまずはドメインのIPv6対応 IPv6専用環境では IPv4専用アドレスは合成IPv6アドレスに変換されますドメインが署名されている場合合成されたアドレスは DNSSECの検証を通過できず DNSSECを有効にしても到達不可能となるのでドメインがIPv6に対応することを確認してください DNSサービスプロバイダが DNSSECでドメインに署名していることを確認してくださいドメインに署名せず AppでDNSSECを有効にすると署名していないドメインの認証を試みるため DNSトラフィックが増加し解決が長引きます対応するインフラサポートが完了したら Appに DNSSECを採用するために必要なコードがこちらです NSURLSession クライアントであれば URLリクエストに DNSSEC検証を要求できますこれはその一例ですまずデフォルトのセッション構成を作成しますそれから DNSSECの検証を要求します次に　変更した構成でセッションを作成しますこのセッションから作成したすべての URLリクエストに対して DNSSECを有効にしますセッション全体でDNSSECを有効にしたくない場合リクエストレベルで行うこともできますまず DNSSECの検証を無効にしたデフォルト設定のセッションを作成しますその後リクエストで有効にしますこのセッションタスクは DNSSECの検証の完了時のみ開始されるようになります Network.frameworkのクライアントであれば接続にDNSSECの検証を要求することも可能ですまずパラメータオブジェクトを作成する際に DNSSECの検証を要求します次に parameters オブジェクトで NWConnectionを作成しますこれで接続を開始すると DNSSECの検証が完了し検証済みのIPアドレスへの接続が確立したときのみ準備完了状態に移行します DNSSECが有効な場合検証されたアドレスのみ接続を確立するために使用します HTTPSではエラーは APIを通して報告されます DNSSECでは検証に失敗してもエラーは返しませんバリデーションに失敗した応答を受け取ることは何も受け取らないも同然ですレスポンスを改ざんする DNSプロバイダがいる場合アドレスは認証チェックを通過しないためそのまま破棄されます DNSプロバイダが応答を改ざんしていない新しいネットワークにデバイスが参加すると検証は再び進展し解決は自動的に正常に戻ります
DNSSECが失敗しうるケースをいくつか紹介しますオリジナルのDNS レスポンスが変更された場合不一致の署名はDNSSEC チェックを通過せず検証失敗の原因となりますデバイスがプリインストールされたトラストアンカーに到達できずトラストチェーンを確立できない場合 DNSSEC有効化ビットを搭載する DNS over TCPや EDNS0 オプションなど DNSSECが必要とするプロトコルにネットワークが対応しない場合も失敗します署名済みドメインが IPv6に対応していない場合インターネットサービスプロバイダから提供される合成されたIPv6アドレスは検証に失敗しますつまり DNSSECでDNS レスポンスを認証する方法ですが暗号化されていなければネットワーク上の誰でも見ることができるのです次に DDRでDNSの暗号化を自動的に有効にする方法をご説明します
iOS 14とmacOS Big Surではプライバシー保護に役立つ暗号化DNSを導入しました AppのNEDNSSettings Managerやプロファイルの DNSSettingsを使用して暗号化DNSをシステム全体に手動で設定できますまた NWParametersの PrivacyContextで Appの暗号化DNSをオプトインできます詳しくは「暗号化DNSの有効か」をご確認ください iOS 16とmacOS Venturaの新機能として暗号化DNSが自動的に使用できるようになりましたネットワークがDiscovery of Designated Resolvers (DDR) に対応する場合 DNSクエリは自動的に TLSまたはHTTPSを使用します暗号化されたDNSを使うにはデバイスはリゾルバが TLSまたはHTTPSに対応するか把握する必要があり同様にポートまたは URLパスの学習が必要な場合もあります DHCPやルーターアドバタイズメントなどの一般的な仕組みではプレーンな IPアドレスしか提供しません DDRは Appleが他の業界パートナーと協力して IETFで開発した新しいプロトコルです DNSクライアントが特別な DNSクエリを使用することでこの必要な情報を知る方法を提供しますデバイスが新しいネットワークに参加すると「dns.resolver.arpa」に対するサービスバインディングクエリを発行します DNSサーバーがDDRに対応している場合 1つまたは複数の構成を返信しますデバイスはこの情報をもとに指定されたリゾルバとの暗号化された接続を設定します暗号化されていないリゾルバのIPアドレスが指定されたリゾルバのTLS証明書に含まれることを確認します暗号化されていないリゾルバとされたリゾルバが同じエンティティに属していることを確認するためです問題なければデバイスはデフォルトで暗号化された
DNSを使用します　DDRは一度に1つのネットワークに適用されます　現在のネットワークが暗号化DNSに対応する場合のみ自動的に暗号化DNSを使用します DNSサーバーのIPアドレスがプライベートIPアドレスだと DDRは動作しないことにも注意してくださいこのようなIPアドレスは所有権が確認できないため TLS証明書では許可されないからです iOS 16および macOS Venturaでは NEDNSSettingsManagerまたは DNSSettingsプロファイルを使用して設定に暗号化DNSを使用する際にクライアント認証を指定する機能にも対応します
クライアント認証でアクセスを許可する前にサーバーがクライアントを認証すべき企業環境では暗号化されたDNSサーバーが使用できます NEDNSSettingsのidentity Referenceプロパティでクライアント証明書が設定できるようになりました VPN用のクライアント証明書と同じような動作をしますこれらは DNS over TLSと DNS over HTTPSの両方に適用できますこれがDNSのセキュリティ確保への道筋です DNSSECでドメインに署名し IPアドレスを認証するために AppでDNSSEC検証を要求しますネットワーク上のDDRを有効にすることでクライアントが自動的に暗号化DNSに切り替わりユーザーのプライバシーを保護できますより良いアクセスコントロールが必要な企業ではクライアント認証を採用します今後より安心できる DNSの基盤作りをお手伝いいただけると期待していますご視聴ありがとうございました！

9:01 - Require DNSSEC validation in your URL request at session level

let configuration = URLSessionConfiguration.default
configuration.requiresDNSSECValidation = true
let session = URLSession(configuration: configuration)

9:38 - Require DNSSEC validation in your URL request at request level

var request = URLRequest(url: URL(string: "https://www.example.org")!)
request.requiresDNSSECValidation = true
let (data, response) = try await URLSession.shared.data(for: request)

10:08 - Require DNSSEC validation in your network request

let parameters = NWParameters.tls
parameters.requiresDNSSECValidation = true
let connection = NWConnection(host: "www.example.org", port: .https, using: parameters)

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC20