ページの先頭です


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

Internet Infrastructure Review(IIR) Vol.32
2016年8月29日発行
RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、Volatility Frameworkプロファイルの生成、マルウェアに感染しないためのWindowsクライアント要塞化(後編)の2つのテーマについて紹介します。

1.4.1 Volatility Frameworkプロファイルの生成

Volatility Frameworkとは

図-14 Volatilityのデフォルトプロファイル

Volatility Framework(以下、Volatility)はコンピュータフォレンジックの際にメモリイメージを解析するために使用されるオープンソースソフトウェアです(※48)

Volatilityを実行する際にはプロファイルを指定する必要があります。プロファイルは、OSやサービスパック、アーキテクチャごとに用意されており、メモリイメージを取得したシステムと同じものを指定しなければ正しく解析することができません。図-14はVolatilityにデフォルトで同梱されているプロファイルの一覧になります。

この図を見れば分かるとおり、デフォルトではWindowsのプロファイルしか同梱されていません。LinuxやMac OS Xのメモリイメージを解析する場合は、VolatilityのGitHubページ(※49)からプロファイルをダウンロードする必要があります。しかし、すべてのOSバージョンに対応したプロファイルが提供されているわけではありません。また、Linuxでは、Kernelのバージョンアップも多く行われますので、同じOSバージョンでもLinux Kernelのバージョンが異なるという状況も考えられます。

このような場合、使用しているシステムに合わせたプロファイルを自身で生成する必要があります。本稿では自身でLinux Kernel用のVolatilityプロファイルを生成する際の手順を解説します。

プロファイル生成の準備

解析対象システムのバージョンの確認

図-15 OSバージョンの確認方法

Volatilityのプロファイルを生成するには、メモリイメージの解析対象となるシステムと同じバージョンのシステムにVolatilityをインストールする必要があります。主なLinuxディストリビューションでのOSバージョンとLinux Kernelのバージョンを確認する方法は図-15を参照してください。なお、今回は、CentOS Linux 7.2-1511、Linux Kernel 3.10.0- 327.22.2.el7.x86_64を例に解説します。

プロファイル生成マシンの準備

Volatilityプロファイルを生成するためのマシンを用意します(解析対象システムへの変更を最小限にするため、別途マシンを用意してください)。このとき、OSバージョンとLinux Kernelバージョンは上記で確認したものと同じバージョンのものを用意することが望ましいです。なお、プロファイルを生成するマシンはバーチャルマシンでも問題ありません。

Volatilityのダウンロード

Volatilityの実行とプロファイルの生成に必要なライブラリをインストールします(図-16)。一部、gitを使用していますが、Linuxディストリビューションによっては、これらのライブラリのパッケージが用意されている場合もあると思いますので、適宜、インストールを行ってください。
次に、Volatilityをダウンロードします(図-17)。Volatilityはシステムにインストールしなくても実行することができるため、今回はこのまま使用します。Volatilityをダウンロードしたディレクトリ内で「$ python ./vol.py --info」と実行して、エラーが発生しないことを確認してください。

図-16 関連ライブラリのインストール

図-17 Volatilityのダウンロードと実行方法

Linux Kernel開発環境インストール

図-18 Linux Kernel開発環境インストール

プロファイル生成の際にカーネルモジュールのコンパイルが必要になるため、Linux Kernelの開発環境をインストールします(図-18)。その他、makeやgccなどのコマンドが必要となりますので、必要に応じて各コマンドをインストールしてください。以上で準備は完了です。

プロファイル生成

「volatility/tools/linux」ディレクトリ内で、makeコマンドを実行します。問題がなければ、同じディレクトリに「module.dwarf」というファイルができているはずです。次に、「volatility/volatility/plugins/overlays/linux/」ディレクトリに、module.dwarfとSystem.mapファイルをまとめたZIPファイルを作成します(図-19)。

図-19 プロファイル生成

このZIPファイルがVolatilityのプロファイルとなります。プロファイルに命名規則はありませんが、最低限OSバージョンが分かるようなプロファイル名が望ましいでしょう。より細かく管理するのであれば、Linux Kernelバージョンもプロファイル名に含めてください。
生成したプロファイルがVolatilityに認識されているかどうかは、図-20のようなコマンドで確認することができます。

図-20 プロファイル確認

異なるバージョンのプロファイルを生成する場合

