この記事は、Ansible Advent Calendar 2020、13日目の記事です。

Ansible Workshop のセキュリティ編を眺めてみた結果を書いていきます。率直な感想としては、「これ、もくもく会で是非やってみたい」です。

ベースとなる情報

Ansible Workshop セキュリティ編へのリンク

github.com

初めに謝辞

今回英語コンテンツを読んでみる覚悟で覗いてみたのですが、実はこのコンテンツ、完全に日本語化されておりました…

立役者のお二方(ひよこ大佐さん、せんさん)に最大級の感謝を…

Section1: Ansible Security Automation の基礎を紹介

1.1 ラボ環境を確認してみよう

他のコンテンツと比較して異色だな、と思ったのは、操作する対象が以下の種類をすべて組み合わせてAnsibleの操作対象としている点です。

  • 疑似攻撃者の端末(SSHで操作)
  • ファイアウォール(管理サーバ含む)(RESTで操作)
  • WebサーバとSnort(IDS)を動かすターゲットサーバ(SSHで操作)
  • SIEMであるIBM QRadar(RESTで操作)

複数種類のプロダクトを共通の制御手法でコントロールできる。やはり、これがAnsibleの強いところだなと思います。

1.2 最初のCheckPoint用のPlaybookを実行してみよう

ファイアウォールであるCheckPointをAnsibleで操作するためのPlaybookを実行します。

CheckPointに対して、今回のラボ実行に必要となる通信ポリシーを許可させるために、以下の3点を実施するPlaybookを実行します。

  • 送信元/宛先のオブジェクトの作成
  • 通信許可ポリシーの追加
  • 作成したポリシーの実環境へのインストール

1.3 最初のSnort用のPlaybookを実行してみよう

侵入検知・防止システムであるSnortをAnsibleで操作するためのPlaybookを実行します。

snort用のモジュールは無いそうで、「だからモジュール作ったよ」とのこと。SASUGA。

1.4 最初のIBM QRadar用Playbookを実行してみよう

QRadar操作用のモジュールは標準では同梱されていないようで、「Ansible collections」からインストールを行う工程があります。

Section2: Ansible Security Automation のユースケース

2.1 Investigation Enrichment

Section1で自動化の下ごしらえをした環境群に対し、実際の調査対応を行う演習です。

こういうロールバックなども一発で実施できるのが、IaCの素晴らしいところだなと思いますね。

2.2 Threat hunting

統合的にセキュリティイベントを管理できる環境を作るために、Ansible TowerのRBACを活用して設定を行っています。

2.3 Incident response

最後の項目では、SQLインジェクション攻撃が発生した場合のインシデントレスポンスを実践します。

全体的な感想

Section2のユースケースにあるように、複数のプラットフォームに対してAnsibleという統一された手段でコントロールできることは、非常に重要だなと実感できました。

実際には、このあたりのSnortでの検知→CheckPointへのブラックリスト登録などまで含めてすべて連動させ自動実行させることで、より運用に手間がかからなくなる、ということも可能だと思います。

https://tenko.hatenablog.jp/entry/2020/12/13/193209

バックアップ日時: 2026年1月12日