Studio Sixnine.

I present "Next computing for the junk of us."

Site Index

• Greeting & Abstracts
• Fine Killing Library
• Project HeavyMoon
• Regular Expression
• Trumps by the roadside
• Weekly "Keyboard World"
• Reminiscences of Trains

Branch Navigation

• 目次
• 概論とインストール
• ツールとユーティリティ
• アプリケーション開発
• アーキテクチャ
• 情報源

NT セキュリティモデルに関するメモ

はじめに

• 「NT セキュリティモデルに関するメモ」などと銘打っていますが、本ドキュメントでカバーしている範囲は SID までです。ACL については、気が向いたら追加するかもしれませんし、しないかもしれません。
• 本ドキュメントで「NT」と呼称しているのは、NT カーネルを採用している Windows のことです。具体的には、NT / 2000 / XP 及びその後継 OS がそれに該当します。
• 興味深いことに、「NT のセキュリティモデル」は NT 以外のシステムでも利用可能なように設計されています。もっとも、私自身は NT 以外のシステムでこのセキュリティモデルを採用しているシステムを見たことはありません。

アカウント

概説

「アカウント(account)」とは、システムがユーザやグループなどを管理するための概念です。 アカウントには通常、ユーザを識別する名前(ユーザ名)とそのパスワード、そのユーザが持つ権限が定義されます。勿論、システムにアカウントが登録されていない人間はそのシステムを利用することが出来ません。

アカウントの管理

アカウントはシステムの内部では一意な識別子(ID)で管理されます。UNIX の場合は UID(ユーザ ID: ユーザの管理用)及び GID(グループ ID: グループの管理用)となりますが、NT では SID(後述)と呼ばれる複雑な識別子が用いられています。

アカウントの情報は「アカウントデータベース」と呼ばれるデータベースに格納され、認証を必要とする局面ではここに格納された情報が参照されます。 例えば、ユーザがシステムにログオンする場合は、システムはユーザが入力したユーザ名 / パスワードとアカウントデータベース中に格納されているユーザ名 / パスワードと比較します。そして、両者が合致した場合のみ、そのシステムへのログオンが許可されます。

ユーザとグループ

UNIX にも NT にも、「ユーザ」アカウントと「グループ」アカウントという、二つの概念が存在します。

ユーザアカウントはその名の通り、個々のユーザを管理するための概念であり、システムはユーザをユーザアカウントによって識別します。 グループアカウントは、ユーザアカウントを纏めて管理するための概念です。 グループには 0 個以上のユーザアカウントが登録され、そのグループに所属するユーザには、グループアカウントに対して定義された権限も合わせて付与されます。

グループを定義するのは、権限の定義を簡単にするためです。 個々のユーザに対して権限を逐一定義していくのは面倒ですが、ユーザを特定のグループに所属させ、そのグループに対して一括して権限を割り当てるようにすれば、管理作業が軽減出来ます。 グループアカウントには通常、 ID、名前及び権限のみが定義され、パスワードは定義されません。 グループアカウントを利用してシステムがユーザを識別することはないからです(もっとも、「許可されたユーザのみ、所属グループを目的とするグループへの変更を許可する」などという用途では、グループアカウントに対するパスワードにも意味はあります)。

グループのメンバ情報のことを、NT では「メンバシップ」と呼びます。 UNIX ではグループのメンバとなれるのはユーザだけですが、NT では制限はあるものの、グループをグループのメンバにする(グループの入れ子)が可能になっています(後述)。

UNIX でも NT でも、ユーザは同時に複数のグループに所属することが出来、その中の一つがそのユーザの「プライマリグループ(primary group)」として定義されます。例えば、ユーザ hoge が devel、user、staff の 3 つのグループに所属していた場合、この中の一つのグループ(例えば devel)がプライマリグループとして選ばれます。

UNIX では任意のグループをプライマリグループとして指定出来ますが、NT でプライマリグループとして指定出来るのは、「グローバルグループ」か「ユニバーサルグループ」(共に後述)のみとなっています。但し、NT でプライマリグループが意味を持つのは POSIX サブシステムか Macintosh サービスを利用する場合だけであり、Win32 環境でプライマリグループの情報が利用されることは通常ありません。

