ユーザーアカウントとサービスアカウントの違いは何ですか？

ユーザーアカウントは実際のユーザーによって使用され、サービスアカウントはシステムサービス（Webサーバー、メール転送エージェント、データベースなど）で使用されます。通常、サービスアカウントには<1000程度のより小さい範囲のユーザーIDがあります。 UID 0を除き、サービスアカウントには特別な権限がありません。サービスアカウントは特定のリソースとデバイスの特殊ファイルまで所有でき、しばしば所有しますが、スーパーユーザーなどの権限はありません。

サービスアカウントは通常のユーザーアカウントのように作成できます（たとえばuseradd、サービスアカウントは通常、サービスソフトウェアをインストールするときにパッケージマネージャによって作成および構成されているため、管理者でもサービスアカウントの作成に直接関与することはほとんどありません。

妥当な理由があります。ユーザーアカウントとは異なり、サービスアカウントには通常「適切な」ログインシェルはありません。つまり、/usr/sbin/nologinログインシェル（または過去には/bin/false）があります。また、サービスアカウントがロックされることがよくあります。つまり/etc/passwd、ログインできません（既存のアカウントの場合、/etc/shadowパスワードハッシュを任意の値（たとえば、または）に設定すると*可能ですx）。これは、悪用に備えてサービスアカウントを強化するためのものです（深い防御）。

サービスごとに別々のサービスアカウントを設定することは、主に2つの目的に使用されます。 1つのサービスで事故が発生した場合の影響を軽減するためのセキュリティ対策。区画化）、どのリソースがどのサービスに属しているかを追跡する方が簡単なため、管理が簡素化されます。バラよりこれまたはこれ詳細は関連質問への回答です。

最初に、ユーザーはシステムを使用している人を対象として名前が付けられました。すべてのプロセスは特定のユーザーとして実行され、すべてのファイルは特定のユーザーによって所有されます。ルートという特別なユーザーは、特定の人間ユーザー（オペレーティングシステム自体など）に属さない操作を実行するために使用されます。ルートはオペレーティングシステム自体に対応するため、すべての権限を持ちます。

まもなく、人々はあまりにも多くの権限を必要とせずに複数のシステムユーザーを作成するのが便利であることを知りました。これにより、マシンで実行されているさまざまなサービスを分離し、互いに干渉しないようにすることができます。サービスアカウント（または「システムアカウント」、2つの用語は同義語です）は、システムを使用している人ではなく、システムで実行されているサービスに対応するアカウントです。通常、システムで実行される各タスクには、独自の権限セット（たとえば、独自のファイル、独自のネットワークポートなど）を持つサービスアカウントがあります。

人間アカウントとシステム/サービスアカウントの正式な定義はありません。カーネルは気にしません（UID 0を持つユーザーに多くの権限を与えることに加えて）。ほとんどの管理コマンドも問題ありません。いくつかの一般的な違いは次のとおりです。

• 人間のユーザーは「ジョン・ドー」のような実際の名前を持ち、システム・ユーザーは「ナサル・デーモン」のような説明的な名前を持っているか、まったく持っていません。
• 人間のユーザーには、実際のログインシェル（または/bin/shまたは/bin/bash）があります/bin/csh。一部のシステムユーザーはシェル（ほぼ常に）を持っていますが、他のユーザーは使用方法に応じて（たとえばシェルが必要です）、そうではありません/bin/sh。su foofoo
• 人間のユーザーは通常パスワードを持っていますが、必ずしもそうではありません。たとえば、リモートユーザーだけがSSHキーのみを持つことができます。最新の unice では、パスワードは/etc/passwd他のファイルにありません/etc/shadow。
• /home人間のユーザーのホームディレクトリは通常（または一部のサイト固有の場所）にありますが、システムユーザーのホームディレクトリは通常、場所がないか存在しない可能性があります/home（例外があります）。
• ほとんどのサイトでは、システムユーザーのユーザーIDの範囲を指定し、人間のユーザーには別の範囲を指定します。通常、100–65533 または 500–65533 または 1000–65533 が予約されており、ほとんどのディストリビューションは 500 または 1000 から始まる実際のユーザー ID を割り当てるように設定されます。

複数のコンピュータがアカウントを共有するサイトには、通常、ユーザーのリストを含む中央サーバーがあります。国家庭園またはLDAP。passwdアイテム/etc/nsswitch.confユーザー情報を検索する場所を指定します。システムユーザーがローカルにあり、/etc/passwdネットワーク全体のデータベースに物理ユーザーがあることが一般的ですが、ネットワーク全体のデータベースにシステムユーザーがあり（一貫したUIDを強制し、サーバーとデータの複製を容易にするため）、人がいることがあります。ローカルファイルのユーザー（ネットワークがハングしてもログインしたまま）

システムユーザーとして偽装する人がアクセスできるアカウントには通常、実際の名前はありませんが、ログインシェル、パスワードセット、SSHキー、システム全体のユーザーIDがあります。実際、実際のシステムアカウントを使用する方が良い変装であり、そのアカウントを削除すると一部のサービスの動作が停止します。しかし、潜在的な攻撃を検出するために厳格で迅速なルールを持つことはできません。定義によると、攻撃者はルールに従わない。

サービスアカウントとヒューマンアカウントは同じコマンドで管理され、同じファイルに書き込まれます。アカウント作成コマンドには、人とサービスのユーザーに合理的なデフォルト値を設定するオプションがあります。たとえば、適切な範囲内でユーザー ID を選択し、ユーザーにパスワードの入力を求めるメッセージ、サービスのパスワード確認を無効にするなどのオプションがあります。たとえば、Linuxではadduservsadduser --systemまたはuseraddvsです。useradd -r

• 1. 技術アカウントとも呼ばれるサービスアカウントは、通常のユーザーではなく、サービス/アプリケーションでのみ使用されるアカウントです。
• 2. アプリケーションとサービス開発者は、プロセスを root として実行するのではなく、これらのアカウントが関連するプロセス権限と権限を制限したいと考えています。ルートとして実行されるinitまたは同様のサービスは、systemdリスクを制限するためにサービスアカウントにすばやくダウングレードされます。使用するオペレーティングシステムによっては、アプリケーションアカウントには、特権TCPポートにバインドする権限など、通常のアカウントよりも多くのfork権限が付与されることがありますexec。この場合、サービスを開始するために使用できるサービスアカウントにサービスをダウングレードする必要はありません。
• 3. 必ずしもそうではありませんが、うまくいくパスワードがなく、うまくいかないシェル（たとえば）を持つアカウントを作成すると、一般ユーザーはそれを使用できません。つまり、次のようにローカルまたはリモートで/bin/falseログインすることはできません。sshアカウント名。ほとんどの制限と同様に、rootアカウントを使用するか、sudoそれを克服できます。

たとえば、サービスアカウントはシェルを使用できない可能性があります。限られた範囲と権限でサービス（デーモン）を実行するために使用されます。私の考えでは、一般ユーザーとして作成することができ、権限とグループメンバーシップに注意してください。ただし、ほとんどの場合、プログラムはインストールプロセス中に自動的に生成されるため、これを行う必要はありません。見て/etc/passwd root:x:0:0:root:/root:/bin/bash

0 は、ユーザー空間のアカウント階層を表す UID です。すべての人の上にルートがあり、グループメンバーシップ、:rootホームディレクトリがあり、/root最後に/bin/bashアカウントがシステムに「ログイン」するために使用するシェルがあります。

/usr/sbin/nologinログイン権限を必要としないアカウントを使用できます。