サービスの保護メカニズムにおける最初の重要な変更は、Windows XP Service Pack 2に登場しました。今では想像がつきませんが、SP2より前は、オペレーティングシステム自体のすべてのサービスは、コンピューターの最も完全な管理権限を持つ組み込みのローカルシステムアカウントのコンテキストで起動されていました。 SP2では、ローカルサービスとネットワークサービスの2つのエントリが追加されました。 リストされている3つのエントリの基本的な違いは、表に記載されています。 1。
| アカウント | ローカルリソース | ネットワークリソース |
|---|---|---|
| ローカルシステム | すべてのコンピューターリソースへのフルアクセス | 実行中のコンピューターのアカウントのコンテキストでネットワークリソースに接続する |
| ローカルサービス | 標準ユーザー権利+追加の特権セット | ネットワークリソースへの匿名接続 |
| ネットワークサービス | 標準ユーザー権利+追加の特権セット | 実行されているコンピューターのアカウントのコンテキストでのネットワークリソースへの接続。 アクセストークンには、EveryoneおよびAuthenticated UsersのSIDも含まれています |
表1
したがって、Windows XP SP2以降、管理者はビルトインアカウントの1つ、ローカルアカウントまたはドメインアカウントのコンテキストでサービスの起動を構成できます。 ただし、Windows自体のほとんどのサービスは、依然としてローカルシステムのコンテキストで実行されます。 しかし、これを無視しても、同じアカウントのコンテキストで複数のサービスが起動されると、管理者権限がなくても、1つのサービスのハッキングが成功すると、攻撃者がアクセスできる他のリソースが開かれる可能性がありますハッキングされたサービスアカウント。
Windows Vistaでは、サービスの分離を強化するいくつかのメカニズムが導入されました。 2つに焦点を当てます。
最初のメカニズムは、一意のサービスSIDです。 このSIDは、SHA-1アルゴリズムを使用してサービス名をハッシュすることにより、各サービスに対して生成されます。 プレフィックスS-1-5-80-が結果に追加されます。 sc showsidコマンドを使用してサービスのSIDを表示するには、サービス名をパラメーターとして指定します（図1を参照）。
図 1
たとえば、W32Timeサービスを試すことができます。 NTFS上のフォルダーの場合、アクセス許可の設定では、NT SERVICE \ <サービス名>の形式でユーザー名を入力するだけでよく、この場合はNT SERVICE \ w32timeです（図2を参照）。
図 2
[名前の確認]、[OK]の順にクリックし、権限を割り当てることができるユーザー（図3を参照）を確認します。
図 3
w32timeはユーザーオブジェクトではないことを再度強調します。 これはSIDですが、もしそうであれば、グラフィカルインターフェイス、コマンドライン、およびプログラムの両方でACLで使用できます。 また、Windowsファイアウォールの設定でサービスSIDを使用して、特定のルールを特定のサービス、または特定のサービスSIDに適用できます。
Vistaで導入された2番目の変更は、新しいタイプのセキュリティ識別子、書き込み制限付きSIDです。 サービスが書き込み制限SIDとしてマークされている場合、そのSIDは特別リスト-制限SIDリストの特別アクセストークンに追加されます。 このようなサービスをファイルに書き込もうとすると、アクセス制御アルゴリズムがわずかに変わります。 つまり、このサービスのSIDまたはEveryoneグループに書き込み権限が明示的に与えられている場合にのみ、サービスはファイルに書き込むことができます。
たとえば、Service1のServiceAccount1アカウントはGroup1のメンバーです。 Group1およびそれのみがFolder1フォルダーに対する書き込み権限を持ちます。 サービスがFolder1フォルダ内の何かを変更しようとするとどうなりますか？ 通常の状況では、ServiceAccount1はGroup1のメンバーシップを介してフォルダーに書き込むことができます。 ただし、Service1サービスが書き込み制限SIDタイプでマークされている場合、そのアクセストークンは異なる方法で処理され、フォルダーに何も書き込むことができません。これは、Everyoneがこの権利を与えられていないのと同様に、書き込みアクセス許可が明示的に与えられていないためです。
sc qsidtypeコマンドを使用して、セキュリティーIDのタイプを表示できます（図4を参照）。
図 4
特に、図 4 Windowsファイアウォールサービスはこれらのタイプの1つにすぎないことがわかります。 当然、このタイプは、正常に破壊された場合にサービスの機能（何かを消去または上書きする機能）をさらに制限するために導入されました。 また、このメカニズムは主にシステム管理者向けではなく、サービス開発者向けであることを追加する必要があります。 彼らがそれを使用する場合のみ。
Windows 7およびWindows Server 2008 R2では、サービスの分離に関する作業が継続されました。 仮想アカウント（仮想アカウント）と管理されたサービスアカウント（管理されたサービスアカウント）があります。 しかし、問題は何ですか？ サービスを分離する必要があります-適切な量のローカル（またはドメイン）ユーザーアカウントを作成しましょう。 各重要なサービスには独自のアカウントがあります。 はい、これは解決策です。 ただし、リソースへのネットワークアクセスを必要としないローカルサービスの場合、長く複雑なパスワードを手動で設定する必要があります。 また、定期的に手動で更新します。 まあ、私たちはセキュリティのためです。 ドメインアカウントのコンテキストでネットワーク経由でリソースにアクセスする必要があるサービスに加えて、サービスごとにサービスプリンシパル名（SPN）を登録する必要があります。 これは不便です。 ただし、パスワードの有効期限が切れたためにサービスを開始できない場合、不便は大きな問題になります。 そして、管理者はパスワードを変更するのを忘れました。
したがって、ローカルサービスには仮想アカウントを使用できます。 仮想アカウントは、特定のサービスを開始するため、または特定のサービスのセキュリティコンテキストを作成するためにのみ使用されます。 [コンピューターの管理]のユーザーにはこのエントリはありません。 それにもかかわらず、これは一意のSIDとユーザープロファイルを持つアカウントです。 そして、あなたは彼に許可を割り当て、それによって、アクセス権を区別し、それらを明確に制御することができます。 ただし、ローカルシステム、ローカルサービス、およびネットワークサービスと同様に、オペレーティングシステムは仮想アカウントのパスワード管理タスクを処理します。 必要なサービスを分離し、パスワードに関する頭痛の種はありません。
仮想アカウントを作成するには、サービス設定でアカウントとして指定する必要があります：NT SERVICE \ <サービス名>（図5を参照）
図 5
サービスを開始すると、仮想コンソールがサービスコンソールに表示され（図6）、[ユーザー]フォルダーに新しいユーザープロファイルが表示されます。
図 6
形式は、サービスSIDに非常に似ています。 ただし、これはVistaのようにサービスの追加の一意のSIDであるだけでなく、個別のアカウントであるため、異なるレベルの分離であることを強調しています。 既定では、たとえば、Windows Server 2008 R2のIIS 7.5のアプリケーションプールに仮想アカウントが使用されます。 仮想アカウントはローカルでの使用を目的としていることに注意してください。 仮想アカウントのコンテキストで起動されたサービスがネットワーク経由でアクセスされた場合、この呼び出しはサービスが実行されているコンピューターのアカウントに代わって発生します。 ドメインアカウントの代わりにネットワーク経由で作業するためにSQL Serverなどのサービスが必要な場合は、管理されたサービスアカウントが役立ちます。 ただし、より多くの微妙さがそれらに関連付けられており、それらの検討はこの投稿の範囲外です。 MSAの詳細については、 こちらをご覧ください 。
リストしたサービスを分離するメカニズムは、これで終わりではありません。 また、ゼロセッション分離、整合性レベル、DEPメカニズムに言及することもできます。 私の考えではあまり知られていないが、同時に管理者にとって非常に実用的な意味を持つものに焦点を当てました。 そしてもちろん、Windowsの将来のバージョンでサービスのセキュリティを強化する作業は継続されます。