[レポート] SEC310: Amazon EC2インスタンスメタデータサービスのセキュリティベストプラクティス #reinvent

こんにちは、コンサル部の望月です。

re:invent での発表ではなかったものの、大変、気になるアップデートだった IMDSv2 について、下記弊社ブログでも取り上げましたが、現地ではもちろんセッションを聞いてきました。

[待望のアプデ]EC2インスタンスメタデータサービスv2がリリースされてSSRF脆弱性等への攻撃に対するセキュリティが強化されました！ ｜ Developers.IO

本記事では AWS re:Invent 2019のセッション「SEC310: Security best practices for the Amazon EC2 instance metadata service」 のレポートをお送りします。

セッション概要

The Amazon EC2 instance metadata service (IMDS) provides a rich set of relevant data to software on that instance. The IMDS ability to perform introspection about the runtime environment, as well as to pass parameters and code through user data, greatly simplifies software development and deployment. At the same time, an instance’s metadata includes private information, such as AWS credentials, that should be limited to the software or humans that need access. In this session, we take a close look at the IMDS and mechanisms for protecting it from unintended access, including new capabilities provided by the recently launched IMDS version.

スピーカー

• Mark Ryland
  • Director, Office of the CISO , Amazon Web Services

まとめ

これから EC2 をセキュアに利用するためのぜひ使っていきたいアップデートだと思いました。

弊社ブログでもこれからどんどんやってみたブログがアップされるかと思いますので、利用を検討してみるといいかと思います。

[UPDATE] IMDSv2を強制するIAMポリシーを検証してみた #reinvent ｜ Developers.IO

レポート

アジェンダ

• Amazon EC2インスタンスメタデータサービス (IMDS) の(再)紹介
• IMDSv2(およびその周辺)の新機能
• IMDSを保護するためのベストプラクティス
• アクションの呼び出し

Amazon EC2インスタンスメタデータサービス (IMDS) の(再)紹介

• Amazon EC2 IMDS とは
  • 初期の Amazon EC2 の一部
  • リンクローカルネットワークアドレス "169.254.169.254"
    • 実際には Amazon EC2 コントロールプレーンからデータを読み取るためのパス
  • すべてのソフトウェアからローカルに簡単にアクセスできる
    • HTTPはユニバーサル言語バインディングを提供します
  • APIを呼び出したり、OSプリミティブを使用したりすることなく、Amazon EC2のコードが実行環境について知ることができる
    • たくさんの有用なデータ (私のお気に入り：launch-index)、参照
    • インスタンスメタデータとユーザーデータ - Amazon Elastic Compute Cloud
• ユーザーデータ
  • Amazon EC2 APIを使用すると、IMDSのユーザーデータ機能を介してインスタンスにデータを入れることができます
    • 完全に動的な AMI カスタマイズを可能にする
• IMDS および Amazon EC2 ロール認証情報
  • 課題：コード認証の Bootstrapping
    • 認証されていない状態から認証された状態にコードを取得する方法
    • コードに安全に資格情報（アクセスキー/シークレットキー）を取得する方法
    • 標準の認証方法を使用できません
  • 歴史的に：多くの危険な慣行
  • ソリューション (2012年6月以降)：IMDSを介して Amazon EC2 ロールの資格情報を配信する
  • 資格情報管理に関連する無数のセキュリティインシデントを回避するのに役立ちました
• IMDS (および役割の資格) を安全に保つ
  • ホスト上のソフトウェア (およびユーザー) のみが利用可能
    • リンクローカルアドレス "169.254.169.254" はAmazon EC2でリモートで動作しません
    • (Xen hypervisor/dom0 または Nitro コントローラーと実際に通信するだけです)
  • ソフトウェアを分析し、Amazon EC2ロールの最小特権アクセスを実装します
  • ローカルのファイアウォール保護も可能、推奨
    • メタデータにアクセスできるプロセスを必要なプロセスに制限する
• 顧客が悩んでいる部分
  • IMDSv1 は安定しており、うまく機能しています
  • しかし、ローカルソフトウェアの設定ミスはリスクを生み出します
    • オープンプロキシ、NATおよびルーター、サーバー側のリフレクションの脆弱性
    • 何らかの方法で、ローカルソフトウェアがローカルのみのデータにアクセスし、リモートからの接続で不適切に提供する可能性があります
  • どのように改善するか
    • テストにより、特殊なメタデータのヘッダーを追加するだけでは不十分

