Internet Infrastructure Review（IIR）Vol.30
2016年2月29日

ISO 27017策定の背景

クラウドサービスの特徴

まず、ISO 27017を理解する前に、クラウドサービスの特徴を振り返ります。クラウドサービスはカスタマイズを行わない定型のサービスです。事業者はサービスの提供において、人が介在する要素を減らして自動化を行い、設備や運用体制を集約、共用してリソースを効率的に使用するなど様々な工夫を行うことで、コスト面やスケール面などのメリットを生み出しています。そのためクラウドサービスは、人手による個別対応やシステム内部の情報開示などを行うことが本質的に困難なサービスです。これはクラウドサービスの特徴として理解しておく必要があります。

この特徴は利用者によるセキュリティ管理を難しいものとしています。自組織の情報を管理するためには、自組織の情報を誰がどのように扱っているのかと詳細な管理状態を知る必要があります。しかし、自組織のセキュリティポリシーを適用する個別のシステム開発などと異なり、共用リソースであるクラウドサービスに対して特定組織のセキュリティポリシーを適用することはできません。そのため、事業者がセキュリティ管理状況を開示しない前提で、利用者は事業者が主張する安全策を自ら検証することなく契約し、クラウドサービスを利用することになります。

ISO 27017の策定

前述のようにクラウドサービスでは、利用者と事業者の間にセキュリティ管理についてのギャップが存在し、そのギャップを埋める様々な方法が考えられています。その1つとして、本レポートのVol.24ではクラウドセキュリティ推進協議会によるクラウド情報セキュリティ監査制度を取り上げました（※54）。クラウドサービスの安全性を確認するために各種のセキュリティ基準を使うことは、利用者にとっては事業者がどの程度セキュリティ基準に適合しているかが分かりやすく、また、事業者にとってはセキュリティ対策のレベルを容易に示すことができるなど、双方にメリットのある方法です。そのため、関連する国内、国外の組織、団体によって個別に様々な基準やガイドライン、認定制度などが作られました。しかしその結果として、数多くの独自基準ができてしまい、逆に事業者や利用者の混乱を生んでいることも否めません。クラウドセキュリティ管理基準の国際的な統一化は必然的に必要な状況となっていました。

そのような状況下で、日本では世界に先駆けて、クラウドセキュリティのガイドラインを経済産業省が発行しました（※55）。ISO 27017は経済産業省発行のガイドラインをベースに検討が開始されており、日本が非常に重要な役割を担った国際規格と言えます。策定にあたっては、米英など各国の他にCloud Security Allianceなども参加し、多くの議論が交わされることとなりました。サービス提供が主体となる地域や国、また、その逆にサービス利用が主体となる地域や国、個別のセキュリティ規制を持つ地域や国など、立場が異なる人々の様々な意見を取り入れることにより、ISO 27017は少し複雑な構造になっています。次に、ISO 27017を理解するためのポイントをいくつか紹介します。

ISO 27017理解のポイント

利用する立場の違い

繰り返しとなりますが、クラウドサービスは事業者が定めたスペックのサービスから自組織の要件に合うサービスを利用者が判断し選択します。これがISO 27017の基本的な発想であり、記述内容は利用者と事業者両方の内容が記載されています。ISO 27017を適用するにあたっては、事業者の立場でこの規格に準拠するか利用者の立場でこの規格に準拠するか、それとも両方の立場でこの規格に準拠するかをしっかりと認識することが混乱を避けるために重要です。

そこで必要となるのは、どこまでが事業者の責任範囲で、どこからが利用者の責任範囲となるかを明確にすることです。そうすることで、組織の責任範囲において、行うべき管理策が何かが分かります。そのためISO 27017では、利用者と事業者が、セキュリティの管理についてどちらが何をどのように行うべきか明確に区分するよう、責任分界（Shared responsibility）の項目が追加されています。

なお、IaaSを使ってSaaSを提供するようなサービスの事業者は同時に利用者でもあります。よって、そのようなサービスは利用者及び事業者両方の立場で準拠することとなります。