ここまで説明した手順で、現在動作しているLinux KernelのVolatilityプロファイルは生成できるようになりました。しかし、同じOSバージョンでも異なるバージョンのLinux KernelやカスタマイズされたLinux Kernelのプロファイルを生成する場合は、作業手順を少し変える必要があります。

Linux Kernelのバージョンが異なる場合

「Linux Kernel開発環境インストール」のステップの代わりに、図-21のように適当なディレクトリにプロファイルを生成したいLinux Kernelのパッケージを展開します。

図-21 異なるバージョンのLinux Kernelを展開

図-22 異なるバージョンのLinux Kernelプロファイル生成

この他の手順は基本的に同じですが「プロファイル生成」に関しては、図-22のようにmakeコマンドの引数として、KDIRとKVERを指定しなければなりません。

図-23 シンボリックリンクの張り直し

注意点として、CentOS 7の場合、/lib/modules/<kernel_ver>/buildのシンボリックリンクがリンク切れとなるため、makeを実行すると「/home/admin/ksrc/lib/modules/<kernel_ver>/buildは存在しない」旨のエラーが発生してしまいます。この場合、図-23のように、buildファイルのシンボリックリンクを張り直すことでエラーを回避することができます。

カスタマイズされたLinux Kernelの場合

特定の機器や用途向けにLinux Kernelがカスタマイズされている場合、Linuxディストリビューションが配布しているパッケージをそのまま利用することはできません。このような場合、以下のいずれかの対応を行い、Linux Kernelのソースコードを用意します。

  1. カスタマイズされたLinux Kernelのソースコードやパッチが手に入る場合、それを利用する。
  2. ソースコードやパッチが手に入らない場合、解析対象システムが利用しているLinux Kernelに可能な限り近いバージョンのLinux Kernelソースコードを用意する。また、解析対象システムのカーネルコンフィグを利用して、可能な限り似通ったコンフィグを行う(※50)

このように解析対象システムで動作しているLinux Kernelに近い状態のソースコードが必要になりますが、これ以外の作業はこれまで解説した手順と変わりません。

なお、Mac OS X用のプロファイルは本稿の冒頭で書いたように、VolatilityのGitHubページからダウンロードすることができますが、新バージョンのリリース直後など、タイミングによっては最新版用のプロファイルをダウンロードすることができない場合があります。生成手順はLinux Kernelとおおよそ同じ(※51)ですので、自分でOS X用プロファイルを生成することを検討してみてはいかがでしょうか。

1.4.2 マルウェアに感染しないためのWindowsクライアント要塞化(後編)

前号のIIRではパッチ適用や一般ユーザ権限のみを付与するなどの基本的な対策に加え、アプリケーションホワイトリスティングと呼ばれる要塞化設定について紹介しました。本稿では残りの対策について紹介します。まだ前号を読んでいない方は、IIR Vol.31「マルウェアに感染しないためのWindowsクライアント要塞化(前編)」(※52)も合わせてご覧ください。

EMET

EMET(Enhanced Mitigation Experience Toolkit)は脆弱性の悪用を緩和するためのツールで、マイクロソフトが配布しています(※53)。Windowsのセキュリティ機能を最大限有効化すると共に、既知の攻撃手法への緩和策が実装されています。EMETはドメイン配下のクライアントに一斉インストールし、ポリシーを強制することも可能です(※54)。本稿執筆時点での最新版は5.5であり、それを元にEMETを単一ホストで利用する場合の説明します。インストール後、スタートメニューからEMET GUIを起動すると、EMETの管理ツールが起動します。

図-24 EMETの設定画面

  1. Quick Profile NameをMaximum security settingsに変更します。この際、再起動が必要である旨のポップアップが出現するため、OKをクリックします(図-24)。
  2. Importをクリックし、C:\Program Files(x86)\EMET5.5\Deployment\Protection Profilesに存在するプロファイルを一通り適用します。
  3. 設定を有効にするためにホストを再起動します。

これで基本的な設定は終了です。以降は管理画面からAppsをクリックし、環境に応じて個別のアプリケーションを追加したり、テスト中や利用中に不具合が出たアプリケーションについて、干渉している機能を個別に外すなどの対処を行いながら、運用をしていきます。

UACの厳格化

