こんにちは！インフラやセキュリティの世界へようこそ。
初めてサーバーの要塞化やコンテナセキュリティの話題に触れるとき、ずらりと並ぶ見慣れない専門用語に圧倒されてしまいますよね。「何から手をつければいいんだろう…」と不安になるかもしれませんが、安心してください。一つひとつ、身近な例えから紐解いていけば、決して難しくありません。
今回は、現代のインフラ開発で必須の知識となっている「Linux Capabilitiesの最小化（Drop All Capabilities）」について、まるで自分の家の防犯を見直すような感覚で、一緒に楽しく学んでいきましょう！
—
1. 家の鍵で例える「特権」と「セキュリティ」の基本
突然ですが、みなさんが住んでいるおうちの「玄関の鍵」を想像してみてください。
毎朝出かけるとき、私たちはちゃんと鍵を閉めますよね。それはなぜでしょうか？
もちろん、空き巣や泥棒に入られて、大切な家電やプライベートなデータを盗まれないようにするためです。では、もし「この家はいつでも誰でもウェルカムですよ！」と、玄関の鍵を開けっぱなしにして出かけたらどうなるでしょう？ 考えただけでも恐ろしいですよね。
実は、サーバーの世界でもこれと全く同じことが起きています。
サーバー上で動くプログラム（コンテナなど）は、デフォルト（初期状態）のままだと、「家中のすべての部屋の合鍵を持った状態」で動いていることが多いのです。中には、普段の生活では絶対に必要のない「金庫を開ける鍵」や「家の構造を勝手にリフォームする鍵」まで、すべてポケットにジャラジャラと入ったままになっています。
もし、そのプログラムがサイバー攻撃者に乗っ取られてしまったらどうなるでしょうか？
攻撃者は、プログラムが持っている「最強の合鍵」をそのまま悪用して、サーバー全体を我が物顔で乗っ取ってしまいます。
だからこそ、「今の作業に本当に必要な鍵だけを渡して、それ以外の鍵はすべて没収する」というアプローチが必要になります。これが、今回学ぶ「Capabilitiesの最小化」の基本的な考え方です。
—
2. Linux Capabilities（ケーパビリティ）ってなに？
Linuxの世界には、伝統的に「root（ルート）ユーザー」という、すべての権限を持った最強の支配者が存在します。
昔のシステムでは、「何か特別な管理作業をしたいときは、とりあえずroot権限でプログラムを動かそう！」というのが定番でした。しかしこれでは、プログラムにわずかでもバグや脆弱性があった場合、そこを突かれた瞬間にサーバーの命運が尽きてしまいます。
そこでLinuxには、「rootの絶大な権限を、細かな作業ごとのパーツ（権限のかけら）に分解しよう」という仕組みが導入されました。これが Linux Capabilities です。
例えば、以下のようなパーツに分かれています。
CAP_NET_BIND_SERVICE: ウェブサーバーなどで使われる、小さな番号のポート（1024番未満）を開くための権限CAP_CHOWN: ファイルの持ち主（オーナー）を変更するための権限CAP_SYS_ADMIN: システム管理全般を行うための「超・危険な何でもできる権限」（実質的なrootに近い、最強の合鍵）
コンテナ技術（DockerやKubernetesなど）は、この仕組みを利用して、アプリケーションが必要とする最小限の権限だけを渡せるように設計されています。しかし、多くの設定ファイルでは、この便利さを甘く見て「とりあえず全部の権限を渡しておこう」という状態（デフォルト状態）でコンテナを動かしてしまっているのが実情です。
—
3. 攻撃者はその「不要な鍵」をどう狙うのか？
もし、あなたが動かしているWebアプリケーションのコンテナに、不要な権限がたっぷり残されたままだとしたら、攻撃者はどうやってそこにつけ込むでしょうか？
よくあるシナリオはこうです。
1. アプリケーションの古いライブラリに脆弱性（セキュリティのほころび）が見つかる。
2. 攻撃者がそこに細工をしたリクエストを送り込み、アプリケーションの裏側でこっそり任意のコードを実行する（RCE：リモートコード実行）。
3. ここまでは「ただの一般ユーザー」としての侵入ですが、もしコンテナの中に強力なCapabilities（例えば CAP_SYS_ADMIN や CAP_SYS_PTRACE など）が残っていると、攻撃者はそれを足がかりにしてコンテナの「壁」をいとも簡単にブチ破り、ホストOS（土台となる大元のサーバー）そのものを乗っ取ってしまいます。
コンテナという「檻（おり）」に入っているはずの猛獣が、檻の鍵を持ったまま暴れ出して、外の管理人室まで占拠してしまうイメージです。これではコンテナを使っている意味が半減してしまいますよね。
—
4. 実践！「Drop All Capabilities」の設定方法
それでは、一歩進んで実際のコードや設定を見てみましょう！
「すべての鍵をいったん没収し、本当に必要な鍵だけを新しく渡す」という設定は、DockerやKubernetesの世界では驚くほど簡単に、そして確実に行うことができます。
Docker Composeでの設定例
お仕事の開発環境などでよく使われる docker-compose.yml を例に見てみましょう。
セキュリティを最高レベルに高めるための設定は、以下のように記述します。
version: '3.8'
services:
web_app:
image: my-secure-app:latest
ports:
- "80:8080"
# 【ここが今日の核心！】まず全てのCapabilitiesを完全に剥奪（ドロップ）する
cap_drop:
- ALL
# もしアプリケーションの動作上、どうしても必要な鍵がある場合は、ここで「例外的に」追加する
# ※今回は例として、低いポートを使うための権限だけを最小限で追加しています
cap_add:
- NET_BIND_SERVICE
# さらなる要塞化として、読み取り専用のファイルシステムにするなどの設定も有効です
read_only: trueこの設定のポイント
cap_drop: - ALLと書くことで、コンテナが生まれた瞬間に持っていたすべての「合鍵」をきれいに没収しています。- アプリケーションが「どうしてもポート80番で待ち受けたい！」と言うのであれば、
cap_add: - NET_BIND_SERVICEでその鍵だけをそっと渡します。 - もし、アプリケーションが特別な管理作業を一切必要としない（ただWebページを返すだけなど）のであれば、
cap_addの行すら書く必要はありません。「完全丸腰（だけど安全）」な状態を作ることができます。
—
5. まとめと最初の一歩
いかがでしたでしょうか？
「Capabilitiesの最小化(Drop All Capabilities)」という言葉を聞いたときは、なんだか難しそうな要塞の防衛システムのように感じられたかもしれませんが、蓋を開けてみれば「使っていない合鍵はすぐに引き出しにしまう」という、私たちの日常の防犯意識そのものですよね。
今日からできるセキュリティの第一歩として、ご自身が管理しているコンテナの設定ファイル（Dockerfile や docker-compose.yml、Kubernetesのマニフェストなど）をそっと開いてみてください。
そして、cap_drop: - ALL の一行を書き加えて、アプリケーションが正しく動くかどうかをテストしてみましょう。
「うちのアプリ、鍵を全部取り上げても元気に動いたぞ！」という小さな成功体験の積み重ねが、あなたを頼もしいセキュリティ・エンジニアへと導いてくれます。一歩ずつ、確実にセキュアなインフラを作っていきましょう！
コメント