メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

ICANN and Iron Mountain Complete Registrar Data Escrow QA Testing andBegin Accepting Escrow Deposits
翻訳文

社団法人日本ネットワークインフォメーションセンター
最終更新2008年8月21日

この文書は2008年2月13日に公開された
http://www.icann.org/announcements/announcement-2-13feb08.htm
を翻訳したものです。
JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。


2008年2月13日

ICANNとIron Mountain社がレジストラデータエスクローの品質保証テストを終了し、エスクローデポジットの受け入れを開始

概要

 レジストラデータエスクロー(RDE)プログラムは、 ICANN認定レジストラが重要な登録データを預託しレジストラ認定契約の終了の際にICANN にデータが引き渡されるようにすることによって、 登録者の保護を強化するためのICANNの構想です。 ICANNはRDEシステムのテストをすでに実施しました。 テストには、プログラムの技術仕様の有効性を確認し、 レジストラの機能停止の際のエスクローエージェントによるデータ引き渡し手順をテストするための 「プロセステスト」と「負荷テスト」が含まれます。

「プロセステスト」と「負荷テスト」は成功裏に終了しました。 そして、いくつかのデータ引き渡し手順の改善をもたらしました。 それはシステム外からの手段(つまり、ICANN職員や弁護士による電話確認) による引き渡し要求の多方面からの認証や、 レジストラの利用登録に関する文書の明確化などです。

 品質保証テストを終了した後、 ICANNと指定されたエスクローエージェントは、 実際のRDE環境でシステムの運用とレジストラの登録を開始しました。 これまでに750近くのレジストラが ICANN指定のエスクローエージェントを選択する意向を示し、 八つのレジストラはRDE規約に従い預託を開始しました。

背景

 ICANNは2007年11月9日、 Iron Mountain社がICANN指定レジストラデータエスクロー(RDE) エージェントを務めることについて同社と協議を終了したことと、 レジストラが機能停止した際の登録者保護を強化するための RDEプログラムの実装を開始したことをアナウンスしました。 RDEプログラムを通じて、 全てのICANN認定レジストラは定期的に gTLD登録データのバックアップ情報をIron Mountain社または RDEサービスについてICANNが承認した第三者機関(TPP) にデポジットすることとなります。 エスクローで保有されるデータはレジストラ認定契約の終了時や、 認定契約を更新せずに期限切れを迎えた際に、 機能停止したレジストラから他のレジストラへの登録の移行を容易にするためにICANN に引き渡されます。

RDE仕様書の概要

 RDEプログラム(「RDE仕様」)の規約、スケジュール、および形式要件は、 レジストラのボランティアと技術的な専門家からなるワーキンググループと協議のうえICANNによって定められ、 以下のICANNのウェブサイトにて公開されています。

