AlmaLinux 9 総合ガイド 第４章

2025.01.24

第4章: ユーザーとグループ管理

4.1 この章で解説する主要な技術・概念

本章では、AlmaLinux9 環境におけるユーザー／グループ管理の中核を成す以下の６つの技術・概念を詳細に掘り下げます。各項目で背景・役割・活用のポイントを解説し、運用にあたって注意すべきセキュリティ設定やベストプラクティスを紹介します。

4.1.1 Linux ユーザー・グループ管理の基盤ファイル

  • 背景・役割
    • システム上の全ユーザーおよびグループ情報はテキストファイルで一元管理され、OSがこれらを参照して認証・権限付与を行います。
    • 適切なファイル保護により、不正アクセスを未然に防ぎつつセキュリティ設定を堅牢化します。
  • 管理ファイル一覧
ファイル管理対象デフォルト権限
/etc/passwdユーザー名・UID・GID・ホーム・シェルなど-rw-r--r--
/etc/shadowパスワードハッシュ・最終変更日・有効期限-r-------- (root のみ)
/etc/groupグループ名・GID・メンバーリスト-rw-r--r--
/etc/gshadowグループパスワード・管理者・メンバー-r-------- (root のみ)
  • 活用ポイント
    • /etc/shadow と /etc/gshadow は root のみアクセス可能。一般ユーザーからの読み取りを厳重に防ぎます。
    • SELinux Enforcing モード下では、ファイルの SELinux コンテキストも参照されるため、編集後は restorecon を用いてラベルの整合性を確認・再適用してください。 (Red Hat Documentation)

4.1.2 ユーザーアカウント操作コマンド（useradd/usermod/userdel）

  • 背景・役割
    • useradd で新規ユーザーを作成し、usermod で属性を変更、userdel でアカウントを削除します。
    • 適切なアカウント管理は不要アカウント放置によるリスクを排除し、サービス／アプリケーション専用ユーザーの分離を実現します。
  • 主な操作と注意点
    • 新規作成 (useradd)
      • UID/GID、ホームディレクトリ、ログインシェルなどをテンプレート化可能
      • システムアカウントは -r オプションで UID < UID_MIN 範囲に固定 (Red Hat Documentation)
    • 属性変更 (usermod)
      • 補助グループ追加は必ず -aG を併用し、既存設定を上書きしない
      • ロック／アンロックは -L/-U で制御
    • 削除 (userdel)
      • -r でホームディレクトリとメールスプールを同時に削除
      • 本番環境では事前にバックアップと利用状況の確認を徹底

4.1.3 グループ操作コマンド（groupadd/groupmod/groupdel）

  • 背景・役割
    • 複数ユーザーにまとめて権限を付与する“セキュリティグループ”の作成・変更・削除を行います。
    • 運用規模に応じてグループ設計を先行することで、権限ミスを大幅に削減できます。
  • 基本操作 
# root ユーザーで実行：グループ作成
sudo groupadd -g 3001 devops

# グループ名変更
sudo groupmod -n devteam devops

# グループ削除
sudo groupdel devteam
  • ポイント
    • GID 範囲は /etc/login.defs の GID_MIN/GID_MAX で管理。大規模環境ではカスタマイズを検討
    • 直接 etc/group を編集せず、必ず専用コマンドを用いることでファイル整合性を保持します (Red Hat Documentation)

4.1.4 sudo の詳細設定と権限昇格管理

  • 背景・役割
    • sudo により一般ユーザーに最小限の管理者権限を付与し、操作ログを一元管理します。
    • 誤操作や不正な操作の防止と、後続のトラブルシューティング／コンプライアンス対応が容易になります。
  • 構成要素
    • /etc/sudoers は visudo でのみ編集し、文法チェックを必ず実行
    • Alias 機能 (User_Alias、Cmnd_Alias など) を活用すると設定が大規模でも可読性高く管理可能
    • NOPASSWD: でパスワードレス実行を制限的に許可し、自動化用途に対応
  • ログ監査
    • 実行履歴は /var/log/secure や journalctl -t sudo に記録
    • SIEM（Splunk／Elastic Stack など）と連携してリアルタイム監視・アラートが設定可能 (Red Hat Documentation)

4.1.5 パスワードポリシーと pam_faillock による保護

  • 背景・役割
    • /etc/login.defs で最小・最大パスワード有効期間や長さを定義し、pam_faillock モジュールで総当たり攻撃をブロックします。
    • 長寿命かつ複雑なパスワードを強制しつつ、失敗回数による自動ロック機能でセキュリティを強化します。
  • 設定例
# /etc/login.defs
PASS_MAX_DAYS   90
PASS_MIN_LEN    12
PASS_WARN_AGE   7

# /etc/pam.d/system-auth 等に追加
auth required pam_faillock.so preauth silent deny=5 unlock_time=600
account required pam_faillock.so
  • ポイント
    • ロック閾値 (deny) や解除時間 (unlock_time) は運用ポリシーに合わせて調整
    • RHEL9 系では直接 PAM ファイルを編集せず、authselect で一元管理を推奨 (Red Hat Documentation)