NT で新規にユーザを作成した場合、そのユーザのプライマリグループは「そのドメイン(後述)に所属するユーザの集合」を意味するグループ(Domain Users グループ)となります。しかし、ドメインに所属していないシステムでは、このグループは「Domain Users」という名称では表示されず、ただ単に「なし(日本語版 NT の場合)」という名称になります(*1)。 また、ドメインに所属していないシステムでは、ユーザのプライマリグループを変更することは出来ません。

NT のアカウント管理

概説

UNIX と NT では、アカウントの管理方法に幾つかの違いがあります。 後発だけあって、NT のほうがより柔軟なアカウント管理が可能になっています。

UNIX の UID と GID は相互に異なった空間を持つので、UID と GID に同じ値を利用することが可能です。 つまり、UID 0 のユーザと GID 0 のグループは同時に存在することが出来ます。 これとは逆に、NT の SID ではユーザもグループも同一の空間で管理されます。 つまり、SID 1000 のユーザと SID 1000 のグループが同時に存在することは出来ません。

また、UNIX では通常、アカウントはそのシステムだけで管理されます(*2)。アカウントデータベース(/etc/passwd 及び /etc/group)はシステム毎に存在し、システム毎にメンテナンスされます。UID が同じ 0 でも、システム A の root とシステム B の root は別人です(実際には同じ人間かもしれませんが、システム A とシステム B にしてみれば別人です)。

これに対し、NT では複数のシステムの間で同一のアカウントを共有し、アカウントを一元的に管理することが出来ます。これを可能にするのがドメインや Active Directory です。Active Directory は改良されたドメイン管理モデルなので、以後は両者を併せて「ドメイン」と表現します。

ドメインを利用した環境では、アカウントデータベースはドメインコントローラ(後述)に格納されており、各システムはドメインコントローラ中のアカウントデータベースを利用して認証を行います。 ドメインの管理下にあれば、システム A のユーザ hoge とシステム B のユーザ hoge は同一人物であり、システム A で hoge のパスワードや権限を変更すれば、その変更はシステム B ででも有効です(同一人物なので当然ですね)。ドメインの管理下にあるアカウントのことをドメインアカウントと言います。

ドメインの管理下にないシステムでは、UNIX 同様、アカウントはシステムごとに管理されます。 この場合、システム A のユーザ hoge とシステム B のユーザ hoge は別人です。 ドメインの管理下にないシステムでは、アカウントデータベースは %systemroot%\System32\config\SAM(*3)というファイルに格納されています。このようにドメインの管理下になく、システムごとに管理されているアカウントのことを ローカルアカウントと言います(*4) 。

既に述べたように、ドメインやシステムが異なれば、同じ名前のアカウントでも SID は異なります。 但し、後述するような以下の二つの例外があります。

• well-known SID
• ローカルグループ

ドメインとは

「ドメイン(domain)」とは NT の用語で、その定義は「アカウントを共有出来るシステムの集団」です(*5)。ドメインの内部で定義されたアカウントは、そのドメインに所属している全てのシステムから利用出来ます。

ドメインを利用するのは、個々のシステムに対する認証を不要にするためです。 ドメインを利用した環境では、ユーザ認証はシステム単位ではなく、ドメインが行います。これを「ドメインに対してログオンする」と言います。 一旦ドメインがそのユーザを認証したならば、ユーザはそのドメイン内の全システムに対して、そのユーザが持つ権限を行使出来ます。

ドメインは「ドメインコントローラ(domain controller; DC)」と呼ばれる特定のシステムが管理しており、他のシステムはドメインコントローラが管理する情報を参照するだけの存在となります。

ドメインに所属しないシステム

システムが特定のドメインに所属していない場合、そのシステムはワークグループ(workgroup)に所属することになります。 ドメインとは異なり、ワークグループには集中管理の仕組みは存在せず、個々のシステムは相互に独立しています。

