【Linux講座】インフラエンジニア必見のシステム管理とアカウントロック解除！管理編（第2回）

前回の「基礎編」では、黒い画面の恐怖を消し去るフォルダ構成や、実務で必須となる15個の基本コマンド、そして「作業前には必ずバックアップを取る」という現場の黄金ルーティンを解説しました。

まだ基礎編を読んでいない方は先にそちらを確認し、まずはLinuxの基本操作をマスターしてみてください。

基本の操作をマスターしたあなた。第2回となる今回は、いよいよ本格的な「システム管理と権限」のフェーズへ進みます。

インフラエンジニアとして現場に配属されると、単にファイルを操作するだけでなく、「メンバーのアカウントを作る」「止まってしまったWebサービスを再起動する」といった、サーバーそのものを管理する業務がスタートします。

しかし、ここには一歩間違えるとシステム全体を危険に晒す、あるいは大障害を引き起こす「権限の罠」がたくさん潜んでいます。今回も、大企業のインフラを支える現場のガチ運用とやらかしエピソードを交えながら、本番環境で絶対に怒られないためのシステム管理術をじっくり解説します！

rootユーザーの役割と安全な権限切り替え（su・sudoコマンドの違い）

Linuxの世界には、すべてのルールを無視して、どんな操作でも実行できてしまう特別なユーザーが存在します。それが root です。

rootユーザーとは「何でもできる神の権限」

Windowsでいう「管理者」にあたりますが、Linuxのroot権限の強大さはその比ではありません。システム上にある重要なファイルを一瞬で全消去することも、動いているシステムを強制停止させることも自由自在です。

そのため、現場では「普段の作業は権限の制限された一般ユーザーで行い、必要なときだけroot権限を借りる」のが鉄則となっています。権限を切り替えるには、以下の2つの方法を使い分けます。

su コマンド

ユーザーを完全に切り替えるコマンドです。後ろに - をつけると、rootユーザーの環境変数を引き継いで完全に切り替えます。切り替えにはroot自身のパスワードが必要です。

# 一般ユーザーからrootユーザーに切り替える
$ su -
Password: （ここでrootのパスワードを入力）

# プロンプトの末尾が「$」から「#」に変われば、root権限になった証拠
[root@web-server-01 ~]# pwd
/root

# ログアウトして元のユーザーに戻るには exit を入力
[root@web-server-01 ~]# exit
logout
$

sudo コマンド

「一般ユーザーのままで、特定のコマンドだけroot権限で実行する」という、現場で最も推奨されるコマンドです。実行には「自分自身のパスワード」を使います。

# 一般ユーザーのまま、rootしか見られない設定ファイルを開こうとすると拒否される
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

# sudoを先頭につけて実行する
$ sudo cat /etc/shadow
[sudo] password for mocchii: （自分のパスワードを入力）
root:$6$vX...:19842:0:99999:7::: （中身が表示される）

業界基準：大企業のガチの特権アクセス管理（PAM）

実際のエンタープライズの本番環境では、su や sudo を自由に叩ける状態にはなっていません。多くの大手現場では PAM（特権アクセス管理ソフト） が導入されています。 障害対応などの緊急時を除き、このPAMを経由しなければ本番サーバーへのアクセスすら許されません。ログインするためには、事前に「どのサーバーで何の作業をするか」の申請を出し、上長の承認を得る必要があります。

さらに、実行したすべての操作ログは、リアルタイムで一元管理マネージャーへ転送されています。これにより、セキュリティインシデント発生時の完全なトレーサビリティを担保しているのです。プロの現場のセキュリティは、ここまで徹底されています。

運用保守の定番！ユーザー管理とアカウントロック解除方法（faillock）

運用保守チームに配属された新人が、最初によく任されるタスクが「ユーザーアカウントの管理」と「ログインできないトラブルの解消」です。

Linuxのユーザーを確認する /etc/passwd

Linuxにどんなユーザーが存在するかは、すべて /etc/passwd というファイルに記録されています。

# ユーザー一覧を確認してみる
$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
mocchii:x:1001:1001::/home/mocchii:/bin/bash

新しいユーザーを作る、パスワードを設定する操作は以下のコマンドで行います。

# 「testuser」という新しいアカウントを作成する
$ sudo useradd testuser

# testuserのパスワードを設定する
$ sudo passwd testuser
Changing password for user testuser.
New password: （パスワードを入力）
Retype new password: （再入力）
passwd: all authentication tokens updated successfully.

アカウントロック状態の確認と解除（faillock）

セキュリティ対策として「パスワードを5回連続で間違えるとロックがかかる」という運用が一般的です。開発チームやベンダーから「ログインできなくなった！」と泣きつかれたら、faillock コマンドの出番です。

# testuserのロック状態を確認する
$ sudo faillock --user testuser
testuser:
2026-06-09 23:10:15  192.168.1.50  ssh  V  (Failure)