4.1.6 LDAP／SSSD を使った集中認証管理

  • 背景・役割
    • 大規模環境向けに、Active Directory や OpenLDAP など外部ディレクトリと連携し、一元的なユーザー管理を可能にします。
    • SSSD は名前解決（NSS）と認証（PAM）のクライアントを担い、オフラインキャッシュ機能で可用性を確保します。
  • 導入の流れ
    1. dnf install sssd でパッケージを導入
    2. /etc/sssd/sssd.conf に接続先情報を設定
    3. authselect で nss/pam プロファイルを切り替え
  • ポイント
    • LDAP サーバーとの通信は TLS 証明書検証を必須とし、中間者攻撃を防止 (sssd.io)
    • キャッシュ設定（entry_cache_timeout など）は組織のネットワーク状況に合わせて最適化

以上を理解いただいた上で、次節以降では各機能の具体的な手順とベストプラクティスを詳述していきます。

4.2 Linux におけるユーザーとグループの基本構造

AlmaLinux9 上でユーザーおよびグループ情報がどのように管理・解決されるかを基盤ファイル、レコード構造、UID/GID ポリシー、名前解決、SELinux コンテキストの観点から詳述します。

4.2.1 主要管理ファイルと役割

Linux はテキストファイルでユーザー・グループ情報を一元管理し、認証・権限付与の土台を提供します。

ファイル管理対象デフォルト権限
/etc/passwdユーザー名・UID・GID・ホームディレクトリ・シェル-rw-r--r--
/etc/shadowパスワードハッシュ・最終変更日・有効期限-r-------- (rootのみ)
/etc/groupグループ名・GID・メンバーリスト-rw-r--r--
/etc/gshadowグループパスワード・管理者リスト・メンバー-r-------- (rootのみ)
# rootユーザーで実行：各ファイルの先頭3行を確認
sudo head -n3 /etc/passwd /etc/shadow /etc/group /etc/gshadow
  • /etc/shadow と /etc/gshadow は root のみ読み取り可能。一般ユーザーからの漏洩を防ぎます。
  • SELinux Enforcing モード下では、ラベルが不整合だとログインやサービスが失敗するため、編集後は必ず restorecon で整合性を確認してください。

💡ポイント:
管理ファイルのパーミッションと SELinux コンテキストの両輪でセキュリティ設定を強化しましょう。

4.2.2 レコード構造の詳細

各ファイルはコロン区切りのフィールドで情報を保持し、OS や dnf でインストールしたサービスが参照・更新します。

/etc/passwd

ユーザー名:パスワードプレースホルダ:UID:GID:GECOS:ホームディレクトリ:シェル
フィールド説明
ユーザー名ログイン名
パスワード欄x（実ハッシュは shadow）
UID数値ユーザー識別子
GIDプライマリグループ識別子
GECOSコメント（氏名など）
ホームデフォルトカレントディレクトリ
シェルログインシェル
# rootユーザーで実行：alice のレコードを抽出
sudo awk -F: '$1=="alice"{print}' /etc/passwd

/etc/shadow

ユーザー名:ハッシュ:最終変更日:最小日数:最大日数:警告日数:非アクティブ日数:有効期限:予約
  • 最終変更日は 1970-01-01 からの日数で管理
  • 非アクティブ日数でロック閾値を制御
# rootユーザーで実行：alice のパスワード期限情報を確認
sudo chage -l alice

/etc/group／/etc/gshadow

# /etc/group
グループ名:パスワードプレースホルダ:GID:メンバー[,…]

# /etc/gshadow
グループ名:ハッシュ:管理者[,…]:メンバー[,…]
# rootユーザーで実行：developers グループの詳細を確認
sudo grep '^developers:' /etc/group /etc/gshadow

💡ポイント:
フィールドの意味を正確に理解することで、スクリプトや Ansible での自動化が安定します。

4.2.3 UID/GID 範囲ポリシー

AlmaLinux9 では /etc/login.defs で UID/GID の範囲を定義し、システムアカウントと通常ユーザーを分離します。

# rootユーザーで実行：現在の範囲を確認
sudo grep -E '^(UID_MIN|UID_MAX|GID_MIN|GID_MAX)' /etc/login.defs
UID_MIN   1000
UID_MAX   60000
GID_MIN   1000
GID_MAX   60000
  • UID 1000 未満はシステムアカウント、1000 以上が通常ユーザーに割り当てられます。
  • ポリシーを変更する際は sudo useradd -D で新規作成時のデフォルトと整合性を取ってください。

💡ポイント:
大規模環境ではカスタム範囲（例：10000–20000）を設定し、UID/GID の衝突リスクをさらに低減しましょう。

4.2.4 名前解決（NSS）と統合参照

/etc/nsswitch.conf で「files」「sss」「ldap」など複数ソースを連携し、getent コマンドで統一的に情報を取得します。

# rootユーザーで実行：NSS の設定を確認
sudo grep '^passwd:' /etc/nsswitch.conf

# 一般ユーザーで実行：統合参照
getent passwd alice
getent group developers
  • SSSD 導入後はキャッシュ優先で高速参照が可能です。
  • ネームサービス変更時は systemctl restart sssd nscd でキャッシュをクリアしてください。

