OpsSecJAWS 第1回レポート #opssecjaws01 #opsjaws #secjaws #jawsug

こんにちは、坂巻です。

Ops-JAWSとSecurity-JAWSの合同開催イベント、OpsSecJAWS 第1回が開催されましたのでレポート致します。

• OpsSecJAWS #01 | OpsSecJAWSからはじまる異世界(AWS)狂想曲

レポート

AWS ConfigとSystems Managerのちょっといい話

登壇者 :Ops-JAWS 会澤 康二さん

• AWSの基本（責任共有モデル）
  • OSより下位レイヤーの部分はAWSで管理、それ以上は利用者責任者
• インベントリのすごいところ
  • OS以上の管理ができる（ログインなし）
  • 責任範囲は利用者だけど、AWSの機能を使って管理できるように
• AWS Config
  • 変更を追跡可能
  • OS内の変更まであとから何が起こったか追跡できる
• AWS Configみてますか？
  • Excelで出力する機能を作成
  • 構成は以下

• アウトプット(Excel)のイメージ

• Tips
  • イベントドリブンでやるにはCloudWatchEventsだが…
    • Inventory Resource State Changeだとインベントリ変更に反応しない
    • Config RulesのSSM：ManagedInstanceInventoryで対応する
  • 変更時以外も発火する
    • 新規インベントリ関連付け時や、起動・停止など
    • 厳密に「変更された時だけ」をトリガーしようとすると地味に条件は多い
    • ユースケースによってはスケジュール実行が無難なケースも
• まとめ
  • 宙ぶらりんな部分をなくす努力を
  • AWSの機能で実できるならガンガン使おう(今回はSystems Manager)
  • AWS Nativeが難しければ、既存ソフトとの併用を(今回はSystems Manager + Excel)
  • ツール化で煩雑な作業を減らそう
  • 環境と管理者は良き関係を維持しよう

AWS Config RulesでIAMポリシーを自動適用する話

登壇者 :株式会社サーバーワークス 齋藤 裕樹さん

• 前提
  • 複数のAWSアカウントを管理している
  • 操作されたくないリソースがある
  • 強い権限の付与、自由にポリシーを作成できない状態になった
• IAMリソースを作りたくなったら
  • 理想
    • 作る
    • 利用する
  • 現実
    • 担当者に依頼
    • 担当者が作業
    • 確認
    • 利用する
• 改善が必要
  • スピード感を改善
  • 最低限の制限はかけたい
• 特定のポリシーを自動的にアタッチすればいいのでは？
• ConfigRulesでカスタムルールを作ろう！
• こういう仕組み

• カスタムルールを選んだ理由
  • IAMリソースの作成、変更の検知が楽だから
• Lambda Function
  • 特定のポリシーがアタッチされているか評価
  • アタッチされていなければアタッチして再評価
  • 全てCOMLIANTになるようにする
• ポイント
  • 処理用のAWS Lambdaは管理用AWSアカウントに置く
    • 修正が用意
    • アプリログも分散しない
    • 各アカウントのユーザーが触れない
  • アタッチするポリシーではそのポリシー自身の操作を制限する
    • ポリシーの中身を修正されてしまったら元も子もない
  • ポリシーのデタッチはできるようにしておく
    • リソースの削除ができなくなってしまう
• 結果こうなった
  • Before
    • 管理者に依頼
    • 管理者が作業
    • 確認
    • 利用する
  • After
    • 自分で作業（自動でポリシーアタッチ）
    • 利用する
• まとめ
  • AWS Lambdaがあればなんでもできる（たぶん）
  • ConfigRulesは想像以上に簡単に使える
  • 自動化してみんなハッピー

AWS WAFの初心者向け最初の一歩

登壇者 :Security-JAWS　臼田 佳祐

弊社、臼田の登壇です。

内容は以下となります。

Security Operations and Automation on AWS

登壇者 :アマゾンウェブサービスジャパン　関山 宜孝さん

• 3つのユースケース
  • QuickSightとAthenaを使ったCloud Trail/VPC Flow Logsに基づくセキュリティ分析
  • CloudWatchイベントバスによるセキュリティ自動化
  • Systems ManagerとConfig Aggregatorによるコンプライアンス管理

QuickSightとAthenaを使ったCloud Trail/VPC Flow Logsに基づくセキュリティ分析

• AWS CloudTrail
  • AWSユーザの操作をロギング
    • ユーザーのアクティビティ（APIコール、コンソールサインイン）を記録・トラッキング
  • ログデータは複数箇所に保存し活用可能
    • CloudTrailイベント履歴（過去90日間/管理イベントのみ）
    • S3(無期限)
    • CloudWatch Logs（無期限
• Amazon Athena
  • S3上の複数ファイルに対して標準SQLでクエリを実行可能
    • 分散処理エンジンとして presto を利用
  • サーバレスで運用コストがかからない
  • クエリでスキャンしたデータの分だけ重量課金
• Amazon QuickSight
  • AWSの各種サービスと統合されたBIツール
  • データの可視化、アドホック分析、ダッシュボードの作成などをサポート
  • ユーザーによるアクセスについてのみセッション単位の料金で課金

セッションではどのようなサービスを利用していたか、ソースIPはどこから多いのか等、QuickSightのデモがありました！

• VPC Flow Log
  • トラフィックをキャプチャ
    • VPCのネットワークインタフェースとの間で行き来するIPトラフィック情報をキャプチャ
  • ログデータはCloudWatch Logsに保管
    • CloudWatch LogsのVended Log対象なので通常のCloudWatch Logs料金よりも割安
  • トラブルシューティングやセキュリティなどの目的で利用可能

