Kompass Days 2022 article05 | 運用自動化プラットフォーム Kompira

株式会社ビデオリサーチの髙橋と申します。
本日は「トイル撲滅に向けた取り組み～脆弱性情報管理を自動化する3つの機能～」と題しましてお話しさせていただきます。
よろしくお願いいたします。

本編に入る前に私の自己紹介をさせていただければと思います。
2021年にビデオリサーチに入社し、現在2年目を迎えました。
入社時からIT部門に所属し、今年度は主にシステムの運用自動化を担当しています。
学生時代は数学を専攻していました。先日基本情報技術者試験を受けましたが、アルゴリズムなどといったところはすごく面白いなと思いながら取り組んでいました。

では、弊社ビデオリサーチについて簡単に紹介させていただきます。
ビデオリサーチ調べといった文言を見たことがある方もいらっしゃるのではないかなと思いますが、弊社はテレビ視聴率データを提供する調査機関として設立し、今年で60周年を迎えています。
以来、日本国内におけるテレビ視聴率を始めとして各種メディアデータやマーケティングデータ等、最先端のデータを提供してきました。
また、マーケティング課題の解決までトータルサポートを行う、テレビも含めた動画ビジネスを支えるデータシステム会社です。

運用課題

そんな弊社の抱える運用課題とその取り組みを説明させていただきます。
運用課題として、システムを運用する上では様々なトイルが存在します。
これは手作業や定型的に繰り返されるもののことです。
このような部分は運用標準化においても重要なポイントになってきます。
この辺りについてはフィックスポイント様のユーザーインタビューも受けさせていただいているので、そちらもご参照いただければと思います。（https://www.kompira.jp/user_interview/videor/）
このトイルを撲滅するための取り組みとして、Kompiraを利用した自動化を行ってまいりました。

課題解決への取り組み

では、その取り組みの一つとして行ってきた脆弱性情報管理の自動化についてご説明させていただきます。
まず、このツールがどういったものか説明します。
脆弱性情報に関するメールはJPCERTのCISTAから送られてくるメールで、日に2,3件ほど送られてくるものになります。
メール本文に該当するプロダクト、例えば利用しているOS、サーバにインストールされているソフトウェア名等が書かれていた場合に、タスク管理ツールのBacklogへ自動起票するといったものになっています。
Backlogは弊社では管理タスクや課題を管理するために利用しています。

脆弱性情報管理自動化の理由

この脆弱性情報管理を自動化させた理由としては、主に4つあります。

1つ目が、日次作業の手間を削減すること。
2つ目が、緊急性の高い脆弱性情報の即時検知ができるようにすること。
3つ目が、手作業によるミスの誘発。
4つ目が、検知対象漏れのリスク。

メール確認は目視でしていたので手間がかかっていました。
その作業を1日の最後にまとめて行うといった運用にした場合に、即時の対応ができなくなることも課題として挙げられました。
メールの中にプロダクト名が入っていても見落としていたり、そもそもメールを見逃してしまったりといった手作業によるミスの可能性があることも課題として挙げられます。
また、照合に利用している構成情報は従来エクセルで管理をしており、こちらは半期に1回しか更新されていないものだったので、最新の情報による検知というものができていなかったという課題がありました。
これら4つの理由から今回脆弱性情報管理の自動化を進めていきました。

自動化前のフロー

ここから脆弱性情報管理の自動化の中身に入っていきたいと思います。
脆弱性情報管理が一体どういう業務なのかを自動化導入前の運用フローも合わせてご説明させていただきます。

左側のフロー図はCISTAからメールを受信するところから始まりメール受信をトリガーにメール本文を確認し、メールの内容に該当するプロダクトがあるかを判定するということを示しています。対象の語句があった場合に、管理台帳へ検知したプロダクトを追加します。
この管理台帳はエクセルで管理しており、検知した語句や、その脆弱性情報に対する対応をするかどうかが記載されたものになっています。

検知した脆弱性情報を全て調査をしているというわけではなくCVSS値等といった基準を設けているので、それに対する確認を⑤にて行っています。調査の対象となったものはBacklogへ起票し、調査を進めていくといった形です。
調査の結果をさらに台帳に更新していました。

自動化対象と自動化構成

今回自動化させた部分は①～⑥の部分になります。ポイントは3つです。

1つ目は、メールの確認をする手間を省く。
2つ目は、最新の構成情報による判定をする。
3つ目は、自動で台帳を更新させる。

これらの3つを叶えるための脆弱性情報管理の自動化は、主に3つの機能で構成しています。

まず1つ目が、メール情報取得と脆弱性マッチングです。
脆弱性情報のメールをKompira AlertHubで受信し、この情報をCSVファイルの形に変形させ、AWSのストレージ上に配置させます。
それを置かれている構成情報と照合させ脆弱性マッチングを行い、結果ファイルを出力するといったものが機能の1つになっています。