💡ポイント:
dnf で sssd をインストールすると自動的に NSS モジュールが有効化され、LDAP 連携も容易になります。

4.2.5 SELinux コンテキストの確認と修復

ファイル／ディレクトリのラベルが不整合だと、正しいパーミッション設定でもアクセスが拒否されます。

# rootユーザーで実行：コンテキストを表示
ls -lZ /home/alice

# rootユーザーで実行：ラベルを再適用
sudo restorecon -Rv /home/alice
  • -Z オプションで SELinux ラベルを併記表示。
  • restorecon により、ファイルパーミッションと SELinux コンテキストを同期できます。

💡ポイント:
SELinux Enforcing モードでのセキュリティ設定は、パーミッションだけでなくコンテキスト管理もセットで行いましょう。

4.2.6 情報参照コマンドとスクリプト例

日常運用でよく使うコマンドやワンライナーを紹介します。

# ユーザーの UID/GID、所属グループを確認
id alice

# ユーザーが所属するグループ一覧
groups alice

# 全ユーザーの UID:ユーザー名 一覧を作成
getent passwd | awk -F: '$3>=1000{print $3":"$1}' | sort -n

💡ポイント:
スクリプト化して定期的に実行すれば、UID/GID の重複や範囲外割当を自動検出できます。

次節では、これらの基盤を踏まえた上で具体的なアカウント操作と高度設定を解説します。

4.3 ユーザーアカウントの高度な設定

AlmaLinux9 環境でのユーザーアカウント操作を、標準以上に柔軟かつ安全に行うためのテクニックを解説します。ここでは「システムアカウントの管理」「useradd の高度オプション」「usermod の応用」「userdel のベストプラクティス」「デフォルト設定のカスタマイズ」の５つに分け、背景・役割・具体手順を詳述します。

4.3.1 システムアカウントとスケルトンディレクトリの管理

背景・役割

  • サービス用ユーザー（例：バックアップ、監視ツール）はログイン不要なシステムアカウントとして分離
  • /etc/skel をカスタマイズすると、新規ユーザーのホーム初期化を組織の標準設定に合わせられる

手順例

実行ユーザー: root
効果: ホームなしでログイン不可のシステムアカウント svc_backup を作成

# システムアカウントを作成（UID < UID_MIN 自動割当、ホームなし、nologin シェル）
useradd -r -s /sbin/nologin svc_backup

実行ユーザー: root
効果: /opt/custom_skel の内容を custom01 のホームとして初期化

# カスタムスケルトンを指定してユーザー作成
useradd -k /opt/custom_skel -m -c "Custom Skel User" custom01
  • /etc/skel ではなく任意のディレクトリをテンプレートにできるため、組織共通の設定ファイルを配布可能 (mediacollege.com)

4.3.2 useradd の高度オプション

背景・役割

  • 通常ユーザー、システムアカウント、グループ割当を柔軟に制御し、一貫したポリシー運用を実現
オプション役割
-rシステムアカウントとして UID < UID_MIN 範囲で作成
-NUser Private Group を自動作成せず、既存グループのみ使用 (Red Hat Documentation)
-g グループプライマリグループを指定
-G グループカンマ区切りで補助グループを指定

例：特定グループとスケルトンを併用
実行ユーザー: root
効果: developers をプライマリ、qa を補助に指定して作成

useradd -m -s /bin/bash -g developers -G qa john
passwd john

4.3.3 usermod の応用例

背景・役割

  • 役割変更や一時的な属性変更を安全に行い、既存アカウントの運用を継続しながら設定を更新
オプション役割
-l 新ログイン名ユーザー名の変更
-s シェルデフォルトログインシェルの変更
-e YYYY-MM-DDアカウント有効期限を設定
-L / -Uアカウントのロック／アンロック
-aG グループ補助グループを追加（既存を保持） (Oracle Docs)

例：複数ユーザーのシェル一括変更
実行ユーザー: root
効果: alice と bob のシェルを Zsh に切り替え

usermod -s /bin/zsh alice
usermod -s /bin/zsh bob

4.3.4 userdel のベストプラクティス

背景・役割

  • アカウント削除時のデータ残存・サービス停止リスクを回避し、安全にクリーニング

手順例

  • 事前ロック
    実行ユーザー: root
    効果: ログインを即時停止
usermod -L targetuser
  • ホームディレクトリのアーカイブ
    実行ユーザー: root
    効果: /home/targetuser を圧縮バックアップ
tar czf /root/archive/targetuser_home_$(date +%F).tgz /home/targetuser
  • アカウント削除
    実行ユーザー: root
    効果: ホームとメールスプールを含め削除
userdel -r targetuser
  • Cron ジョブや at ジョブも手動で確認・削除してください (Oracle Docs)

4.3.5 /etc/default/useradd とデフォルト設定のカスタマイズ

背景・役割

  • useradd -D で確認・変更可能な初期値を組織ポリシーに合わせ、一貫したユーザー作成を実現
# 現在のデフォルトを表示
useradd -D

# 出力例:
# GROUP=100
# HOME=/home
# INACTIVE=-1
# EXPIRE=
# SHELL=/bin/bash
# SKEL=/etc/skel

