Security Watch: Subjects and Security Principals

[アーティクル]
08/25/2016

セキュリティウォッチサブジェクトとセキュリティプリンシパル

Jesper M. Johansson

セキュリティに関するすべての要素は、最も基本的なレベルで考えると、"サブジェクト" と "オブジェクト" に分類されます。"オブジェクト" は保護する対象であり、"サブジェクト" はオブジェクトを保護するために制限を課す対象です。この 2 つの構成要素は、認証 (身元を証明する処理)、承認 (なんらかの要素にアクセス権を付与する処理)、および監査 (どのユーザーがどの要素にアクセスしたかを追跡する処理) で使用されます。基本的に、これらは非常に単純な概念です (図 1 参照)。

図 1 ユーザーによるファイルの読み取り

サブジェクトは行為者であり、オブジェクトはサブジェクトによる行為の対象です。さらに、サブジェクトによる行為の対象であるオブジェクトが、別のサブジェクトになることもあります。

Windows では、セキュリティに関する非常に優れたセマンティクスがいくつかサポートされ、大幅に拡張されたサブジェクトとオブジェクトの定義が採用されています。サブジェクトにはユーザー以外の要素も該当する可能性があるので、その表現は基本的なユーザー ID よりもはるかに複雑になります。

Windows のセキュリティプリンシパルには、一般的なサブジェクト (ユーザーと考えられる要素) だけでなく、グループとコンピュータも含まれます。セキュリティプリンシパルとは、セキュリティ識別子 (SID) を割り当て、なんらかの要素に対するアクセス許可を付与できるあらゆる要素です。

今回のセキュリティウォッチでは、Windows においてサブジェクトがどのように表現および使用されるかについて概説します。

サブジェクト、オブジェクト、操作の組

ほとんどの場合、セキュリティの管理は、サブジェクト、オブジェクト、および操作の組を基準として考えることができます。サブジェクトは、なんらかの操作をオブジェクトに対して実行する行為者です。たとえば、ファイルにアクセスするユーザーはサブジェクトです (図 1 参照)。ユーザーがファイルを読み取るとき、オペレーティングシステムは、その特定のオブジェクト (ファイル) に対するサブジェクト (ユーザー) の操作 (読み取り) を許可するアクセス許可がオブジェクトに設定されているかどうかを確認する必要があります。適切なアクセス許可が設定されている場合、アクセス要求は成功します。適切なアクセス許可が設定されていない場合、アクセス要求は拒否されます。ここまでは非常に単純です。

大文字と小文字は区別される

Windows では、"Administrator" または "Administrators" という単語の最初の文字が大文字の "A" である場合、通常はそれぞれがユーザーまたはグループを表します。この単語がすべて小文字で "administrator" と綴られている場合は、管理者特権を持つユーザーアカウントまたは人物を表します。これは、"Guest" と "guest" など、他のエンティティにも当てはまります。

セキュリティプリンシパルの種類

Windows ベースのシステム、さらに Windows ベースのネットワークでは、単なるユーザー以外の要素がサブジェクト (これ以降は "セキュリティプリンシパル" と呼びます) に該当する可能性があります。ただし、それでもユーザーが最も基本的な概念であることに変わりはありません。

ユーザーユーザーは、コンピュータにログオンする個々のエンティティです。基本的に、すべてのセキュリティプリンシパルは、ユーザーと少なくともなんらかの形で関連しています。Windows には、2 種類のユーザーが存在します。具体的には、ローカルとドメインの 2 種類です。ローカルユーザーは、ローカルコンピュータのセキュリティアカウントマネージャ (SAM) 内で定義されます。すべての Windows ベースのコンピュータはローカル SAM を保持し、この SAM にコンピュータ上のすべてのユーザーが格納されます。

一般に、ドメインコントローラ (DC) はローカル SAM を保持せず、したがって DC にローカルユーザーは存在しないと考えられていますが、これは間違いです。DC もローカル SAM を保持しますが、DC の SAM に格納されたアカウントはディレクトリサービス復元モードでのみ使用できます。

