テキスト版 AWS環境のセキュリティ強化 発見的統制系サービスについて

はじめに

雲勉動画の音質が悪かったのでテキスト版を作成しました。目次に記載している各項目の時間帯は目安です。

自己紹介 1:25〜2:23

動画にて自分の経歴を簡単に記載したスライドを写してますので、そちらを参照ください。

アジェンダ 2:24〜3:14

1. 昨今のセキュリティインシデントの状況とこれからにについて
2. AWSの主要なセキュリティサービスについて
3. AWS Configルールを使ってみた
4. 終わりに

本日のゴール 3:15〜5:20

• IPAやガートナーが公開している資料の情報から昨今どのようなセキュリティインシデントが起きているのか、今後どのようになっていくのか、大まかな傾向を理解する。
• すぐに利用できるAWSの主要なセキュリティサービスを抜粋し解説。概要を把握する。
• AWS Configについては深掘りし、ルール機能やProactiveモード、Detectiveモード、Detectiveモードの自動修復機能について概要を把握する。

前置き：今回の内容は2024年の1月時点までの情報をもとに作成しています。

本題 5:21〜35:27

1.昨今のセキュリティインシデントの状況とこれから 5:21〜10:02

直近のセキュリティインシデントの状況を把握するにあたり、下記IPAの資料を参照する。

コンピュータウイルス・不正アクセスの届出状況［2022 年（1 月～12 月）］独立行政法人情報処理推進機構 セキュリティセンター 2023 年 2 月 8 日

• 不正アクセスの届出件数
  • 2020年に急増し、21年はさらに上がり、22年は下がったものの、20年を超える水準となっている。
• 不正アクセスの原因件数
  • 2022年、最も多いのが古いバージョンの利用や修正プログラム・必要なプラグイン等の未導入。2020年時点では次点だったが、21年、22年にかけ件数が急増した。
  • 2番目に多いのが、設定の不備。(セキュリティ上問題のあるデフォルト設定を含む)
  • 3番目がID、パスワード管理の不備。

続いてはガートナーが公開しているIs the Cloud Secureという資料を参照する。この資料の中から、私が気になった箇所をいくつか抜粋し、私の解釈ベースで日本語に要約している。

Is the Cloud Secure? Gartner October 10, 2019 Contributor: Kasey Panetta

• セキュリティに関する現状の傾向や将来的な予測について
  • 2025年にかけ起きうる事象として、パブリッククラウドを利用するにあたり、どのように環境を利用するか、利用戦略を立てずにパブリッククラウドを利用すると、センシティブなデータを外に公開してしまうようなリスクやインシデントを起こしかねない。
  • 2024年にかけ、元々パブリッククラウドを利用するにあたりリスクを過大評価する傾向にあったようだが、逆転現象が起きており、リスクを過小評価する流れとなる。
  • 2025年にかけ、クラウド下のインシデントの99%は設定不備によって生じる。

これらの情報を総合すると、今後パブリッククラウドをはじめ、クラウドサービスを活用する流れは加速していくかと思われる。ただし、どのように利用するか、例えば、どのユーザーにどの権限を割り当てるか、利用戦略を正しく設計していなければ、セキュリティインシデントを起こしかねない。

2.AWSの主要なセキュリティサービスについて 10:03〜22:30

