DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

ローカルユーザー vs 集中認証：適切なLinux環境の選択

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

ローカルユーザー vs 集中認証：適切なLinux環境の選択

Linuxの認証は小さな問題から始まります。1台のサーバー、1人の管理者、1つのローカルアカウント。その後、2台目のサーバーが登場します。次に、契約社員が一時的なアクセスを必要とします。そして、誰かが会社を去ります。その時点で、問題は「useraddでユーザーを追加できるか」ではなくなります。問題は、誰がアクセス権を持っているかを証明できるか、アクセス権を迅速に削除できるか、そしてマシン間で権限の一貫性を維持できるかどうかです。

ローカルユーザーと集中認証には、それぞれ適した場面があります。ローカルアカウントは、孤立したシステムにとってシンプルで信頼性があります。LDAP、Active Directory、FreeIPA、または類似のディレクトリサービスによる集中認証は、Linuxサーバーが共有インフラストラクチャになると、通常はより適切な選択肢です。

ローカル認証を理解する（/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など）を共有する際に権限の問題を引き起こします。

UIDの問題は過小評価されがちです。Linuxのファイル所有権は名前ではなく数値IDとして保存されます。あるサーバーでaliceがUID 1001であり、別のサーバーでbobがUID 1001である場合、共有ストレージでは、どこから見るかによってファイルが間違った人物の所有として表示される可能性があります。これはラボでは煩わしく、本番環境では危険です。

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

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

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

集中認証を理解する

集中認証は、ユーザーIDを検証する責任を、ネットワーク経由でアクセス可能な専用サービスに委任します。ユーザーがLinuxマシンにログインしようとすると、そのマシンは中央のディレクトリサーバーに検証を問い合わせます。

主要な集中テクノロジー

Linux環境における集中認証の状況では、2つの主要なテクノロジーが主流です。

  1. LDAP（Lightweight Directory Access Protocol）: ディレクトリアクセスプロトコルであり、OpenLDAP、389 Directory Server、またはより大規模なIDプラットフォームの一部として実装されることがよくあります。柔軟性がありますが、生のLDAP環境では、スキーマ、TLS、レプリケーション、アクセス制御の設計に注意が必要です。
  2. Active Directory（AD）: Microsoftのディレクトリサービスです。Linuxマシンは、認証にKerberos、IDルックアップとグループマッピングにSSSDまたはWinbindを使用して、ADと統合するのが一般的です。
  3. FreeIPA/IdM: LDAP、Kerberos、DNS、証明書、ポリシー管理を組み合わせたLinux向けのIDプラットフォームです。環境が主にLinuxであり、既にADに依存していない場合に検討する価値があります。

集中認証の長所

  1. 単一の情報源: ユーザーの作成、変更、削除が1か所で行われ、接続されているすべてのシステム間で即座に一貫性が確保されます。
  2. スケーラビリティ: 手動管理のローカルアカウントよりもはるかに優れたスケーラビリティを発揮します。運用作業は依然として必要ですが、ユーザーのライフサイクル管理は中央で行われます。
  3. セキュリティとコンプライアンスの強化: アクセス権の取り消しは、キャッシュ設定とサービスの動作に依存しますが、1か所から広範囲に適用できます。集中システムは、MFA、パスワードポリシー、グループベースのアクセス、監査プロセスともより自然に統合されます。
  4. UID/GIDの一貫性: 集中システムはPOSIX属性（UID、GID、ホームディレクトリ）を中央で管理するため、共有ストレージを使用する際の競合がなくなります。

集中認証の短所

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

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

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

特徴 ローカル認証（/etc/passwd） 集中認証（LDAP/AD）
環境規模 少数のスタンドアロンシステム 共有フリート、チーム、またはエンタープライズ環境
管理オーバーヘッド 高い（サーバーごとのメンテナンス） 低い（単一の制御点）
セキュリティポリシーの適用 一貫性の適用が困難 優れている（グローバルポリシー）
オフラインアクセス 優れている キャッシュが必要（例：SSSD）
初期セットアップの難易度 非常に低い 高い

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

ローカル認証は以下に最適です：

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

集中認証を実装すべき場合

集中認証は通常、以下の場合に適切な選択肢です：

  • 企業環境: ユーザーが複数のサーバー、ネットワーク共有、またはサービスにアクセスする必要があるあらゆる環境。
  • コンプライアンス要件: 一貫したアクセス制御と監査証跡を義務付ける監査または厳格なコンプライアンスの対象となる環境。
  • 大規模なデプロイメント: オンボーディングとオフボーディングを迅速、再現可能、かつ監査可能にする必要がある場合。

誰にとっても答えが変わる魔法のサーバー台数はありません。ラボの1人の管理者がいる5台のサーバーは、ローカルユーザーで十分に運用できます。規制対象データを保持する3台の本番サーバーは、すぐに集中制御を必要とする場合があります。推進力は規模だけでなく、リスク、離職率、コンプライアンス、共有ストレージ、そしてアクセス権が変更される頻度です。

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

AD、LDAP、またはFreeIPAと統合する多くの最新のLinuxシステムでは、sssd（System Security Services Daemon）が一般的なクライアントです。nss_ldapやpam_ldapなどの古いツールも一部の環境ではまだ存在しますが、キャッシュとプロバイダー統合の点で、SSSDが通常はより良いデフォルトです。

SSSDの役割

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

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

