サーバーのハードニング基礎。最小化・最小権限・更新・設定堅牢化をCISベンチマークから学ぶ

サーバーを新しく立ち上げたとき、OSやミドルウェアは多くの場合「とりあえず動く」状態に設定されています。標準でいろいろな機能が有効になっていて、初期設定のままでも一通りのことができます。便利な反面、その「使うかもしれない機能」の一つひとつが、攻撃者にとっての入口になりえます。ハードニング（hardening、要塞化）とは、こうした不要な入口を減らし、残した入口も堅牢にして、サーバーが攻撃を受けても簡単には突破されない状態へ作り込んでいく作業です。

ハードニングは派手な対策ではありません。新しいセキュリティ製品を導入するわけでも、高度な検知システムを動かすわけでもありません。しかし、攻撃が成立する前提そのものを削っていくため、費用対効果が非常に高く、あらゆる防御の土台になります。逆に言えば、ここが緩いと、その上にどれだけ検知や監視を積み重ねても、足元から崩されてしまいます。

この記事では、ハードニングの中心にある「最小化」「最小権限」「継続的な更新」「設定の堅牢化」という4本柱を原理から噛み砕いて説明し、それを体系的に進めるための基準であるCISベンチマークの使い方、そして一度きりで終わらせないための運用までを、サーバーの構築・運用に携わる実務者の目線で整理します。OSやミドルウェアの種類を問わず通用する考え方を中心に扱います。

ハードニングの4本柱（早見表）#

ハードニングでやることは多岐にわたりますが、目的で分類すると次の4つに整理できます。個別の設定項目に入る前に、まずこの全体像を押さえると、なぜその設定をするのかを見失わずに済みます。

これらは独立しているようで、互いに補い合います。最小化で入口を減らし、それでも残る入口を最小権限で囲い、更新で弱点を塞ぎ、設定の堅牢化で残った機能を引き締める。どれか一つだけでは不十分で、4つを組み合わせて初めて「要塞化」になります。

なぜ「最小化」が最初に来るのか#

ハードニングの出発点は最小化です。理由はシンプルで、存在しない機能は攻撃できないからです。脆弱性が後から見つかったとしても、そのサービスを最初からインストールしていなければ、影響を受けません。検知や監視は「攻撃を受けてから気づく」仕組みですが、最小化は「そもそも攻撃を受けない」状態を作るため、より根本的です。

具体的には、次のようなものを「使っていないなら止める・消す」ことを検討します。

• 使っていないネットワークサービス（FTP、Telnet、不要なデーモンなど）
• 外部に公開する必要のないポート
• 標準で入っているが使っていないパッケージやコンパイラ、各種ツール類
• 初期作成された不要なアカウントや、退職者・使われなくなったアカウント
• 動作確認用に作ったままのサンプルページや管理コンソール

ここで「アタックサーフェス（攻撃対象領域）」という言葉を押さえておくと、判断の軸ができます。アタックサーフェスとは、攻撃者が狙える入口の総量のことです。開いているポート、動いているサービス、存在するアカウント、公開されているエンドポイントが多いほど、アタックサーフェスは広くなります。最小化とは、このアタックサーフェスを意図的に小さくしていく作業だと考えると、何を消すべきかの優先順位が付けやすくなります。

最小権限。侵入を「広げさせない」設計#

最小化で入口を減らしても、ゼロにはできません。Webサーバーやデータベースのように、公開して使う以上は動かし続ける必要があるものは残ります。そこで効いてくるのが最小権限の原則です。これは「各プロセス・各ユーザーに、業務に必要な最小限の権限だけを与える」という考え方です。

最小権限が重要なのは、侵入を前提にした被害の封じ込めにあります。たとえばWebアプリに脆弱性があって攻撃者に乗っ取られたとしても、そのWebサーバーのプロセスが管理者権限（rootなど）で動いていれば、攻撃者はサーバー全体を自由にできてしまいます。一方、Webサーバーが必要最小限の権限を持つ専用ユーザーで動いていれば、攻撃者が奪える権限もその範囲に限られ、被害の拡大（権限昇格や横展開）を一段難しくできます。

実務では、次のような観点で権限を見直します。