ドメインを利用していない環境では、ユーザは各システム毎に認証作業が必要です。 システム A にログオンしたユーザ hoge が、システム B にある資源(共有フォルダやプリンタなど)を利用することを考えてみましょう。 ユーザ hoge がシステム B にある資源を利用するには、システム B にもユーザ hoge のアカウントが存在し、かつシステム B に対する認証に成功しなければなりません。 このことはつまり、システム A、B の両方に同じアカウントを作成しなければならないということを意味します。 システムが 2 つくらいなら何とかなるかもしれませんが、システムの数が増えてくると、アカウントのメンテナンスは大変な作業になります。

NT のグループ

NT では、参照出来る範囲(グループスコープ)の違いによって、 グループは以下の 3 種類に分けられます。

• ユニバーサルグループ
• グローバルグループ
• ローカルグループ

ローカルグループはそのシステム内だけで有効なグループであり、ローカルグループ以外のグループとユーザをそのメンバとすることが出来ます。

ローカルグループはそのシステムがドメインに所属しているかどうかで異なり、ドメインに所属している場合は「ドメインローカルグループ」、ドメインに所属していない場合はただの「ローカルグループ」です。 ドメインローカルグループの場合、その情報はドメインに格納され、有効範囲はシステムではなくドメインとなります。 逆に、(ただの)ローカルグループの情報はドメインではなく、システム内部のアカウントデータベースに格納されています。

グローバルグループは特定のドメインに加え、そのドメインと信頼関係を結んでいるドメインの間で有効となるグループです。 グローバルグループにはユーザアカウントしか格納できません(*6) 。

ユニバーサルグループは Active Directory のネイティブモードでしか利用できないので、ここでは省略します。

NT のビルトインアカウント

NT には最初から「Administrator」と「Guest」という二つのユーザアカウントが用意されています。 また、「Administrators」や「Power Users」などといったグループアカウントも最初から用意されています。

これらのアカウントは名前を変更することは出来るものの、削除することは出来ません。 このようなアカウントを「ビルトインアカウント」と言います。 ユーザとグループの違いを強調するために、「ビルトインユーザアカウント」「ビルトイングループアカウント」と区別して呼称することもあります。 また、ビルトイングループアカウントは全てローカルグループです。

ドメイン環境では、ビルトイングループアカウントは多少変わった振る舞いをします。 ドメインコントローラ間ではそのドメインのビルトイングループは共有されますが、 そのビルトイングループは、ドメインコントローラ以外のシステムからは参照することは出来ません(*7)。 ドメインコントローラ以外のシステムでは、ビルトイングループは(ただの)ローカルグループです。 これらのグループは個々のシステム内部でのみ有効なグループであり。その定義は各システム内部のアカウントデータベースに格納されています。

オブジェクトの所有者

システムの中には様々なオブジェクトがあり、それらのオブジェクトには所有者が定義されています。 オブジェクトにはファイル、プロセス、スレッドなど様々なものがありますが、話を簡単にするために、オブジェクトの代表としてファイルを例にします。

UNIX にはファイルに対して「所有者」と「所有グループ」という情報が付与されています。 ファイルを作成すると、そのファイルの所有者と所有グループが定義されます。 通常、所有者となるのはファイルを作成したユーザであり、所有グループとなるのはファイルを作成したユーザのプライマリグループです(*8)。

NT にも「所有者」と「所有グループ」という概念はありますが、「所有グループ」については「(そのオブジェクトの)所有グループ」とは言わず、「(そのオブジェクトの)プライマリグループ」と称します。 UNIX と同様、ファイルを作成したユーザがそのファイルの所有者、ファイルを作成したユーザのプライマリグループがそのファイルのプライマリグループとなります。

なお、NT ではグループもオブジェクトの所有者となることが出来ます。

ログオン

UNIX での「ログイン(login)」に相当する概念を NT では「ログオン(logon)」と称しますが、NT の「ログオン」という用語は、「システムに対するユーザ認証の総称」という意味で使われていると考えていいと思います(多分)。