2つ目が左上の部分の構成情報取得です。
こちらは最新の構成情報をKompira Sonarで取得し、同じく取得した結果はファイルに出力してAWS S3上に配置しています。

3つ目が下側Backlog自動起票です。
ここは脆弱性マッチングの結果ファイルが作成されたことをトリガーに、Backlogにその内容を起票するものです。

この機能を3つについてそれぞれ詳しく説明します。

機能①メール情報取得/脆弱性マッチング

まず1つ目、メール情報を取得と脆弱性マッチングについてです。
主にKompira AlertHubとKompira Enterpriseを利用したものになります。

まず初めにKompira AlertHubでメールを受信し、その後メールの件名やメールの本文の情報をKompira Enterprise側に送付。
送付された情報を元にメール情報ファイルを作成します。
それをAWS S3上に配置しマッチング判定を行い、最後にマッチング結果ファイルを出力、Backlogへ自動起票するといった流れです。

Kompira部分についての詳細をご説明します。
Kompira AlertHubの受信スロットでメールを受信し、ルール、アクションを通してKompira Enterpriseに繋げます。
アクションのところではチャネル型のKompira Enterpriseのオブジェクト「メール受信」にWebhookを投げています。
この時、メールの件名だったり受信日時といったところの情報を付与します。
この後Kompira Enterprise上の処理に入り、ジョブフロー型のメールフィルタリングを行っています。
ここはチャネルに情報が入ってきたら常に処理を動かせるように常時実行としています。

処理としてはまず1つ目、差出人によるメールであるかフィルタリングとして、JPCERTから送られてきたメールフィルタリングを行っています。
2つ目、該当するものだった場合にメール情報ファイルを作成するスクリプトジョブを実行しています。
このスクリプトジョブはKompira Enterpriseのジョブフローの中で実行しています。

機能①-ポイント

ここでポイントが２つあります。
1つ目が、メール情報をS3へ格納するといった部分です。
流れとしてはKompira Enterpriseのチャネルにメールの情報を転送し、そこで転送されたものをCSVファイルとして出力しています。
当初アクションから直接ジョブフローにパラメーターを渡そうとしましたが、なかなか本文が表示されない等上手くいかない部分がありました。
そこで、Kompira AlertHubと連携し、チャネル型オブジェクトを利用することで上手く処理を進めることができました。

2つ目が、差出人による処理の判断です。
パラメーターとして設定された差出人アドレスをジョブフロー内で正規表現が利用できるので、こちらでフィルタリングを行いました。

脆弱性マッチングをLambdaで行った理由

今回脆弱性のマッチングはAWS Lambdaで行っています。
どうしてKompiraを利用しなかったのかというと、まずKompira Enterpriseではソースの変更履歴が残らないためバージョン管理が難しく、AWS CodeCommitのソース機能を活用したかったからです。
また、S3へのファイルの配置をトリガーにプログラムを実行したい、CloudWatchでAWS Lambdaのログ出力からSNSを利用して監視メールの通知を実施実行したい、と考えておりました。
これらを一元的にAWSで管理を行うために、今回脆弱性マッチングはKompiraではなくAWS Lambdaを利用するといった形を取りました。

機能②構成情報取得

2つ目、構成情報取得についての説明をします。
主にKompira SonarとKompira Enterpriseを利用しています。自動化前のプロセスで言うと③に利用する構成情報を最新化させる部分です。
処理フローは、まずKompira Enterpriseでスキャンするジョブフローを実行するところから始まります。
このジョブフローを起動すると、Kompira Sonar側でシステムに構成情報を取得するスキャンが開始されます。
スキャンが完了すると、その結果をファイルとしてS3に配置します。

スキャン実行のジョブフローの中身は、スキャンを実行する用のAPIを実行、その後スキャンのステータスを取得するAPIを実行し、スキャンが終了したらノード/パッケージ一覧をCSVファイルとして出力するスクリプトジョブを実行します。
このスクリプトジョブもジョブフローの中で実行しています。

機能②-ポイント

ここでポイントが3つあります。
1つ目が、スキャンを終了したことをトリガーにスクリプトジョブを起動することです。
元々スキャンを実行させるAPIは1つで考えていましたが、スキャンが終了したことを検知することができなかったので、スキャンが開始された時に付与されるスナップショットIDを利用したAPIをスキャンのステータスチェックのために利用しました。

2つ目が、Kompira Sonarに表示される情報をCSVファイルとして出力することです。
フィックスポイント様から提供されているPythonのスクリプトであるkc-export-nodeというものを利用しました。

3つ目が、スキャンのスケジュール実行です。
このシステムでは日次で定時実行しており、Kompira Enterpriseのスケジュール機能を利用しています。

機能③Backlog自動起票