• 紹介しているサービス
  • CloudTrail
    • IAMユーザー、ロール、AWSのサービスによって実行されたアクションを記録する。「いつ」「誰れが」「どのAWSサービス、リソースに」「どのような操作を行なったか」API操作のイベントログを記録している。イベントログは「管理イベント」、「データイベント」、「インサイトイベント」の3種類。
      • 使用例は何かしらのAWSリソースが設定変更されていた場合、そのリソースがどのIAMユーザーにより、どのAPIが実行されたのか、特定調査をしたい場合に使用する。この際に確認するログが管理イベントとなる。管理イベントは無料で利用でき、CloudTrail上では最新の90日間分のログを参照できる。
      • データイベントとインサイトイベントについて、これらはオプションとなる。
        • データイベントは記録対象をAWSリソース内のデータ操作に特化した機能となる。例えばS3の特定のバケットに対する書き込み処理（PUT）のAPIのみ記録、というような設定が可能。
        • インサイトイベントは、そのAWSアカウント上で普段実行されていないAPIやAPIエラー率を分析し、不審なアクティビティを検出する機能となる。不審なアクティビティをトリガーにEventBridgeを稼働させ、通知を送る仕組みを作ることが可能。
  • IAM Access Analyzer
    • 対象サービスにおいて外部とアクセス可能状態のリソースを検出する。
      • IAMロールやS3、SQSキューなど対象サービスにおいて、IAM Access Analyzerを有効化したアカウントとは別のアカウントのような外部に対する許可ポリシーを持っており、外部からアクセスできる状態になっている対象サービスのリソースを検出する。
      • 検出したリソースは「アクティブ」、「アーカイブ済み」、「解決済み」の3つに分類される。まずアクティブに出力され、問題ない外部アクセス先であれば、アーカイブ済みに移すのが基本的な運用となる。外部からアクセスできる状態から、その設定を削除、設定変更をした場合、解決済みに分類される。
      • アーカイブルールを設定すれば、指定条件で自動的にアーカイブ済みに移すことが可能。
      • 「アクティブ」を検出した際、それをトリガーにEventBridgeを稼働させ、通知を送る仕組みを作ることが可能。
    • 未使用のIAMロール、アクションの確認ができる機能もある。
      • 「未使用のアクセス分析」という機能があり、これを利用するとデフォルトだと90日間、未使用のIAMロールやアクションの一覧を参照できる。
  • GuardDuty
    • DNSクエリログなどのデータソースを元に悪意あるアクティビティがないかを確認し、検出結果を提供する脅威検出サービス。
    • EC2やIAM、S3などが脅威検出確認対象で、検出した脅威は「HIGH」、「MEDIUM」、「LOW」に分類される。
    • GuardDutyはデフォルトではオフ状態。オンにすると、DNSのクエリログやCloudTrail、VPCフローログなどを情報源に異常なアクティビティを検出する。
    • 異常なアクティビティとして検出するかはGuardDutyにて定義されており、例えばEC2インスタンスが暗号通貨関連のIPアドレスやドメインをクエリし、マイニングに活用されている可能性があった場合、これは脅威判定「HIGH」として検出する。
    • 「HIGH」の脅威を検知した際、それをトリガーにEventBridgeを稼働させ、通知を送る仕組みを作ることが可能。
  • Amazon Detective
    • セキュリティに関する検出結果や疑わしいアクティビティの原因分析、調査に利用する。
    • CloudTrailやVPCフローログ、GuardDutyのデータを収集し、機械学習 (ML)、統計分析、グラフ理論を活用、セキュリティ調査の視覚化を実現する。
    • GuardDutyでは発生したイベントベースで事象を認知し調査する形となるが、Detectiveを有効化していれば、時系列データをグラフで表示でき、点で見ていた事象を線で把握できるようになる。
    • GuardDutyを有効化し、48時間経過していなければ有効化できない。
  • Security Hub
    • AWS Configをあらかじめ有効化しておく必要がある。
      • AWS環境をセキュリティ観点で包括的に把握できるサービス。
        • セキュリティ系サービス（ex.GuardDuty）の検出結果を統合できる。
      • セキュリティ標準が数種類用意されており、指定したセキュリティ標準を満たす形でリソースが設定されているか、セキュリティスコアとして結果を定量的に認識することができる。
        • 指定したセキュリティ標準において、どれがどの基準で違反しているかを見ることができる。
        • ピンポイントで利用したいセキュリティ標準がなければ、AWS Foundational Security Best Practice（AWS基礎セキュリティのベストプラクティス）の利用を推奨する。
          • AWS Foundational Security Best Practice（AWS基礎セキュリティのベストプラクティス）はAWSのセキュリティ専門家が作成しており、適宜アップデートが施される。
  • AWS Config
    • AWSリソースの変更状況を管理でき、変更履歴を確認できるサービス。
    • Configルールを利用すれば、そのルールの状態から乖離しているリソースを非準拠状態として一覧化できる。
      • 一覧化するだけでなく、非準拠状態から準拠状態に戻すための機能も付帯している。
    • ConfigルールにはProactiveとDetectiveの評価モードがある。
      • Proactiveはリソースをデプロイ、作成する前にConfigルールを適用する際に使用する。
      • Detectiveは既にデプロイ、作成されたリソースにConfigルールを適用する際に使用する。