IMDSv2(およびその周辺)の新機能

• インスタンスメタデータサービス2.0 (IMDSv2) の紹介
  • IMDSアクセスへの不正なアクセスする、ほとんどの設定ミスやSSRFの脆弱性を打ち負かす
    • ほとんど = すべての既知 / テスト済み
    • 認証なしですべての取得は不可能
  • 具体的には
    • ステートレスな要求/応答モデルからセッション指向モデルへ
    • ソフトウェアはPUTでセッショントークンを作成します
    • そして、すべてのリクエストはヘッダーにセッショントークンを含める必要があります
• 新モデルの中核
  • セッションの開始 (bashの例)
    • TOKEN= curl --request PUT "http://169.254.169.254/latest/api/token" --header"x-aws-ec2-metadata-token-ttl-seconds: 600"
  • GETリクエストでセッションを続行するためにトークンが必要
    • curl --request GET "http://169.254.169.254/latest/metadata/ami-id" --header "x-aws-ec2-metadata-token: $TOKEN"
  • このトークンは 10 分 (600 秒) 後に期限切れになります
  • IMDSは、ヘッダーの存在によって v1 要求と v2 要求を区別します
• ローカルの詳細
  • セッショントークンは N 秒後に有効期限が切れます（初期化済み）
  • その特定の Amazon EC2 インスタンスでのみ使用可能
  • X-Forwarded-For ヘッダーがある PUT 要求は拒否
  • PUT 要求からの応答パケットのホップカウント/ TTL = 1 (デフォルト)
    • 特定のTCP層の設定ミスから保護します
    • IP パケットレベルのみに影響します。レイヤー7 (HTTP) での影響なし (例：Webプロキシの場合)
    • APIを介してインスタンスごとに構成可能
  • 使用中のトークンの数に実質的な制限はありません
    • 既存のIMDS接続の制限と調整は引き続き適用されます

デモ

• 3つのアクセスパターン
  1. EC2 API (どこからでも可能)
  2. IMDS の呼び出し (ローカルのみ)
  3. 役割の認証情報で行われた呼び出し
  • 
• 実際に AWS CLI を利用したデモが行われました。
  • 認証していない接続を拒否するなど
• (オプション) 移行のサポート - 新機能
  • RunInstances および ModifyinstanceMetadataoptions API のパラメーター
  • IAM/SCP 条件キー
    • RunInstances で IMDS 設定を制御する
    • IMDSv1 の使用をブロックする
  • Amazon CloudWatch インスタンスレベルのメトリックが取得できる
  • IMDSv2 にデフォルト設定されている CLI および SDK はすでに利用できる
    • 他のAWSソフトウェア (Amazon EC2エージェントなど) は間もなく移行します
    • AWSパートナーのソフトウェアの移行が進行中
  • Coming soon
    • ModifyInstanceMetadataOptions の IAM / SCP条件キー
    • AWS CloudTrailは、ロール認証情報配信メカニズム、Amazon EC2 起動テンプレートのサポートを表示します
• 新 parameters/values および新 API
  • RunInstances：新しいパラメータ
    • HttpEndpoint = enabled | disabled
      • メタデータサービスの有無 (デフォルト enabled)
    • HttpTokens = optional | required
      • メタデータの利用にTokenを必須にするか (デフォルト optional)
    • HttpPutResponseHopLimit = 1-64
      • Token取得時のPutのレスポンスで付与するホップ数 (デフォルト 1)
  • DescribeInstances：新フィルターと戻り値
  • ModifyInstanceMetadataOptions：新 API
    • 同じパラメータ
    • パラメータなしの呼び出しは現在の状態を返します
• 新しい条件キー
  • [1] AWS IAM および組織のサービスコントロールポリシー(SCP)の新しい条件キーでRunInstancesの動作を制御する
  • [3] API リクエストに署名したコードに Amazon EC2 ロール認証情報を配信するため、使用されたIMDSのバージョンを制御する
    • "NumericGreaterThan": {"ec2: RoleDelivery": "1.0 [I 2.0]"}
