ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.26
  6. 1.インフラストラクチャセキュリティ

Internet Infrastructure Review(IIR)Vol.26
2015年2月25日
RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、ドメイン名のレジストリ登録情報改ざんの対策、端末のメモリ内に潜む脅威をスキャンするopenioc_scan、ID管理技術の3つのテーマについて紹介します。

1.4.1 ドメイン名のレジストリ登録情報改ざんの対策

レジストリ登録情報の改ざんによる脅威

インターネットの世界では、ドメイン名が重要な役割を果たしています。例えば、クライアントがwww.example.comにアクセスする際、サーバが属するexample.comゾーンの権威DNSサーバに問い合わせを行い、サーバのIPアドレスを取得します(図-13左)。この一連のやりとりを名前解決と言います。

しかし、名前解決の結果、正規のサーバではなく、攻撃者が用意したサーバにアクセスさせられてしまう攻撃があります。この攻撃はドメインハイジャックと呼ばれ、攻撃手法として、「ドメインの所有者のDNSサーバに不正侵入しレコードを書き換える」「DNSキャッシュポイズニングにより不正なIPアドレスをキャッシュDNSサーバにキャッシュさせる」「BGPに誤った情報を流し、特定のトラフィックを本来のネットワークとは異なるネットワークへルーティングさせる」などが存在します。

このような攻撃手法はISPやサービス提供事業者の対策により影響は少なくなっていますが、異なる攻撃手法によるドメインハイジャックが、国内企業のドメインにおいて、2014年9月以降に複数発生しました。この攻撃手法では、レジストリに登録されているドメイン名に関する登録情報を書き換えることで、名前解決の際に、攻撃者が用意したサーバのIPアドレスを応答させるようにします。この結果、正しいドメイン名を入力しても、攻撃者が用意したサーバにアクセスさせられ、フィッシングやマルウェア感染などの被害に遭ってしまう可能性があります。TLD(Top Level Domain)(※43)の権威DNSサーバに偽の情報が登録されるため、自身のサーバのセキュリティレベルが高くても、攻撃の影響を受けてしまうのが特徴です(図-13右)。なお、偽の情報が登録されるのは、サーバが属するドメインの上位の権威DNSサーバであればよいため、ドメインの階層が深い場合、TLDではなく、SLD(second-level domain)などの権威DNSサーバに偽の情報が登録される場合があります。

図-13 www.example.comの名前解決(DNSプロトコルは一部省略)

2014年9月から10月にかけて発生したインシデントでは、国内の複数の企業が保有する「.com」ドメインに対して、Webページの訪問者にマルウェアをダウンロードさせようとする攻撃が行われました(※44)(※45)。また、2014年11月には海外企業が提供するSNS連携サービスを利用している国内外の大手新聞社やニュースサイトなどで、Webページの訪問者に不正なJavaScriptファイルを読み込ませ、SEA(Syrian Electronic Army)の意匠を表示させるインシデントが発生しました。

なお、2014年11月のインシデントでは、すべてのNSレコードが攻撃者のものに改ざんされ、必ず不正なJavaScriptが読み込まされる状態でしたが、9月から10月の国内企業のドメインのインシデントでは、正規のNSレコードは削除されずに攻撃者のNSレコードの追加だけが行われていました。このため、一部のユーザのみが影響を受ける結果となりました。

今回と同様の手法を使った攻撃は、海外においては既に数多く発生しています。例えば、2013年では、多数のレジストリが攻撃対象となり、毎月のように事件が発生しています(※46)

レジストリ登録情報改ざんの手法

ドメインに関する情報はTLDを運用・管理するレジストリという組織のデータベースに登録されています。ドメインを登録するには、レジストラと呼ばれる仲介業者(またはレジストラのサービスを再販するリセラー)のサービスを利用して、レジストリにドメインの登録申請を行います。ドメインの登録情報は図-14の矢印の順番で受け渡され、レジストリの権威DNSサーバとWHOISサーバに登録されます。

したがって、攻撃者は以下のいずれかのポイントを攻撃することで、レジストリ登録情報の改ざんを行います。

  1. 登録者やリセラーになりすまして、レジストラのデータを改ざんする。
  2. レジストラになりすまして、レジストリのデータを改ざんする。
  3. レジストリやレジストラのシステム上の脆弱性を利用してデータを改ざんする。

