本番Linuxサーバーの初期設計 — 最初に固定する項目

本番Linuxサーバーの初期設計では、稼働後に変更するほど影響範囲が広がる項目がある。ファイルシステムの分割構成、ユーザー・権限モデル、ログの収集先、ホスト名の命名規則——これらは運用フェーズで手を入れるたびに調査・停止・検証の工程を要し、1台あたり数時間以上の作業に膨れ上がることも珍しくない。設計フェーズで「最初に固定すべき項目」を見極め、判断の根拠をチームで揃えておくことが、後工程の手戻りを最小化する。本記事ではその判断軸と設計の考え方を整理する。

なぜ初期設計は「後から変えにくい」項目から決めるのか

変更コストが構築時と運用時で大きく異なる理由

構築フェーズと運用フェーズでは、同じ変更でも作業コストがまったく異なる。構築中であれば再インストールや再構成で済む変更が、本番稼働後には「停止→バックアップ→変更→検証→復旧→事後確認」という一連の工程を経ることになる。20台規模の環境でパーティション構成を後付けで修正しようとすると、1台あたり数時間の作業が必要になり、全台完了までに数週間を要するケースもある。問題の本質は変更そのものではなく、「影響調査」に時間がかかる点にある。ディレクトリ構成を1か所変えるだけで、Systemdのユニットファイル、Cronジョブ、ログ収集エージェントの設定、デプロイスクリプトをすべて洗い出す作業が発生するからだ。設計当初に1時間で決められた事項が、後付けでは調査だけで5〜10倍の工数を要する例は珍しくない。

「変えやすい」と「変えにくい」を仕分ける三つの基準

初期設計で固定すべき項目の選び方は、「変更時にサービス停止が必要か」「他の設定ファイルやスクリプトへの依存が広いか」「変更後の検証範囲が広いか」という三点の確認が基本になる。この三点すべてに該当する項目を最初に確定させ、それ以外は後から調整可能なものとして扱うと、設計フェーズの優先順位が自然に定まる。ユーザー・権限モデル、ファイルシステム分割、ホスト名の命名規則、NTP・タイムゾーン、SELinuxの有効/無効はこの「固定すべき項目」の典型だ。一方、パッケージの追加や個別アプリの設定値は比較的変更しやすく、後回しにしても影響は限定的になる。この仕分けをチーム内で合意しておくことが、設計フェーズの議論を効率化する第一歩となる。

アンチパターン：暗黙の判断を積み重ねる危険性

現場でよく見られる失敗は、「とりあえずデフォルトで進める」という判断が積み重なることだ。ある構築を任された担当者が時間の制約からパーティション設計を後回しにしたところ、半年後にログが肥大化してルートパーティションが逼迫し、サービス停止を伴う緊急対応が発生したという話はよく聞く。デフォルト設定そのものが悪いわけではなく、「意図して選んだ根拠がない」状態で本番に出ることが問題だ。根拠を持って選択した結果がデフォルト値なのか、単なる放置なのかは後から区別できない。設計記録にその差を残すことが、将来の担当者への責任ある引き継ぎにもなる。

ユーザー/権限モデルの初期設計（sudo境界の考え方）

システムアカウントと運用アカウントを分ける意味

サーバーに存在するアカウントは「サービス動作用のシステムアカウント」と「人が操作する運用アカウント」に大別できる。設計段階でこの境界を明確にしないまま構築を進めると、rootや汎用アカウントで複数人が作業する状態が続き、監査ログから誰が何をしたかを特定できなくなる。本番環境では、作業者ひとりにつき1アカウントの原則を設計に組み込んでおくことが、後のインシデント調査を大幅に簡略化する。システムアカウントは原則としてログイン不可（シェルを/sbin/nologinなどに設定）とし、サービスの実行ユーザーとしてのみ機能させる方針を初期段階で決めておくことが重要だ。このルールを初期設計で決めておかないと、構築の途中でSSH鍵を設定したシステムアカウントが本番環境に残り続けるという状況が生まれやすい。

sudo境界をどこに引くか

sudoの設計で判断が分かれるのは「権限の粒度」だ。NOPASSWD指定で全コマンドを許可する設計は運用の手間を減らすが、誤操作や不正アクセス時の被害範囲が広がる。コマンド単位での細かい制限は設計コストが高く、アプリのアップデートのたびにsudoersを修正する運用負担も生まれる。現場でよく採用されるのは「役割グループ単位でsudo範囲を定義し、グループへの追加・削除でアクセス制御を行う」モデルだ。たとえばapp-operatorグループにはアプリ再起動コマンドのみ許可し、infra-adminグループにはより広い権限を与えるといった構成が典型的な例として挙げられる。このグループ設計を初期段階で確定させておかないと、後から再整理するときに既存の手順書やデプロイスクリプトとの整合性を一から取り直す作業が発生する。

