ページの先頭です

ページ内移動用のリンクです
  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review（IIR）
  5. Vol.24
  6. 1.インフラストラクチャセキュリティ

Internet Infrastructure Review（IIR）Vol.24
2014年8月22日発行RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、OpenSSLの脆弱性、国内金融機関の認証情報などを窃取するマルウェア「vawtrak」、クラウドの安全性確認と監査制度の3つのテーマについて紹介します。

1.4.1 OpenSSLの脆弱性

OpenSSL（※46）は、オープンソースの暗号処理ライブラリの実装であり、UNIX環境において広く使用されています。類似の機能を持つ実装としては、GnuTLS（※47）やNetwork Security Services（NSS）（※48）があります。Windows環境においては、OSの標準機能として、Cryptographic API（CryptoAPI）やCryptography API Next Generation（CNG）が組み込まれています。これらのライブラリは、Webなどの通信の暗号化、サーバ証明に用いられる処理を受け持っており、秘匿性の高いデータを扱っています。最もよく目にする使用箇所としては、Webサービスにおける秘密の保護です。ユーザの認証や、オンラインショッピングにおけるクレジットカードなどの決済情報の入力時への利用がこれにあたります。

OpenSSLライブラリの脆弱性や、SSL/TLSにおいて利用可能な特定の暗号方式に対する効率的な攻撃方法は過去にいくつも公開されました。しかし、これらの脆弱性では攻撃の成立に様々な前提条件が要求されたり、攻撃が成立した結果得られる情報も断片的であったりと、即座に深刻な影響を受けるものはほとんどありませんでした。一方で、今回発見されたHeartbleedではサーバ側に保存されている秘密鍵やデータの漏えいが、CCS Injectionでは暗号化された通信が解読できるなど、致命的な影響があるため、大きく話題となりました。どちらの脆弱性も、特定の暗号方式やSSL/TLSの仕様における問題ではなく、OpenSSLの実装に起因する問題であったため、他の実装においてはこれらの脆弱性の影響を受けませんでした。

Heartbleedとは

表-1 Heartbleed影響実装一覧

この脆弱性は、2014年4月7日にOpenSSLのセキュリティアドバイザリ（CVE-2014-0160）（※49）として公開されました。系列ごとの影響の有無を表-1に示します。この脆弱性の影響を受けるOpenSSLのバージョンは、1.0.1以降のみでした。クライアント、サーバ実装の組み合わせに関わらず、該当バージョンであれば脆弱性の影響を受けました。

OpenSSL 1.0.1以降のバージョンは、新しいプロトコルバージョンであるTLS v1.1、TLS v1.2を利用するために必要です。TLS v1.1、TLS v1.2は過去に発見された仕様に起因する問題の修正、強度の高い暗号方式が追加されるなど、様々なセキュリティが強化されたプロトコルバージョンです。影響の有無は、このOpenSSLのバージョンを境界として分かれており、セキュリティ強化のために新しいプロトコルバージョンをサポートした箇所に限って、影響を受けてしまうという皮肉な結果になりました。具体的には、ハートビート処理の実装に問題があり、細工したデータをリクエストとして送ることにより、本来読み出せないプロセスのメモリ領域をレスポンスに含めさせることが可能となっていました。

このように、本来読めないはずのメモリ上のデータが読めてしまう脆弱性は、ローカルのみから攻撃可能なカーネルやドライバの脆弱性としては、過去にも多く発見されています。しかし、今回のHeartbleedの脆弱性においては、それがネットワーク越しに可能であること、読み出し可能なサイズが大きいこと、攻撃を受けてもログが残らないことから大きな問題となりました。
攻撃により得られるメモリ上のデータは、OS、メモリアロケータ、アプリケーションの実装や稼働状態に依るため、必ずしも狙ったデータが得られる訳ではありません。しかし、この攻撃は非破壊的な攻撃手法であり、何度でも試行が可能でした。得られるデータには、サーバの保持する秘密鍵や、他のユーザの認証情報など、本来外部から知り得ないデータが含まれる可能性も指摘されていました。