一般的に「ログオン」という用語から連想されるのは、キーボードから Ctrl + Alt + Del を押してユーザ名とパスワードを入力する作業ですが、これは「対話的(interactive)なログオン」と呼ばれるログオンの一形態に過ぎません。 Telnet 経由でのアクセスもログオンの一種ですし、ネットワーク経由で共有フォルダにアクセスしたり、共有プリンタを利用する行為もログオンの一種です。

ドメインを利用している環境では、一旦そのドメインに対する認証が完了すれば、そのドメイン中の資源(のうち、そのユーザに権限が与えられているもの)は全て利用可能となります。 ドメインを利用していない環境では、あるシステムから別のシステムへとログオンする際はログオン先システムに対する認証が必要となります。 但し、ユーザ名 / パスワードが共に同じであれば、ユーザが明示的にユーザ名 / パスワードを入力する必要はありません。

なお、NT は明示的にユーザ名 / パスワードを指定せずに対象システムの資源を利用する「匿名ログオン」という機能をサポートしています。 匿名ログオンは通常、プリンタの共有などに利用されており、利用されるのは「Guest」と呼ばれる特別なユーザアカウントです。 例えば、「Guest」アカウントが有効になっているシステムのプリンタを共有プリンタとして利用する場合、「Guest」アカウントが共有プリンタにアクセス可能であれば、プリンタを利用する際にいちいちユーザ名 / パスワードを入力する必要はありません。

SID とは

概説

長々と書いてきましたが、ここからが本題です。

NT のセキュリティモデルでは、アカウントとドメインを一意に識別するため SID (セキュリティ識別子)と呼ばれる識別子が使用されます。SID はシステム中で一意であることが保証されており、別のシステム及びドメインの間でも一意となっています(つまり、システム A のユーザ hoge と、システム B のユーザ hoge は別人です)。

システム中で一度使用された SID が再利用されることはありません。 一度削除されたアカウントと同じ名前のアカウントを作成することは出来ますが、その場合は別の SID が割り当てられます。勿論、SID が異なれば同じ名前のユーザでも別人として扱われます。 また、UNIX ではあるアカウントに割り当てられた UID / GID を後から変更することが可能ですが、NT ではあるアカウントに割り当てられた SID を後から変更することは出来ません。

つまり、SID は時間と空間を通じて一意性が保証されているということになります。

SID の構造

SID は以下のような標準簡略記法(文字列表記法)で表現されます。

S-R-I-S1-S2-....-Sn-...

• 最初の「S」という文字は固定の値であり、この表記で表現される内容が SID であることを示しています。
• 次の「R」はバージョン番号であり、現在のところは常に 1 です。
• 次の「I」は「トップレベル権限(top-level authority)」と呼ばれる 48 ビットの値で、この SID の発行元を示しています。
• 続く「S1」以降の値は「副権限(subauthority: サブオーソリティ)」と呼ばれる値です。

トップレベル権限と副権限を組み合わせることによって、様々な SID が表現出来ます。 副権限は一つの SID 中で複数個指定することが出来ます(*9)。 つまり、SID とは「SID のリビジョン、トップレベル権限、0 個以上の副権限を組み合わせたもの」ということが出来ます。 「0 個以上」というのがポイントで、例えば「S-1-0」は立派な SID となります。

SID サフィックス

SID 中の最後の副権限を取り除いた残りの部分を 「SID サフィックス(SID suffix)」と称します。SID サフィックスそれ自身も有効な SID です。 なお、Cygwin では最後の副権限が「Cygwin での UID」として利用されます。

この説明だけではよく分からないと思われるので、簡単な例を挙げましょう。

• 「S-1-5-18」という SID は、SYSTEM(後述)というアカウントを示す SID です。 ここで「S-1-5」の部分(SID サフィックス)は「NT AUTHORITY」という SID、「18」の部分は NT AUTHORITY 中でアカウントを一意に識別するための値です。
• 「S-1-5-21-65679179-1906189016-1065227541-500」という値が、「HOGE」というシステムでの Administrator の SID だとします。 このとき、「S-1-5-21-65679179-1906189016-1065227541」はシステム「HOGE」を示す SID、「500」は Administrator を示す値です。つまり、この SID は「HOGE というシステムの Administrator アカウント」を意味しています。