# ロックされていることを確認したら、以下のコマンドでリセット（解除）します
$ sudo faillock --user testuser --reset

# もう一度確認して、履歴が消えていれば解除成功です
$ sudo faillock --user testuser
testuser:

現場あるある：アカウントロック原因の第1位は？

開発チームから「なぜかアカウントがロックされてしまう」と依頼が来る原因で最も多いのは、人間の入力ミスではなく**「自動バッチのパスワード変更漏れ」**です。

システム間で定期実行されているデータ転送バッチなどに古いパスワードが埋め込まれたままになっており、定期的なパスワード変更が行われた瞬間、そのバッチが裏で古い情報を使って自動ログインを試行。一瞬で5回以上のミスペアを叩き出し、アカウントロックを引き起こしてしまうのです。「バッチのパスワード変更忘れがないか」を疑うのが、インフラエンジニアの知恵です。

伝説の修羅場：rootのパスワードを忘れたらどうする？

滅多にあってはならないことですが、もし誰もrootのパスワードが分からなくなったらどうするか。過去に私もこの状況に直面したことがあります。

その際の解決策が、サーバーの起動時にOSの核心に直接アクセスする**「シングルユーザーモード」**での強制起動です。サーバーを再起動し、起動メニュー（GRUB）からカーネルのパラメータを書き換えて、パスワード入力なしの最小構成で起動させます。そこから passwd root を実行してrootのパスワードを強制変更し、九死に一生を得ました。インフラエンジニアの最後の切り札として、頭の片隅に置いておいてください。

403エラーを防ぐパーミッションの仕組みとchmod・chownコマンド

「新しく作ったWebサイトが 403 Forbidden というエラーで表示されない！」 開発チームが慌ててあなたのところに駆け込んできました。原因の9割は、このパーミッションの設定ミスです。

ls -l で権限（パーミッション）の状態を読み解く

$ ls -l index.html
-rw-r--r--. 1 root root 25 Jun  9 20:00 index.html

一番左にある -rw-r--r-- という暗号が、パーミッションを表しています。

• 最初の1文字： - は普通のファイル、dr ならディレクトリ。
• 次の3文字（rw-）： 所有者の権限。「読み込み（r）」と「書き込み（w）」ができる。
• 真ん中の3文字（r--）： 所有グループの権限。「読み込み（r）」だけができる。
• 最後の3文字（r--）： その他大勢の権限。世界中の誰でも「読み込み（r）」だけができる。

これを数字に変換して管理することもよくあります。r=4、w=2、x=1 として足し算します。 つまり、rw- は 4+2=6、r-- は 4+0=4 なので、このファイルの権限は数字で表すと 644 になります。

権限と所有者を変えるツール（chmod, chown）

Webサーバーがこのファイルを読み込んで画面に表示するためには、Webサーバーのプログラム（その他大勢）に r の権限がついていなければなりません。これを修正するために、以下のコマンドを使います。

# パーミッションを「644」に変更する
$ sudo chmod 644 index.html

# ファイルの所有者を root から nginx ユーザーに変更する
$ sudo chown nginx:nginx index.html

デフォルトの権限を決める umask

新しくファイルを作ったとき、最初から付いている権限の初期値を決めているのが umask です。

# 現在のumask値を調べる
$ umask
0022

これは「本来の最大権限（ファイルなら666）から、022を引き算した権限（644）で新しいファイルを作りますよ」という裏方のルールです。

恐怖の失敗談：「とりあえず777」にした結果、ログインできない状態に

権限エラーに悩まされた開発担当者が、「一番権限の緩い設定にすれば問題でないだろう」と、設定ファイルの権限をとりあえず「777（全員何でもできる状態）」に変更したことがありました。

これが地獄の始まりでした。なんと、そのファイルはセキュリティの要である「PAMの設定ファイル」だったのです。Linuxシステムは非常に賢いため、「こんな誰でも書き換えられる危険なセキュリティファイルは信用できない」と自動的に判断し、その瞬間からそのサーバーへのログインを一切拒否する状態に陥りました。

権限を緩くすれば解決するというのは大きな間違いです。セキュリティが高い重要ファイルほど、権限が緩すぎるとOSから拒絶されます。権限設定の変更は、十分に検討して慎重に行うべきである、という強烈な教訓です。

サーバーの負荷を監視するプロセス管理とsystemctlによるサービス制御

サーバーの動きが何だか重い。そんなとき、サーバーの内部で今どんなプログラム（プロセス）が動いていて、誰が悲鳴を上げているかを突き止める必要があります。

top コマンド

サーバーのCPUやメモリの消費量をリアルタイムに監視するモニターです。

$ top
# 画面全体にリアルタイムで負荷状況が表示されます。終了は「q」キー。

ps コマンド

今動いているプロセスを一覧表示します。実務では aux オプションと grep をセットで使います。

$ ps aux | grep nginx
root      1234  0.0  0.1  12345  2345 ?        Ss   20:00   0:00 nginx: master process