権限昇格ログの取得設計

sudoの実行ログはデフォルトでもシステムのログファイルに出力されるが、「どのコマンドを実行したか」の詳細が残らないことがある。初期設計の段階でsudoのログ詳細化やauditdとの連携を検討しておくと、後のセキュリティ監査や障害調査で根拠のある記録が提示できる。監査ログの取得設計は、後から追加すると既存の監査ルールとの競合調整が発生するため、最初に方針を固めておく項目のひとつだ。「何を記録する必要があるか」をセキュリティ要件や業務ポリシーから逆引きして確定させると、設計の抜け漏れを防げる。記録対象を曖昧にしたまま稼働させると、インシデント後に「ちょうどその時期のログが残っていない」という事態につながる。

ディレクトリ/ストレージ配置の設計判断

/var・/tmp・/homeの分割判断

Linuxのデフォルトインストールでは多くのディレクトリがルートパーティションに同居するが、本番環境では用途に応じた分割が基本的な設計方針となる。分割する主な理由は「特定ディレクトリのディスク肥大化でシステム全体が停止するリスクを設計で遮断する」ことだ。ログや一時ファイルが膨らんでルートパーティションを使い切ると、SSHログインやプロセス起動さえ不能になる。/varはログ出力量が最も多いディレクトリのため独立したパーティションまたは論理ボリュームに分割するのが定石だ。/tmpは一時ファイルの書き込みが集中するため、noexecオプション付きで別パーティションにする構成が多い。/homeはサービスがほぼ使わない環境であれば省略も設計選択肢に入る。サービスが/homeを利用するかどうかが分割要否の判断軸となる。

LVMを採用するかどうかの判断基準

LVM（論理ボリュームマネージャ）を採用すると、パーティションサイズの後付け変更やスナップショット取得が容易になる。一方、LVMを使わないシンプルな構成は障害時の復旧手順が単純になるという利点がある。10台規模以下の小規模環境や、クラウドのブロックストレージを前提とした構成では「LVMを入れないシンプル設計」を選ぶケースも多い。判断の分岐点は「稼働後にディスク拡張が発生する可能性があるか」と「スナップショットが運用上必要か」の二点だ。オンプレミスで物理ディスクを扱う場合はLVM採用が安全側の選択になるが、クラウド環境ではストレージを動的に割り当てられるためLVMの恩恵が限定的になる場面もある。この判断を設計段階でドキュメントに残しておかないと、後の担当者がLVMの有無の意図を読み取れず、誤った操作につながることがある。

マウントオプションと用途の対応

ファイルシステムのマウントオプションは、セキュリティと用途の両面から設計が必要だ。実行ファイルを置かない領域には「noexec」、setuidを許可しない領域には「nosuid」、デバイスファイルを不要とする領域には「nodev」を付与するのが基本方針だ。/tmpや/homeに対してこれらオプションを設定しておくと、万が一の侵害時に攻撃者の活動範囲を制限する効果がある。マウントオプションはfstabに記述する設定であり、変更は次回マウント時（多くの場合は再起動時）まで反映されない。このため後から追加するためにはサービス停止が必要になるケースがあり、初期設計で確定させておくべき項目に含まれる。

ログ・監査の置き場所を最初に決める理由

/varをログ専用領域に分ける設計根拠

ログの出力先を初期設計で確定させる最大の理由は、「ログの肥大化でシステムが停止するリスクを設計で排除するため」だ。/varを独立させていれば、ログが増大してもシステム本体の動作には影響しない。逆に/varがルートパーティションに同居している状態でログが増大すると、システム全体への書き込みが不可能になり、SSHでの接続さえ困難になる事態を招く。本番環境では50GB〜数百GB規模のログを扱うケースもあり、容量設計を楽観的に見積もると数ヶ月で逼迫するサーバーが出てくる。ログの増加傾向はサービス開始直後から徐々に変化するため、初期段階での余裕ある設計が後の安定運用につながる。

監査ログ（auditd）の設計方針

Linuxカーネルの監査フレームワークであるauditdは、システムコールレベルでの記録が可能なため、セキュリティインシデント発生後の追跡に強力なツールとなる。しかし監査ルールを広範に有効化するとログ量が爆発的に増加し、ストレージを圧迫するだけでなく、肝心な記録を探すのが困難になる。設計段階では「何を記録しなければならないか」を洗い出し、監査対象を必要最小限に絞った上で保存期間と収集先を決める必要がある。一般的には、ユーザーのログイン・ログアウト、sudoの実行、重要設定ファイルへの書き込み、特権コマンドの実行が監査対象の基本セットとなる。これをベースラインとして業務要件や法規制に応じて追加する設計フローが整理しやすい。