実行ユーザー: root
効果: デフォルトシェルを Zsh、ホームベースを /home2 に変更

useradd -D -s /bin/zsh -b /home2
  • SKEL の変更と組み合わせることで、新規ユーザーの初期設定を完全に統制できます (Oracle Docs)

4.4 グループ管理とアクセス制御

AlmaLinux9 環境で複数ユーザーの権限を一元管理し、ファイル・ディレクトリへのアクセスを効率的かつ安全に制御する方法を詳しく解説します。

4.4.1 グループ設計の重要性と役割

システム上で同じ業務やサービスを担当するユーザーをグループにまとめると、一括で権限付与・削除ができます。

  • 運用負荷を軽減し、誤設定によるセキュリティ事故を防止
  • グループ単位でのログ監査やアクセス制御ルール適用が容易

💡ポイント:

  • 命名規則（例：devops, webteam, dbadmins）を事前に定めると運用ミスを減らせます。
  • /etc/login.defs の GID_MIN/GID_MAX でグループID範囲を管理し、システムと通常グループを明確に分けましょう。

4.4.2 基本コマンドによるグループ操作

以下のコマンドでグループの作成・変更・削除が行えます。

操作コマンド例結果
作成sudo groupadd -g 3001 devopsGID=3001 の devops グループを作成
名前変更sudo groupmod -n devteam devopsdevops → devteam にグループ名を変更
削除sudo groupdel devteamdevteam グループを削除
# rootユーザーで実行
sudo groupadd -g 3001 devops
  • GID を指定すると、既存システムと衝突しにくくなります。
# rootユーザーで実行
sudo groupmod -n devteam devops
  • 将来的に名称変更や組織名変更があっても、権限はそのまま引き継がれます。
# rootユーザーで実行
sudo groupdel devteam
  • 削除前には、getent group devteam で影響範囲を確認しましょう。

4.4.3 プライマリ／補助グループの使い分け

あるユーザーが複数の役割を持つ場合、プライマリグループと補助グループを使い分けると柔軟に管理できます。

  • プライマリグループ：新規作成ファイルの所有グループになる
  • 補助グループ：追加の権限が必要なときにのみ所属
# rootユーザーで実行：補助グループとして webteam を追加
sudo usermod -aG webteam alice
  • -aG を付けないと既存の補助グループが上書きされるため注意してください。
# rootユーザーで実行：プライマリグループを変更
sudo usermod -g developers bob
  • プライマリグループ変更後は、chown bob:developers /home/bob などで既存ファイルの所有グループを揃えると混乱が防げます。

4.4.4 setgidビットによる共同ディレクトリ運用

プロジェクト共有ディレクトリで、メンバーが作成したファイルを自動的に同じグループ所有にしたい場合に有効です。

# rootユーザーで実行：ディレクトリ作成＆オーナー設定
sudo mkdir -p /var/www/proj
sudo chown root:webproject /var/www/proj

# setgidビットとパーミッションを設定
sudo chmod 2770 /var/www/proj
  • 2（setgid）により、新規ファイルは必ず webproject グループ所有になります。
  • 770 で所有者とグループのみ読み書実行を許可。

💡ポイント:

  • SELinux Enforcing モード下では、Apache などのサービスが書き込む場合に適切なコンテキスト（例：httpd_sys_rw_content_t）を再設定し、restorecon -Rv /var/www/proj を実行してください。

4.4.5 ACL による細粒度アクセス制御

標準の rwx だけでは対応しきれないケースでは、ACL（Access Control List）を利用してユーザーやグループごとにきめ細かい権限設定が可能です。

# rootユーザーで実行：ACL パッケージの確認・インストール
sudo dnf install -y acl

# ディレクトリにデフォルト ACL を設定（analysts に読み取り権限）
sudo setfacl -m d:g:analysts:rx /data/reports

# 特定ユーザーに書き込み権限を追加
sudo setfacl -m u:jane:rw /data/reports/2025_Q1.csv

# 現在の ACL を表示
getfacl /data/reports
  • d:g:グループ:権限 は新規ファイルに適用されるデフォルトACL
  • ACLを多用すると設定が複雑になるため、定期的に getfacl で監査し、不要なルールを削除しましょう。

4.4.6 ファイルパーミッションと umask の最適化

umask を適切に設定すると、新規ファイル／ディレクトリのデフォルトパーミッションを制御できます。

# rootユーザーで実行：/etc/login.defs の umask 値を確認・変更
sudo grep UMASK /etc/login.defs

# 一般ユーザーのシェル設定に umask を追加（例：022）
echo "umask 022" >> /etc/profile
  • 022 はファイル作成時に 644、ディレクトリ作成時に 755 をデフォルト設定します。
  • セキュリティ設定として、共同利用ディレクトリは umask 007（770）を推奨する場合もあります。

4.4.7 トラブルシューティングと運用ベストプラクティス

  • 権限エラー確認：ls -lZ でパーミッションと SELinux コンテキストを同時に確認
  • setgid 設定漏れ：新規ファイルのグループが異なる場合、chmod g+s ディレクトリ を再実行
  • ACL 過剰設定：getfacl で不要エントリを洗い出し、setfacl -b で一括削除
  • 定期監査：スクリプトで /var/www や /data 配下のパーミッションを収集・レポート化