この脆弱性の公開後に、CloudFlare社によって、この脆弱性を用いてサーバに保存された秘密鍵を奪取することを試みる、The Heartbleed Challenge（※50）が開催されました。開始後まもなく鍵の奪取の成功が複数報告され、秘密鍵の漏えいが現実的な脅威であることが示されました。また、秘密鍵の情報を完全に奪取しなくても、部分的な情報から秘密鍵を復元できることも指摘されています（※51）。

この脆弱性への対応として対策版へのバージョンアップも必要ですが、併せて秘密鍵の漏えいを考慮し、新しい鍵ペアの作成とそれを用いた証明書の再発行、既存の証明書の失効が必要になります。これは、過去において攻撃を受けていないことを証明するのが困難であり、既に秘密鍵が漏えいしていた場合を想定した対応が必要なためです。

CCS Injectionとは

この脆弱性は、2014年6月5日にOpenSSLのセキュリティアドバイザリ（CVE-2014-0224）（※52） （※53）として公開されました。影響を受けるOpenSSLのバージョンは0.9.8以降であり、公開時点においてサポート中の全バージョンが対象でした。この脆弱性の影響を受ける実装の組み合わせを、表-2に示します。クライアントは0.9.8以降、サーバは1.0.1以降の組み合わせにおいてのみ脆弱性の影響を受けました。

表-2 CCS Injection影響実装一覧

この脆弱性は、SSL/TLSのネゴシエーション完了後に暗号化通信に切り替えるChange Cipher Specメッセージの処理に問題があり、中間者攻撃による暗号化通信の完全な解読や改ざんが可能となっていました。

過去において、今回の脆弱性同様に完全な形式での解読が可能な脆弱性としてはSSL v2の問題がありました。SSL v2については、ネゴシエーション時の通信が保護されていないため、容易に改ざんすることができました。このため、通信に用いる暗号アルゴリズムを、攻撃者が解読可能な強度の弱い暗号アルゴリズムに強制的にダウングレードさせることが可能でした。SSL v3以降において、ネゴシエーション時の通信改ざんを検知する仕組みが導入されたため、この問題はなくなりました。しかしながら、今回の脆弱性で利用されたChange Cipher Specメッセージは、改ざん検知の対象から外れており、OpenSSLの実装では中間者攻撃にて挿入することが可能でした。

Change Cipher Specメッセージの処理は、同じバージョンのOpenSSLにおいても、サーバ側とクライアント側で異なります。この差異が使用箇所によって、影響を受けるバージョンが異なる理由です。脆弱性の特性上、サーバ、クライアント双方を攻撃する必要があるため、いずれかが脆弱性の対象ではないバージョン、またはOpenSSL以外の実装を使用している場合は影響を受けません。他にも影響の有無を分ける細かい条件はありますが、こちらについてもIIJ Security Diary（※54）において考察をしています。

こちらの脆弱性は、Heartbleedと異なり、サーバに保存されている秘密鍵の漏えいなどは発生しませんので、対策版へのバージョンアップのみで問題ありません。

まとめ

OpenSSLのような広く使われているライブラリに脆弱性が見つかると、その影響は広範囲に及びます。更に、暗号処理を必要とする通信は、重要な情報を扱っている場合が多いため、必然的に大きな問題になります。

今回のHeartbleedが大きな問題となった後、Linux Foundationは大手IT企業と共に、基盤となるオープンソースプロジェクトを支援するCore Infrastructure Initiative（※55）を立ち上げました。この支援先候補として、OpenSSLプロジェクトが挙げられています。

OpenBSDプロジェクトは、新しくLibreSSLプロジェクト（※56）を立ち上げました。LibreSSLは、OpenSSLのコードを元として、リファクタリング、不要な機能やコードの削減、セキュリティを重視した実装への変更を進めています。

Google社も同様にBoringSSLプロジェクト（※57）を立ち上げました。こちらはOpenSSLの置き換えを目的としておらず、自社のソフトウェア向けに特化した派生プロジェクトです。まずはその成果をChromeのベースとなっているChromiumへ適用し、将来的にはAndroidなどへ展開する計画のようです。

いずれもアプローチは異なりますが、基盤となるソフトウェアにHeartbleedのような大きな問題を再び起こさないために動いていると考えられます。このように、ソフトウェアを作成する側も様々な対策を講じていますが、それでもバグや脆弱性の根絶は困難です。そのため、ソフトウェアを利用する側も公開された脆弱性情報を理解し、影響を受ける脆弱性が公開された場合には、適切に対応する必要があります。