なりすましはドメインの登録者に対するフィッシングやマルウェア感染、ソーシャルエンジニアリングなどで得られた情報を基に行われます。また、レジストリやレジストラのアカウント情報流出やリスト型攻撃が原因となることも考えられます。

改ざんされるデータは、レジストリのWHOISサーバに登録されているネームサーバや権威DNSサーバに登録されているNSレコード及びグルーレコードです。

図-14 ドメイン情報登録の流れ

対策

以下にレジストリ登録情報の改ざんの対策を説明します。

レジストリ/レジストラ/リセラー

最も基本的なセキュリティ対策として、OSやWebアプリケーション、APIなどの脆弱性の修正やパッチ適用が必要です。組織内のクライアントもパッチ適用やアンチウイルスのインストールなどの対策を行わなければなりません。

次に、なりすましに備え、ユーザアカウントの認証機能の改善を検討します。多くのシステムではパスワードによる認証を行っていると思いますので、複雑なパスワードの設定やパスワードの使い回し防止が必要になります。可能であれば、2段階認証やクライアント証明書による認証の導入も検討してください。

また、ユーザアクティビティの監視・通知機能の実装も検討してください。アカウントのログインや登録情報の変更を通知することで、ユーザが意図しない操作に気付くことができます。また、ログインや登録情報変更の履歴があれば、いつ頃から不正アクセスがあったのかユーザ自身でも確認できます。

実際の攻撃に備え、攻撃の検知と対処の体制を整える必要もあります。セキュリティ機器やシステムの負荷やログから攻撃を検知し、適宜、FWなどで遮断します。

最後に、「レジストリロック」の提供を検討してください。これはレジストリの登録情報の変更を制限する機能で、登録情報を変更する際に登録者に追加の認証が必要となるため、意図しない情報の変更を防ぐことができます。

なお、海外のレジストラではFAXによってメールアドレスやパスワードをリセットするサービスが悪用された例もあります。同様のサービスを提供している場合は、サービスの必要性や本人確認フローを見直した方がよいでしょう。

登録者

先に説明したような対策を実施しているレジストリ/レジストラを選ぶことが重要です。レジストラが提供している認証強化や通知機能、レジストリロックなどを積極的に利用してください。また、OSのパッチを適用し、最新版のソフトウェアを利用します。併せて、アンチウイルスもインストールしてください。また、レジストラのアカウントのパスワードは、使い回しをしてはいけません。

通知機能を使用する場合は、通知メールがスパム判定されないように設定します。このとき、連絡用のメールアドレスは、自身が登録しているドメイン以外のものにしてください。仮にレジストリ登録情報が改ざんされても、レジストラなどと連絡を取ることができます。また、WHOISの公開情報に登録者の情報を表示しないオプションがある場合は、有効にすることを検討してください。

更に、定期的に「WHOISサーバ」と「レジストリの権威DNSサーバ」に登録されている情報が改ざんされていないか確認することで、いち早くレジストリ登録情報の改ざんに気付ける可能性があります。WHOISサーバでは「ネームサーバ」、レジストリの権威DNSサーバでは「ドメインのNSレコード及びグルーレコード」を確認してください。

ただし、これらの情報を監視する標準的なツールは存在しないため、各自で作成する必要があります。有志により、いくつかの監視ツールが公開されていることを確認していますが、特定のレコードのみが監視対象となっていたり、レジストリの権威DNSサーバへ直接問い合わせを行わなかったりするなど、使用する場合は事前に十分な動作確認が必要です。

また、監視を行う場合、レジストリの権威DNSサーバとWHOISサーバに必要以上の問い合わせを行わないようにしてください。過剰に問い合わせを行った場合、レジストリに対する攻撃であると判断され、問い合わせが制限または遮断される可能性があります。

一般ユーザ

一般ユーザがレジストリ登録情報が改ざんされているか否かを見分けることはほとんど不可能です。したがって、攻撃者が用意したサーバにアクセスしてしまっても、脆弱性が利用されないようにOSのパッチ適用や最新版のソフトウェアと併せて、アンチウイルスソフトウェアを使用してください。

