APACシステムのためのLinuxインフラハードニング

ほとんどのプロダクションLinuxシステムは、誰も認めたいと思わない程度にデフォルト構成に近いまま動いています。ハードニング文書は存在します。多くは何年も前の監査向けに書かれたものでしょう。しかしサーバーは文書と一致していません。「文書化されたベースライン」と「実際の構成」の隙間こそ、攻撃者が安定して住む場所です。

Linuxハードニングとはその隙間を閉じる規律であり、次のデプロイメントにも生き延びるやり方で行うことです。

デフォルトは出発点であって態勢ではない #

デフォルトのLinuxインストールはセキュリティではなく互換性を優先します。使わないサービス、不要なカーネル機能、デスクトップには足りるが侵害されたプロダクションホストには不足なロギングを同梱します。ハードニングとは汎用マシンを専用機に変える工程です。

重い作業はいくつかのカテゴリーに分かれます:

カーネルとsysctlの調整: ネットワーク保護(ICMPリダイレクト無視、ソースルートフィルタリング有効化など)、ファイルシステム制限、アドレス空間配置ランダム化などのメモリ保護。
サービス最小化: ホストが実行しないものを無効化・削除し、使用していない攻撃面を残しません。
強制アクセス制御: SELinuxや AppArmorで、侵害された場合でもプロセスができることを拘束します。
Systemdとコンテナハードニング: capability drop、raw socket遮断、seccompプロファイルによるsyscall制限。
監査とロギング: 重要なイベントを捕捉し、ホスト外へ送信して攻撃者が痕跡を消せないように。

CIS Benchmarksがこうした統制の最も実用的で広く認知された成文化であり、 OpenSCAPが適用と監査の両方を自動化します。

Config as code、なければ存在しない #

Wikiに置かれたハードニングガイドは願望リストです。コードに生きるハードニング(Ansible role、Packerイメージ、Kubernetes admission policy)は事実です。ベースラインがコードになると三つのことが変わります:

再現可能になります。 誰かが設定したことを覚えていたホストだけでなく、全ての新規ホストがベースラインを継承します。
テスト可能になります。 設定がドリフトすればCIのcompliance scanがビルドを失敗させます。
レビュー可能になります。 ベースライン変更はpull requestであり、アプリケーションコードと同じレビュー規律を受けます。

年次イベントとしてのハードニングと、プラットフォームの属性としてのハードニングの差です。

不変性という終着状態 #

論理的な帰結はイミュータブルインフラです。ホストとコンテナはその場でパッチされず、置き換えられるだけです。新しいイメージを構築・スキャン・デプロイし、古いものは破棄されます。構成ドリフトは不可能になります。ドリフトする対象がないからです。稼働中のシステムはビルド成果物です。

イミュータブルインフラはコードとしてのハードニングと自然に組み合います。ベースラインをメンテナンスするのではなく、セキュリティをイメージにコンパイルするのです。脆弱性が出現したときの修正は深夜のSSHセッションではなく再ビルドです。

flowchart LR A[CIS benchmarkベースラインas code] --> B[CIでハードニングイメージを構築] B --> C[パイプライン内compliance scan] C -- 合格 --> D[デプロイとインスタンス入れ替え] C -- 不合格 --> B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px

ホストの向こうへ #

ハードニングはOSで終わりません。同じ規律が複数の方向へ伸び、それぞれ固有の失敗様式を伴います。

コンテナはすべてを継承し、さらに自前のリスクも加えます。 ハードニングされていないベースレイヤーから作られたコンテナイメージは、ホストレベルの弱点をすべて、それを実行するすべてのpodに運び込みます。解決策は上流にあります: 最小限のbase image、CIでのスキャン、read-onlyファイルシステム付きのnon-root実行、capabilitiesの剥奪、そしてワークロードが実際に必要なsyscallへ制限するseccompプロファイル。デフォルトのseccompプロファイルだけでもかなり防ぎます。観測されたsyscall挙動に合わせて調整したプロファイルが残りを塞ぎます。Kubernetesアドミッションポリシーがこれらすべてをフリート全体で強制するため、基準未満のデプロイはそもそもスケジュールされません。

OT環境では賭け金が上がります。 産業・運用技術(OT)環境では、ハードニングがオフィスITには想像もつかない形で可用性と衝突します。ビル管理システムや生産ラインのPLCネットワーク、病院機器セグメントに誤って適用されたCIS統制ひとつが生むのはfindingではなくダウンタイムで、時には人命安全に関わります。だからOTハードニングは順序を逆にします: 受動的モニタリングと資産棚卸しが先、変更はメンテナンス窓口にロールバック計画付きで実施し、統制は本番の鏡像環境でパイロットしてから現物に触れます。ITは「このシステムは安全か?」と問い、OTは「止めずに守れるか?」と問わなければなりません。

ドリフト検知が輪を閉じます。 ベースラインは日常的な変更で劣化します: エンジニアがデバッグ目的でポートを開け、インストーラがサービスを再び有効化し、ホットフィックスがコードに還元されないまま放置される。検知がなければ、今日のハードニング済みホストは来年の緩いホストです。効果的なパターン: 毎日の構成スキャンで稼働中のホストとイメージをコード化されたベースラインと比較し、発見を誰も読まない四半期報告に埋もれさせるのではなくalertとして所有者に直接ルーティングします。一日以内に捉えたドリフトはチケットです。一年後に捉えたドリフトはインシデント調査です。

過度に寛容なクラウドIAMロールの背後にあるハードニング済みホストも、スキャンされないコンテナパイプライン内のハードニング済みホストも依然露出しています。最も持続的な態勢は、ホストベースライン、コンテナビルドチェーン、クラウド構成、アイデンティティ境界を一つの連続した表面として扱い、そう監視することです。

サーバーが実際にハードニング文書と一致しているか自信がありませんか? 気軽に簡易チェックをご相談ください。LINE(@PureSecurity)またはメール(hello@puresecurity.com)まで。

当社のLinux & インフラハードニングはベースラインをコードとして自動ドリフト検知付きで提供し、構成 & アーキテクチャ評価はホスト周辺のクラウドとアイデンティティ層を審査します。全体像にはエンジニアリング & スコーピングセッションをご予約ください。