いまだから知っておきたい！ XP EmbeddedからStandard 7への移行ポイント【後編】：特集 どうなる？ どうする？ 組み込み機器向けWindows XP（1/2 ページ）

2014年4月9日（日本時間）で「Windows XP」のサポートが終了。組み込み機器向けに提供されている「Windows XP Embedded」についても2016年1月に期限を迎えてしまう……。そろそろOSの移行を前向きに検討するときなのではないだろうか。本特集では、Windows XP Embeddedから「Windows Embedded Standard 7」への乗り換えを前提に、その移行ポイントを解説する。

[山下喜宏，MONOist]

　【前編】では、「Windows XP Embedded」から「Windows Embedded Standard 7（以降、WES7）」への移行ポイントのうち、「OSのセキュリティ強化による影響」における「PC全体で共有するデータの保存先」に関する注意点を解説しました。今回お届けする【後編】では、残りのポイントを紹介していきます。

＞＞【前編】の内容はこちら

アクセス制限のための機能追加（IL、UAC、UIPI）

　整合性レベル（IL：Integrity Level）はプロセスやファイル、レジストリといったオブジェクトへのアクセス制限を実現する機能です。また、ユーザーアカウント制御（UAC：User Account Control）とユーザーインタフェース特権の分離（UIPI：User Interface Privilege Isolation）は、ILを使用することで、リソースへのアクセスを制御します。

図1　アクセス制限のための機能追加（IL、UAC、UIPI）

　以降でそれぞれの詳細を説明します。

整合性レベル（IL）によるオブジェクトへのアクセス制御

　ILとは、プロセスの権限を制限するためにWES7から追加された新しいメカニズムです。プロセス、ファイル、レジストリといったオブジェクトへのアクセス権限を3つのレベルに分類します（表1）。例えば、ファイルを誤って削除してしまったり、故意や悪意により削除されてしまったりといった、セキュリティ上のリスクを最小限に抑えるために提供された機能です。

ILのレベル	権限	アクセスできるフォルダーやレジストリの例
高IL	管理者権限　 システム用の領域への書き込み可	Program FilesやWindows　 HKEY_LOCAL_MACHINE
中IL	標準権限　 ユーザー用の領域に書き込み可	Users\＜ユーザー名＞　 HKEY_CURRENT_USER
低IL	信頼できない権限　 安全な領域への書き込みのみ可	Users\＜ユーザー名＞\AppData　 \LocalLow　 HKEY_CURRENT_USER\Software　 \AppDataLow
表1　整合性レベル（IL：Integrity Level）について

　IL自体は、単純にプロセスなどに対する権限付与を行うだけの機能です。このILの機能を使って、実際のアクセス制限を実現しているのが、以降で説明するUACとUIPIです。

ユーザーアカウント制御（UAC）

　UACとは、ユーザーが意図しないプログラムの実行を抑制するための仕組みです。例えば、標準権限（中IL）のユーザーが起動したプロセスのILは通常「中IL」ですが、プロセス内で実行される部分で管理者権限を必要とする箇所があると、権限不足により動作がブロックされます。これにより、意図しないプログラムの実行を抑制できます。万が一、実行時に管理者権限が必要な場合は、UACにより、ユーザーが画面上で承認することで、標準ユーザーから管理者ユーザーへと権限昇格できます。これにより、ブロックされていたプログラムが動作可能となります。

図2　ユーザーアカウント制御（UAC）の動作

　UACにより、WES7の耐セキュリティ性は飛躍的に向上しました。アプリケーションは、システム領域のリソースへのアクセスが制限された状態（中IL）で起動されるため、システムにとってはより安全な環境といえます。さらに、承認ユーザーインタフェースによる権限昇格により、シームレスな権限昇格を実現しており、ユーザビリティを損なわずにシステムの安全性の向上を実現しています。

ユーザーインタフェース特権の分離（UIPI）

　UIPIとは、上位権限のプロセスを下位権限のプロセスから保護する機能です。具体的には、下位のプロセスから上位のプロセス（より高レベルのIL）への通信は、“許可されない”仕組みとなっています。この仕組みにより、上位のプロセスに対して悪意のあるプログラムが注入され、管理者権限で実行されることを防ぎます。

図3　ユーザーインタフェース特権の分離（UIPI）

　アプリケーションがUIPIに対応するためには、以下に注意して設計する必要があります。

• 上位プロセスとは通信をしない
• 権限を昇格して、上位権限を得る
• アプリケーションマニフェストへの定義により、高ILとして通信する

そのままアプリケーションを使える可能性

　これまでは、非互換などにより、従来のアプリケーションが動作しない可能性について解説してきました。ここでは反対に、互換性問題のあるアプリケーションを修正せずに、そのままで動作させるための機能である「互換性フィックス」について説明します。

　互換性フィックスは、非互換問題のある関数呼び出しに対して、OS側でその関数を互換性のある関数へと実行時に置き換え、アプリケーションが期待する値を返すことで、互換性を確保する機能です。

　この機能を利用するためには、個々のアプリケーションのプロパティにある［互換性］タブで設定を行います。互換モードを利用して、アプリケーションがWES7で動作しているように見せかけることができます。

図4　互換性フィックス

　そのままでは動作しなかったアプリケーションが、互換性フィックスを適用することで、動作するようになるケースも実際に存在します。

　ただし、互換性フィックスの利用は“一時的な救済措置”として考えた方がいいでしょう。恒久措置としては、互換性の問題がある場合には、互換性フィックスの適用がない状態でもWES7で動作するようにアプリケーションを修正することをオススメします。理由は、せっかくセキュリティの高いWES7というOSを適用しているにも関わらず、アプリケーションはこれらの恩恵を受けず、セキュリティの脅威がある状態で使用している可能性があるためです。特に、管理者権限がないと動作しないような状態にある場合は、早急な措置が必要です。