1.4.2 国内金融機関の認証情報などを窃取するマルウェア「vawtrak」

vawtrak（別名Neverquest、Snifula、ZeuS Based Ponyなど）は、2013年頃から海外で感染事例が報告されているマルウェア（※58）ですが、2014年4月から6月にかけて、日本国内で観測されるようになりました（※59）。感染したパソコンに保存されている認証情報や、オンラインバンキング利用時の認証情報などを窃取する機能、VNCプロトコルで外部からパソコンを直接操作する機能などを備えており、日本国内の改ざんされたWebサイトを経由して感染を広げていました。IIJでは、MITFのWebクローラ（※60）によって収集されたvawtrakの検体を抽出し、解析を行いました。本稿では、その解析結果と対策を紹介します。なお、当該検体のハッシュは以下のとおりです。

主な機能と特徴

vawtrakの注目すべき特徴として、ZeuS（別名Zbot）（※61）及びPony（別名Fareit）（※62）に酷似した機能を備えていることが挙げられます。具体的には、Webinject（※63）、Dynamic Config、Report、VNC ServerやSOCKS ProxyといったZeuSの特徴的な機能のほとんどを備えています。また、パソコンに保存されたWebブラウザ、メールクライアント、FTPクライアントやsshクライアントなどの設定ファイルからアカウント情報を収集する機能も持っており、この機能の対象とするアプリケーションの種類は、Ponyが対象としているものとほぼ一致します。今回のvawtrak検体におけるZeuS、Ponyとの実行コードの一致率（BinDiffによる）は、それぞれ約8%、20%でしたが、ZeuS、Ponyは、いずれも以前にソースコードがインターネット上に流出したことがあるため、これらのソースコードを参考に多くの機能を組み込んでいるのではないかと推測されます。

以下では、vawtrakの動作フローに沿って検体の各機能について紹介します。

図-13 vawtrakによって改変されたレジストリ

感染時、最初に実行されるのはexe形式のDropperです。これは、実行環境に合わせて32bitまたは64bitのdllファイルを、ランダムなファイル名に.dat拡張子を付与した名前でCSIDL_COMMON_APPDATA（Windows Vista、7、8の場合はC:\ProgramData）にドロップし、起動時に自動実行されるようレジストリを改変します（図-13）。そして、先のdllファイルと同等のvawtrak本体をexplorer.exeにコードインジェクションした上で、自身を削除して終了します。

Dropperは削除されてしまいますが、ドロップされたdllファイルや自動起動のレジストリエントリは比較的容易に見つけられるため、本検体感染のインジケータとして利用することが可能です（※64）。

explorer.exeにインジェクションされたコードは、更に、svchost.exeやwininit.exeなど一部のプロセスを除くすべてのプロセスにコードインジェクションを行います。その後、パソコンのユーザがInternet ExplorerやFirefoxなどのブラウザを起動してインターネット通信を始めると、vawtrakはあらかじめ決められたC&CサーバにHTTPで接続し、追加の設定などが含まれるDynamic Configを受信します。Dynamic ConfigはaPLib（※65）で圧縮され、更に独自方式で暗号化されており、受信後に復号されます。また、再起動に備えてレジストリに保存されます。

本検体が保持していた接続先C&Cサーバを以下に示します。

  • baggonally.com
  • mentilix.com
  • bennimag.com
  • humpold.com
  • sandoxon.com
  • 185.13.32.67
  • 185.13.32.80
  • 146.185.233.38
  • maxigolon.com
  • 146.185.233.80
  • terekilpane.com

Dynamic Configを取得して解析をしたところ、Webinjectを行う対象として、日本国内の大手金融機関などのオンラインバンキングやクレジットカード関連サービスを提供するURLが記載されていました（図-14）（※66）。また、閲覧時の情報窃取の対象として、国内外の著名なSNSやクラウドサービス、動画共有サービス、ファイル共有サービスなどを提供するURLも列挙されていました。

図-14 取得したvawtrakのDynamic Configの一部（復号済み・赤枠部は国内の金融機関などのサービスを示すURL）

