[レポート]SEC319: エンタープライズ企業のセキュリティ要件をAWSのネイティブセキュリティ機能で満たす #reinvent

re:Invent2018 SEC319のセッションレポートです。ゼネラル・エレクトリック社がエンタープライズ企業として持つ高いセキュリティ基準に対してAWSのネイティブセキュリティ機能を活用した事例を通して、大企業がクラウドで加速するためのノウハウが紹介されました。

AWS re:Invent 2018

#AWS

#セキュリティ

臼田佳祐

2018.12.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

本記事はAWSの一大イベントであるre:Inventの下記セッションについてのレポートです。

SEC319 - Meeting Enterprise Security Requirements with AWS Native Security Services

GE has very deep security requirements for their cloud applications. In this session, hear their story on replacing on premises complex solutions with AWS native services like Amazon GuardDuty, VPC Flow logs, AWS CloudTrail, and AWS Config rules. Learn how large enterprises can accelerate their cloud adoption by meeting established security standards with AWS native services. Please join us for a speaker meet-and-greet following this session at the Speaker Lounge (ARIA East, Level 1, Willow Lounge). The meet-and-greet starts 15 minutes after the session and runs for half an hour.

Saurabh Saxena - Principal TAM , AWS Enterprise Support, AWS David Strum - Senior Staff Incident Responder, General Electric Thomas Wold - Principal Architect, AWS, General Electric

大企業ゼネラル・エレクトリックが高いセキュリティ要件を満たすためにどのようにAWSネイティブセキュリティ機能を活用しているかが紹介されました。

資料・動画

[slideshare id=124453364&doc=meeting-enterprise-security-re-1944a8d6-9309-4e1d-936c-55216fafee51-591953301-181130023326]

レポート

アジェンダ
- 毎日直面している課題
- クラウドとクラウドの中のセキュリティ
- AWSセキュリティサービスの概要
- クラウドでの資産管理の自動化
- 予防的な防御
- 脅威検知の運用
- インシデントレスポンス
管理運用についてはGEのThomas氏から、セキュリティオペレーション面は同じくGEのDavid氏から話す

主な要点
- AWS環境のセキュリティとワークロードのセキュリティを理解する
- 環境を可視化し、それを利用する方法を理解する
- 脅威の検出とインシデント対応を自動化する方法

AWSセキュリティの話

AWSの責任共有モデル
- AWSとユーザの責任分界点を明確にした図
- AWSはクラウド自体のセキュリティを保つ
- ユーザはクラウド上のセキュリティを保つ
- AWSの責任部分についてはSOCなどのコンプライアンスレポートを取得することが可能
- クラウド上にあるデータやアクセス制限などはユーザが管理する必要がある
- しかし、ユーザが管理しやすい仕組みを沢山用意している
  - 中央集権するための機能
  - OSのパッチ適用
  - ネットワークのファイアウォール
- これらをユーザの責任で利用していく必要がある

AWSのセキュリティソリューション(一部抜粋)
- アイデンティティ
  - IAM
  - AWS Organizations
    - 組織の管理
    - ポリシーを決めて責任範囲を決めることができる
    - 外部の承認者を設定することもできる
  - Cognito
    - モバイルアプリのユーザベース
  - Directory Service
  - AWS SSO
- Detective control
- インフラセキュリティ
  - どのように活用していくかは後ほど
- データ保護
  - KMS
    - 暗号鍵管理
  - CloudHSM
    - HSM(Hardware Security Module)
- インシデントレスポンス

AWSサービスとの連携
- 一般的なフレームワークとの突き合わせ
- アイデンティティを積極的に保護するには？
- 脅威を検知したい
- 検知した後は自動的に対応してアプリケーションを正常な状態に保ちたい

アイデンティティ
- CloudWatch
  - メトリクス・ログの管理
  - アラームを上げることも可能
- Systems Manager(SSM)
  - EC2のパッチ適用などを行える
- CloudTrail
  - クラウドAPIの履歴を管理する
- AWS Config
  - 設定の変更の監視
  - 変更時にアクションを実行
- GuardDuty
  - アカウントやネットワークの異常を検知
- Inspector
- Shield
- Macie
- VPCフローログ

保護
- IAM
  - アイデンティティの保護
- SSM
- Shield
- AWS WAF
  - 特定のIPからのアクセス保護等
- ACM(AWS Certificate Manager)
  - 退屈な証明書更新作業からの開放
- VPC / Security Group / NACL
  - ネットワークの保護

検知
- Inspectorでは脆弱性の検知やアセスメントが可能
- MacieはS3にアクセスしているパターンを見て判断する