💡ポイント:

  • Ansible や Puppet などの構成管理ツールでグループ／ACL 設定をコード化し、ヒューマンエラーを防ぎつつ AlmaLinux9 の運用を自動化しましょう。

4.5 sudo の高度な設定

AlmaLinux9 環境で sudo をより安全かつ柔軟に運用するためのテクニックを詳しく解説します。各節で背景・役割・具体手順を示し、実行ユーザーと期待結果を明示します。

4.5.1 sudo の利点と基本動作

  • 背景・役割
    • 一般ユーザーに必要最小限の管理権限を一時付与し、誤操作や不正利用を抑制します。
    • 操作ログを /var/log/secure や journalctl -t sudo に残し、トラブルシューティングやセキュリティ監査に活用します。
  • 基本確認
    • 実行ユーザー: 一般ユーザー
    • 手順: sudo のバージョンを表示
    • 期待結果: インストール済みの sudo バージョン表示（例: Sudo version 1.9.5p2）
sudo --version

💡ポイント:
最小権限の原則（Least Privilege）に沿って設定し、AlmaLinux9 のセキュリティ設定に貢献します。

4.5.2 visudo と sudoers ファイル構造

  • 背景・役割
    • visudo でのみ /etc/sudoers を編集し、文法エラーによる全ユーザー sudo ロックアウトを防止します。
  • 構造解説
要素説明
<ユーザー>個別ユーザー名または %<グループ名>
<ホスト>許可対象ホスト（通常は ALL）
(<実行ユーザー>)実行時に切り替わるユーザー（通常は root）
<コマンド>許可するコマンドまたは Cmnd_Alias
  • 編集手順
    • 実行ユーザー: root
    • 手順: /etc/sudoers を安全に開く
    • 期待結果: デフォルトエディタで開き、保存時に構文チェックが走る
sudo visudo

💡ポイント:
直接編集せずに必ず visudo を利用し、SELinux Enforcing 環境では restorecon も併用してファイルラベルを保持しましょう。

4.5.3 Alias を使った設定の整理

  • 背景・役割
    • User_Alias、Runas_Alias、Host_Alias、Cmnd_Alias を活用し、大規模設定でも可読性と保守性を維持します。
  • Alias 定義例
    • 実行ユーザー: root
    • 手順: /etc/sudoers.d/00_alias を作成して Alias を定義
    • 期待結果: Alias 定義が分割管理され、メインの sudoers を汚さず整理可能
sudo visudo -f /etc/sudoers.d/00_alias
User_Alias    ADMINS    = alice, bob
Runas_Alias   WEB       = root, apache
Cmnd_Alias    WEB_CMDS  = /usr/bin/systemctl {start,stop,restart} httpd

ADMINS    ALL = (WEB)  NOPASSWD: WEB_CMDS

💡ポイント:
Alias 名は大文字かつ説明的に（例：DB_ADMIN_CMDS）命名すると、seo効果も高まりやすくなります。

4.5.4 NOPASSWD を利用したパスワードプロンプト制御

  • 背景・役割
    • 自動化スクリプトやCI/CDでの非対話的実行に対応しつつ、パスワード入力不要の範囲を限定的に許可します。
  • 設定例
    • 実行ユーザー: root
    • 手順: /etc/sudoers.d/10_nopasswd を作成
    • 期待結果: deployer グループのメンバーはパスワード入力なしで指定コマンドを実行可能
sudo visudo -f /etc/sudoers.d/10_nopasswd
%deployer ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

💡ポイント:
NOPASSWD: の乱用はセキュリティリスクにつながるため、必要最小限のコマンドに限定してください。

4.5.5 /etc/sudoers.d による分割管理

  • 背景・役割
    • 部門やサービス単位で設定ファイルを分割し、Gitなどでの差分管理やレビュープロセスを容易にします。
  • 手順
    • 実行ユーザー: root
    • 確認: デフォルトで includedir /etc/sudoers.d が有効
    • ファイル作成: developers 用設定
    • 期待結果: /etc/sudoers.d/developers に限定設定が追加され、本体は変更不要
sudo visudo -f /etc/sudoers.d/developers
%developers ALL=(ALL) ALL

💡ポイント:
ファイル名は英数字とアンダースコアのみ、拡張子は .conf に統一すると運用がスムーズです。

4.5.6 監査ログ収集と外部連携

  • 背景・役割
    • sudo 実行履歴を SIEM やログサーバへ転送し、リアルタイム監視やアラートに活用します。
  • ローカル確認
    • 実行ユーザー: root
    • 手順: 指定期間の sudo ログを表示
    • 期待結果: 期間内の sudo 実行ログ一覧が表示される
sudo journalctl -t sudo --since "2025-05-01" --until "2025-05-05"
  • rsyslog 転送例
    • 実行ユーザー: root
    • 手順: /etc/rsyslog.d/90-sudo.conf を作成
    • 期待結果: sudo ログがリアルタイムで logs.example.com に送信される
cat <<EOF | sudo tee /etc/rsyslog.d/90-sudo.conf
if \$programname == 'sudo' then @@logs.example.com:514
& stop
EOF
sudo systemctl restart rsyslog

