[レポート]AWS によるセキュリティ・オートメーションの実践 #AWSSummit

今日は2018/05/30より3日間に渡って東京で開催されている「AWS Summit Tokyo 2018」からセッションをレポートします。 このレポートはTech中級 「AWS によるセキュリティ・オートメーションの実践」です。スピーカーはアマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの桐山 隼人氏です。

レポート

セッションのポイント

1. クラウド時代に必要なオートメーション
2. セキュリティオートメーションのパターン
3. オートメーションによるセキュリティ対策のユースケース

クラウド時代に必要なオートメーション

従来のセキュリティ業務

従来はセキュリティポリシーやルールへの準拠が主眼で、スプレッドシート、ポリシー文書、チェックリストなどを使う。 大きな労力が必要な作業がオートメーションによって、削減できる。

自動化しなければならない重要な理由

• 拡張性（セキュリティの自動追従）
  • 従来は先にITがあり、後からセキュリティを追加していた。その間にはリスクが存在する
  • ITとセキュリティを同時に投入しないと、セキュリティが軽んじられる
• コスト（労力・時間の削減）
  • クラウドを使うということは、将来必要なリソースがわからないということ。オンプレミスと違って、毎分、毎日など変動する
  • 変動するリソースを継続的に評価するために、自動化が必要になる
• 信頼性（品質の担保、人為的ミスの排除）
  • データは人を介さない。人はツールの開発に注力する。

自動化の最小パターン

入力（トリガー）＞評価（チェック）＞実行（アクション）を、人を介することでなく、流れていく形が最小パターン。

セキュリティにおいて実行したいこと（例）

• 入力
  • システム障害
  • 構成変更
  • DDoS
  • 不正通信
• 評価
  • IPアドレス
  • ポート
• 実行
  • 管理者への連絡
  • パッチの適用

セキュリティにおいて実行したいこと（種類）

• 入力
  • メトリクスベース（閾値、異常検知）
  • イベントベース（任意、定期）
  • ルールベース
• 評価
  • 取得
  • 解析
  • 比較
  • 演算
• 実行
  • 通知（レポート）
  • 確認（スキャン、棚卸し）
  • 修正（パッチ適用）
  • 対応（隔離、タグ付け）
  • 分析（ログ解析）

実現するAWSサービス

AWS Lambda

評価をLambdaで行う

• Lambda = サーバレスのコード実行環境
• Lambda Function = 実行するコードと構成情報

セキュリティの評価はキャパシティプランニングが難しいので、サーバレスと相性が良い

セキュリティリスク要因

リスクベースアプローチで考える起点

脅威

外からの脅威。標的型攻撃、マルウェアなど

脆弱性

セキュリティホール、設定ミスなど

情報資産

機密情報、個人情報など

脅威にまつわるセキュリティオートメーション

AWS WAF

ウェブアプリケーションを保護するファイアウォール

AWS Firewall Mangaer

AWS WAFルールの設定を一元管理するサービス。 アカウントなどが増えてきたときに、利用する。

アプリ層へのDDoS攻撃を緩和

メトリクストリガーの例

ALB、CloudFrontでアクセスを受ける。 アクセスログをS3に配置される。 S3にログがPutされることをイベントとして、Lambdaを発火する。 閾値を超えたエラー数にひもづくIPアドレスを特定し、AWS WAFのIPブロックルールに追加する。

イベントトリガーの例1

Lambdaを定期的に実行してLambdaを実行し、SpamhausのDROPリストなどを取得。 IPアドレスを基にブロックルールを追加する。 IPアドレスは鮮度が必要なので、CloudWatch Eventで定期的にLambdaを実行する。

イベントトリガーの例2

人間ではアクセスしないハニーポットを作成しておく ハニーポットはAmazon API Gatewayで作成する。 Lambdaでアクセス解析し、ソースIPを取得する。LambdaでIPアドレスのブロックルールを追加する。

イベントトリガーの例3

Amazon GuardDutyを使う。脅威検知と継続的監視ができる。 マスターアカウントにメンバーアカウントの情報を集約する。 メンバーアカウントのポートスキャンを検知したら、CloudWatch EventからLambdaを発火する。 Lambdaはポートスキャンは優先度が低いと判断し、管理者に通知のみ行う。

イベントトリガーの例4

Amazon GuardDutyでは、C&Cサーバーとの通信を検知できる。 重要度が高いので、AWS Systems Manager Run Commandを実行し、3rd Partyのアンチマルウェアでマルウェアを駆除する。

イベントトリガーの例5

不正ユーザーによるなりすましもAmazon GuardDutyで検知できる。 不正なAPI呼び出しを検知したら、Step Functionを呼び出し、ワークフローを自動実行する。 管理者への通知、該当ユーザー権限制限、過去の操作ログ分析といったことを実行する。

脆弱性にまつわるオートメーション

AWS Config

AWSリソース設定変更の継続的記録

AWS Config Rules

企業ポリシー準拠の継続的監査と評価

セキュリティポリシー準拠の確認

許可されていないライブラリの検知

AWS Systems Manager InventoryとAWS Config Rulesを使って、会社が許可していないライブラリを使っていないか確認する。 違反のあった場合、自動で管理者に通知できる。

診断からパッチ適用までの自動化

Inspectorで脆弱性診断を行う。 脆弱性があった場合、SNSからSystems Manager RunCommandを実行し、パッチ適用する。

データ重要度に基づいたポリシー実行

あるユーザーがS3に機密情報を配置してしまったとする。 Macieで機密情報が配置された旨を検出する。 CloudWatch Eventで検出結果を取得、Lambdaを発火し、S3のポリシーを変更したり、サーバーサイド暗号化などを行う。

適用型セキュリティアーキテクチャ

予測、防御、検知、対応のサイクルを回す必要がある。 継続的監視と対応が必要になる。

AWSのセキュリティオートメーションは、AWSの様々なサービスを組み合わせることで実現する。 インシデントが発生してからの対応完了までの時間を短くできる。

まとめ

クラウド時代にはセキュリてオートメーションが不可欠である。 セキュリティオートメーションのパターンを紹介した。

おわりに

クラウドではAuto Scalingに代表されるようにリソースが変わり続けるため、セキュリティオートメーションが必要であることがわかりました。