DevOpsナレッジハブ
DevOpsナレッジハブ

ローカルユーザー対集中認証: 適切なLinuxセットアップの選択

Linux環境におけるローカル `/etc/passwd` ユーザー管理と、LDAPまたはActive Directoryを使用した集中認証の重要な決定について解説します。このガイドでは、両方のセットアップの長所、短所、スケーラビリティの課題、およびセキュリティへの影響を詳しく説明します。ローカルのシンプルさと、SSSDの役割を含め、ディレクトリサービスが提供する必須の一貫性のどちらを選択すべきかについて実践的なガイダンスを学びます。

41 ビュー

＃ローカルユーザー vs. 集中型認証: 適切なLinux設定の選択

ユーザーのIDとアクセスの制御は、Linuxシステム管理における基本的なタスクです。成長している環境では、ユーザーをどのように認証するかが重要な決定事項となります。それは、各マシンで個別に管理すべきか（ローカル認証）、それとも単一の信頼できるソースから管理すべきか（集中型認証）という問題に帰着します。

この記事では、従来の/etc/passwdファイル構造に依存する方法と、LDAPやActive Directoryなどのディレクトリサービスを統合する方法という、2つの主要な手法について包括的に比較します。スケーラビリティ、セキュリティ、および管理上のオーバーヘッドに関するトレードオフを理解することは、特定の組織のニーズに最適な認証戦略を選択するために不可欠です。

ローカル認証（/etc/passwdモデル）の理解

ローカルユーザー管理は、スタンドアロンのLinuxマシンでユーザーアカウントを処理するための、デフォルトで最もシンプルな方法です。すべてのユーザーおよびグループ情報はローカルファイルシステムに直接保存されます。

ローカル認証の仕組み

ユーザー認証情報、ユーザーID（UID）、グループID（GID）、ホームディレクトリ、およびデフォルトシェルは、特定のシステムファイル内で管理されます。

  • /etc/passwd: 必須のユーザーアカウント情報（ユーザー名、UID、GID、ホームディレクトリ、シェル）を格納します。
  • /etc/shadow: 暗号化されたパスワードハッシュとパスワードエージング情報（このファイルはrootのみが読み取り可能）を格納します。
  • /etc/group: グループ情報を格納します。

ローカル認証のメリット

  1. シンプルさと速さ: 1台または2台のマシンに対して設定するのが非常に簡単です。ユーザーの追加は、useraddのようなツールを使用するか、ファイルを直接手動で編集するのと同じくらい簡単です（ただし、ツールの使用が推奨されます）。
  2. オフラインでの利用可能性: ネットワークがダウンしている場合や、中央認証サーバーに到達できない場合でも、ユーザーはログインできます。
  3. 外部依存性の排除: 追加のインフラストラクチャ、専用サーバー、または複雑なネットワーク設定は必要ありません。

ローカル認証のデメリット

  1. スケーラビリティの悪夢: 数十または数百のサーバーがある環境では、一貫性を維持することが不可能になります。ユーザーが20台のサーバーへのアクセスを必要とする場合、20個の別々の同一アカウントを持たなければなりません。
  2. セキュリティリスク: アクセスを取り消すには、影響を受けるすべてのマシンに個別にログインする必要があります。1台のサーバーを忘れると、不正なアカウントがアクティブなままになります。
  3. UID/GIDの不整合: 複数のシステム間でUIDを手動で管理すると、競合が発生し、ファイルシステム（NFSなど）を共有するときにパーミッションの問題を引き起こすことがよくあります。

実践例：ローカルユーザーの追加

analyst1という名前の新しいユーザーをローカルに追加するには：

sudo useradd -m -s /bin/bash analyst1
sudo passwd analyst1
# プロンプトが表示されたらパスワードを設定します

集中型認証の理解

集中型認証は、ユーザーIDを検証する責任を、専用のネットワークアクセス可能なサービスに委任します。ユーザーがLinuxマシンにログインしようとすると、そのマシンは検証のために中央ディレクトリサーバーにクエリを実行します。

主要な集中型テクノロジー

Linux環境向けの集中型認証を支配する主要なテクノロジーは2つあります。

  1. LDAP (Lightweight Directory Access Protocol): OpenLDAPなどのツールを使用して実装されることが多いベンダーニュートラルなプロトコルです。非常に柔軟ですが、かなりの設定と知識が必要です。
  2. Active Directory (AD): マイクロソフト独自のディレクトリサービスです。Linuxマシンは、主にプライマリ認証としてKerberosを使用し、ADユーザーをローカルのPOSIX属性にマッピングするためにSSSDまたはWinbindのいずれかを使用してADと統合できます。

集中型認証のメリット

  1. 信頼できる単一の情報源 (Single Source of Truth): ユーザーの作成、変更、削除が1か所で行われ、接続されているすべてのシステム間で即座に一貫性が確保されます。
  2. スケーラビリティ: ユーザーあたりの管理オーバーヘッドを増やすことなく、5台のサーバーから5千台のサーバーへと容易にスケーリングできます。
  3. 強化されたセキュリティとコンプライアンス: アクセスの取り消しは企業全体で即座に行われます。集中型システムは、高度なセキュリティポリシー（例：MFA、複雑なパスワード要件）と容易に統合できます。
  4. UID/GIDの一貫性: 集中型システムはPOSIX属性（UID、GID、ホームディレクトリ）を一元的に管理するため、共有ストレージを使用する際の競合が排除されます。