以下のようなVPC Flow Logが…

Athenaにいれて、QuickSightにいれると以下のような出力になります。

• 本格運用に向けて
  • 最初はAtenaフルスキャン or QuickSight で SPICEにインポートするところからスタート
  • 大規模でインクリメンタルに増大するログも対象にするならコストとパフォーマンスを最適化するためにGlueによるファイルフォーマット変換・パーティショニング推奨

CloudWatchイベントバスによるセキュリティ自動化

• Amazon CloudWatch
  • AWSサービスやリソースをモニタリング
    • メトリクス…AWSサービスのメトリクスやカスタムメトリクスを保管、グラフ描画、再利用
    • アラーム…メトリクスに対して設定し、しきい値をもとにアクション(SNS、AutoScaling、EC2を実行)
    • ログ…AWSサービスのログやOS、アプリケーションのログ
  • イベントバス
    • アカウント間でイベントを送受信
• アカウト間のイベント送受信に必要なステップ
  • 受信側でのイベントバス設定
    • 送信側アカウントから送信されたイベントの受信を許可するようイベントバスを設定
  • 送信側のルール設定
    • 受信側アカウントのイベントバスをターゲットとする1つ以上のルールを設定
  • 受信側のルール設定
    • 送信側アカウントからのイベントに一致する1つ異常のルールを設定
• 本番運用に向けて
  • まずはセキュリティ・運用の観点で重要なイベントを集めて通知するところから
  • CloudWatch Events - Lambda連携で変更系の対応をリアルタイムに実装する場合は、本番システムへの影響範囲等、十分に事前検証する必要あり

Systems ManagerとConfig Aggregatorによるコンプライアンス管理

• AWS Systems Manager
  • インフラストラクチャを可視化し制御
    • システム設定、OSパッチレベル、ソフトウェアインストール状況等をダッシュボードで確認可能
    • メンテナンスやデプロイ等のタスクのオートメーションが可能
  • ハイブリッド環境の管理
    • AWS上のリソースだけでなくオンプレミスのサーバ管理も可能
• AWS Config／Config Rules
  • AWSリソースのレポジトリ情報から、リソースの変更履歴、構成変更を管理
    • 構成情報は定期的にスナップショットとしてS3に保存
    • 必要に応じSNSを使った通知も可能
  • 構成情報を元に、現在のシステムがあるべき状態になっているかを評価
    • AWS マネージドルール
    • カスタムルール

セッションではConfig Aggregatorのデモがありました！

まとめ

• Security Operations and Automation on AWS
  • AWSサービスをうまく活用して予測→防御→検知→対応のサイクルを回していきましょう
• 3つのユースケース
  • QuickSightとAthenaを使ったCloud Trail/VPC Flow Logsに基づくセキュリティ分析
  • CloudWatchイベントバスによるセキュリティ自動化
  • Systems ManagerとConfig Aggregatorによるコンプライアンス管理

パッチマネージャ - そこに在る、ビジネスを最高に加速させるヒント -

登壇者 :Ops-JAWS 伊藤 覚宏さん、Security-JAWS 吉田 浩和さん

本番と検証とテストの話

• 本番環境と検討環境分けてますか？
• なんで、分けるんだっけ？
• NIST SP800-53 CM-4 セキュリティ影響分析

拡張管理策：(1) セキュリティ影響分析 | 切り離されたテスト環境 情報システムに対する変更を本番環境で実施する前に、そうした変更を本番環境とは切り離されたテスト環境で分析し、欠陥・弱点・互換性が無いこと、あるいは意図的な犯意に起因するセキュリティ影響を組織が特定する。

• NIST SP800-53 CM-5 変更に対するアクセス制限

拡張管理策：(5) 本番環境における権限を制限する 組織は、 (a) 本番環境内の情報システムコンポーネントとシステム関連情報を変更する権限をに制限する (b) 権限のレビューと再評価を［指定：組織が定めた頻度で］行う。

変更に係るドキュメント管理の話

• ドキュメント管理してますか？
• なんでドキュメント管理するんだっけ？
• NIST SP800-53 MA-2:管理されたメンテナンス

a. 製造業者またはベンダーの仕様書および／または組織の要求事項に従って、情報システムコンポーネントのメンテナンスと修理を計画、実施、文書化し、記録をレビューする b. メンテナンス活動が現地で行われるか、遠隔で行われるかにかかわらず、また、その機器が現地でメンテナンス／修理を受けるか、別の場所に移動されてメンテナンス／修理を受けるかにかかわらず、すべてのメンテナンス活動を承認し、モニタリングする e. メンテナンスまたは修理後に、影響を受けた可能性のあるすべてのセキュリティ管理策をチェックして、それらの管理策が正しく機能しているかどうかを確認する f. ［指定：組織が定めた、メンテナンス関連情報］を組織のメンテナンス記録に含める。

• Why? Japanease People !?
  • 提案できないのはなぜ？
  • ビジネスの個性や特性など、判断できる材料が少ないから？
  • AWSは便利な機能が豊富なのに、使いこなせない
• Tips for business acceleration
  • 監視で異常に気づいてｍ，速やかに戻す段取りは整えておく
  • そのシステムにおいて、何いが正常であるか、何が異常であるかがわからないと監視できない
  • セキュリティにおいても同じことが言える

ビジネスを加速させるのはいつでもあなた自身

さいごに

セキュリティとその運用について、様々な話を聞くことが出来ました。デモを通して、そんな事もできるのかと思う場面もありました。Ops-JAWSとSecurity-JAWSの合同開催は始まったばかりです、少しでも興味がある方は、参加してみてはいかがでしょうか！！