💡ポイント:
ログ容量が増大しやすいため、/etc/logrotate.d/secure で適切なローテーション設定を行ってください。

4.5.7 トラブルシューティングとベストプラクティス

  • 構文チェック
    • 実行ユーザー: root
    • 手順: sudoers 全体を検証
    • 期待結果: エラーなく「/etc/sudoers: parsed OK」が表示される
sudo visudo -c
  • 権限確認
    • 実行ユーザー: 一般ユーザー
    • 手順: 自身のsudo権限を確認
    • 期待結果: 許可されているコマンド一覧が表示される
sudo -l
  • 定期レビュー
    • 半期ごとに /etc/sudoers.d 配下も含めた設定を見直し、不要エントリを削除します。

💡ポイント:
Ansible や Puppet など構成管理ツールで sudoers 配下をコード化し、セキュリティ設定を自動化・標準化しましょう。

4.6 パスワードポリシーとアカウント保護

AlmaLinux9 環境でパスワードの有効期限・強度を管理し、総当たり攻撃を防ぐためのアカウントロック機能までを網羅的に解説します。dnf で更新される PAM モジュールや authselect を利用した設定手順を示し、SELinux との連携も含めてセキュリティ設定を強化します。

4.6.1 パスワード有効期限と強度制御（/etc/login.defs）

  • 役割
    • 新規ユーザー作成時にパスワードの最小・最大有効期限や警告開始時期を一括設定し、ポリシーに沿った運用を自動化します。
  • 設定項目
パラメータ目的デフォルト例
PASS_MAX_DAYSパスワードの最大有効日数（これを超えると変更を強制）90
PASS_MIN_DAYSパスワード変更後、再変更可能になるまでの最短日数0
PASS_WARN_AGE失効前の警告開始日数7
  • 手順
    • 実行ユーザー: root
    • 手順: /etc/login.defs を編集
    • 結果: 新規ユーザーは作成後 90 日でパスワード変更を強制され、期限 5 日前から警告メールが届きます。
sudo vi /etc/login.defs

変更例:

PASS_MAX_DAYS   90
PASS_MIN_DAYS   7
PASS_WARN_AGE   5
  • 注意点
    • 既存ユーザーには反映されないため、後述の chage を併用してください。

💡ポイント:
/etc/login.defs の設定は新規ユーザーのみ対象で、既存ユーザーは chage コマンドで個別に調整する必要があります。 (man7.org, Medium)

4.6.2 chage コマンドによる個別ユーザー管理

  • 役割
    • 既存ユーザーのパスワード有効期限や警告日数を即時に変更し、ポリシー変更後の対応を効率化します。
  • 主なオプション
オプション機能
-lユーザーの現在設定を一覧表示
-M 日数最大有効日数を設定
-m 日数最小有効日数を設定
-W 日数警告開始日数を設定
-E YYYY-MM-DDアカウントの有効期限を設定
  • 手順例
    • 実行ユーザー: root
    • 手順: 既存ユーザー alice の期限を 60 日に設定
    • 結果: alice は作成後 60 日目でパスワード変更が必須となり、7 日前から警告が始まります。
sudo chage -M 60 alice
sudo chage -W 7 alice
  • 確認
sudo chage -l alice
  • 期待結果: 最大日数や警告日数が反映された一覧が表示される。

💡ポイント:
chage は既存ユーザーに直接適用され、/etc/login.defs よりも優先されます。ポリシー変更時は全ユーザーへの一括適用スクリプトを用意すると効率的です。 (Medium)

4.6.3 pam_faillock による総当たり攻撃対策

  • 役割
    • 一定回数のログイン失敗でアカウントを一時ロックし、不正アクセスを自動的に防止します。
  • 設定例
    • 実行ユーザー: root
    • 手順: /etc/pam.d/system-auth および /etc/pam.d/password-auth に以下を追加
    • 結果: 5 回失敗でアカウントをロックし、15 分（900 秒）以内に5回以上失敗すると再度ロック、10 分（600 秒）後に自動解除されます。
auth required pam_faillock.so preauth silent deny=5 unlock_time=600 fail_interval=900
auth [default=die] pam_faillock.so authfail deny=5 unlock_time=600 fail_interval=900
account required pam_faillock.so
  • 注意点
    • 直接 PAM ファイルを編集する場合、構文ミスで認証不能となる恐れがあるため注意してください。

💡ポイント:
pam_faillock モジュールは複数エントリが必要で、手動編集ミスが起こりやすいです。ansible など自動化ツールの利用を検討しましょう。 (static.open-scap.org)

4.6.4 authselect を用いた PAM 設定の一元管理

  • 役割
    • authselect で PAM/NSS プロファイルを管理し、pam_faillock 設定を安全に適用・更新します。
  • 手順
    • 実行ユーザー: root
    • 手順: sssd プロファイルに with-faillock 機能を追加
    • 結果: /etc/pam.d/system-auth 等に自動で pam_faillock の設定が反映され、authselect 管理下に置かれます。
sudo authselect select sssd with-faillock
sudo authselect apply-changes
  • メリット
    • 手動編集による構文エラーリスクを低減し、将来のパッチ適用時も一貫した設定を保持できます。