• サービスは専用の低権限ユーザーで動かし、rootで常駐させない
• 管理者権限（sudoなど）は、必要な人・必要なコマンドの範囲に限定する
• ファイルやディレクトリのアクセス権を、所有者と用途に応じて絞る
• データベースは、アプリ用アカウントに必要な操作（参照・更新など）だけを許可し、不要な管理権限を与えない

認証まわりの最小権限と多層防御は、認証の強化と組み合わせると効果が高まります。管理者アカウントの保護については

継続的な更新。塞いだ穴は開き直る#

設定をどれだけ堅牢にしても、OSやミドルウェアそのものに脆弱性が見つかれば、そこが新たな入口になります。脆弱性は日々公表され続けるため、更新（パッチ適用）は一度やれば終わりではなく、継続的に回し続ける運用です。

ここでつまずきやすいのが、「動いているから触りたくない」という心理です。本番サーバーの更新は不具合の不安がつきまといます。しかし、既知の脆弱性を放置することは、攻撃者に対して入口を開けたままにしておくことに等しく、特にインターネットに公開しているサーバーでは、公表済みの脆弱性が短期間で悪用されることもあります。更新を止める判断は、そのリスクを引き受ける判断でもあります。

現実的に回すための要点は次のとおりです。

• どのサーバーに何が入っているか（構成・バージョン）を把握しておく。把握できていないものは更新できない
• 重要度に応じて適用の優先順位とスピードを変える。公開サーバーや影響の大きい脆弱性は急ぐ
• 検証環境で先に確認してから本番へ適用する手順を用意し、不具合時に戻せるようにしておく
• サポートが終了（EOL）した製品は更新が提供されないため、計画的に移行する

脆弱性情報の追い方や深刻度の読み方そのものは、別途、脆弱性管理の知識が必要になります。どの脆弱性をどの順で塞ぐかは、深刻度評価（CVSSなど）と自組織での影響を突き合わせて判断します。

設定の堅牢化。残した機能を引き締める#

最小化で消し、最小権限で囲い、更新で塞いでもなお、サーバーには使うために動かしている機能が残ります。その残した機能を、初期設定のままにせず安全側に設定し直すのが「設定の堅牢化（セキュア・コンフィギュレーション）」です。初期設定は「動きやすさ」や「互換性」を優先していることが多く、安全性が最優先になっているとは限りません。

代表的な観点を挙げます。

• 通信の暗号化を有効にし、古い・弱い暗号方式やプロトコルを無効にする
• 不要な初期設定（サンプル設定、デバッグ機能、詳細なエラー表示など）を無効にする
• 認証を強化し、初期パスワードやデフォルトの認証情報を必ず変更する
• ログを適切に出力・保管し、不正の兆候を後から追えるようにしておく
• 推測しやすい初期値（標準ポート、標準アカウント名など）への依存を見直す

ここで難しいのは、「何を、どの値に設定すれば堅牢と言えるのか」という具体的な基準です。経験と勘で個別に判断していくと、漏れや属人化が生じます。そこで役立つのが、次に説明するCISベンチマークのような、合意形成で作られた具体的な設定基準です。

CISベンチマークとは何か#

CISベンチマーク（CIS Benchmarks）は、米国の非営利団体 Center for Internet Security（CIS）が公開している、ITシステムを安全に設定するためのベストプラクティス集です。OS、サーバーソフトウェア、データベース、クラウド基盤、コンテナ、ネットワーク機器など、対象ごとに「どの項目を、どう設定すべきか」が具体的な手順とともにまとめられています。

CISベンチマークの大きな特徴は、特定ベンダーが一方的に決めたものではなく、世界中のセキュリティ専門家やベンダー、コミュニティが参加する合意形成プロセス（コンセンサス・ベース）で作られている点です。CIS自身の説明によれば、ベンチマークの策定にはコミュニティを通じて1万2千人を超えるIT セキュリティ専門家が関わっており、100を超えるベンチマークが25以上のベンダー製品ファミリーを対象に提供されています。非商用利用ではPDFを無償でダウンロードして参照できます。

CISの公式説明では、CISベンチマークが合意形成に基づくコミュニティ主導の設定推奨であること、100超のベンチマークが25以上の製品ファミリーを対象に提供されていることが述べられています（執筆時点の記載に基づく）。

Level 1 と Level 2 の2段階#