章立て・構成

ISO 27017はISO/IEC 27002：2013（以下、ISO 27002）の追加管理策となっており、各章に記載されている管理策はISO 27002と番号が同じとなっています。そのため、ISO 27002をそのまま適用可能なものについては、"ISO/IEC 27002 apply." と記載されています。このことはつまり、本規格に準拠するためには、組織がISMSを実装できていることが前提となっている、ということです。

そもそもISO 27002はISO 27001を実装するための手引きという位置づけで、組織が自らのセキュリティ管理を具体的にどう行うか記載した文書であり、事業者が提供するサービスのセキュリティ管理策がどうあるべきかを定めるものではありません。よって、ISO 27002をベースとしているISO 27017も、利用者が自らのセキュリティ管理を行うにはどうするか、が基本的な考え方となっています。それに加えて、クラウドサービス事業者はクラウドサービス利用者の要求にどのように答えるべきか、という視点で内容が加筆されていると考えると分かりやすいでしょう。

実際の記述ですが、クラウド特有の考慮事項として、"Implementation guidance（実施の手引き）"が記載されています。"Implementation guidance"には、利用者が実装すべきこと、事業者が実装すべきことが個別に表形式で記載されています。双方が同じことを共同で行う場合は表が結合されて記載されています。実装の手引き以外に、注意すべき点や特筆すべき事項などがある場合には、"Other information"として記載されています。

加えて、ISO 27001にはそもそも存在していない、クラウドサービス特有の管理策がISO 27017には定義されています。具体的には、仮想環境のセキュリティ強化についての管理策、情報資産の消去についての管理策などがあります。これらクラウドサービス特有の管理策は本文内ではなく、Annex AにCLD x.y.zという番号で追加されているので、これらの考慮漏れがないように注意してください。

利用方法

ここでは本規格の利用方法について説明します。利用者の利用方法としては、自組織でクラウドを利用する場合に、"Implementation guidance"に記載されている"Cloud service customer"の項目について実装を行います。先にも触れましたが、ISO 27017は、ISMSに準拠している組織がクラウドを利用するために何を追加的に行うかが記載されていますので、ISMSによるセキュリティ管理が行われていない場合は、まずそこから始める必要があります。ご注意ください。

一方、事業者の利用方法ですが、"Implementation guidance"に記載されている"Cloud service provider"の項目を参照して、利用者に提供する情報の内容やシステムが備えるべきセキュリティ機能を実装します。ログ管理や情報提供の仕組みなど、サービスの機能としてあらかじめ実装しておく必要があるものも存在するため、本規格に準拠するクラウドサービスを行う場合は、クラウドサービスを設計する時点で本規格の管理策を取り込むことが推奨されます。

関連規格

ISO 27017以外にも、クラウドセキュリティに関連する国際標準規格が発行、並びに検討されています。具体的には現在検討中の物を含めて、ISO/IEC 17788：2014（※56）、17789：2014（※57）、NP 19086-4（※58）、27018：2014（※59）、DIS 27036-4（※60）などが挙げられますので、簡単に紹介します。なお、以下本文でISO/IEC などは省略しています。

17788はクラウドコンピューティングとは何か、どのような種類があるかといった定義や、ボキャブラリつまりクラウドの用語などを記載したものです。17789は、クラウドコンピューティングのアーキテクチャが記載されています。27017はこの2つの規格を踏まえて作られています。この2つの規格はオープンであり、ISOのWebサイトから自由にダウンロードして読むことが可能ですので、一読することをお勧めします。また、27018はクラウドサービスでプライバシーを扱う場合についての手引きが定義されています。その他に現在検討が行われているものとして、19086-4はクラウドサービスのSLAについて、27036-4はサプライチェーンの観点から、それぞれ標準化が試みられています。

