こんにちは！インフラやセキュリティの世界へようこそ。
新人のIT担当者や、「コンテナってなんだか便利そうだから使っているけれど、セキュリティって言われるとちょっとドキッとする……」という開発者の方、多いのではないでしょうか。
Dockerなどのコンテナ技術は、アプリを動かすための環境をきれいにパッケージングしてくれて本当に便利ですよね。でも、実はコンテナが動いている「土台（ホストOS）」の守りが甘いと、せっかくの便利な仕組みが、あっという間に侵入者への「合鍵」になってしまうことがあるんです。
今回は、難しく聞こえるホストOSのカーネルパラメータ（sysctl）を使ったコンテナ保護について、身近な防犯にたとえながら、一歩ずつ優しく紐解いていきましょう！
—
1. 家の鍵にたとえる「ホストOSとコンテナ」の関係
突然ですが、あなたが大きなお屋敷（ホストOS）の中に、いくつものプライベートルーム（コンテナ）を作って、それぞれ別の住人を住まわせていると想像してください。
コンテナ技術は、各部屋のドアに鍵をかけ、プライバシーを守るのにはとても優れています。しかし、「お屋敷全体の玄関の鍵」や「廊下の防犯カメラ」の管理を怠っていたらどうなるでしょう？
もし一人の住人が部屋の窓を全開にしていたり、廊下で勝手に暴れ出したりしたとき、お屋敷全体が危険にさらされてしまいますよね。
コンテナセキュリティの鉄則は、「コンテナの中だけをがんばって磨いても、土台となるホストOSがザルだったら意味がない」ということです。今回は、そのお屋敷の頑丈な壁や自動ロックを作るために、sysctl（シスシクル）というカーネルの設定をいじっていきます。
—
2. 攻撃者はどこを狙う？――IPフォワーディングの罠
コンテナ環境で一番怖い事故の一つが、「自分のコンテナから、勝手に外のネットワークへ攻撃の踏み台にされる（あるいは社内の秘密エリアに侵入される）」という事態です。
ここで登場するのが net.ipv4.ip_forward という設定です。
IPフォワーディングってなぁに？
ざっくり言うと、受け取った通信を「別の場所へ素通りさせる（転送する）」機能のことです。
ルーターなら必須の機能ですが、コンテナを動かすホストOSにおいて、これが余計に働いていると、コンテナが勝手にネットワークの「中継地点」になってしまい、部外者があなたのサーバーを踏み台にしてネットワーク内を縦横無尽に走り回れてしまいます。
これを防ぐためには、ホストOS側で「勝手に通信を中継しちゃダメ！」と厳しく交通整理をしてあげる必要があります。
—
3. 実践！ホストOSを守る sysctl.conf の設定
それでは、実際に安全なお屋敷を作るための設定ファイルを見ていきましょう。
Linuxサーバーの /etc/sysctl.conf というファイルを編集することで、カーネル（OSの心臓部）の振る舞いをグッと引き締める（要塞化する）ことができます。
以下の設定例を参考にしてみてくださいね。実務でもそのまま使えるように、丁寧なコメントをつけておきました！
# ==========================================
# コンテナ環境を守るためのホストOS ネットワーク要塞化設定
# ==========================================
# 1. IPフォワーディングの制御
# 通常、Dockerなどのコンテナエンジンが自動で必要に応じて制御しますが、
# 意図しないネットワークの中継を防ぐため、基本方針を明確にします。
# （※Dockerが動的に有効化する場合もありますが、全体の方針として意識します）
net.ipv4.ip_forward = 0
# 2. 送信元ルーティング（Source Routing）の無効化
# 攻撃者が「この経路を通ってこい」と勝手に道順を指定して送ってくるパケットを拒否します。
# 巧妙なネットワーク迂回攻撃を防ぎます。
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.default.accept_source_route = 0
# 3. ICMPリダイレクトパケットの受け入れを拒否
# ルーターのフリをした偽物のパケットによって、通信の向きを勝手に曲げられるのを防ぎます。
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.default.accept_redirects = 0
# 4. 逆パスフィルター（RPフィルタ）の有効化
# 送信元IPアドレスが偽装されていないかをチェックします。
# 「このIPアドレスから来るはずのない方向から通信が来たぞ」という場合にパケットを捨てます。
net.ipv4.conf.all.rp_filter = 1
net.ipv4.default.rp_filter = 1
# ==========================================
# カーネルダンプとメモリ保護の設定
# ==========================================
# 5. カーネルパニック時のメモリダンプを無効化（または制限）
# 万が一システムがクラッシュした際、メモリ上の機密情報（パスワードや暗号鍵など）が
# ダンプファイルとしてディスクに残るのを防ぎます。
fs.suid_dumpable = 0設定ファイルを書き換えたあとは、以下のコマンドを実行してすぐに反映させましょう！
# 設定を即時反映させるコマンド
sudo sysctl -p—
4. もう一つの盲点：「カーネルダンプ」という名のアルバム
セキュリティの現場でよく見落としがちなのが、「システムがエラーでコケたときの記録（カーネルダンプ）」です。
人間でたとえるなら、意識を失って倒れたときに、自分の財布の中身や日記帳が道端にパァーッと広がるようなものです。もしコンテナの中で動いていたアプリケーションが、データベースのパスワードや秘密鍵をメモリ上に展開したままクラッシュした場合、その瞬間がそのままファイルとして保存されてしまうと大変ですよね。
先ほどのコードにも入れた fs.suid_dumpable = 0 は、「おっと、倒れても中身を見られないようにしっかりポケットをチャックしておこうね」という優しい、かつ強力なセキュリティ設定なのです。
—
5. まとめ：一歩ずつ、安全なインフラを育てよう
いかがでしたでしょうか？
「カーネルパラメータ」や「sysctl」という言葉を聞くと、なんだか冷たくて難しそうな黒い画面の呪文に見えたかもしれませんが、やっていることは「お屋敷の鍵をしっかり閉め、余計な通り道を塞ぎ、倒れたときも持ち物を守る」という、身近な防犯の延長線上にすぎません。
セキュリティは一度設定して終わりではなく、日々の開発やインフラ運用のなかで「あれ、この穴は大丈夫かな？」と気付きながら少しずつ固めていくものです。
焦らず、ひとつずつ理解を深めながら、自信を持って安全なコンテナ環境を育てていきましょう！
あなたのインフラライフが、安全で快適なものになりますように。
コメント