「Ansible Automation Platform」と、それを用いたセキュリティ自動化ソリューションを紹介

レッドハット「プラットフォーム化したAnsibleで“自動化2.0”実現を」

2020年02月17日 07時00分更新

文● 大塚昭彦／TECH.ASCII.jp

　レッドハットは2020年2月14日、昨年9月に発表したIT自動化プラットフォームの「Red Hat Ansible Automation Platform」と、同プラットフォーム上に構成されるセキュリティオーケストレーション／自動化ソリューション「Ansible Security Automation」に関する記者説明会を開催した。

「Red Hat Ansible Automation Platform」の概要。Ansible EngineやAnsible Towerといった自動化ツール群を統合し、組織での利用を促す可視化や共有といった機能も追加して、SaaSで提供

レッドハット日本法人製品統括・事業戦略担当本部長の岡下浩明氏、米レッドハット Ansible セキュリティ担当コンサルティング・プロダクトマネージャーのマッシモ・フェラーリ（Massimo Ferrari）氏

プラットフォーム化したAnsibleで目指す「自動化2.0」とは何か

　説明会ではまず、レッドハット日本法人の岡下浩明氏が、Ansible Automation Platformの概要と、同プラットフォームを提供するレッドハットの狙いについて説明した。

　「レッドハットでは、Ansibleを通じて『自動化2.0』という世界観の実現を目指している」と、岡下氏は説明する。

　岡下氏によると、Ansibleは現在、レッドハットの中で「最も顧客のつくスピードの速いプロダクト」になっており、国内でも急速に導入が増えているという。ただし、導入ケースの多くが、まだ「個別の」小さなタスク／業務を自動化するものにとどまっている点が課題だと指摘する。

　「Ansibleというテクノロジーは、シンプルで学びやすいということもあり、ずいぶんポピュラーになったと認識している。個別（のタスク／業務）に導入するという点で『自動化1.0』段階に来ている組織は多くなった。ただし、その次のフェーズ（『自動化2.0』）に進むためには、自動化そのものをいかにサービス化していくかが重要になる。Ansibleで属人性を排除したサービス（機能）を作り、APIを通じて公開し、それらのサービスを連携させる。こうした『自動化2.0』の世界をどう作っていくのか、われわれはそれを日本の顧客に提案している」（岡下氏）

単に個人の個別タスクを対象とする「自動化1.0」から、組織として統制され、共有化された「自動化2.0」への移行を促す

　属人的で個別最適化された「自動化1.0」から、利用する自動化技術が組織全体で標準化され、統制がとれた「自動化2.0」に進化することで、タスク自動化のスピードアップとコスト削減、品質向上につながる。岡下氏は、複数の国内エンタープライズにおける実績を挙げながら、自動化フェーズの進化によって「多大な生産性、品質の差」が生まれると説明した。

　「したがって、これから『自動化2.0』フェーズに移行する顧客を作っていくのが（レッドハットの）課題」（岡下氏）

　レッドハットがAnsible Automation Platformをリリースした理由はここにある。「Ansible Engine」や「Ansible Tower」といった既存のツールだけでなく、Ansibleコンテンツ（プレイブックやモジュールなど）の新しいパッケージ形式「Ansible Content Collections」、多数のパートナーベンダーによる認定済みAnsibleコンテンツのリポジトリ「Automation Hub」、組織内のAnsible利用状況など各種統計データを可視化する「Automation Analytics」なども統合している。これにより、より幅広い業務タスクへのAnsible適用を促すとともに、社内各部門における自動化の取り組みを評価／比較することも可能になる。

「もはやセキュリティ人材の増強だけでは対応できない、自動化が必要だ」

　サーバーやクラウドインスタンスが中心だったAnsibleの自動化適用拡大を促すために、レッドハットではAnsible Automation Platform上で、セキュリティやネットワークの自動化ソリューションを提供している。それがAnsible Security Automation、およびAnsible Network Automationだ。米レッドハットのマッシモ・フェラーリ氏は、このうちSecurity Automationについて説明した。

　セキュリティ領域へのAnsible適用がなぜ必要なのか。フェラーリ氏はその背景として、日々大量のサイバー攻撃を受け、それに対抗するために多様なベンダー製ソリューションが導入されている企業のセキュリティ環境があると説明する。

　「企業のセキュリティチームは、導入している多数のセキュリティソリューションから日々大量のアラートを受け取っている。しかしその『量』に圧倒されて、現実には平均で5％以下のアラートにしか対応できていないという調査結果がある」（フェラーリ氏）

セキュリティ業界のカオスマップの例。「顧客は山のようにあるベンダーとソリューションから選択しなければならない。状況は20年前よりも悪化している」（フェラーリ氏）

　さらに、サイバー攻撃の高度化によって「個々のインシデント調査／解明により多くの時間がかかるようになった」と考えるセキュリティ担当者が57％、「攻撃の深刻度が増している」という答えは65％に及ぶという。「よく『セキュリティ人材の不足』と言われるが、もはや人材の増強だけでは対応できないだろう。オーケストレーションを通じた効率化、自動化が必要だ」（フェラーリ氏）。

　さらにフェラーリ氏は、注目すべき新たな動向として「インフラだけでなく、アプリケーションそのものが複雑化している」ことを指摘する。アプリ開発のマイクロサービス化を背景として、アプリケーションを構成するコンポーネント数が非常に増えている。こうした変化にセキュリティ側は追随できておらず、開発者側からは「セキュリティが足を引っ張っている」とすら見られている。「その一方で、攻撃者側はすでにAI／機械学習の技術を導入し、自動化の恩恵を受けるようになっている」（フェラーリ氏）。

アプリケーションをマイクロサービスで再実装すると……

　こうした問題を解決するために、近年ではセキュリティ対応のオーケストレーションと自動化を図るSOARソリューションが登場した。多くのエンタープライズがSOARに注目しており、大手セキュリティベンダーがSOARを開発するスタートアップを買収する動きも続出している。

　しかし「早期にSOARを導入した企業は多くの問題点も指摘している」と、フェラーリ氏は語る。たとえば、SOARは非常に複雑かつ専門特化したツールであり、企業の期待どおり完璧に動作するわけではない。新しいツールなので使い勝手がこなれていない。自社環境に合わせてカスタマイズしたい場合はPythonコードを書かなければならない――といったことだ。

　そこで、汎用的かつ実績のあるAnsibleをセキュリティ領域の自動化にも適応しようというのが、レッドハットの戦略だ。フェラーリ氏は、セキュリティ自動化ツールに求める要素として「オープンソースをベースとしており、プロプライエタリなツールのように（対応製品などの）偏りがない」「統合やカスタマイズ、メンテナンスが非常にしやすい」「モジュラー化により幅広いサポートができる」の3つを挙げ、これらをすべて実現することを目標に、1年前からAnsible Security Automationの開発に取り組んできたと語る。

　「Ansibleを、さまざまなセキュリティツール間を統合する“標準言語”として使おうというのが、Ansible Security Automationの狙いだ。たとえばログ設定の自動変更からスレットハンティング、インシデントレスポンスまで、セキュリティチームにとって身近なタスクを自動化する事例が出てきている」（フェラーリ氏）