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

こんにちは、臼田です。

本記事は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時間ブロックする処理が走ってくれればいい
  • それを実装する

• 他の脅威検知はCloudTrailがベース
  • 集中型ロギング
  • すべてのリージョンを取得する
• アラートの拡張
  • IDではなく名前をつける
  • IPは各種ログを活用

• インシデントレスポンス
  • まずは封じ込め
  • EC2やユーザへのアクセスを防ぐ
  • セキュリティグループで隔離する
  • 分析サーバからのみアクセスする

• インシデントレスポンス(続き)
  • ライブレスポンスコレクション
    • フォレンジックを行う
    • SSMを利用する

• アーキテクチャは図の通り
  • 隔離後のアクセスはアナリスト用のEC2から

• IRのツールを実行する

• Windowsの場合の選択肢

• 検知と対応を紹介した
  • 本当にAWSは沢山のサービスやツールを提供している

• 次はどうするか
  • クラウドは成熟していた様々なサービスが有る
  • 脅威検知や対応が埋め込むと影響が軽減します
  • コンテナやCI/CDやDevOpsパイプラインが狙われます
  • インシデントレスポンスもコードで管理しましょう

まとめ

GEという大企業がいかにしてセキュリティに注力しているかよくわかりました。

大規模な管理には、特にAWS上で実装できる自動化された仕組みは強力でしょう。アカウントの払い出しなどのガバナンス部分もそうですし、インシデントレスポンスでも様々な自動化の工夫がされていました。

最近ではAWSとしてLandingZoneという大規模環境におけるアカウント管理の考え方が提唱されていますが、これに準じるものがありました。

今後はAWS Control Towerも発表されたので、こちらを利用してもっと簡単に管理できるようになりそうですね。

[新サービス] AWS Control Tower (Preview) が発表されました！ #reinvent

GEの例も参考に、沢山自動化してAWSの恩恵を受けまくりましょう！