ログ収集の集約先と保存期間の設計

個別サーバー上にログを溜め込む設計は、サーバー障害時にログを失うリスクがある。構築当初から外部の集約基盤への転送を前提に設計しておくと、障害後の追跡が格段に楽になる。転送先の設計は後から追加することも可能だが、ログのフォーマットや転送用アカウントの権限設計は初期段階で決めておかないと、後の変更が複数ファイルにまたがる作業になる。保存期間については、「ホット（直近アクセス可能）」と「コールド（長期保管）」の境界を設定することが多い。この設計を後回しにすると、気づいたときには数ヶ月分のログが削除されていて、監査で提出できる記録が存在しないという事態につながることもある。

時刻同期・ホスト名・命名規則という地味な土台

時刻同期（NTP）設計の判断ポイント

複数台のサーバーが連携するシステムでは、時刻のずれがログの照合やトランザクションの整合性に直接影響する。NTPの設定自体は単純な作業だが、「どのNTPサーバーを参照するか」「社内NTPサーバーを経由するか直接インターネット上のサーバーを参照するか」という判断は、セキュリティポリシーやネットワーク設計と連動している。インターネットへの直接アクセスを制限したセグメントではNTPの経路を別途確保しておかないと、時刻がずれたまま稼働するサーバーが生まれる。分散システムでは数十ミリ秒程度のずれでもトランザクション順序に影響する場合があり、設定し忘れが後から発覚すると原因特定に時間を要する。NTP経路の設計はネットワーク設計と並行して確定させておくべき項目だ。

タイムゾーン設定の一貫性

サーバーのタイムゾーンは原則としてUTCに統一するのが一般的な設計方針だ。運用担当者の手元が日本時間であっても、サーバー側のログがUTCで記録されることで、複数拠点や複数環境でのログ照合を一貫して行える。タイムゾーンをJSTに設定したサーバーとUTCに設定したサーバーが混在すると、ログのタイムスタンプを頭の中で変換しながら追跡する手間が生まれる。これは単純な設定ミスではなく、統一方針がなかったことによる設計の齟齬だ。5台程度の環境でも混在があれば、障害調査時の混乱の種になりうる。

ホスト名・命名規則の重要性

ホスト名の命名規則は「決め方」よりも「全員が守れるか」が重要な設計判断だ。ランダムな名前や担当者の好みで付けたホスト名は、後の管理者が用途・環境・ロールを把握するまでに余分な調査コストを要する。一方、名前が長すぎると入力ミスや省略表記が生まれ、スクリプトや構成管理ツールのインベントリでの扱いが煩雑になる。実際の現場では「環境識別子-ロール-連番」（例：prod-web-01、stg-db-02）のような構造化された命名が採用されることが多い。後から全サーバーのホスト名を変えると、SSL証明書のCN、ログの検索パターン、監視ツールの登録名など広範囲に影響が及ぶため、構築開始前に決定してチーム全員で共有しておく必要がある。

セキュリティ初期値をどこまで絞るかの線引き

SSHアクセス制御の初期設計

SSHの初期設定でまず判断すべきは「rootでの直接ログインを許可するか否か」と「パスワード認証を許可するか否か」の二点だ。本番環境では原則として両方を禁止し、公開鍵認証かつ一般ユーザーでのSSHログイン後にsudoで権限昇格する設計を採用するのが安全側の選択だ。この設定は初期構築時に入れておけば変更コストは低いが、稼働後に変更すると設定の誤りでログインできなくなるリスクを伴う作業になる。またSSHの待ち受けポートをデフォルトの22番から変更するかどうかも設計判断のひとつだ。ポート変更は自動スキャンの対象から外れる効果があるが、本質的なセキュリティ向上ではなく「見えにくくするだけ」という点を理解した上で採用を判断する必要がある。ポート番号の変更は、後の接続確認手順やファイアウォール設定に連動するため、変更するなら初期設計の段階でチーム全員が把握した状態で決定すべきだ。

ファイアウォールの初期設定方針