集中型認証のデメリット

  1. ネットワーク依存性: ディレクトリサーバーまたはネットワーク接続に障害が発生した場合、集中型クレデンシャルのみに依存しているユーザーはログインできなくなる可能性があります（キャッシュによって軽減されます。後述のSSSDを参照）。
  2. 複雑性: 初期セットアップには、専用のインフラストラクチャ、ネットワーク構成、および特殊なクライアントソフトウェア（SSSDやKerberosライブラリなど）が必要です。
  3. 初期コスト: LDAPはオープンソースであり得ますが、堅牢なAD環境をセットアップおよび維持するには、ライセンス費用と専門知識が必要になります。

適切な戦略の選択: 環境の規模とニーズ

最適な選択は、組織の規模、複雑さ、およびセキュリティ要件に大きく依存します。

特徴 ローカル認証 (/etc/passwd) 集中型認証 (LDAP/AD)
環境規模 1～5台のサーバー 5台以上のサーバー / エンタープライズ
管理オーバーヘッド 高い（サーバーごとのメンテナンス） 低い（単一の制御点）
セキュリティポリシーの適用 一貫性の適用が困難 非常に優れている（グローバルポリシー）
オフラインアクセス 非常に優れている キャッシュが必要（例：SSSD）
初期設定の難易度 非常に低い 高い

ローカル認証を使用すべき場合

ローカル認証は、次のような場合に理想的です。

  • 小規模なラボまたは個人用ワークステーション: 信頼できる個人が1人か2人しかアクセスを必要としない環境。
  • 隔離されたシステム: ディレクトリサーバーへのネットワーク接続が不可能または望ましくないエアギャップされたマシンやIoTデバイス。
  • 一時的な踏み台ホスト (Bastion Hosts): 完全なディレクトリ統合スタックを展開するには大げさすぎる、短期間のみ使用されるシステム。

集中型認証を導入すべき場合

集中型認証は、次のような場合に必須です。

  • 企業環境: ユーザーが複数のサーバー、ネットワーク共有、またはサービスへのアクセスを必要とするあらゆる環境。
  • コンプライアンスのニーズ: 一貫したアクセス制御と監査証跡が義務付けられている、監査または厳格なコンプライアンスの対象となる環境。
  • 大規模な展開: ユーザーライフサイクル管理（オンボーディング/オフボーディング）を瞬時かつ自動化する必要がある場合。

集中型認証の実装：主要ツール

ADまたはLDAPと統合する最新のLinuxシステムの場合、sssd (System Security Services Daemon) パッケージが業界標準のクライアントです。これは、nss_ldapやpam_ldapなどの古いツールに取って代わります。

SSSDの役割

SSSDは、ローカルシステムサービスとリモートディレクトリプロバイダー（LDAPまたはAD）との間の橋渡し役として機能します。主な機能は次のとおりです。

  1. キャッシング: SSSDは認証データをローカルにキャッシュします。ディレクトリサーバーへの接続が失われた場合でも、最近ログインしたユーザーは、設定された期間内であればローカルで認証できるため、オフラインアクセスの欠点が解消されます。
  2. PAM/NSS統合: Pluggable Authentication Modules (PAM) および Name Service Switch (NSS) とシームレスに統合し、標準のLinuxコマンド（login、ssh）がリモートアカウントで透過的に機能するようにします。

実践例：SSSD構成スニペット（概念）

Active Directoryとの統合では、SSSDを構成してKerberosを認証に使用し、ADドメインにリンクさせることがよくあります。構成ファイルは広範囲にわたりますが、中心となる考え方は接続の確立です。

# AD統合のための /etc/sssd/sssd.conf のスニペット
[domain/example.com]
cache_credentials = True
ldap_search_base = dc=example,dc=com
auth_to_local = match_user

[sssd]
services = nss, pam
domain_blacklist = 169.254.169.254

ユーザー管理のベストプラクティス

選択した方法に関係なく、以下のベストプラクティスを遵守してください。

  • Rootの使用を避ける: 日常的な管理タスクにローカルのrootアカウントを決して使用しないでください。集中型アカウントとsudoメカニズムを活用してください。
  • 定期的な監査: ローカルアカウントを使用している場合は、不正なエントリや古いエントリがないか、/etc/passwdと/etc/shadowを定期的に監査してください。
  • 最小権限の原則: ユーザーには、その役割に必要な最小限の権限のみを付与するようにしてください。集中型システムは、グループメンバーシップを介してこれを容易に適用できます。
  • UIDの標準化: 集中型アカウントと並行してローカルアカウントを使用する必要がある場合は、ローカルUIDが集中型ユーザー用に予約されている標準範囲（例：1000以上）と重複しないようにしてください。

結論

小規模で静的な環境では、ローカルの/etc/passwd管理のシンプルさは魅力的です。しかし、組織が複数のLinuxシステム全体で一貫したアクセス管理を要求するようになった途端、LDAPまたはActive Directoryを介した集中型認証は、贅沢品ではなく必須のものとなります。

SSSDのような最新のツールを活用することで、管理者はディレクトリサービスのスケーラビリティとセキュリティのメリットを獲得しつつ、完全なネットワーク障害のリスクを軽減することができ、堅牢で管理しやすいLinuxインフラストラクチャへの道が開かれます。