vawtrakは、前述のDynamic Configに加えて、次に行うべき命令（Command）をC&Cサーバから受信します。今回の解析時には、vawtrak自身のバージョンアップ及びパソコンに保存されたデジタル証明書を窃取する命令を受信したことを確認しました。デジタル証明書窃取は、Windows OSの提供する証明書ストアに保持されているすべての証明書を抽出し、C&Cサーバに送信する機能です。パソコンに保存されるデジタル証明書にはいくつかの用途があり、証明書が漏えいした場合には、それぞれの用途で第三者によって成りすまされてしまう危険があります。

その他に、ZeuS、Ponyとは異なる機能として、ソフトウェア制限ポリシーを用いてマルウェア対策ソフトウェアを妨害する機能や、Rapport（※67）の無効化を試みる機能などを備えていました。vawtrakと、ZeuS、及びPonyとの機能の対応をまとめると表-3のようになります。

表-3 vawtrakの特徴的な機能及びZeuS、Ponyとの対比

感染経路

MITFのWebクローラは、国内のユーザを対象とした複数のWebサイトでvawtrakを取得しました。該当のWebサイトはいずれもトップページのHTMLファイルが改ざんされ、iframeタグを不正に挿入されていました。Webサイト閲覧者はこのiframeタグによって外部のWebサーバに誘導され、最終的にNuclear Exploit KitやAngler Exploit Kitを用いたドライブバイダウンロードによってvawtrakなどのマルウェアに感染させられてしまいます。

海外では、メールなどによってvawtrakが配布されていることが報告されています（※68）。日本国内では、主に改ざんされたWebサイトを経由したドライブバイダウンロードによって感染を広げているものと推測されます。

なお、改ざんされていたWebサイトのうち1件は、日本国内の著名なコンテンツプロバイダのグループ企業で、4月下旬から6月中旬まで、及び7月中旬から下旬までの期間、改ざんされた状態が断続的に観測されました。このような著名Webサイトを含む複数のWebサイトで、改ざんされた状態が長期間継続していることを観測しています。

対策

ドライブバイダウンロードによるマルウェア感染を防止するためには、クライアントPCのOS、ブラウザ、及び関連プラグインを常に最新の状態に更新し、脆弱性のない状態に保つことが重要です。また、クライアントOSがWindowsの場合には、ソフトウェアの制限ポリシーを用いてプログラムの実行可能領域を制限したり、EMETをインストールして脆弱性の影響を緩和しておくことも効果的です（※69）。

万が一、vawtrakに感染してしまった場合には、クリーンインストールなどのパソコン復旧対応だけでなく、パソコンで利用していたデジタル証明書の失効処理と、パソコン上のクライアントアプリケーションで利用していた各種アカウントのパスワード変更が必要です。更に、該当パソコンでオンラインバンキングやSNSなどのWebサービスを利用していた場合は、それらのサービスのアカウント情報やサービス上でやりとりした情報についても、漏えいした可能性を念頭に、適宜変更や削除などの対処を行う必要があります。

一方、Webサイト運営者、管理者の立場では、サイトが改ざんされExploit Kitの誘導元にならないよう、運用に注力する責任があると考えるべきです。Webサーバ、コンテンツ管理システムやそのプラグイン、あるいはそれらが依存するフレームワークなど、利用しているシステムを網羅的に把握し、脆弱性攻撃の影響を受けないよう管理する必要があります。また、CDNや広告サービス、アクセス解析サービスなど、自社Webサイトに関連する外部（社外）リソースがセキュリティ侵害を受けたことにより、Webサイト閲覧者をマルウェア感染の危機に晒してしまうケース（※70）も散見されます。自社のシステムの診断を重ね、防御を固めるだけでは、このような外部システムに起因する脅威を排除することはできません。提供しているサービスの性質にもよりますが、完全性を担保できない外部リソースについては、その重要度に応じて内製化や廃止などを検討しておくことを推奨します。その上で、外部リソースの利用を継続する場合には、問題を少しでも早く直接把握するために、定期的に外部からWebサイトを閲覧し、実際にクライアントPCにダウンロードされるコンテンツを確認しておくことを推奨します。

1.4.3 クラウドの安全性確認と監査制度

ここでは、利用者がクラウドサービスを安心して利用するために公開されている、各種ガイドの利用について検討すると共に、クラウドセキュリティ推進協議会で検討されている「クラウド情報セキュリティ監査制度」について解説します。