CISベンチマークの各推奨項目には、適用の度合いを示すプロファイル（プロファイル・レベル）が設定されています。代表的なのが Level 1 と Level 2 です。

Level 1 は「攻撃対象領域を下げつつ、機能を損なわず実用性を保つ」ことを意図した基礎的な推奨です。多くの環境ではまずLevel 1の充足を目標にするのが現実的です。一方Level 2 は「defense in depth（多層防御）」の考え方に立ち、セキュリティが最優先される環境向けで、適切に実装しないと業務に悪影響が出る場合があるとされています。

なお、CISのFAQによれば、米国国防総省のSTIG（Security Technical Implementation Guide）に対応するSTIGプロファイルが、かつての「Level 3」を置き換える位置づけで提供されています。自組織がどの水準を求められるのかを踏まえて、目標とするプロファイルを選びます。

CISベンチマークのFAQでは、Level 1が比較的すぐ適用できる基本推奨、Level 2が多層防御を重視する環境向けであること、STIGプロファイルが従来のLevel 3を置き換えることが説明されています（執筆時点の記載に基づく）。

CISベンチマークとCISコントロールの違い#

CISには、設定基準である「CISベンチマーク」とは別に、組織全体の防御施策の優先順位を示す「CIS Critical Security Controls（CISコントロール）」があります。両者は別物で、役割が異なります。

• CISベンチマーク: 個々のOS・製品を「どう設定するか」という、具体的で技術的な設定基準
• CISコントロール: 組織として「何を、どの順で実施するか」という、施策レベルの優先順位付け

CISコントロールには、組織の規模やリスクに応じた実装グループ（Implementation Groups、IG1からIG3）という段階が用意されています。CISの公開情報によれば、CISコントロール v8.1 はセーフガードを実装グループに分け、IG1が基礎的なサイバー衛生（essential cyber hygiene）として位置づけられ、IG2、IG3と進むにつれて適用するセーフガードが累積的に増える構成になっています。サーバーのハードニングは、こうした全体施策の中の「セキュアな設定」を、ベンチマークという具体的な基準で実装する部分にあたる、と捉えると位置づけがはっきりします。

段階的に適用する。締めすぎは事故のもと#

CISベンチマークのような基準は強力ですが、項目をすべて機械的に適用すれば良いわけではありません。Level 2 の項目の中には、適用すると既存の業務やアプリの動作に影響が出るものもあります。何が動かなくなるか分からないまま本番でいきなり締めると、それ自体が障害（自分で起こす可用性の事故）になりかねません。

そこで、次のような段階を踏むと安全に進められます。

ハードニングは一度では終わらない#

ハードニングで見落とされがちなのが、「一度設定したら終わり」ではないという点です。サーバーは運用していくうちに、アプリの追加、設定変更、トラブル対応のための一時的な緩和などで、当初堅牢にした状態から少しずつずれていきます。この「構成のずれ（構成ドリフト、configuration drift）」を放置すると、知らないうちに守りが緩みます。

そのため、ハードニングは構築時の一回作業ではなく、設定が基準からずれていないかを定期的に測り、ずれていれば戻す、という継続的な運用として組み込む必要があります。CISベンチマークは設定項目が明確なため、現状が基準に合致しているかを点検（アセスメント）する基準としても使えます。点検の結果を記録し、設定変更の際には「この変更はハードニングの基準に反していないか」を確認するプロセスにしておくと、ずれを早期に発見できます。

また、ハードニングは単体で完結する対策ではなく、他の防御と組み合わせて初めて力を発揮します。たとえばログを適切に取って監視と結び付ける、Webアプリ自体の脆弱性をなくす、といった取り組みと両輪です。Webアプリの脆弱性対策の全体像は

よくある質問#

まとめ#

サーバーのハードニングは、最小化・最小権限・継続的な更新・設定の堅牢化という4本柱で、攻撃が成立する前提そのものを削っていく地道な作業です。新しい製品を入れるより前に、いま手元のサーバーから不要な入口を減らし、残した入口を引き締めることが、最も確実で費用対効果の高い守りになります。CISベンチマークのような具体的な基準を土台にしつつ、業務への影響を見極めながら段階的に適用し、一度きりで終わらせず継続的に点検し続ける。この当たり前を回し続けることが、サーバーを長く安全に保つ近道です。