機械学習を用いたAWS CloudTrailログの積極的活用

Copyright © 2016 TIS Inc. All rights reserved.

戦略技術センター

高橋和也

機械学習を用いた AWS CloudTrailログの積極的活用

July Tech Festa 2016

2016/07/24

Copyright © 2016 TIS Inc. All rights reserved. 1

はじめに

本日の話

インフラエンジニアと機械学習

Amazon MLを用いて試行錯誤しながらログデータを機械学習させてみた事例

機械学習に触れてみて感じたこと

以下は出てきません

機械学習の理論やアルゴリズムの話

機械学習を活用して効果を挙げた事例

色々試してみたけれど、今のところ成功したかというと･･･


自己紹介

発表者

高橋和也

TIS株式会社戦略技術センター所属

インフラ関連技術の活用に向けた検証や開発等を担当

主な経歴

社内システム運用

各種クラウドサービスの検証

Zabbixの拡張ツールであるHyClopsの開発

クラウドオーケストレーションツールCloudConductorの開発

機械学習の経験は無し

今年の4月から着手


背景


機械学習に対する期待の高まり

データ分析･活用の手段として機械学習に注目が集まっている

少し前からある事例

大量の購買データをリコメンドに利用

大量のセンサデータを障害予測に利用

ディープラーニングの登場でさらに適用範囲は拡大

解決したい問題にあわせて与える学習データを人が調整するのではなく、大量に蓄積されたデータを大規模環境で学習させて法則を見つけ出す

法則を言語化しづらい画像認識などでも活躍

でも大量のデータを持っていない企業には縁が無い？

本当に大量にデータが無いといけないのか？

本当にインフラエンジニアは知らなくてよいのか？

まずは手元のデータで何ができて、何が足りないのか試してみよう


インフラエンジニアの身近にあるデータといえば

運用現場に眠る様々なログ

ログを残しておくことは運用上重要

現在の状態の把握

問題発生の検出

問題の原因切り分け

監査証跡

運用現場には大量のログデータが蓄積されている

AWS上だけでも様々なログが記録されている

CloudTrail: AWSのAPI呼び出しログ

VPC Flow Logs: VPC上のリソースの通信ログ

S3 Bucket Logging: S3のアクセスログ

CloudWatch Logs: 各サーバから収集したログやLambda Functionの実行ログ

でも普段から人がログに目を通す余裕は無い


ログデータの特徴

どのような特徴を持っているか

データ量がそれなりに多い

日常的に利用されるシステムのアクセスログは、不特定多数のユーザを対象としていなくても長期間集めればある程度のボリュームになる

製品毎に一定のフォーマットに従って出力されている

機械学習を適用するためのデータ加工がしやすい

一度うまくいけば同一製品/機器を使う他の運用現場にもノウハウを横展開しやすい

長期間にわたり保管されている

思い立ってからデータを集め始めなくても過去のデータを活用できる

人が全部目を通すのは大変

何か問題が起きない限り確認されないログも多い


これまでのログデータ活用: 監視

ログデータは監視対象としても重要

障害につながるエラーログの検出

バッチ処理等の成功/失敗の確認

想定外のアクセスの検出

ログ監視は監視ルールのメンテナンスが大変

出力されるログメッセージを事前に把握する必要がある

ログレベルが出力される場合は比較的監視しやすいが、そうでない場合は出力されるメッセージ内容の把握が必要

めったに出ないログメッセージは事前に調べるのが難しい

バージョンアップ等で変更があるとまた対応が必要

環境によって注視すべきログが異なる場合が多い

機械学習を使ってルールを置き換えられないか


これまでのログデータ活用: 可視化

ログの検索･可視化が簡単に実現可能な時代に

Elastic Stack, Splunk, etc.

AWSであればAmazon Elasticsearch Service (Amazon ES)

可視化することでログの傾向を短時間で確認可能

例: 過去1週間のアクセスログ件数の推移

例: 権限不足により拒否された操作ログを種別毎に抽出

しかし可視化した結果をどう判断するかはまだ人に委ねられている