UAC(ユーザアカウント制御)はVista以降導入された機能で、管理者権限アカウントであっても通常は特権を無効化しておきます。OSにとって重要な変更が実行中のプログラムによって行われようとした場合に、ユーザに対してその変更は自身が行ったものであるか確認を求めることで、悪意のある変更を検出する機能です。

UACには大きく分けて4段階の設定値が存在し、Vistaではデフォルトで最高値である「常に通知する」が設定されていました。しかし、XPを単体で利用していたユーザはそのほとんどが常時管理者権限を使用しており、Vistaに乗り換えた際、頻繁にUACのポップアップが出現したため、多くのユーザがこの機能を批判しました。そのため、Windows7以降のデフォルトはそれよりも一段低い「アプリがコンピュータに変更を加えようとする場合のみ通知する」に変更になっています。しかし、これにはいくつか欠陥があり、UACを回避してユーザの同意なしに管理者権限に自動昇格してしまう攻撃が実際の事案でも確認されています(※55)。このような脆弱性を避けるため、UACを常に通知する、に変更して運用した方がよいでしょう(※56)

  1. コントロールパネルから、ユーザーアカウント、ユーザアカウントとたどります。
  2. ユーザアカウント制御設定の変更をクリックすると、図-25が表示されます。
  3. Windows 7以降は上から2番目が設定されているので、スライドを一番上に引き上げ、OKを押します(図-26)。

図-25 ユーザーアカウントの設定画面

図-26 ユーザーアカウント制御設定の変更

これで自動昇格が起こらず、常にポップアップが出現し、管理者ユーザが異常に気づきやすくなります。

WSHの無効化

WSH(Windows Script Host)はホスト上でVBScriptやJScriptを実行するための機能です。前号のIIR Vol.31「1.4.1 各種のランサムウェアとその対策」でも記載したとおり、TeslaCryptやLockyではJScript(.js)がメールに添付された事例が確認されています。また、過去にはショートカットファイル(.lnk)内にVBScript(.vbs)を埋め込んだものをメールで送信する手口も確認されています。このような攻撃を防ぐために、レジストリエディターを使用して以下のキーに値を追加し、この機能を無効化します。

  • キー
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
  • 値の名前
    Enabled
  • 値のデータ(DWORD値)
    0

無効化すると、.jsや.vbsをダブルクリックしたり、cscript.exeを実行した場合、警告が出ることが確認できます(図-27)。

図-27 WSHが無効化されたことの確認

rundll32.exe、regsvr32.exeの通信の禁止

rundll32.exe、regsvr32.exeはVBScript(.vbs)やJScript(.js)ファイルをリモートのホストからhttpなどを経由して取得し、実行する機能があります。これは攻撃者に使われうる機能であるため、禁止すべきです。ただし、rundll32.exeやregsvr32.exeは通常のWindowsの処理中にも使われているため、実行そのものを禁止することはできません。そこで、セキュリティが強化されたWindowsファイアウォールの送信の規則など、パーソナルファイアウォールの機能を用いて、これらの実行ファイルが外部と通信するのをブロックします。64bit環境の場合、SysWOW64側にも実行ファイルが存在するため、同様にブロックします。

また、C:\Windows\WinSxS以下のフォルダ内にもこれらの実行ファイルが存在する可能性があるため、それも禁止する必要があります。

PowerShellの禁止

PowerShellはWindowsの管理やWindows APIを呼び出したりできるなど、非常に強力なWindowsのスクリプティング言語です。デフォルトではファイル化されたスクリプトが実行できないようになっていますが、この制限は簡単に回避できてしまいます。また、ショートカットや外部に存在するスクリプトをHTTP経由で直接実行することができるなど、実際の攻撃に利用されていることが確認されているため、一般ユーザが実行できないようにAppLockerやソフトウェアの制限のポリシーなどで、次のパス以下を全体的に制限すると良いでしょう。

また、C:\Windows\WinSxS以下のフォルダ内にもpowershell.exeやpowershell_ise.exeが存在する可能性があるため、それも禁止する必要があります。

HTAの禁止

