機械学習を用いた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年後の改善へ

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

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

More Related Content

What's hot

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

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