なお、レジストリ登録情報の改ざんではサーバのSSL/TLSの秘密鍵を盗むことはできないため、攻撃者はSSL/TLSで暗号化を行うサービスを提供できません。したがって、普段はHTTPSで提供されているサービスにHTTPでアクセスしていたり、SSL/TLSのエラーが発生している場合は、レジストリ登録情報が改ざんされている可能性が考えられますので、サービスの利用を中止したほうがよいでしょう。

まとめ

現時点で最も効果的な対策はレジストリロックですが、この機能を提供していないレジストリもいます。また、万が一、レジストリロックが突破されてしまう事態に備えて、レジストリロックの有無に関わらず、これまで説明した対策を実施することで、レジストリ登録情報の改ざんの防止や早期発見することができます。

ユーザ数が多いサービスを提供するドメインほど、被害が大きくなるため、この機会に対策を実施してください。

1.4.2 端末のメモリ内に潜む脅威をスキャンするopenioc_scan

IOC(Indicator Of Compromise)とは、ネットワーク上や端末内に残る、マルウェア感染や不正侵入の脅威を示す痕跡のことです。マルウェア解析やフォレンジック解析の結果に基づいてIOCを定義することで、次回以降同じ脅威を素早く検出することができます。本節では、IIJで新たに実装した端末のメモリ内のIOCをスキャンするツールの紹介と、それを使った汎用的なIOCに関する検討について述べます。

実装の背景

図-15 IOC Bucketで共有されているIOCフォーマットの数と割合

IOCという用語は、特定のフォーマットや実装を指すものではありません。IOC Bucket(※47)というサイトでは、複数のフォーマットのIOCが共有されています。図-15は同サイトで共有されているIOCフォーマットの数と割合を示したものです(2015年1月8日時点)。

図から、OpenIOC(※48)が3/4以上の割合を占めており、メジャーなフォーマットとして普及していることが分かります。以前IIJ SECTブログの記事で紹介したとおり(※49)、OpenIOCの定義に基づいてスキャンを行うフリーツールとしてIOC FinderやRedlineがあります。IOC Finderは稼働中のシステムに対してスキャンするツールで、ライブレスポンスを効率的に行うことができます。一方でRedlineは、保全したメモリイメージをオフラインでスキャンします。後者の場合、オフラインなのでマルウェアによる情報の隠蔽を無効化できますし、メモリ上の文字列やアンパック後のコードの特徴を定義できるので、マルウェアの機能に即した定義が可能になります。

これまでIIJでは、OpenIOCとRedlineを活用したマルウェアの早期検出について、検討を行ってきました(※50)。しかしながら、Redlineはクローズドソースのツールであり、機能拡張やバグの修正を自分達で行うことができないという問題がありました。そこで、オープンソースのツールであるVolatility Framework(※51)のプラグインとして、openioc_scan(※52)を実装しました。

openioc_scan

openioc_scanの使用方法について説明します。openioc_scanの解析対象はVista以降のWindows OS(※53)のみで、LinuxやMac OS Xは現在サポートされていません。また、実行にはlxml(※54)、ioc_writer(※55)、colorama(※56)の3つのPythonパッケージが必要です。更に、IOCを事前に定義しておく必要があります。openioc_scanは正規表現や後述するparameterをサポートするため、OpenIOC 1.1のフォーマットを利用します。OpenIOC 1.1の定義が可能なフリーツールは、現状PyIOCe(※57)のみです。よってIOCの定義にはこのツールを利用します。

図-16 PyIOCeを使ったIOCの定義の例

図-16はPyIOCeの画面の一部です。ユーザはこの画面上でvolatilityのterm(項目)を定義していきます。図ではProcessItem/ParentProcessNameとProcessItem/nameの2つのtermがAND/ORのロジックで組み合わされて定義されています。図のようにNOT(否定)を指定できるほか、大文字小文字の区別、マッチングの指定(※58)なども可能です。

図-17 openioc_scanの実行

IOCを定義したら、図-17のように、その定義ファイルが存在するフォルダをioc_dirオプションで指定してopenioc_scanを実行します。各termの評価結果をAND/ORで組み合わせた結果、原則的に真になる場合、そのIOCと真になったtermを色付きで表示します。この図では、プロセスIDが2204のsvchost.exeが、条件にマッチしたプロセスであることが分かります。ところで、Volatility FrameworkはRedlineと異なり、メモリイメージの解析結果をキャッシュしませんが、openioc_scanは各termの評価に必要な情報を都度キャッシュするため、同じtermを二度目以降に評価した場合は高速に処理することが可能です(※59)

