Windows OS の特定のディレクトリにあるファイルを監視する Windows サービスを作成しました。ファイルが検出されると、サービスはファイル I/O を実行し、ファイルを読み取り、サブディレクトリを作成します。また、このサービスはデータベース接続を使用して別のサーバーに接続します。このサービスをデフォルトの「ローカル サービス」アカウントとして実行する予定です。書き込み/読み取り権限を許可する必要があるため (「ローカル サービス」アカウントはデフォルトで書き込み/読み取り権限を許可しないようです)、読み取り/書き込み先のフォルダーに対して「ローカル サービス」アカウントに明示的に「フル コントロール」権限を設定します。
上記は良いと思います。質問ですが、読み取りと書き込みを行うフォルダーに対して、フル コントロール アクセスを持つ「ネットワーク サービス」ロールを設定する必要がありますか? 私のサービスは別のサーバーへのデータベース接続を使用するので、「ネットワーク サービス」アカウントの設定が必要かどうか疑問に思っています。
「ネットワーク サービス」アカウントの機能について誤解している可能性があります。
答え1
のNT AUTHORITY\NetworkServiceアカウントアクセス制御のためにマシンの資格情報を必要とするドメイン内の他のコンピュータと通信する場合にのみ必要です。単純なインターネット/ネットワーク アクセスには必要ありません。Active Directory ドメイン内の特定の目的にのみ必要です。
また、NT AUTHORITY\LocalServiceアカウント問題は、システム上で最小限の権限しか持たないことです。権限を高くすると、システム上の多くのサービスが本来低い権限レベルで動作するように設計されているため、セキュリティが低下します。サービスがそれ以上の権限を必要とする場合は、必要な権限を持つ新しいアカウントを作成し、そのアカウントをログオンサービスのプロパティのタブ。(これはプログラムで実行することもできます。)
また、NT AUTORITY\LocalSystemアカウントはシステムに無制限にアクセスできますが、LocalServiceセキュリティ強化のためにこのアカウントを使用したいと考えているのだと思います。
答え2
他の回答は、Local Service の使用に関するあなたの意見を裏付けています。要約すると、Network Service の追加の Active Directory SSPI 機能が必要でない限り、Local Service はサービスで使用するのに推奨されるアカウントです。
ただし、特定のフォルダーへの読み取り/書き込みアクセスを制限するには、汎用の Local Service アカウントにアクセス権を付与するよりも良い方法があります。問題は、他の人が指摘しているように、これにより Local Service として実行されている他のすべてのサービスにも読み取り/書き込みアクセス権が付与され、すべてのサービスがこれを実行すると、徐々に Local Service がより多くの重要なリソースにアクセスできるようになることです。
解決策としては、代わりに特定のサービス SID を使用してフォルダーを ACL 制御することです。サービス SID が関連付けられているのは独自のサービス プロセスのみであるため、これによりリソースがさらにロックダウンされます。 を使用してサービス SID を表示できますsc showsid <service name>。サービス SID はサービス名から生成されるため、すべてのマシンで同じになります。
ChangeServiceConfig2サービスによるサービスSIDの使用を有効にするには、SERVICE_SID_INFO設定する構造。サービス SID で明示的に許可されたリソースへの書き込みアクセスのみを許可する、さらに制限された SID を取得するようにSERVICE_SID_TYPE_UNRESTRICTED設定することもできます。SERVICE_SID_TYPE_RESTRICTED
このリンクには、サービス SID と制限付きサービス SID の概要説明が記載されています。 https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/hh125927(v=ws.10)
答え3
前回の回答では質問に直接答えられなかったようですので、追加しようと思いました。
- 私の計画は、サービスをデフォルトの「ローカル サービス」アカウントとして実行することです。読み取り/書き込みを行うフォルダーの「ローカル サービス」アカウントに「フル コントロール」権限を明示的に設定します。上記は良い計画だと思います。
個人的には、このプランに大きな問題はないと思います。BUILTIN の場合、選択肢は次のようになります。
- LOCALSYSTEMとして実行されているため、このサービスが侵害された場合、攻撃者はすべて、そしてすぐに。
- LOCALSERVICE として実行されているため、このサービス、またはこのアカウントで実行されている他の多くのサービスのいずれかが侵害された場合、攻撃者は 1 つの追加ディレクトリにアクセスできるようになります。*
おそらく、2 番目のオプションを使用できるようにするには、いくつかの ACL を追加することが望ましいでしょう。はい、権限は低いがセキュリティの機密性が高いサービスの場合、最も安全なオプションは、カスタマイズされた権限の低いサービス アカウントで実行することです。ただし、展開するすべてのサービスに対して新しいアカウントを作成したり、パスワードを管理したりしない限り、機密性のない小さなタスクに LocalService を使用することはそれほど悪いことではありません。そのディレクトリやデータベースに何が含まれているか、侵害された場合の影響など、これらの考慮事項に基づいて責任ある決定を下す必要があります。
ただし、最小権限の原則に従って、本当に十分でないFull Control場合にのみ設定する必要があります。Modify
2. 私の質問は、読み取りと書き込みを行うフォルダーに対して、フル コントロール アクセスを持つ「ネットワーク サービス」ロールを設定する必要があるかどうかです。私のサービスは別のサーバーへのデータベース接続を使用するので、「ネットワーク サービス」アカウントの設定が必要かどうか疑問に思っています。
データベースに Windows 統合/SSPI ログインが必要な場合は、RunAs やディレクトリ権限など、あらゆる場所で NetworkService (またはドメイン サービス アカウント) を使用する必要があります。また、このデータベースへのアクセス権を computername$ またはドメイン アカウントに付与していると仮定します。これを実行しているとは思えませんが、通常のユーザー名/パスワード認証を使用している場合は、LocalService ですべてを実行できるはずです。そのディレクトリで付与する必要があるのは、RunAs で使用するアカウント権限の 1 つだけで、両方ではありません。
3.「ネットワーク サービス」アカウントの機能について誤解している可能性があります。
ローカルサービス/ネットワークサービスこれらは、ローカル コンピュータ上のほぼ同じアカウントです。主な違いは、ネットワーク上で実行できることです。NS は、ネットワーク上で実際の (コンピュータ) アカウントとして表示されるため、一部のネットワーク リソースにアクセスできます。ただし、LS は ANONYMOUS として表示されるため、ネットワーク上のほとんどすべての操作が拒否されます。
ちなみに、この場合はサービスではなく、スケジュールされたタスクを使用する必要があります。
*Vista以降では、サービス分離侵害されたLocalServiceプロセスが他のプロセスを簡単に攻撃することはできません。各LocalService/NetworkServiceサービスプロセス/インスタンスは、Windows 2003とは異なり、独自のログオンセッションSID（一意の所有者）を取得します。ただし、これが完璧であり、ファイルとリソースのDACL脆弱性を完全に軽減するかどうかはわかりません。制限されたSIDと 書き込み制限トークンこの文脈で言及されています。