更に、将来的にISO 27017を認証制度とすることが検討されており、国内では一般財団法人日本情報経済社会推進協会（JIPDEC）が認証を行うことを表明しています（※61）。認証制度が確立すれば、定められたセキュリティ水準に達しているクラウドサービスが第三者から認証されたサービスとして、より分かりやすくなりますので、利用者は手間なくその安全性を判断できることとなります。

まとめ

クラウドサービスを利用する上で懸念事項となっているセキュリティですが、管理策の国際標準化が行われることでより一層クラウドサービスを利用しやすくなる環境が整ってきました。IIJのクラウドサービスである「IIJ GIOサービス」でも、一部で既にISO 27017への対応を行っており、今後も対象範囲を順次拡大する予定です。IIJは、これからも積極的に国際標準の順守を推進し、安全安心なクラウドサービスを提供して参ります。

Let's Encryptプロジェクトの概要

Let's Encryptプロジェクトは、SSL/TLSで広く使われているサーバ証明書の自動発行サービスを提供しています。最近まで限られたテストユーザに対してだけ公開されていましたが、2015年12月初旬に一般に広く利用できるようになり、注目を浴びています（※69）。このプロジェクトは、非営利団体Internet Security Research Group（ISRG）（※70）により運営されており、ISRGのメンバー及びスポンサーには、Mozilla、EFF（Electronic Frontier Foundation）、Akamai、Ciscoなどの組織が名を連ねています（※71）。2015年12月、ブラウザベンダーの1つでメインプレイヤーであるChromeがプラチナスポンサーとして参画したことも注目すべき点です（※72）。

Let's Encryptプロジェクトでは、後述するACMEプロトコルを用いた参照実装が提供されています。ACMEクライアント（証明書発行依頼を行うユーザ）はLet's Encrypt clientを用い、ACMEサーバ（Let's Encryptプロジェクトが運営するCA）と通信することにより、証明書の発行、再発行、失効依頼などの処理を行うことができます（※73）。その中で、ドメイン名の保有者かどうかを確認するDomain Validationと呼ばれるいくつかの方式が提供されています。Let's EncryptプロジェクトのDomain Validationの解説（※74）では、ドメイン保有者であることの確認方法として、ACMEサーバ（CA）からのチャレンジに対して、（1） DNSレコードを制御する方法、（2）HTTPサーバのWebページを記載する方法の2種類のみが記載されていますが、ACMEプロトコルで定められている（3）SNI （Server Name Indication） を利用する方式も実装が対応しています。それぞれのDomain Validationの説明は後半を参照してください。

現在のLet's Encryptプロジェクトにおける様々なデータを閲覧することができます（※75）。その中には証明書発行枚数に関するデータがあり、執筆時では失効していない有効な証明書は70万枚程度との報告があります（※76）。24時間以内に処理された発行要求数と成功数に関するデータ（※77）によると、前述したDomain Validationのうち、HTTPサーバにページを追加する方式が7割から8割程度を占め、次いでSNIを利用する方式が見受けられます。一方で、DNSレコードを制御する方式は現状では数パーセントで推移しています。また、Let's Encryptプロジェクトにおける各種サーバ（Web、登録、OCSPサーバなど） のステータスやメンテナンス予告も参照できます（※78）。

Let's EncryptプロジェクトのACMEサーバから発行される証明書は"Let's Encrypt Authority X1"中間CAから発行されます。このとき"Let's Encrypt Authority X1"中間CA証明書はクロスルート証明書であり、2つの親を持ちます（※79）。そのうちの1つである"DST Root CA X3"は、OSやFireFoxの証明書ストア（信頼するルート証明書のリスト）に格納されています。そのため主要ブラウザのユーザは証明書ストアに手を加えることなく（トラストアンカーとしてルート証明書を追加することなく）Let's Encryptから発行されたサーバ証明書の検証に成功します。証明書の有効期間は90日（※80）に設定されており、これは通常購入できるサーバ証明書よりも短い期間となります。これは、秘密鍵が危殆化（※81）した際や、誤って証明書が発行された場合の影響を短くするためと説明されています。また、一部の環境では既に再発行作業も自動化されていることから、短い有効期限であっても、再発行に関わる工数は増えないと予測されます。