クラウドセキュリティに関するガイド

2006年にクラウドコンピューティングの概念が提唱されてから既に8年が経過しました。その後、クラウドコンピューティング技術を使ったサービス（以下クラウドサービス）が続々と提供され、広く一般に利用されています。しかし、当初よりその安全性については様々な疑問が投げかけられており、クラウドサービス導入の障壁としてセキュリティへの懸念が筆頭に挙げられていました。実際に、国内外を問わず大規模な情報セキュリティ事故が発生したことは記憶に新しいところです。その後様々な議論を経て、現在では、各種の団体からクラウドを安全に提供・利用するためのガイドなどが公表されています。ここで、表-4に代表的なガイドなどを例示し、その概要を説明します。
このように、クラウドセキュリティに関するガイドは様々な組織、団体から発行されています。ガイドの数が多くなると目的に合ったガイドの選択が難しくなる面はありますが、以前と比べて容易に情報が入手できるようになったことは歓迎すべきことです。

表-4 クラウドを安全に提供・利用するための代表的なガイドなど

ガイド利用時の注意点

これらのガイドには、クラウドサービスを利用、もしくは提供する上で検討すべきセキュリティ事項に関しての有用な情報が数多く含まれており、チェックリストとしても広く活用されています。しかし、ガイドの対象者（利用者や事業者）、対象物（サービスや情報）をあいまいにすると様々な解釈が可能となり、誤解や混乱が起きやすくなります。
例えば「特権アカウント」は、「クラウドサービスを提供している事業者がサービス全体の維持や保守に使うアカウント（1）」、「サービス事業者の情報システム部が持っている特権アカウント（2）」、「利用者がIaaSで利用している仮想マシンのroot（Administrator）アカウント（3）」、「SaaSでユーザ登録、削除などの保守を行うアカウント（4）」などの解釈が可能です。参照したガイドが利用者用ガイドであれば、「特権アカウント」は（3）もしくは（4）、事業者用ガイドであれば（1）もしくは（2）となります。解釈の違いによりチェックリストの設問の意味合いが異なるため、適切なリスク評価やサービス利用ができなくなる恐れがあります。

適切なリスク評価を行うための1つの方法は、対象者と対象物を明確にして事業者と利用者で合意をとることです。例えば、「特権アカウント」は利用するサービスの保守用アカウントのことである、ということを（利用者からでも事業者からでも、どちらからでもよいので）明確にして合意します。事業者と利用者のコミュニケーションが発生するため、時間や手間がかかりますが、認識のずれや思い込みを減らすことはできます。ただし、クラウドサービスの特徴である自動化を阻害しますし、すべての事業者がこのような個別の対応に答えてくれるとは限りません。

別の方法は、事業者が開示している情報を探してそのまま利用することです。どのようなセキュリティ機能が提供され、どのようなセキュリティ対策が取られているか、各事業者が何らかの形で公開していますので、これらの公開情報から、利用者の求めるセキュリティ水準が維持できるかを利用者自身で判断します。一般的なクラウドサービスによく見られるこの方法は、時間がかからず手軽である反面、事業者が公開可能とする情報や粒度がまちまちで、望んだ内容の回答が得られなかったり、回答の信頼性に関しての確認が難しかったりします。

他にも、SSAE16報告書などを利用する方法もあります。事業者は外部監査人に対してのみ情報を公開し、利用者は事業者の統制状態について第三者からの信頼できる評価結果を受け取ることが可能です。利用者、事業者共に利点がある方法ですが、この方法は外部監査人に対して非常に高度なIT知識を要求することや、事業者が支払うコスト負担が大きくなる（ひいてはサービス価格の上昇につながる）ことから、幅広くクラウドサービスで対応することは困難です。

これら様々な課題を解決し、適切なリスク評価を行う方法として、クラウド事業者が共通の基準に従ってセキュリティを評価し、信頼できる情報を開示する取り組みが始まっています。次にその取り組みを紹介します。

クラウド情報セキュリティ監査制度

図-15 クラウドセキュリティ監査におけるそれぞれの役割

