マネージドサービス部 佐竹です。
今回はセキュリティの向上を目的として、Amazon EC2 の「データ保護とセキュリティ(Data protection and security)」設定について解説していきます。
- はじめに
- Data protection and security の各項目解説
- まとめ
はじめに
2024年3月25日に発表された以下のアップデートにより、IMDSv2 をそのアカウントの各リージョン単位でデフォルト値として EC2 を構築することが可能となりました*1。
ただ、それだけではなく、同時に「インスタンスメタデータのタグへのアクセスを許可する」ことも可能となりました。
この設定追加等により、2024年5月現在は Amazon EC2 の「データ保護とセキュリティ(Data protection and security)」では、設定項目が 5 つまで増えています。
Data protection and security の5つの設定項目
- Data Lifecycle Manager default policies
- EBS encryption
- Block public access for AMIs
- Block public access for EBS snapshots
- IMDS defaults
折角なので、今回はこの5つの設定がどのように役立つのか、設定項目毎にそれぞれ解説していきます。
「データ保護とセキュリティ」設定を正しく行うことで、AWS アカウントがよりセキュアに利用できることは間違いありませんので、EC2 を利用する場合は前提として理解し、可能な限り正しく設定してご利用頂ければ嬉しく思います。
Data protection and security の各項目解説
本オプションは、EC2 ダッシュボードから、コンソール画面の右端にある「設定」の「データ保護とセキュリティ」を押下することで、各項目の設定を行うことが可能です。
もしくは、EC2 の左端メニュー最下部にある「設定」からも遷移することが可能です。
1. Data Lifecycle Manager default policies
それでは1つ目の設定です。
以下の通り、日本語では「Data Lifecycle Manager のデフォルトポリシー」と表示されます。
本設定は2023年11月にリリースされた新機能「デフォルトポリシー」が設定されているかどうかを確認する項目です。もし、デフォルトポリシーが設定されていない場合は、「EBS スナップショットポリシーが設定されていません」のように設定が行われていない旨が表示されます。
デフォルトポリシーとはどのような機能なのか
本機能のリリース時の AWS 公式ページは以下の通りです。
まず、バックアップのデフォルトポリシーは「Amazon Data Lifecycle Manager」の設定です。
デフォルトポリシーを有効化することで、簡単にそのアカウント内の（各リージョンの）全ての EC2 インスタンスと EBS ボリュームをバックアップしておくことが可能になります。
また、以下の記載がある通り余計なコストが発生しないようにも配慮されており、コスト最適化の観点からも優れた機能です。
デフォルトポリシーは、お客様の既存のバックアップメカニズムと連携して機能し、EBS ベースの AMI とインスタンスとボリュームの EBS スナップショットのみが作成され、最新のバックアップは作成されません。これにより、お客様は重複バックアップを作成したり、管理オーバーヘッドやコストを増大させたりすることなく、包括的なバックアップ保護を実現できます。
https://aws.amazon.com/jp/about-aws/whats-new/2023/11/amazon-elastic-block-store-policies-ec2-ebs/
実際の設定画面をご紹介します。
本設定は先の画面の「Lifecycle Manager で管理」のボタンを押下し、その後 Data Lifecycle Manager で「ライフサイクルポリシーを作成」を押下することで作成が可能です。
デフォルトポリシーの設定を行うためには、上図の選択画面で「デフォルトポリシー - 新規」を選択します。
そして「スケジュールベースのポリシー」で「EBS スナップショットポリシー」もしくは、「EBS-backed AMI ポリシー」を選択した後「次へ」を押下して設定していきます。
具体的な設定については今回割愛させて頂きますため、詳しくは「AWS 公式ドキュメント」をご参照ください。
また、デフォルトポリシーとカスタムポリシーの違いについては、公式ドキュメントの「デフォルトポリシーとカスタムポリシー」に比較表が掲載されています。
デフォルトポリシーを設定しておくと何が良いのか
本設定のメリットは「漏れなくそのアカウントの（各リージョンの） EBS ボリュームと EC2 インスタンスのバックアップが保持されること」です。
現在は、2010年頃の EC2 インスタンスや EBS ボリュームと異なり、これらのリソースが意図せずエラーを起こして利用できなくなる、というようなことはほとんど経験することがなくなりました。このため検証環境等の非本番環境では「バックアップを一切取得されていないまま」利用を長期で継続されているケースも散見されます。
平常時においては、これらは問題になりません。バックアップコストもかからず良いことのようにさえ見えます。ですが、私はカスタマーサクセスとしてお客様の対応を継続してきた中で、このような状況下で運用上の課題を抱えたという実体験があります。
私が経験した課題は、以下のようなものでした。
- 誤って手動で EC2 インスタンスを削除してしまったが、バックアップがなく復旧ができない
- EC2 インスタンスがウィルス等により汚染されてしまったが、復旧できるバックアップがない
これらはどちらも最新のバックアップがあれば解決ができました。
このように、運用上日々のバックアップは重要です。ただ、その設定はこれまで煩雑でした。ですが、いま現在は Data Lifecycle Manager のデフォルトポリシーで簡単に漏れのないバックアップ設定が可能です。
このような背景と重要性から、本設定は Data protection and security の最初の設定として表示されていると考えられます。
AWS Organizations への対応
Amazon Data Lifecycle Manager のデフォルトポリシーは、2024年4月26日に AWS Organizations に対応しました。
お客様は AWS CloudFormation StackSets を使用して、組織全体または組織単位 (OU) でデフォルトポリシーを作成および管理できるようになりました。
上記の記載の通り、実際は CloudFormation StackSets が動作するものですが、これにより組織の全 AWS アカウントで漏れなくバックアップを設定しておくことが可能となっています。
このアップデートにより「Use a sample template」に「Create and manage default policies for EBS Snapshots」及び「Create and manage default policies for EBS-backed Amazon Machine Images (AMIs)」が追加されています。
本 Deploy については AWS 公式ブログ「Automate comprehensive data protection using AWS CloudFormation StackSets」を合わせてご覧ください。
2. EBS encryption
次に、EBS encryption です。日本語では「EBS 暗号化」と表示されます。
実のところ、2020年12月に私が以下のブログを記載した時点では、「データ保護とセキュリティ」という項目名は「EBS 暗号化」というそのものズバリの項目名でした。
本設定の動作は現在も基本的に変わりがありませんため、設定や動作確認については上記ブログを参考として頂ければ幸いです。
このように、本設定はこれらの5つの中で最も古くからある設定であり、最初にアカウント単位の設定として実装された機能となります。
EBS の暗号化をするとどうなるか
既に AWS Key Management Service (AWS KMS) による暗号化をご利用されている場合には馴染みがある機能とは存じますが、まずは Amazon EBS の暗号化についての AWS ドキュメントを紹介致します。
EC2 インスタンスを構築するタイミングやEBS を個別に作成するタイミングで、KMS の鍵を利用して EBS ボリュームの暗号化が可能です。
一般的にはデフォルトの aws/ebs の鍵が利用されることが多いでしょう。個別に「対称カスタマーマネージド型暗号化キー」を KMS で作成し、指定頂くことも可能です。
さらに、暗号化に関しての全ての仕組みは AWS 側が自動で行ってくれるため、利用者側がやることといえば、暗号化された EBS ボリューム作成時にどの鍵を利用するのか指定を行うくらいのものです。
そして本設定を行ってさえいれば、上画像の通りマネジメントコンソールからの EC2 インスタンス構築時に、事前に指定された KMS キーが自動的に EBS ボリュームへと設定されます*2。
加えて、CloudFormation を利用して EC2 インスタンスを構築するような場合でも、テンプレートの修正なしに本設定が自動的に（透過的に）構築される EBS ボリュームへと反映されます*3。
このため、本設定は運用の観点からも手間がかからず、お勧めの設定です。
EBS の暗号化を行う利用者側のメリットとは
ここで少し Security Hub の話をしてみます。
[EC2.7] EBS のデフォルト暗号化を有効にすることをお勧めします
このコントロールは、Amazon Elastic Block Store (Amazon EBS) でアカウントレベルの暗号化がデフォルトで有効になっているかどうかをチェックします。アカウントレベルの暗号化が有効になっていない場合、コントロールは失敗します。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/ec2-controls.html#ec2-7
本引用の「EC2.7」のセキュリティのチェック項目は、本設定を示しています。つまり、Security Hub においてもこの設定は推奨されている状況です。
そしてもう1つ、AWS Well-Architected Framework の「セキュリティの柱」における「SEC 8.保管中のデータをどのように保護していますか?」も確認してみましょう。
この中の項目「SEC08-BP02 保管中に暗号化を適用する」において、以下の記載があります。抜粋してご紹介します。
SEC08-BP02 保管中に暗号化を適用する
期待される成果: プライベートデータが保管中にデフォルトで暗号化される。暗号化を行うと、データの機密性を維持し、意図的または不注意によるデータの開示や流出に対する保護層を追加して強化できます。
実装手順
新しい Amazon EBS ボリュームのデフォルトの暗号化を設定する: 新しく作成したすべての Amazon EBS ボリュームを暗号化形式で作成することを指定します。AWS が提供するデフォルトキーを使用するか、作成したキーを使用するかを選択できます。
本設定を行えば、Security Hub のチェックもクリアでき、さらに AWS Well-Architected Framework のレビューにおいてもベストプラクティスに則っていると回答が可能となるメリットがあります。
加えて、本暗号化の根本的なメリットについて記載しますと、先に抜粋しました「意図的または不注意によるデータの開示や流出に対する保護層を追加して強化できます」にあります。
さて、この「不注意なデータの流出」とはどのようなものでしょうか？このような事態は AWS のデータセンターにおいて発生する懸念は基本的にない、と考えても良いほどセキュアではあります。
ということで、一例として、ある自治体において発生した事案（AWS は全く関係のない事案です）をご紹介します。これは、廃棄されたはずの HDD が転売され、情報が流出してしまった事案です。
本事案の詳細は上記ページをご確認ください。
もし万が一、自社の利用している EBS ボリュームの実ストレージがこのような状況や、何らかの物理的な侵害に陥ったとしても、EBS ボリュームの暗号化を行っていれば鍵がないためにデータが復号できません。
このような事態に備えるために、AWS はエンドユーザ側で EBS ボリュームの暗号化が可能となる設定を提供しています。
関連して、AWS におけるストレージの廃棄については以下の AWS 公式ブログが参考になります。一部抜粋して本文もご紹介します。
AWS データセンターは、セキュリティを念頭に置いて設計されており、統制により具体的なセキュリティが実現されています。ユーザーデータの保存に使用されるメディアストレージデバイスは AWS によって「クリティカル」と分類され、そのライフサイクルを通じて非常に重要な要素として適切に取り扱われます。AWS では、デバイスの設置、修理、および破棄 (最終的に不要になった場合) の方法について厳格な基準が設けられています。ストレージデバイスが製品寿命に達した場合、NIST 800-88 に詳細が説明されている方法を使用してメディアを廃棄します。ユーザーデータを保存したメディアは、安全に停止するまで AWS の統制から除外されることはありません。AWSで扱われるメディアはワイプ処理もしくは消磁処理され、AWSのセキュアゾーンを離れる前に物理的に破壊されます。
ご興味があれば是非上記ブログもご覧ください。
3. Block public access for AMIs
3つ目は AMI のパブリック公開禁止の設定です。
日本語では「AMI へのパブリックアクセスをブロック」と表示されます。
どのような機能か
Amazon Machine Images (AMI) は EC2 インスタンスのバックアップであり、仮想サーバ構築の元となるイメージです。
そして、AMI で「ゴールデンイメージ」を作成した後に、その AMI を自社のその他の AWS アカウントに共有し、共通のイメージとして運用することが可能です。このような利用シーンでは他アカウントへの AMI の共有が必要となります*4。
AMI 共有時には一般的には AWS アカウント ID を指定して共有することが多いでしょう。または、AWS Organizations を利用する場合には組織 ID もしくは OU ID を Arn で指定することも可能です。
ですが、この AMI 共有時の設定を誤った結果、特定の AWS アカウントへの共有ではなく「Public（全世界）」に公開されてしまった、というアクシデントも稀に見受けられるものでした。
このような事態を防ぐ目的で、そもそも AMI を「Public」に共有することを禁止する機能がリリースされ、本設定項目になっています。
現在はデフォルトで有効となっている
2023年9月13日にリリースされた本機能ですが、以下のブログでもお知らせした通り、現在では既存・新規に関わらず全ての AWS アカウントの全リージョンにおいて「デフォルトで有効」です。
本ブロックが全アカウントに反映が開始されたのは2023年10月16日からです。
つまり2024年5月現在は、ほとんど全ての AWS アカウントで本設定は既に有効（ブロック）になっています。
ブロックが無効になっている場合
上画像のように「新しい公開共有が許可されました」となっている場合は、本設定が無効です。即ち AMI のパブリックアクセスはブロックされていません。
もし本設定が「無効」となっている場合は、設定を「有効」へ変更されることを推奨します。
4. Block public access for EBS snapshots
4つ目です。
日本語では「EBS スナップショットのパブリックアクセスをブロック」と表示されます。
どのような機能か
AMI のパブリックアクセスのブロックは「AMI 自体の共有」をブロックするものであり、AMI に紐づく個別の EBS スナップショットの共有は引き続き可能でした。
ですが、2023年11月9日の機能追加により、個別の EBS スナップショットでもパブリックアクセスをブロックすることが可能となりました。
Amazon Elastic Block Store が EBS スナップショットのパブリックアクセスのブロックのサポートを開始
Amazon Elastic Block Store (EBS) が、EBS スナップショットのパブリックアクセスのブロックのサポートを開始しました。これは、お客様が AWS リージョンでの EBS スナップショットのパブリック共有をブロックできるようにするアカウント全体のセキュリティ設定です。
EBS スナップショットのパブリックアクセスのブロックは現在、すべての AWS アカウントでデフォルトで無効になっており、AWS コンソール、AWS コマンドラインインターフェイス (CLI)、および AWS SDK を使用して設定を有効にできます。
ただし上記の抜粋の通り、本設定はデフォルトで無効になっています。つまり、利用者が個別に（必要があればリージョン毎に）有効とする必要があります。
何故、本設定はデフォルトで有効となっていないのでしょうか？
推測するに、AMI を別のアカウントと共有するという利用シーンは多いものの、EBS スナップショットを個別に共有するという利用シーンは少ないためだと想定します。このため、AMI がデフォルトでパブリックアクセスをブロックしているにも関わらず、本設定はデフォルトでブロックしていないのではないでしょうか。
ただし、今後この初期値は変更される可能性もあります。
現状は少々手間ではあるのですが、EBS スナップショットのパブリックアクセスをブロックしたい場合、本設定を有効化ください。
本設定に関連する Security Hub のコントロール
Amazon EC2 に関連する Security Hub の1つ目のコントロールとして以下のチェックが存在します。
[EC2.1] Amazon EBS スナップショットはパブリックに復元できないようにすることをお勧めします
スナップショットのパブリックへの共有は滅多に認められていません。一般的に、スナップショットを公開する決定は、誤って行われたか、影響を完全に理解せずに行われています。このチェックは、そのような共有がすべて完全に計画され、意図的であったことを確認するのに役立ちます。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/ec2-controls.html#ec2-1
上記 AWS 公式ドキュメントからの抜粋に記載された「一般的に、スナップショットを公開する決定は、誤って行われたか、影響を完全に理解せずに行われています」の通り、リソースのパブリックへの共有が行われている場合、意図されていない設定であることが大半です。
もし、Security Hub で [EC2.1] のコントロールが「失敗」となっている場合は、一度 EBS スナップショットの共有設定を見直すとともに、パブリックアクセスのブロック設定も合わせて確認してみてください。
5. IMDS defaults
最後の設定です。
日本語では「IMDS デフォルト」と表示されます。
本項目は、インスタンスメタデータサービスに関するデフォルト設定ですが、それに関連した3つのオプションの設定が合わせて可能となっています。
5-1. インスタンスメタデータサービス
まず「そもそもインスタンスメタデータサービスとは何か？」について解説していきます。
インスタンスのメタデータサービスは、実行中の EC2 インスタンス内部からメタデータの取得を可能とするためのサービスです。基本的に IAM ロール （インスタンスプロファイル）を通じて認証情報を利用する場合に本オプションは必須です。
IPv4 の例がよく知られていると思われますが http://169.254.169.254/latest/meta-data/ の URL にアクセスすることでインスタンスに関連する情報（メタデータ）の取得が可能です。
インスタンスメタデータサービスはセキュリティの強化された新しいバージョン2があり、これは「IMDSv2」と省略されます。古いバージョンは「IMDSv1」です。
IMDSv2 の詳細については、以下のブログ記事を合わせてご覧ください。
メタデータサービスを利用されたい場合、現在はセキュリティの強化されたバージョンである IMDSv2 の利用が推奨されています。
例えば、Security Hub のコントロールにおいては以下の通りです。
[EC2.8] EC2 インスタンスは、インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用することをお勧めします
Security Hub では、EC2 インスタンスを IMDSv2 で設定することを推奨します。
https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/ec2-controls.html#ec2-8
重要なのが、インスタンスメタデータには設定が可能な場所が現在が「3つ」あることで、これらは「アカウント設定」、「AMI 設定」そして「インスタンス 設定」です。
加えて、この3つには優先順位があります。
インスタンスメタデータオプションの優先順位
優先順位 1: 起動時のインスタンス設定
優先順位 2: アカウント設定
優先順位 3: AMI 設定https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html
上記引用の通り、アカウント設定は優先順位が2番目になっているため、インスタンスの設定が優先されることに留意してください。
この優先順位について、簡単に図にしてみました。左から右に行くにつれ、設定が優先（上書き）されます。
これまでは「アカウント設定」がなかったため、何も指定をしない場合は AMI の設定に依存していました。構築時に個別に設定したい場合は、CloudFormation テンプレートや Launch テンプレート等を利用するか、構築時に個別に設定が必要でした。
本アカウント設定を利用することで、全体を統一させる層が生まれ、設定の統一性とセキュリティの向上を担保できるようになりました。
また、アカウントレベルのデフォルト設定値は、これを変更したとしても既存の EC2 インスタンスには影響がありません。
IMDS のデフォルト値における1つ目の項目「インスタンスメタデータサービス」の設定は、これから構築(Launch)を行う EC2 インスタンスに「インスタンスメタデータサービス」を利用させるかどうかです。
一般的には IMDS を利用するケースが多いと考えられますため「有効」の設定にしておいて問題ないでしょう。
5-2. Metadata version
先に記載しました IMDSv1 と IMDSv2 のどちらを使うのか、という設定が本オプションです。
ただし、設定は「IMDSv1 と IMDSv2 どちらも利用可能 [V1 and V2 (token optional)] 」か「IMDSv2 だけが利用可能 [V2 only (token required)] 」のどちらかです。
IMDSv2 をアカウントのデフォルトとして設定する
インスタンスメタデータサービス (IMDS) のデフォルトバージョンは、各 AWS リージョンのアカウントレベルで設定できます。つまり、新規インスタンスを起動すると、そのインスタンスメタデータバージョンは自動的にアカウントレベルのデフォルトに設定されます。ただし、起動時または起動後に値を手動で上書きできます。https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html
本項目については AWS 公式ドキュメントにも上記引用の通り記載されています。
Security Hub の例にもあるように、現在は「V2 only (token required)」とすることが推奨されますため「V2 only (token required)」としておかれるとよりセキュアでしょう。
注意事項
注意点として、IMDSv2 にすることで運用上の問題が発生する場合があります。
以下、AWS re:Post からの引用となります。
Systems Manager オートメーションを使用して、Amazon EC2 インスタンスからインスタンスメタデータにアクセスするために IMDSv2 のみを使用するように強制するにはどうすればよいですか?
重要: IMDSv2 を強制すると、IMDSv1 は動作しなくなり、IMDSv1 を使用するアプリケーションが正しく機能しない可能性があります。IMDSv2 を強制する前に、Amazon EC2 メタデータを使用するアプリケーションが IMDSv2 をサポートするバージョンにアップグレードされていることを確認します。
https://repost.aws/ja/knowledge-center/ssm-ec2-enforce-imdsv2
上記の通り、IMDSv2 に対応していないアプリケーションがインストールされている場合に、IMDSv2 を必須とした後に正常に動作しないというトラブルを発生させてしまう可能性があります。このため、切り替え前には IMDSv2 に対応したバージョンにアップグレードする必要が出てきます。
IMDSv2 への移行に関連して知っておきたいこと
以下の通り、CloudWatch の MetadataNoToken または MetadataNoTokenRejected メトリクスを利用することで IMDSv1 から IMDSv2 へ移行した場合の影響を確認することが可能です。
IMDSv2 への移行に役立つツール
CloudWatch
IMDSv2 では、IMDSv1 がサポートしていない、トークンベースのセッションが利用できます。MetadataNoTokenCloudWatch メトリクスは、IMDSv1 を使用しているインスタンスメタデータサービス (IMDS) への呼び出しの数を追跡します。このメトリクスをゼロまでトラッキングすることにより、すべてのソフトウェアが IMDSv2 を使用するようアップグレードされたかどうか、およびいつアップデートが行われたかを測定できます。IMDSv1 を無効にした後、
MetadataNoTokenRejectedCloudWatch メトリクスを使用して、IMDSv1 呼び出しが試行および拒否された回数を追跡できます。このメトリクスを追跡することで、IMDSv2 を使用するようにソフトウェアを更新する必要があるかどうかを確認できます。
また、以下の AWS 公式ブログでは2024年半ばからデフォルトで IMDSv2 のみを使用するようになると予告がされています。
2024 年半ば – 新しくリリースされた Amazon EC2 インスタンスタイプは、デフォルトで IMDSv2 のみを使用します。移行をサポートするために、これまで同様に、インスタンス上での起動時または起動後に再起動や停止/開始を必要とせずに IMDSv1 を有効化できます。
https://aws.amazon.com/jp/blogs/news/amazon-ec2-instance-metadata-service-imdsv2-by-default/
このため、IMDSv2 への移行は、予め検討されておいたほうが良いと考えられる状況となっています。
5-3. Access to tags in metadata
2022年1月6日、EC2 インスタンスに付与されたタグをメタデータサービスから参照できるようになりました。
インスタンスタグが Amazon EC2 インスタンスメタデータサービスで利用可能に
ただし、本設定はデフォルトでは有効となっておらず、個別に有効とする必要がありました。
EC2 インスタンスの内部からタグを参照する必要がある場合、本設定も合わせて有効にしなければなりません。
例えば以下のブログでご紹介したような例があります。
本ブログのように、コストの高騰など、何らかの理由があって Amazon Inspector を動作させたくないインスタンスがあるとします。
この場合、EC2 インスタンスに InspectorEc2Exclusion というタグキーを指定し*5、加えてインスタンスメタデータのタグへのアクセスを許可する必要があります。
このような場合において、インスタンスメタデータのタグへのアクセスを都度許可するのは煩雑になりますので、インスタンスの新規構築時に自動的に本設定が有効となるように、アカウント設定を行っておくことも可能となっています。
注意事項
先にご紹介しましたブログ内にも記載したのですが、インスタンスメタデータのタグへのアクセスを許可する場合、その EC2 インスタンスに付与されている全てのタグキーにおいて、半角スペースは使用できません。
インスタンスメタデータでインスタンスタグを有効にすると、インスタンスタグキーは文字 (a-z、A-Z)、数字 (0-9)、および次の文字のみを使用できます: + - = . , _ : @。インスタンスタグキーは、スペースまたは / を含めることはできず、. (1 つのピリオド)、.. (2 つのピリオド)、または _index のみを含めることはできません。
特に Systems Manager において「Patch Group」をタグキーに利用している場合に、本制限に抵触してしまいます。
これに関しては、2022年8月末に PatchGroup も同様に利用可能となるアップデートが施されておりますため、現在はこのタグキーをスペースなしの「PatchGroup」へと修正してご利用頂けます。
5-4. メタデータレスポンスのホップ制限
メタデータレスポンスのホップ制限についてのベストプラクティスを先にまとめておきます。
- EC2 インスタンス上でコンテナを利用するアカウントの場合：「2」
- EC2 インスタンス上でコンテナを利用しないアカウントの場合：「1」
上記の通りとなります。
本設定に関しての理解を深めるため、AWS 公式ドキュメントから引用します。
コンテナ環境では、ホップ制限を 2 に設定することをお勧めします。
AWS SDK はデフォルトで IMDSv2 コールを使用します。IMDSv2 呼び出しに応答がない場合、SDK は呼び出しを再試行し、それでも失敗した場合は、IMDSv1 を使用します。これにより、特にコンテナ環境では、遅延が発生することがあります。コンテナ環境では、ホップ制限が 1 の場合、コンテナへの到達は余分なネットワークホップと見なされるため、IMDSv2 応答は返されません。IMDSv1 へのフォールバックプロセスとその結果として生じる遅延を回避するために、コンテナ環境でホップ制限を 2 に設定することをお勧めします。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
EC2 インスタンスそれ自体が、IMDSv2 を利用してメタデータを取得する場合、そのリクエストは「ホップ数のカウントダウンが発生しない」ために、ホップ制限の設定値が 1 であってもメタデータを取得することが可能です。
しかし、EC2 インスタンス上で動作しているコンテナから、その EC2 インスタンスを通じてメタデータを取得する場合は、1つホップしたとカウントされるため、設定は 2 である必要があります。
昨今、コンテナ環境で動作するアプリケーションが非常に増えてきています。このため、今現在は本設定の推奨値は「2」と考えて良いでしょう*6。
なお、先の設定で「V2 only (token required)」としている場合には、IMDSv1 が利用されることはないため、AWS SDK は IMDSv1 によるリトライを行えず、失敗する点にも注意が必要です。
GuardDuty の検出結果に関連して知っておきたいこと
本ホップの制限に関連する GuardGury の検出結果が存在します。
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
インスタンス作成ロールで EC2 インスタンス専用に作成された認証情報が外部 IP アドレスから使用されています。
この検出結果は、AWS 外部のホストが、AWS 環境内の EC2 インスタンスで作成された一時的な AWS 認証情報を使用して AWS API 操作を実行しようとしたことを通知します（※英語版を意訳しました）。
これは、EC2 インスタンスのプロファイルから取得された認証情報が、AWS の外部で利用されていることが判明した場合に通知される検出結果です。
例えば、専用線を通じて社内 LAN から EC2 インスタンスへ接続し認証情報を取得後、ローカル PC でその認証情報を用いて AWS CLI を操作したような場合です。
このような場合でも「リクエストがホップしている」と判定されるため、ホップのカウントダウンが発生します。よって、メタデータレスポンスのホップ制限を設定している場合には、このような利用方法を禁止することが可能となります。
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS のような事態を禁止されたい場合にも、本設定は有効と考えられます。
まとめ
本ブログでは、AWS におけるセキュリティの向上を目的として、Amazon EC2 の「データ保護とセキュリティ(Data protection and security)」について詳しく解説しました。
オプションの1つ1つがなかなかに奥の深いものであるため、本ブログで各設定について少しでも理解が深まれば嬉しく思います。
最後に全ての項目について、お勧めの設定を記載しておきます。
- Data Lifecycle Manager のデフォルトポリシー
- EBS スナップショットポリシー：デフォルトポリシーを追加で設定する
- EBS-backed AMI ポリシー：デフォルトポリシーを追加で設定する
- EBS 暗号化
- 有効にする：KMS キーには
aws/ebsを指定するか、カスタマーマネージドキーを作成しそれを指定する
- 有効にする：KMS キーには
- AMI へのパブリックアクセスをブロック
- デフォルトで有効のため、無効となっていないか確認する
- EBS スナップショットのパブリックアクセスをブロック
- 有効にする：「すべての公開共有をブロック」として設定する
- IMDS デフォルト
- インスタンスメタデータサービス：
有効 - Metadata version：
V2 only (token required) - Access to tags in metadata：
有効 - メタデータレスポンスのホップ制限：
2
- インスタンスメタデータサービス：
また、再度の記載になりますが、これら全てリージョン毎に設定が必要な点にご留意ください。
余談
本ブログのタイトルがいつもの私らしくないと感じた方、正解です。
本ブログのタイトルは Google Gemini に考えてもらいました。たまにはこういうのも良いだろうと思ってそのまま使ってみています。
では、またお会いしましょう。
*1:本アカウント設定はリージョンごとに設定が必要です
*2:暗号化がサポートされていないインスタンスタイプも存在しますが、c1 など非常に古いインスタンスタイプであるため、今回は除外して考えています
*3:テンプレートに個別に KMS キーを指定可能ですが、それを失念したとしても本設定により最低限暗号化は行われます
*4:デフォルトの AWS Managed CMK で暗号化された AMI はそもそも共有設定ができないことに注意してください
*5:この場合のタグ値は不要です
*6:ユーザの利用状況によっては仕様を理解した上で 1 にして頂いても問題はありません
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