ローカル SAM には、少なくとも 2 つのユーザーアカウントが必ず格納されます。これらは Administrator アカウントと Guest アカウントです。Guest アカウントは、既定で無効になっています。

Windows Server 2008 では、すべてのバージョン (Windows Small Business Server 2008 を除く) で Administrator アカウントが既定で有効になっています。Windows Server 2008 コンピュータに初めてログオンするときは、このアカウントを使用する必要があります。Windows Vista では、Administrator アカウントが既定で無効になっていて、非常に限られた状況でしかこのアカウントを使用できません。

いずれの場合も、コンピュータを管理するユーザーごとに、少なくとも 2 つのアカウントを作成する必要があります。ほとんどの場合、なんらかの規制に従う必要があると思われるので、これは必須の作業です。ユーザーごとに、そのユーザー専用の管理アカウントを 1 つと、管理以外の作業に使用するそのユーザー専用の非管理アカウントを 1 つ用意します。

ローカルユーザーでないユーザーはドメインユーザーであるこのようなユーザーは、ドメインの DC 上で定義されます。ローカルアカウントとドメインアカウントの主な違いは、アカウントのスコープです。ドメインアカウントは、そのドメイン内のすべてのコンピュータ上で使用できますが、ローカルアカウントはそのローカルアカウントが定義されているコンピュータ上でのみ有効です。また、ドメインアカウントには、ローカルアカウントと比べてはるかに多くのプロパティを関連付けることができます (図 2 と図 3 を比べてみてください)。

図 2 ローカルアカウントのプロパティウィンドウ

図 3 ドメインアカウントのプロパティウィンドウ

ドメインアカウントでは、より優れた一連のセマンティクスが提供され、電話番号、所属、電子メールアカウントなど、組織環境におけるさまざまな属性に対応できます。また、ドメインアカウントは、ネットワーク内のどのコンピュータ上でも使用でき、アクセス許可を割り当てることができるので、ネットワーク内ではドメインアカウントの方が格段に便利です。さらに、ドメイン内でアカウントを定義すると、アカウントを一元管理できるようになるので、管理が単純化されます。

コンピュータコンピュータは、ユーザーの一種にすぎません。特に Active Directory では、この概念がよく当てはまります。その証拠となるのが継承モデルです。図 4 は、コンピュータまでの継承構造を示しています。

図 4 ユーザーとコンピュータの関係を表す Active Directory 内の継承階層

図 4 は、いくつかの非常に興味深い事実を示しています。まず、この図からわかるように、Active Directory 内のすべてのクラスは、Top というルートクラスから派生しています。実は、Top 自体も Top のサブクラスの 1 つと見なされます。2 つ目に、User クラスは organizationalPerson クラスから派生しています。そして 3 つ目に (これが最も興味深い点です)、Computer クラスは User クラスから派生しています。つまり、オブジェクト指向では、コンピュータはユーザーの一種です。ただし、このようにコンピュータを擬人化することは、実は非常に理にかなっています。コンピュータはサブジェクトとしても扱う必要があり、人間とほぼ同じ属性を必要とするからです。

グループサブジェクトは、前述のとおり、オブジェクトへのアクセスを試行します。Windows は、オブジェクトのアクセス許可を確認することによって、この試行されたアクセスを検証します。かなり前のことですが、Windows の設計者は、オブジェクトを必要とする各ユーザーに対応したアクセス許可をオブジェクトごとに割り当てるのは非常に不便であることに気が付きました。設計者は、この問題を解決するために、ユーザーをグループのメンバとして扱うことができるようにしました。これにより、アクセス許可をユーザーだけでなくグループにも割り当てることができるようになりました。