クラウドサービスを利用するということは、多数の利用者が資源を共同で利用するためにサービス事業者が用意したシステムを決められた使い方で利用するということです。従って、システムインテグレーションのように、利用者のシステム環境が専用で構築され、その構成や運用体制の詳細が明かされるといったことはありません。また、クラウドサービスは環境が動的に変化するため、その仕組みの内部を推測することにも意味はありません。コストをかけて監査を行ったとしても、事業者が利用者にすべての仕組みを明らかにすることはありません。クラウドサービスを「ブラックボックス」として利用することは避けられません。従来型のオンプレミス企業システムを前提としたセキュリティやリスク評価の考え方がクラウドサービスに適用しづらいのは、これが一因と言えます。

そこで、2013年4月に、日本セキュリティ監査協会（以下JASA）を発起人としてクラウドサービスに関連する事業者など25社が集まり、「JASA-クラウドセキュリティ推進協議会（以下J-CISPA）」が発足しました。JASAでは従来の情報セキュリティ監査制度をベースとして、それをクラウドコンピューティングに適用した、「クラウド情報セキュリティ管理基準」を2012年9月に公開しています。そこで定められている基準を元に、クラウドサービスに適したシステム監査を行い、適切なリスク管理を行うための情報を利用者に提供しようとしています。この試みは世界に先駆けて行われており、J-CISPAでは、活動で得られた知見を元に、クラウドセキュリティの国際標準として検討中のISO27017やISO27036-4への提案なども積極的に行っています。
J-CISPAで想定されている監査の仕組みを図-15と共に説明します。

表-5 クラウドサービスで懸念されるリスク（J-CISPAの資料から引用）

J-CISPAでは、一般的にクラウドサービスで懸念されるリスク（表-5）を定めています。まず、クラウド事業者はそれらリスクに対してどのように対応しているかを明らかにして文書化します。その文書を「言明書」と呼びます。サンプルとして、IIJがパイロット監査（後述）で行った言明書を図-16に示します。次に、言明書で書かれた内容に対して、JASAで定める監査人資格を持った内部監査人が、言明書の内容に関して監査を行い、監査結果を記録します。内部監査人は、JASAの有識者WGで検討されたクラウド内部監査標準手続に定められた監査手続きを使って監査を行います。監査内容や手続きが詳細に定義されていますので、監査人が異なる場合でも監査品質は変わりません。共通の監査基準を利用することで、異なる事業者、異なるサービスでも、リスクにどう対応しているかの比較が行いやすくなります。

なお、この仕組みは、内部監査人が監査を行うことを前提としています。クラウドサービスの仕組みは発展途上であり、時々刻々と変わっていくため、IT技術に精通した専門家でなければ監査の情報が正しいかどうかを判断することが困難です。サービス事業者の内部監査人であれば正確なサービス知識を持った上での判断を行うことが可能であり、これも一定の監査品質を確保することに役立っています。加えて、クラウド事業者は自社のサービスに関する秘密情報を外部に出さなくてもよくなるため、事業者の負担も軽減されます。

しかし、いくら認定された内部監査人が決まった手続きで監査を行うとしても、利用者から見た場合には、ただの自己主張であることに変わりはありません。そこで、この監査制度では内部監査結果をうまく利用する形で外部監査を取り入れています。具体的には、内部監査で得られた「内部監査報告書」などを元に内部監査が正しい手続きで行われたものであるかどうかを外部監査人が検証するというものです。内部監査として技術的に確かな内容で、手続きや書式が均一の監査報告書が残るため、外部監査では「内部監査が正しく行われたかどうか」を監査すればよいということになります。

本監査制度ではこの2段階の仕組みを取り入れることで、クラウドサービスに関する技術情報の正確な判断と、正確な監査手続きを、可能な限り低コストで両立させようとしています。コストを抑えることでより多くのクラウドサービスが本制度に対応可能となります。J-CISPAでは内部監査人により監査された言明書にシルバーマーク、その結果が外部監査人により検証された場合はゴールドマーク、という形でマークを発行します。2013年度に、協議会のクラウドサービス事業者各社が「パイロット監査」として、この仕組みを試行しており、今年度は、この結果を元に本監査を行うべく、精力的に準備が行われています。

クラウドサービスを安心して利用していただくために、IIJはこのような新しい制度や国内、国際的なルール作りをこれからも積極的に推進して参ります。

図-16 パイロット監査における言明書の例

図-16 パイロット監査における言明書の例

1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る