CNSec2022 - AWS Security Hubの警告数 ”34,326”から始めた クラウドセキュリティ対策
20.7K Views
August 08, 22
スライド概要
2022-08-05に行われた、Cloud Native Security Conference 2022 での発表資料です。
概要は以下の通りです。
---
2021年の夏に完了したメインサービスのオンプレ環境からAWSへのリフトシフト案件に一息ついたあと、私たちは次のステップとしてクラウドセキュリティの改善を進めることにしました。
AWSエンタープライズサポートの力も借りつつ、第一歩として現状の可視化を行うためにAWSの各種セキュリティサービスを有効化してAWS Security Hubに集約して可視化したところ、検出されたのはなんと 34,326 もの数。本セッションでは私たちが検出した膨大な警告をどのように対策したのか、よくありそうな事例にパターン化してお伝えしたいと考えています。
---
URL: https://event.cloudnativedays.jp/cnsec2022/talks/1462
私たちはOisixのSREセクションです。 Oisixは、有機野菜や特別栽培野菜、保存料・着色料を使わない加工食品などを取り扱うEC食品宅配サービスです。
関連スライド
各ページのテキスト
AWS Security Hubの警告数 ”34,326”から始めた クラウドセキュリティ対策 Track C 2022/08/05 18:05-18:45 林 如弥 SREセクション マネージャ 岡本 真一 SRE & セキュリティ担当 1
最初にこちらをご覧ください 2
3
4
970 + 12,309 + 17,578 + 3,469 = 34,326 5
アジェンダ ● Before Security Hub（morihayaパート） ○ オンプレミス環境からAWSへの移行 ○ セキュリティ改善プログラムの受講 ● After Security Hub（Okamosパート） ○ AWS Security Hubについて ○ マルチアカウント・マルチリージョンでの集約 ○ 検出への対策の事例 ○ これからの活用 6
お話しすること ● Oisixブランドの話 ● AWSエンタープライズサポートの力を借りたこと ● 現状の可視化を行うためにAWSの各種セキュリティサービスを有効 化したこと ● AWS Security Hubに集約して可視化したこと ● 検出した膨大な警告をどのように対策したのか、よくありそうな事 例にパターン化して紹介 7
話さないこと ● 他ブランドのこと（らでぃっしゅぼーや、大地を守る会、etc） ● 各AWSセキュリティ関連サービスの細かな設定方法 8
(宣伝)Oisixは、有機野菜や特別栽培野菜、保存料・着色料を使わない 加工食品などを取り扱うEC食品宅配サービスです PC↑ スマホ→ 9
オンプレミス環境からAWSへの移行 10
オンプレミスからAWSへの移設 ● 2021年07月以前まではこんな感じでした 11
オンプレミスからAWSへの移設 - 2 ● 2021年07月以前まではこんな感じでした ○ 本番環境はAWSではなかった（一部を除き） ○ 開発環境などは古くからあるAWSアカウントで運用 ■ ここにはかなりの負債が溜まり続ける... ● 誰が作ったか不明なリソース群 ● 70%程度は手動作業 12
オンプレミスからAWSへの移設 - 3 ● 少なくない困難を乗り越えて本番環境をAWSへ移行完了 13
オンプレミスからAWSへの移設 - 4 ● 少なくない困難を乗り越えて本番環境をAWSへ移行完了 ○ 本番環境は新アカウントへ ○ 本番環境は、既存環境のカオスっぷりを反省点とした ■ TerraformによるIaC導入 ■ AWS SSO(現IAM Identity Center)の導入 ■ AWS Control Towerの導入 14
オンプレミスからAWSへの移設 - 5 ● 基本的なAWSの運用はできてきたが...？ ● AWS Well-Architected フレームワークを確認 ○ なかなかのボリュームに進捗が振るわない ● AWS Solutions Architectさんにも相談してみる ○ 「セキュリティ改善プログラム」をご提案いただいた ■ 喜んでお願いした！！ 15
（AWSさんによる） セキュリティ改善プログラムの受講 16
セキュリティ改善プログラムの受講 ● どんなプログラムなの？ ○ AWSのセキュリティ・スペシャリストと共に、QA形式でシステ ムのチェックを実施する ○ 1時間30分 x 3回のプログラム（調整可能） ○ エンタープライズサポートであれば無料（詳細は各ご担当へ） 17
セキュリティ改善プログラムの受講 - 2 ● 雰囲気はこう ルートユーザの”仮想または物理 MFA”を有効にしていますか？ はい！もちろんです！！！ AWSの方 ORD担当（我々） 18
セキュリティ改善プログラムの受講 - 3 ● ひたすら質問に答えていきます セキュリティインシデント対応の模擬演 習を実施して、脅威の検知や対応の訓 練を実施していますか？ いいえ.... AWSの方 ORD担当（我々） 19
セキュリティ改善プログラムの受講 - 3 ● 質問数は150以上。3回に分割されていますが精神を試されます Q136 ? できてません... Q142 ? AWSの方 Q158 ? してません... ないです... ORD担当（我々） 20
セキュリティ改善プログラムの受講 - 4 ● そうして算出された判定結果がこちら！(ぼかしで失礼...) 21
セキュリティ改善プログラムの受講 - 5 ● 初見の感想「予想以上に評価が低い...」 ● 一般的なインフラ的セキュリティはできている認識だったが ● 大半がGoodすらではなく「Average」以下 ○ Poor, Average, Good, Excellentで評価される ● “Insident Response”は「Poor」の判定 22
セキュリティ改善プログラムの受講 - 6 ● ● ● ● 計測することでやっと現状がわかる SREの基本でもある「可視化」がセキュリティにおいても重要 毎回AWSさんにプログラムを実施いただく訳にもいかない 自分たちで運用できるクラウドセキュリティの可視化が必要！！ 23
「AWSのセキュリティの可視化？ それ、AWS Security Hubでできるよ」 24
AWS Security Hub ● セキュリティのベストプラクティスや業界標準のチェック ● セキュリティアラートの集約 インサイト 検出結果 ● 調査 ● 対応 検出結果 25
AWS Security Hub ● 各種AWSサービスとパートナー製品から検出結果を集約 ● サマリーやインサイトといったコンソール上で現在の状況を把握し 調査や修復といったアクションを迅速に行うことが可能 26
検知に利用できる統合 ● ● ● ● ● ● ● Amazon GuardDuty Amazon Inspector Amazon Macie IAM Access Analyzer AWS Firewall Manager AWS Config <有効化必須> Integrated AWS Partner Network(APN) security solutions 27
検知に利用できる統合 ● Amazon GuardDuty: 管理イベントログ・ネットワーク・Kubernetes監査ログ をデータソースとして利用。不正なアクティビティの検知やAmazon Detectiveを利用したフォレンジックが可能 *1 ● Amazon Inspector: VMとコンテナイメージに対するスキャンを行いインス トールされているパッケージの脆弱性や予期しないネットワークへの露出を確 認 ● Amazon Macie: S3上に存在する個人情報などの機密データを保護するための データハンティングが可能。他のサービスと連携してバケットポリシーや Access Control Litsを自動修復するといったアクションが可能 28
検知に利用できる統合 ● IAM Access Analyzer: 外部エンティティと共有されているリソースの識別や IAMポリシーの検証、アクティビティに基づいたIAMポリシーの生成を行う ● AWS Firewall Manager: ネットワークの保護のために複数のアカウントとリ ソースを保護する。AWS WAFポリシー / AWS Shield Advancedポリシー / セ キュリティグループポリシー / Amazon Route 53 Resolver DNS Firewallポリ シーの検出 ● AWS Config: AWSリソースの設定を評価、監査、設定変更の管理を行う。 Security Hub上ではセキュリティ標準のチェックにも利用される 29
検知に利用できる統合 ● Integrated APN security solutions: さまざまなパートナーセキュリティソ リューションからセキュリティ関連の発見事項を集約可能 ● Security Hubでは30日間、そのほかのサービスについても15 ~ 30日間の無料 期間が設けられているサービスが多いので実際のコストを見積もるために一度 有効化してみるのがオススメ 30
セキュリティ標準について ● AWS Foundational Security Best Practices ● CIS AWS Foundations Benchmark ● PCI DSS 80% 23% failed 31
セキュリティ標準について ● コントロールとはセキュリティ的な保護・対策のための規定のこと。セキュリ ティ標準は複数のコントロールで構成される ● AWS Foundational Security Best Practices: アカウントとリソースについて ベストプラクティスからの逸脱を検出する。CIS AWS Foundations Benchmarkに比べて多くのAWSサービスと紐づいたコントロールがある ● CIS AWS Foundations Benchmark: CIS(Center for Internet Security)が定め るAWS向けのセキュリティ標準。モニタリングの設定に関するコントロールが 多数ある。AWS Foundational Security Best Practicesとお互いに内容かぶる コントロールもある 32
セキュリティ標準について ● CI DSS: カード会員情報の保護を目的として作成された情報セキュリティの国 際統一基準を満たす支援をするように設計されている。コントロール自体が PCI DSSの評価に対する合格を保証するものではないという点に注意が必要。 カード会員情報を扱っていない場合は基本的に有効にする必要はない ● 個人的にはセキュリティ標準のコントロールについてはリソース作成時に参照 するかリソースの作成ガイドラインなどに盛り込まれていると望ましいと考え る。例えば[S3.4]「S3バケットでは、サーバー側の暗号化を有効にする必要 があります。」というコントロールがあるがS3バケットの作成時デフォルト ではサーバー暗号化が有効ではない。設定によってはこういったリソース作成 時には意識しづらい項目もあるため事前にセキュリティリスクの低いリソース 作成をおこなえる 33
関連サービスの有効化と集約 ● AWS Control Towerによる自動的なAWS Configの有効化 ● AWS Organizationsによる容易なサービスの有効化と監査アカウントへの委任 ● リージョン集約 管理アカウント 委任 監査アカウント ログアーカイブ アカウント 34
関連サービスの有効化と集約 ● AWS ConfigはControl Towerで管理しているService Control Policyによって自 動的に有効化されるように設定されていた。Aggregatorを手動でセットアッ プする場合でもOrganizationsを利用していると導入が容易 ● 各サービスは管理アカウントから委任先のアカウントを登録するだけで Organizations配下のメンバーアカウントが有効化される。稀に管理アカウン トのみ別途有効化が必要なサービスもある ● Security Hubを使いたいリージョンで各サービスを有効化する必要がある 35
検出への対策の事例 36
Case.1 大量のセキュリティアラート ● 既に運用しているアカウントで有効化 ● 何から手をつければ良いのか分からない Resource type AwsEc2Instance AwsIamUser AwsS3Bucket AwsEc2SecurityGroup 37
Case.1 大量のセキュリティアラート - 対策 ● Security Hubではマネージド型インサイトまたはカスタムインサイトを作成可 能で容易に分類が可能 ● AWS Security Finding Format(ASFF)と呼ばれる一定の形式で結果を処理して おり判断された重要度であったりCVEに対して脆弱性の深刻度を表すCVSSス コアなど様々な角度からフィルタリングすることが可能 ● AWSが判定する重要度は大まかなセキュリティリスクを知る上で重要だが深堀 する場合はASFFのデータを使ってより詳細に分類する必要がある ● どのリソースが重要でセキュリティを高める優先度が高いのかを分類したリ ソースの種類や脆弱性の深刻度によって判断して対応していくのが重要 38
Case.2 過剰な検出リソース ● 同一のAmazon マシンイメージから作成されたVM ● レジストリ(Amazon ECR)でスキャンされている同類のイメージ ● CDにより作成された同一種類のコンテナイメージ(アプリケーションコードの み更新されているなど)から大量のセキュリティアラートが上がっており分類 時にノイズとなっていた Critical 30000 High 250000 39
Case.2 過剰な検出リソース - 対策 ● Inspectorではコンテナイメージの再スキャン間隔を変更できるので短くして おくと良い。またコンテナイメージのライフサイクル自体も適切にしておくこ とが重要 ● 個別に抑制ルールを作成可能で条件にはリソースの種類や作成日時などを指定 可能。今回のケースの他に許容できるセキュリティリスクを抑制ルールとして 定めることも可能 ● 適切な抑制ルールを入れてノイズとなる情報は無くしておく 40
Case.3 多量の失敗するコントロール ● 集約された状態でコントロールのチェックを全て成功させなければいけない ● 表示されるセキュリティスコアの実態 12% 41
Case.3 多量の失敗するコントロール - 対策 ● セキュリティ標準のコントロールはチェックを無効化することが可能 ● [IAM.6] ルートユーザーに対してハードウェア MFA を有効にする必要があり ますについては仮装MFAを利用していることで代替できていることやリモート ワークが多くなったため実現が現実的ではないなど許容できる理由があれば無 効化していく ● コントロールを無効化すると新しく作成されたリソースに対してセキュリティ チェックが全く働かなくなる。コントロールの無効化は組織のポリシーや実現 の難易度または許容できる内容かなど様々な視点から慎重に行う必要がある 42
Case.4 検出不能なコントロール ● 不明 ● データなし Compliance Status 失敗 43
Case.4 検出不能なコントロール - 対策 ● CloudFrontやAWS WAFなど一部のサービスはバージニア北部でのみサポート されています。 *2 ● Security Hubと関連サービスはリージョナルなサービスが多いのでリージョン ごとに設定する必要がある ● Control Towerで東京リージョンに加えてバージニア北部も有効にすることで AWS Configの有効化とAggregatorの設定が作成され監査アカウントに集約 *3 44
Case.5 リソース設定変更の難解さ ● [EC2.9] EC2 インスタンスは、パブリック IP アドレスが設定されていない必 要があります ● [EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセス を許可してはいけません ● [RDS.2] Amazon RDS DB インスタンスはパブリックアクセスを禁止する必要 があります。これは、PubliclyAccessible 設定により判断されます。 45
Case.5 リソース設定変更の難解さ - 対策 ● 本番稼働しているワークロードのネットワーク設定は変更が難しい ● VPC内の通信内容はVPC Flow Logsで取得可能。セキュリティグループを利用 しているネットワークインターフェイスに対してFlow Logsの設定を行い実際 の通信内容を確認することによって確信を持って厳格化していく ● セキュリティパッチが適用されていない古いパッケージはアプリケーション チームやQAチームなどと連携して十分にテストした上で計画的にアップデー トしていく 46
Case.6 時間による検知内容のブレ ● リソースの状態は時間によって刻一刻と変化するのでSecurity Hubでの検知結 果が常に変わる ○ 09:00 Critical: 1,200 ○ 17:00 Critical: 1,800 🤔🤔🤔 47
Case.6 時間による検知内容のブレ - 対策 ● より正確に通知を実施するためにSecurity Hubで検出された内容はSlackや PagerDutyなどの普段利用しているツールに通知するようにしておいて重要な セキュリティイベントを漏れなく検知できるようにしておく ● 全てのセキュリティイベントを通知するとノイズとなりやすいので通知も適切 にフィルタリングする。Security Hubはカスタムアクションを使用して結果を EventBridgeに送信することが可能 48
これから 49
ワークフローの強化 ● AWS Security Hubに集められたセキュリティイベントを過不足なく通知する 仕組みを作る ● 通知されたセキュリティイベントを解決するためにトラッキングできる状態に する 50
まとめ ● 各サービス・アカウント・リージョンから集約できているか確認 ● 検知された内容を適切に取り扱う必要性 ● セキュリティアラート・セキュリティチェックへの対応は優先度を決めること が重要 ● 継続的な改善していくための仕組みが必要 52
ご静聴ありがとうございました 53
補足 1. 最近Malware Protectionという機能が追加された 2. サポートされているリソースタイプ 3. AWS Configの有効化時にすでにレコーダーが作成されているとControl Tower によって作成されたCloud Formation Stackによるリソース作成が失敗するの で注意。レコーダーはWebコンソールからは削除不能 54