グループはユーザーではない場合もありますが、ユーザーやコンピュータと同様に識別子を指定できるので、セキュリティプリンシパルの一種であることに変わりはありません。Windows では、ユーザーは複数のグループに属することができ、オブジェクトには複数のグループに割り当てられたアクセス許可を設定できます。また、多少の制限はありますが、グループは入れ子にすることもできます。

ドメインコントローラ以外のコンピュータは、組み込みのグループと管理者が定義したローカルグループという 2 種類のグループのみを保持します。ただし、Active Directory 内には 6 種類のセキュリティグループが存在します。これらは、組み込みのドメインローカルグループ、組み込みのグローバルグループ、組み込みのユニバーサルグループ、ユーザー定義のドメインローカルグループ、ユーザー定義のグローバルグループ、ユーザー定義のユニバーサルグループです。

ドメインローカルグループには、このグループが定義されているドメイン内のリソースに対するアクセス許可のみを割り当てることができます。ただし、ドメインローカルグループには、信頼済みドメインまたはフォレストに属するユーザー、ユニバーサルグループ、グローバルグループと、これらのグループ自体が属するドメインのドメインローカルグループを含めることができます。

グローバルグループには、このグループが定義されているドメインのユーザーとグローバルグループのみを含めることができます。ただし、グローバルグループには、このドメインが属するフォレストまたは信頼する側のフォレスト内に含まれたすべてのドメインのリソースに対するアクセス許可を割り当てることができます。

ユニバーサルグループには、すべてのドメインのユーザー、ユニバーサルグループ、およびグローバルグループを含めることができます。ユニバーサルグループには、信頼する側のドメインまたはフォレスト内のリソースに対するアクセス許可を割り当てることができます。つまり、ユニバーサルグループは、ドメインローカルグループとグローバルグループを掛け合わせたようなグループです。

ワークステーションでは、既定で提供されるグループは 2 種類のみ (Administrators と Guests) ですが、ドメインではこれよりも数が増加し、上記の 3 種類すべてのグループが提供されます。図 5 は、ドメイン内の既定のグループを示しています。どのグループもセキュリティグループに指定されているので、アクセス許可を割り当てることができます (セキュリティグループと配布グループを混同しないようにしてください。配布グループは、Microsoft Exchange Server がユーザーをグループ化して電子メールの一覧を作成するために使用するグループです。どちらのグループも Active Directory 内で定義されます)。すべての Windows ベースのコンピュータ上に存在するローカルグループは、Active Directory 内の DC 上で定義されます。

図 5 Active Directory の Users コンテナ内で定義される既定のグループ

DC 以外のコンピュータも、DC と同様に多数のグループを保持する場合があります。図 6 は、あるテストコンピュータ上で提供される 16 個の組み込みのグループを示しています。あるコンピュータ上で提供されるグループの実際の数は、そのコンピュータにインストールした役割によって異なります。

図 6 DC 以外のコンピュータ上で提供される組み込みのグループ (画像をクリックすると拡大表示されます)

オブジェクトにアクセス許可を割り当てるときは、ここまでに紹介していないグループも目にするでしょう。実際、基本的な DC では、少なくとも 63 個のグループと組み込みのセキュリティプリンシパルが提供されます (図 7 参照)。

図 7 に示された 63 個のグループの多くは、"特殊な ID" とも呼ばれる抽象的な概念で、セキュリティプリンシパルの動的なグループを表します。これらはログオングループと呼ばれることもあります。

ログオングループログオングループは、セキュリティプリンシパルの動的な側面を表すグループです。たとえば、ユーザーや他のセキュリティプリンシパルがどのようにログオンしたかを表します。たとえば、図 7 の INTERACTIVE グループには、コンピュータのコンソールにログオンしたユーザーとターミナルサービス経由でログオンしたユーザーがすべて含まれます。対照的に、NETWORK グループには、ネットワーク経由でログオンしたすべてのユーザーが含まれます。当然、ユーザーが同時にこれら両方のグループに属することはなく、各グループのメンバシップはログオン時に割り当てられます。これら 2 つのグループを使用すると、ある特定の方法でログオンしたすべてのユーザーにアクセス許可を割り当てることができますが、ユーザーをどちらのグループのメンバにするかを制御することはできません。