例: このアクセス傾向は普段通りなのか、普段と異なるのか

例: この拒否された操作は問題ないのか、攻撃の兆候なのか

機械学習を使って自動的に判断できないか


機械学習に触れてみよう


機械学習とは？

機械学習に対して持っていた漠然としたイメージ

数式がたくさん出てきて統計学の知識が必要。難しそう。

大規模な並列分散処理を行う環境が必要。手が出しにくい。

しかし今ならクラウドサービスがある

理論やアルゴリズムを知らなくてもとりあえずは使える

覚えるのは詰まってからでも遅くない

自前で環境を用意する必要が無い

試行錯誤する段階では財布にやさしい

機械学習関連のクラウドサービスの例

Amazon Machine Learning

Azure Machine Learning

Google Prediction API / Cloud Machine Learning


機械学習でできること

教師あり学習

入力と対応する答えの例を大量に与えると、その法則を学習して他の入力に対しても答えを導き出す

例: あるアクセスログを見て、通常のアクセスか不審なアクセスか分類

例: バッチ処理の入力データを見て、そのデータの処理にかかる時間を推定

学習データの答えは事前に用意しておく必要がある

教師なし学習

大量の入力を与えると、それらの入力から関係性を見出す

例: 似た入力をまとめて複数のクラスタにグルーピングする

学習データに答えは用意しなくて良いが、機械学習から得られた結果が妥当かどうかは人が解釈する必要がある


今回の題材: AWS CloudTrailのログを用いた操作主体分類

AWS CloudTrailのログには様々なAPI呼び出しが記録される

人による操作

Management Console

CLI

連携させた外部サービス/スクリプトによる操作

AccessKey/SecretKeyによるスクリプト/外部ツール連携

Instance ProfileによるEC2インスタンス内からのAPI呼び出し

SAMLによる外部サービス連携

何らかのEventと連動したLambda Functionからの操作

AWS Config Rules

AWS CloudWatch Event

その他 S3/SNS/DynamoDB/CloudWatch Logs等との連携

それぞれで傾向は異なるため、操作主体を区別して可視化したい


ログの特徴

同一の操作でも操作主体や対象サービスによってログ内容が異なる

ec2:RunInstancesの場合

人がManagementConsoleから起動した場合

sourceIPAddress: 接続元IP

userAgent: signin.amazonaws.com

人がSwitchRoleした後ManagementConsoleから起動した場合


userAgent: console.ec2.amazonaws.com

人がManagementConsoleからMarketplaceのAMIを起動した場合

sourceIPAddress: marketplace.amazonaws.com

userAgent: marketplace.amazonaws.com

スクリプトからSDKを使って起動した場合


userAgent: 利用したツールやSDKのuserAgent

上記のような傾向は対象サービス毎にさらに少しずつ異なる


現状の課題

ルールベースでログから操作主体を区別するのが難しい

どんなログであれば人による操作なのか

Management Consoleでの操作の場合

userAgent = "signin.amazonaws.com"の場合？

他にも"AWS CloudWatch Console"とか"[S3Console/0.4]"とか色々ある

これからも新サービスが出るたびに増え続ける

ルール化できないこともない気がするが、ルールのメンテナンスで挫折することが目に見えている

結局使われているUser/Role名を見て判断する

このアカウントではこのUser/Roleはこの用途で使われているはず

この判断基準だと運用ルールに依存し、横展開が難しい

さらにRoleを追加するたびにフィルタルールの更新が必要に

Amazon MLを試してみよう


今回用意した学習データ

検証用AWSアカウントのCloudTrailログ

対象データ: 2016年6月に記録されたログ

対象データ件数: 7467件 (重複排除後)

学習用データ(70%): 5235件

評価用データ(30%): 2232件


前準備: 学習データの整形

CloudTrailのログをAmazon ML用に整形

JSONで記述されているログをCSV形式に変換

今回はアカウントの運用ルールに左右されにくい属性のみを利用

その他の属性はラベル付け時には参照したが、学習データには含めていない

属性名データ例

awsRegion ap-northeast-1

eventName RunInstances

