ブログ

SysdigでAmazon EC2のセキュリティを確保する方法

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2022年6月2日にBrett Wolmaransが投稿したブログ(https://sysdig.com/blog/aws-ec2-security-cloudtrail-sysdig/)を元に日本語に翻訳・再構成した内容となっております。

Elastic Compute Cloud(EC2)は、AWSの中でも最も人気のあるサービスの1つであり、本当は紹介する必要がないのですが、ここではとりあえず紹介します。Sysdigを使用すると、設定と権限のリスクを管理し、コンプライアンス要件を満たし、コンテナとホストVMの脆弱性を管理することによって、EC2を保護することができます。

Attackers can exploit improper security groups
攻撃者は不適切なセキュリティグループを悪用することができる

EC2やHostそのものに関しては、Sysdig Secureは複数の方法で警告を発しています。


EC2ホストの脆弱性

OSやソフトウェアパッケージの脆弱性に関しては、コンテナやホスト自体に現れることがあります。ホストはKubernetesクラスターのノードを指すこともあれば、コンテナのユースケースを持たずにワークロードを実行するEC2ホストを指すこともあります。

これらの保護は、EC2ホストに適用されるのと同様に、コンテナ環境にも適用されることを理解することが重要です。

Sysdig Secureは、EC2ホストだけでなく、Fargateの脆弱性もチェックすることができます。

OSの脆弱性(rpmやdpkgなど)、OS以外の脆弱性(JavaパッケージやRuby gemsなど)に関係なく、Sysdig SecureはEC2ホストとそれぞれのScan状況を簡単に確認することができます。

List of Hosts EC2 Security
これらのホストの1つを掘り下げてみると、まず、Amazon Linux 2ベースのホストであることがわかります。

脆弱性のリストが表示され、最も緊急性の高い脆弱性に優先順位をつけるために、Sysdigでは、CriticalまたはHighで、修正プログラムが利用可能な脆弱性のみを表示するように選択することが可能です。

Vulnerability Details EC2 Security
最初の脆弱性 ALAS2-2021-1722 は、Amazon Linux 2 ホストに存在するため、Sysdig Secure は、この脆弱性に関して Amazon Security Tracker データベースを使用しています。

Sysdig Secureは、この問題の詳細を示しています:

Vulnerability detailed EC2 Security
...そして、リンクから公式データベースにアクセスし、詳細を確認することができます。

CVE detail EC2 Security

EC2ホスト上のワークロードをランタイムで保護する

ランタイムセキュリティは、EC2ホストと、他の防御策を回避した脅威との間に存在する唯一のものです。ランタイム環境を継続的に監査することで、ランタイムの脅威がもたらす潜在的な影響を最小限に抑えることができます。

Sysdigは、コンテナに対する豊富なランタイムワークロード保護機能を備えており、Sysdigのポリシーは、コンテナレベルで行うのと同じようにホストレベルで作用します。

同じエンジンとルール、そしてFalco構文によって、ホストレベル、この場合は私たちのEC2ホストに対する悪意のある活動や脅威を検出することができます。

ここでは、"Delete Bash History" というアウトオブボックスのルールでテストを行なってみます。

Falco Rule Detail

このルールをPolicyに追加し、Hostにのみ適用されるようにPolicyの範囲を設定します。

Runtime Policy

では、EC2ホストで簡単なテストをしてみましょう。

alt_text

そして、Sysdig はイベントを表示します。

Security Event

そして、イベントを掘り下げると、必要なすべての「誰が」「何を」「いつ」「どこで」の詳細が表示され、行動を起こすことができます。これが、EC2ホストにおけるランタイムワークロード保護で す。

Event Detail


SysdigのEC2環境におけるCSPMバリデーション

EC2ホストでのワークロード保護もその一つです。。しかし、EC2ホストは安全なクラウド環境全体に存在する必要があります。AWS環境が安全であることを確認する必要があるのです。

クラウド・セキュリティ・ポスチャー・マネジメント(CSPM)は、AWS環境全体を保護することを目的としたさまざまなユースケースを統合する仕組みです。CSPMは、クラウドのリソースを監査・追跡し、フレームワークに対してクラウドの静的な構成を評価します。

CSPM Frameworks

また、CSPMの主なユースケースの1つは、クラウドの設定が業界のコンプライアンスフレームワークで定義されたベストプラクティスに従っているかどうかをチェックすることです。

CSPMは以下のようなアラートを出すことができます:

  • インターネットに直接接続されているデータストレージ
  • データベースの暗号化の欠如
  • 重要なシステム・アカウントで多要素認証が有効になっていないこと


        ここでは、AWS環境で実行したCSPMコンプライアンスレポートの一覧を示します:

        Compliance

        ここでは、あるCSPMスキャンの詳細が表示され、パスしたコントロールと、修正する必要があるいくつかのフェイルしたコントロールが表示されています。ここで使用したフレームワークは、AWS WAF COMPLIANCEというカスタムフレームワークです。

        CSPM Details

        EC2の変更を継続的に検出

        CSPMでは、ある時点のセキュリティポスチャーを把握することができます。一方、CloudTrailの監視に基づく継続的な検知は、リアルタイムにアラートを出すことができます。CSPMとCloudTrailの継続的な検知を組み合わせることで、最大限の可視性を得ることが可能となります。

        CSPMのレポートに問題がなくても、何か変化があれば、できるだけリアルタイムにアラートする必要があります。そこで本稿では、AWS EC2の構成が変わると、リアルタイムでセキュリティホールが発生することを明らかにしたいと思います。

        そして、このようなリスクの高い設定イベントをネイティブのツールで探し出し、Sysdig Secureがこのような状況でどのように役立っているのかを比較します。

        どのAmazon EC2構成イベントが脅威を生むのか?

        Sysdigは20の危険な設定イベントを特定しましたが、このリストは拡張可能です。

        これらのイベントのいくつかは、1つ以上の有名なMITRE ATT&CK TTPに対応しています。https://attack.mitre.org/matrices/enterprise/cloud/iaas/、クラウドインフラの脅威マッピングに欠かせないものです。

        セキュリティイベント インパクト 説明
        Allocate New Elastic IP Address to AWS Account High アカウントにパブリックIPアドレスが割り当てられていることを検知します。
        Run Instances with Non-standard Image High 指定された数のインスタンスが非標準のイメージで起動したことを検知します。
        Run Instances in Non-approved Region Medium 非認証リージョンで指定された数のインスタンスの起動を検知します。
        Run Instances Medium 指定された数のインスタンスの起動を検知します。
        Revoke Security Group Ingress High AWS EC2のセキュリティグループから指定したイングレスルールが削除されたことを検知します。
        Revoke Security Group Egress High AWS EC2のセキュリティグループから指定したegressルールの削除を検知します。
        Replace Route Medium VPC内のルートテーブル内で既存のルートを置き換えることを検知します。
        Modify Snapshot Attribute Medium 指定したEC2スナップショットの権限設定の追加・削除を検知します。
        Modify Image Attribute Medium 指定された AMI の指定された属性が変更されたことを検知します。
        Make EBS Snapshot Public High EBSスナップショットの公開を検知します。
        Get Password Data High 実行中のWindowsインスタンスの暗号化された管理者パスワードの取得を検知します。
        EC2 Serial Console Access Enabled High 特定のリージョンのアカウントでAWS EC2のシリアルコンソールアクセスが有効になっていることを検知します。
        Disable EBS Encryption by Default Medium 現在のリージョンにあるアカウントに対して、EBS暗号化をデフォルトで無効にすることを検知します。
        Describe Instances Medium 指定したAWS EC2インスタンス、またはすべてのEC2インスタンスの説明を検知します。
        Delete Subnet High 指定されたサブネットの削除を検知します。
        Delete Cluster High 指定したクラスタの削除を検知します。
        Create Snapshot Medium EBSボリュームスナップショットの作成とAmazon S3へ格納を検知します。
        Authorize Security Group Ingress High AWS EC2セキュリティグループへの指定されたイングレスルールの追加を検知します。
        Authorize Security Group Egress High AWS EC2 のセキュリティグループに指定した egress ルールが追加されたことを検知します。
        Associate Elastic IP Address to AWS Network Interface High パブリックIPアドレスがネットワークインターフェースに関連付けられたことを検知します。

        このリストの中から、セキュリティの観点から非常に興味深い3つの危険な動きに焦点を当てます。

        1. 非標準のイメージでインスタンスを実行する
        2. セキュリティグループのIngressを許可する
        3. EBS暗号化をデフォルトで無効にする

        カスタムAMIは危険

        Amazonによると、Amazon Machine Image(AMI)とは、ソフトウェア構成(例えば、OS、アプリケーションサーバ、アプリケーション)を含むテンプレートのことです。AMIからインスタンスを起動すると、クラウド上で仮想サーバとして動作するAMIのコピーとなります。

        AWSアカウントでは、おそらく数種類のAMIが使用されており、OSやソフトウェアパッケージなど、それぞれの中身を把握する必要があります。これらのバージョンのOSやソフトウェアには脆弱性が含まれている可能性があり、それに対するランタイムソリューションが必要です。

        しかし、それと同じくらい重要なのは、まず意識することです。つまり、見えないものは守れないので、カスタムAMIがインスタンス化されたら即座にアラートを出す必要があるのです。そうして初めて、状況のトリアージと是正措置が可能になります。

        Sysdigは、組み込みの非標準イメージでインスタンスを実行するルールを使用して、このイベントのすべての発生を検出します。

        Amazon EC2のワイドオープンなポート、とは?

        ポート443のようなWebサーバーに使用されるポートのように、間違いなくインターネットに開放されるべきポートがあります。しかし、このように決して開いてはいけないポートもあり、もし開いていたら、それは大きな間違いか、侵入される状況です。

        次の表は、一般に公開すべき/すべきでないポートをいくつか示しています:

        ポート 目的 これはインターネットに公開すべきなのか?
        80,8080,8008 HTTP (cleartext) おそらくそうではないと思いますが、残念ながら多くのウェブサイトが平文になっています。
        443,4434,4443 HTTPS (encrypted TLS) はい、おそらくそうでしょう。
        25,587 SMTP クラウドプロバイダーがブロックする可能性はありますが。
        22,3389 SSH and RDP いいえ!

        これらのポートのうち、SSHのポート22を選んでみましょう。ポート22をインターネットに開放する正当な理由がないため、今回の例ではこのポートが良い候補となります。


        AWSのIPスペースに22番ポートのオープンインスタンスがいくつ存在していると思いますか?


        Shodanの公開検索を使って調べてみましょう。あなたは3,000,000と答えましたか?もしそうなら、あなたは賞品(無料トライアル)を獲得します。なぜなら、グローバルなAWS IPスペース内でポート22をリッスンしているインスタンスはおよそ300万個あるからです。

        Amazonの主要なIPブロックの分布は以下の通りです(Shodanによる):
        Shodan shows high numbers of open security groups

        犯罪の現場

        AWSアカウント内で世界に公開されているすべてのセキュリティグループを手動で見つけることができますか?はい、そのためにAWS CLIを使用した簡易的な例を紹介します:

        AWS CLI describing Security Groups
        このアプローチの明らかな欠点は、かなり手作業で地味だということです。

        私たちは、AWSアカウントで公開されたIPアドレスを見つけ、それらの評価を得るためにShodan APIを呼び出し、DynamoDBデータベースにすべてを格納する楽しいプロジェクトを発見しました。

        Lambda codeLambdaコード

        まずはレポをcloneしてみましょう。Lambdaを実行すると、AWSのDynamoDBのテーブルにこのような素敵な結果が表示されます:

        DynamoDB with IP Addresses
        IPアドレスを含むDynamoDB

        コードのチャンクを追加するごとに(どんなに簡単に入手できたとしても)管理負担が増えることはちょっと無視して、ここに根本的な問題があることがわかりますか?同じTOCTOUの問題だと思ったなら、その通りです。

        TOCTOU Problem with long scan intervals
        スキャン間隔が長い場合のTOCTOU問題

        このAWS Lambdaでは、実行時にしかパブリックIPアドレスを知ることができません。これを実行した後にAWSアカウントの誰かがIPを公開しても、次に実行する時までわかりません。

        また、Lambdaを再実行する前に変更を元に戻されたとしても、私たちはそのことを知ることはできません。

        犯罪現場を再現する

        では、どのようにこれらの広いAWS EC2 Security Groupルールを1つ作成するのでしょうか?ここではAWS CLIを使って、0.0.0.0/0からのアクセスをすべて許可するセキュリティグループを作成・失効させていますが、実際には以下の3つのことを行っています。

        1. ネームタグを元にInstanceIDを探す
        2. このInstanceIDに対応するセキュリティグループIDの検索
        3. 0.0.0.0/32:22をこのSecurity Group IDに追加する。

        AWS CLI Authorize Security Group
        AWS CLIでセキュリティグループを認可する

        これら2つのAWS EC2セキュリティグループのイベントの間に、攻撃者はAmazon EC2セキュリティグループがポート22でインターネットに広く開かれている間にSSHセッションを悪用することができました。

        Sysdig Secureは、Authorize Security Group Ingressルールによって、新しいセキュリティイングレスルールの発生をすべて検知します。

        AWS EC2 EBSの暗号化

        暗号化は一般的に、良いことです。AWS EC2のEBS暗号化も良いことであり、デフォルトで有効になっているはずです。

        AWSによると、暗号化処理はEC2インスタンスをホストするサーバー上で行われ、インスタンスと接続されたEBSストレージ間の静止データと転送中のデータの両方のセキュリティを確保しています。

        稀に古いインスタンスタイプでは暗号化をサポートしていない可能性もありますが、それは例外であり、ケースバイケースで処理されるはずです。

        このように、誰かがAWSアカウント全体のデフォルトEBS暗号化設定を無効化した場合、セキュリティの観点からも大きな問題であり、この事象についてアラートを出す必要があります。

        EBS Encryption being Disabled is a major security concern
        EBS暗号化が無効になることは、セキュリティ上の重大な問題です。

        Sysdigは、Disable EBS Encryption by Defaultルールで、このリスクイベントの発生をすべて検出します。

        CloudTrailでリスクを掘り起こす

        AWSは、私たちの変更を追跡する方法なしには放置しません。CloudTrailという天空の偉大な監査ログがすべてを追跡します。

        さらに良いことに、CloudTrailはイベントが発生したときに見るので、同じように使用時間の問題に悩まされることはなく、ある機能の頻度に依存することはありません。

        ここでは、AWS EC2 Security Groupのイベントを忠実に見ることができます:

        CloudTrail has the right information
        More CloudTrail details
        CloudTrailは正しい情報を持っているCloudTrailのログエントリーの詳細

        CloudTrailはもちろん何百万ものイベントを持つことができ、これらのほぼすべてがセキュリティに全く影響を与えない良いイベントである可能性が高いです。しかし、どれがどれなのかどうやって知ることができるのでしょうか?ここでは、StackOverflowのメンバーが、興味深いイベントを見つけることがいかに難しいかを説明する質問を投稿しています。

        StackOverflow Post
        StackOverflowの投稿

        CloudTrailは本質的に何百万行もの大きさの空の巨大なログであることに加え、アラートを送ってきませんが、仮に送れたとしても、善悪の概念がないので、アラートは意味をなさないでしょう。

        そこで、これを便利に使うには

        1. 善悪の区別がつき、アラートを送信できるツールを使う。
        2. AWSのネイティブツールでDIYする。


        しかし、以前のブログ記事で書いたように、ネイティブツールで必要なものを得るのは非常に難しいでしょう。

        そこで、Sysdig Secure for Cloudの登場です。

        CloudTrailとSysdig Secureの出会い

        SysdigはCloudTrailを常に監視しているので、CloudTrailが何かを知った瞬間に、Sysdigもそれを知ることになります。

        しかし、CloudTrailとは異なり、Sysdigは正しいことと間違っていることの区別がつき、適切なタイミングで適切なデータをアラートし、そして何よりもSysdigはすぐに使えるのです。

        Sysdigがデフォルトで検出するリスクの高いAmazon EC2イベントの幅を示すために、いくつかの例を見てみましょう。

        まず、上記で見たように、トップ10のワーストプラクティスは、次のように0.0.0/0(世界)に対してSecurity Groupを開くことです。

        AWS Console Security Group
        AWSコンソールのセキュリティグループ

        それでは、いくつかのリスクの高い事象について、Who/What/When/Where ifを調べてみましょう。

        • 0.0.0.0のセキュリティグループを作成する
        • EBS暗号化の無効化


        どのように行うのでしょうか?ミニデモを使って、簡単なウォークスルーを行ってみましょう。


        SysdigとCloudTrail - より良い関係

        AWS EC2は広い攻撃対象領域を提供し、その中でセキュリティグループは最上位に位置します。AWSセキュリティグループの制限は、安全でセキュアなデプロイメントの重要なコンポーネントです。

        また、別のひどい設定イベントも見てみました。AWS EBSの暗号化をオフにすることです。どちらも絶対に知っておきたいイベントですね。

        CloudTrailはすべてを見ますが、残念ながら善悪の区別がつかず、時には何百万ものエントリーを抱えています。CloudTrailのどこかに、リスクの高いイベントが埋蔵金のように隠れているのです。

        Sysdigは、このようなダイヤモンドの原石をCloudTrailから見つけ出し、Sysdigのセキュリティポリシーに通し、「誰が、何を、いつ、どこで」発生したのかを即座に把握することができます。

        Sysdig Secureは、Amazon EC2のセキュリティに穴が開き始めたことを簡単に確認し、簡単に修正することができます。

        このブログではEC2のみに焦点を当てましたが、SysdigはAWSの重要なサービスのほとんど全てに対して、すぐに使えるセキュリティ機能を備えています。

        また、Sysdig CloudTrailのルールは、オープンソースのFalcoプロジェクト(3000万回以上ダウンロードされている)と同じフォーマットを使用しているため、独自のカスタムルールを作成することができます。

        Sysdigでリスクを一元的に把握する

        Sysdig Secureを使用すると、EC2を含むクラウドとワークロード(ホスト、コンテナ、Kubernetes)における脅威を検出し、対応することができます。

        EC2に関しては、クラウドの他の領域と同様に、Sysdigはいくつかの方法で保護を提供します:

        • EC2ホスト上のOSおよびソフトウェアパッケージにおける脆弱性検出
        • EC2ホスト上のワークロードのランタイム保護
        • EC2の定期的なCSPMチェック
        • EC2ホストへの変更の継続的なチェック


        これらの保護がコンテナ環境にも適用されることを理解することが重要です。

        設定や許可のリスクを管理し、コンプライアンス要件を満たし、コンテナとホストVMの脆弱性を管理することができます。

        Sysdigは、深い可視性と豊富なコンテキストでリスクを一望できるため、問題を迅速に発見し修正することができます。

        しかし、私たちの言葉を鵜呑みにしないでください。もしお時間があれば、無料で今日から始めて、ご自分の目でその証拠を確かめてください。

        Sysdigに関するお問い合わせはこちらから

        最近の投稿

        カテゴリー

        アーカイブ

        ご質問・お問い合わせはこちら

        top