HTA(.hta)はHTMLで記述されたアプリケーションであり、HTML、VBScriptやJScriptを用いてコードを記述することが可能です。例えば最近ではLockyを使う攻撃者が.htaファイルを添付したメールを送信し、それをユーザに開かせることで感染を試みた事例が存在します。それ以外にも、少なくとも2007年からマルウェアが悪意のあるHTAを利用した事例が存在します(※57)。これに対処するために、mshta.exeをAppLockerやソフトウェアの制限のポリシーなどで制限すると良いでしょう。C:\Windows\WinSxS以下のフォルダ内にも存在する可能性があるため、それも禁止する必要があります。グループポリシーエディターで.htaの関連付けを外す手法も限定的な解決策の1つですが、厳密に言えば、mshta.exeをショートカット経由で呼び出された場合に回避されてしまうため、完全な解決策ではありません。

Webブラウザのプラグインを自動実行させない(Click to Play)

Google ChromeやFirefoxにはClick to Playと呼ばれる、ユーザが明示的に許可した場合のみWebブラウザプラグインの実行を許可する設定を行うことができます(※58)。これにより、Flashなどが自動的に実行されなくなり、これらの脆弱性を悪用してマルウェアに感染させる攻撃(ドライブバイダウンロード)を緩和することができます。

Google Chrome

  1. Google Chromeのメニューから、設定をクリックします(図-28)。
  2. ページの一番下にある、詳細設定を開く、をクリックします。
  3. プライバシーのコンテンツの設定をクリックします。
  4. プラグインのプラグインコンテンツをいつ実行するかを選択する、をクリックします。
  5. 完了ボタンをクリックすれば、Click to Playが有効になります(図-29)

図-28 Chromeの設定

図-29 Chrome - コンテンツの設定

Firefox

  1. URLバーにabout:configと入力します。その際に、警告が出ますが、細心の注意を払って使用する、をクリックします(図-30)。
  2. plugins.click_to_playの値をtrueにすることで、Click to Playが有効になります(図-31)。

図-30 Firefoxの詳細設定画面

図-31 Firefox - Click to Playの設定

マッシュアップコンテンツを制限する

Firefoxのアドオンには、NoScript Security Suite(※59)やRequestPolicy Continued(※60)のような、スクリプトの実行を許可するサイトを限定したり、URLバーに入力したドメインとは異なるドメインへのアクセスを制限するプラグインが存在します。これらを利用することで、普段閲覧しているWebページが改ざんされていても外部サイトにはリダイレクトされないため、悪意のあるWebサイトに誘導されにくくなり、結果としてマルウェア感染を緩和することが可能です。

ストアアプリの禁止

Windows 8以降では、ストアアプリが利用できますが、ユーザが自由にアプリをインストールできてしまうため、ストア内にマルウェアなどが混入していた場合に誤ってインストールしてしまう可能性があります。また、デフォルトでもゲームなどが含まれており、ビジネス環境においては好ましくありません。そこで、ストアアプリの利用を一律禁止します。

  1. 管理者権限でローカルグループポリシーエディターを起動してください。これはgpedit.mscを実行することで起動することが可能です。
  2. メニュー左側のツリーからコンピューターの構成、管理用テンプレート、Windowsコンポーネント、ストア、とたどります(図-32)。
  3. 以下の項目を有効に切り替えます(図-32)。
    -ストアアプリケーションをオフにする
    -Windowsストアからすべてのアプリを無効にする(この項目はWindows 10以降のみ)
  4. ポリシーを強制したいホストを再起動するか、管理者権限でコマンドプロンプトを開き、gpupdate/forceコマンドを実行すると、ソフトウェアの制限のポリシーが有効になります。

図-32 ストアアプリの設定画面

無効にした後にストアにアクセスすると、アプリにアクセスできなくなっているのが分かります(図-33)。また、AppLockerでもアプリを制御することができます。

図-33 ストアアプリ - 拒否されたときに表示される画面

各対策と侵入経路の効果

各侵入経路ごとの各対策の有効性を以下の表-1にまとめました。

表-1 各対策とそれぞれの侵入経路の効果

攻撃成立の可能性

上記対策を行うことで多くのマルウェア感染を止められますが、以下のような条件下では攻撃を防ぐことはできません。

  • 任意のコード実行の脆弱性を突くExploitによる攻撃が成立
  • 権限昇格の脆弱性を用いてSYSTEM権限など、高い権限でマルウェア実行
    もしくは、マルウェアをメモリ上のみに展開し、実行

ただし、EMETを回避した上で未知の脆弱性(0-day)を成立させるなど、条件としては非常に厳しいものであり、ほとんどの攻撃は成立しないと考えています(※61)

