はじめに：なぜLinuxサーバのアカウント・権限管理監査が重要なのか

Linuxサーバは、企業のWebサービス基盤やデータベースサーバ、社内システムのインフラとして広く利用されています。その一方で、適切なアカウント管理と権限設定が行われていないLinuxサーバは、内部不正や外部からのサイバー攻撃の格好の標的となります。

実際、IPA（情報処理推進機構）の調査によると、情報セキュリティインシデントの約40%が内部者による不正アクセスや権限の悪用に起因しているとされています。また、CVE（共通脆弱性識別子）データベースに登録される脆弱性の多くは、不適切な権限設定を悪用するものです。

本記事では、IT監査担当者やセキュリティ実務者向けに、Linuxサーバのアカウント・権限管理を監査する際の具体的なチェックポイントを解説します。監査手順書の作成や実際の監査作業に役立つコマンド例も豊富に紹介しますので、ぜひ実務にお役立てください。

背景・概要：Linuxにおけるアカウント・権限管理の基本

Linuxのアカウント管理の仕組み

Linuxでは、すべてのユーザーに一意のユーザーID（UID）が割り当てられます。アカウント情報は主に以下のファイルで管理されています。

• /etc/passwd：ユーザーアカウントの基本情報（ユーザー名、UID、GID、ホームディレクトリ、ログインシェルなど）
• /etc/shadow：パスワードのハッシュ値やパスワード有効期限などの認証情報
• /etc/group：グループ情報とグループに所属するユーザー一覧
• /etc/gshadow：グループパスワードの情報

権限管理の基本概念

Linuxでは、ファイルやディレクトリに対して「所有者（owner）」「グループ（group）」「その他（others）」の3つのカテゴリごとに「読み取り（r）」「書き込み（w）」「実行（x）」の権限を設定できます。これを「パーミッション」と呼びます。

また、特殊な権限として以下の3つがあります。

• SUID（Set User ID）：実行時に所有者の権限で動作
• SGID（Set Group ID）：実行時にグループの権限で動作
• Sticky Bit：ディレクトリ内のファイル削除を所有者のみに制限

これらの設定が不適切な場合、権限昇格（Privilege Escalation）攻撃の対象となる可能性があります。

監査の目的と観点

Linuxサーバの監査では、以下の観点から確認を行います。

1. 完全性（Integrity）：不正なアカウントや設定変更がないか
2. 機密性（Confidentiality）：機密情報へのアクセスが適切に制限されているか
3. 可用性（Availability）：正当なユーザーが必要なリソースにアクセスできるか
4. 説明責任（Accountability）：操作履歴の追跡が可能か

具体的なチェックポイント

チェックポイント1：不要なアカウント・無効化すべきアカウントの特定

監査の目的

使用されていない古いアカウントや、本来無効化すべきシステムアカウントが放置されていると、攻撃者に悪用されるリスクがあります。退職者のアカウントが残っているケースは非常に多く、これが内部不正の温床になることもあります。

確認コマンドと手順

全ユーザー一覧の取得

# /etc/passwdの内容を確認
cat /etc/passwd

# ユーザー名のみを抽出
cut -d: -f1 /etc/passwd

ログイン可能なアカウントの特定

# ログインシェルが/bin/bash、/bin/sh等のアカウントを抽出
grep -v -E "nologin|false" /etc/passwd

最終ログイン日時の確認

# 各ユーザーの最終ログイン情報
lastlog

# 90日以上ログインのないアカウントを抽出
lastlog -b 90

パスワード期限情報の確認

# 特定ユーザーのパスワード情報
chage -l username

# 全ユーザーのパスワード有効期限を一括確認
for user in $(cut -d: -f1 /etc/passwd); do echo "=== $user ==="; chage -l $user 2>/dev/null; done

実務上のチェックポイント

チェックポイント2：root権限の管理とsudo設定の監査

監査の目的

root（UID=0）は Linuxシステムにおける最高権限であり、その管理が不適切だとシステム全体が危険にさらされます。直接rootログインを禁止し、sudo経由で必要最小限の権限を付与する「最小権限の原則（Principle of Least Privilege）」の実装状況を確認します。

確認コマンドと手順

UID=0のアカウント確認

# UIDが0のアカウントを検索（rootのみであるべき）
awk -F: '$3 == 0 {print $1}' /etc/passwd