eventSource ec2.amazonaws.com

eventType AwsApiCall

sourceIPAddress 52.197.67.xxx, lambda.amazonaws.com

userAgent awslambda-worker

userIdentity.accessKeyId (先頭4文字) AKIA, ASIA

userIdentity.invokedBy signin.amazonaws.com, (空値)

userIdentity.type IAMUser, AssumedRole


前準備: ラベルの付与

手作業で答えとなるラベルを付与

今回は以下の4カテゴリに分類

Human (人による操作)

Script (スクリプトや外部ツールによる操作)

AWSLambda (Lambda Functionによる操作)

AWSService (AWSの他のサービスによる操作)

分類毎のデータの分布


Amazon ML: DataSource登録

先ほど用意したCSVファイルをDataSourceとして登録

S3上にファイルを格納してファイルパスを指定

この後デフォルト設定で進めるなら、データは事前にシャッフルしておく

データの各属性のタイプを指定

Binary, Number, Text, Categorical

今回はUserAgentとSourceIPAddressがText、それ以外はCategorical

最後に機械学習で推定したい属性を指定


Amazon ML: Model作成

どのような学習モデルを生成するかを設定

今回はデフォルト設定を利用

今回は目的変数がCategoricalなので、多項分類が行われる

データは学習用(70％)と評価用(30％)に分割

後は評価用データを用いてEvaluationまで実施してくれる

簡単！


Amazon ML: Evaluation結果の確認

評価結果

同一アカウント、同一時期であればそれなりには分類できそう

分割した評価データ(左)では高い精度で分類できている

追加で翌月のログ2週間分もラベルを付与して評価した場合(右)は Scriptに関してはうまく分類できていないデータがあった

外した5件は学習データに含まれていなかったツールのログだった


Amazon ML: 追加の評価

では別のAWSアカウントのログの場合はどうなるか

開発に利用している別のAWSアカウントのログを1日分だけ借りてきて同様にラベルを付与

データ数3771件、このアカウントではAWS Lambdaは利用していない

評価結果は微妙な結果に

学習データには無かったスクリプトや外部ツールの分類精度が低い

しかし初出のスクリプト全てが分類できなかったわけではない

学習データには無かったCloudFormationから間接的に呼び出されるAPI呼び出しの分類精度が低い


評価結果を踏まえた改善

評価結果が出てからが機械学習の本番

機械学習を動かしてみるだけであれば、知識が無くても簡単

結果を解釈してどのように改善していくかは、知識が無いと厳しい

試してみたけれどぱっとしない結果のまま詰まってしまう

今回はどのように改善すべきか

学習データの多様性の向上

そもそも複数のアカウントへの適用を想定するのであれば、学習データも用途が異なる複数のアカウントから集めるべき

最も確実だと思われるが、手作業でのラベルの付与作業が負担に

ラベル付与を半自動化する仕組みが無いと厳しい

使い方の転換

学習データの元となったアカウントであれば精度が出るのであれば、まずはそのアカウントだけでしばらく運用し、他の課題を洗い出す

もう少し腰を据えて学習データをためる仕組みを作ってみよう


その他の試行錯誤してみた例


行き詰った事例1: 普段行われない外部への通信の検出

目的

AWSのVPC Flow Logsを使うと通信ログを記録することができる

InboundはSecurityGroupでしっかり塞いでいるが、Outboundの通信は検証用アカウントなので厳密に制御していない

常時稼動させているサーバの過去の通信ログを学習すれば、そのサーバが普段行わない不審な外部通信を見つけられないか

結果 (Azure MLでAnomaly Detectionを利用)

アクセス先が一定でないサーバでは、頻度の低い通信が検出される

正常な通信も不審な通信もHTTP(S)通信にしか見えず、傾向が出にくい

これはデータがより蓄積されれば、用途によってはパケット数や転送データ量で区別できるようになる可能性はある

アクセス先が一定なサーバであれば、ホワイトリストを作った方が早い


行き詰った事例2: 定常的なログと例外的なログの分類

目的

定常運用中のサーバは出力されるログもある程度一定である

