Amazon Web Services（AWS）をはじめとするクラウドが「導入」フェーズから徐々に「運用」フェーズへと入ってきたことを踏まえ、ユーザーの抱える課題もまた変化してきた。たとえば、オンプレミスで実現していたのと同じ、いやそれ以上のログ管理をどう実現するか、一定のポリシーに沿ったガバナンスをどう実現するか――5月16日に東京・五反田のInnovation Space DEJIMAで開催されたSecurity JAWSの第9回勉強会では、そんな、ある意味泥臭い課題に取り組むエンジニアの取り組みが紹介された。
オープンな技術で作る「オープンSIEM」で内外の脅威を分析
フューチャーアーキテクトの日比野恒さんは、最初のセッション「Kibana Canvasで魅せる！AWS環境における脅威分析ユースケース」において、BeatsやLogstash、ElasticsearchにKibanaといったオープンな技術を使って、オープンな環境で実現する「オープンSIEM」構想を紹介した。
フューチャーアーキテクトの日比野恒さん
オープンSIEM開発のきっかけとなったのは、とある金融機関のマイナンバー管理システム開発プロジェクトだ。マイナンバーを参照するユーザーの履歴をどうすれば監視できるだろうかというニーズに応え、AWSのログを管理・分析するサブシステムを開発した。そして「最近ではイーコマースや小売、流通といった分野でも、個人情報や顧客情報をAmazon RDSやS3で管理するケースが増えています。たとえば配送に必要な住所や体の寸法といった、万一漏れると大きなダメージになる機微な情報を、AWSの中でいかに適切に扱うべきかという案件が増えています」（日比野さん）
日比野さんらが構築したオープンSIEMの基本的な考え方は、オンプレミスのものと変わらない。AWS EC2のインスタンスのログはBeatsで、またデータベースのログはLogstashで取得し、加工した上でElasticsearchに入れるというアーキテクチャだ。それをKibanaでビジュアライズしてダッシュボードとし、何か異常なイベントがあればアラートで通知する。
基本的にはオープンソースのElastic Stackを利用して構築したが、アラート通知や機械学習といった部分には有償プラグインの「X-Pack」を活用した。実はこのX-Packプラグインには一部の機能を無償で使える「X-Pack ベーシック」があり、これが意外と使えるそうだ。たとえば、性能に関するデータをKibanaのダッシュボードに細かく表示できるため、「Elasticsearchのクラスタをどう大きくしていくかとか、Logstashでログの取り込みに時間がかかっているといったとき、サイジングの参考情報になります」という。
Elasticプロダクトの活用イメージ
また、BeatsではWindowsのイベントログIDを指定すると、関連するデータをXMI形式で取得できるが、最近出た「Audit Beat」では、Linuxについて同じようにログを正規化してくれる。「こういったツールを使うとログの正規化が楽になります」と日比野さんは述べた。
フューチャーアーキテクトではこうした仕組みを使って、外部からの脅威と内部犯行、両方の分析に取り組んでみたそうだ。「外部からの攻撃を分析するポイントとしては、やはりマネジメントコンソールへのログインをしっかり見張る必要があります。また、API Gatewayを用いてデータを出し入れしている場合は、AWS APIコールやそういったデータのやり取りも見張る必要があります」（日比野さん）
一方、内部犯行対策で注意すべきは、「機微な情報の保存先やアクセス経路を知っている人」だ。そうしたアクセスを見張るには、踏み台やRDS/S3のアクセスログを拾うことがポイントになる。元々データベースのエンジンに用意されているオーディット（監査）機能を有効にし、監査ログをXMLフォーマットで出力してS3に保存し、AWS Lambdaを使ってフィルタをかければ、「誰が、いつ、どんなSQLを叩いたか」が分かるという。
ただ、「内部不正については、ログだけ見ていてもよく分からない部分もあります。作業申請書と付き合わせ、メンテナンス時間ではないのに触っているとか、意図せぬタイミングでログが出ているといった事象を把握できるようにしておくと、時間をかけずに不正を見張ることができます」と日比野さんは述べた。
CloudTrailのログ可視化は「シンプルイズベスト」で
続けて同社の中井祐季さんが、こうして収集したログをCloudTrailを用いてどのように分析したかを説明した。
フューチャーアーキテクトの中井祐季さん
ログの可視化というと、往々にしていろいろな情報を盛り込み、あれこれグラフを表示したくなるが、「シンプルイズベストで作っていくことにしました。CloudTrailのログにはかなりのフィールドがあり、何を見張ればいいかを決めるのが難しくなります。まずポイントとして、管理コンソールへのログインやAPI操作にフォーカスして、誰がどこから実行したかを抑えるところから始めるのがいいと思います」（中井さん）
そして一例として、管理コンソールへのログイン履歴にGeoIPフィルタを組み合わせ、「どのIPアドレス、どの国からログインしているか」を把握したり、コンソールログイン時にきちんと多要素認証（MFA）を使っているか、打ち間違いがないかを確認したり、ログインした後にどのようなAPIを叩いたかを把握できるようにしたダッシュボードを紹介した。
こうした解析の仕組みをClassic Load Balancerのログに適用し、機械学習を組み合わせれば、アプリケーションの脆弱性を狙った攻撃やDoS攻撃の検知にも活用できるという。今回は、Kibana Canvasを用いてハニーポットから収集したデータを分析するところまでは手が回らなかったが、いろいろな用途に活用できそうだ。
クラウド上に構築したSIEMとPagerDutyでログや対応履歴の追跡を可能に
この日のライトニングトークでは、クックパッドの水谷正慶さんも「セキュリティログ分析のためのサーバーレスアプリケーションの構築（仮）」と題して、同社がクラウド上に構築しつつあるログ解析の仕組みを紹介した。
クックパッドのSIEMでは、EC2のインスタンスから出てくるログをはじめ、CloudWatch LogsやCloudTrail、GuardDutyなどで取れた情報、さらにはサードパーティのSaaSのログも含め、全てをS3に保存しているという。これらをAWS Lambdaを用いて処理し、統合ログ管理ツールの「Graylog」で検索・分析できる状態にするとともに、長期間に渡るログ分析用のデータもS3に保管しているそうだ。あとは、ログの中からアラートに該当するイベントを検知すると通知・処理を行なう。
このようにログの収集、ログの処理、アラートの処理という3段階に分けた構成を構築し、全体としてSIEMのような機能をクラウド上に構築しようと試みている。
水谷さんはさらに「PagerDuty」を組み合わせ、アラートがあればSlackに通知するとともに、GitHub Enterpriseのイシューとして立ち上げ、「いつ、誰が、どうやって対応したか」といった情報をどんどん追加できるようにしているそうだ。もし怪しいファイルを見つけたら自動的にVirusTotalに問い合わせ、その結果もコメントとして残せる仕組みになっている。何があったのか、誰がどのように判断したのかが、履歴やGraylogの情報を確認しつつ追跡できるため、これからのインシデント対応にも有効だという。
週刊アスキーの最新情報を購読しよう