ACMEプロトコルの概要と策定状況

ACMEプロトコルについては、2014年11月にはMLが開設されて議論が進められており（※82）、2015年3月のIETF meeting 92 ではBOF（※83）が開催されました。更に、2015年5月にはACME WGとして正式に活動を開始し（※84）、7月のIETF 93 meeting で会合が行われています（※85）。この時点では、メインのプロトコル仕様としてdraft-barnes-acme-04（※86）が議論されています。draft-barnes-acmeは、2015年1月から7月にかけて改訂された後、9月にはdraft-barnes-acme-04をベースにWG draftとしてacme-acme（※87）が登場し、本稿執筆時には-01のドラフトが登場しています。Editor's copy版（※88）は日付やdraft version が正しくメンテナンスされていませんが、acme-acme-01から加筆されており、こちらが最も新しい仕様となります。acme-acmeはCharterによると、2016年3月までにIESG（Internet Engineering Steering Group）（※89）の提出を目指しており、現在もドラフトに関する議論が急ピッチで進められています。議論の内容はGitHubサイトで確認することができます（※90）。また、現在WG draftとして扱われている仕様はacme-acmeのみです。関連ドラフトとしてdraft-pepanbur-acme-proxy（※91）が挙げられていますが、IETF 94 meetingではacme-acmeのみが議論されました（※92）。

ここからは、ACMEプロトコルについてacme-acme-01のEditor's copy版（2016年2月12日取得）をベースに解説します。ACMEはJSON形式（※93）でやり取りするサーバ・クライアント間のプロトコルです。基本的には、ACMEサーバはHTTPSサーバとして振る舞い、ACMEメッセージはHTTPSで保護されています。ACMEサーバはCA側で証明書発行を受け付けるサーバで、ACMEクライアントは証明書発行依頼を行うユーザであり、Webサーバやメールサーバなど、サーバ証明書を必要とするサーバでクライアントソフトを動作させることを想定しています。このとき、クライアントとサーバは、共にPublic Key Pinning（※94）に対応することが推奨（SHOULD）されています。Public Key Pinningに対応することで、従来のような証明書チェーンを辿る方式と併用して、ACMEサーバの証明書が正しいものであることが保証されます。

HTTPSを通してクライアントからサーバに送信されるすべてのACMEメッセージはJWS（JSON Web Signature）（※95）を用いてクライアントにより署名が付与されます。この処理により、正しいクライアントからのメッセージであることを、サーバが検証可能となります。この仕組みを提供するためには、クライアントは証明書発行依頼などの前に、自身の公開鍵をACMEサーバに登録する作業が必要となります（※96）。具体的にはJSON Web Key形式（※97）の鍵データがメールアドレスや電話番号を格納するcontact情報と共にサーバに送付されます。このとき、署名に用いられる公開鍵は、サーバ証明書で用いられる公開鍵とは異なり、登録時に使用されるAccount Key Pairと呼ばれる別の鍵です。この登録時に利用された1つの鍵で、複数のFQDN（Fully-Qualified Domain Name）に対して証明書の発行依頼を行うことができます。本仕様においては、FQDNではなくidentifierという記載で抽象化されていますが、これは今後の拡張を想定しているためです。そのため現時点では、identifierの箇所をFQDNと読み替えても問題ありません。

ACMEサーバが提供するサービス一覧は、directoryと呼ばれるディスカバリサービス機能を用いて入手します。例えば、現在のLet's Encryptプロジェクトでは、クライアントがdirectoryに関するURLを指定することで、JSONデータを入手します（※98）。

ACMEではいくつかの種類のプロトコルメッセージが規定されており、クライアントは、directoryに記載されたURLに対して、規定されたデータにJWS形式で署名してPOSTで配送します。今回は、証明書発行から廃棄までの基本的なリソースのみを取り上げて説明します。通常、ACMEクライアントは以下のリソース順で一連の処理が行われます。