エラーログは監視で検知するが、その他の例外的なログは拾っていない

過去のログメッセージを学習させれば、普段出ていないINFOやWARNINGのログをうまく分類できるのでは無いか

結果

過去にも出ていて学習データに含まれていた例外的ログに関してはメッセージが一部変化していてもほぼ正確に分類できる

学習データに含まれていない初出のログメッセージは分類が安定しない

普段発生しないログメッセージを学習データに含めるのは難しい


行き詰った事例の共通点

単一のデータだけを見てできることを考えている

人が判断する場合、一種類のデータだけを見て判断することは少ない

複数のログを確認して総合的に考える

運用設計の内容も踏まえて考える

メンテナンスなどのイベントも把握している

その時世の中で流行っている攻撃方法の特性も考慮する

データを見て適用先を考えていると、目的がぶれやすい

どのような課題を解決したいのかを決め、そのためにどのようなデータが役立ちそうか考えるべき

複数のデータが役立ちそうなら組み合わせてみる

判断に前提知識が必要そうであれば、事前に学習データに組み込んでみる

課題解決に必要なデータが足りなければ、まずはためる仕組みから

人が気付いていない法則を学習させるためには、多様性が保たれた大量の学習データを用意することが前提


機械学習に触れてみて感じたこと


機械学習に触れてみて (1/2)

人は様々な情報を組み合わせて判断を下している

今回のCloudTrailログを用いた例の場合

環境特有の知識

このIAM Roleはこの目的に使用している

このIPアドレスは社内からのアクセスである

過去に起こったイベントの知識

この機能はこの頃から使い始めた

こうした情報は機械学習で扱いやすい形式になっていない

Excelの設計書等にしか記載されていなかったり

本当に機械学習に代替させたい問題の答えは、扱いやすいデータとして記録できていない

教師あり学習では答えは事前に用意しなければいけない

答えに相当する、人の判断結果は意外と記録されていない

記録されていてもフォーマットが一定でない


機械学習に触れてみて (2/2)

実際に機械学習に触れてみると、データに対する意識が変わる

色々学習させてみると、こういう属性も取得してあればよかったのにと思うようになる

例: Apacheのアクセスログにこういう情報も含めておけばよかった

例: rsyslogの標準フォーマットではログに年の情報がなかった

重要なのは頻度の低い事象の記録

よく起こる事象はルールベースでも対応しやすい

学習データに無い事象に機械学習で対応させるのは難しい

少なくとも似た事象のデータが含まれていないと推測できない

単一のPJや組織で記録しているデータにはそれほど多様性は無い


機械学習との付き合い方

まずは試してみて、普段の業務におけるデータの捉え方を見直す良い機会とする

今見直しておけば、1年後にはデータの量や質に差がつく

何か人が判断を下したときは、その時の情報と下した判断結果を扱いやすい形式で残しておこう

今まで短期間分しか残していなかったログももう少しためてみよう

小さな問題から補助的に適用してみる

手元にあるそれほど多くないデータだけでもできることはある

過去に起こった事と同じ内容であれば高い精度で推定できる

新しく起こったことでも、それを再学習させれば次からは推定できる

ただし目的意識は明確に

目的を明確にしておかないと、何をKPIとして結果を評価すべきかが定まらない

別の方法で達成可能であるのであればそれで構わない


まとめ

インフラエンジニアにも機械学習は無縁では無い

運用現場には様々なログデータが存在する

知らなければどう活用してよいか検討できない

機械学習は怖くない

知識がなくても初期設定で動かしてみるだけなら簡単

どう活用するかのアイデアと、対象領域に関する知識が重要に

まずは試してみてどのようなものか知ろう

多分最初から役に立つものは作れない

ルールベースでも日常的な運用の大部分はカバーできている

非日常的なイベントを機械学習で解決するにはデータが足りない

データをためる仕組みを作るためには、知ることが重要

こういうデータもあればよかったという気付きが1年後の改善へ

ご清聴ありがとうございました

Technology

機械学習を用いたAWS CloudTrailログの積極的活用