レスポンス
- CloudWatchなどからイベント検知時にLambdaをトリガーできる
- Lambda関数で自動化されていれば毎回同じ処理が自動的に実行される
- Step Functionsを利用すればより簡単にLambdaを組み合わせて利用できる
- SSMではメンテナンスウインドウの設定やパッチの適用が可能

復旧
- Lambda / Step Functionsで復旧を自動化
- 復旧したことをSNSで通知
- メールでもhttpでもiOSへのプッシュも可能
- 今回発表したカスタムランタイムにより、より沢山の言語でLambdaを実行することもできる

もう一度この図に戻る
- 資産と資源を中央で管理する
- 脅威を検知して対応する
- なるべく自動化する
- 如何に自動化するかをこれからGEのThomas氏が紹介する

GEのセキュリティの話

Thomas氏
- ホスティングチームと設計を担当した
- 今で言うガードレールやLandingZoneを実装した

GEはとてもスケールがでかい
- 180カ国・4,000以上のロケーションがある
- 新旧様々なアプリケーションが入り交じる
- 500ものAWSアカウントで3,000を超えるアプリを利用
- おそらくほぼすべての規制機関の影響を受ける

GEのクラウドジャーニー(クラウド移行の設計)
- チーム間にも責任共有モデルを適用
- SLAはセルフサービス(チケットでのやり取りはスケールしない)
- コンプライアンス要件は業種・お客様ごとに個別
- なるべく軽量に使う

GEのテナンシーモデル
- 大きく3つの役割に分類される
  - Restrictedアカウントは組織のマスター
    - アカウントの払い出しやCMDB・資産の管理
    - 中央集権で管理する必要があるものを集める
  - 管理者アカウント
    - 課金やログ・セキュリティ等用途ごと分ける
  - アプリケーションチームアカウント
    - 顧客に提供するアプリごと分ける

これらのネイティブサービスを利用している
- 単一アカウントに対して一通り設定して払い出す
GEのシェアードサービス
- アカウントプロビジョニング
  - 統一された設定
- アセットマネジメント
  - ニアリアルタイムで取得
  - configによる変更の通知も受け取る
- ボット
  - イベント駆動での構成変更とリアルタイムの修復
- バージョン管理
  - IAMの管理はNetflixが開発したオープンソースのaardvarkを利用している

デモ: 簡単に新しいアカウントを払い出した
- API Gatewayで受け取ってLambdaやDynamoDBを利用している
アカウント払い出し時のCloudTrailの構築例
- SQSに必要な情報を入れる
- Lambdaで取得して構築
GuardDutyはマスターアカウントから招待を受けメンバーとなる動きが実装されている

Organizationsで設定するサービスコントロールポリシーの一部
- CloudTrail等は管理側で払い出し時に有効化しているので一般アカウントでは操作の必要がない
- DirectConnectは確認と許可をとってからとするのでデフォルト無効化

ここまででアイデンティティの管理とどのようにログを取っていくかを紹介した
すべてのリソースを自動的に中央で管理し、APIを通じて素早く情報にアクセスできる
アカウントが払い出されたらそれはセキュアでありすぐ利用できる
この先のセキュリティの内容についてはDavid氏が紹介

GEのセキュリティ運用

David氏はGEでCIRTに所属している

GEのセキュリティクラウドジャーニー
- 何を知らないといけないのか知らないといけない
  - オンプレミスの脅威検知とは違う
- どのような脅威を検知する必要があるのか確認する
- どのレイヤーを見る必要があるか認識する
- 脅威検知やレスポンスは自動化する
- 責任共有モデルなのでEC2で何が起こっているかを確認する必要がある
- OSレイヤーはユーザの責任

1年ほど前、実際にインシデントが発生していた
- GuardDutyを早期に導入して500以上のすべてのアカウント、14リージョンに展開した
- 様々なアカウントがあるのでアナリストが監視できる場所に情報を集約した

GuardDutyのログパイプラインがこちら
- シンプルにメンバーとマスターがいる
- マスターではログを加工して保存したり外部通知したりしていた

初期段階ではその内容が本当に必要かどうか知る必要がある
ベースラインがわかり必要ないログがわかったらそれをフィルターして、必要なもののみ通知するようにする
そしてプレイブックを考える
- CloudWatchやLambda/StepFunctionsで実装する
- SSHやRDPのブルートフォースは一定確率で発生する
- これらの通知はほしいわけではない
- 例えば自動的にそのIPを24時間ブロックする処理が走ってくれればいい
- それを実装する