図 7 基本的な DC では少なくとも 63 個のグループと組み込みのセキュリティプリンシパルが提供される

このようなグループは他にもあります。中でも特筆すべきは、Everyone グループと Authenticated Users グループです。Everyone グループには、その名が示すとおり、そのコンピュータにアクセスするすべてのユーザーが含まれます。ただし、Windows XP 以降では、認証されていない完全な匿名ユーザーはこのグループに含まれません。つまり、サポートされる Windows ベースのオペレーティングシステムでは、悪名高い NULL ユーザーは Everyone に含まれません。ただし、Guests は含まれます。

Authenticated Users グループにも動的にメンバが設定されますが、このグループには実際に認証されたユーザーのみが含まれます。したがって、ゲストは Authenticated Users には含まれません。これが、Everyone グループと Authenticated Users グループの唯一の違いです。ただし、Windows で提供される唯一のゲストアカウントである Guest は無効になっているので、手動で Guest アカウントを有効にしない限り、Authenticated Users と Everyone の間に機能上の違いは生じません。Guest アカウントを有効にするのは、おそらく Guests にリソースへのアクセスを許可する必要がある場合です。このため、Everyone グループには手を加えないようにする必要があります。

それにもかかわらず、多くの管理者は、"自分が管理しているサーバーに対するアクセス許可が全世界のすべてのユーザーに与えられる" という事実への不安から何度も眠れぬときを過ごし、この状況を制限するために、非常に思い切った方法でアクセス許可を変更します。通常、このような変更を加えた場合、非常に悲惨な結果がもたらされます。Everyone のアクセス許可を Authenticated Users のアクセス許可に置き換える理由など、まったくありません。Guest アカウントを有効にして、コンピュータに対するアクセス許可をゲストに付与するか、これを行うことなく、Guest アカウントを無効のままにするとよいでしょう。ゲストにアクセス許可を付与する場合は、Everyone のアクセス許可が必要です。ゲストにアクセス許可を付与しない場合、Everyone グループと Authenticated Users グループとの間に違いはなくなります。

このような変更は、"多層防御" を目的とした変更であると主張する人もいます。"多層防御" を "他の方法では正当化できない変更" であると定義する場合、この主張は正しいと言えます。ただし、実際には、このような変更を加えてもセキュリティはほとんどまたはまったく強化されず、そのうえ非常に大きなリスクが課されます。このため、既定の設定は変更しないようにする必要があります。

上記の説明で納得がいかない場合は、マイクロソフトサポート技術情報の文書番号 885409 「セキュリティ構成ガイダンスのサポートについて」を参照してください。簡単に言うと、この記事には、大幅なアクセス許可の置き換えを行うと、サポート契約が無効になる可能性があることが記載されています。アクセス許可を大幅に変更することは、簡単に言ってしまえば独自のオペレーティングシステムを構築することを意味するので、マイクロソフトは正常な動作を保証できなくなります。

また、組み込みのグループである Users と Authenticated Users の違いにも注意してください。この違いはかなり明確で、Authenticated Users には、別のドメイン内のユーザー、Users 以外のローカルグループに属するユーザー、どのグループにも属していない (このようなことも可能です) ユーザーも含め、コンピュータに対して認証を行ったすべてのユーザーが含まれます。したがって Users グループは、Authenticated Users よりも大きく制限されたグループです。

私は、組織がこのような事実が存在するにもかかわらず、"システムのセキュリティ強化" を図り、Users のアクセス許可を Authenticated Users のアクセス許可に置き換えようとして、ネットワークを台無しにする状況を目にしてきました。以前、何も理解していない PCI/DSS 監査担当者と、終わりの見えない議論をしたことがあります。その担当者は、支払いカード業界では Users のすべてのアクセス許可を Authenticated Users のアクセス許可に置き換える必要があると主張しました。しかし、その主張は間違っています。

