AWSセキュリティサービスによるコンテナの脅威検知

Pulisher : Cloud Technology Center イ・イェウン
Description : EKSコンプライアンスを遵守し、構成管理、セキュリティ監視方式についてのワークショップを実施

はじめに

現在、多くの企業で使用されているAmazon EKSのようなコンテナ技術を活用する環境におけるセキュリティの側面を明確に理解し、潜在的な脅威を識別する方法を理解するために申し込み、当該ワークショップを通じてEKSおよびコンテナにおける脅威の検出方法を理解するために参加しました。

セッションの概要紹介

AWSが管理するコンテナサービス、コンテナセキュリティ、脅威検知/モニタリングサービス、マルチアカウントアーキテクチャについての簡単な説明とHands-onを行ったセッションです。

2028年までにグローバル組織の95%がコンテナ化されたアプリケーションを実行すると予測されています。コンテナ運用の課題とセキュリティの重要性を考えると、AWSでは様々なコンテナ実行方法があり、その中でも今回のワークショップでは、Amazon Elastic Container Service (ECS)とAmazon Elastic Kubernetes Service (EKS)を重点的に取り上げました。

このセッションでは、コンテナのセキュリティに関するいくつかの重要なベストプラクティスを紹介します。まず、マルチアカウントアーキテクチャーを導入し、複数の環境と事業部のワークロードを分離し、最小権限の原則を適用することが強調され、コンプライアンスとセキュリティを強化するための重要なステップとして言及されました。

また、自動化の重要性が強調され、特に大規模システムでは、多数のAWSアカウントを効果的に管理するために自動化を積極的に活用する必要があり、中央集権的なロギングアカウントを設定し、変更不可能な場所にログを保管することでセキュリティと監査を強化する方法も強調されました。

また、セキュリティを強化するためにすべての層に深層防御を適用することが重要であると強調され、これにより様々なセキュリティ作業を効率的に行うことができると説明します。

GardDutyとIAMを活用してPodスキャンと適切なIDとアクセス管理を実装し、検知制御とセキュリティハブを活用してセキュリティ脅威に対応する方法について説明します。

ワークショップの前に各GaurdDutyとInspecotr、Security Hubの基本的な概念を説明しました。

ワークショップの進行

モジュール1：AWS Configを使用してEKS構成をモニタリング

このモジュールでは、AWS Configが構成タイムラインを表示する方法を確認し、EKSに対して3つのAWS Configルールを有効にします。

まず、AWS Configリソースのセクションでリソースのタイプを選択し、EKSを入力して関連するすべてのEKSリソースのタイプを確認します。

AWS Configを使用すると、管理者と監査人は、時間の経過に伴う構成変更を確認することができます。

構成変更がいつ行われたか、誰が変更を実行したか、以前の状態と新しい現在の状態を確認することができ、以下のようにAWS Configルールを使用して、コンプライアンス違反の構成に対してトリガーすることができます。

Config>Rulesでルールを追加して、AWS管理型ルールであるeks-cluster-oldest-supported-version(EKSクラスターが入力されたパラメータと同じであることを確認する)、eks-endpoint-no-public-access(EKSエンドポイントに公的にアクセスできないことを確認する)、eks-secrets-encrypted(EKSクラスターがKMSキーを使用してKubernetes Secretを暗号化するように構成されていることを確認する)の3つのルールを作成します。

モジュール2：KubescapeをAWS Security Hubに統合します。

このモジュールでは、事前に構築されたエンドツーエンドのアーキテクチャを使用してkubescape(オープンソースの脆弱性スキャンツール)をインポートします。 EKS

クラスターで生成されたセキュリティ結果をAWS Security Hubにスキャンします。kubescapeは自動化されたスケジュール

に従って実行するようにスケジュールすることができ、セキュリティチームがSecurity Hubをガラス窓として分析できるように結果が自動的にアップロードされます。

構成は上の図のように、Kubescapeの結果をSecurity HubにマッピングするためにLambda関数を配布し、この結果を保存するためにS3バケットを生成しました。 このバケットは、オブジェクト生成時、Lambda関数をトリガーしてSecurity Hubからその結果を取得するように構成します。 (Lambda関数とコマンドは省略)

構成が完了した後、Security Hub>Findingsで確認すると、Kubescapeで取得した結果を確認することができます。

モジュール3：AWS Security Hubを使用してEKSコンプライアンスをモニタリングする。

AWS Security Hubは、AWSリソースに対して自動化された継続的なセキュリティベストプラクティス検査を実行するクラウドセキュリティ状態管理サービス(CSPM)です。Security Hubは、さまざまなAWSサービスやパートナー製品からのセキュリティアラートを標準化された形式で集約することで、より簡単に対策を講じることができます。

このモジュールでは、コンテナワークロードのセキュリティを向上させるために複数のセキュリティサービスを使用する方法を検討し、Security Hubを他のAWSサービスの結果（GuardDuty、Inspector、Configなど）を集約するツールとして使用しました。

