皆さん、こんにちは！
日々の開発やインフラの管理、本当にお疲れ様です。セキュリティの世界へようこそ！
「コンテナ技術って便利だけど、なんだか難しそう……」
「セキュリティの専門家が言う『ルートレス』とか『読み取り専用』って、いったい何のことなの？」
そんな風に感じていませんか？ 大丈夫です、安心してください。今日は、難解なセキュリティの専門用語を、私たちの身近にある「家や部屋の防犯」にたとえながら、一歩ずつ優しく紐解いていきたいと思います。
インフラエンジニアや開発者の仲間たちが現場で頭を悩ませている「本当の脅威」から身を守るための知恵を、一緒に楽しく学んでいきましょう！
—
1. コンテナのセキュリティって、家の防犯に似ているんです
まず、現代の開発現場で大人気の「コンテナ（Dockerなど）」についてイメージしてみましょう。
コンテナは、アプリケーションを動かすための「便利なカプセル（お部屋）」のようなものです。このお部屋の中には、プログラムや設定ファイル、ライブラリなど、動くために必要なものがひとまとめになっています。
さて、ここでちょっと想像してみてください。
あなたが賃貸マンションの管理人だとします。入居者（コンテナの中で動くアプリ）に、部屋の「合鍵」を渡すとき、どんな鍵を渡しますか？
もし、部屋だけでなく 「マンション全体のマスターキー（管理人キー）」 を渡してしまったらどうなるでしょう？
もしその入居者（アプリ）がうっかり悪意ある外部の侵入者に乗っ取り（脆弱性の悪用）を受けてしまったら……。侵入者はそのマスターキーを使って、マンション全体の部屋を自由に出入りし、すべてを破壊したり盗み出したりできてしまいますよね。
これが、セキュリティの世界で恐れられている 「コンテナの特権昇格（Rootフルアクセス）問題」 なんです。
—
2. 攻撃者はどこを狙う？ 「合鍵」と「書き換えられる壁」の恐怖
サイバー攻撃者は、私たちが想像するよりもずっと泥臭く、そして巧妙にシステムの「隙」を突いてきます。
彼らがよく狙うのは、Webアプリケーションに潜むわずかなバグ（例えば、外部からの入力をうまく処理しきれない脆弱性など）です。ここを踏み台にしてコンテナの内部に入り込んだ攻撃者は、次にこう考えます。
- 「このコンテナの中、管理者権限（root）で動いてるラッキー！」
- 「しかも、このファイルシステム、何でも書き換えられるぞ！」
もし、コンテナの中が root ユーザー（何でもできる最強の権限）で動いていて、さらにファイルシステムが「書き込み自由」だった場合、攻撃者は次のような悪行を簡単に成し遂げてしまいます。
1. システムの奥深くに悪意あるプログラム（バックドア）をこっそり書き込む。
2. 内部の重要な設定ファイルを書き換えて、さらに別のサーバーへ攻撃を広げる。
3. 気づかないうちにコンテナの「外（ホストOS）」にまで侵入を広げてしまう。
怖いですよね。でも、落ち込む必要はありません。私たちの手で、この「最強の合鍵」を取り上げ、部屋の壁を「頑丈なガラスケース」にしてしまえばいいのです！
それが今回学ぶ 「ルートレス実行（非特権ユーザーでの実行）」 と 「読み取り専用ファイルシステムの設定」 です。
—
3. 対策その1：コンテナの「ルートレス実行」で、最強の権限を取り上げる
最初の対策は「ルートレス実行」です。これは、コンテナの中で動くアプリに、何でもできる「管理人キー」ではなく、「自分の部屋の鍵しか開けられない一般住民の鍵」 を持たせる設定のことです。
たとえアプリが乗っ取られたとしても、動いているユーザーが「ただの一般人（non-root）」であれば、システム全体の心臓部を触ることはできません。「おいおい、そこから先は通さないよ！」と、オペレーティングシステムがガッチリガードしてくれます。
実践！ Dockerfileでのルートレス設定
実際のコンテナの設定ファイル（Dockerfile）を見てみましょう。難しく考えず、「こういう風に書くんだな」と雰囲気を掴んでくださいね。
# ベースイメージとして安全な公式の軽量Linuxを使用します
FROM python:3.11-slim
# アプリケーション用の専用作業ディレクトリを作成
WORKDIR /app
# アプリケーションに必要なファイルをコピー
COPY . /app
# 【ここがポイント！】
# システム管理者の「root」ではなく、権限を制限した専用の一般ユーザー（appuser）を新しく作ります
RUN useradd -u 10001 appuser
# 以降の操作やアプリの実行は、すべてこの一般ユーザーに切り替えます
USER appuser
# アプリケーションを起動するコマンド
CMD ["python", "app.py"]このように、USER appuser という一行を入れるだけで、コンテナの中の主人は「一般ユーザー」になります。これだけで、万が一のときの被害を最小限に食い止めることができるのです。
—
4. 対策その2：読み取り専用ファイルシステムで「悪意ある落書き」を防ぐ
ふたつめの対策は「ルートファイルシステムの読み取り専用化（Read-only）」です。
先ほどの部屋の例えに戻りましょう。
お部屋の壁が、もし自由にいじれる「粘土」でできていたらどうでしょう？ 侵入者はそこに勝手に怪しい落書きをしたり、別の危険な家具を置き換えたりしてしまいます。
では、もしその壁が 「ガチガチに固められた強化ガラスのディスプレイケース」 だったらどうでしょうか？
中にあるものは見えても、勝手に付け足したり、書き換えたりすることは一切できませんよね。
コンテナの世界でもこれと同じことをやります。アプリが動くためにどうしても書き込みが必要な場所（ログを吐く場所や一時的な作業場所など）以外は、すべて「見るだけ（読み取り専用）」にしてしまうのです。
実践！ Docker Composeでの読み取り専用設定
今度は、コンテナを動かすときの設定ファイル（docker-compose.yml）で、この「読み取り専用」を指示してみましょう。
version: '3.8'
services:
web-app:
image: my-secure-app:latest
# 【ここがポイント！】
# コンテナ全体のルートファイルシステムを「読み取り専用（read_only）」に設定します
read_only: true
# ただし、アプリケーションがどうしてもデータを保存・一時保存したい場所（ログや一時フォルダ）だけは、
# 別の安全な「一時領域（tmpfs）」として特別にマウントして許可してあげます
tmpfs:
- /app/tmp
- /var/log/myapp
# セキュリティをさらに高めるために、不要なカーネル権限をバッサリ切り捨てる設定
security_opt:
- no-new-privileges:true
ports:
- "8080:8080"この設定を入れておくと、攻撃者がもしコンテナ内に侵入して「よし、ここに怪しいプログラムファイルを書き込んでやろう！」と企んでも、ファイルシステム側から 「ここは読み取り専用だから書き込めません！」 と冷たく拒絶されます。攻撃の芽を文字通り「根っこから」摘み取ることができるわけです。
—
5. まとめ：安全なコンテナ運用は「ちょっとした心掛け」の積み重ね
いかがでしたでしょうか？
「ルートレス実行」と「読み取り専用ファイルシステム」。言葉だけ聞くとすごく難しそうですが、要するにこういうことでしたよね。
1. アプリには必要最低限の権限（一般人の鍵）しか持たせない（ルートレス）
2. 書き換えられたくない場所は、頑丈なガラスケース（読み取り専用）にして守る
セキュリティの対策は、一度にすべてを完璧にやろうとすると息切れしてしまいます。でも、今日学んだこの基本の「型」を、次の開発やインフラ構築のときから少しずつ取り入れていくだけで、あなたのシステムは劇的に強くなります。
一歩ずつ、確実に。安全でワクワクするモノづくりを一緒に楽しんでいきましょう！
それでは、また次回のセキュリティ解説でお会いしましょう。お疲れ様でした！
コメント