3.AWS Configルールを使ってみた 22:31〜34:21

• ルールの種類
  • マネージドルール
    • どのような評価を行うか、AWS側にて定義されているルール。
    • 300個以上のルールがあり、EC2、S3、IAM、RDS、ELB用に作成されているものが比較的多い。
  • カスタムルール
    • 内容そのものを自分で設定する。基本的にはLambdaでルールを作成する。
  • トリガータイプについて
    • 評価モードDetectiveにおいて、どのタイミングでルールの評価を実行するかを決めるのがトリガータイプ。
    • トリガータイプ：設定変更
      • 名前の通り、設定変更があった場合、そのマネージドルールのスコープと一致するリソースに対し、ルールの評価が行われる。対象スコープを絞る機能もあり、例えば指定タグをもつリソースのみを評価対象とするような設定が可能。
    • トリガータイプ：定期的
      • 指定間隔で評価を実行する。
    • トリガータイプ：ハイブリッド
      • 設定変更と定期的の両方を持つ。
      • 注意点として、タグで制限をしていても、スコープが効くのは設定変更の時のみで、定期的にはタグのスコープは適用されない。
  • 評価モードについて
    • Proactiveモード
      • 後発で使えるようになった機能。リソースをデプロイする前にルールの評価を行いたい場合に使用する。
      • 現在Proactiveモードで利用できるマネージドルールはおよそ17個。
      • 現時点ではコンソールでは使用できず、使用方法の例としてはCLIでAPIを実行する。発見的統制的に活用したい場合、CI/CDによるデプロイを実行する前のプロセスに、このAPIを設定したスクリプトを実行する設定を組み込む方法がある。
      • Proactiveモードの使用例は下記AWSのドキュメントが参考となる。
        • NEW — AWS Config ルールがプロアクティブなコンプライアンスをサポートするようになりました
    • Detectiveモード
      • 発見的統制目的に利用でき、利用できるマネージドルールは300個以上。
      • リソースや設定がルールに非準拠状態となった際、それをトリガーにアクションを稼働させる修復アクション機能がある。

マネージドルールと修復アクションの設定例 30:14〜34:21

使用マネージドルール：guardduty-enabled-centralized

使用修復アクション：AWSConfigRemediation-CreateGuardDutyDetector

手順 コンソールでの設定方法

1. AWS Systems Managerオートメーション用IAMロールと実行したいオートメーションランブックのアクションを持つIAMポリシーを作成する。
2. ルールを作成する。
3. 作成したルールの編集で修復アクションを設定する。

手順の1について、IAMロールとIAMポリシーを用意する。

• IAMロール
  • ssm.amazonaws.comの信頼ポリシーを設定する。作成したら、arnは控えておく。
• IAMポリシー
  • 下記アクションを設定し、IAMロールにアタッチする。
    • ssm:StartAutomationExecution
    • ssm:GetAutomationExecution
    • guardduty:CreateDetector
    • guardduty:GetDetector
      • 修復アクションに必要な許可設定情報はAWSドキュメントの各修復アクション（例：AWSConfigRemediation-CreateGuardDutyDetector）の必要な IAM アクセス許可に記載がある。

手順の2について、ルールを作成する。

• マネージドルールを選択し、一覧の中からguardduty-enabled-centralizedを選択する形でルールを作成する。

手順の3について、作成したルールの編集で修復アクションを設定する。

• 作成したルールのアクションボタンから、修復の管理を選択し、修復アクションを設定する。
• 修復アクションの設定箇所にてAWSConfigRemediation-CreateGuardDutyDetectorをプルダウンから選択し、パラメータには控えておいたIAMロールのARNを入力する。

これで設定は完了。GuardDutyが無効化状態の場合、非準拠状態とルールが評価し、その評価をトリガーに修復アクションが発動する。ちなみに修復アクションは自動稼働でなく、手動稼働とすることも可能。

4.終わりに 34:22〜35:27

昨今のセキュリティインシデントの状況とAWSのセキュリティ系サービスについて説明をしたが、今回の内容はAWS Well-Architectedのセキュリティのフレームワーク、とりわけ「検出」項目を考慮するにあたり、全て有用なので、導入することを勧める。
https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.pillar.security.ja.html#sec.detective