第7回 特権的な操作を制限するUAC（ユーザーアクセス制御）：Windows OS入門（2/2 ページ）
Windows OSでは、管理者権限のあるアカウントでログオンして作業しがちだが、これは危険な行為である。だがWindows OSの仕様上、さまざまな場所で管理者権限を求められるので、ついこういった運用をしがちだ。このような状況を改善するために導入されたUACの仕組みを解説する。
UACが有効な場合におけるAdministratorsアカウントでの挙動
以上の例は、Usersグループのアカウントにおける挙動だが、Administratorsグループに属するアカウントで同じことを実行するとどうなるだろう。Windows XPのようなUACがないWindows OSなら、Administratorsグループのアカウントでログオンすれば、時刻の変更に限らず、何でもほぼ自由に実行できたのだが、UACがあると少し挙動が変わる。
以下はコマンドプロンプトを起動して、先ほどと同じことをしたところである。UACが有効なWindows 8.1上で実行している。
管理者権限でtimeコマンドを実行する（1）
管理者権限のあるアカウントuser01でWindows 8.1にサインインし、同じように特権の表示と時刻の変更を行ってみた。なおUACはデフォルト設定のままである。
（1）現在サインイン中のアカウント。これはAdministratorsグループに属するアカウントである。
（2）特権を表示させてみる。
（3）特権名。全部で5つの特権が表示されている。先ほどと同じだ。
（4）時刻を変更してみる。
（5）やはり特権不足で変更できない。
UACが有効な状態でコマンドプロンプトを起動したが、やはり利用できる特権は先ほどの一般ユーザーアカウントの場合と同じく、5つしか表示されていない。当然timeコマンドの実行も失敗している。
コマンドプロンプトを管理者権限で起動してみる
次はコマンドプロンプトを管理者権限で起動してから実行してみよう。Windows 8／Windows Server 2012以降なら、［Windows］＋［X］のクイックアクセスメニューから［コマンド プロンプト(管理者)］を選択するか、タスクバー上にあるコマンドプロンプトのアイコンを［Ctrl］＋［Shift］キーを押しながらクリックするなどして起動する（関連記事参照）。
管理者権限でtimeコマンドを実行する（2）
まず管理者権限でコマンドプロンプトを起動する。UACが有効な場合は確認ダイアログが表示されるので、［はい］を押して許可する。そうやって起動したコマンドプロンプト上で実行してみる。
（1）このコマンドプロンプトは管理者権限で実行されている。
（2）特権を表示させてみる。
（3）特権名。先ほどの5つと違い、23の特権が表示されている。これが本来Administratorsグループに与えられていた特権。この中には時刻の変更を許可する「システム時刻の変更」特権もある。
（4）時刻を変更してみる。エラー無しに実行できた。
先ほどの例と違い、ここでは23の特権が列挙されている（システムの構成などによって総数は変わる。Active Directoryドメイン環境だといくつか増える）。これが本来Administratorsグループのアカウントに割り当てられていた特権である。Windows XPやWindows Server 2003などでは、ログオンするだけで最初からこれだけの特権が利用できていた。
だがUAC環境下ではログオン直後には5つの特権しか与えられず（これはUsersグループのアカウントの特権と同じ）、UACによる許可を得た場合のみ残りの特権も利用できるようになっている。具体的な特権名とその意味については、以下のサイトを参照していただきたい。
UACの仕組みとWindowsのログオン処理
以上のことから、UACの仕組みがだいたい分かるだろう。UACが有効な場合は、最初から全特権をプログラム（プロセス）に与えるのではなく、まず限定的ないくつかの特権しか与えないようになっている。これにより、たとえAdministratorsグループのユーザーであっても、Usersグループのアカウントと同様の権限しか持たないようになっている。
そしてUACによる確認ダイアログで許可した場合だけ、残りの特権がプログラムに与えられる。特権が与えられるのはプロセス単位であり（基本的には、子プロセスにも特権リストは引き継がれる）、別のプロセスが特権を必要とする場合は、その都度UACによる許可ダイアログが表示されるようになっている。
以上のことを踏まえて、Windows OSにおけるユーザーのログオン処理の内容をまとめておこう。
●ログオンステップ1．ユーザーログオン処理の開始
Windows OSに対するログオン（サインイン）やログオフ（サインオフ）は、Winlogon（winlogon.exe）プロセスが担当する。ユーザーが［Ctrl］＋［Alt］＋［Del］キー（セキュアアテンションシーケンスという）を押すと、ログオン画面のUIを表示するプロセス（LogonUI.exe）や、スマートカード、音声認証、指紋認証などの方法を使ってユーザー名とパスワードの入力を受け付ける。
●ログオンステップ2．アカウントの認証
入力されたユーザー名とパスワードはLSASS（ローカルセキュリティ認証サブシステムサーバー、lsass.exe）のプロセスに送られ、ローカルアカウントなら「SAM（Security Authentication Manager）」、ドメインアカウントならActive Directoryのドメインコントローラーなどから取得したユーザー情報と照合して、正しいログオン情報であるかどうかが検証される。
●ログオンステップ3．アクセストークンの作成
認証が成功して正しくログオンできた場合は、「セキュリティ参照モニタSRM（Security Reference Monitor）」がユーザーのセキュリティプロファイル（ポリシー）に基づいて、ログオンしたユーザーのための「アクセストークン」オブジェクトを作成する。
SRMはOSカーネル（ntoskrnl.exe）内にあるコンポーネントで、アクセストークンの作成や、オブジェクトのセキュリティアクセスチェック（必要なセキュリティトークンを持っているかどうかの検証）などを担当している。アクセストークンとは、簡単に言えばwhoami /privで表示された特権の一覧（と、どのユーザーやグループに許可するか、といったアクセス制御リストなど）である。一度作成されたアクセストークンは、基本的には親プロセスから子プロセスへ継承されるようになっている。この最初に作成されたトークンは完全な特権のリストを含んでいるので、以後「完全なトークン」と呼ぶことにする。
Windows OS内部で誰かが特権操作を行おうとした場合（特権が必要なオブジェクトへアクセスしようとした場合）、SRMはそのプロセスが持つアクセストークンを調べ、必要なトークンが含まれているかどうかを検証する。例えば、あるプログラムが時計情報を変更しようとした場合、そのプロセスがSeSystemTimePrivilege（システム時刻の変更）のアクセストークンを持っているかどうかがSRMによってチェックされる。もし存在しなければそのアクセス（API呼び出し）は失敗することになる。
●ログオンステップ4．UACに対する処理
UACが無効な場合は、上のステップ3．で作成された完全なトークンは次のステップ5．のユーザープロセスの作成段階へそのまま渡される。
UACが有効で、かつ管理者権限のあるグループ（AdministratorsやBackup Operators、Power Usersなど）に属していたり、特定のいくつかの特権を持っていた場合は、ステップ3．で作成された完全なトークンをそのまま使わず、いくらか制限（フィルタリング）された状態のトークン（「フィルターされたトークン」と呼ぶ）を作成して、次のステップ5．へ移行する。どのトークンがフィルターされて取り除かれるかは状況によって変わるが、通常は先の例で示した5つのみが残るようにフィルターされる（詳細については関連記事参照）。
以後作成されるプロセスは、全てこのフィルターされたアクセストークンを引き継ぐことになる。
●ログオンステップ5．ユーザー環境の準備
ステップ4．で用意されたアクセストークンを使って、Winlogonはユーザーの最初のプロセス（通常はUserinit.exe）を起動する。Userinitでは、ユーザー環境の初期化やログオンスクリプトの処理、グループポリシーの適用などを行う。
●ログオンステップ6．ユーザーシェルの起動
Userinitの最後の段階で、ユーザーシェル（通常はexplorer.exe）が起動する。
以上でユーザー環境におけるログオン処理は完了である。以後起動するプログラム（プロセス）は、全て上記のステップ4．で用意された「フィルターされたトークン」を引き継ぐため、特権が制限された状態で起動することになる。
ユーザーがUACによるダイアログを許可すると、新しく起動されるプロセスには、フィルターされたトークンではなく、本来の特権を全て持った、完全なトークンが渡される。これにより、そのプロセスでは特権的な操作を実行できる。
一度完全なトークンが渡されると、そこから起動される子プロセスも（基本的には）同じトークンを引き継ぐため、制限無く特権操作が行えることになる。
今回はUACの機能とその仕組みについて見てきた。Windows OSでは、管理者アカウントでログオンして使うという習慣が長く続いていたが、UACでは、管理者アカウントでログオンしたまま、その特権の一部を無効化することによってユーザーの意図しない操作を阻止している。あまりスマートな解決方法とは思えないが（本来ならば、Users権限での使用をもっと強制すべきだろうが）、よく実装したなと感心もする。UACによる効果を考えると、UACを無効にするような運用はすべきではないだろう。
Copyright© Digital Advantage Corp. All Rights Reserved.