http://www.icann.org/rde/rde-specs-09nov07.pdf (PDF, 33K)

 RDE仕様では、 全てのレジストラに登録データのコピーを週次で預託することと、 大手のレジストラに毎日差分のデポジットを更新することを求めています。 レジストラ認定契約(RAA)の条項に従い、そのデータベースには、 スポンサー付きgTLDを含む全てのgTLD登録の完全な WHOISデータと経理担当者の情報を含まなければなりません。 レジストラはWHOISプライバシー代理サービスの顧客のコンタクト情報を提供することが推奨されますが、 これはRAAが修正されるまでは必須ではありません。 (これを含む登録者保護の強化提案に関するRAAの修正プロセスが進行中です。 http://www.icann.org/topics/raa/をご覧ください。)

 RDE情報の安全性と有用性を確保するため、 レジストラは要求された登録情報をコンマ区切り(CSV) テキストファイルとして、1ギガバイトまたは100 万行以下に集積し、 各々についてSHAハッシュを生成することが求められます。 そのファイルはエスクローエージェントへ検証と保管のため、圧縮、 暗号化され、安全に提出されなければなりません。 エスクローエージェントは少なくとも1年間分の全てのデポジットを保持し、 ICANNまたは指定された第三者機関へ、 ICANNの要求から5営業日以内にそれらを引き渡します。

RDEプログラムの実装

 11月の初旬にIron Mountain社との協定が正式化されたため、 ICANNとIron Mountain社は、 全てのレジストラにデータエスクローの義務を通知し、 Iron Mountain社と第三者機関のどちらを選択するかレジストラの希望を取りまとめることによって、 RDEプログラムを運用可能とすることに着手しました。

 レジストラに送付された通知では、レジストラ毎の預託の要求頻度と、 データ預託予定期日が示されました。 定められたスケジュールでは、 全てのレジストラは遅くとも2008年7月1日までに、 RDE技術仕様書に従ってデータデポジットを行います。 ICANN契約コンプライアンスチームは、 レジストラが期限までに登録しデータ預託を行うことを確保するため、 このプロセスを入念に監視します。

 900のICANN認定レジストラのうちこれまでに750近くが ICANN指定エスクローエージェントを選択することを表明し、 二つのレジストラが自らの費用負担により第三者組織を使用することを選択しました。 残りのレジストラからも選択結果を取りまとめる努力が続けられます。 2008年2月15日までに選択を表明しないレジストラにはコンプライアンス強制施行の措置が計画されています。

 レジストラへの通知やエスクローエージェント選択の取りまとめと時を同じくして、 ICANNとIron Mountain社は、 ICANNがレジストラと相談して策定したデータ預託と、 その引き渡し手順の実効性を確認するため、 RDEシステムの品質保証(QA)テストを開始しました。 このドキュメントでは、計画中の将来の構想とともに、 ICANNによってが実施するQAテストについても記述します。

RDEプロセステストの実施

 2007年11月に発行されたRDEプログラムの技術仕様書は、 RDEデータのデポジットと引き渡しの手順について設計していますが、 ICANNスタッフにとってQAテストの展開は、 ICANNとエスクローエージェントの間で予想されることについての相互理解を確実にするために更なる明確化が必要とされる範囲を洗い出すのに有用でした。 このプロセスは、 技術系エスクロー業界における議論とベストプラクティスの実装を通して、 データ引き渡しの保護措置を強化する機会も提供しました。

 Iron Mountain社がレジストラデータエスクローの実施のために使用する技術的なインフラとソフトウェアは、 同社がレジストリエスクローのために長年使用してきたものです。 従って、ICANNとIron Mountain社は、 今回の一連のテストでは計画した預託、データ引き渡し手順、 および保護を評価することに焦点を絞るべきであると判断しました。 これを達成するために、「プロセステスト」と 「負荷テスト」が展開されました。

RDEプロセステスト

 テストの第1ラウンドは、 RDE預託・データ引き渡しプロセス自体に加えレジストラの機能停止模擬実験を行い、 これらのプロセスをICANNとIron Mountain社が適切に実施できるかをテストするように設計されました。

 RDEプロセステストを実行するために、 ICANNは「IANAレジストラ」 (認定レジストラのものと良く似た登録/WHOISデータを持ち多くの予約ドメイン名を保持するために、レジストリとともにICANNに維持されるアカウント) をIron Mountain社のRDEプログラムに登録しました。 具体的には、ICANNはIron Mountain社の使用登録と暗号鍵の交換手続きを終え、 RDE仕様書に従ってIANAレジストラ登録情報のCSVを準備、圧縮、 暗号化しました。 他方、Iron Mountain社はRDE仕様書に従ってそのデータを受領、復号、 解凍、チェックサム検証を実施し、 ICANNのRDEコンプライアンス電子メールアカウント宛てに受領証明証を送付しました。 検証プロセスの終了後、暗号化されていないデータは破棄され、 元の暗号化されたデータは保管されました。

 ICANNはIANAレジストラによる預託の成功を確認した後、 引き渡し手順を開始しました (引き渡し手順のフローチャートは http://www.icann.org/rde/rde-release-procedure-13feb08.pdf [PDF,93K] にて参照可能です) 。 典型的な引き渡しの状況を想定したうえで、ICANNのリエゾンスタッフは、 解放はRDE仕様書(および実際の場合におけるレジストラ認定契約) の条件において適切かつ許容されるものであることを弁護士に確認しました。 その後、ICANNは5日以内のICANNレジストラデータの引き渡しのための正式な要求を提示するかもしれないという非公式な通知が Iron Mountain社へ電子メールで送られました (この非公式な通知は、 Iron Mountain社にデータ引き渡しの可能性があることを事前に伝えることと、 係争中のレジストラに関するRDEデータの有用性について、 Iron Mountain社がICANNに手短に示す機会を提供する意図によるものです)。

 非公式な通知がIron Mountain社へ発信された1週間後、 ICANNの弁護士はIANAレジストラのエスクローデータの引き渡し要求を FAXとPGP署名付きの電子メールで伝えました。 既定の引き渡し手順に従い、 Iron Mountain 社はICANN指名スタッフとともに引き渡しの詳細を電話で確認し、 データ引き渡し要求の信憑性を検証しました (引き渡し要求のなりすましや偽造を防ぐため、ICANNは、 ICANNの交換台を通して、 ICANNのWebサイトに掲載している電話番号を使用し、 書簡の差出人に確認の電話を掛けることをエスクローエージェントに要請しています)。

 RDEデータは引き渡される前に、 Iron Mountain社の秘密鍵を使用して再度復号化され、 次にICANNの公開鍵を使用して再暗号化されました。 ICANNの引き渡し要求から2営業日以内に、 Iron Mountain社は翌日配達便とsFTPによって引き渡しを実現しました*1。 オンラインでの引き渡しのためのログイン証明情報は、 PGPで暗号化された電子メールによってICANNへ提供されました*2。 両データセットを受け取り次第、 ICANNは引き渡されたデータを元データと比較しそれらがビット単位で同一であることを確認しました。

*1 Iron Mountain社とのICANNの協定では、 Iron Mountain社はICANNによる正式な要求から 5営業日以内にエスクローデータを引き渡すこととしています。

*2 RDE協定の条件下では、 Iron Mountain社はICANNへのデータの引き渡しの際にレジストラに通知します。

RDE負荷テスト

 QAテストの第2ラウンドは、 再びRDE預託・引き渡し手順をテストするよう設計されましたが、 大手レジストラ(100万件以上のgTLD登録を管理するレジストラ) の預託者を模擬したものとしました。 上記の通り、RDE仕様書の規定の下では、 レジストラはCSVファイルを1ギガバイトまたは 100万行より大きくならないよう分割しなければなりません。

 RDE負荷テストを実施するために、 ICANNはIANAレジストラデータを約 3ギガバイトのファイルサイズとなるよう操作しました。 このファイルはRDE仕様書に従い分割、圧縮、暗号化され、 Iron Mountain社へアップロードされました。 RDEプロセステストと同様に、Iron Mountain社は復号、解凍、 チェックサム検証を実施し、その後暗号化されていないデータを破棄し、 元の暗号化されたデータを保管しました。 同様に、前回と同様に、ICANNは同意されたデータ解放手順に従い、 再暗号化されたファイルは、 sFTPと翌日配達便によって引き渡し要求から1営業日以内にICANNに引き渡されました。

 負荷テストは全般的に成功裏に終了しましたが、 スタッフは結果の信頼性を多少損なうようなプロセス上の異常を確認しました。 特に、スタッフは、 模擬的に作成された登録データがアップロード用に準備された時、 いつになく効率的に圧縮されていたことに気付きました。 模擬的に作成された大きなレジストラデータはおよそ 7,000:1の比率で圧縮されました。 これに対して、独自にRDEプログラムの準備とテストを開始したレジストラでは、 データ圧縮比率は13:1でした。 模擬的に作成された登録データの冗長性が、 異常に高い圧縮率を生じたように思われたため、 ICANNは、RDE負荷テストにおける技術的な手順(ファイル準備、 アップロード、および引き渡し)については、 より一般的な圧縮率で再実施すべきであると判断しました。

 負荷テストの第2ラウンドでは、 模擬のレジストラデータはよりランダムに作成されました。 これにより現実的なデータ圧縮となりました。 2回目にアップロードされたファイルは、 それぞれ(先の負荷テストにおける142KBに対して) 349MBとかなり大きいものであり、 およそ3:1の圧縮率となりました。

 RDE負荷テストを再実施することにより、 ICANNとIron Mountain社はRDE仕様書の実効性と、 ICANNとIron Mountain社の大規模なレジストラのデータ引き渡しの実行能力を評価することができました。 この複数回のテストを通して、ICANNは、 毎秒700キロバイトのアップロード速度とこれに対する 20分程度の合計アップロード時間を観測しました。 Iron Mountain社は、データアップロードの処理時間(すなわち復号、 解凍、預託の検証の所要時間)は2分30秒足らずであったことを報告しました。 ICANNはsFTPによって15分(毎秒950キロバイト)でRDEデータをダウンロードし、 復号と解凍を2分足らずで完了することができました。 データの同一性はチェックサム検証により確認されました。 これらの結果から、 RDEプロセスと負荷テストは成功裏に完了したと判断されました。

問題の認識

 一連のICANNのQAテストの進行を通して、少数の問題が確認されました。 そのような問題の多くは概して軽微なものでしたが、 あるものはICANNとIron Mountain社によって RDEプログラムの中で使用された手順と安全保護策への更なる改良に寄与しました。 軽微な事項の中には、 電子メールアカウントやオフラインFAX機についての誤字、 およびレジストラ説明文書の中に、 「レジストラ」でなく「レジストリ」と記述した誤字等ありました。 これらの事項はQAテストの進行の中で全て速やかに対処、修正されました。

 加えて、テストプロセスを通して、 またレジストラによるフィードバックから、 Iron Mountain社はレジストラへの実行指示を明確なものとし、 RDEシステムユーザーの預託プロセスを合法化する方法を発見することができました。

 もう少し意義のあるものとしては、 エスクローデータ引き渡し手順に関連する手続きの変更の「確実化」があります。 特に、ICANNが、引き渡し要求の認証の適した方法を領域外のもの、 つまりPGPで署名された ICANNからの電子メールは必ずしも必要でないことを決定し、 エスクローエージェントに既定の電話確認ステップを利用させることにしたことです。 業界のベストプラクティスに従い、 データ引き渡しを要求する所感の差出人ともう一つの信託会社、 例えば執行役員やICANN Webサイトで確認できる弁護士等、 にICANNの交換台を通じてエスクローエージェントがコンタクトを取るよう要求するように、 電話による検証手順が追加されました。 これらのステップは、引き渡し要求書簡に従って行動をとる前に、 エスクローエージェントがこの書簡が本物であり ICANNによって正式に認可されたものであると確信することを保証するものとなります。

今後の追加テストとコンプライアンス構想

 ICANNのQAテストを終え、 Iron Mountain社はレジストラからのエスクローデポジットを受け入れ始めました。 これまでにいくつかのレジストラがシステムテストを始め、 八つのレジストラは指定されたスケジュールでデータエスクローを開始しました。 ICANNは性能を継続的に監視し、手続き上の変更を適切に行うため、 これら早期のプログラム参加者へのアウトリーチを開始しました。

 今後何ヶ月かの間に、 ICANNは登録者の保護とRDE要件へのレジストラの準拠の確保のために RDE預託検証スクリプトの開発と遵守監査を通して定期的にテストを実施していく予定です。 ICANNは2008年7月までに初版の監査スクリプト開発作業を終了すると予想し、 RDE遵守監査を2008年8月から12月の間に行うことを計画しています。

ICANNからのアナウンス(2008年2月13日)

"ICANN and Iron Mountain Complete Registrar Data Escrow QA Testing andBegin Accepting Escrow Deposits"

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.