副作用

AppLockerやソフトウェアの制限のポリシーを利用した場合、通常のGoogle Chromeは動かなくなります。これはChromeが一般ユーザのユーザディレクトリにインストールされるためです。この代替案として、スタンドアローンインストーラを利用することで、Program Files以下にインストールすることができます。ただし、この状態でもGoogle Chromeのアップデート用プログラムはユーザのtempディレクトリ上に実行ファイルを展開して実行しようとするため、正常にアップデートが行われなくなってしまいます。これを回避するために、このアップデータが持つ証明書を許可ルールとして登録しておくと良いでしょう(※62)

WSHを無効化した場合、ログオンスクリプトなどにVBScriptを用いているとこれらの実行ができなくなります。PCの管理にPowerShellを用いていた場合はPowerShellの実行が禁止されると影響が出ます。

メールで文書をやりとりする場合、ファイルを暗号化する際に自己展開形式にして送信する文化が日本には根強く残っていますが、アプリケーションホワイトリスティングを導入した場合、ユーザが保存できる領域に存在する実行ファイルを例外なく拒否することになるため、受信者は添付ファイルの中身をチェックすることができなくなります。しかし、例えば一昨年に標的型攻撃で頻繁に使われたEMDIVIも自己展開形式を使用していましたが、攻撃者が送信元の組織と同一のアーカイバや暗号化ツールを入手し、自己展開形式でファイルを作成してメールを送信した場合、無害な添付ファイルと攻撃の区別がつきません。添付ファイルの暗号化を行いたい場合はパスワード付きzipや、より強い暗号化強度が必要であればGPGを使用して暗号化した上で添付する、もしくは信頼できるオンラインストレージサービスを利用してhttpsで通信路を暗号化してファイル共有するか、PGP/MIMEやS/MIMEなどでメール全体を暗号化するなどして代替し、このような悪しき文化を早く根絶していくべきです。