実践例：SSSD設定スニペット（概念）

Active Directoryとの統合には、多くの場合、realmやadcliなどのツールを使用してドメインに参加し、その後SSSDにIDと認証を処理させることが含まれます。実際の設定は、ドメインポリシー、DNS、TLS、アクセスルール、およびディストリビューションのデフォルトに依存します。この簡略化されたスニペットは、一般的な形状のみを示しています。

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

[sssd]
services = nss, pam
domains = example.com

小さなスニペットを本番環境にコピーして、それが完全であると期待しないでください。SSSDには、/etc/sssd/sssd.confの正しいファイル権限、機能するDNS、Kerberosのための時刻同期、およびプロバイダー固有の設定が必要です。フリート全体にロールアウトする前に、管理者以外のアカウントでログインをテストしてください。

ハイブリッド設定は一般的

集中認証が標準であっても、ほとんどのLinuxシステムは依然としていくつかのローカルアカウントを保持しています。rootアカウントは存在します。クラウドイメージにはローカルのブートストラップユーザーがいる場合があります。IDプロバイダーに到達できない緊急時に備えて、緊急時用アカウントが必要になる場合があります。

それは問題ありませんが、ローカルの例外には規律が必要です：

  • ローカルの人間用アカウントの数を少なく保ちます。
  • 適切な場合はSSHキーまたはロックされたパスワードを使用します。
  • ローカルアカウントを定期的に監査します。
  • 緊急時用の使用を文書化し、使用後は資格情報をローテーションします。
  • すべての管理者に、すべてのサーバーで個別の管理されていないローカルアカウントを与えないでください。

一般的なパターンは、通常の管理には集中ログイン、ディレクトリグループに基づくsudoルール、そして厳重に管理された1つの緊急パスです。これにより、ID障害時にリカバリを不可能にすることなく、日常的な監査可能性が得られます。

成功を左右する運用上の詳細

集中認証が失敗する最も多い理由は、DNS、時刻、証明書、キャッシュといった退屈なものです。

Kerberosは時刻のずれに敏感です。サーバーのクロックがドリフトすると、パスワードが正しくてもログインに失敗する可能性があります。NTPまたはchronyを使用し、それを監視してください。

ディレクトリルックアップはDNSに依存します。LinuxクライアントがドメインコントローラーまたはLDAPサーバーを確実に見つけられない場合、認証は不安定に感じられます。単一のサーバーをハードコーディングすると、メンテナンス日までは機能するかもしれません。ディレクトリサービスに推奨される検出メカニズムを使用してください。

LDAPではTLSが重要です。適切なトランスポートセキュリティなしで資格情報やディレクトリデータを送信することは、特に完全に制御できないネットワークを介する場合、悪い習慣です。「とりあえず動かす」ためにチェックを無効にするのではなく、証明書を検証してください。

キャッシュには意識的なポリシーが必要です。SSSDは、最近認証されたユーザーが障害発生時にログインできるようにすることができ、これは便利です。しかし、キャッシュの有効期間が長いと、権限の取り消しが遅れる可能性があります。キャッシュの有効期間が短いと制御は向上しますが、障害がより苦痛になります。環境のリスクに基づいて選択してください。

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

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

  • rootの使用を避ける: 日常的な管理タスクにローカルのrootアカウントを使用しないでください。集中アカウントとsudoメカニズムを利用してください。
  • 定期的な監査: ローカルアカウントを使用する場合は、許可されていないエントリや古いエントリがないか、/etc/passwdと/etc/shadowを定期的に監査してください。
  • 最小権限の原則: ユーザーには、その役割に必要な最小限の権限のみが付与されるようにしてください。集中システムは、グループメンバーシップを介してこれを適用しやすくします。
  • UIDの標準化: 集中アカウントと一緒にローカルアカウントを使用する必要がある場合は、ローカルUIDがディレクトリユーザーに使用される範囲と重複しないようにしてください。正確な範囲はディストリビューションとID設定によって異なるため、ローカルの規約を文書化してください。

移行に関するアドバイス

ローカルユーザーから集中認証に移行する場合は、すべてのサーバーを一度に切り替えないでください。重要でないホストから始めてください。id usernameでユーザーが解決されること、グループが正しく表示されること、sudoルールが機能すること、SSHログインが期待どおりに動作すること、キャッシュされたログインがポリシーに従って機能することを確認してください。

次に、ファイルの所有権を処理します。ローカルUIDがディレクトリUIDと異なる場合、ファイルの所有権を変更する必要があるかもしれません。共有ホームディレクトリとNFSマウントは特別な注意が必要です。一括でchownを実行する前にバックアップを取り、実際のユーザーワークフローでテストしてください。

最後に、ディレクトリパスが機能した後、古いローカルアカウントを削除またはロックしてください。両方のシステムを永久にアクティブのままにしておくと、得ようとしていたセキュリティ上の利点の多くが失われる可能性があります。

最終確認

ローカルユーザーは、マシンが真にスタンドアロンであり、アクセス権がめったに変更されず、影響範囲が小さい場合に最適です。集中認証は、人、サーバー、権限が頻繁に変更され、手動のアカウント管理がリスクになる場合に適しています。ローカルの緊急時用アクセスは維持しつつ、通常のパスは集中化、監査可能、グループベースにしてください。これが、ほとんどのチームが誰がどこにログインできるかを見失うことなく運用できる設定です。