openioc_scanがサポートしているtermの一覧を表-1に示します。ProcessItemとDriverItemについては、スキャン対象となるプロセスやドライバは、個別にIOCの定義内容に対して真か偽かを評価されます。例えば、先の例のIOCは1つのプロセス内に閉じて評価されることになります。また、カテゴリの異なるtermを組み合わせた定義を行うことも可能ですが、組み合わせによってはパフォーマンスが著しく低下する場合があるので(※60)、定義内容はできるだけ1つのカテゴリのtermのみをシンプルに定義していくほうが良いでしょう。

図-18 parameterの利用例

先程、「各termの評価結果をAND/ORで組み合わせた結果、原則的に真になる場合、そのIOCと真になったtermを色付きで表示します」と書きました。実は、termのAND/ORの最終結果が真でない場合でも、IOCを表示する方法があります。

OpenIOC 1.1ではparameterという概念を使い、termごとにメタデータを定義することができます。openioc_scanはそのparameterを用いて、スコアリングでの評価をサポートしています。例えば、先の例のIOCを評価した際、片方のtermのみ真であっても、parameterとして定義したスコアが閾値を超えている場合、そのスコアに基づきIOCにマッチしたことが表示されます。具体的には、parameterにセットされていたscoreが整数値で合計100を超える場合、図-18のように該当するIOCが表示されます。openioc_scanはそのほかにdetailやnoteというparameterをサポートしています(※61)

汎用的なIOCに関する検討

表-1 openioc_scanがサポートしているterm

一般的にIOCは、既知の脅威を検出する目的で利用されます。その最も大きな理由として、従来のIOCの大半が、マルウェアのMD5やC&CサーバのURLなど、未知の脅威を検出するために再利用しにくい定義内容であったことが挙げられます。そこでIIJでは特定のマルウェアやインシデントに依存しない、openioc_scanのための汎用的なIOCについて検討を行いました。

表-2に検討結果をまとめます。汎用的な定義である以上、誤検出を完全に避けることはできないため、誰しもが今回検討したIOCを使って未知の脅威を検出できるわけではありませんが、更なる詳細な解析を行っていくための優先順位づけ(トリアージ)という観点では、ある程度活用できるという感触を得ました。一方、Volatility Framework自体の機能の制約によって、検出漏れが発生しているケースも見受けられました。

表-2 汎用的なIOCに関する検討結果

まとめ

本節ではopenioc_scanの紹介と、それを使った汎用的なIOCに関する検討結果について述べました。検討によって、Volatility Frameworkの機能に由来する制約が判明しましたが、Redlineとは異なりオープンソースなので、各ユーザで自由にそれを修正及び拡張することは可能です。

メモリイメージに対してIOCをスキャンするという考え方以前に、IOC自体を活用しているアナリストはまだまだ少ないように思います。今後インシデントレスポンスで解析対象とする端末の数、メモリやディスクの容量は、増加の一途をたどることは容易に推測できますし、経験豊富なアナリストは既に既存の手法の限界を感じているかもしれません。効率的にインシデントレスポンスを行っていくために、openioc_scanを使って脅威の検出やトリアージを試みてはいかがでしょうか。

1.4.3 ID管理技術

2014年も、事件・事故などで漏えいしたユーザIDとパスワードのリストを用いたとみられる不正ログインが後を絶たない状況が続きました。そのためID・パスワードだけを用いた認証方式は危険であるという認識が拡がり、他の認証方式を併用するなど新しいID管理技術が注目されています。そこで本節では、ID管理(Identity Management)技術について取り上げます。ID管理技術は、IDの発行・利用・廃棄と言うライフサイクルに関する技術だけでなく、利用者認証、クレデンシャルの発行・利用、属性情報の管理・流通、各種リソースに対するアクセス制御、権限移譲、そしてこれらの情報を異なる主体間で連携させる技術など非常に多岐に渡る概念を指すことがあります。そのため、インターネット上で利用されるID管理・ID連携に関連する仕様も多様化しており、それぞれが様々な考え方に基づき策定されているため、利用環境に応じて適切なものを選択する必要があります。しかし、使用されている技術用語がまちまちであることや仕様がカバーする範囲も多様化していることから、残念ながら非常に分かりにくい分野になりつつあります。本節では、特定の仕様に関する解説をできるだけ避け、ID管理技術に関する一般的な考え方を解説することで、技術導入のための助けになることを目指します。

