【レポート】AWSにおける継続的なセキュリティモニタリングの実践：AWS Summit Osaka 2019 #AWSSummit

本ブログは2019年06月27日に行われたAWS Summit Osaka 2019のセッションレポートです。

『AWSにおける継続的なセキュリティモニタリングの実践』のセッションをリモートで聴講したので内容をレポートしたいと思います。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 プラクティスマネージャー 高田 智己

AWS環境のメリットを最大限活用しようとしたとき、従来と同じアプローチでの構成・変更管理では運用しきれません。AWSのメリットを最大限に活用しつつ、どのように各システムのコンプラアインスを維持していくのかをご紹介します。

レポート

• セキュリティと監査における現在の課題と継続的コンプライアンス
• セキュリティポリシー準拠への典型的な4ステップ
  • セキュリティ要件の分析 → 統制要件の定義と文書化 → チェックリスト → 監査
• 準拠に向けてお客様が行う業務の例
  • 統制要件
  • 監査プロセス
  • チェックリスト(情報セキュリティ
  • 問診/文書スクリーンショット(監査人
• 一般的なセキュリティと監査の課題
  • サンプリング抽出によるアプローチ
  • ある時点の状態でのアセスメント
  • 信頼性の低い証跡と収集手順
  • 人手による確認作業
• 継続的コンプライアンスとは
  • 継続的モニタリングによる検知性・可視性の向上 ＋ ほぼリアルタイムの対応自動化
• 継続的コンプライアンスによる３つのベネフィット
  • 日々の業務への監査の組み込み
  • スケールによる環境に対する一貫性のある監査
  • 付加価値の高い業務への時間と人的リソースへの集中
• 継続的コンプライアンスに取り組むお客様事例
  • National Australia Bank
    • NABの中で継続的コンプライアンスソリューションを構築している
    • AWS上のワークロードのセキュリティコンプライアンスをシステマティックかつ継続的にレビューしている
    • セキュリティコントロールの導入にかかる時間を従来の１９日間から４５秒に短縮
• 継続的コンプライアンスを導入する５つのステップ
• 継続的コンプライアンスへの２つのアプローチ
  • １. チェックリスト → チェック作業の自動化
  • ２. 監査 → 継続的なモニタリング
• セキュリティポリシー準拠への新しい５ステップ
  • セキュリティ要件の分析 → 統制要件の定義と文書化 → チェックリスト → チェック作業の自動化 → 継続的なモニタリング
  • チェック作業の自動化とAWS環境にBuilt inされたモニタリング機能の活用により、より高度な統制環境の実現をはかる

Step.1:セキュリティ要件の分析

• 目的：セキュリティ要件とAWSの特性の分析
• 進め方：AWSの責任共有モデルを念頭に、利用者の統制要件、AWSの統制情報、AWS及びAPNパートナー様の提供するセキュリティ機能を把握する
• 責任共有モデルの理解
  • 従来の統制目標に対して、利用者側が統制すること、AWSが統制することの責任境界の確認をすることがはじめの一歩
• AWS Artifactの活用
  • AWSの統制に対する信頼の根拠として第三者機関の各種レポートを取得し、自社の統制目標を満たすことができるか確認する
• AWSのセキュリティ関連サービス/機能の把握
  • AWSのセキュリティサービスの機能を把握し、利用者側での統制に活用

Step.2:統制要件の定義と文書化

• 目的：セキュリティ要件に対する、責任分担とセキュリティ対策の定義を行う
• 進め方：各要件に関する対応指針を責任共有モデルに基づき記載する
  • AWS内の統制状況と根拠
  • 利用者側で行う必要のある対応方針
• 各種リファレンスアーキテクチャーの活用
  • 要求事項に対する検討事項と対応指針のマッピング資料をまとめたもの
  • 各種標準の要件に対して責任共有モデルを前提にした検討事項のマッピングを参考にすることで自社の要件にも活用することが可能
• AWS Quick Starts Security & Compliance
  • 各種標準に準拠した環境のデプロイ用テンプレートを提供
  • Quick Startsでも様々なセキュリティ要件への対応をまとめたマトリックスが提供されており、定義と文書化の作業の参考にすることができる

Step.3:チェックリスト

• 目的：対策状況に関する確認項目の整理
• 進め方：対応指針に則っていることを確認する手段について各項目についてまとめていく
• CIS Benchmark等の活用
  • CIS Benchmarkは、米国政府、企業、業界、学術機関のエキスパートが開発したコンセンサスベースの設定ガイドライン
  • 様々な領域でAWSのセキュリティに関するどのような項目を、どのような手段で確認すればよいかを確認できる
• チェックリスト作成の流れ
  • 対応指針の文書化
    • アプリケーションの設計や運用について確認する項目
    • AWSサービスの設計や運用について確認する項目
    • AWSについての統制情報を確認する項目

Step.4:チェック作業の自動化

• 目的：確認作業の自動化と継続的な監視
• 進め方：具体的な確認手段のうち、AWS ConfigといったAWSのサービスを用いて自動化できる部分を抽出し、確認作業の自動化を行う
• AWS Config/Config Rules
  • AWS環境の設定にルールを設け、そのルールが守られているかを評価（複数の機能群で構成）
  • 80を超えるマネージドルールの活用
    • S3バケットでパブリック読み取りアクセスが許可されないこと
    • ELBのログ記録が有効になっていること
    • EC2インスタンスのSSH受信ポートが制限されていること
    • EC2インスタンスがSSMの管理下に入っていること
    • CloudTrailが有効化されていること
    • 指定した日数以内にアクセスキーがローテートされていること
  • Config Rules用のGitHubリポジトリの活用
    • カスタムルール用のサンプル関数のパブリックレポジトリ
    • AWSコミュニティによって作成および提供
• 自動化を検討する際の注意点
  • あらゆる項目の自動化は難しく、また常に適切というわけではない。リスクや優先度、技術的難易度を鑑み「自動化すべき項目」と「自動化しない項目」を整理することが必要。また自動化すること自体が目的ではない。

Step.5:継続的なモニタリング

• 目的：一時的な断面での情報ではなく継続的な統制環境維持の確認
• 進め方：AWSのイベント検知機能と監視機能とを組み合わせ、継続的な監視状況を作り上げる
• Amazon CloudWatch/Events
  • AWSサービスの各種リソースを監視するマネージドサービス
  • CloudWatch Eventsは「ルール」を定義し、イベントソースとターゲットを紐付ける
• セキュリティモニタリングを担うサービス（AWS Security Hub）
  • Amazon Inspector
  • Amazon GuardDuty
  • Amazon Macie
  • Amazon Config

継続的コンプライアンスの活用例

• S3上のデータの漏洩対策についての方針例
  • クラウド利用の方針
    • データ保管にも利用
    • 必要な人に対してのみの権限付与
    • インターネット上からの許可のないアクセスの禁止
    • 設定ミスや一人の内部犯行による漏洩の防止
  • リスク
    • クラウド上にあるデータの漏洩
  • S3における方針対策例
    • S3のバケットポリシー/ACLによる公開アクセス設定の禁止
    • IAMによるバケットへの必要のないアクセスの制限
    • 万が一公開設定が行われた場合の発見・修復措置の実装
• 確認項目の整理とその自動化の例
  • バケットポリシー/ACLの公開設定がされていないこと → S3 Block Public ACcess機能の利用
  • バケットへのアクセスに関するIAMポリシーの最小権限設定 → IAMポリシー変更のAPIログによる検知と通知
  • バケットの設定変更に関するIAMポリシーの最小限設定 → OrganizationsのSCPによる子アカウントにおける設定変更の制限
  • S3 Block Public Accessが有効化されていること → AWS Configによる設定変更の検知とAWS Lambdaを用いた自動修復

感想

AWSサービスにおける継続的なコンプライアンスのモニタリングをどうやってやっていくか、実例も交えて紹介していてわかりやすいセッションでした。

AWSではセキュリティチェックの作業もマネージドなサービスで自動化されている部分も多く、監査作業も軽減できるのでうまく活用していきたいです。