通常、結果は「root」のみであるべきです。それ以外のアカウントがUID=0を持っている場合は重大な問題です。

sudoersファイルの確認

# sudoersの内容確認（visudoで編集するのが基本）
cat /etc/sudoers

# /etc/sudoers.d/配下の追加設定も確認
ls -la /etc/sudoers.d/
cat /etc/sudoers.d/*

危険なsudo設定の検出

# NOPASSWDが設定されているエントリ
grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# ALL権限が付与されているエントリ
grep -r "ALL=(ALL)" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

sudo実行履歴の確認

# sudo実行ログの確認（ディストリビューションにより異なる）
grep sudo /var/log/auth.log      # Debian/Ubuntu系
grep sudo /var/log/secure        # RHEL/CentOS系

監査で指摘すべき問題例

# 危険な設定例1：全ユーザーに全権限をパスワードなしで許可
ALL ALL=(ALL) NOPASSWD: ALL

# 危険な設定例2：特定ユーザーに無制限のsudo権限
username ALL=(ALL:ALL) ALL

# 推奨される設定例：必要なコマンドのみを許可
%webadmin ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

チェックポイント3：パスワードポリシーの設定状況

監査の目的

脆弱なパスワードは、ブルートフォース攻撃（総当たり攻撃）やパスワードスプレー攻撃の標的になります。組織のセキュリティポリシーに沿ったパスワード要件が技術的に強制されているかを確認します。

確認コマンドと手順

PAM（Pluggable Authentication Modules）設定の確認

# パスワード品質設定（RHEL/CentOS系）
cat /etc/security/pwquality.conf

# PAM設定ファイルの確認
cat /etc/pam.d/system-auth
cat /etc/pam.d/password-auth
cat /etc/pam.d/common-password  # Debian/Ubuntu系

ログイン制御設定の確認

# /etc/login.defs の設定確認
cat /etc/login.defs | grep -E "^PASS_|^LOGIN_|^FAIL_"

推奨されるパスワードポリシー設定

/etc/login.defs の推奨設定

PASS_MAX_DAYS   90      # パスワード最大有効期間
PASS_MIN_DAYS   1       # パスワード変更後の最小期間
PASS_MIN_LEN    12      # パスワード最小文字数
PASS_WARN_AGE   14      # パスワード期限切れ警告日数
LOGIN_RETRIES   3       # ログイン試行回数
LOGIN_TIMEOUT   60      # ログインタイムアウト（秒）

/etc/security/pwquality.conf の推奨設定

minlen = 12             # 最小文字数
dcredit = -1            # 数字を最低1文字要求
ucredit = -1            # 大文字を最低1文字要求
lcredit = -1            # 小文字を最低1文字要求
ocredit = -1            # 記号を最低1文字要求
maxrepeat = 3           # 同一文字の連続を3回まで
difok = 5               # 前回と異なる文字数

チェックポイント4：重要ファイルのパーミッション確認

監査の目的

システムの重要ファイルに不適切なパーミッションが設定されていると、情報漏洩や設定改ざんのリスクがあります。特に認証関連ファイルや設定ファイルは厳格な権限管理が必要です。

確認コマンドと手順

重要ファイルのパーミッション一括確認

# 認証関連ファイル
ls -la /etc/passwd /etc/shadow /etc/group /etc/gshadow

# SSH関連
ls -la /etc/ssh/sshd_config
ls -la ~/.ssh/

# sudo関連
ls -la /etc/sudoers

重要ファイルの適切なパーミッション一覧

一括チェックスクリプト例

#!/bin/bash
echo "=== 重要ファイルのパーミッション監査 ==="

check_perm() {
    file=$1
    expected=$2
    actual=$(stat -c "%a" "$file" 2>/dev/null)
    if [ "$actual" = "$expected" ]; then
        echo "[OK] $file: $actual"
    else
        echo "[NG] $file: $actual (expected: $expected)"
    fi
}

check_perm "/etc/passwd" "644"
check_perm "/etc/shadow" "640"
check_perm "/etc/group" "644"
check_perm "/etc/sudoers" "440"
check_perm "/etc/ssh/sshd_config" "600"

チェックポイント5：SUIDとSGID設定ファイルの監査

監査の目的

SUIDやSGIDが設定された実行ファイルは、実行時に所有者やグループの権限で動作します。これらが不正に利用されると、一般ユーザーがroot権限を取得できてしまう「権限昇格」攻撃が成立します。

確認コマンドと手順

SUID/SGIDファイルの検索

# SUIDビットが設定されたファイルを検索
find / -perm -4000 -type f 2>/dev/null

# SGIDビットが設定されたファイルを検索
find / -perm -2000 -type f 2>/dev/null

# SUID/SGID両方を検索
find / -perm /6000 -type f 2>/dev/null

# 所有者情報も含めて詳細表示
find / -perm /6000 -type f -exec ls -la {} \; 2>/dev/null

一般的に許容されるSUIDファイル

以下は多くのLinuxシステムで標準的にSUIDが設定されているファイルです。

/usr/bin/passwd
/usr/bin/sudo
/usr/bin/su
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/mount
/usr/bin/umount
/usr/bin/ping

監査時の注意点

1. ベースラインとの比較：初期構築時のSUID/SGIDファイル一覧を保存しておき、監査時に差分を確認
2. 不審なファイル：ユーザーのホームディレクトリや/tmpにSUIDファイルがある場合は要注意
3. カスタムスクリプト：組織独自のスクリプトにSUIDが設定されている場合は正当性を確認

# ベースラインとの差分確認例
find / -perm /6000 -type f 2>/dev/null | sort > /tmp/suid_current.txt
diff /opt/audit/baseline/suid_baseline.txt /tmp/suid_current.txt

チェックポイント6：SSH認証設定の監査

監査の目的

SSHはLinuxサーバへのリモートアクセスの標準プロトコルです。設定が不適切な場合、ブルートフォース攻撃や不正アクセスのリスクが高まります。

確認コマンドと手順

sshd_configの確認

# SSH設定ファイルの確認
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

# 重要な設定項目の抽出
grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication|PermitEmptyPasswords|MaxAuthTries|Protocol|AllowUsers|AllowGroups)" /etc/ssh/sshd_config

SSHログイン履歴の確認

# 成功したログイン
grep "Accepted" /var/log/auth.log | tail -20

# 失敗したログイン
grep "Failed" /var/log/auth.log | tail -20

# 不正なユーザーでのアクセス試行
grep "Invalid user" /var/log/auth.log | tail -20

推奨されるsshd_config設定

# SSHプロトコルバージョン
Protocol 2

# rootログイン禁止
PermitRootLogin no

# 公開鍵認証を有効化
PubkeyAuthentication yes

# パスワード認証の無効化（公開鍵認証のみ）
PasswordAuthentication no

# 空パスワードを禁止
PermitEmptyPasswords no

# 認証試行回数の制限
MaxAuthTries 3

# ログイン猶予時間
LoginGraceTime 30

# アクセス許可するユーザー/グループを限定
AllowGroups sshusers

# X11フォワーディングの無効化（不要な場合）
X11Forwarding no

チェックポイント7：グループ管理とアクセス制御

監査の目的

Linuxではグループを使って効率的にアクセス権を管理できます。しかし、グループ設計が不適切だと、意図しないユーザーに機密情報へのアクセス権が付与されてしまいます。

確認コマンドと手順

グループ一覧とメンバーの確認

# グループ一覧
cat /etc/group

# 特定ユーザーが所属するグループ
groups username
id username

# 特定グループに所属するユーザー
getent group groupname

特権グループの確認

# wheel/sudoグループのメンバー（sudo権限を持つ可能性）
getent group wheel
getent group sudo

# root グループのメンバー
getent group root

# admin グループのメンバー
getent group admin

注意すべき特権グループ

チェックポイント8：監査ログ（auditd）の設定確認

監査の目的

auditd は Linux の監査フレームワークで、システムイベントを詳細に記録できます。インシデント発生時の調査や、不正操作の検知に不可欠です。

確認コマンドと手順

auditdの稼働確認

# auditdのステータス確認
systemctl status auditd

# auditdサービスが有効か確認
systemctl is-enabled auditd

監査ルールの確認

# 現在の監査ルールを表示
auditctl -l

# 監査ルールファイルの確認
cat /etc/audit/rules.d/audit.rules
cat /etc/audit/audit.rules

監査ログの確認

# 監査ログの確認
ausearch -m USER_LOGIN -ts today

# 特定ファイルへのアクセス履歴
ausearch -f /etc/passwd

# sudo実行の履歴
ausearch -m USER_CMD

推奨される監査ルール例

# /etc/audit/rules.d/audit.rules

# 認証関連ファイルの監視
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k sudoers

# ログインイベントの監視
-w /var/log/lastlog -p wa -k logins
-w /var/log/faillog -p wa -k logins

# sudoコマンドの監視
-w /usr/bin/sudo -p x -k sudo_usage

# システム設定変更の監視
-w /etc/sysctl.conf -p wa -k sysctl
-w /etc/ssh/sshd_config -p wa -k sshd_config

よくある質問（FAQ）

Q1：監査の頻度はどのくらいが適切ですか？

A1： 監査の頻度は、システムの重要度やリスクレベルによって異なりますが、一般的な目安は以下のとおりです。

• 重要度が高いシステム（本番環境、顧客データを扱うサーバ）：月次監査 + リアルタイム監視
• 標準的なシステム：四半期ごとの定期監査
• 開発・テスト環境：半年ごとの監査

また、以下のタイミングでは臨時監査を実施することをお勧めします。

• 大規模なシステム変更後
• セキュリティインシデント発生後
• 組織変更（人員の異動・退職）後
• 新たな脆弱性情報が公開された後

自動化ツール（Lynis、OpenSCAP、AIDE等）を活用すれば、日次の自動チェックも可能です。

Q2：監査で問題が見つかった場合、どのように優先順位をつけて対応すべきですか？

A2： 発見された問題は、リスクベースで優先順位付けを行います。以下のマトリクスを参考にしてください。

すべての問題を一度に解決しようとせず、まず緊急・高優先度の項目に集中し、その後計画的に中・低優先度の改善を進めることが重要です。

Q3：監査結果をどのように報告・ドキュメント化すべきですか？

A3： 監査報告書には以下の要素を含めることをお勧めします。

1. エグゼクティブサマリー（経営層向け）

• 監査期間と対象範囲
• 重要な発見事項のサマリー（件数と深刻度）
• 全体的なリスク評価（高・中・低）
• 推奨アクションの概要

2. 詳細な発見事項 各項目について以下を記載します。

• 発見事項の説明
• 確認に使用したコマンドと結果のエビデンス
• リスク評価と想定される影響
• 推奨される改善策
• 対応期限と担当者

3. 確認済みの準拠項目 問題がなかった項目も記録し、監査の網羅性を示します。

4. 参考資料

• 使用した監査基準（CIS Benchmarks、NIST等）
• 前回監査からの改善状況
• 次回監査に向けた推奨事項

報告書は、監査対象サーバのスナップショット、コマンド実行結果のログファイル、スクリーンショットとともにアーカイブし、最低3年間は保管することをお勧めします。

まとめ：効果的なLinuxサーバ監査のために

本記事では、Linuxサーバのアカウント・権限管理に関する8つの主要なチェックポイントを解説しました。

1. 不要なアカウント・無効化すべきアカウントの特定
2. root権限の管理とsudo設定の監査
3. パスワードポリシーの設定状況
4. 重要ファイルのパーミッション確認
5. SUIDとSGID設定ファイルの監査
6. SSH認証設定の監査
7. グループ管理とアクセス制御
8. 監査ログ（auditd）の設定確認

監査を成功させるための3つのポイント

1. ベースラインを確立する 初期構築時やセキュリティ強化後の状態を「正常な状態」として記録し、その後の監査で差分を検出できるようにしましょう。

2. 自動化を活用する 定型的なチェックはスクリプト化やツール（Lynis、OpenSCAP）を活用して自動化し、人的ミスを防ぎつつ監査頻度を高めましょう。

3. 継続的な改善サイクルを回す 監査は一度きりのイベントではなく、PDCA サイクルの一部として位置づけ、発見した問題を改善し、再発防止策を講じる継続的なプロセスとして実施しましょう。

Linuxサーバのセキュリティは、日々の運用と定期的な監査の両輪で維持されます。本記事で紹介したコマンドやチェックリストを活用し、組織のセキュリティレベル向上に役立てていただければ幸いです。

本記事は一般的な監査手法を解説したものであり、実際の監査では組織のセキュリティポリシーや規制要件に応じた調整が必要です。