ところで、ファイルの ACL (アクセス制御リスト)を操作する NT のコマンド cacls を実行すれば、例えば以下のような情報が表示されることが分かるでしょう。

C:\>cacls sample.txt
C:\sample.txt HOGE\Administrator:F
              Everyone:R
              BUILTIN\Power Users:R
              NT AUTHORITY\SYSTEM:R

それぞれ、「\」の前に置かれている「HOGE」「BUILTIN」「NT AUTHORITY」部分が SID プレフィックスであり、「Administrator」「Power Users」「SYSTEM」が最後の RID によって示されるアカウントとなります。 「Everyone」については「\」によって分割されていませんが、これは「Universal well-known SID(後述)」という特殊な SID だからです。

この例を SID で示すと、それぞれ以下のようになります。

ちなみに、ここで出てきた 3 つの SID プレフィックスは、それぞれ次のような意味を示しています。

トップレベル権限

トップレベル権限に指定出来るのは「識別子オーソリティ(identifier authority)」と呼ばれる値で、以下に示すようなものが定義されています。 識別子オーソリティは「SID の発行元を示す」などと定義されていますが、実質的には「このオーソリティの元に定義された SID の性質を定義する」程度に考えておけばいいでしょう。

ここに挙げた 5 つの識別子オーソリティのうち、SECURITY_NT_AUTHORITY(5)以外は NT 以外の OS ででも意味を持ちます。 それに対して、SECURITY_NT_AUTHORITY は NT でのみ意味をもつ SID を生成するために利用されます。SECURITY_NT_AUTHORITY と後述する SECURITY_DIALUP_RID などの RID とを組み合わせることによって、「NT でのみ利用可能な well-known SID」を作成することが出来ます。

先に「トップレベル権限は 48 ビットの値」だと書きましたが、実際には 6 バイトの配列として定義されています。 そのため、各識別子オーソリティも以下のような定義になっています(以下、winnt.h より抜粋)。

typedef struct _SID_IDENTIFIER_AUTHORITY {
    BYTE Value[6];
} SID_IDENTIFIER_AUTHORITY,*PSID_IDENTIFIER_AUTHORITY,*LPSID_IDENTIFIER_AUTHORITY;

typedef struct _SID {
    BYTE  Revision;
    BYTE  SubAuthorityCount;
    SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
    DWORD SubAuthority[ANYSIZE_ARRAY];
} SID, *PISID;

#define SECURITY_NULL_SID_AUTHORITY     {0,0,0,0,0,0}
#define SECURITY_WORLD_SID_AUTHORITY    {0,0,0,0,0,1}
#define SECURITY_LOCAL_SID_AUTHORITY    {0,0,0,0,0,2}
#define SECURITY_CREATOR_SID_AUTHORITY  {0,0,0,0,0,3}
#define SECURITY_NON_UNIQUE_AUTHORITY   {0,0,0,0,0,4}
#define SECURITY_NT_AUTHORITY           {0,0,0,0,0,5}

副権限と RID

副権限とは、あるトップレベル権限、或いはより上位の副権限に対して一意に関連付けられる値です。

副権限として指定する値は、RID(相対識別子)」と呼ばれる 32 ビットの値です。「相対」の名が示す通り、RID はあくまでも特定のトップレベル権限或いは副権限からの相対値に過ぎず、それ単体では意味を為しません。 また、副権限の性格上、RID の一意性はあくまでもその RID が関連付けられている識別子オーソリティ、或いは他の RID の中でのみ保証されています。

RID は適当に指定すればいいというものではなく、定義できる順序と組み合わせが決められています。 最初に指定する値は以下のようになっています。 なお、これらのように事前に定義された RID を「well-known RID」と呼びます。

