%201.svg){kind=logo}
Amazon Web Services（AWS）でワークロードをホストされている場合、そのワークロードを稼働させるためにEC2をご利用になる可能性が高いでしょう。EC2は、アプリケーションをホストする仮想マシン（VM）を展開できるスケーラブルなクラウドサービスです。EC2はAWSで利用可能な数百のサービスの一つに過ぎませんが、最も広く利用されているサービスの一つです。
そのため、AWS環境を管理するほとんどのチームにとって、EC2のセキュリティ対策を理解することは重要です。クラウド戦略にEC2が含まれる場合、どのようなセキュリティリスクが影響するか、保護に役立つツールや手法は何か、そして可能な限り安全にするためのベストプラクティスを知る必要があります。本記事では、AWS EC2セキュリティの包括的な概要を提供するため、これらのトピックについて詳しく解説します。
AWS EC2とは？
AWS EC2は、Infrastructure-as-a-Service（IaaS）ソリューションであり、ユーザーがAWSクラウド上で仮想マシンインスタンスを起動することを可能にします。（EC2では、仮想マシンではなく物理マシンをご希望のお客様向けに、AWSが専用ホストと呼ぶ物理サーバーの限定的な選択肢も提供しています）。
EC2が人気のクラウドサービスである理由はいくつかあります：
- AWSは数百種類のEC2インスタンスタイプを提供しており、それぞれCPU、メモリ、および（場合によっては）特殊なハードウェア構成が異なります。これらの選択肢により、様々なワークロードに最適なインスタンスタイプを容易に見つけることができます。
- 完全に管理されたサービスとして、EC2は設定と使用が容易です。お客様は希望するインスタンスタイプを決定し、ネットワークやストレージなどの基本設定を行うだけで結構です。その後は、AWSが仮想マシンの稼働と管理、および仮想マシンが依存する基盤となる物理インフラのサポートを代行します。
- EC2は複数の異なる料金モデルで提供されています。オンデマンド料金は、お客様がいつでも仮想マシンを起動できる最も高価な方法ですが、コスト削減をご希望のお客様は、予約インスタンスなどの料金オプションをご利用いただけます。予約インスタンスでは、事前に予約することで割引されたEC2インスタンスをご利用いただけます。
- EC2は高いスケーラビリティを実現するよう設計されており、お客様はワークロードのホスティングに割り当てられたリソースを容易に変更できます。
ワークロードのホスティングに柔軟で費用対効果の高いソリューションをお求めのアWSユーザー様にとって、EC2は is a great option.
EC2セキュリティの重要性
EC2は、ユーザー側の設定や管理負担を最小限に抑えながらVMインスタンスを簡単に起動できますが、ユーザーのワークロードを自動的に保護するものではありません。
AWSはEC2インスタンスをセキュリティリスクや脅威から保護する責任を負いません。そのため、ユーザーが外部セキュリティソリューションを導入することが極めて重要です。AWSはEC2インスタンスをホストする基盤インフラの安全性を維持する責任を負いますが、EC2インスタンス内で動作するソフトウェアのセキュリティは保証しません。これはAWSの共有責任モデルに基づき、お客様ご自身で対応いただくことを前提としています。
つまり、EC2をセキュリティリスクから保護する唯一の方法は、積極的なEC2セキュリティ戦略を策定することです。AWSがEC2のセキュリティを代行してくれると期待することは、ワークロードを様々なセキュリティ問題に晒す重大な過ちとなります。
EC2の主なセキュリティリスク
EC2インスタンスは、AWS自体が保護を試みない様々なセキュリティ脅威やリスクの影響を受ける可能性があります。これには以下が含まれます：
- お客様がEC2インスタンス内にインストールするオペレーティングシステムの脆弱性。公式にサポートされているEC2オペレーティングシステムイメージをご利用の場合でも、カスタムイメージを展開する場合でも、お使いのOSには脆弱性が含まれている可能性があります。攻撃者はこの脆弱性を悪用して、データの不正取得、マルウェアの展開、さらにはVMインスタンス全体の制御を奪うことさえ可能となります。
- EC2上にデプロイする個々のアプリケーションの脆弱性。これらの脆弱性は、VMの完全な制御奪取を含む（ただしこれに限定されない）様々な攻撃を可能にする可能性があり、EC2インスタンス上で実行するOSが安全であっても存在する可能性があります。
- ネットワーク設定の誤り。不適切なネットワーク設定により、EC2インスタンスがインターネット経由の攻撃に晒される可能性や、ネットワーク上で送信される機密データを悪意のある者が傍受する機会を提供してしまう恐れがあります。
- AWSアカウントにおける脆弱なアクセス制御。過度に許可的なIdentity and Access Management（IAM）設定は、攻撃者や悪意のある内部関係者によるEC2インスタンス設定の変更や、EC2上で実行中のワークロードの改変を容易にしてしまう可能性があります。
- EC2インスタンスが使用するストレージリソースを管理するセキュリティ設定の不備。多くの場合、EC2上でホストされる仮想マシン（VM）は、ブロックストレージサービスであるAmazon EBSを使用して永続データを保存します。EBSの構成方法における見落とし（例えば、デフォルトでは暗号化されないEBSボリュームの暗号化を忘れるなど）は、機密データを攻撃に晒す可能性があります。（明確に申し上げますと、EBSはEC2とは別のサービスであるため、不適切なストレージ設定がEC2そのものに直接的なリスクをもたらすわけではありません。しかしながら、EBSとEC2は密接に関連しているため、EBSのセキュリティ対策が不十分である場合、EC2上でホストされているあらゆるワークロードのセキュリティ問題につながる可能性があります。）
したがって、EC2インスタンスは様々な経路を通じた攻撃に対して脆弱となる可能性があります。EC2のセキュリティを積極的に強化することで初めて、EC2インスタンスおよびそこにホストされているワークロードに影響を及ぼす可能性のある様々なセキュリティリスクや脅威に先手を打つことが可能となります。
セキュリティ上のリスクは、すべてのEC2インスタンスタイプおよび構成に影響を及ぼします。
特筆すべきは、上記のセキュリティリスクがすべてのEC2インスタンスタイプおよび構成に適用される点です。汎用的なEC2インスタンスタイプを使用する場合でも、GPU加速ワークロード向けに最適化されたインスタンスなどの特殊なタイプを使用する場合でも、脆弱性、脆弱なアクセス制御、不安全なストレージに関連する中核的なセキュリティリスクは同様です。
同様に、選択される料金モデルもEC2インスタンスのセキュリティに実質的な影響を与えません。お支払い方法にかかわらず、EC2ワークロードはリスクに晒される可能性があります。
要するに、本質的に安全なEC2インスタンスは存在しないということです。すべてのEC2インスタンスタイプおよびデプロイメントは、構成の詳細にかかわらず、安全でない可能性があります。
AWS EC2のセキュリティ確保におけるベストプラクティス
幸いなことに、上記のようなセキュリティリスクを回避するのに役立つ、いくつかの有効なベストプラクティスが存在します。
ワークロードの分離
単一のEC2インスタンス上で複数のアプリケーションをホストすることは可能です。ただし、原則として、異なるワークロードには別々のインスタンスを作成する方がより安全です。これにより、あるアプリケーション（またはそれをホストするOS）内の脆弱性が他のワークロードに影響を与えることを防げます。
また、EC2では非常に多くのインスタンスタイプが提供されているため、ほとんどのケースにおいて、実行するワークロードの規模に関わらず、費用対効果の高いインスタンスタイプを見つけることが容易です。言い換えれば、複数のワークロードを単一のEC2インスタンスに統合しようとすることでコスト削減が実現する可能性は低い一方で、セキュリティリスクを高める恐れがあります。したがって、各ワークロードを個別のインスタンスで運用することが賢明です。
AWS IAMにおける最小権限の原則の適用
AWS環境内のユーザーがEC2インスタンスにアクセスできる権限を設定する際には、最小権限の原則に従ってください。最小権限とは、各ユーザーに必要な最小限のアクセス権限のみを付与することを意味します。アクセス制御は細分化され、各ユーザーの特定のニーズに合わせた権限が設定されるべきです。
例えば、あるユーザーはEC2に関する特定の種類の情報を読み取る権限のみを必要とする場合があります。このようなポリシーは、以下のようなIAM設定を通じて実施できます：
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeTags",
"ec2:DescribeSnapshots"
],
"Resource": "*"
}]
}
一方、EC2インスタンスのストレージボリュームを表示および作成する権限の両方が必要なユーザーには、以下のようなポリシーを割り当てることができます
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeVolumes",
"ec2:DescribeAvailabilityZones",
"ec2:CreateVolume",
"ec2:DescribeInstances"
],
"Resource": "*"
}, {
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:region:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/purpose": "test"
}
}
}, {
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:region:111122223333:volume/*"
}]
}
ユーザーごとに最小限の権限を適用することは、すべてのユーザーにEC2および関連リソースに対する完全な制御権を付与するよりも、はるかに安全です。
ネットワークの保護
同様に、ネットワークレベルにおいても、EC2のセキュリティ対策として、ネットワークリソースを構成する際に、EC2インスタンスをインターネットに公開するのは必要な時と場所のみに限定することがベストプラクティスです。
AWSはEC2向けに様々なネットワーク構成オプションを提供しており、EC2のネットワークを保護する最善の方法は、ネットワークを構成する際に採用するアプローチによって異なります。ただし、インターネットに直接接続する必要のない EC2 インスタンスは、ファイアウォールの背後で保護されるようにすることが目標です。さらに、不要なポートの開放やネットワークプロトコルの有効化は避けるべきです。一般的に、インターネットに公開されるアプリケーションをホストする EC2 インスタンスのみがインターネットへの露出を必要とし、その場合でも、インターネット上のユーザーがインスタンスとやり取りできる方法を厳密に制限すべきです。
EC2ワークロードの脆弱性を監視する
EC2上の脆弱性から保護するため、チームはEC2インスタンス内で実行しているオペレーティングシステムとアプリケーションを体系的に追跡し、既知の脆弱性がないか確認する必要があります。繰り返しになりますが、公式にサポートされているEC2 OSイメージを使用している場合でも、脆弱性が存在しない保証はなく、また、スキャンを行わない限り、EC2上で実行しているアプリケーションが脆弱性から完全に自由であるとは確信できません。
AWSはこれらのスキャンを代行いたしません。共有責任モデルに基づくEC2の脆弱性監視は、お客様ご自身で実施いただく必要がございます。
EC2ソフトウェアを最新の状態に保つ
同様に、EC2をご利用のお客様には、EC2上でホストされているオペレーティングシステムおよびアプリケーションが、常に最新のパッチを適用された状態に保たれるようご自身で管理いただく必要がございます。ソフトウェアを最新の状態に保つことは、セキュリティ上の脆弱性から保護する上で重要です。
AWSはEC2を稼働させる基盤ソフトウェアの更新を提供しますが、お客様がEC2上に展開するソフトウェアの更新は行いません。後者の更新のインストールは、EC2ユーザーの皆様の責任となります。
まとめ
EC2は強力なクラウドコンピューティングサービスですが、ユーザーの観点からは多くのセキュリティ上の課題が存在します。ソフトウェアの脆弱性や不適切なアクセス制御設定など、EC2に影響を及ぼす様々なリスクを理解することは、EC2を利用するあらゆるチームにとって極めて重要です。同様に、ワークロードの脆弱性スキャンや最小権限のアクセス制御設定の徹底など、EC2のセキュリティリスクを最小限に抑えるベストプラクティスを遵守することも重要です。