インフラを「信頼」するな、「検証」せよ：Chef InSpecで実現するセキュリティのコード化
「このサーバーの設定、本当にセキュアか？」
管理コンソールを眺めてそう自問したことはないだろうか。設定変更のたびにSSHでログインし、手作業でステータスを確認する。そんな運用は、現代のスピード感においては「技術的負債」以外の何物でもない。
インフラ構成管理（IaC）において、Chefが「あるべき姿（State）」を定義するツールならば、Chef InSpecは「その定義が正しく反映され、かつ安全であること」を証明する監査官だ。
今回は、ただのテストツールとしてではない。「インフラの信頼をコードで担保し、CI/CDのボトルネックを排除する」ための極限の実践知を共有する。
—
1. なぜ「テスト」をインフラの主軸に置くべきか
多くの現場でテストは「最後に行う確認作業」と見なされている。だが、我々のようなSREにとって、テストは「開発の加速器」だ。
インフラテストを自動化し、CI/CDパイプラインに組み込むことで、以下のパラダイムシフトが起こる。
- 心理的安全性の最大化: 「この変更で何が壊れるか」を瞬時に検知できるため、大胆なリファクタリングが可能になる。
- コンプライアンスの継続的担保: CISベンチマークのような厳格な基準を、人間が目視することなく「パス」し続けることができる。
—
2. InSpecプロファイルの深淵：実戦的な構成
InSpecの真価は、再利用可能な「プロファイル」にある。単発のテストを書くのではなく、パッケージ化された監査基準を作成せよ。
プロファイルのベストプラクティス構成
my-security-profile/
├── inspec.yml # メタデータ。依存関係もここに記述
├── controls/ # テストロジックの本体
│ ├── os_hardening.rb # OSレベルのテスト
│ └── nginx_config.rb # アプリ層のテスト
└── libraries/ # 複雑なロジックを分離するカスタムリソース
実用的なテスト記述例（`controls/os_hardening.rb`）
CISベンチマークを意識した、ssh設定の厳格な検証
control ‘ssh-hardening-01’ do
title ‘SSHのrootログインを無効化する’
describe sshd_config do
its(‘PermitRootLogin’) { should cmp ‘no’ }
end
end
【隠れた神テクニック】
InSpecのテストを書く際、`inspec shell` を使って対象サーバーに接続し、その場で `describe` 句を書いて挙動を確認せよ。IDEと往復する時間は無駄だ。`inspec shell -t ssh://user@host` で接続し、即座に検証を回すのがプロの流儀だ。
—
3. Chef × InSpecによるCI/CDパイプラインの構築
Chefで設定を流し込み、直後にInSpecで検証する。このループこそが現代の黄金律だ。
GitLab CI / GitHub Actions への組み込み構成例
.gitlab-ci.yml の抜粋
test_infrastructure:
stage: test
script:
- chef-client -z -c client.rb # ローカルモードで適用
- inspec exec ./my-security-profile -t ssh://target-server –reporter json:report.json
artifacts:
paths:
- report.json # 監査ログとして永続化
【チーム開発の鉄則】
1. プロファイルは別リポジトリで管理せよ: アプリやインフラのコードが変更されても、監査基準は独立してバージョン管理されるべきだ。
2. `inspec.yml` に依存関係を明記: `depends` キーを使い、他チームが作成したCISベンチマークの公式プロファイルを継承せよ。車輪の再発明は禁止だ。
—
4. セキュリティ基準の自動監査への応用
手動でCISベンチマークをチェックしているようでは、インフラエンジニアとしての寿命を縮めるだけだ。InSpecなら、数千項目のチェックも数秒で終わる。
究極の設定例：カスタムリソースの活用
複雑なロジックは `controls/` に書くな。`libraries/` にカスタムリソースとして切り出し、DRY原則を徹底する。
libraries/web_server.rb
class WebServer < Inspec.resource(1)
name 'web_server'
def running?
inspec.service('nginx').running?
end
end
controls/web_server_test.rb
control 'web-server-check' do
describe web_server do
it { should be_running }
end
end
---
現場で差がつく「極限の知見」まとめ
- 絶対に入れるべきプラグイン: `inspec-bin` で実行環境を汚さずにバイナリを管理せよ。
- 設定共有のルール: チーム全員の `~/.inspec/config.yml` をAnsibleやChefで配布せよ。特に `reporter` の出力先や、共通の `input`（環境変数）を統一することで、レビューの齟齬をなくす。
- CI/CDのコツ: InSpecの終了コード（Exit Code）を監視せよ。`0` 以外はビルドを即時停止させ、ロールバックをトリガーする設計にすること。
最後に
インフラコードは、書いた瞬間から腐敗が始まる。しかし、InSpecによって「継続的な検証」を実装すれば、腐敗を検知し、即座に回復させる「自己治癒力」を持つシステムへと進化する。
「動いているから大丈夫」という甘えを捨て、「テストがパスしているから正しい」と言えるエンジニアを目指してほしい。コードは裏切らない。だが、検証のないコードは必ず君を裏切る。
さあ、今すぐサーバーの監査コードを書き始めよう。