まず、Security Hubが有効になっていることを確認します。(Security Hub使用時、AWS Configを有効にする必要があります。) Security Hubでは、AWS基本ベストプラクティス及びCIS Benchmarkなどが基本的に有効になっていることを確認することができます。

Security Hub > Controlsでは、有効化したセキュリティ標準の統合コントロールを失敗、不明、合格、無効、有効、またはすべてのコントロールで構成して表示し、失敗の原因となるリソースを確認することができます。

モジュール4：Amazon Inspectorの作業

Amazon Inspectorは、AWSワークロードのソフトウェア脆弱性と意図しないネットワーク露出を継続的に検査する脆弱性管理サービスです。このサービスを有効にすると、実行中のAmazon Elastic Compute Cloud（EC2）インスタンス、Amazon Elastic Container Registry（ECR）に常駐するコンテナイメージ、AWS Lambda関数を自動的にスキャンし、既知の脆弱性の評価を即座に開始します。

Amazon Inspectorを使用してコンテナイメージをスキャンする

Amazon Inspectorは、Amazon Elastic Container Registry(ECR)に保存されているコンテナイメージからソフトウェアの脆弱性をスキャンし、パッケージの脆弱性結果を生成します。

このモジュールでは、脆弱性パッケージのスキャンにInspectorエンジンを使用するAmazon ECRの高度なスキャンを有効にします。

Amazon Inspectorが提供する拡張スキャンを有効にして、レジストリレベルでオペレーティングシステムとプログラミング言語パッケージの両方の脆弱性スキャンを行います。

画像レベル、画像の各レイヤー、およびAmazon ECRコンソールで拡張スキャンを使用して見つかった結果を確認できます。

上のようにAWS Security Hubを使用してInspectorの結果を確認することができます。

特定された脆弱性は、詳細を確認して対策を進めることができることを確認することができます。

ECR と Amazon Inspector を使用した DevSecOps

このモジュールでは、Amazon InspectorとAWS CodePipelineを使用してDevSecOpsパイプラインを構築します。このソリューションは、Amazon ECRにPushされたコンテナイメージに対する自動化された脆弱性検索サービスと通知サービスを提供します。

すでに下記のようにDevSecOpsが構成された内容で、ECRとAmazon Inspectorを使って脆弱性検索や通知サービスを確認してみました。

・DevSecOpsの構成： AWS CodeCommitにはDockerfileとイメージビルドインストラクションがあり、EventBridgeルールはリポジトリコミットを検知してコンテナパイプラインを開始し、パイプラインはCodeCommitからイメージ定義とビルドインストラクションを取得し、ビルド後、コンテナイメージを生成してAmazon ECRに保存します。ContainerVulnerabilityAssessmentでは、Amazon SNSを使って承認リクエストを送信し、接続されたLambda関数は応答に必要な情報を保存します。Lambda関数はEventBridgeを通じてAmazon Inspectorのスキャン結果を受け取り、配布を許可するかどうかを判断し、結果をパイプラインに提出します。CodePipelineは承認された場合、コンテナイメージをAmazon ECSクラスターにデプロイしてパイプラインを成功で完了し、拒否された場合、失敗に設定されます。

意図的な脆弱性があるドッカーファイルの基本イメージを編集して他の公開イメージでnode.jsをビルドした後、コードを配布しました。

数分後、このコンテナイメージの確認された脆弱性により、コンテナの脆弱性評価に失敗した失敗段階が表示されることを確認しました。

失敗したステップの詳細を確認すると、画像の詳細と重要な脆弱性閾値である0を超えたことを示すコメントが表示され、どのような重要な脆弱性が発見されたかを特定する必要があります。

コンテナイメージの初期ビルドから現在(最新)までの記録と結果がどう落ちたかを確認することができます。

一番最近タグ付けされたコンテナイメージを確認した時、Amazon Inspectorで確認したいくつかの脆弱性があることが確認でき、重要な脆弱性の数がLambda Function環境変数に定義されたしきい値を超えてApproval段階が拒否されたことが確認できます。

公開Repoから脆弱なイメージを取得した後、コンテナイメージを更新するためDockerファイルを更新します。再度、AWS CodeCommit Container Components Repo(AWS CodeCommit Container Components Repo)でドッカーファイルを開き、先ほどと同じようにファイルを更新します。 その後、リポジトリに更新をコミットします。

パイプラインが実行されることを確認し、コンテナの脆弱性評価段階を確認します。アップグレードステートメントを追加した後、コンテナの脆弱性評価ステップが承認され、イメージが対象Amazon ECS Clusterにデプロイされることが確認できました。 その後、Inspectorなどを確認して脆弱性を確認し、対策することができます。

モジュール5：Amazon EKSのAmazonGuardDutyタスク

Amazon GuardDutyは、AWSアカウント、Amazon Elastic Compute Cloud（EC2）ワークロード、コンテナアプリケーション、Amazon Auroraデータベース（プレビュー）、およびAmazon Simple Storage Service（プレビュー）に保存されているデータを保護するために、悪意のあるアクティビティや不正行為を継続的に監視する脅威検出サービスです。