ここで表示される「1234」などの数字はプロセスID（PID）といい、プログラムの識別番号です。

kill コマンド

もし、暴走してCPUを使い果たしている犯人を特定したら、このコマンドで強制退去させます。

Bash

# プロセスID「1234」の暴走プログラムを強制終了する
$ sudo kill -9 1234

systemctl コマンド

裏で常駐して動いている重要なプログラム（サービス）全体をコントロールする総司令塔です。

# Webサーバー（nginx）の現在の状態を確認する
$ sudo systemctl status nginx

# サービスを再起動する
$ sudo systemctl restart nginx

💡 インフラエンジニアに必要な「サービス影響への想像力」 実務で「ちょっと設定書き換えたから、サービス再起動しといて」と言われることがあります。このとき、何も考えずにエンターキーを叩いてはいけません。 本番環境のサービスを再起動するということは、**「今まさにそのサイトにアクセスしているユーザーの通信が、一瞬途切れる（瞬断する）」**ということです。「今の時間帯に実行してユーザーへの影響はないか？」コマンド1つを叩く前に、その裏側にあるサービス影響を想像できるようになって初めて、一人前のインフラエンジニアです。

ソフトウェアを安全に導入するyumによるパッケージ管理の基本

Linuxサーバーに新しいツールや、セキュリティの修正プログラムを導入するときは、インターネット上の安全な倉庫から自動でソフトウェアをダウンロードしてインストールしてくれる yum を使います。

# ネットワーク調査の定番ツール「bind-utils」をインストールする
$ sudo yum -y install bind-utils
...
Complete! （この表示が出ればインストール完了です）

-y オプションをつけておくと、「本当にインストールしますか？」という確認をすべて自動進行してくれるため、実務の手順書を作成する際にも必須となります。

本番環境での注意点！サーバーのシャットダウンとOS再起動コマンド

最後に、インフラエンジニアの仕事の中で、最も緊張し、最も重いコマンドを紹介します。それがサーバーの停止（シャットダウン）とOS再起動（リブート）です。当然、実行には最高権限（sudo）が必要です。

# サーバーを今すぐ安全にシャットダウンする
$ sudo shutdown -h now

# サーバーを今すぐ安全に再起動（リブート）する
$ sudo shutdown -r now

🛠️ なぜプロは reboot ではなく shutdown -r now を使うのか？

Linuxには単にOSを再起動する reboot というコマンドも存在しますが、現場の厳格な手順書では shutdown -r now が指定されることが非常に多いです。

なぜなら、shutdown コマンドは、動いているすべてのサービス（プロセス）に対して「これからOSが再起動するから、データを安全に保存して順番に停止してね」と、システム全体に優しく終了通知を送りながら安全に処理を行うからです。本番サーバーの大切なデータを守り、予期せぬ破損を防ぐための、インフラエンジニアの重要な「防衛策」なのです。

【リーダーの遺言】エンターキーを押す前に、必ずホスト名を確認しろ！

物理的な電源ボタンを押しに行かなくても、手元の黒い画面からコマンド1つで遠くのサーバーを再起動できるようになりました。しかし、手軽になったからこそ、その重みを忘れてはいけません。数千人、数万人が使っている本番サーバーを落としてしまったら大障害です。

私がチームのメンバーに口を酸っぱくして言っているのは、「シャットダウン、OS再起動のコマンドを実行する際は、絶対に間違ったサーバーに対して実行しようとしていないか、100%ホスト名を確認しろ」ということです。

作業しているタブは本当にそのサーバーですか？隣の本番環境の画面と見間違えていませんか？コマンドを入力し、エンターキーを押す前のその1秒、ホスト名を確認するだけで、すべての致命的なオペレーションミスは防げます。

まとめ＆次回予告

お疲れ様でした！これでLinuxの「管理編」は完了です。

サーバー全体の神であるRootユーザーの重要性、日々発生するアカウントロックへの対応、Webサイトのエラーを救うパーミッションの罠、そしてシステム全体を揺るがすOSシャットダウンの重み。運用の視点が、少しずつ見えてきたでしょうか。

システムを安全に管理できるようになったあなたに、次に立ち塞がる壁は、外の世界との繋がり。つまり「ネットワーク」です。

次回の【実践編（第3回）】では、 「突然システムが外と通信できなくなった！」という大ピンチを10分で鎮めるネットワーク切り分け術（ip, ifconfig, ss, nslookup, dig 等の使い分け）、 サーバーが流す血と汗の涙であるログ（/var/log）の調査方法、 そして、毎朝のルーティン作業を完全に自動化する cron の設定方法と、新人が絶対にハマる「手動では動くのに自動だと動かない罠」について徹底解説します。

この他に、インフラエンジニアを目指す方のロードマップを紹介した記事があります。この機会にインフラエンジニアを目指してみたい方は以下を確認してみてください。