はじめに

2022年1月に apache log4j 脆弱性に関するニュースが世間を賑わせました。

弊社も例外ではなく対応に奔走することになりましたが、実は影響範囲の特定に関しては非常にスムーズに実施する事が出来ました。
今回はその立役者である、弊社内で独自に設計構築した Ansible を利用した構成情報収集ツールを紹介しようと思います。

本ツールの設計・実装は 2021年末頃の話になります。

ツール開発の発端

情報セキュリティ対策の一つとして脆弱性対応は重要であり、システムの構成情報を把握しておく事はその前提となります。
しかし、弊社内ではシステムの大まかなアーキテクチャやサーバーOSなどは認識していても、導入されているパッケージの全量やライブラリの情報までは把握しきれてはいませんでした。

設計書は存在し、そこに記述があっても最新化されているかが不明であり、いざ脆弱性情報を拾っても「そもそも我々のシステムは対象なのか」「我々のシステムに導入されているパッケージやライブラリのバージョンは脆弱性に該当するのか」という点の確認をシステムベンダに頼らざるを得ず、初動対応に時間がかかっていました。

こういったところから、システム構成情報を収集し可視化するツールの必要性があったのです。

構成情報収集ツール概要

システムに導入されているパッケージや利用されているライブラリ情報は可視化と管理が難しいと以前から感じていました。設計書やパラメーターシートに記載する事は簡単でも、その管理は誰がするのか、パッケージやライブラリがアップデートされた時に誰が更新するのか、正しく最新化できているのか、といった問題が付きまといます。

そのあたりを解決する一手段として SBOM（Software Bill of Management）と言われる製品も存在しており、活用されているのかと思います。
しかし、製品導入となると見積もりを取り、PoCと共に製品選定を行い、決裁をとり…と、どうしてもスピード感が落ちてしまいます。

そこで弊社では、弊社なりに必要となる構成情報を定義し、それを収集し、一覧化するツールを独自に作成し、定期的に実行させています
Infrastructure composition Management（通称：ICM）と呼称しており、その構成は以下の様になっています。

構成情報の収集はAnsibleで実装し、OSのクーロンで週次実行しています
収集した情報はICMサーバー上で加工して S3 に格納しています
S3にあるファイルをQuickSightで可視化しています

　
Ansible採用の理由としては

コーディングが非常に容易である事
エージェントレスで実装出来る事

という点で、非常にスピーディに且つ既存システムへの影響少なく実装できました。

収集している情報

サーバー情報（ホスト名、OS情報、AWSリージョンなど）
インストールパッケージ
共有ライブラリ
ユーザー/グループ情報
NW情報（IPアドレス、リスンポート等）

など

どんな風に見えるの？

画面の一例ですが、このような形で一覧化しています

Ansibleのスクリプト

実際に動いているスクリプトですが、例としてインストールパッケージ情報を取得するplaybookを以下に記載します。

スクリプト内にある特定の文字列は **** でマスクしております

- name: Get packages from hosts file
  hosts:
    - servers
 
  tasks:
    - name: Get packages
      package_facts:
        manager: auto
      become: false
      ignore_errors: yes

# ansible template module で jinja2 file を target 側で実施する形でパッケージ取得
    - name: Output packages
      template:
        src: ../tmp/package.j2
        dest: "/home/****/result/{{ inventory_hostname }}/packages"
        mode: '0644'
      delegate_to: localhost

# 取得したFileのJsonへのパース
    - name: parse result to json
      command: '/home/****/shell/parse_json_package.sh {{ inventory_hostname }}'
      delegate_to: localhost

# サーバー側に作成される一時ファイルの削除
    - name: delete temporarily result file
      shell:
        cmd: "rm /home/****/result/{{ inventory_hostname }}/packages"
        warn: false
      delegate_to: localhost

今後について

現在の状況でもある程度の要件を満たしてはいますが、まだまだ使いづらい点はあります。
今後は検索機能の追加であったり、収集情報の追加、更に収集した構成情報や設定ファイルの意図しない変更の検出などをゆっくりと実装していければと思っています。
　
　
　
　

CCoE　西村

Ansible使ってSBOMのようなものを作った話