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