💡ポイント:
authselect で管理すると、個別ファイルへの手動修正がチェックにより失敗するため、必ずプロファイル機能を通じて変更してください。 (Red Hat ドキュメント)

4.7 LDAP と SSSD による集中管理

AlmaLinux9 環境で外部ディレクトリ（LDAP）と連携し、複数サーバーのユーザー情報を一元管理する方法を詳述します。各節で背景・役割・手順を具体的に示し、運用上の注意点やトラブルシューティングも併せて解説します。

4.7.1 LDAP クライアントでの集中認証のメリット

システムごとにローカルユーザーを管理するのではなく、LDAP サーバー上で一元的にユーザー／グループ情報を保持すると、以下の利点があります：

  • 一貫性：UID/GID の重複を回避し、全サーバーで同一のアカウント運用が可能 (Red Hat Customer Portal, Red Hat Customer Portal)
  • メンテナンス効率：ユーザー追加・削除をディレクトリ側で一度行うだけで全ノードに即時反映 (Red Hat Customer Portal, Red Hat Customer Portal)
  • セキュリティ強化：パスワードポリシーや MFA をディレクトリで集中管理し、各サーバーに個別設定不要

💡ポイント: LDAP は読み取り集中型のため、専用レプリカ構成を組むと可用性とパフォーマンスが向上します。

4.7.2 SSSD の役割と主要機能

SSSD（System Security Services Daemon）は、LDAP や Active Directory などの外部ディレクトリを以下のように仲介します：

機能説明
NSS モジュール/etc/nsswitch.conf 経由で LDAP を統合参照
PAM モジュール認証時に LDAP/CAS/Kerberos を使ったログインを実現
オフラインキャッシュネットワーク障害時でも最後に取得した認証情報でログインを継続
セキュリティ機能TLS/SSL 設定、アクセスフィルタ（ldap_access_filter 等）による追加制御

💡ポイント: SSSD は複数ドメインを扱えるため、AD と OpenLDAP を同時に利用するハイブリッド環境にも対応できます。

4.7.3 AlmaLinux9 での SSSD クライアント設定手順

以下の手順で LDAP クライアントとして SSSD を構成します。

1. SSSD パッケージのインストール・起動

# 実行ユーザー: root
sudo dnf install -y sssd
sudo systemctl enable --now sssd
  • 期待結果: sssd サービスが自動起動し、ステータスが active (running) になる (Red Hat Customer Portal)

2. /etc/sssd/sssd.conf の作成

# 実行ユーザー: root
sudo tee /etc/sssd/sssd.conf > /dev/null << 'EOF'
[sssd]
domains = example.com
services = nss, pam