上記の表を見ると、SECURITY_NULL_RID と SECURITY_WORLD_RID にはそれぞれ「0」という、全く同じ値が定義されています。 しかし、SECURITY_NULL_RID は SECURITY_NULL_SID_AUTHORITY(0)、SECURITY_WORLD_RID は SECURITY_WORLD_SID_AUTHORITY(1)の下でのみ意味を持つ値ですので、同じ値でも問題とはなりません。 これらを組み合わせた結果はそれぞれ「S-1-0-0」「S-1-1-0」となり、組み合わせた結果は異なる値となるからです。

well-known SID

識別子オーソリティと well-known RID とを組み合わせることによって、「well-known SID」を生成することが出来ます。 well-known SID とは、システムによって定義されたユーザ / グループを識別するための SID であり、 これらの SID によって示されるユーザ / グループは、全ての NT 中で最初から用意されています。

well-known SID には「Universal well-known SID」と「NT well-known SID」の二種類があります。

Universal well-known SID

Universal well-known SID とは、NT セキュリティモデルを利用する全てのセキュアなシステムで意味を持つ SID のことです。既に述べたように、これには NT 以外の OS も含まれます。

Universal well-known SID としては、以下のようなものが定義されています。これらの SID は先に挙げた識別子オーソリティの 0 から 3 と、0 から 3 に関連付けられた RID とを組み合わせることによって生成されています。

これ以外の well-known SID は「NT well-known SID」であり、NT でのみ意味を持ちます。

NT well-known SID

NT well-known SID は、NT でのみ意味を持つ SID です。 NT well-known SID は、識別子オーソリティの 5(SECURITY_NT_AUTHORITY) と関連付けられている、次のような RID から構成されます。

これらの値を「S-1-5」(NT AUTHORITY)と組み合わせることによって、以下のような NT well-known SID が定義出来ます。 これらの SID は全て NT のグローバルグループを示します。

これらのグループはシステムが管理しているので、メンバの追加や削除を行うことは出来ません。 表の内容を見れば分かるように、セキュリティ割当のダイアログに登場する大文字のアカウントが並んでいます。 これらのグループはユーザ個人を分類するためのものではなく、「ユーザがどのような方法を利用してシステムにアクセスしているか」を示すなどの用途に利用されます。

ところで、先の表で RID 5 と RID 21 が欠けているのは、グローバルグループを示すためではなく、別の特別な用途に利用されるからです。

RID 5(SECURITY_LOGON_IDS_RID)ははログオンセッションを示す SID を作成するために利用されます。 ログオンセッションを示す SID は「S-1-5-5-X-Y」という形式であり、X と Y は各ログオンセッションごとに異なります。 また、RID 21(SECURITY_NT_NON_UNIQUE) はそのシステム又はドメイン中でのみユニークとなる SID を作成するために利用されます。 この「S-1-5-21」から始まる SID は、システム又はドメイン中で定義されたユーザ / グループや、組み込みユーザ / 組み込みグループなどで利用されます。

組み込みユーザ(built-in user)

NT には「Administrator」と「Guest」という、事前に定義されたユーザが存在しますが、この 2 つのユーザの SID はドメイン又はシステムに関連付けられています。 すなわち、あるドメインの「Guest」アカウントの SID と、別のドメインの「Guest」アカウントの SID は異なったものとなる、ということです。

以下の表に示すのは、この 2 つの組み込みユーザを示す SID を作成するために利用される RID です。

組み込みグローバルグループ(built-in global group)

組み込みユーザと同様に、組み込みグループというものも存在します。 以下に示すのは、グローバルグループとして定義される組み込みグループの SID を作成するための RID です(*10)。

なお、DOMAIN_GROUP_RID_USERS(513)を除き、ドメインに所属していないシステムにはこれらのグローバルグループは存在しません。

組み込みローカルグループ(built-in local group)

ローカルグループとして定義されている組み込みグループには、以下のようなものがあります。 これらのビルトイングループに所属するユーザには、特定の作業を行うために適切な権限が与えられます。