IDの考え方~実体と識別子

アイデンティティについて非常に多くの考え方・定義・思想があり、これが技術者・利用者を混乱させる原因になっています。そこで本稿ではIDを識別子(Identifier)として捉えるシンプルな考え方を導入します。

現実世界の実体はデジタル世界のエンティティと結び付けられます。現実世界の実体の例としては、何らかのサービスを利用しようとするユーザが挙げられますが、IoT(Internet of Things)に代表されるように能動的に他のノードと繋がろうとする機器もIDを持つことがあります。このとき、デジタル世界のエンティティを識別(identify)するために、ユニークな識別子(Identifier=ID)が割り当てられます。IDはあるレルム(Realm;領域)ごとに定められる識別子空間(Identifier Space)上の元と捉えることができます。IDのユニーク性は、当該レルムにおいて異なるエンティティであれば、異なるIDが割り振られることを意味します。

現実世界の実体は複数のレルムにおいて、それぞれ異なるIDを持つことが一般的です。また、現実世界の実体が同じレルムにおける複数のIDと結び付けられることもしばしばあります。しかしデジタル世界においては、IDが異なれば、それらは異なるエンティティと認識されます。例えば、現実世界の実体であるAさんは、メールアドレスとしてa@aaa.exampleとa@bbb.exampleのように2つの異なるレルムaaa.example、bbb.exampleにおいてそれぞれのIDを持つことがあります。また、Aさんはレルムaaa.exampleにおいて、a@aaa.exampleだけでなくa1@aaa.exampleのように同じドメインに異なるメールアドレスを持つケースがあります。このように現実世界においては同じ実体に、デジタル世界においては異なるレルムに複数のIDが割り振られることもあることが分かります。

トークン・クレデンシャルと認証(Authentication)

前述したようにデジタル世界においてIDを用いることで異なるエンティティを識別できることが分かります。しかしIDは公開情報であるため、誰でも自分がそのIDを持つエンティティだと言い張っては困ります。そこで、デジタル世界において今アクセスしているエンティティが本当にそのIDが割り振られたエンティティであるかどうかを認証(Authentication)する仕組みが必要となります。そのために当該IDに呼応したパスワードなどの秘密情報が必要となります。

本節ではNIST SP800-63(※73)の定義に沿ってクレデンシャル(※74)とトークンを区別して説明することにします。トークンは"Something you know"、"Something you have"、"Something you are"の3つで代表されるように当該IDが割り当てられたユーザが持つ秘密にすべき情報を指します。トークンとしては例えば、パスワードや公開鍵暗号方式で利用される秘密鍵、ICカードやドングルなどの物理的媒体、指紋や虹彩などバイオメトリクス認証で用いられる身体情報などがあります。一方でクレデンシャルはトークンとIDとの結び付けを指し示す公開情報です。場合により、クレデンシャルは信頼のおけるエンティティからお墨付きを得ており、第三者がその正当性について検証可能な情報となります。トークンの一種であるパスワードに対応するクレデンシャルは、認証子であるIDそのものと捉えることができます。SSL/TLSなどで利用される公開鍵暗号系の認証方式を考えると、X.509証明書(※75)がクレデンシャルであり、証明書に含まれる公開鍵に呼応する秘密鍵がトークンに該当します。また、SSL/TLSサーバ証明書にはFQDNが含まれており、これをIDと捉えることができます。BitcoinアドレスはIDと捉えることができますが、アドレスそのものが公開鍵であり、アドレスだけでトランザクションの署名検証が可能なことから、Bitcoinアドレスはクレデンシャルとも捉えることができます。