[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
cache_credentials = True
EOF

sudo chmod 600 /etc/sssd/sssd.conf
  • 期待結果: SSSD が指定ドメインを参照し、キャッシュ機能が有効化される (Red Hat Customer Portal)

3. NSS/PAM プロファイルの設定（authselect 推奨）

# 実行ユーザー: root
sudo authselect select sssd --force
sudo authselect enable-feature with-faillock
sudo authselect apply-changes
  • 期待結果: /etc/nsswitch.conf と PAM 設定が自動で更新され、SSSD 経由の認証が有効になる (Red Hat Customer Portal)

4.7.4 TLS/SSL 設定と証明書管理

LDAP 通信を暗号化し、中間者攻撃を防ぎます。

# 実行ユーザー: root
# CA 証明書を配置
sudo cp /path/to/ca.crt /etc/ssl/certs/ldap-ca.crt
sudo chmod 644 /etc/ssl/certs/ldap-ca.crt

# sssd.conf に TLS オプションを追加
sudo tee -a /etc/sssd/sssd.conf > /dev/null << 'EOF'
ldap_tls_cacert = /etc/ssl/certs/ldap-ca.crt
ldap_id_use_start_tls = True
ldap_tls_reqcert = demand
EOF

# SSSD 再起動
sudo systemctl restart sssd

💡ポイント: ldap_tls_reqcert = demand で証明書検証を厳格化し、安全性を最大化します。

4.7.5 キャッシュ管理とパフォーマンス最適化

SSSD のキャッシュ設定を調整し、レスポンス性能とディレクトリ負荷のバランスを取ります。

パラメータ説明推奨値
entry_cache_timeoutエントリキャッシュの有効期間（秒）600
ldap_cache_timeoutLDAP レスポンスキャッシュの有効期間（秒）300
cache_credentials認証情報キャッシュを有効化True
krb5_store_password_if_offlineオフライン時のパスワードキャッシュTrue
# /etc/sssd/sssd.conf の domain セクションに追記
entry_cache_timeout = 600
ldap_cache_timeout = 300
  • 期待結果: ネットワーク障害時でも最後に取得した認証情報でログインでき、通常時はキャッシュヒットにより高速レスポンスを実現 (Red Hat Customer Portal, Red Hat Customer Portal)

💡ポイント: キャッシュ期間を短くすると最新情報反映が早くなりますが、LDAP への問い合わせが増加するため注意してください。

4.7.6 トラブルシューティングとベストプラクティス

  • ログ確認 
# 実行ユーザー: root
sudo tail -F /var/log/sssd/sssd.log \
            /var/log/sssd/sssd_LDAP.log
  • アクセスフィルタ (ldap_access_filter) 
# domain セクションにユーザー絞り込みを追加
ldap_access_filter = (&(objectClass=person)(memberOf=cn=staff,ou=Groups,dc=example,dc=com))
  • ドメイン解決順序 (domain_resolution_order)
    • 期待結果: 優先ドメインを先に問い合わせ、AD フォレスト環境での認証精度を向上 (Red Hat Customer Portal)
domain_resolution_order = child.example.com,example.com

💡ポイント:
定期的に SSSD のログローテーションとディレクトリ健全性を確認し、LDAP サーバーの負荷状況も監視する運用を推奨します。

4.8 学習のまとめ

本章では、AlmaLinux9 環境におけるユーザー／グループ管理の基盤から高度な運用テクニックまでを解説しました。以下に各節の要点を振り返り、運用における重要ポイントを詳述します。

  1. 基盤ファイルによる認証情報管理
    • /etc/passwd・/etc/shadow・/etc/group・/etc/gshadow でユーザー・グループ情報を一元管理。
    • 💡ポイント: パスワードハッシュ（/etc/shadow）やグループパスワード（/etc/gshadow）は root のみアクセス可能にし、SELinux コンテキストも常に restorecon で整合性確認。
  2. ユーザー操作コマンドの高度活用
    • useradd：システムアカウントの -r、カスタムスケルトンの -k、デフォルト設定の -K で柔軟に新規ユーザーを作成。
    • usermod：-aG 併用による補助グループ追加、-e で有効期限設定、-L/-U でロック制御。
    • userdel：事前ロック＋ホームアーカイブ＋-r 実行で安全に削除。
    • 💡ポイント: 本番環境では必ずバックアップと影響範囲確認を実施し、dnf 更新後の shadow-utils 仕様変更にも注意。
  3. グループ管理とアクセス制御
    • groupadd／groupmod／groupdel でセキュリティグループを適切に設計・運用。
    • プライマリ vs 補助グループの役割分担でファイル所有権を明確化。
    • setgid ビットや ACL で共同ディレクトリを構築し、細粒度のアクセス制御も実現。
    • 💡ポイント: ファイルパーミッション（770、2770 等）だけでなく、umask や SELinux ラベルも含めて総合的にセキュリティ設定を強化。
  4. sudo の細かな調整と監査
    • visudo + Cmnd_Alias／User_Alias で可読性を維持しつつ、最小権限付与を徹底。
    • NOPASSWD: は自動化用途に限定し、パスワードレス実行を最小化。
    • /etc/sudoers.d でファイル分割管理し、Git 連携やレビューを容易化。
    • ログは /var/log/secure／journalctl -t sudo、外部SIEM連携でリアルタイム監視。
    • 💡ポイント: 半期ごとに sudo -l／visudo -c で設定レビューを行い、意図しない権限付与を排除。
  5. パスワードポリシーとアカウント保護
    • /etc/login.defs で PASS_MAX_DAYS／PASS_MIN_LEN／PASS_WARN_AGE を一括管理。
    • chage で既存ユーザーの有効期限／警告日を即時更新。
    • pam_faillock と authselect で総当たり攻撃を自動ロックし、unlock_time／deny を運用ポリシーに調整。
    • 💡ポイント: PAM 設定は自動化ツールで管理し、SELinux Enforcing 下でも認証フローをテストしておく。
  6. LDAP／SSSD による集中認証管理
    • SSSD を通じて LDAP（OpenLDAP／AD）と NSS/PAM を統合し、一貫した UID/GID ポリシーを実現。
    • TLS 証明書検証（ldap_tls_reqcert = demand）を必須化し、安全な通信を担保。
    • キャッシュ設定（entry_cache_timeout 等）でパフォーマンスと可用性を最適化。
    • 💡ポイント: 定期的に /var/log/sssd/*.log を監視し、アクセスフィルタやドメイン解決順序を運用に合わせて調整。

全体を通したベストプラクティス

  • 一貫性と自動化：authselect、Ansible/Puppet などの構成管理ツールを活用し、手動ミスを排除。
  • 定期監査：権限設定（ファイル・sudo・PAM・SSSD）をスクリプト化して定期的にチェックし、不要設定を削除。
  • セキュリティ重視：最小権限、SELinux、TLS、ログ監査を組み合わせ、AlmaLinux9 のセキュリティ設定を多層で強化。

このまとめを踏まえ、AlmaLinux9 環境でのユーザー／グループ運用を安全かつ効率的に実践してください。

4.9 さらなる学習リソース

AlmaLinux9 環境でのユーザー／グループ管理、dnf 運用、SELinux やセキュリティ設定をさらに深く学ぶための主要リソースをまとめました。公式ドキュメントからチュートリアル、オンラインコースまで幅広くカバーしています。

💡ポイント: これらのリソースを活用し、AlmaLinux9 のユーザー／グループ管理、dnf 運用、SELinux 設定、セキュリティ設定を体系的にマスターしましょう。

スポンサーリンク