「OSは使い捨て、設定は鉄壁に」— Bottlerocketで実現するコンテナホストの最終防衛ライン
現場でインシデント対応をしていると、決まって「なぜ攻撃者はこれほどまでにOSの深いところまでアクセスできたのか？」という問いに突き当たります。答えはシンプルです。多くのエンジニアが、コンテナの中身には神経を使うのに、その足元であるホストOSを「単なる箱」として放置しているからです。
従来の汎用Linuxディストリビューションは、柔軟性が仇となり、攻撃者に「パーシステンス（永続化）」の足場を与えてしまいます。そこで、今回皆さんに叩き込んでおきたいのが、AWSが提供するコンテナ専用OS「Bottlerocket」を活用した、妥協なき要塞化の手法です。
1. なぜ「読み取り専用」が最強の防御なのか
攻撃者がホストOSに侵入した際、最初に行うのは「バックドアの設置」や「設定ファイルの改ざん」です。これらは /etc/ や /usr/bin/ への書き込みが必要になります。
Bottlerocketは、ルートファイルシステムが読み取り専用（Read-only）で設計されています。これにより、攻撃者が侵入に成功したとしても、その場でファイルを書き換えて永続化を図ることは物理的に不可能になります。これは単なる「設定」ではなく、OSの設計思想による防御です。
2. カーネルパラメータの固定：攻撃のトリガーを封じる
ファイルシステムを固めただけでは不十分です。攻撃者はカーネルパラメータを操作して、特権昇格やネットワークの盗聴を試みます。例えば、kernel.kptr_restrict を適切に設定しなければ、カーネルのアドレス空間が露出し、攻撃者にヒントを与えてしまいます。
Bottlerocketでは、settings セクションを通じて、起動時からこれらのパラメータを強制的に固定します。
実務で即戦力となる設定ファイル（TOML）
Bottlerocketのユーザーデータ（user-data.toml）に記述する、推奨のハードニング設定は以下の通りです。
# Bottlerocketの要塞化設定
[settings.kernel]
# カーネルのシンボル情報を隠蔽し、攻撃者にアドレスを特定させない
kptr_restrict = "2"
# dmesgログによる情報漏洩を防ぐ
dmesg_restrict = "1"
# 悪意あるシンボリックリンクの作成を防ぐ（特権昇格の常套手段）
yama.ptrace_scope = "1"
[settings.network]
# IPスプーフィング攻撃を防御するためのリバースパスフィルタ
# 0: チェックなし, 1: 厳密なチェック（推奨）
ip_forward = false
[settings.network.interfaces.eth0]
# 不要なネットワーク露出を防ぐため、必要最小限のインターフェース制御
# 必要に応じて有効化する3. 実践：攻撃者のPoC（概念実証）を無力化する
想像してください。攻撃者がコンテナから脱出し、ホストOS上で cron を書き換えて定期的にバックドアを起動させようとするPoCを。
通常OSであれば、echo "evil_script" >> /etc/crontab で終了です。しかし、Bottlerocket上でこれを行うと、以下のようなエラーが返ります。
bash: /etc/crontab: Read-only file system
この瞬間、攻撃者の「永続化」という戦略は破綻します。ログには書き込み拒否のイベントが記録され、SIEM等で即座にアラートを上げることも可能です。
4. 運用エンジニアへの提言：設定は「コード」で管理せよ
「設定をいじったらサーバーにログインして確認する」という時代は終わりました。Bottlerocketの設定は、Gitで管理された user-data として配布し、CI/CDパイプラインを通すのが鉄則です。
以下は、Terraformを用いてこの設定を適用する際の一例です。
# TerraformでのBottlerocket用ユーザーデータ設定例
resource "aws_launch_template" "bottlerocket_node" {
name_prefix = "hardened-node-"
image_id = "ami-xxxxxxxxxxxxxxxxx" # BottlerocketのAMI
user_data = base64encode(<<-EOF
[settings.kernel]
kptr_restrict = "2"
yama.ptrace_scope = "1"
[settings.kubernetes]
api-server = "https://your-cluster-endpoint"
EOF
)
}最後に：セキュリティは「諦め」の積み重ね
セキュリティチーフとして言いたいのは、「何でもできるOSは、何でもされるOSである」ということです。
Bottlerocketを採用するということは、利便性を一部捨てる（SSH接続が標準では不可など）ことを意味します。しかし、その「不自由さ」こそが、攻撃者にとっての「絶望」になります。
インシデント対応で徹夜したくないのであれば、OSレベルでの「読み取り専用」と「パラメータ固定」を今すぐ実装してください。コードを一行書くよりも、この設計を導入する方が、皆さんのシステムの生存確率は劇的に向上します。
現場からは以上です。次のステップとして、皆さんの環境で sysctl の値が適切に設定されているか、今すぐ確認することから始めてみてください。
コメント