Linuxプロセスセキュリティとシステムログ解析のアーキテクチャ設計

Fri, 29 May 2026 09:40:32 +0900

Linuxプロセスセキュリティとログ解析アーキテクチャの技術的考察

Linuxシステムにおけるセキュリティの核心は、静的なファイル権限の管理を超え、実行中のプロセスの振る舞いをいかに制御し、監視するかにあります。本稿では、プロセスのアイデンティティ、隔離技術、およびフォレンジックに不可欠なログ解析アーキテクチャについて、実務的な観点から技術分析を行います。

1. プロセスセキュリティの定義と境界

プロセスは、ディスク上の静止したデータであるファイルとは異なり、RAM上で実行されている動的な実体です。従来のファイルパーミッションだけでは、以下の脅威を防ぐことは困難です。

ファイルレスマルウェア: ディスクに痕跡を残さず、メモリ内でのみ動作する攻撃コード。
リモートコード実行 (RCE): 認可されたプログラムの脆弱性を突き、攻撃者が意図しないコマンドを実行させる手法。

これらに対抗するため、プロセスセキュリティは隔離（Isolation）、監視（Monitoring）、検知（Detection）の3つの柱で構成されます。

2. プロセスの識別子と権限モデル

Linuxカーネルは、各プロセスに特定の識別子を付与し、リソースへのアクセスを制御します。

PID (Process ID): システム全体で一意の番号。ブート時に最初に実行される systemd (PID 1) を頂点としたツリー構造を形成します。
PPID (Parent PID): 親プロセスのID。例えば、Webサーバー (nginx) が /bin/bash を生成した場合、不自然なPPIDの関係からRCEの可能性を疑う重要な指標となります。
UID/GID (User/Group ID): プロセスがどのユーザー権限で動作しているかを示します。最小権限の原則に基づき、root 権限での実行を最小限に抑えることが基本です。

RUIDとEUIDの分離メカニズム

SUID (Set-user-ID) ビットが設定されたバイナリの動作を理解するには、RUIDとEUIDの区別が不可欠です。RUID (Real UID) はプロセスを開始した実際のユーザーIDであり、EUID (Effective UID) はプロセスが実行中に実際に行使する権限を決定するIDです。攻撃者はこの仕組みを悪用して権限昇格を狙うため、システム内のSUIDバイナリの監査は必須です。

# システム内のSUIDバイナリを検索し、権限昇格のリスクを特定する
find / -perm -4000 -type f 2&gt;/dev/null

3. カーネルレベルの隔離技術：Namespacesとcgroups

コンテナ技術の基盤でもあるこれらの機能は、プロセス間の干渉を物理的に遮断します。

Namespaces (名前空間)

カーネルリソースを論理的に分割し、プロセスごとに異なるリソースセットを見せます。

Network Namespace: 独立したネットワークインターフェース、IP、ルーティングテーブルを提供。
Mount Namespace: ファイルシステム階層を隔離。
PID Namespace: コンテナ内のプロセスに独自のPID 1を割り当て。
User Namespace: ホスト側の一般ユーザーを、コンテナ内でのみ root として扱うことが可能。

cgroups (Control Groups)

Namespacesが「何が見えるか」を制御するのに対し、cgroupsは「どれだけ使えるか」を制御します。CPU使用率、メモリ量、ネットワーク帯域を制限することで、特定のプロセスによるリソース枯渇（DoS状態）を防止します。

4. 不審なプロセスの検知手法

異常な挙動を示すプロセスを特定するためのチェックリストを以下に示します。

マスカレード: kworker や syslogd といった正規のプロセス名に偽装したバイナリ。
異常な実行パス: /tmp, /dev/shm, /var/tmp といった書き込み権限の広いディレクトリから実行されているプロセス。
削除済みバイナリの実行: ディスク上から削除された後もメモリ上で動作し続けているプロセス。

# 実行中に削除された不審なバイナリを特定する
ls -al /proc/*/exe | grep deleted

不審なネットワーク接続: ss -tulnp を使用し、未知の外部IPアドレスと通信しているプロセスを特定します。

5. ログ解析アーキテクチャの設計

インシデント発生時のブラックボックス化を防ぐため、ログには網羅性と不変性が求められます。

journald (systemd-journald)

モダンなLinuxの標準ロガーであり、バイナリ形式でログを保存します。テキストベースのログよりも高速なインデックス検索が可能です。

# 特定のサービスにおけるエラーログを抽出
journalctl -u sshd.service -p err

auditd (Linux Audit Framework)

auditdはカーネルレベルでシステムコールをインターセプトします。これにより、攻撃者がログ出力を抑制しようとしても回避困難な記録を残せます。💡 実行ファイルへのアクセスやシステムコールの監視に極めて有効です。

# 実行されたすべてのコマンド（execveシステムコール）を監査するルールの確認
auditctl -l

6. Windowsイベントログの重要ID

マルチプラットフォーム環境では、Windowsのイベントログ構造の理解も不可欠です。特に以下のEvent IDはセキュリティ監視の要となります。

4624: ログオン成功（Logon Type 3はネットワーク、10はRDPを指す）。
4688: 新しいプロセスの作成（デフォルトでは無効なため、グループポリシーでの有効化が必要）。
4732: 管理者グループへのメンバー追加。

Operational Notes 🛠️

実務運用において、ログの有効性を担保するための留意事項をまとめます。

ログの外部転送: 攻撃者が root 権限を奪取した場合、ローカルログは即座に改ざん・消去されます。rsyslog のTCP転送やSIEMへのリアルタイム転送を構成し、ログの不変性を確保してください。
時刻同期 (NTP): 複数サーバー間のログを相関分析する際、1秒のズレがタイムラインの再構築を不可能にします。全ノードでUTC設定と厳密な時刻同期を行ってください。
auditdのルール設計: ルールを定義しない auditd は、セキュリティ上の価値がほとんどありません。重要な設定ファイル（/etc/passwd, /etc/sudoers）や実行バイナリに対する監視ルールを明示的に設定してください。
ディスク容量の監視: ⚠️ auditd はディスクが満杯になった際、設定によってはシステムを停止（Halt）させることがあります。ログローテーションポリシーとディスククォータの設計を事前に行う必要があります。

Ruid-Euid on K-Life Hack | システムアーキテクチャ & DevOps