また私は、アクセス制御リスト (ACL) を全面的に置き換える作業が発生すれば、作業時間が増加し、顧客から支払われる作業代金が増加すると考えるコンサルタントから、世界中の組織を保護してきました。言うまでもないことですが、Users や Everyone のアクセス許可を全面的に Authenticated Users のアクセス許可に置き換えようとすると、セキュリティの面でも安定性の面でも大きな影響が及ぼされます。

サービス

Windows Vista と Windows Server 2008 では、新たに 1 つのセキュリティプリンシパルがサポートされます。それはサービスです。このエンティティの価値を理解するには、ホストベースのファイアウォールに関する進行中の議論について考えてみてください。このような製品の販売を熱心に支持するベンダをはじめとして、大勢の人が、ホストベースのファイアウォールで送信トラフィックをフィルタ処理すべきであると主張しています。侵害されたコンピュータからネットワークの他のリソースを保護できるというのがその理由です。ただし、もう少し客観的に考えてみると、あるコンピュータが侵害されているのであれば、マルウェアは既にそのコンピュータ上に存在しています。その結果、このマルウェアによってホストベースのファイアウォールを完全に回避したり無効にしたりできます。

このような状況がなぜ発生するかを理解するために、同じセキュリティプリンシパルとして実行されている 2 つのサービスについて考えてみましょう。サービス A にはファイアウォールを経由した通信が許可されていますが、サービス B にはこの通信が許可されていません。サービス B が侵害された場合、攻撃者はこのセキュリティプリンシパルとして実行されている別のプロセス (たとえば、サービス A) の制御を取得することによって制限を回避し、このプロセスから通信を行うことができます。

この問題を解決するには、プロセス、より具体的に言えばサービスにアクセス許可を適用する手段が必要でした。このため、サービスという種類のセキュリティプリンシパルが導入されました。その結果、現在はそれぞれのサービスに識別子が設定され、これを使用してアクセス許可を適用できます。コマンドラインから "sc showsid" コマンドを実行すると、任意のサービスの SID を確認できます。

サービスの SID を使用すると、特定のユーザーにのみアクセスを制限するのではなく、特定のプロセスにリソースへのアクセスを制限できます。この変更のおかげで、ホストベースのファイアウォールで提供される送信フィルタが、一部の状況で役立つようになりました。このような状況の詳細についてはこの記事では取り上げませんが、興味がある場合は、私が 2008 年 6 月号の TechNet Magazine に寄稿した Windows Vista ファイアウォールについての記事「Windows Vista のファイアウォールを管理する」を参照してください。

まとめ

Windows のセキュリティは、かなりの部分がセキュリティプリンシパルに基づいているので、管理者は、さまざまな種類のセキュリティプリンシパルの機能と使用方法について、少なくとも基本的な知識を持つ必要があります。この知識を身に付けなければ、セキュリティプリンシパルを効果的に使用するセキュリティ戦略を効率よく作成することはできません。この知識は、セキュリティプリンシパルを十分に理解していないにもかかわらず、不要かつ不適切な変更を要求してネットワークの正常性を危険にさらそうとする人々の的外れな議論に立ち向かわなくてはならないときに役立ちます。

この記事は、私の著書『Windows Server 2008 Security Resource Kit』(Microsoft Press) の資料に基づいています。

Jesper M. Johansson は、Fortune 200 に名を連ねる有名企業の主任セキュリティアーキテクトで、リスクに基づくセキュリティ構想とセキュリティ戦略の開発に取り組んでいます。また、TechNet Magazine の編集にも携わっています。彼の業務は、世界で最も規模が大きく、分散度の高いシステムのセキュリティを確保することです。彼は、管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズセキュリティの MVP でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。

目次

その他のリソース