【イベントレポート】知らない間に使われていませんか？AWSの利用監査対策 #jawsug #jawsdays

今年の2月にAPN Reference of the yearを受賞されたオージス総研 多田様のセッションイベントをレポートさせて頂きます。

セッション概要

[General] 知らない間に使われていませんか？ ～AWSの利用監査対策～

登壇者

株式会社オージス総研 多田　友昭様

オージス総研とは

• 親会社は大阪ガスとなる
• 情報システム部門が独立して出来たものがオージス総研となる
• 主に公共インフラのシステム構築、ガス供給の運用システムの安定稼働を行っている
• ２月の末に発表されたAWS Partner NetworkのReference of the Yearを受賞している
  • 大阪ガスのエネファームのデータをアップして見える化、スマホでの遠隔操作、故障予知などに使われるソリューションを作成したことで受賞した

システム運用で実施すべきこと

システムを運用するにあたって以下4点が必要と考えられる

• 監視
• ロギング
• バックアップ
• 構成管理

ロギングについて

• ログを取ることで何が起こっているか分かる
• ログが取れると何が出来るのか？
  • どのような操作が行われているのか？
  • モニタリングによるシステム等の異常検知
  • 障害、問題発生時にログから原因究明を実施
  • 社内規定等に準拠しているのかを確認
    • プロキシの日次ログから通信先の特定など

取得対象のログについて

取得対象のログが対象となるのか？を考えた。

• システムログ
  • OS
    • /var/log/messagesなどOSレイヤーの動作ログ
  • ミドルウェア
    • ApacheやMySQLなどミドルウェアの動作ログ
  • アプリケーション
    • アプリケーションの動作ログ
• 監査ログ
  • OSへのアクセスログ
  • DBのAuditログ
  • ID管理のライフサイクルログ

これまでのオンプレ環境のログは上記までだったが、クラウドの世界に当てはめるとで次のようなログ取得も取る必要がある

• AMCへのアクセスログ
  • AMCの操作ログ
  • 各AWSサービスログ
    • S3やELBなどのログを取る

取得対象ログより、下記2点で利用監査を実現しようと考えた

• CloudTrailのログを使用して利用監査を実現する
• OS(Bastion)ログを利用して利用監査を実現する

CloudTrailのログを使用して利用監査を実現する

• セキュリティ部門として実現したかったことは、「不正と思われる操作があれば、リアルタイムにアラート通知を行う」であった
  • では、不正とする操作は何が該当するのか？
    • CIS(Center for Internet Security)セキュリティベンチマークにAWSのものがある
    • あなたのAWSセキュリティ監査状況を採点〜CISベンチマークを読んでみた
    • 主に「3章 monitoring」がScoredとなっている必須項目をアラート通知項目として考えた
      • unauthorizedやMFAなどベンチマークで言われていることを不正操作の対象とした
      • 合わせて社内セキュリティ部門からの社内規定を確認した
        • IGWの変更
        • EIPの変更
        • SGの変更
    • ロギング対象のログは40前後とし、帰ってロギング対象が多すぎるとオオカミ少年になるので注意した
    • しかし、CloudTrailのCloudWatchだけでは実現できなかった
      • 一分以内に同じ操作があっても検知できなかった
      • CloudTrailのログ出力タイミングは5分間隔のため、リアルタイムとはならない
    • 作業影響によるイベントを把握しているにも関わらず特定の時間を抑止することが出来ず、不正と思われるイベントが入ってきてしまった
    • CloudWatchのアラート通知の内容をカスタマイズしたかった
      • 非SEでは敷居が高かった(英語だらけ)
      • カスタマイズして日本語を入れるようにしたかった
    • アラート時、IAMユーザー権限を外したかった
    • 上記を考慮して検討されたアラート通知のアーキテクチャは以下のようになった
      • Cloudtrail ---> CloudWatchLogs ---> Lambda ---> SNS
    • CloudTrailの機能ではリアルタイムアラート通知は実現できない
  • インシデント発生時の原因究明のため、ログを可視化・検索(準備をしておく)
    • CloudTrailのログ可視化、検索機能は利用の難易度が高い
    • sumologicを使って可視化、検索、レポートを実現
      • SaaSログ分析
      • sumologic自体もAWS上で構築されている
      • AWSサービスの各種ログ分析テンプレートを標準提供
      • OS,ミドルも見れる
      • ダッシュボード、クエリ検索、レポート機能
      • 機械学習
  • 定期的なモニタリングのため、レポート作成(しかるべきところで確認、管理を行う)
    • 定期的なレポート出力がない

なぜsumologicを採用したか

• 新しいものにチャレンジしたかった
  • splunkなど色々使われている所が多かった
  • SaaS型でやりたかった
    • APIで操作出来るのは非常にやりやすい
  • 機械学習に対応している
    • 回帰分析利用できる
    • LogReduceを見てスコア付をして大量のログからスコア付していないものをキャッチアップするような機能
    • AWS回りのログ分析テンプレが揃っていた
    • sumologicは無料枠があるので触るのはいいかも

作成されたアーキテクチャ

CloudTrailログ --> S3 --> sumologicが定期的にS3ログを取得して確認

• sumologicは日時レポート(HTML形式)で送付
• 日時レポートで操作レポートが取れる

OS(Bastion)のログを利用して、クラウドの利用監査を実現する

• Bastionのサーバーアクセスを確認して、ログイン成功/失敗等をリアルタイムアラート通知する
• ログ可視化
• レポート作成

これまでの仕組みを使っている事例

宅ふぁいる便サービス

宅ふぁいる便

• 大容量ファイル転送サービス
• AWSで動作している
• AWS操作権限を持つ運用担当者が未承認作業を実施していないか、時間外作業をしていないか監視

• セキュリティ部門のリクエストに対して、AWSの利用監査の仕組みを作った

• CloudTrail,Lambda,SNSなどを使ってアラート通知と、可視化、レポート作成の仕組みを作った

最後に

監査対応にて重要になる点を網羅されており、その中でどのように扱うべきか悩ましいログファイルについてとても貴重なセッションでした。
ログファイルより、得られる情報は大きいもので問題発生時の手がかりとして重宝するものです。
今回はただログを取得するではなく、監査に対応する事と仕組みとしてユーザーに見てもらうということが分かりやすく纏まったセッションと思いました。