これまで紹介してきた設定で運用していると、この他にもいくつかの不具合に直面することがあります。そのときは、不具合がルールや運用を工夫することで回避できるかを検討していく必要があります。また、今回はマルウェアに感染しないことに特化して記述しましたが、よりセキュアに運用するためには、例えばプロセス生成やファイルの生成、書き込みイベントなどの監査ポリシーを設定したり、サードパーティの監査ソフトウェアなどを用いて監視するなど、他の対策も検討すべきです。Windows 10では、最新の脅威に合わせ、Device Guard(※63)やCredential Guard(※64)など、セキュリティを守るためのより強力で新しい実装があります。これらも導入を検討していくと良いでしょう。また日々新しい脅威が発見されているため、情報収集を行い、それらの脅威に対応するための方法を考え、定期的にポリシーの見直しを行う必要があります。

  1. (※48)VolatilityのGitHubページ。"GitHub - volatilityfoundation/volatility:An advanced memory forensics framework"(https://github.com/volatilityfoundation/volatilityblank)。
  2. (※49)プロファイル配布ページ。"GitHub - volatilityfoundation/profiles:Volatility profiles for Linux and Mac OS X"(https://github.com/volatilityfoundation/profilesblank)。
  3. (※50)ただし、この場合、作成したプロファイルと解析対象システムの間で、Kernel内部のデータ構造に異なる部分があると、その部分は正常に解析できない場合があるため、それを認識した上で解析を行う必要がある。
  4. (※51)Mac OS X用プロファイル生成手順詳細(https://github.com/volatilityfoundation/volatility/wiki/Macblank)。
  5. (※52)「Internet Infrastructure Review(IIR) Vol.31」(http://www.iij.ad.jp/company/development/report/iir/pdf/iir_vol31.pdfPDF)。
  6. (※53)EMETに関する情報やダウンロード先は次のURLからたどることが可能。「Enhanced Mitigation Experience Toolkit」(https://technet.microsoft.com/ja-jp/security/jj653751blank)。
  7. (※54)EMETは3.0以降、Active Directory経由でのパッケージの自動インストールや、ポリシーの配信をサポートしている。次のURLでは画像や動画でこれらに関する説明を詳しく行っている。「Active Directoryを利用したEMETの制御」(http://n.pentest.ninja/?p=31157blank)。"ITSCFORUM Deploy and Manage EMET using a GPO"(https://www.youtube.com/watch?v=4MgODgeDr18&app=desktopblank)。
  8. (※55)IIR Vol.21「1.4.1 標的型攻撃で利用されるRAT「PlugX」」(http://www.iij.ad.jp/company/development/report/iir/021.htmlblank)では、PlugXにおけるUACの迂回による管理者権限への自動昇格について触れている。また、過去にはDridexなどがPlugXとは異なるsdbを使用したUAC回避を用いていた。次のURLでは、その手法について解説している「Dridexが用いる新たなUAC回避手法(2015-02-09)」(https://www.jpcert.or.jp/magazine/acreport-uac-bypass.htmlblank)。ある研究者はWindows7以降のデフォルト値で運用した場合のUAC回避手法を一覧にまとめ、それを検証ツールとして公開している。"UACMe"(https://github.com/hfiref0x/UACMEblank)。
  9. (※56)ドメイン環境では、グループポリシー管理エディターで行う。コンピュータの構成、ポリシー、Windowsの設定、セキュリティの設定、ローカルポリシー、セキュリティオプション、とたどり、ユーザーアカウント制御の項を組み合わせることで同様のことが可能。
  10. (※57)次のURLでは、悪意のあるHTAの事例について紹介している。"The Power of(Misplaced)Trust:HTAs and Security"(https://nakedsecurity.sophos.com/2009/10/16/power-misplaced-trust-htas-insecurity/blank)。
  11. (※58)Internet ExplorerにもClick to Playに類似する機能としてActiveXフィルターという機能が存在する。「Internet Explorer 11とInternet Explorer 10でActiveXコントロールを使う」(https://support.microsoft.com/ja-jp/help/17469/windows-internet-explorer-use-activex-controlsblank)。
  12. (※59)"NoScript Security Suite"(https://addons.mozilla.org/ja/firefox/addon/noscript/blank)。
  13. (※60)"RequestPolicy Continued"(https://addons.mozilla.org/ja/firefox/addon/requestpolicy-continued/blank)。
  14. (※61)本レポート期間中、Angler Exploit Kitが最新のEMETを完全に突破し、攻撃を成立させるとの報告があった。"Angler Exploit Kit Evading EMET"(http://www.fireeye.com/blog/threat-research/2016/06/angler_exploit_kite.htmlblank)。過去に研究者によっていくつかの脆弱性が報告されたことはあったが、実際の攻撃で確認されたのは筆者の知る限りではこの事例が初めてである。ただしこの攻撃が出回った時点でAngler Exploit Kitは未知の脆弱性を利用していなかったため、パッチ適用が適切に行われていれば被害は出なかった。EMETの次回のアップデートではこの手法に対する対策が行われる可能性はあるが、本稿執筆時点で、EMETでこの手法を防ぐことは難しいと考えられる。報告された手法を緩和するためには、FlashやSilverlightを無効化しておくか、Click to Play機能でFlashなどに関連するDLLが自動的にロードされないようにすることである。このように、1つの対策が突破されても、他の手法で防ぐ、いわゆる多層防御が必要である。また、攻撃情報を収集し、それを緩和するための手段を普段から検討しておくことも必要である。EMETはあくまでも脆弱性を緩和するためのツールである。EMETを導入することで、パッチ適用を回避するという誤った判断をしてはならない。
  15. (※62)ChromeはWindowsドメイン上のクライアントに一斉インストールし、グループポリシーで一元管理、ユーザにポリシーを強制することが可能なChrome for Workを配布している(https://www.google.com/intl/ja/chrome/business/browser/admin/blank)。この仕組みであれば、管理者が強制的に全クライアントに対して新バージョンを配信をさせることが可能である。またユーザに勝手な拡張機能やアドオンをインストールされることを防ぐこともできる。FirefoxやThunderbirdについても、Mission Control Desktop(MCD)やAutoConfigと呼ばれる仕組みを用いることで、ユーザに利用環境を自由に変更できないようにし、管理者の設定を強制させることのできる機能が存在する(https://www.mozilla.jp/business/faq/tech/setting-management/blank)。
  16. (※63)「Device Guardの概要」(https://technet.microsoft.com/ja-jp/library/dn986865(v=vs.85).aspxblank)。
  17. (※64)「Credential Guardによるドメインの派生資格情報の保護」(https://technet.microsoft.com/ja-jp/library/mt483740(v=vs.85).aspxblank)。
1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る