ファイアウォールの初期設定では「デフォルト拒否・必要なものだけ許可」の原則が基本となる。問題になりがちなのは、構築作業中に一時的に許可したポートや通信経路が、構築完了後もそのまま残り続けるケースだ。本番リリース直前に全ポートを棚卸しするのは手間がかかり、見落としが生まれやすい。設計段階で「本番で必要なポート一覧」をリスト化し、それ以外はデフォルト拒否というルールを明文化しておくと、構築中の一時的な解放が後に残るリスクを減らせる。このリストが設計書に残っていれば、後の担当者が許可ルールの意図を判断できる。

SELinuxの有効・無効の判断

SELinuxはRHEL系ディストリビューションでデフォルト有効となっているが、「動作確認が取れないのでとりあえずPermissiveかDisabledにする」という選択が積み重なって、本番環境でSELinuxが無効のまま放置されるケースがある。SELinuxを無効にすること自体が即座に重大な問題を引き起こすわけではないが、有効化して設計したポリシーが活きてこないという意味で、設計の意図と実装の乖離が生まれる。判断のポイントは「アプリケーションやミドルウェアがSELinuxのポリシーと競合するか否か」だ。競合が多い場合はポリシーの調整コストを見積もった上で有効・無効を判断する。無効にする場合はその根拠をドキュメントに残しておかないと、後の担当者が理由のわからない設定を前に立ち止まることになる。

初期設計チェックリスト（RHEL系を例に）

以下に、本番Linuxサーバーの初期設計で確認すべき項目をまとめる。RHEL系を念頭に置いているが、判断の考え方はDebian系でも共通して適用できる。手を動かす具体的な設定コマンドはセミナーや専門書に譲り、ここでは「判断したか・根拠があるか」を確認するための設計視点の一覧として活用いただきたい。

設計項目	判断のポイント	後から変えにくい度
パーティション分割（/var, /tmp等）	ログ肥大化リスク、停止影響の分離	高（再インストールに準ずる作業）
LVMの採用・非採用	後付け拡張の有無、クラウド vs オンプレ	高（構築後の変更はリスクを伴う）
マウントオプション（noexec等）	用途とセキュリティ要件の組み合わせ	中（変更自体は可能だが再起動が必要）
ユーザー・グループ設計	役割ごとの分離、sudo境界の定義	高（後付けは手順書・スクリプト全体に影響）
sudoersの権限粒度	コマンド単位 vs グループ単位	中（変更自体は容易だが影響調査が広い）
SSH設定（root禁止・認証方式）	公開鍵認証のみへの絞り込み、ポート番号の方針	高（誤設定で接続不能リスク）
SELinuxの有効・無効	アプリとの競合有無、ポリシー調整コスト	高（後から有効化はポリシー整備が大変）
ファイアウォールの初期ルール	デフォルト拒否の徹底、許可ポートの明文化	中（ルール追加は容易だが棚卸しが手間）
NTP参照先・タイムゾーン	社内NTP経由か直接か、UTC統一の方針	中（変更は容易だが混在が問題を生む）
ホスト名・命名規則	環境-ロール-連番などの構造化命名	高（後変更は証明書・監視・ログに波及）
auditdの監査ルール	記録対象の洗い出し、ログ量とのバランス	中（追加は可能だが過去ログは遡れない）
ログ収集・転送先	集約先の設計、保存期間のホット/コールド区分	中（後から追加可能だが初期ログが手元に残る）

設計完了の判断基準

チェックリストの各項目について「設定したか」だけでなく「なぜその設定にしたかを説明できるか」を確認基準にすると、設計の抜け漏れが見えやすくなる。デフォルト値のままの項目があっても問題はないが、「デフォルトを意図的に選んだ」という根拠がドキュメントに残っていることが重要だ。根拠のない設定は後の担当者が変更してよいかどうかを判断できず、そのまま放置されることで技術的負債の一種になる。設計書に根拠が書かれているかどうかが、長期的な保守性の分かれ目になる。

初期設計ドキュメントに残すべき情報

設計フェーズで確定させた判断は、「何を選んだか（設定値）」「なぜ選んだか（判断根拠）」「何を選ばなかったか（採用しなかった選択肢）」の三点としてドキュメントに記録しておくと、後工程での参照が容易になる。特に「採用しなかった選択肢」は記録されにくいが、後の担当者が同じ検討を繰り返さないためにも有効な情報だ。以下に、設計ドキュメントに最低限含めるべき項目を示す。

• パーティション設計の図または表（サイズ・マウントポイント・マウントオプション）
• ユーザー・グループの一覧と用途・sudo許可範囲
• ホスト名の命名規則の定義と具体例
• NTP参照先とタイムゾーンの設定根拠
• SELinuxの有効/無効の判断根拠とポリシーの概要
• ファイアウォールで許可するポートと用途の一覧
• auditdの監査対象・収集先・保存期間の設計