3つ目、Backlog自動機器の説明をします。
主にKompira Enterpriseを利用しています。
従来の自動化前のプロセスでは、④～⑥に当てはまるところになります。
元々④のところはエクセルベースの管理台帳、⑥はBacklogでのチケット管理としていましたが、この2つをBacklogに統合させるといった運用に変更しています。
対象の語句があった場合にはBacklogにすぐに起票し、その中で調査等を行っています。
処理フローは、まずAWS上にBacklog設定ファイルと記載内容に関するファイルが置かれた状態でジョブフローを実行するところから始まります。
Backlog設定ファイルにはBacklogのどのプロジェクトに起票するのか、起票した際にメンションを誰に送るのか等の情報が書かれたものになっています。
起票内容に関するファイルには、脆弱性の検知されたプロダクト名や、トリガーとなったメールの件名等が書かれたファイルになっています。
ジョブフローはこのファイルをダウンロードし、起票に必要なパラメーターを作成、最後にそれらを利用し起票のAPIを実行するといった流れになっています。

Backlog自動起票フロー

システムごとにBacklog起票のジョブフローがあり、外側に振り分けのジョブフローを作成しています。
このBacklog起票はAPIで実行しており、AWS Lambdaを利用しています。システムごとに起票用のAPIを実行させるAWS Lambdaを持たせてしまうとAWS Lambda管理が大変になってしまうので、Backlog起票をする用のジョブフローを1つにまとめたかったという意向がありました。
そのため、大きい外枠として振り分けのジョブフローを作成し、その中でシステムAに対するBacklog起票のジョブフローや、システムBに対するBacklog起票といったように振り分けます。
この振り分けはトリガーとなったファイル名で行っています。

起票のジョブフローでは、まずS3からKompira管理サーバにファイルをダウンロードし、その後Backlog起票パラメーター作成を行います。
2つ目のブロックは、Backlog設定ファイルに書かれた内容をパラメーターとして読み込むといったものになります。
起票先のプロジェクトや通知先は、脆弱性情報管理では変更しない部分なので、固定パラメーターという名前をつけています。

次に起票内容のパラメーター作成です。
ここでは検知されたプロダクト名やメールの情報をパラメーターとして設定しています。
上のものに追加していき、最後にこれを利用してBacklog起票のAPIを実行します。
必要に応じてコメントやファイル添付をするといったブロックも追加しています。
今回の脆弱性情報管理では、トリガーとなったメールの情報ファイルや検知したプロダクトがどのサーバに利用されているのか等のノード情報が書かれたファイルを添付しています。

Backlog自動起票ジョブフロー作成ポイント

ここのポイントは2つです。
1つ目が、Backlogチケットの内容を決定させるところで、起票内容のデータを積み上げていく形にしたことです。
積み上げていたデータを利用して、課題をAPIによって追加するといったものになります。

どうしてこのような形を取ったかというところが、2つ目のポイントに繋がる部分になります。
汎用性を持たせるため、2点工夫しました。
１つ目が必要な情報は外部ファイルから読み込むように作成したことです。
例えば通知先を変更したい場合、ジョブフローの中で記入していると、変更があった時にジョブフローの変更をしなくてはいけなくなるので、変更が考えられる部分については外部ファイルとして持たせ、そこからインポートすることでファイルを置き換えるのみで変更に対応します。
2つ目が、起票内容の積み上げをブロックに分割することです。
例えばBacklog起票を他の案件でも使っていく場合、メールの情報で不要な項目がある、別の情報を付与したいといったことがあった時に、ブロックにしておくことで一からジョブフローを作り直すのではなく、組み合わせで別案件でも対応できるようになります。

効果と感想

最後に導入したことによる効果と感想になります。
まず導入による効果ですが、選定理由として挙げさせていただいた課題４つが、すべてクリアされています。
1つ目については1日約1時間工数がかかっていた部分が削減され、2～4つ目についても自動化によって実現することができました。

感想として、苦労した点の1つ目は、クラウドとの活用事例の参考資料が少なかったため調査や検証が長引いてしまったといったことがありました。
ただ、引っかかった部分や処理自体は成功しているものの曖昧さが残る部分は、フィックスポイント様の技術サポートに問い合わせ、レスポンスが早くご回答いただけましたので、私のようなKompiraに不慣れな人でも、開発を進めることができました。

2つ目は、紹介した3つの機能を元々分けて考えておらず、一機能で実現しようと考えており、その要件や設計の整理に時間がかかってしまったという部分です。そこを3つの機能に分解したことで、要件や設計をシンプルにすることができました。
また、個々で機能を分けたことにより、それぞれの機能が汎用的に利用できるようになったことも良かった点だと考えています。

何か業務を自動化させたい時に、まるっと自動化させると考えがちだと思いますが、それを部品で分けて考えシンプルに一つずつ進めていくことが重要であると、今回の開発を通じ教訓として得ることができました。
このようなところも意識しながら、次の自動化を進めていきたいと思っています。

説明は以上となります。
本日はありがとうございました。