1つの{トークン・クレデンシャル}の組を用いた認証ではなく、複数の{トークン・クレデンシャル}を用いて、あるIDが割り振られたエンティティを認証する方式を多要素認証と呼びます。一般的には並列の多要素認証方式、つまりそれぞれの認証方式において独立したトークンを用いる方法が知られています。一方で直列の多要素認証方式という考え方もあります。例えば、公開鍵暗号方式における秘密鍵をトークンとして使用する場合、秘密鍵ファイルは暗号化しておくことが一般的ですから、復号するためにパスワードの入力が必要になります。このとき、トークンとしてパスワードと秘密鍵の2つを利用する直列の多要素認証方式と捉えることができます。ICカードとPINコードも同様です。また、トークンのうち"Something you have"に属するハードウェアトークンでは、物理的媒体に表記された定期的に表示が更新されるワンタイムパスワードをトークンとして提示し、多要素認証の1つとして利用されることが一般的です。ネットワーク型としてはLamportによるハッシュチェーンを用いたワンタイムパスワード方式(※76)が知られておりS/Keyなどとして仕様(※77)(※78)が策定されています。ワンタイムパスワード方式は、従来のID・パスワード方式の置き換えや併用により、近年のリスト型攻撃への対策案(※79)の1つとして期待されています。

認証と認可(Authorization)の違い

デジタル世界においてユーザがログインする、もしくはサーバがあるIDを持つエンティティを認証することは最終的な目的ではありません。サーバはユーザを識別した後に、しかるべきサービスを提供したり、各種リソースにアクセスできるようにするために認証が行われます。エンティティの確からしさを確認した上で、当該IDを持つエンティティに対して権限を与えることを認可(Authorization)と呼び、認証(Authentication)とは分離して考えます。認可とは、あるIDに対して適切なアクセス権を付与することにほかなりません。その際にはポリシー(Policy)があることが前提となり、ポリシーに基づきあるIDに対して権限を付与するエンティティPDP(Policy Decision Point)とその決定された結果を実際に適用するエンティティPEP(Policy Enforcement Point)の2つに役割を分ける考え方があります(※80)。あるIDに権限を付与するアクセス制御方法にはRBAC(Role-Based Access Control)(※81)やABAC(Attribute-Based Access Control)(※82)などがあります。これらの方式には、IDに対して直接権限を付与するのではなく、IDに紐付けられた属性情報から判断して権限を付与するという考え方が導入されています。これら2方式の大きな違いは、RBACがロールと呼ばれる属性値が固定化されている属性情報を扱うのに対し、ABACではアトリビュートと呼ばれる属性値が定められた範囲の元を取り、その値がどの範囲に属しているかによって権限を変更するという設定方法が採用されています。例えば、役職や性別による判断はRBAC、年齢や期間・時刻による判断はABACの考え方に基づいてアクセス権限が与えられます。認可のために使われる属性情報は、ID付与や認証を行うエンティティが管理する場合もありますが、属性情報を管理するエンティティ(Attribute Authority)がクレデンシャルを発行してIDと属性情報を紐付ける方法もあります。クレデンシャルにして属性情報を流通させるメリットは、アクセス権限を得るためにユーザが開示すべき属性情報のうち、本来ならば不必要な情報までサービス提供者に流れることを防ぎ、最低限の属性情報のみを提示してサービス提供を受けることができるようになる点です(※83)。図-19は、トークンを用いた認証から各種クレデンシャルの流通、アクセス権限付与までの一連の流れを示した概念図を表しています。

ID連携技術

一度の認証で複数のレルムにおけるサービスが利用できるシングルサインオンを実現するためにID連携と呼ばれるフレームワークがいくつか存在しています。今回はSAML(Security Assertion Markup Language)(※84)における考え方を中心に説明します。SAMLにおける役割は(1)ID付与や認証に関する業務を行うIdP(Identity Provider)、(2)IdPが発行するクレデンシャルを信用して受け入れるRP(Relying Party)/SP(Service Provider)、(3)利用者であるEnd Userの3つに分けることができます。End UserはSPのサービスを利用する際にクレデンシャルを提示することでサービスを享受します。このときクレデンシャルを発行するのがIdPであり、SPで定められたポリシーに基づいてアサーション(Assertion)と呼ばれるクレデンシャルが要求されIdPにより発行されます。SAMLではアサーションのデータ形式だけでなくブラウザがEnd Userとして振る舞う場合の動作についてプロトコルが定められています。クレデンシャル(アサーション)の種類としては認証結果に関する情報だけでなく、属性情報を保証する情報や、更に認可決定に関する情報についても流通させることができます。このとき図-19のように、認証に関わるクレデンシャルを発行する機関を狭義のIdPとし、属性情報に関するクレデンシャルを発行するAttribute Authority、認可決定に関するクレデンシャルを発行するPDPと役割を細分化して考えることができます。また、SPがPEPの役割にあたりますが、実装によってはPDPでのアサーション発行を省略しPDPとPEPの両方の役割をSPが担当することも考えられます。