Amazon GuardDutyを使用したEKSモニタリングの紹介

Amazon GuardDutyのEKS保護は、AWS環境内でAmazon EKSクラスターを保護するのに役立つ脅威検知範囲を提供します。

EKS保護には、EKS監査ログモニタリングとEKSランタイムモニタリングが含まれます。EKS監査ログモニタリングは、Kubernetes監査ログを使用して、Amazon EKS内のEKSクラスター内の潜在的に不審なアクティビティを検出するのに役立ち、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーンの時系列のアクティビティをキャプチャします。

EKSランタイムモニタリングは、オペレーティングシステムレベルのイベントを使用して、Amazon EKSクラスター内のAmazon EKSノードとコンテナから潜在的な脅威を検出するのに役立ちます。

まず、Amazon GuardDutyでEKS Audit Log Monitoring, Runtime Monitoringが有効になっていることを確認します。

GuardDutyエージェントをEKSクラスターに自動配布できるように設定を更新します。

GuardDuty agent management を探して活性化を進めます。有効にすると、GuardDutyはEKS GuardDutyエージェントのインストールをEKSクラスターに自動でPushします。

EKS Cluster RuntimeメニューでEKSランタイムモニタリング保護のために正常な状態であることを確認することができます。

上の図のようにGuardDutyで潜在的な脅威として検出されたEKSに対する結果が生成されることが確認できます。

EKS ランタイム保護

前のモジュールでAmazon GuardDutyランタイムエージェントを有効化しました。 これはAmazon EKSの追加機能を使って配布されます。

機能を使って配布されます。GuardDutyセキュリティエージェントは、システムイベントタイプを収集し、脅威の検出と分析のためにGuardDutyバックグラウンドで

GuardDutyバックエンドに送信し、脅威の検出と分析を行います。GuardDutyはこれらのイベントにはアクセスできません。

GuardDutyが潜在的な脅威を検出し、EKSランタイムモニタリング結果を生成すると、その結果の詳細を見ることができます。

その結果の詳細を見ることができます。

今回のモジュールでは、ポッドに仮想通貨実行ファイルをインストールして実行し、一つのEKSランタイム脅威をシミュレートします。

シミュレーションし、これにより、様々な脅威となる結果が発見されます。

上記の内容を見ると、実行した仮想通貨マイニングコマンドによってトリガーされる2種類のCryptoCurrencyの結果があることが確認できます。

CryptoCurrency:EC2/BitcoinTool.B!DNS – EC2インスタンスレベルの調査結果CryptoCurrency:Runtime/BitcoinTool.B!DNS – ポッド(コンテナ)レベルのランタイムを検索

詳細にImpact:Runtime/CryptoMinerExecutedの結果やインスタンスに関する情報などの結果を確認して分析することができます。

Amazon Detective for EKSの紹介

ハンズオンの他に、Amazon Detectiveの紹介も行いました。

Amazon Detectiveは、AWSリソースからログデータを自動的に収集し、セキュリティの結果や疑わしいアクティビティの根本原因を分析、調査、迅速に特定するのに役立ちます。

その後、機械学習、統計分析、およびグラフ理論を使用して、より迅速かつ効率的なセキュリティ調査を行うのに役立つ可視化を生成し、事前に構築されたデータ集計、要約、およびコンテキストは、考えられるセキュリティ問題の性質と範囲を迅速に分析および決定するのに役立ちます。

Amazon Detective for Kubernetesを有効にすると、Amazon Detectiveは自動的にEKS監査ログの収集を開始し、クラスター、パッド、コンテナイメージ、Kubernetesトピック（Kubernetesユーザーとサービスアカウント）に対して、Amazon EKSのユーザー、アプリケーション、コントロールプレーンから時系列のAPIアクティビティをキャプチャします。

Detectiveは、ログを手動で有効化、保存、または維持することなく、CloudTrailを使用するユーザーアクティビティとAmazon VPCフローログを使用するネットワークアクティビティを自動的に相関させます。

上の図のようにGuardDuty > FindingでEKS Clusterの結果を詳細に確認することができます。 (EKSクラスタ名、ARN、VPC ID、VPC ID、作成日を含むGuardDutyの結果と関連リソースの詳細)

詳細な内容の「Investigate with Detective」により、Detectiveで詳細な調査が可能です。

また、Detectiveでは、AWSアカウントID、IPアドレス、Detective-Demo EKSluster、kubernetes-adminサービスアカウント、スコープ時間など、GuardDuty調査結果に関連するすべてのリソースを検索し、スコープ時間を使用すると、期間を移動して関連するすべてのアクティビティと観測されたMITRE ATT&CKを確認することができ、様々な脆弱性の確認と管理に役立ちます。

セッションを終えて

今回のセッションでは、EKSコンプライアンスと構成管理、セキュリティモニタリング方式についての詳細を実習することができ、特にAWS Config、Security Hub、Inspector、GuardDuty、Detectiveを活用した戦略的なアプローチが重要だと判断され、効果的に組み合わせて自動化すれば、強力な侵害事故対応体系を構築できると思います。