ACMEクライアントは、new-regリソースで登録処理を行った後、登録時に用いたAccount Key pairのうち秘密鍵を用いて署名を行います。そのためACMEサーバは、クライアントが登録したAccount Keyの管理をする必要があります。特に、同じAccount Keyで登録が行われた場合には、HTTPエラーとして409（Conflict）を返答することが規定されています。

登録処理後は、まず最初にnew-authzリソースを用いてidentifier の登録を行います。前述したように、identifierはFQDNですので、ここでは発行したいサーバ証明書の対象となるFQDNを登録することになります。ACMEクライアントはnew-regと同様にAccount Keyを用いてJWS形式で署名することで、当該Account Keyの所有者によるリクエストであることをサーバが認識できます。ACMEサーバはこのリクエストに対して、表-2に挙げられるDomain Validationのうちどれが可能かのリストを返却します。ACMEクライアントはchallengeリソースを用い、いずれか、または複数の手法を選択してchallengeのリクエストを送信します。サーバはFQDNの所有確認を行った後、その結果を返却します。成功時には、この時点で証明書発行の準備が整ったことになります。クライアントは、Account Keyとは別の公開鍵ペア（仕様ではSubject Public Keyと記載）を準備して、PKCS#10 Certificate Signing Request（CSR）を生成し、同様に、JWS形式の署名をAccount keyで施した上でnew-certリソースで証明書発行依頼を行います。サーバはJWSとCSR両方の署名検証を行い、証明書を発行した後、DERエンコーディングされた証明書を返却します。証明書を失効依頼する場合にはrevoke-certリソースを用い、当該証明書を格納してJWS形式の署名付でリクエストします。

Domain Validationとしてacme-acme-01では表-2に記載のhttp-01、dns-01、tls-sni-01などが規定されています。これらのタイプの接尾に「-01」とあるのは、ドラフトバージョンと連動していることを示しています。実際、既にtls-sni-02に対する議論が始まっています（※99）。ただし、今後ドラフト自体のバージョンアップのタイミングで手順が変更される場合には、ドラフトバージョンと連動して新しいタイプ名になりますが、Validationの手順に変更がない場合には、タイプ名はそのまま保持されます。

拡大する

表-2 acme-acme-01におけるDomain Validationの種類

いくつかの懸念点

JWS署名の対象範囲は厳密に規定されておらず、緩やかな表現が現時点でのドラフトに記載されています。例えば、registrationリソースの形式としては、key、authorizations、certificatesフィールドも定義されていますが、実際にnew-regリソースをサーバが処理する際には、これらのフィールドを無視せねばなりません。ハッシュ関数に入力するデータのうち、処理が無視される箇所にダミーデータを格納することで、中間CA 証明書の偽造（※100）やSLOTH攻撃（※101）が成功する要因となっており、潜在的な攻撃の余地を残すことになりかねません。

DV証明書は現実世界での実在性を確認しないため、悪用を意図したサーバに対しても発行される可能性があります。実際、Trojanの配布サーバに対して、Let's Encryptプロジェクトから発行された証明書が利用されていたことが、2016年1月初旬に報告されています（※102）。

Let's EncryptプロジェクトはCertificate Transparency （CT）（※103）に対応しており、発行された証明書はログサーバ（※104）に通知されているため、誰でも証明書が閲覧できる状況にあり（※105）、国内ではCTに関する問題が以前から噴出していました（※106）。指摘されている懸念事項の1つにプライバシ問題があります。例えば、今後サービスインする予定のサーバのFQDNがリリース前に漏れてしまう点などが考えられます。今後、メールの到達性のみを確認することでS/MIME証明書が同様の仕組みで発行され、CTによってメールアドレスを一覧されてしまうケースも考えられます。

本稿執筆時には不透明な箇所もありますが、冒頭で紹介したように、ACMEメインプロトコルは急ピッチで標準化されており、identifierやchallengeにおいて新たな拡張が行われる可能性があります。また、実装・運用という観点では、Let's Encrypt プロジェクトとは別の同様のサービスが登場する可能性も秘めています。これは、現在の証明書ビジネスが変化していくターニングポイントに来ていると捉えることができるかもしれません。