• CloudWatch メトリクス
  • CloudWatchは、IMDSv1の利用をカウントする新しいメトリクスを追加します
    • Amazon EC2: MetadataNoToken
  • メトリクスを使用して、v1 の使用をカウント(ダウン)します
    • カウントがゼロに達すると、ソフトウェアのアップグレードが完了します
    • ゼロ以外のメトリクスのアラーム
  • CLI/SDK は IMDSv2 を優先するようになりました。他のホスト上のソフトウェアについても、すぐ対応予定
  • Amazon EC2 起動テンプレートのサポートは近日中に提供予定 (CloudFormation、自動スケーリングなどをカバー)
  • Coming soon：
    • CloudTrail でのロール配信のロギング。
    • Amazon EC2 コンソール

IMDS を保護するためのベストプラクティス

• ベストプラクティスのチェックリスト
  • BLUF：Amazon EC2 インスタンスに幅広くアクセスできる場合 (インターネットなど)、特に注意すること
    • アクセス可能なポートで Listen しているソフトウェア/プロセスのアクセスを制限する
    • 必要に応じて、access broker model を使用する：信頼できるプロセスは、より危険にさらされているソフトウェアにIMDSデータを送信します
  • ソフトウェアは IMDS データにアクセスする必要がありますか？
    • そうでない場合は、IMDS を無効にします
  • 実際にアクセスする必要があるソフトウェアは何ですか？
    • ローカルファイアウォールルールを使用してローカルアクセスを制限する
    • access broker model を使用する
  • ソフトウェアにはAmazon EC2ロールが必要ですか？
    • AWS API を呼び出す
    • AWS Secrets Manager を使用して他のソフトウェアへの認証済みアクセスを Bootstrapping
    • そうでない場合は、使用しないでください
  • Amazon EC2 ロールが必要な場合
    • ソフトウェアを分析して、最小限の特権を持つロールのアクセス許可を作成します
    • ローカルファイアウォールルールを使用してアクセスを制限する
    • access broker model を使用する
    • IMDSv2 を使用するためのアップグレード手順を開始します
  • そしてもちろん、ソフトウェアを更新/パッチする

デモ (ローカルファイアウォールとIMDSへのアクセスの使用)

• AWS Global Infrastructure を利用したデモ
  • 
• ファイアウォールに関する注意
  • Deny-Y ルールよりも安全な Deny-all-but-X ルール（X = trusted principal）
  • Linux：iptables owner module は、プリンシパルのプライマリグループのみをサポートします
  • Windows ファイアウォールは問題なく動作します (複雑ですが、グループは正常に動作します)
  • 
• IMDSv2 の新しいアクセス制御機能を使用する
  • 新機能のデモ
    • DescribeInstances と modifyinstanceMetadataOptions を使用して IMDS を管理する
    • IAM ポリシーで RunInstances 条件を使用する
    • RoleDelivery 条件の使用と IMDS の無効化
    • ModifyInstanceMetadataoptions へのアクセスを制限する
    • SCP ですべての条件を使用する

アクションの呼び出し

• IMDS 保護のベストプラクティスを実装する
  • 最もリスクの高い/アクセスしやすいシステムから始めます
  • 必要でない限り、IMDS を無効にします
  • 必要でない限り、IAM ロールを使用しないでください
  • ソフトウェアを分析し、最小特権ロールを使用する
  • ローカルファイアウォールルールを使用してアクセスを制限する
  • 必要に応じて (より) 信頼できるプロセスブローカーパターンを使用する
  • 今日から始めて、IMDSv1 または IMDSv2 に等しく適用されます
• IMDSv2：リスク評価と移行計画
  • 既存のリスクと緩和の価値を評価する
  • v2 に移行するかどうか、およびそのペースを決定する
    • 完全にオプションです。 AWS には、v1 を非推奨にする現在の計画はありません
  • 提供されているツールを使用して、移行を管理および測定します
    • 例：modifyInstanceMetadataoptions、CloudWatch メトリクス
  • 最終的に IAM/SCP 経由で IMDSv1 の使用を無効にします
    • 新しい条件キーを介したインスタンス作成時
    • 役割の資格情報のその後の承認時：IMDSv1 で提供された資格情報で行われた API 呼び出しを拒否
  • CloudTrail、Console、modifyInstanceMetadataoptions の IAM 条件など、近日公開予定