OpenID(※85)もSAMLと似たような考え方に基づくフレームワークであり、前述した狭義IdPやAttribute Authorityの役割としてOpenID Provider(OP)と呼ばれるエンティティが発行したクレデンシャル(Claimと呼ばれます)をRPが検証する仕組みで属性情報の流通を可能にしています。事前にOPとRPが連携しない状況でも運用可能であり、RP・OPがそれぞれ適したOP・RPを発見するディスカバリサービスに関する拡張仕様も用意されています。更に、権限委譲に関する仕様も策定されており、OAuth(※86)はリソースにアクセスするためのトークンを保持している利用者が、秘密情報であるトークンを開示することなく代理人に権限のみを一時的に付与する仕組みを提供しています。技術用語が違うため混乱しますがResource Ownerと呼ばれる利用者がClientと呼ばれる代理人に、秘密情報を渡すことなくAccess tokenと呼ばれる認可情報を含むクレデンシャルをAuthorization Serverと呼ばれるPDPが発行することで代理人がリソースにアクセスすることを可能にしています。

このように、今後も新しいモデルに基づいた様々な仕様が策定されると考えられますが、今回紹介したID・トークン・クレデンシャルと認証・認可・アクセス制御という一般的な考え方を知っておくことで新仕様の理解の一助となれば幸いです。

  1. (※43)「www.example.jp」や「mail.example.com」などドット(.)で区切られた一番右側のラベル(jpやcom)を指す。
  2. (※44)Democracy in Hong Kong Under Attack | Volexity Blog(http://www.volexity.com/blog/?p=33blank)。
  3. (※45)IIJではマルウェアに感染した事例を観測していない。
  4. (※46)株式会社日本レジストリサービス(JPRS)、「補足資料:登録情報の不正書き換えによるドメイン名ハイジャックとその対策について」(http://jprs.jp/tech/security/2014-11-05-unauthorized-update-of-registration-information.pdfPDF)。
  5. (※47)有志によって運営されているIOCを共有するサイト。2015年1月8日時点で327のIOCが共有されている(https://www.iocbucket.com/searchblank)。
  6. (※48)Mandiant社が推進する規格。IOCはXML形式で記述される(http://openioc.org/blank)。
  7. (※49)記事ではOpenIOCのフリーツールを使った活用例を説明している「。OpenIOCを使った脅威存在痕跡の定義と検出」(https://sect.iij.ad.jp/d/2012/02/278431.htmlblank)。
  8. (※50)一昨年のSANS DFIR Summit 2013にて、揮発性のIOCを定義して検出する手法に関する発表を行った(https://digital-forensics.sans.org/summit-archives/DFIR_Summit/Volatile-IOCs-for-Fast-Incident-Response-Haruyama.pdfPDF)。
  9. (※51)オープンソースのメモリフォレンジックツールであり、有志によって様々なプラグインが提供されている(https://github.com/volatilityfoundation/volatilityblank)。
  10. (※52)以下で最新版を配布している(http://takahiroharuyama.github.io/blog/2014/08/15/fast-malware-triage-using-openioc-scan-volatility-plugin/blank)。
  11. (※53)実際には通信情報以外の項目についてはXPや2003のメモリイメージもスキャンできるが、十分な検証を行っていないため、サポート対象外とした。
  12. (※54)XMLをパースするためのパッケージ(https://pypi.python.org/pypi/lxml/3.2.1blank)。
  13. (※55)OpenIOC 1.1の項目をパースするためのパッケージ(https://github.com/mandiant/ioc_writerblank)。
  14. (※56)コンソールの出力文字の色を変更するためのパッケージ(https://pypi.python.org/pypi/coloramablank)。
  15. (※57)Sean Gillespie氏によるオープンソースツール(https://github.com/yahoo/PyIOCeblank)。
  16. (※58)スキャン対象が文字列か数値などによって、is/contains/matches/starts-with/ends-with/greater-than/less-thanという指定が可能。matchesでは正規表現を指定する。
  17. (※59)文字列の抽出など、時間のかかるtermに関係する情報のみをキャッシュする。termの種類が同じであれば、その値を変更したとしても高速に処理される。
  18. (※60)例えば、ProcessItemやDriverItemは繰り返しの処理が多いため、それらのカテゴリに属するtermを組み合わせた定義を行うと実行時間が長くなる傾向にある。
  19. (※61)detailはマッチした文字列が一部の場合、その全体の文字列を表示するparameterで、値にonを指定する。noteはtermごとのコメントを残したいときに使う。以下のページで具体的な設定方法を解説している(http://takahiroharuyama.github.io/blog/2014/10/24/openioc-parameters-used-by-openioc-scan/blank)。
  20. (※62)Direct Kernel Object Manipulationの略。ここではカーネルが保持するプロセスのリンクリストを改ざんすることで隠されたプロセスのことを指す。
  21. (※63)HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility\AppCompatCacheもしくはHKLM\SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatCache\AppCompatCacheに存在するレジストリ値。
  22. (※64)IRPとはI/O Request Packetsの略であり、ドライバごとに設定されるバッファの読み書きなどの操作のための関数テーブルをIRP function tableという。
  23. (※65)System Service Descriptor Tableの略。SSDTエントリとはシステムコール名のこと。
  24. (※66)MFTとはMaster File Tableの略であり、MFTエントリとはNTFSファイルシステムで管理されるファイルやフォルダごとに作成されるメタデータのこと。
  25. (※67)Volatility Frameworkはinlineフックについては最初の3命令までしかチェックしないため、4命令以降にフックを埋め込まれた場合は検出できない。
  26. (※68)Volatility Frameworkの仮想アドレス変換機構の制限による。
  27. (※69)シェルコードなどの、実行コンテキストに依存せず動作可能なコードのこと。
  28. (※70)Process Environment Blockの略。利用するAPIへのアクセスに必要な情報。
  29. (※71)Get Program Counterの略。現在の実行位置を取得するためのコードのこと。
  30. (※72)OS/2アプリケーションとの互換性のために使われるデータ領域のこと。
  31. (※73)NIST Special Publication 800-63-2、Electronic Authentication Guideline(http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdfPDF)。参考情報としてIPAによる日本語訳がある(https://www.ipa.go.jp/files/000025342.pdfPDF)。
  32. (※74)認証に用いられるあらゆる情報の総称としてクレデンシャルという用語が利用されることもあるが、本節では公開情報と秘密情報の観点で明確に分類すべきという立場で利用する。
  33. (※75)ITU-T Recommendation X.509 | ISO/IEC 9594-8, Information Technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks
  34. (※76)Lamport、"Password Authentication with Insecure Communication"。Communications of the ACM 24.11, November 1981, pp.770-772.
  35. (※77)N. Haller、"The S/KEY One-Time Password System"(http://tools.ietf.org/html/rfc1760blank)。
  36. (※78)N. Haller et al.、"A One-Time Password System"(http://tools.ietf.org/html/rfc2289blank)。
  37. (※79)総務省、「リスト型攻撃対策集について」(http://www.soumu.go.jp/main_content/000265404.pdfPDF)。
  38. (※80)OASIS、"eXtensible Access Control Markup Language3( XACML) Version 2.0"(http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdfPDF)。
  39. (※81)David Ferraiolo、Richard Kuhn、"Role-Based Access Controls"、15th National Computer Security Conference(http://csrc.nist.gov/rbacblank)。
  40. (※82)NIST、Attribute Based Access Control (ABAC) Overview(http://csrc.nist.gov/projects/abac/blank)。
  41. (※83)更に、IDも仮名(Pseudonym)を用いてアクセス権限を得る考え方もあるが、本節では触れない。
  42. (※84)OASIS、Security Assertion Markup Language(SAML)(http://xml.coverpages.org/saml.htmlblank)。
  43. (※85)OpenID Foundation、OpenID specifications(http://openid.net/developers/specs/blank)。かつて策定されていたOpenID Authenticationなどの仕様群は廃止され、OAuth 2.0をベースにしたOpenID connect 1.0に統合されている。
  44. (※86)D. Hardt、"The OAuth 2.0 Authorization Framework"(http://tools.ietf.org/html/rfc6749blank)。OAuth 2.0周辺仕様は、以下のページ(http://tools.ietf.org/wg/oauth/blank)で策定されている。
1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る