経緯と改定の概要

このガイドラインは、日々変化するサイバー攻撃に対応するために、ISPなどの通信事業者が取り得る対策について例示することを目的としたガイドラインです。通信事業者において通信の遮断などの対策を行う場合に、電気通信事業法などの関連法令を考慮し、通信の秘密の侵害などの違法行為を行うことなく対策を実施するための参考資料として位置付けられるものです。このガイドラインは2007年初版以来、民間団体において自主的に策定し改定を重ねているものですが、2015年改定の第3版より、総務省の「電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会（※108）」と連動し、民間側で課題となっているサイバー攻撃の対処の適法性について総務省研究会で検討し、その結果をガイドラインに反映する形で改定を重ねています（※109）。

通信事業においてサイバー攻撃などに対処することは、多くの場合において通信の秘密の侵害に当たりますが、特定の攻撃への対処の目的と限定的な対策手法の範囲においては正当業務行為として違法性が阻却される場合があり、このガイドラインでは研究会でまとめられた考え方に基づいて、適法となる範囲の対処を示しています。

今回の第4版の改定は、研究会の第二次とりまとめ（※110）及び、とりまとめとは別に発せられた「第三者によるIP電話等の不正利用への対策について」（※111）を元にしています。この結果、タイトルを従来の「大量通信等」から「サイバー攻撃等」に変更し、ガイドラインの「電気通信役務の不正享受」への対策を追加すると共に、次の5つの対策に関する記述が追加されました。

1. DNSの機能を用いたDDoS攻撃への対策の強化
2. 脆弱性を有するホームルータなどの利用者への注意喚起
3. マルウェア感染端末とC&Cサーバなどとの通信に関するレピュテーションDBに基づいた遮断
4. 他人の認証情報を悪用したインターネットの不正利用への対処
5. 他人の認証情報を悪用したIP電話などの電話サービスの不正利用への対処
次に、それぞれについて解説します（※112）。

DNSの機能を用いたDDoS攻撃への対策

DNSの名前解決の機能を悪用し、アクセス制御などに問題のあるホームルータなどを踏み台として名前解決要求を行い、応答を引き出すことで大量通信を発生させるDNSamp攻撃については、この数年来大きな問題となっており、本ガイドラインの第3版の改定においてもその対応策が検討されています。今回の改定では、同様にDNSの機能を用いたDDoS攻撃の一種で、存在しないサブドメインに対する名前解決要求を大量に発生させることで、権威サーバやISPなどの提供するキャッシュDNSサーバに負荷を与えるような攻撃（※113）について考え方と対策例を示しています（ガイドライン中P13（キ））。このような攻撃に対して、ISPなどが利用者の名前解決のために提供しているDNSキャッシュサーバにおいて、その名前解決のFQDNを常時監視し、攻撃に関係するFQDNを判断してリスト化し、そのリストに基づいて名前解決の通信を遮断する対策について示しています。

脆弱性を有するホームルータなどの利用者への注意喚起

DNSに限らず、NTPやSSDPなど複数の通信プロトコルについて、設定や機能に問題のあるホームルータなどの機器が攻撃の踏み台となり、通信を増幅させて大量通信を発生させ、DDoS攻撃を深刻なものとしています。また、機器から認証情報が漏えいし、第三者に悪用されるような場合も増えてきています。このような機器の全体数について、各ISPや業界団体などによる実態調査が行われていますが、特定のIPアドレスを用いて接続された機器に脆弱性や設定の不備があると判明した場合でも、そのIPアドレスに関する契約情報を参照して利用者を特定する行為が通信の秘密の侵害に当たるため、注意喚起と対策につなげることができませんでした。今回の改定では、調査行為そのものに関する適法性を示すと共に、調査の結果明らかとなった脆弱性を有する機器について、利用者を特定して注意喚起を実施できるとしています（ガイドライン中P24（ヒ））。

マルウェア感染端末とC&Cサーバなどとの通信に関するレピュテーションDBに基づいた遮断

研究会第一次とりまとめ及びガイドライン第3版において、Webで感染するマルウェアの感染予防として、URLに関するレピュテーション情報を用いてアクセス制限を行い、注意喚起のコンテンツを表示する対策手法について検討が行われ、事前の契約約款における同意の在り方とオプトアウトの手法を用意する前提で対策を行ってよいという判断になりました。第4版では、Webを利用しない感染活動や、マルウェアによる感染後のC&Cサーバとの通信を阻害する対策を検討しています。このためにFQDNに関するレピュテーションDBを用いて、DNSの名前解決時に通信を遮断することで実現する対策について、適法に実施できるとしています（ガイドライン中P25 （フ））。この手法では、通信の遮断の事実やマルウェアに関する注意喚起をWebブラウザに表示するなどして利用者に示すことができないため、遮断を行わないDNSキャッシュサーバを用意して遮断を望まない利用者が利用できるようにするなどのオプトアウト策を同時に実施することが必要とされています。また、実施にあたっては、ISPなどと利用者の間における契約約款に基づく同意の在り方が厳密に検討され、少なくとも約款において規定すべき項目が示されています（研究会第二次とりまとめP14）。更に、マルウェアに感染し被害を受けることを望む利用者はいないということなどを前提とした適法性の判断であることから、このマルウェア感染予防とマルウェアの活動防止の目的以外において、例えば、違法・有害コンテンツへのアクセスにおいて、この手法を取ることは通信の秘密の侵害にあたる可能性があると判断されました（研究会第二次とりまとめP12及びガイドラインP26③）。

他人の認証情報を悪用したインターネットの不正利用への対処

脆弱性を有するホームルータなどの装置から、インターネットの接続に利用するISPが提供した認証情報を不正に取得され、第三者により犯罪などに悪用される事例があることから、認証情報の悪用に関する対策が検討されました。ISPなどの認証サーバにおける認証の様態を常時調査し、例えば短時間に大量の認証を繰り返すことや、北海道の利用者が瞬時に九州から接続し直すなど、実際の移動が不可能な短時間に地域的な移動が行われている場合など、不正利用の蓋然性が高い認証の試みを見つけること、及びその情報を持って認証の処理を一時停止して、利用者に状況を確認することが対策として示されました（ガイドラインP27（ヘ））。

他人の認証情報を悪用したIP電話などの電話サービスの不正利用への対処

IP電話に利用するSIPサーバへの不正アクセスにより不正に国際電話をかけられ、正規の利用者が心当たりのない通信費用を請求される事案が発生しています（※114）。この問題への対応として、契約者の国際電話料金などを一定の頻度で検知した上で、平時と比較して急増した場合に、相手国、発信元電話番号、発信IPアドレスなどを分析し、正規の利用者によるものかどうかを判断してよいと示されました。そして正規の利用者によるものでない蓋然性が高い場合には、利用者に連絡をしたり、連絡が取れない場合に当該回線に関する国際発信を休止したり、当該IPアドレスからのSIP認証を一時停止したりすることが対策として示されています（ガイドラインP28（ホ）、P29（マ））。また、これらを含む不正利用対策では対応が困難な場合、不正利用に用いられていると認められる特定国宛ての発信一般を、一時的に規制する手法も示されています（ガイドラインP29（ミ））。

まとめ

これまで示したように、本ガイドラインでは今発生しているサイバー攻撃への対策に関して、個別の対策を検討し、その適法性を示しています。その実現にあたっては、各通信事業者に関わる攻撃の状況や、コスト、副作用を最小とするための技術的検討項目など、様々な条件があるため、これらの対策のすべてが実施されるわけではありません。しかし、サイバー攻撃を取り巻く状況が日々変化する中、いざというときにすぐに参照できる規範が示されていることは、多くの通信事業者、及びその利用者にとって有益なものとなっています。