# セキュリティとコンプライアンスの目標を満たすように Amazon EC2 を設定し、Amazon EC2 リソースの保護に役立つ他の サービスの使用方法を学びます。
AWS ではクラウドのセキュリティが最優先事項です。AWS のお客様はセキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャから利点を得られます。
セキュリティはAWS とお客様の間の共有責任です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)ではこれをクラウドのセキュリティおよびクラウド内のセキュリティと説明しています。
+ **クラウドのセキュリティ** - AWS は AWS Cloud で AWS のサービスを実行するインフラストラクチャを保護する責任を負います。また、AWS は使用するサービスを安全に提供します。[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。Amazon EC2 に適用するコンプライアンスプログラムの詳細については[AWSコンプライアンスプログラムによる対象範囲の](https://aws.amazon.com/compliance/services-in-scope/)
+ **クラウド内のセキュリティ** - お客様は以下の事項について責任を負います。
+ VPC とセキュリティグループの設定など、インスタンスへのネットワークアクセスの制御。詳細については[ネットワークトラフィックの制御](infrastructure-security.md#control-network-traffic)を参照してください。
+ インスタンスへの接続に使用する認証情報の管理。
+ ゲスト OS と、ゲスト OS にデプロイされたソフトウェア (更新およびセキュリティパッチを含む) の管理。詳細については[Amazon EC2 Windows インスタンスの更新管理](update-management.md)を参照してください。
+ インスタンスにアタッチされた IAM ロールと、それらのロールに関連付けられたアクセス許可の設定。詳細については[Amazon EC2 の IAM ロール](iam-roles-for-amazon-ec2.md)を参照してください。
このドキュメントは Amazon EC2 使用時における責任共有モデルの適用法を理解するのに役立ちます。ここではセキュリティやコンプライアンスに関する目標を達成できるように Amazon EC2 を設定する方法について説明します。Amazon EC2リソースのモニタリングやセキュリティ確保に役立つ他の AWS サービスの使用方法についても説明します。
**Topics**
+ [データ保護](data-protection.md)
+ [インフラストラクチャセキュリティ](infrastructure-security.md)
+ [耐障害性](disaster-recovery-resiliency.md)
+ [コンプライアンス検証](compliance-validation.md)
+ [Identity and access management](security-iam.md)
+ [更新管理](update-management.md)
+ [Windows インスタンスにおけるベストプラクティス](ec2-windows-security-best-practices.md)
+ [キーペア](ec2-key-pairs.md)
+ [セキュリティグループ](ec2-security-groups.md)
+ [NitroTPM](nitrotpm.md)
+ [EC2 インスタンスアテステーション](nitrotpm-attestation.md)
+ [Windows インスタンスの クレデンシャルガード](credential-guard.md)
+ [AWS PrivateLink](interface-vpc-endpoints.md)
# Amazon EC2 でのデータ保護
AWS [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)は、Amazon Elastic Compute Cloud のデータ保護に適用されます。このモデルで説明されているように、AWS は、AWS クラウド のすべてを実行するグローバルインフラストラクチャを保護する責任を担います。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「AWS のサービス」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された「[AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/)」のブログ記事を参照してください。
データを保護するため、「AWS アカウント」認証情報を保護し、AWS IAM アイデンティティセンター または AWS Identity and Access Management (IAM) を使用して個々のユーザーをセットアップすることをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して AWS リソースと通信します。TLS 1.2 は必須ですが、TLS 1.3 を推奨します。
+ AWS CloudTrail で API とユーザーアクティビティロギングを設定します。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「**AWS CloudTrail ユーザーガイド」の「[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS のサービス内のすべてのデフォルトセキュリティコントロールに加え、AWS 暗号化ソリューションを使用します。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API を使用して AWS にアクセスする際に FIPS 140-3 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これには、コンソール、API、AWS CLI、または AWS SDK を使用して Amazon EC2 またはその他の AWS のサービス で作業する場合が含まれます。タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
**Topics**
+ [Amazon EBS のデータセキュリティ](#ebs-data-security)
+ [保管中の暗号化](#encryption-rest)
+ [転送中の暗号化](#encryption-transit)
## Amazon EBS のデータセキュリティ
Amazon EBS ボリュームは、初期化されていない raw ブロックデバイスとして表示されます。これらのデバイスは、EBS インフラストラクチャ上に作成される論理デバイスであり、Amazon EBS サービスは、お客様による利用または再利用の前に、デバイスが論理的に空になっている (つまり、raw ブロックがゼロになっている、または暗号で擬似ランダムデータが含まれている) ようにします。
**DoD 5220.22-M** (National Industrial Security Program Operating Manual) や **NIST 800-88** (Guidelines for Media Sanitization) に詳述されているような、使用後もしくは使用前 (またはその両方) に特定の方法を使用してすべてのデータを消去する必要がある手順がある場合、Amazon EBS でこれを行うことができます。ブロックレベルのアクティビティは、Amazon EBS サービス内の基盤となるストレージメディアに反映されます。
## 保管中の暗号化
**EBS ボリューム**
Amazon EBS暗号化は、EBS ボリュームおよびスナップショット向けの暗号化ソリューションです。それは AWS KMS keys を使用します。詳細については、「*Amazon EBS ユーザーガイド*」の「[Amazon EBS 暗号化](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html)」を参照してください。
[Windows インスタンス] フォルダレベルおよびファイルレベルの暗号化に Microsoft EFS および NTFS アクセス許可を使用することもできます。
**インスタンスストアボリューム**
NVMe インスタンスストアボリューム内のデータは、インスタンスのハードウェアモジュールに実装されている XTS-AES-256 暗号を使用して暗号化されます。ローカルに接続された NVMe ストレージデバイスに書き込まれるデータの暗号化に使用されるキーは、お客様ごと、ボリュームごとに異なります。キーはハードウェアモジュールによって生成され、ハードウェアモジュールの内部にのみ存在します。AWS ユーザーはハードウェアモジュールにはアクセスできません。暗号化キーは、インスタンスが停止または終了して復元できないときに破棄されます。この暗号化を無効にしたり、独自の暗号キーを指定したりすることはできません。
H1、D3、D3en インスタンス上にある HDD インスタンスストアボリュームのデータは、XTS-AES-256 とワンタイムキーを使用して暗号化されます。
インスタンスを、停止、休止、または終了するとき、インスタンスストアボリュームのストレージの各ブロックはリセットされます。そのため、別のインスタンスのインスタンスストアを通じてデータにアクセスすることはできません。
**メモリ**
メモリの暗号化は、次のインスタンスで有効になります。
+ AWS Graviton2 以降の AWS Graviton プロセッサを搭載したインスタンスは、常時オンのメモリ暗号化をサポートします。暗号化キーは、ホストシステム内で安全に生成され、ホストシステムから離れることはなく、ホストの再起動または電源切断時に破棄されます。詳細については、「[AWS Graviton プロセッサ](https://aws.amazon.com/ec2/graviton/)」を参照してください。
+ M6i インスタンスなどの第 3 世代 Intel Xeon スケーラブルプロセッサ (Ice Lake) と M7i インスタンスなどの第 4 世代 Intel Xeon スケーラブルプロセッサ (Sapphire Rapids) を搭載したインスタンス。これらのプロセッサーは、インテル・トータル・メモリー暗号化 (TME) を使用した常時オンのメモリー暗号化をサポートします。
+ M6a インスタンスなどの第 3 世代 AMD EPYC プロセッサ (Milan) と M7a インスタンスなどの第 4 世代 AMD EPYC プロセッサ (Genoa) を搭載したインスタンス。これらのプロセッサーは、AMD Secure Memory Encryption (SME) を使用した常時オンのメモリー暗号化をサポートします。
+ AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) は、一部の AMD ベースのインスタンスタイプでサポートされています。詳細については、「[AMD SEV-SNP をサポートする EC2 インスタンスタイプの検索](snp-find-instance-types.md)」を参照してください。
## 転送中の暗号化
**物理レイヤーでの暗号化**
AWS グローバルネットワーク上の AWS リージョンを流れるすべてのデータは、AWS の安全な施設を離れる前に、物理層で自動的に暗号化されます。AZ 間のトラフィックはすべて暗号化されます。追加的な暗号化レイヤーでは、このセクションに記載されているもの以外にも、保護が提供されている場合があります。
**Amazon VPC ピアリングおよび Transit Gateway のクロスリージョンピアリング接続によって得られる暗号化**
Amazon VPC ピアリングおよび Transit Gateway のピアリング接続を使用する、すべてのクロスリージョントラフィックは、リージョンからの送信時に自動的に一括で暗号化されます。このセクションで先に述べたように、すべてのトラフィックにおける物理レイヤーには、そのトラフィックが AWS の保護された設備を離れる前に、追加の暗号化レイヤーが自動的に提供されています。
**インスタンス間での暗号化**
AWS では、すべてのタイプの EC2 インスタンス間において安全でプライベートな接続を提供しています。さらに、一部のインスタンスタイプでは、基盤となる Nitro System ハードウェアのオフロード機能を使用して、インスタンス間の転送中のトラフィックを自動的に暗号化します。この暗号化では、256 ビットの暗号化による関連データによる認証暗号化 (AEAD) アルゴリズムを使用します。ネットワークのパフォーマンスには影響しません。インスタンス間でこの追加の転送中トラフィック暗号化をサポートするには、次の要件を満たす必要があります。
+ インスタンスは、次のインスタンスタイプを使用します。
+ **汎用**: M5dn、M5n、M5zn、M6a、M6i、M6id、M6idn、M6in、M7a、M7g、M7gd、M7i、M7i-flex、M8a、M8azn、M8g、M8gb、M8gd、M8gn、M8i、M8id、M8i-flex、Mac-m4、Mac-m4pro
+ **コンピューティング最適化:** C5n、C6a、C6gn、C6i、C6id、C6in、C7a、C7g、C7gd、C7gn、C7i、C7i-flex、C8a、C8g、C8gb、C8gd、C8gn、C8i、C8id、C8i-flex
+ **メモリ最適化:** R5dn、R5n、R6a、R6i、R6id、R6idn、R6in、R7a、R7g、R7gd、R7i、R7iz、R8a、R8g、R8gb、R8gd、R8gn、R8i、R8id、R8i-flex、U-3tb1、U-6tb1、U-9tb1、U-12tb1、U-18tb1、U-24tb1、U7i-6tb、U7i-8tb、U7i-12tb、U7in-16tb、U7in-24tb、U7in-32tb、U7inh-32tb、X2idn、X2iedn、X2iezn、X8g、X8aedz、X8i
+ **ストレージ最適化:** D3、D3en、I3en、I4g、I4i、I7i、I7ie、I8g、I8ge、Im4gn、Is4gen
+ **高速コンピューティング:** DL1、DL2q、F2、G4ad、G4dn、G5、G6、G6e、G6f、Gr6、Gr6f、G7e、Inf1、Inf2、P3dn、P4d、P4de、P5、P5e、P5en、P6-B200、P6-B300、P6e-GB200、Trn1、Trn1n、Trn2、Trn2u、VT1
+ **ハイパフォーマンスコンピューティング:** Hpc6a、Hpc6id、Hpc7a、Hpc7g、Hpc8a
+ 各インスタンスは同じリージョンにあるものとします。
+ 各インスタンスは同じ VPC 内、あるいはピア接続された VPC 内にあり、トラフィックは仮想ネットワークのデバイスもしくはサービス (ロードバランサーや Transit Gateway など) を通過しないものとします。
このセクションで先に述べたように、すべてのトラフィックにおける物理レイヤーには、そのトラフィックが AWS の保護された設備を離れる前に、追加の暗号化レイヤーが自動的に提供されています。
**AWS CLIを使用してインスタンス間のトランジットトラフィックを暗号化するインスタンスタイプを表示するには、以下のようにします。**
次の [ describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-types.html) コマンドを使用します。
```
aws ec2 describe-instance-types \
--filters Name=network-info.encryption-in-transit-supported,Values=true \
--query "InstanceTypes[*].[InstanceType]" \
--output text | sort
```
**AWS Outposts との間の暗号化**
Outpost は、AWS ホームリージョンとの間に*サービスリンク*と呼ばれる特別なネットワーク接続を作成し、オプションとして指定した VPC サブネットとのプライベート接続も可能です。これらの接続上のすべてのトラフィックは完全に暗号化されます。詳細については、*AWS Outposts ユーザーガイド*の[サービスリンクによる接続](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links)および[転送中の暗号化](https://docs.aws.amazon.com/outposts/latest/userguide/data-protection.html#encryption-transit)を参照してください。
**リモートアクセスの暗号化**
SSH プロトコルおよび RDP プロトコルは、直接でも EC2 Instance Connect 経由でも、インスタンスへのリモートアクセスにおいてセキュアな通信チャネルを提供します。AWS Systems Manager Session Manager または Run Command を使用したインスタンスへのリモートアクセスは、TLS 1.2 を使用して暗号化されます。また、接続確立のリクエストは [SigV4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) を使用して署名され、[AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) により認証および許可されます。
クライアントと Amazon EC2 インスタンスの間の転送中の機密データを、Transport Layer Security (TLS) などの暗号化プロトコルを使用して暗号化することは、お客様の責任範囲です。
(Windows インスタンス) EC2 インスタンスと、AWS API エンドポイントなどの機密性の高いリモートネットワークサービスとの間では、必ず暗号化された接続のみを許可してください。これを適用するには、アウトバウンドセキュリティグループまたは [Windows ファイアウォール](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/)のルールを使用します。
# Amazon EC2 でのインフラストラクチャセキュリティ
マネージドサービスとして、Amazon Elastic Compute Cloud は AWS グローバルネットワークセキュリティによって保護されています。AWS セキュリティサービスと AWS がインフラストラクチャを保護する方法については「[AWS クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには「*セキュリティの柱 - AWS 適切なアーキテクチャを備えたフレームワーク*」の「[インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が公開している API コールを使用し、ネットワーク経由で Amazon EC2にアクセスします。クライアントは次をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
詳細については、「*セキュリティの柱 - AWS Well-Architected フレームワーク*」の「[インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
## ネットワークの隔離
仮想プライベートクラウド (VPC) はAWS クラウド内の論理的に隔離された領域にある仮想ネットワークです。ワークロードまたは組織エンティティ単位でインフラストラクチャを隔離するには個別の VPC を使用します。
サブネットはある範囲の IP アドレスが示す VPC 内の領域です。インスタンスを起動する場合にはVPC 内のあるサブネットにおいて起動することになります。サブネットを使用すると、単一の VPC 内で多階層ウェブアプリケーションの各階層 (ウェブサーバー、アプリケーションサーバーおよびデータベースサーバーなど) を隔離できます。インターネットからの直接アクセスを認めるべきでないインスタンスにはプライベートサブネットを使用します。
プライベート IP アドレスを使用して VPC から Amazon EC2 API を呼び出すにはAWS PrivateLink を使用します。詳細については「[インターフェイス VPC エンドポイントを使用して Amazon EC2 にアクセスします。](interface-vpc-endpoints.md)」を参照してください。
## 物理ホストでの分離
同じ物理ホストで実行される異なる EC2 インスタンスは個別の物理ホストで実行されるかのように隔離されます。ハイパーバイザーが CPU およびメモリを隔離し、各インスタンスには生ディスクデバイスへのアクセスに代わる仮想ディスクへのアクセスが提供されます。
インスタンスを停止または終了すると、そのインスタンスに割り当てられていたメモリをハイパーバイザーがスクラブ (ゼロに設定) し、そのメモリが新たなインスタンスに割り当てられ、すべてのストレージブロックがリセットされます。これはお客様のデータが誤って他のインスタンスに引き渡されないようにするための処理です。
ネットワーク MAC アドレスはAWS ネットワークインフラストラクチャが各インスタンスに対し動的に割り当てます。IP アドレスはAWS ネットワークインフラストラクチャが各インスタンスに対し動的に割り当てるか、要認証 API リクエストを介して EC2 管理者が割り当てます。AWS ネットワークはインスタンスは割り当てられた MAC および IP アドレスからのみトラフィックを送信できます。それ以外のトラフィックは除外されます。
デフォルトではインスタンスはそのインスタンス宛ではないトラフィックを受信することはできません。インスタンスにおいて、ネットワークアドレス変換 (NAT、network address translation)、ルーティングまたはファイアウォールといったサービスの実行が必要な場合にはネットワークインターフェースの送信元/送信先チェックを無効化できます。
## ネットワークトラフィックの制御
EC2 インスタンスへのネットワークトラフックを制御するには以下のオプションを検討します。
+ [セキュリティグループ](ec2-security-groups.md)を使用してインスタンスへのアクセスを制限します。最小限必要なネットワークトラフィックを許可するルールを設定します。例えば、企業ネットワークのアドレス範囲からのトラフィックのみ、または HTTPS など特定のプロトコルのトラフィックのみを許可することができます。Windows インスタンスではWindows 管理トラフィックと最小限のアウトバウンド接続を許可します。
+ Amazon EC2 インスタンスへのネットワークアクセスをコントロールするための主要なメカニズムとして、セキュリティグループを活用します。必要に応じて、ネットワーク ACL を控えめに使用して、ステートレスできめの粗いネットワークコントロールを提供します。セキュリティグループはステートフルなパケットフィルタ処理を実行でき、他のセキュリティグループを参照するルールを作成できるため、ネットワーク ACL よりも汎用性があります。ただし、ネットワーク ACL はトラフィックの特定のサブセットを拒否したり、高レベルのサブネットガードレールを提供したりするための、セカンダリコントロールとして効果的です。また、ネットワーク ACL はサブネット全体に適用されるため、多層防御として使用して、正しいセキュリティグループなしでインスタンスが意図せずに起動される事態に備えることができます。
+ [Windows インスタンス] グループポリシーオブジェクト (GPO) を使用して Windows Firewall 設定を一元的に管理し、ネットワークコントロールをさらに強化します。顧客は多くの場合、Windows Firewall を使用してネットワークトラフィックをさらに可視化し、セキュリティグループフィルタを補完して、特定のアプリケーションからのネットワークへのアクセスをブロックしたり、サブセット IP アドレスからのトラフィックをフィルタ処理したりする高度なルールを作成します。例えば、Windows Firewall はEC2 メタデータサービスの IP アドレスへのアクセスを特定のユーザーまたはアプリケーションに制限できます。また、公開サービスではセキュリティグループを使用して、特定のポートへのトラフィックを制限し、Windows Firewall を使用して、明示的にブロックされた IP アドレスのリストを維持する場合があります。
+ インターネットからの直接アクセスを認めるべきでないインスタンスにはプライベートサブネットを使用します。プライベートサブネット内にあるインスタンスからのインターネットアクセスに踏み台ホストまたは NAT ゲートウェイを使用します。
+ [Windows インスタンス] SSL/TLS を介した RDP カプセル化などのセキュアな管理プロトコルを使用します。リモートデスクトップゲートウェイクイックスタートからはSSL/TLS を使用するように RDP を設定するなど、リモートデスクトップゲートウェイのデプロイに関するベストプラクティスを得られます。
+ [Windows インスタンス] Active Directory または Directory Service を使用して、Windows インスタンスへのインタラクティブなユーザーアクセスおよびグループアクセスを厳密かつ一元的に制御およびモニタリングし、ローカルユーザーのアクセス許可を防ぎます。また、ドメイン管理者の使用を避け、代わりに、より細かいアプリケーション固有のロールベースのアカウントを作成します。Just Enough Administration (JEA) により、Windows インスタンスに対する変更をインタラクティブなアクセスや管理者のアクセスなしで管理できます。さらに、JEA を使用すると、組織はインスタンス管理に必要な Windows PowerShell コマンドのサブセットへの管理アクセスをロックダウンできます。追加の情報については[AWS セキュリティのベストプラクティス](https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf)ホワイトペーパーの Amazon EC2 への「OS レベル」のアクセスの管理セクションを参照してください。
+ [Windows インスタンス] システム管理者はアクセスが制限された Windows アカウントを使用して日常のアクティビティを実行し、特定の設定変更を実行する必要があるときにのみアクセスを昇格させる必要があります。さらに、絶対に必要な場合にのみ Windows インスタンスに直接アクセスするようにします。代わりに、EC2 Run Command、Systems Center Configuration Manager (SCCM)、Windows PowerShell DSC、または Amazon EC2 Systems Manager (SSM) などの一元設定管理システムを活用して、変更を Windows サーバーにプッシュします。
+ 最小限必要なネットワークルートを使用して Amazon VPC サブネットルートテーブルを設定します。例えば、インターネットゲートウェイへのルートがあるサブネットに、インターネットへの直接アクセスを必要とする Amazon EC2 インスタンスのみを配置し、仮想プライベートゲートウェイへのルートがあるサブネットに、内部ネットワークへの直接アクセスを必要とする Amazon EC2 インスタンスのみを配置します。
+ 追加のセキュリティグループまたはネットワークインターフェイスを使用して、Amazon EC2 インスタンス管理トラフィックを通常のアプリケーショントラフィックとは別に制御および監査することをご検討ください。このアプローチにより、顧客は変更管理用の特別な IAM ポリシーを実装できるため、セキュリティグループルールや自動化されたルール検証スクリプトに対する変更の監査が容易になります。複数のネットワークインターフェイスを使用すると、ホストベースのルーティングポリシーを作成したり、ネットワークインターフェイスの割り当てられたサブネットに基づいて異なる VPC サブネットルーティングルールを活用したりするなど、ネットワークトラフィックを制御するための他のオプションも利用できます。
+ AWS Virtual Private Network または Direct Connectを使用して、リモートネットワークから VPC へのプライベート接続を確立します。詳細については[ネットワークから Amazon VPC への接続オプション](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)を参照してください。
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)を使用して、インスタンスに到達するトラフィックを監視します。
+ [GuardDuty Malware Protection](https://docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html) はワークロードを危険にさらしたり、リソースを悪用したり、データに不正にアクセスしたりする、悪意のあるソフトウェアによるインスタンス上での不審な動作を特定するために使用します。
+ [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) はインスタンスへの潜在的脅威を特定し、これに対処するために使用します。詳細については「[How Runtime Monitoring works with Amazon EC2 instances](https://docs.aws.amazon.com/guardduty/latest/ug/how-runtime-monitoring-works-ec2.html)」を参照してください。
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/)、[Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/) または [Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/) を使用して、インスタンスからの意図しないネットワークアクセスがないか確認します。
+ [EC2 Instance Connect](connect-linux-inst-eic.md)を使用して、SSH キーの共有および管理が不要な Secure Shell (SSH) を使いインスタンスに接続します。
+ インバウンド SSH または RDP ポートを開いてキーペアを管理する代わりに、[AWS Systems Manager セッションマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html)を使用してインスタンスにリモートアクセスします。
+ インスタンスに接続する代わりに、[AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) を使用して一般的な管理タスクを自動化します。
+ [Windows インスタンス] Windows OS のロールと Microsoft のビジネスアプリケーションの多くにはIIS 内の IP アドレス範囲制限、Microsoft SQL Server の TCP/IP フィルタリングポリシー、Microsoft Exchange の接続フィルターポリシーなどの拡張機能も備わっています。アプリケーション層内のネットワーク制限機能により、重要なビジネスアプリケーションサーバーに追加の防御層を提供できます。
Amazon VPC はゲートウェイ、プロキシサーバー、ネットワークモニタリングのオプションなど、追加のネットワークセキュリティコントロールをサポートしています。詳細については「*Amazon VPC ユーザーガイド*」の「[Control network traffic](https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html#control-network-traffic)」を参照してください。
# Amazon EC2の耐障害性
AWS のグローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心として構築されています。リージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立および隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。
データまたはアプリケーションをより広範な地理的距離にわたってレプリケートする必要がある場合は、AWS Local Zonesを使用します。AWS ローカルゾーンは AWS リージョンの拡張であり、ユーザーに近い場所に配置されます。Local Zones は、インターネットへの独自の接続を持ち、Direct Connect をサポートします。すべての AWS リージョンと同じように、AWS Local Zonesは他の AWS リージョンから完全に分離されています。
AWS ローカルゾーン内でデータまたはアプリケーションをレプリケートする必要がある場合、次のいずれかのゾーンをフェイルオーバーゾーンとして使用することを AWS はお勧めします。
+ 別のローカルゾーン
+ 親ゾーンではないリージョン内のアベイラビリティーゾーン。親ゾーンを確認するには、[describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html) コマンドを使用できます。
AWS リージョンとアベイラビリティーゾーンの詳細については、[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)を参照してください。
Amazon EC2 は、AWS グローバルインフラストラクチャに加え、データ耐障害性をサポートする以下の機能を提供します。
+ リージョンで AMI をコピーする機能
+ リージョン間の EBS スナップショットをコピーする機能
+ Amazon Data Lifecycle Manager を使用した EBS-backed AMI の自動化
+ Amazon Data Lifecycle Managerを使用して EBS スナップショットを自動化する機能
+ Amazon EC2 Auto Scalingを使用してフリートの健全性や可用性を維持する機能
+ Elastic Load Balancing を使用して、単一のまたは複数のアベイラビリティーゾーンにある複数のインスタンスの間で受信トラフィックを分散する機能
# Amazon EC2 のコンプライアンス検証
AWS のサービスが特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「[コンプライアンスプログラムによる AWS のサービス 対象範囲内](https://aws.amazon.com/compliance/services-in-scope/)」を参照して、関心のあるコンプライアンスプログラムを選択してください。一般的な情報については、[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) を参照してください。
AWS Artifact を使用して、サードパーティの監査レポートをダウンロードできます。詳細については、「[AWS Artifact でレポートをダウンロードする](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」「」を参照してください。
AWS のサービスを使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目的、適用可能な法律および規制によって決定されます。AWS のサービス を使用する際のコンプライアンス責任の詳細については、[AWS セキュリティドキュメント](https://docs.aws.amazon.com/security/)を参照してください。
# Amazon EC2 の Identity and Access Management
AWS Identity and Access Management (IAM) は管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービスです。IAM 管理者は Amazon EC2 リソースの使用に「*認証*」(サインイン) されて「*承認*」(許可の付与) される人を管理します。IAM は追加費用なしで使用できる AWS のサービスです。
セキュリティ認証情報により、AWS サービスでユーザーの身分が証明され、Amazon EC2 リソースなどの AWS リソースへのアクセスが付与されます。Amazon EC2 および IAM の機能を使用して、他のユーザー、サービス、およびアプリケーションがユーザーの Amazon EC2 リソースを使用できるようにします。その際、ユーザーのセキュリティ認証情報は共有されません。他のユーザーが AWS アカウントのリソースを使用する方法を制御するには IAM を、Amazon EC2 インスタンスへのアクセスを制御するにはセキュリティグループを使用できます。Amazon EC2 のリソースの完全使用または制限付き使用のどちらを許可するか選択できます。
開発者はEC2 インスタンスで実行するアプリケーションに必要なセキュリティ認証情報を、IAM ロールを使用して管理できます。IAM ロールをインスタンスにアタッチすると、インスタンスで実行されているアプリケーションはインスタンスメタデータサービス (IMDS) から認証情報を取得できます。
IAM を使用して AWS リソースを保護するためのベストプラクティスについては「*IAM ユーザーガイド*」の「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
**Topics**
+ [Amazon EC2 のアイデンティティベースのポリシー](iam-policies-for-amazon-ec2.md)
+ [Amazon EC2 API へのアクセスを制御するポリシーの例](ExamplePolicies_EC2.md)
+ [Amazon EC2 コンソールへのアクセスを制御するポリシーの例](iam-policies-ec2-console.md)
+ [Amazon EC2 の AWS マネージドポリシー](security-iam-awsmanpol.md)
+ [Amazon EC2 の IAM ロール](iam-roles-for-amazon-ec2.md)
# Amazon EC2 のアイデンティティベースのポリシー
デフォルトではユーザーには Amazon EC2 リソースを作成または変更、または Amazon EC2 API、Amazon EC2 コンソールあるいは CLI を使用するタスクを実行する許可がありません。ユーザーがリソースを作成または変更、およびタスクを実行できるようにするにはIAM ポリシーを作成する必要があります。これによって、必要な特定のリソースおよび API アクションを使用するための許可をユーザーに付与し、その後、ポリシーをその許可が必要なユーザー、グループまたは IAM ロールにアタッチします。
ポリシーをユーザー、ユーザーのグループ、またはロールにアタッチする場合、ポリシーによって特定リソースの特定タスクを実行するユーザーの許可が許可または拒否されます。IAM ポリシーの一般的な情報については「*IAM ユーザーガイド*」の「[IAM の許可とポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)」を参照してください。&IAM; ポリシーの管理と作成の詳細については「[IAM ポリシーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html)」を参照してください。
IAM ポリシーは1 つ以上の Amazon EC2 アクションを使用するアクセス許可を付与または拒否する必要があります。さらに、このアクションで使用できるリソース (すべてのリソースか、場合によっては特定のリソース) も指定する必要があります。このポリシーにはリソースに適用する条件も含めることができます。
最初に、Amazon EC2 の AWS マネージドポリシーがニーズを満たしているかどうかを確認できます。満たしていない場合は独自のカスタムポリシーを作成できます。詳細については、[Amazon EC2 の AWS マネージドポリシー](security-iam-awsmanpol.md)を参照してください。
**Topics**
+ [ポリシー構文](#policy-syntax)
+ [Amazon EC2 のアクション](#UsingWithEC2_Actions)
+ [Amazon EC2 API アクションでサポートされるリソースレベルのアクセス許可](#ec2-supported-iam-actions-resources)
+ [Amazon EC2 用の Amazon リソースネーム (ARN)](#EC2_ARN_Format)
+ [Amazon EC2 の条件キー](#amazon-ec2-keys)
+ [属性ベースのアクセスを使用するアクセスの制御](#control-access-with-tags)
+ [ユーザー、グループ、およびロールに許可を付与する](#granting-iam-permissions)
+ [ユーザーが必要なアクセス許可を持っているかどうかの確認](#check-required-permissions)
## ポリシー構文
IAM ポリシーは 1 つ以上のステートメントで構成される JSON ドキュメントです。各ステートメントは次のように構成されます。
```
{
"Statement":[{
"Effect":"effect",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value"
}
}
}
]
}
```
ステートメントはさまざまなエレメントで構成されます。
+ **Effect**: *effect* は`Allow` または `Deny` にすることができます。デフォルトでは ユーザーはリソースおよび API アクションを使用するアクセス許可がないため、リクエストはすべて拒否されます。明示的な許可はデフォルトに上書きされます。明示的な拒否はすべての許可に優先します。
+ [**Action**]: *action* はアクセス許可を付与または拒否する対象とする、特定の API アクションです。*action* の指定については[Amazon EC2 のアクション](#UsingWithEC2_Actions)を参照してください。
+ [**Resource**]: アクションによって影響を及ぼされるリソースです。Amazon EC2 API アクションの中にはアクションによって作成/変更できるリソースをポリシー内で特定できるものもあります。Amazon リソースネーム (ARN) を使用して、またはステートメントがすべてのリソースに適用されることを示すワイルドカード (\$1) を使用して、リソースを指定します。詳細については、[Amazon EC2 API アクションでサポートされるリソースレベルのアクセス許可](#ec2-supported-iam-actions-resources)を参照してください。
+ [**Condition**]: condition はオプションです。ポリシーの発効条件を指定するために使用します。Amazon EC2 の条件を指定する方法については[Amazon EC2 の条件キー](#amazon-ec2-keys)を参照してください。
ポリシー要件の詳細については「*IAM ユーザーガイド*」の「[IAM JSON ポリシーリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)」を参照してください。Amazon EC2 の IAM ポリシーステートメントの例については「[Amazon EC2 API へのアクセスを制御するポリシーの例](ExamplePolicies_EC2.md)」を参照してください。
## Amazon EC2 のアクション
IAM ポリシーステートメントで、IAM をサポートするすべてのサービスから任意の API アクションを指定できます。Amazon EC2 の場合、API アクション `ec2:` の名前に次のプレフィクスを使用します。例: `ec2:RunInstances` および `ec2:CreateImage`。
単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。
```
"Action": ["ec2:action1", "ec2:action2"]
```
ワイルドカードを使用して複数のアクションを指定することもできます。例えば、以下のようにDescribeという単語で始まる名前のすべてのアクションを指定できます。
```
"Action": "ec2:Describe*"
```
**注記**
現在、すべての Amazon EC2 Describe\$1 API アクションがリソースレベルのアクセス許可をサポートしているわけではありません。Amazon EC2のリソースレベルの許可の詳細については[Amazon EC2 のアイデンティティベースのポリシー](#iam-policies-for-amazon-ec2)を参照してください。
Amazon EC2 API アクションをすべて指定するには\$1 ワイルドカードを以下のように使用します。
```
"Action": "ec2:*"
```
Amazon EC2 アクションのリストを確認するには「*Service Authorization Reference*」の「[Actions defined by Amazon EC2](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions)」を参照してください。
## Amazon EC2 API アクションでサポートされるリソースレベルのアクセス許可
*リソースレベルのアクセス許可*とはユーザーがアクションを実行できるリソースを指定できる機能を意味します。Amazon EC2 はリソースレベルのアクセス許可を部分的にサポートします。これは特定の Amazon EC2 アクションでは満たす必要がある条件、またはユーザーが使用できる特定のリソースに基づいて、ユーザーがそれらのアクションをいつ使用できるかを制御できることを意味します。例えば、特定の AMI のみを使用して、特定のタイプのインスタンスだけを起動するアクセス許可をユーザーに付与できます。
IAM ポリシーステートメントでリソースを指定するには Amazon リソースネーム (ARN) を使用します。ARN 値の指定については[Amazon EC2 用の Amazon リソースネーム (ARN)](#EC2_ARN_Format)を参照してください。API アクションが個々の ARN をサポートしていない場合はワイルドカード (\$1) を使用して、アクションによってすべてのリソースが影響を受ける可能性があることを指定する必要があります。
リソースレベルのアクセス許可をサポートする Amazon EC2 API アクション、およびポリシーで使用できる ARN と条件キーがわかる表を見るには[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)を参照してください。
Amazon EC2 API アクションに対して使用する IAM ポリシーで、タグベースのリソースレベルアクセス許可を適用できます。これにより、ユーザーがどのリソースを作成、変更、または使用できるかを制御しやすくなります。詳細については、[Amazon EC2 リソース作成時にタグ付けするアクセス許可の付与](supported-iam-actions-tagging.md)を参照してください。
## Amazon EC2 用の Amazon リソースネーム (ARN)
各 IAM ポリシーステートメントはARN を使用して指定したリソースに適用されます。
ARN には以下の一般的な構文があります。
```
arn:aws:[service]:[region]:[account-id]:resourceType/resourcePath
```
*service*
サービス (例: `ec2`)。
*region*
リソースのリージョン (例: `us-east-1`)。
*account-id*
ハイフンなしの AWS アカウント ID (例: `123456789012`)。
*resourceType*
リソースの種類 (例: `instance`)。
*resourcePath*
リソースを識別するパス。パスにワイルドカードの \$1 が使用できます。
例えば、以下のように ARN を使用して、ステートメント内で特定のインスタンス (`i-1234567890abcdef0`) を指定することができます。
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"
```
以下のように \$1 ワイルドカードを使用して、特定のアカウントに属するすべてのインスタンスを指定できます。
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
```
また、以下のように \$1 ワイルドカードを使用して、特定のアカウントに属するすべての Amazon EC2 リソースを指定することもできます。
```
"Resource": "arn:aws:ec2:us-east-1:123456789012:*"
```
すべてのリソースを指定する場合、または特定の API アクションが ARN をサポートしていない場合は以下のように、`Resource` エレメント内で \$1 ワイルドカードを使用します。
```
"Resource": "*"
```
Amazon EC2 API アクションの多くが複数のリソースと関連します。例えば、`AttachVolume` では Amazon EBS ボリュームをインスタンスにアタッチするため、ユーザーはボリュームおよびインスタンスを使用する許可が必要です。1 つのステートメントで複数のリソースを指定するには次のように ARN をカンマで区切ります。
```
"Resource": ["arn1", "arn2"]
```
Amazon EC2 リソースの ARN のリストについては、[Amazon EC2 で定義されるリソースタイプ](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-resources-for-iam-policies)を参照してください。
## Amazon EC2 の条件キー
ポリシーステートメントではオプションで有効になるタイミングを制御する条件を指定できます。各条件には 1 つ以上のキーと値のペアが含まれます。条件キーは大文字小文字を区別しません。AWS グローバル条件キーに加え、追加のサービス固有の条件キーも定義されています。
Amazon EC2 のサービス固有の条件キーのリストについては、[Amazon EC2 の条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys)を参照してください。Amazon EC2 ではAWS グローバル条件キーも実装されています。詳細については、*IAM ユーザーガイド*の[すべてのリクエストで利用可能な情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#policy-vars-infoallreqs)を参照してください。
すべての Amazon EC2 アクションは `aws:RequestedRegion` および `ec2:Region` 条件キーをサポートします。詳細については、[例: 特定のリージョンへのアクセスの制限](ExamplePolicies_EC2.md#iam-example-region)を参照してください。
IAM ポリシーで条件キーを使用するには`Condition` ステートメントを使用します。例えば、次のポリシーはセキュリティグループのインバウンドルールとアウトバウンドルールを追加および削除するアクセス許可をユーザーに付与します。`ec2:Vpc` 条件キーを使用して、これらのアクションを実行できる対象は特定の VPC 内のセキュリティグループに限ることを指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupIngress",
"ec2:RevokeSecurityGroupEgress"],
"Resource": "arn:aws:ec2:us-east-1:111122223333:security-group/*",
"Condition": {
"StringEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-11223344556677889"
}
}
}
]
}
```
------
複数の条件、または単一の条件に複数のキーを指定する場合、論理 AND 演算を使用してそれらを評価します。1 つのキーに複数の値を使用して単一の条件を指定する場合、論理 OR 演算を使用して条件を評価します。アクセス許可が付与されるにはすべての条件を満たしている必要があります。
条件を指定する際にプレースホルダーも使用できます。詳細については、*IAM ユーザーガイド*の[IAM ポリシーエレメント: 変数およびタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)を参照してください。
**重要**
多くの条件キーはリソースに固有のものであり、一部の API アクションでは複数のリソースを使用します。条件キーを使用してポリシーを作成する場合はポリシーステートメントの `Resource` 要素で、条件キーが適用されるリソースを指定します。指定しない場合、そのポリシーはユーザーに対してすべてのアクションの実行を禁止します。これは条件キーが適用されないリソースに対して条件チェックが失敗するためです。リソースを指定しない場合や、ポリシーの `Action` 要素に複数の API アクションを含めている場合は`...IfExists` 条件タイプを使用して、条件キーが適用されないリソースに対して無視されるようにする必要があります。詳細については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Conditions_IfExists)の*..IfExists 条件*を参照してください。
**Topics**
+ [ec2:Attribute 条件キー](#attribute-key)
+ [ec2:ResourceID 条件キー](#imageId-key)
+ [ec2:SourceInstanceARN 条件キー](#SourceInstanceARN)
### ec2:Attribute 条件キー
`ec2:Attribute` 条件キーはリソースの属性によってアクセスをフィルタリングする条件に使用できます。
この条件キーはプリミティブデータ型 (文字列や整数など) のプロパティ、または **Value** プロパティのみを含む複雑な **[AttributeValue](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AttributeValue.html)** オブジェクト ([ModifyImageAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) API アクションの **Description** または **ImdsSupport** オブジェクトなど) に使用できます。条件キーは[ModifyImageAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) の **LaunchPermission** オブジェクトなど、複数のプロパティを含む複雑なオブジェクトには使用できません。
例えば、次のポリシーでは**ModifyImageAttribute**API アクションの複雑な **Description** オブジェクトによるアクセスをフィルタリングするために `ec2:Attribute/Description` 条件キーを使用します。条件キーはイメージの説明を `Production` または `Development` のいずれかに変更するリクエストのみを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:ModifyImageAttribute",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:Attribute/Description": [
"Production",
"Development"
]
}
}
}
]
}
```
------
次のポリシー例では**ModifyImageAttribute** API アクションのプリミティブな **Attribute** プロパティによるアクセスをフィルタリングするために `ec2:Attribute` 条件キーを使用します。この条件キーはイメージの説明を変更しようとするすべてのリクエストを拒否します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:ModifyImageAttribute",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:Attribute": "Description"
}
}
}
]
}
```
------
### ec2:ResourceID 条件キー
指定された API アクションで次の `ec2:ResourceID` 条件キーを使用する場合、条件キーの値はAPI アクションによって作成される結果のリソースを指定するために使用されます。`ec2:ResourceID` 条件キーを使用して、API リクエストで指定されたソース リソースを指定することはできません。指定された API で次の `ec2:ResourceID` 条件キーのいずれかを使用する場合は常にワイルドカード (`*`) を指定する必要があります。別の値を指定した場合、条件はランタイム中に常に `*` に解決されます。例えば、**CopyImage** API で `ec2:ImageId` 条件キーを使用するには次のように条件キーを指定する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CopyImage",
"Resource": "arn:aws:ec2:us-east-1::image/ami-*",
"Condition": {
"StringEquals": {
"ec2:ImageID": "*"
}
}
}
]
}
```
------
これらの API アクションではこれらの条件キーを使用しないことをお勧めします。
+ `ec2:DhcpOptionsID` – `CreateDhcpOptions`
+ `ec2:ImageID` – `CopyImage`、`CreateImage`、`ImportImage`、`RegisterImage`
+ `ec2:InstanceID` – `RunInstances` および `ImportInstance`
+ `ec2:InternetGatewayID` – `CreateInternetGateway`
+ `ec2:NetworkAclID` – `CreateNetworkAcl`
+ `ec2:NetworkInterfaceID` – `CreateNetworkInterface`
+ `ec2:PlacementGroupName` – `CreatePlacementGroup`
+ `ec2:RouteTableID` – `CreateRouteTable`
+ `ec2:SecurityGroupID` – `CreateSecurityGroup`
+ `ec2:SnapshotID` – `CopySnapshot`、`CreateSnapshot`、`CreateSnapshots`、`ImportSnapshots`
+ `ec2:SubnetID` – `CreateSubnet`
+ `ec2:VolumeID` – `CreateVolume` および `ImportVolume`
+ `ec2:VpcID` – `CreateVpc`
+ `ec2:VpcPeeringConnectionID` – `CreateVpcPeeringConnection`
特定のリソース ID に基づいてアクセスをフィルタリングするには次のように `Resource` ポリシー要素を使用することをお勧めします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CopyImage",
"Resource": "arn:aws:ec2:us-east-1::image/ami-01234567890abcdef"
}
]
}
```
------
### ec2:SourceInstanceARN 条件キー
`ec2:SourceInstanceARN` を使用して、リクエスト元のインスタンスの ARN を指定します。これは [AWS グローバル条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)であり、Amazon EC2 以外のサービスで使用できるということです。ポリシーの例については「[例: 特定のインスタンスが他の AWS サービスでリソースを表示できるようにする](ExamplePolicies_EC2.md#iam-example-source-instance)」を参照してください。
## 属性ベースのアクセスを使用するアクセスの制御
EC2 リソースを使用するための許可をユーザーに付与する IAM ポリシーを作成する場合、ポリシーの `Condition` 要素にタグ情報を含めることで、タグに基づいてアクセスをコントロールできます。これは属性ベースのアクセス制御 (ABAC) と呼ばれます。ABAC を使用すると、ユーザーが変更、使用、または削除できるリソースをより適切に制御できます。詳細については、[AWS の ABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)を参照してください。
例えば、インスタンスを終了することをユーザーに許可するが、インスタンスに `environment=production` タグが付いている場合はアクションを拒否するポリシーを作成できます。これを行うには`aws:ResourceTag` 条件キーを使用し、リソースにアタッチされているタグに基づいてリソースへのアクセスを許可または拒否します。
```
"StringEquals": { "aws:ResourceTag/environment": "production" }
```
Amazon EC2 API アクションが `aws:ResourceTag` 条件キーを使用したアクセスの制御をサポートしているかどうかについては[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)を参照してください。`Describe` アクションはリソースレベルのアクセス権限をサポートしないため、条件のない別のステートメントでそれらのアクセス権限を指定する必要があることに注意してください。
IAM ポリシーの例は[Amazon EC2 API へのアクセスを制御するポリシーの例](ExamplePolicies_EC2.md)を参照してください。
タグに基づいてリソースへのユーザーのアクセスを許可または拒否する場合はユーザーが同じリソースに対してそれらのタグを追加または削除することを明示的に拒否することを検討する必要があります。そうしないと、ユーザーはそのリソースのタグを変更することで、制限を回避してリソースにアクセスできてしまいます。
## ユーザー、グループ、およびロールに許可を付与する
アクセス権限を付与するにはユーザー、グループ、またはロールにアクセス許可を追加します。
+ AWS IAM アイデンティティセンター のユーザーとグループ:
アクセス許可セットを作成します。「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[アクセス許可セットを作成する](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html)」の手順に従ってください。
+ IAM 内で、ID プロバイダーによって管理されているユーザー:
ID フェデレーションのロールを作成します。詳細については *IAM ユーザーガイド* の [サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) を参照してください。
+ IAM ユーザー:
+ ユーザーが担当できるロールを作成します。手順については *IAM ユーザーガイド* の [IAM ユーザーのロールの作成](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) を参照してください。
+ (お奨めできない方法) ポリシーをユーザーに直接アタッチするか、ユーザーをユーザーグループに追加します。詳細については「*IAM ユーザーガイド*」の「[ユーザー (コンソール) へのアクセス権限の追加](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## ユーザーが必要なアクセス許可を持っているかどうかの確認
IAM ポリシーを作成したら、ポリシーを本稼働環境に置く前に、そのポリシーがユーザーに特定の API アクションおよび必要なリソースを使用するアクセス許可を付与しているかどうかを確認することをお勧めします。
まずテスト目的のユーザーを作成し、作成した IAM ポリシーをテストユーザーにアタッチします。次に、テストユーザーとしてリクエストを作成します。
テスト中の Amazon EC2 アクションがリソースを作成または変更する場合、`DryRun` パラメータ を使用してリクエストを作成する (または AWS CLI オプションで `--dry-run` コマンドを実行する) 必要があります。この場合、発信者は認可チェックを行いますが、操作は完了しません。例えば、実際に終了させることなく、ユーザーが特定のインスタンスを終了できるかどうかを確認できます。テストユーザーに必要なアクセス許可がある場合、リクエストで `DryRunOperation` が返されます。必要なアクセス許可がない場合は `UnauthorizedOperation` が返されます。
ポリシーが想定したアクセス許可をユーザーに付与していない場合、または過度に許可されている場合、必要に応じてポリシーを調整し、必要な結果を得るまで再テストできます。
**重要**
ポリシーの変更が反映され、有効になるには数分間かかります。したがって、ポリシーの更新をテストするには 5 分かかると見ておいてください。
認可チェックが失敗した場合、リクエストでは診断情報でエンコードされたメッセージが返されます。`DecodeAuthorizationMessage` アクションを使用してメッセージをデコードできます。詳細については、*AWS Security Token Service API * リファレンス の [DecodeAuthorizationMessage、](https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html) および コマンドリファレンスの[decode-authorization-message](https://docs.aws.amazon.com/STS/latest/APIReference/API_DecodeAuthorizationMessage.html).を参照してください。
# Amazon EC2 API へのアクセスを制御するポリシーの例
IAM ポリシーを使用して、Amazon EC2 を操作するために必要なアクセス許可をユーザーに付与することができます。詳細な手順については「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
以下の例ではAmazon EC2 を使用するアクセス許可をユーザーに付与するために使用できるポリシーステートメントを示しています。これらのポリシーはAWS CLI または AWS SDK を使用して行われたリクエスト向けに設計されています。次の例では*ユーザー入力プレースホルダー*をユーザー自身の情報で置き換えます。
**Topics**
+ [読み取り専用アクセス](#iam-example-read-only)
+ [特定のリージョンへのアクセスの制限](#iam-example-region)
+ [インスタンスの使用](#iam-example-instances)
+ [インスタンスの起動 (RunInstances)](#iam-example-runinstances)
+ [スポットインスタンス の操作](#iam-example-spot-instances)
+ [リザーブドインスタンス の操作](#iam-example-reservedinstances)
+ [リソースのタグ付け](#iam-example-taggingresources)
+ [IAM ロールの使用](#iam-example-iam-roles)
+ [ルートテーブルの使用](#iam-example-route-tables)
+ [特定のインスタンスが他の AWS サービスでリソースを表示できるようにする](#iam-example-source-instance)
+ [起動テンプレートの使用](#iam-example-launch-templates)
+ [インスタンスメタデータの使用](#iam-example-instance-metadata)
+ [Amazon EBS ボリュームとスナップショットの使用](#iam-example-ebs)
Amazon EC2 コンソールで機能するポリシーの例については、「[Amazon EC2 コンソールへのアクセスを制御するポリシーの例](iam-policies-ec2-console.md)」を参照してください。
## 例: 読み取り専用アクセス
次のポリシーでは名前が `Describe` で始まるすべての Amazon EC2 API アクションを使用できるアクセス許可をユーザーに与えます。`Resource` エレメントにワイルドカードを使用します。これはユーザーが API アクションですべてのリソースを指定できることを示します。また、API アクションがリソースレベルのアクセス許可をサポートしていない場合も、\$1 ワイルドカードが必要です。どの Amazon EC2 API アクションでどの ARN を使用できるかの詳細については、「[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)」を参照してください。
デフォルトで API アクションを使用するアクセス許可が拒否されているため、ユーザーには (別のステートメントでアクセス許可が与えられない限り) そのリソースに対してアクションを実行するアクセス許可がありません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*"
}
]
}
```
------
## 例: 特定のリージョンへのアクセスの制限
次のポリシーではリージョンが 欧州 (フランクフルト) でない限り、すべての Amazon EC2 API アクションを使用するアクセス許可をユーザーに拒否します。これにはグローバル条件キー `aws:RequestedRegion` が使用され、このキーはすべての Amazon EC2 API アクションでサポートされています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "eu-central-1"
}
}
}
]
}
```
------
または条件キー `ec2:Region` を使用することもできます。これはAmazon EC2 に固有のもので、すべての Amazon EC2 API アクションでサポートされています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"ec2:Region": "eu-central-1"
}
}
}
]
}
```
------
## インスタンスの使用
**Topics**
+ [例: すべてのインスタンスを記述、起動、停止、開始、および終了する](#iam-example-instances-all)
+ [例: すべてのインスタンスを記述し、特定のインスタンスのみを停止、開始、および終了する](#iam-example-instances-specific)
### 例: すべてのインスタンスを記述、起動、停止、開始、および終了する
次のポリシーでは`Action` エレメントで指定された API アクションを使用するアクセス許可をユーザーに与えます。`Resource` エレメントでは \$1 ワイルドカードを使用して、ユーザーが API アクションですべてのリソースを指定できることを示します。また、API アクションがリソースレベルのアクセス許可をサポートしていない場合も、\$1 ワイルドカードが必要です。どの Amazon EC2 API アクションでどの ARN を使用できるかの詳細については、「[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)」を参照してください。
ユーザーはデフォルトで API アクションを使用するアクセス許可を拒否されているため、ユーザーには (別のステートメントでユーザーにそのアクセス許可を与えない限り) その他の API アクションを使用するアクセス許可がありません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeKeyPairs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeAvailabilityZones",
"ec2:RunInstances",
"ec2:TerminateInstances",
"ec2:StopInstances",
"ec2:StartInstances"
],
"Resource": "*"
}
]
}
```
------
### 例: すべてのインスタンスを記述し、特定のインスタンスのみを停止、開始、および終了する
次のポリシーでは、ユーザーは「`purpose=test`」のリソースタグを使用してすべてのインスタンスを表示し、i-1234567890abcdef0 および i-0598c7d356eba48d7 のインスタンスのみを開始および停止し、`us-east-1` リージョンでインスタンスのみを終了できるようにします。
最初のステートメントでは`Resource` エレメントに \$1 ワイルドカードを使用して、ユーザーがそのアクションにすべてのリソースを指定できることを示しています。この場合、すべてのインスタンスをリストできます。また、API アクションがリソースレベルのアクセス許可をサポートしていない場合も、\$1 ワイルドカードが必要です (この場合は`ec2:DescribeInstances`)。どの Amazon EC2 API アクションでどの ARN を使用できるかの詳細については、「[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)」を参照してください。
2 番目のステートメントでは`StopInstances` および `StartInstances` アクションに対してリソースレベルのアクセス許可を使用しています。`Resource` エレメント内で、ARN によって特定のインスタンスが指定されています。
3 番目のステートメントでは、指定された AWS アカウントに属する `us-east-1` リージョン内のすべてのインスタンスを終了する許可がユーザーに与えられます。ただし、インスタンスに `"purpose=test"` タグがある場合にのみ該当します。`Condition` エレメントはポリシーステートメントの発効条件を指定します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeInstances",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StopInstances",
"ec2:StartInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890abcdef0",
"arn:aws:ec2:us-east-1:111122223333:instance/i-0598c7d356eba48d7"
]
},
{
"Effect": "Allow",
"Action": "ec2:TerminateInstances",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/purpose": "test"
}
}
}
]
}
```
------
## インスタンスの起動 (RunInstances)
[RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) API アクションは1 つ以上の オンデマンドインスタンス または 1 つ以上の スポットインスタンス を起動します。`RunInstances` は AMI を必要とし、インスタンスを作成します。ユーザーはリクエストでキーペアとセキュリティグループを指定できます。VPC 内に起動するにはサブネットが必要であり、起動されるとネットワークインターフェイスが作成されます。Amazon EBS-backed AMI から起動すると、ボリュームが作成されます。そのため、ユーザーにはこれらの Amazon EC2 リソースを使用するアクセス許可が必要です。ユーザーが `RunInstances` に対してオプションのパラメータを指定する必要がある、またはユーザーからパラメータの特定の値を制限するポリシーステートメントを作成できます。
インスタンスの起動に必要なリソースレベルのアクセス許可の詳細については、「[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)」を参照してください。
デフォルトでは作成したインスタンスを記述、開始、停止、または終了するアクセス許可はユーザーに付与されていません。作成したインスタンスを管理するアクセス許可をユーザーに付与する 1 つの方法としてはインスタンスごとに特定のタグを作成し、そのタグでインスタンスを管理できるようにステートメントを作成します。詳細については[インスタンスの使用](#iam-example-instances)を参照してください。
**Topics**
+ [AMI](#iam-example-runinstances-ami)
+ [インスタンスタイプ](#iam-example-runinstances-instance-type)
+ [サブネット](#iam-example-runinstances-subnet)
+ [EBS ボリューム](#iam-example-runinstances-volumes)
+ [タグ](#iam-example-runinstances-tags)
+ [起動テンプレートのタグ](#iam-example-tags-launch-template)
+ [Elastic GPU](#iam-example-runinstances-egpu)
+ [起動テンプレート](#iam-example-runinstances-launch-templates)
### AMI
次のポリシーでは指定された AMI (`ami-9e1670f7` および `ami-45cf5c3c`) のみを使用してインスタンスを起動できます。(別のステートメントでユーザーに起動するアクセス許可が付与されない限り) ユーザーはその他の AMI を使用してインスタンスを起動することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-9e1670f7",
"arn:aws:ec2:us-east-1::image/ami-45cf5c3c",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*"
]
}
]
}
```
------
または次のポリシーを使用すると、ユーザーは Amazon、または特定の信頼できる検証済みのパートナーが所有するすべての AMI からインスタンスを起動できます。最初のステートメントの `Condition` エレメントは`ec2:Owner` が `amazon` であるかどうかをテストします。(別のステートメントでユーザーに起動するアクセス許可が付与されない限り) ユーザーはその他の AMI を使用してインスタンスを起動することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
### インスタンスタイプ
次のポリシーにより、ユーザーは `t2.micro` または `t2.small` インスタンスタイプのみを使用してインスタンスを起動できます。これにより、コストを管理することができます。最初のステートメントの `Condition` エレメントは `ec2:InstanceType` が `t2.micro` または `t2.small` のどちらであるかをテストするため、ユーザーは大きなインスタンスを起動することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:InstanceType": ["t2.micro", "t2.small"]
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
また、ユーザーが `t2.micro` と `t2.small` のインスタンスタイプ以外のすべてのインスタンス起動へのアクセスを拒否するポリシーを作成することもできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringNotEquals": {
"ec2:InstanceType": ["t2.micro", "t2.small"]
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
### サブネット
次のポリシーにより、ユーザーは指定したサブネット `subnet-12345678` のみを使用してインスタンスを起動できます。グループはインスタンスを他のサブネットに起動することはできません (他のステートメントがそのような許可をユーザーに与えている場合はその限りではありません)。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:subnet/subnet-12345678",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
また、ユーザーがその他のサブネットにインスタンスを起動するアクセス許可を拒否するポリシーを作成することもできます。ステートメントではサブネット `subnet-12345678` が指定されている場合以外はネットワークインターフェイスの作成を拒否することでこれを実行します。この拒否は他のサブネットへのインスタンスの起動を許可する他のすべてのポリシーよりも優先されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:network-interface/*"
],
"Condition": {
"ArnNotEquals": {
"ec2:Subnet": "arn:aws:ec2:us-east-1:111122223333:subnet/subnet-12345678"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-1::image/ami-*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*"
]
}
]
}
```
------
### EBS ボリューム
次のポリシーではインスタンスの EBS ボリュームが暗号化されている場合のみユーザーがインスタンスを起動できます。ユーザーはルートボリュームが暗号化されるように、暗号化されたスナップショットを使用して作成された AMI からインスタンスを起動する必要があります。ユーザーが起動時にインスタンスにアタッチする追加ボリュームも暗号化されている必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*:*:volume/*"
],
"Condition": {
"Bool": {
"ec2:Encrypted": "true"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:*:network-interface/*",
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ec2:*:*:subnet/*",
"arn:aws:ec2:*:*:key-pair/*",
"arn:aws:ec2:*:*:security-group/*"
]
}
]
}
```
------
### タグ
**インスタンスの作成時にタグを付ける**
次のポリシーではユーザーがインスタンスを起動し、作成時にインスタンスにタグ付けすることができます。タグを適用するリソース作成アクションにはユーザーが `CreateTags` アクションを使用するアクセス権限を持っていることが必要です。2 番目のステートメントは`ec2:CreateAction` 条件キーを使用し、ユーザーが `RunInstances` のコンテキストでのみ、インスタンスに対してのみタグを作成できるようにします。ユーザーは既存のリソースにタグ付けすることができず、`RunInstances` リクエストを使用してボリュームにタグ付けすることもできません。
詳細については[Amazon EC2 リソース作成時にタグ付けするアクセス許可の付与](supported-iam-actions-tagging.md)を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
**インスタンスやボリュームの作成時に特定のタグを付ける**
次のポリシーには`aws:RequestTag` および `RunInstances` タグを使用して `environment=production` により作成されたすべてのインスタンスおよびボリュームへのタグ付けをユーザーに求める `purpose=webserver` 条件キーが含まれています。ユーザーがこれらのタグを渡さないか、タグをまったく指定しない場合、リクエストは失敗します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production" ,
"aws:RequestTag/purpose": "webserver"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
**インスタンスやボリュームの作成時に特定のタグを少なくとも 1 つ付ける**
次のポリシーは`ForAnyValue` 条件で `aws:TagKeys` 修飾子を使用して、リクエストで少なくとも 1 つのタグが指定されている必要があり、キー `environment` または `webserver` が含まれている必要があることを示します。タグはインスタンスとボリュームの両方に適用される必要があります。リクエストでは任意のタグ値を指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*",
"arn:aws:ec2:us-east-1:111122223333:security-group/*",
"arn:aws:ec2:us-east-1:111122223333:key-pair/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:volume/*",
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": ["environment","webserver"]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
**インスタンスの作成時にタグを付ける場合は特定のタグを使用してタグ付けする必要がある**
次のポリシーではユーザーはリクエストでタグを指定する必要はありませんが、指定する場合は `purpose=test` タグを指定する必要があります。他のタグは許可されません。ユーザーは`RunInstances` リクエストでタグ付け可能なリソースにタグを適用できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/purpose": "test",
"ec2:CreateAction" : "RunInstances"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": "purpose"
}
}
}
]
}
```
------
RunInstances の呼び出しで作成時のタグ付けをユーザーを禁止するには
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Effect": "Deny",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
spot-instances-request の特定のタグのみを許可します。ここで矛盾数 2 が意外な効果を発揮します。通常の状況ではタグを指定しないと非認証になります。spot-instances-request の場合、spot-instances-request タグがないと、このポリシーは評価されないため、タグなしの Spot on Run リクエストが成功します。
### 起動テンプレートのタグ
次の例で、ユーザーはインスタンスを起動できますが、特定の起動テンプレートを使用する場合に限ります (`lt-09477bcd97b0d310e`)。`ec2:IsLaunchTemplateResource` 条件キーはユーザーが起動テンプレートで指定されたリソースを上書きしないようにします。ステートメントの 2 番目の部分ではユーザーは作成時にインスタンスにタグ付けできます — ステートメントのこの部分は起動テンプレートでタグがインスタンスに対して指定されている場合に必要になります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/lt-09477bcd97b0d310e"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction" : "RunInstances"
}
}
}
]
}
```
------
### Elastic GPU
次のポリシーではユーザーはインスタンスを起動させ、インスタンスにアタッチする Elastic GPU を指定できます。ユーザーは任意のリージョンでインスタンスを起動できますが、Elastic GPU をアタッチできるのはその `us-east-2` リージョンでの起動中に限られます。
`ec2:ElasticGpuType`条件キーは`eg1.medium``eg1.large`インスタンスがまたはエラスティック GPU タイプのいずれかを使用することを保証します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:*:111122223333:elastic-gpu/*"
],
"Condition": {
"StringEquals": {
"ec2:Region": "us-east-2",
"ec2:ElasticGpuType": [
"eg1.medium",
"eg1.large"
]
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:*::image/ami-*",
"arn:aws:ec2:*:111122223333:network-interface/*",
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ec2:*:111122223333:subnet/*",
"arn:aws:ec2:*:111122223333:volume/*",
"arn:aws:ec2:*:111122223333:key-pair/*",
"arn:aws:ec2:*:111122223333:security-group/*"
]
}
]
}
```
------
### 起動テンプレート
次の例で、ユーザーはインスタンスを起動できますが、特定の起動テンプレートを使用する場合に限ります (`lt-09477bcd97b0d310e`)。ユーザーは`RunInstances` アクションでパラメータを指定することで、起動テンプレートのパラメータを上書きできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/lt-09477bcd97b0d310e"
}
}
}
]
}
```
------
この例で、ユーザーは起動テンプレートを使用する場合に限りインスタンスを起動できます。ポリシーでは `ec2:IsLaunchTemplateResource` 条件キーを使用して、ユーザーが起動テンプレート内の既存の ARN を上書きできないようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
}
]
}
```
------
次のサンプルポリシーによりユーザーはインスタンスを起動できますが、起動テンプレートを使用する場合に限ります。ユーザーはリクエストでサブネットおよびネットワークインターフェイスのパラメータを上書きすることはできません。これらのパラメータは起動テンプレートでのみ指定できます。ステートメントの最初の部分は[NotResource](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notresource.html) 要素を使用して、サブネットやネットワークインターフェイスを除くその他のすべてのリソースを許可します。ステートメントの 2 番目の部分はサブネットおよびネットワークインターフェイスのリソースを許可しますが、これは起動テンプレートから取得された場合に限ります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"NotResource": ["arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*" ],
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": ["arn:aws:ec2:us-east-1:111122223333:subnet/*",
"arn:aws:ec2:us-east-1:111122223333:network-interface/*" ],
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
}
]
}
```
------
次の例では起動テンプレートを使用していて、また起動テンプレートにタグがある場合に限り、ユーザーはインスタンスを起動できるようになります `Purpose=Webservers`。ユーザーは`RunInstances` アクションで起動テンプレートパラメータを上書きすることはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"NotResource": "arn:aws:ec2:us-east-1:111122223333:launch-template/*",
"Condition": {
"ArnLike": {
"ec2:LaunchTemplate": "arn:aws:ec2:us-east-1:111122223333:launch-template/*"
},
"Bool": {
"ec2:IsLaunchTemplateResource": "true"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:111122223333:launch-template/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Purpose": "Webservers"
}
}
}
]
}
```
------
## スポットインスタンス の操作
RunInstances アクションを使用してスポットインスタンスリクエストを作成し、作成時にスポットインスタンスリクエストにタグ付けできます。RunInstances に指定するリソースは `spot-instances-request` です。
`spot-instances-request` リソースはIAM ポリシーで次のように評価されます。
+ スポットインスタンスリクエストの作成時にタグを付けない場合、Amazon EC2 は RunInstances ステートメント内の `spot-instances-request` リソースを評価しません。
+ スポットインスタンスリクエストの作成時にタグを付けると、 RunInstances ステートメント内の `spot-instances-request` リソースが、Amazon EC2 により評価されます。
したがって、`spot-instances-request` リソースの場合、次のルールが IAM ポリシーに適用されます。
+ RunInstances を使用してスポットインスタンスリクエストを作成し、その際リクエストにタグを付けない場合は`spot-instances-request` リソースを明示的に許可しなくても、その呼び出しは成功します。
+ RunInstances を使用してスポットインスタンスリクエストを作成する際に、そのリクエストにタグを付ける場合にはRunInstances の許可ステートメントに `spot-instances-request` リソースを含める必要があります。これがない場合は呼び出しが失敗します。
+ RunInstances を使用してスポットインスタンスリクエストを作成し、作成時にタグを付ける場合はCreateTags 許可ステートメントに `spot-instances-request` リソースまたは `*` ワイルドカードを指定する必要があります。指定しないと、呼び出しは失敗します。
スポットインスタンス はRunInstances または RequestSpotInstances を使用してリクエストできます。次の例の IAM ポリシーはRunInstances を使用して スポットインスタンス をリクエストする場合にのみ適用されます。
**例: RunInstances を使用して スポットインスタンス をリクエストする**
次のポリシーではRunInstances アクションを使用して スポットインスタンス をリクエストすることをユーザーに許可します。`spot-instances-request` リソースはRunInstances によって作成されます。このリソースは スポットインスタンス をリクエストします。
**注記**
RunInstances を使用してスポットインスタンスリクエストを作成し、作成時にタグを付けない場合は`spot-instances-request` リストから `Resource` を省略できます。これはスポットインスタンスリクエストの作成時にタグを付けない場合、Amazon EC2 は RunInstances ステートメント内の `spot-instances-request` リソースを評価しないためです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
}
]
}
```
------
**警告**
**サポート対象外 – 例: RunInstances を使用して スポットインスタンス をリクエストするためのアクセス許可をユーザーに拒否する**
次のポリシーは`spot-instances-request`リソースではサポートされません。
次のポリシーではユーザーに オンデマンドインスタンス を起動するためのアクセス許可を付与しますが、スポットインスタンス をリクエストするためのアクセス許可を拒否します。`spot-instances-request` リソースはRunInstances によって作成されます。このリソースは スポットインスタンス をリクエストします。2 番目のステートメントでは`spot-instances-request` リソースに対する RunInstances アクションを拒否します。ただし、スポットインスタンスリクエストの作成時にタグを付けない場合、Amazon EC2 が RunInstances ステートメントの `spot-instances-request` リソースを評価しないため、この条件はサポートされません。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*"
]
},
{
"Sid": "DenySpotInstancesRequestsNOTSUPPORTEDDONOTUSE",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:*:spot-instances-request/*"
}
]
}
```
**例: スポットインスタンスリクエストの作成時にタグを付ける**
次のポリシーではインスタンスの起動時に作成されるすべてのリソースにタグを付けることをユーザーに許可します。最初のステートメントでは一覧表示されたリソースの作成を RunInstances に許可します。`spot-instances-request` リソースはRunInstances によって作成されます。このリソースは スポットインスタンス をリクエストします。2 番目のステートメントでは`*` ワイルドカードを指定し、インスタンスの起動時に作成されるすべてのリソースのタグ付けを許可します。
**注記**
スポットインスタンスリクエストの作成時にタグを付けると、 RunInstances ステートメント内の `spot-instances-request` リソースが、Amazon EC2 により評価されます。したがって、RunInstances アクションで `spot-instances-request` リソースを明示的に許可する必要があります。許可しないと、呼び出しは失敗します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Sid": "TagResources",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
**例: スポットインスタンスリクエストの作成時にタグ付けを拒否する**
次のポリシーではインスタンスの起動時に作成されるリソースにタグを付けるためのアクセス許可をユーザーに拒否します。
最初のステートメントでは一覧表示されたリソースの作成を RunInstances に許可します。`spot-instances-request` リソースはRunInstances によって作成されます。このリソースは スポットインスタンス をリクエストします。2 番目のステートメントでは`*` ワイルドカードを指定し、インスタンスの起動時に作成されるすべてのリソースのタグ付けを拒否します。`spot-instances-request` リソースまたは他のリソースの作成時にタグを付けた場合、RunInstances の呼び出しは失敗します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Sid": "DenyTagResources",
"Effect": "Deny",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
**警告**
**サポート対象外 - 例: スポットインスタンスリクエストに特定のタグを割り当てる場合にのみ、リクエストの作成を許可する**
次のポリシーは`spot-instances-request` リソースではサポートされません。
次のポリシーはスポットインスタンスリクエストに特定のタグを付ける場合にのみ、リクエストを作成するためのアクセス許可を RunInstances に付与することを想定しています。
最初のステートメントでは一覧表示されたリソースの作成を RunInstances に許可します。
2 番目のステートメントではスポットインスタンスリクエストにタグ `environment=production` が付いている場合にのみ、リクエストを作成するためのアクセス許可をユーザーに付与することを想定しています。この条件を RunInstances によって作成された他のリソースに適用する場合、タグを指定しないと、`Unauthenticated` エラーが発生します。ただし、スポットインスタンスリクエストにタグを指定しない場合、Amazon EC2 は RunInstances ステートメントの `spot-instances-request` リソースを評価しないため、RunInstances がタグなしのスポットインスタンスリクエストを作成します。
`environment=production` 以外の別のタグを指定すると、`Unauthenticated` エラーが発生することに注意してください。これはユーザーがスポットインスタンスリクエストにタグを付けると、Amazon EC2 が RunInstances ステートメントの `spot-instances-request` リソースを評価するためです。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*"
]
},
{
"Sid": "RequestSpotInstancesOnlyIfTagIsEnvironmentProductionNOTSUPPORTEDDONOTUSE",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:*:spot-instances-request/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production"
}
}
},
{
"Sid": "TagResources",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
**例: スポットインスタンスリクエストに特定のタグが割り当てられている場合、このリクエストの作成を拒否する**
次のポリシーはスポットインスタンスリクエストにタグ `environment=production` が付いている場合、このリクエストを作成するためのアクセス許可を RunInstances に拒否します。
最初のステートメントでは一覧表示されたリソースの作成を RunInstances に許可します。
2 番目のステートメントではスポットインスタンスリクエストにタグ `environment=production` が付いている場合、このリクエストを作成するためのアクセス許可をユーザーに拒否します。`environment=production` をタグとして指定すると、`Unauthenticated` エラーが発生します。他のタグを指定するか、タグを指定しないと、スポットインスタンスリクエストが作成されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRun",
"Effect": "Allow",
"Action": [
"ec2:RunInstances"
],
"Resource": [
"arn:aws:ec2:us-east-1::image/*",
"arn:aws:ec2:us-east-1:*:subnet/*",
"arn:aws:ec2:us-east-1:*:network-interface/*",
"arn:aws:ec2:us-east-1:*:security-group/*",
"arn:aws:ec2:us-east-1:*:key-pair/*",
"arn:aws:ec2:us-east-1:*:volume/*",
"arn:aws:ec2:us-east-1:*:instance/*",
"arn:aws:ec2:us-east-1:*:spot-instances-request/*"
]
},
{
"Sid": "DenySpotInstancesRequests",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:us-east-1:*:spot-instances-request/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production"
}
}
},
{
"Sid": "TagResources",
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "*"
}
]
}
```
------
## 例: リザーブドインスタンス の操作
次のポリシーではアカウントで リザーブドインスタンス を表示、変更、購入するアクセス許可をユーザーに与えます。
個別の リザーブドインスタンス にリソースレベルのアクセス許可を設定することはできません。このポリシーはユーザーがアカウントのすべての リザーブドインスタンス にアクセスできることを意味します。
`Resource` 要素は \$1 ワイルドカードを使用して、ユーザーがそのアクションにすべてのリソースを指定できることを示しています。この場合、アカウントのすべての リザーブドインスタンス をリストして変更できます。ユーザーはアカウント認証情報を使用して リザーブドインスタンス を購入することもできます。また、API アクションがリソースレベルのアクセス許可をサポートしていない場合も、\$1 ワイルドカードが必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances",
"ec2:ModifyReservedInstances",
"ec2:PurchaseReservedInstancesOffering",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeReservedInstancesOfferings"
],
"Resource": "*"
}
]
}
```
------
次のコードではアカウント内の リザーブドインスタンス を表示および変更できるようにユーザーに許可しています。新しい リザーブドインスタンス の購入は許可していません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances",
"ec2:ModifyReservedInstances",
"ec2:DescribeAvailabilityZones"
],
"Resource": "*"
}
]
}
```
------
## 例: リソースのタグ付け
次のポリシーではタグにキー `CreateTags` および値 `environment` が含まれている場合のみ、ユーザーが `production` アクションを使用してインスタンスにタグを適用できます。他のタグは許可されず、ユーザーは他のリソースタイプをタグ付けすることはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "production"
}
}
}
]
}
```
------
次のポリシーではユーザーは `owner` のキーとユーザー名の値を使用したタグが既に適用されているタグ付け可能なリソースにタグ付けできます。加えて、ユーザーはリクエストで `anycompany:environment-type` のキーと値 `test` または `prod` を持つタグを指定する必要があります。ユーザーはリクエストで追加のタグを指定できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/anycompany:environment-type": ["test","prod"],
"aws:ResourceTag/owner": "${aws:username}"
}
}
}
]
}
```
------
ユーザーがリソースの特定のタグを指定できるようにする IAM ポリシーを作成できます。例えば、次のポリシーではリクエストで指定されたタグキーが `environment` または `cost-center` の場合、ユーザーがボリュームのタグを削除できます。タグにはどの値でも指定できますが、指定されたキーのいずれかにタグキーが一致する必要があります。
**注記**
リソースを削除すると、リソースに関連付けられているすべてのタグも削除されます。タグ付きのリソースを削除する場合、ユーザーは `ec2:DeleteTags` アクションを使用するためのアクセス許可は必要ありません。削除アクションを実行するためのアクセス許可のみが必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:volume/*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment","cost-center"]
}
}
}
]
}
```
------
このポリシーではリソースが `owner` のキーとユーザー名の値で既にタグ付けされている場合のみ、ユーザーが任意のリソースで `environment=prod` タグのみ削除できます。ユーザーはリソースの他のタグを削除することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DeleteTags"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:*/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": "prod",
"aws:ResourceTag/owner": "${aws:username}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment"]
}
}
}
]
}
```
------
## 例: IAM ロールの使用
次のポリシーでは`department=test` タグを持つインスタンス対して IAM ロールのアタッチ、置換、デタッチを行うことをユーザーに許可します。IAM ロールの置換またはデタッチには関連 ID が必要であるため、ポリシーでは `ec2:DescribeIamInstanceProfileAssociations` アクションを使用するアクセス許可もユーザーに付与します。
ユーザーはロールをインスタンスに渡すために `iam:PassRole` アクションを使用するための許可が必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation",
"ec2:DisassociateIamInstanceProfile"
],
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/department":"test"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:DescribeIamInstanceProfileAssociations",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/DevTeam*"
}
]
}
```
------
次のポリシーではどのインスタンスに対しても IAM ロールのアタッチまたは置換を行うことをユーザーに許可します。ユーザーは`TestRole-` で始まる名前の IAM ロールのみアタッチまたは置換できます。`iam:PassRole` アクションではインスタンスプロファイルではなく IAM ロールの名前を指定します (両方の名前が異なる場合)。詳細については[インスタンスプロファイル](iam-roles-for-amazon-ec2.md#ec2-instance-profile)を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DescribeIamInstanceProfileAssociations",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/TestRole-*"
}
]
}
```
------
## 例: ルートテーブルの使用
次のポリシーではVPC (`vpc-ec43eb89`) のみに関連付けられているルートテーブルのルートの追加、削除、置換を行うことができます。`ec2:Vpc` 条件キーの VPC を指定するにはVPC の完全な ARN を指定する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DeleteRoute",
"ec2:CreateRoute",
"ec2:ReplaceRoute"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:route-table/*"
],
"Condition": {
"StringEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-1:111122223333:vpc/vpc-ec43eb89"
}
}
}
]
}
```
------
## 例: 特定のインスタンスが他の AWS サービスでリソースを表示できるようにする
次に示すのはIAM ロールにアタッチできるポリシーの例です。ポリシーにより、インスタンスは AWS サービスのさまざまなリソースを表示できるようになります。このポリシーではグローバル条件キー `ec2:SourceInstanceARN` を使用して、リクエスト元のインスタンスがインスタンス `i-093452212644b0dd6` である必要があることを指定します。同じ IAM ロールが別のインスタンスと関連付けられている場合、他のインスタンスはこれらのどのアクションも実行できません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVolumes",
"s3:ListAllMyBuckets",
"dynamodb:ListTables",
"rds:DescribeDBInstances"
],
"Resource": [
"*"
],
"Condition": {
"ArnEquals": {
"ec2:SourceInstanceARN": "arn:aws:ec2:us-east-1:111122223333:instance/i-093452212644b0dd6"
}
}
}
]
}
```
------
## 例: 起動テンプレートの使用
次のポリシーではユーザーは起動テンプレートのバージョンを作成して起動テンプレートを変更することができます。ただし、特定の起動テンプレートに限られます (`lt-09477bcd97b0d3abc`)。ユーザーは他の起動テンプレートを使用することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:CreateLaunchTemplateVersion",
"ec2:ModifyLaunchTemplate"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:us-east-1:111122223333:launch-template/lt-09477bcd97b0d3abc"
}
]
}
```
------
次のポリシーではユーザーは任意の起動テンプレートと起動テンプレートのバージョンを削除できます。ただし、起動テンプレートに `Purpose`=`Testing` のタグがある場合に限ります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DeleteLaunchTemplate",
"ec2:DeleteLaunchTemplateVersions"
],
"Effect": "Allow",
"Resource": "arn:aws:ec2:us-east-1:111122223333:launch-template/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Purpose": "Testing"
}
}
}
]
}
```
------
## インスタンスメタデータの使用
以下のポリシーではインスタンスメタデータサービスバージョン 2 (IMDSv2) を使用して、ユーザーが[インスタンスメタデータ](ec2-instance-metadata.md)のみを取得できるようにします。以下の 4 つのポリシーは4 つのステートメントを使用する 1 つのポリシーに結合できます。1 つのポリシーとして結合すると、このポリシーをサービスコントロールポリシー (SCP) として使用できます。これは既存の IAM ポリシーに適用する*拒否*ポリシーとして (既存のアクセス許可を削除して制限するために) 使用したり、アカウント、組織単位 (OU)、組織全体にグローバルに適用する SCP として使用したりすることもできます。
**注記**
以下の RunInstances メタデータオプションポリシーはRunInstances を使用してインスタンスを起動するアクセス許可をプリンシパルに付与するポリシーと組み合わせて使用する必要があります。プリンシパルに RunInstances アクセス許可もない場合、インスタンスを起動することはできません。詳細については[インスタンスの使用](#iam-example-instances)と[インスタンスの起動 (RunInstances)](#iam-example-runinstances)のポリシーを参照してください。
**重要**
Auto Scaling グループを使用し、すべての新しいインスタンスで IMDSv2 の使用を要求する必要がある場合は、Auto Scaling グループで*起動テンプレート*を使用する必要があります。
Auto Scaling グループが起動テンプレートを使用する場合、新しい Auto Scaling グループが作成されるときに IAM プリンシパルの `ec2:RunInstances` アクセス許可がチェックされます。また、既存の Auto Scaling グループが更新され、新しい起動テンプレートまたは新しいバージョンの起動テンプレートが使用される場合にもチェックされます。
`RunInstances` の IAM プリンシパルでの IMDSv1 の使用に関する制限は起動テンプレートを使用している Auto Scaling グループが作成または更新された場合にのみチェックされます。`Latest` または `Default` 起動テンプレートを使用するように設定された Auto Scaling グループでは起動テンプレートの新しいバージョンが作成されたときにアクセス許可はチェックされません。アクセス許可をチェックするには*特定のバージョン*の起動テンプレートを使用するように Auto Scaling グループを設定する必要があります。
作成された新しいプリンシパルのサービスコントロールポリシー (SCP) または IAM アクセス許可の境界を使用して、組織内のすべてのアカウントの起動設定の使用を無効にします。Auto Scaling グループアクセス許可を持つ既存の IAM プリンシパルの場合、関連するポリシーをこの条件キーで更新します。起動設定の使用を無効にするには値が `"autoscaling:LaunchConfigurationName"` として指定された `null` 条件キーを使用して、関連する SCP、アクセス許可の境界、または IAM ポリシーを作成または変更します。
新しい起動テンプレートの場合は起動テンプレートでインスタンスメタデータオプションを設定します。既存の起動テンプレートの場合は新しいバージョンの起動テンプレートを作成し、新しいバージョンでインスタンスメタデータオプションを設定します。
起動テンプレートを使用するアクセス許可を任意のプリンシパルに付与するポリシーで、`$latest` を指定して `$default` と `"autoscaling:LaunchTemplateVersionSpecified": "true"` の関連付けを制限します。使用を特定のバージョンの起動テンプレートに制限することで、インスタンスメタデータオプションが設定されているバージョンを使用して新しいインスタンスを確実に起動できます。詳細については*Amazon EC2 Auto Scaling API リファレンス* (具体的には `Version` パラメータ) の「[LaunchTemplateSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_LaunchTemplateSpecification.html)」を参照してください。
起動設定を使用する Auto Scaling グループの場合、起動設定を起動テンプレートに置き換えます。詳細については「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Create a launch template for an Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/migrate-to-launch-templates.html)」を参照してください。
起動テンプレートを使用する Auto Scaling グループの場合、インスタンスメタデータオプションが設定された新しい起動テンプレートを使用するか、インスタンスメタデータオプションが設定された現在の起動テンプレートの新しいバージョンを使用します。詳細については、「[update-auto-scaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html)」を参照してください。
**Topics**
+ [IMDSv2 の使用を要求する](#iam-example-instance-metadata-requireIMDSv2)
+ [IMDSv2 のオプトアウトを拒否する](#iam-example-instance-metadata-denyoptoutIMDSv2)
+ [ホップ制限の最大値の指定](#iam-example-instance-metadata-maxHopLimit)
+ [インスタンスメタデータオプションを変更できるユーザーの制限](#iam-example-instance-metadata-limit-modify-IMDS-options)
+ [IMDSv2 からロール認証情報を取得することを要求する](#iam-example-instance-metadata-require-roles-to-use-IMDSv2-credentials)
### IMDSv2 の使用を要求する
次のポリシーではインスタンスが IMDSv2 の使用を要求するようにオプトインされていない限り(`"ec2:MetadataHttpTokens": "required"` で指定)、RunInstances API を呼び出せないように指定します。インスタンスが IMDSv2 を要求するように指定しないと、RunInstances API を呼び出したときに `UnauthorizedOperation` エラーが発生します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireImdsV2",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:MetadataHttpTokens": "required"
}
}
}
]
}
```
------
### IMDSv2 のオプトアウトを拒否する
次のポリシーでは`ModifyInstanceMetadataOptions` API を呼び出さないように指定し、IMDSv1 または IMDSv2 のオプションを許可します。`ModifyInstanceMetadataOptions` API を呼び出す場合は`HttpTokens` 属性を `required` に設定する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyIMDSv1HttpTokensModification",
"Effect": "Deny",
"Action": "ec2:ModifyInstanceMetadataOptions",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:Attribute/HttpTokens": "required"
},
"Null": {
"ec2:Attribute/HttpTokens": false
}
}
}]
}
```
------
### ホップ制限の最大値の指定
次のポリシーではホップ制限を指定しない限り、RunInstances API を呼び出せないように指定します。また、ホップ制限を 3 以下にするように指定します。これを指定しないと、RunInstances API を呼び出したときに `UnauthorizedOperation` エラーが発生します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MaxImdsHopLimit",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"NumericGreaterThan": {
"ec2:MetadataHttpPutResponseHopLimit": "3"
}
}
}
]
}
```
------
### インスタンスメタデータオプションを変更できるユーザーの制限
次のポリシーでは一般の管理者がインスタンスメタデータオプションを変更するロール `ec2-imds-admins` を持つユーザーのみに変更を行うことを許可します。`ec2-imds-admins` ロール以外のプリンシパルが ModifyInstanceMetadataOptions API を呼び出そうとすると、`UnauthorizedOperation` エラーが発生します。このステートメントはModifyInstanceMetadataOptions API の使用を制御するために使用できます。現在、ModifyInstanceMetadataOptions API 用の詳細なアクセスコントロール (条件) はありません。
### IMDSv2 からロール認証情報を取得することを要求する
次のポリシーではこのポリシーを適用したロールを EC2 サービスが引き受けて、結果の認証情報をリクエストの署名に使用する場合はIMDSv2 から取得した EC2 ロールの認証情報を使用してリクエストに署名する必要があることを指定します。それ以外の場合はすべての API コールで `UnauthorizedOperation` エラーが発生します。このステートメント/ポリシーはリクエストが EC2 ロールの認証情報によって署名されていない場合は効果がないため、一般的に適用できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireAllEc2RolesToUseV2",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NumericLessThan": {
"ec2:RoleDelivery": "2.0"
}
}
}
]
}
```
------
## Amazon EBS ボリュームとスナップショットの使用
Amazon EBS ボリュームとスナップショットを使用するポリシーの例については「[Amazon EBS のアイデンティティベースのポリシー例](https://docs.aws.amazon.com/ebs/latest/userguide/security_iam_id-based-policy-examples.html)」を参照してください。
# Amazon EC2 コンソールへのアクセスを制御するポリシーの例
IAM ポリシーを使用して、Amazon EC2 を操作するために必要なアクセス許可をユーザーに付与することができます。詳細な手順については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
コンソールではこの機能を実行するために追加の API アクションを使用するので、これらのポリシーは正常に動作しない可能性があります。例えば、`DescribeVolumes` API アクションのみを使用するアクセス許可を持つユーザーがコンソールでボリュームを表示しようとすると、エラーが発生します。このセクションでは、コンソールの特定の部分をユーザーが操作できるようになるポリシーを説明します。Amazon EC2 向けのポリシー作成の詳細については、以下の AWS セキュリティブログの投稿[Granting Users Permission to Work in the Amazon EC2 Console](https://aws.amazon.com/blogs/security/granting-users-permission-to-work-in-the-amazon-ec2-console/)を参照してください。
以下の例では、Amazon EC2 を使用するアクセス許可をユーザーに付与するために使用できるポリシーステートメントを示しています。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。これらのポリシーは、AWS マネジメントコンソールを使用して行われたリクエスト向けに設計されています。Amazon EC2 コンソールは複数の API アクションを呼び出して 1 つのリソースを表示する場合があり、ユーザーがタスクを試行してコンソールにエラーが表示されるまではそれが明確でない場合があります。詳細については、AWS セキュリティブログの投稿「[Granting Users Permission to Work in the Amazon EC2 Console](https://aws.amazon.com/blogs/security/granting-users-permission-to-work-in-the-amazon-ec2-console/)」を参照してください。
**Topics**
+ [読み取り専用アクセス](#ex-read-only)
+ [EC2 インスタンス起動ウィザードの使用](#ex-launch-wizard)
+ [セキュリティグループの操作](#ex-security-groups)
+ [Elastic IP アドレスの操作](#ex-eip)
+ [リザーブドインスタンス の操作](#ex-reservedinstances)
コンソールでタスクを実行するために必要な API アクションを探すには、呼び出しをログに記録する AWS CloudTrail などのサービスを使用できます。ポリシーにより特定のリソースを作成または変更するアクセス許可が付与されない場合、コンソールではエンコードされた診断情報のメッセージが表示されます。[ の DecodeAuthorizationMessage](https://docs.aws.amazon.com/STS/latest/APIReference/API_DecodeAuthorizationMessage.html) API アクションAWS STS、または AWS CLI の [decode-authorization-message](https://docs.aws.amazon.com/cli/latest/reference/sts/decode-authorization-message.html) コマンドを使用してメッセージをデコードできます。
## 例: 読み取り専用アクセス
ユーザーが Amazon EC2 コンソールですべてのリソースを表示できるようにするには、次の例と同じポリシーを使用します: [例: 読み取り専用アクセス](ExamplePolicies_EC2.md#iam-example-read-only)。別のステートメントによりユーザーにアクセス許可が与えられない限り、ユーザーはリソースのアクションを実行したり新しいリソースを作成することができません。
**インスタンス、AMI、スナップショットを表示する**
代わりに、リソースのサブセットへの読み取り専用アクセスを提供できます。これを行うには、`ec2:Describe` API アクションの \$1 (ワイルドカード) を各リソースの固有の `ec2:Describe` アクションに置き換えます。次のポリシーによりユーザーは Amazon EC2 コンソールですべてのインスタンス、AMI、およびスナップショットを表示できます。`ec2:DescribeTags` アクションにより、ユーザーはパブリック AMI を表示できます。コンソールでタグ付け情報にパブリック AMI を表示させる必要がありますが、ユーザーがプライベート AMI だけを表示できるようにするには、このアクションを削除できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeTags",
"ec2:DescribeSnapshots"
],
"Resource": "*"
}
]
}
```
------
**注記**
Amazon EC2 `ec2:Describe*` API アクションは、リソースレベルのアクセス許可をサポートしていません。そのため、ユーザーがコンソールで表示できる個人のリソースを制御できません。したがって、上記のステートメントの `Resource` エレメントには、\$1 (ワイルドカード) が必要です。どの Amazon EC2 API アクションでどの ARN を使用できるかの詳細については、[Amazon EC2 のアクション、リソース、および条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html)を参照してください。
**インスタンスと CloudWatch メトリクスを表示する**
以下のポリシーは、ユーザーに対して Amazon EC2 コンソールでのインスタンスの表示、[**Instances**] ページの [**Monitoring**] タブでの CloudWatch アラームおよびメトリクスの表示を許可します。Amazon EC2 コンソールでは、アラームとメトリクスの表示に CloudWatch API を使用するため、ユーザーに対して `cloudwatch:DescribeAlarms`、`cloudwatch:DescribeAlarmsForMetric`、`cloudwatch:ListMetrics`、`cloudwatch:GetMetricStatistics` および `cloudwatch:GetMetricData` のアクションを使用する許可を付与する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmsForMetric",
"cloudwatch:ListMetrics",
"cloudwatch:GetMetricStatistics",
"cloudwatch:GetMetricData"
],
"Resource": "*"
}
]
}
```
------
## 例: EC2 インスタンス起動ウィザードの使用
Amazon EC2 インスタンス起動ウィザードは、インスタンスを設定し、起動するためのオプションを提供する画面です。ユーザーがウィザードのオプションを操作できるように、API アクションを使用するアクセス許可をポリシーに含める必要があります。ポリシーにそれらのアクションを使用するアクセス許可が含まれない場合、ウィザードの一部の項目は適切にロードされず、ユーザーは起動を完了できません。
**基本のインスタンス起動ウィザードのアクセス**
起動を正常に完了させるには、ユーザーに `ec2:RunInstances` API アクションを使用するアクセス許可を付与し、少なくとも以下の API アクションを使用できるようにする必要があります。
+ `ec2:DescribeImages`: AMI を表示して選択します。
+ `ec2:DescribeInstanceTypes`: インスタンスタイプを表示および選択します。
+ `ec2:DescribeVpcs`: 使用できるネットワークオプションを表示します。
+ `ec2:DescribeSubnets`: 選択した VPC のすべての使用可能なサブネットを表示します。
+ `ec2:DescribeSecurityGroups` または `ec2:CreateSecurityGroup`: 既存のセキュリティグループを表示および選択する、または新しいセキュリティグループを作成します。
+ `ec2:DescribeKeyPairs` または `ec2:CreateKeyPair`: 既存のキーペアを選択する、または新しいキーペアを作成します。
+ `ec2:AuthorizeSecurityGroupIngress`: インバウンドルールを追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeInstanceTypes",
"ec2:DescribeKeyPairs",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:CreateKeyPair"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*"
}
]
}
```
------
ポリシーに次のような API アクションを追加して、ユーザーに追加のオプションを提供できます。
+ `ec2:DescribeAvailabilityZones`: 特定のアベイラビリティーゾーンを選択します。
+ `ec2:DescribeNetworkInterfaces`: 選択したサブネットの既存のネットワークインターフェイスを表示および選択します。
+ VPC セキュリティグループにアウトバウンドルールを追加するには、ユーザーに `ec2:AuthorizeSecurityGroupEgress` API アクションを使用するアクセス許可を付与する必要があります。既存のルールを変更または削除するには、ユーザーに関連する `ec2:RevokeSecurityGroup*` API アクションを使用するアクセス許可を付与する必要があります。
+ `ec2:CreateTags`: により作成されたリソースにタグ付けする場合に使用します。`RunInstances`詳細については、「[Amazon EC2 リソース作成時にタグ付けするアクセス許可の付与](supported-iam-actions-tagging.md)」を参照してください。ユーザーにこのアクションを使用する許可がなく、インスタンス起動ウィザードのタグ付けページでてタグを適用しようとした場合、起動に失敗します。
**重要**
インスタンスの起動中に **[Name]** (名前) を指定すると、タグが作成され、`ec2:CreateTags` アクションが必要になります。ユーザーに `ec2:CreateTags` アクションを使用するアクセス許可を付与すると、`aws:ResourceTag` 条件キーを使用してユーザーによる他のリソースの使用を制限する能力が制限されるため、注意が必要です。ユーザーに `ec2:CreateTags` アクションを使用するアクセス許可を付与すると、ユーザーがそれらの制限を回避するためにリソースのタグを変更できます。詳細については、「[属性ベースのアクセスを使用するアクセスの制御](iam-policies-for-amazon-ec2.md#control-access-with-tags)」を参照してください。
+ AMI を選択するときに Systems Manager パラメータを使用するには、ポリシーに `ssm:DescribeParameters` と `ssm:GetParameters` を追加する必要があります。`ssm:DescribeParameters` は、ユーザーに Systems Manager パラメータを表示および選択する許可を付与します。`ssm:GetParameters` は、ユーザーに Systems Manager パラメータの値を取得する許可を付与します。また、特定の Systems Manager パラメータへのアクセスを制限することもできます。詳細については、このセクションの後半の**特定の Systems Manager パラメータへのアクセスの制限**を参照してください。
現在、Amazon EC2 `Describe*` API アクションは、リソースレベルの許可をサポートしていません。そのため、ユーザーがインスタンス起動ウィザードで表示できる個人のリソースを制限することはできません。ただし、`ec2:RunInstances` API アクションにリソースレベルのアクセス許可を適用して、ユーザーがインスタンスの起動に使用できるリソースを制限できます。ユーザーが使用する権限がないオプションを選択すると、起動は失敗します。
**特定のインスタンスタイプ、サブネット、リージョンへのアクセスの制限**
次のポリシーにより、ユーザーは Amazon が所有する AMI を使用して `t2.micro` インスタンスを特定のサブネット (`subnet-1a2b3c4d`) でのみ起動することができます。ユーザーは指定されたリージョンでのみ起動できます。ユーザーが異なるリージョンを選択するか、インスタンス起動ウィザードで異なるインスタンスタイプ、AMI、サブネットを選択すると、起動は失敗します。
最初のステートメントでは、上記の例で説明したように、インスタンス起動ウィザードでオプションを表示する許可または新しいオプションを作成する許可がユーザーに付与されます。2 番目のステートメントでは、`ec2:RunInstances` アクションでネットワークインターフェイス、ボリューム、キーペア、セキュリティグループ、サブネットリソースを使用するアクセス許可が付与されます。これは、ユーザーが VPC でインスタンスを起動するために必要です。`ec2:RunInstances` アクションの使用方法の詳細については、[インスタンスの起動 (RunInstances)](ExamplePolicies_EC2.md#iam-example-runinstances)を参照してください。3 番目と 4 番目のステートメントは、それぞれインスタンスと AMI リソースを使用するための許可をユーザーに付与しますが、これは、インスタンスが `t2.micro` インスタンスであり、AMI が Amazon または特定の信頼できる検証済みのパートナーによって所有されている場合に限られます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ec2:DescribeInstanceTypes",
"ec2:DescribeKeyPairs",
"ec2:CreateKeyPair",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets", "ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action":"ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:network-interface/*",
"arn:aws:ec2:us-east-2:111122223333:volume/*",
"arn:aws:ec2:us-east-2:111122223333:key-pair/*",
"arn:aws:ec2:us-east-2:111122223333:security-group/*",
"arn:aws:ec2:us-east-2:111122223333:subnet/subnet-1a2b3c4d"
]
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:instance/*"
],
"Condition": {
"StringEquals": {
"ec2:InstanceType": "t2.micro"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": [
"arn:aws:ec2:us-east-2::image/ami-*"
],
"Condition": {
"StringEquals": {
"ec2:Owner": "amazon"
}
}
}
]
}
```
------
**特定の Systems Manager パラメータへのアクセスの制限**
次のポリシーは、特定の名前の Systems Manager パラメータを使用するアクセスを許可します。
1 つ目のステートメントは、インスタンス起動ウィザードで AMI を選択するときに Systems Manager パラメータを表示する許可をユーザーに付与します。2 つ目のステートメントは、`prod-*` という名前のパラメータのみを使用するアクセス許可をユーザーに付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameters"
],
"Resource": "arn:aws:ssm:us-east-2:123456123456:parameter/prod-*"
}
]
}
```
------
## 例: セキュリティグループの操作
**セキュリティグループを表示し、ルールを追加/削除する**
次のポリシーは、Amazon EC2 コンソールでセキュリティグループを表示し、インバウンドおよびアウトバウンドのルールを追加および削除し、タグ `Department=Test` を含む既存のセキュリティグループのルール説明を変更するアクセス許可をユーザーに付与します。
最初のステートメントの `ec2:DescribeTags` アクションにより、ユーザーはコンソールでタグを表示できます。これにより、ユーザーは変更できるセキュリティグループをより簡単に識別できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:AuthorizeSecurityGroupIngress",
"ec2:RevokeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress",
"ec2:RevokeSecurityGroupEgress",
"ec2:ModifySecurityGroupRules",
"ec2:UpdateSecurityGroupRuleDescriptionsIngress",
"ec2:UpdateSecurityGroupRuleDescriptionsEgress"
],
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:security-group/*"
],
"Condition": {
"StringEquals": {
"aws:ResourceTag/Department": "Test"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:ModifySecurityGroupRules"
],
"Resource": [
"arn:aws:ec2:us-east-2:111122223333:security-group-rule/*"
]
}
]}
```
------
**[Create Security Group] ダイアログボックスの使用**
ユーザーが Amazon EC2 コンソールの [**Create Security Group**] ダイアログボックスを使用して作業できるようにするポリシーを作成できます。このダイアログボックスを使用するには、ユーザーに少なくとも以下の API アクションを使用するアクセス許可を付与する必要があります。
+ `ec2:CreateSecurityGroup`: 新しいセキュリティグループを作成するには
+ `ec2:DescribeVpcs`: [**VPC**] リストに既存の VPC のリストを表示します。
これらのアクセス許可で、ユーザーは新しいセキュリティグループを正常に作成できますが、ルールを追加することはできません。[**Create Security Group**] ダイアログボックスでルールを操作するには、ポリシーに次の API アクションを追加します。
+ `ec2:AuthorizeSecurityGroupIngress`: インバウンドルールを追加します。
+ `ec2:AuthorizeSecurityGroupEgress`: VPC セキュリティグループにアウトバウンドルールを追加します。
+ `ec2:RevokeSecurityGroupIngress`: 既存のインバウンドルールを変更または削除します。これは、ユーザーがコンソールで [**Copy to new**] 機能を使用できるようにするために役に立ちます。この機能により、[**Create Security Group**] ダイアログボックスが開き、選択したセキュリティグループと同じルールが追加されます。
+ `ec2:RevokeSecurityGroupEgress`: VPC セキュリティグループのアウトバウンドルールを変更または削除します。これは、すべてのアウトバウンドトラフィックを許可するデフォルトのアウトバウンドルールを変更または削除する場合に役に立ちます。
+ `ec2:DeleteSecurityGroup`: 無効なルールを保存できないときに対応します。コンソールでは、最初にセキュリティグループを作成し、次に指定されたルールを追加します。ルールが無効である場合、アクションは失敗し、コンソールによってセキュリティグループの削除が試行されます。引き続き、[**Create Security Group**] ダイアログボックスが利用できるため、ユーザーは無効なルールを修正してセキュリティグループを再作成できます。この API アクションは必須ではありませんが、ユーザーにこのアクションを使用するアクセス許可が付与されておらず、無効なルールを持つセキュリティグループを作成しようとすると、ルールのないセキュリティグループが作成され、後でルールを追加することが必要になります。
+ `ec2:UpdateSecurityGroupRuleDescriptionsIngress`: 入力 (受信) セキュリティグループルールの説明を追加または更新するには
+ `ec2:UpdateSecurityGroupRuleDescriptionsEgress`: 出力 (送信) セキュリティグループルールの説明を追加または更新するには
+ `ec2:ModifySecurityGroupRules`: セキュリティグループのルールを変更します。
+ `ec2:DescribeSecurityGroupRules`: セキュリティグループのルールを一覧表示します。
次のポリシーは、[**Create Security Group**] ダイアログボックスを使用し、特定の VPC (`vpc-1a2b3c4d`) に関連付けられたセキュリティグループに対してインバウンドおよびアウトバウンドのルールを作成するアクセス許可をユーザーに付与します。ユーザーは VPC のセキュリティグループを作成できますが、ルールを追加することはできません。同様に、ユーザーは VPC `vpc-1a2b3c4d` に関連付けられていないの既存のセキュリティグループにルールを追加することもできません。ユーザーには、コンソールですべてのセキュリティグループを表示するアクセス許可も付与されます。これにより、ユーザーはインバウンドルールを追加するセキュリティグループをより簡単に識別できるようになります。このポリシーは、ユーザーに VPC `vpc-1a2b3c4d` に関連付けられたセキュリティグループを削除するアクセス許可も付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:CreateSecurityGroup",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteSecurityGroup",
"ec2:AuthorizeSecurityGroupIngress",
"ec2:AuthorizeSecurityGroupEgress"
],
"Resource": "arn:aws:ec2:us-east-2:111122223333:security-group/*",
"Condition":{
"ArnEquals": {
"ec2:Vpc": "arn:aws:ec2:us-east-2:111122223333:vpc/vpc-1a2b3c4d"
}
}
}
]
}
```
------
## 例: Elastic IP アドレスの操作
Amazon EC2 コンソールで Elastic IP アドレスを確認することをユーザーに許可するには、`ec2:DescribeAddresses` アクションを使用するためのアクセス許可をユーザーに付与します。
Elastic IP アドレスの使用をユーザーに許可する場合は、ポリシーに次のアクションを追加できます。
+ `ec2:AllocateAddress`: Elastic IP アドレスを割り当てます。
+ `ec2:ReleaseAddress`: Elastic IP アドレスをリリースするには。
+ `ec2:AssociateAddress`: Elastic IP アドレスをインスタンスまたはネットワークインターフェイスに関連付けます。
+ `ec2:DescribeNetworkInterfaces` と `ec2:DescribeInstances`: [**Associate address**] で使用します。この画面には、Elastic IP アドレスを関連付けることができるインスタンスまたはネットワークインターフェイスが表示されます。
+ `ec2:DisassociateAddress`: Elastic IP アドレスとインスタンスまたはネットワークインターフェイスの関連付けを解除します。
次のポリシーでは、Elastic IP アドレスの表示、割り当て、インスタンスとの関連付けを行うことができます。ユーザーは Elastic IP アドレスとネットワークインターフェイスの関連付け、Elastic IP アドレスの関連付けの解除、または Elastic IP アドレスのリリースを行うことはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeAddresses",
"ec2:AllocateAddress",
"ec2:DescribeInstances",
"ec2:AssociateAddress"
],
"Resource": "*"
}
]
}
```
------
## 例: リザーブドインスタンス の操作
次のポリシーにより、アカウントのリザーブドインスタンスの表示と変更、および AWS マネジメントコンソール での新しいリザーブドインスタンスの購入をすることができます。
このポリシーにより、ユーザーがアカウント内のすべての リザーブドインスタンス と オンデマンドインスタンス を表示できるようになります。個別の リザーブドインスタンス にリソースレベルのアクセス許可を設定することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:DescribeReservedInstances",
"ec2:ModifyReservedInstances",
"ec2:PurchaseReservedInstancesOffering",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeReservedInstancesOfferings"
],
"Resource": "*"
}
]
}
```
------
`ec2:DescribeAvailabilityZones` アクションは、リザーブドインスタンス を購入できるアベイラビリティーゾーンに関する情報を Amazon EC2 コンソールで表示できるようにするために必要です。`ec2:DescribeInstances` アクションは必須ではありませんが、このアクションにより、ユーザーがアカウントのインスタンスを表示し、正しい仕様に合わせて予約を購入できるようになります。
`ec2:DescribeInstances` を削除するなど、API アクションを調整してユーザーアクセスを制限できます。`ec2:DescribeAvailabilityZones` はユーザーが読み取り専用アクセスを持っていることを意味します。
# Amazon EC2 の AWS マネージドポリシー
ユーザー、グループ、ロールにアクセス許可を追加するには自分でポリシーを作成するよりも、AWS マネージドポリシーを使用する方が簡単です。チームに必要な権限のみを提供する [IAM カスタマーマネージドポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)には時間と専門知識が必要です。すぐに使用を開始するために、AWS マネージドポリシーを使用できます。これらのポリシーは一般的なユースケースを対象範囲に含めており、AWS アカウントで利用できます。AWS マネージドポリシーの詳細については「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
AWS のサービスはAWS マネージドポリシーを維持および更新します。AWS マネージドポリシーの許可を変更することはできません。サービスでは新しい機能を利用できるようにするために、AWS マネージドポリシーに権限が追加されることがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。新しい機能が立ち上げられた場合や、新しいオペレーションが使用可能になった場合に、各サービスが AWS マネージドポリシーを更新する可能性が最も高くなります。サービスはAWS マネージドポリシーから権限を削除しないため、ポリシーの更新によって既存の権限が破棄されることはありません。
さらに、AWS は複数のサービスにまたがるジョブ機能の特徴に対するマネージドポリシーもサポートしています。例えば、**ReadOnlyAccess** AWS マネージドポリシーではすべての AWS のサービスおよびリソースへの読み取り専用アクセスを許可します。サービスが新しい機能を起動する場合、AWS は新たなオペレーションとリソース用に、読み取り専用の許可を追加します。ジョブ機能ポリシーの一覧と説明については「*IAM ユーザーガイド*」の「[AWS ジョブ機能のマネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。
## AWS マネージドポリシー: AmazonEC2FullAccess
`AmazonEC2FullAccess` ポリシーは IAM アイデンティティにアタッチできます。このポリシーではAmazon EC2 への完全なアクセスを可能にする許可を付与します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2FullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2FullAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonEC2ReadOnlyAccess
`AmazonEC2ReadOnlyAccess` ポリシーを IAM IDにアタッチできます。このポリシーではAmazon EC2 に対する読み取り専用アクセスを可能にする許可を付与します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ReadOnlyAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonEC2ImageReferencesAccessPolicy
`AmazonEC2ImageReferencesAccessPolicy` ポリシーを IAM IDにアタッチできます。このポリシーは、EC2 DescribeImageReferences API を使用するために必要なすべてのアクセス許可を付与します (EC2 インスタンス、起動テンプレート、Systems Manager パラメータ、Image Builder レシピを表示するためのアクセス許可が含まれます)。このポリシーは `IncludeAllResourceTypes` フラグをサポートし、新しいリソースタイプのサポートが AWS で追加されると引き続き機能します。将来におけるポリシー更新は必要ありません。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ImageReferencesAccessPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ImageReferencesAccessPolicy.html)」を参照してください。
## AWS マネージドポリシー: AWSEC2CapacityReservationFleetRolePolicy
このポリシーは **AWSServiceRoleForEC2CapacityReservationFleet** という名前のサービスにリンクされたロールにアタッチされ、サービスがユーザーの代わりにキャパシティ予約を作成、変更、およびキャンセルすることを、キャパシティ予約フリートに許可します。詳細については、「[キャパシティ予約フリートでのサービスにリンクされたロールの使用EC2 Capacity Manager 用のサービスリンクロールの使用](using-service-linked-roles.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityReservationFleetRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityReservationFleetRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: AWSEC2FleetServiceRolePolicy
このポリシーは**AWSServiceRoleForEC2Fleet** という名前のサービスにリンクされたロールにアタッチされ、ユーザーの代わりにインスタンスのリクエスト、起動、終了、タグ付けを行うことを、EC2 フリートに許可します。詳細については「[EC2 フリート用のサービスにリンクされたロール](ec2-fleet-prerequisites.md#ec2-fleet-service-linked-role)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2FleetServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2FleetServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: AWSEC2SpotFleetServiceRolePolicy
このポリシーは**AWSServiceRoleForEC2SpotFleet** という名前のサービスにリンクされたロールにアタッチされ、ユーザーの代わりにインスタンスの起動および管理を行うことをスポットフリートに許可します。詳細については「[スポットフリート用のサービスにリンクされたロール](spot-fleet-prerequisites.md#service-linked-roles-spot-fleet-requests)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotFleetServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotFleetServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: AWSEC2SpotServiceRolePolicy
このポリシーは**AWSServiceRoleForEC2Spot** という名前のサービスにリンクされたロールにアタッチされ、ユーザーの代わりにスポットインスタンス の起動および管理を行うことを、Amazon EC2 に許可します。詳細については「[スポットインスタンスリクエスト向けのサービスにリンクされたロール](service-linked-roles-spot-instance-requests.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2SpotServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: AWSEC2VssSnapshotPolicy
この管理ポリシーは Amazon EC2 Windows インスタンスに使用する、IAM インスタンスプロファイルロールにアタッチすることができます。このポリシーはAmazon EC2 に、ユーザーに代わって VSS スナップショットを作成し管理することを許可するアクセス許可を付与します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2VssSnapshotPolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2VssSnapshotPolicy.html)」を参照してください。
## AWS マネージドポリシー: DeclarativePoliciesEC2Report
このポリシーは、`AWSServiceRoleForDeclarativePoliciesEC2Report` という名前のサービスにリンクされたロールにアタッチされ、宣言ポリシーのアカウントステータスレポートを生成するために必要な読み取り専用 API へのアクセスを提供します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/DeclarativePoliciesEC2Report.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/DeclarativePoliciesEC2Report.html)」を参照してください。
## AWS マネージドポリシー: EC2FastLaunchFullAccess
`EC2FastLaunchFullAccess` ポリシーはインスタンスプロファイルまたはその他の IAM ロールにアタッチできます。このポリシーはEC2 Fast Launch アクションへのフルアクセスと、次のようにターゲットを絞ったアクセス許可を付与します。
**アクセス許可の詳細**
+ **EC2 Fast Launch** – 管理アクセスが付与されて、対象ロールが EC2 Fast Launch を有効または無効にしたり、EC2 Fast Launch イメージを記述したりできるようになります。
+ **Amazon EC2** – Amazon EC2 RunInstances、CreateTags、Describe、Create Launch Template、Modify Launch Template の各オペレーションにアクセス権が付与されます。ネットワークとセキュリティグループのリソースを作成する、イングレスルールを承認する、および EC2 Fast Launch が作成したリソースを削除するためのアクセス権も付与されます。
+ **IAM** – 名前に `ec2fastlaunch` が含まれるインスタンスプロファイルを取得および使用して、EC2FastLaunchServiceRolePolicy のサービスにリンクしたロールを作成するためのアクセス許可が付与されます。
+ **CloudFormation** – EC2 Fast Launch が CloudFormation スタックを記述して作成し、作成したスタックを削除するためのアクセス権が付与されます。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AWSEC2CapacityManagerServiceRolePolicy
このポリシーは、EC2 Capacity Manager がキャパシティリソースを管理し、ユーザーに代わって AWS Organizations と統合できるように、**AWSServiceRoleForEC2CapacityManager** という名前のサービスリンクロールにアタッチされます。詳細については、「[Service-linked roles for EC2 Capacity Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-service-linked-roles-cm.html)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityManagerServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSEC2CapacityManagerServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: EC2FastLaunchServiceRolePolicy
このポリシーは**AWSServiceRoleForEC2FastLaunch** という名前のサービスにリンクしたロールにアタッチされ、EC2 Fast Launch が有効になっている AMI からのインスタンスの起動にかかる時間を短縮する、事前プロビジョニングされたスナップショットのセットを作成および管理することを、Amazon EC2 に許可します。詳細については「[EC2 Fast Launch でのサービスにリンクしたロール](slr-windows-fast-launch.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchServiceRolePolicy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2FastLaunchServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: Ec2InstanceConnect
`Ec2InstanceConnect` ポリシーを IAM アイデンティティにアタッチできます。このポリシーは、お客様が EC2 Instance Connect を呼び出して EC2 インスタンスにエフェメラルキーを公開し、ssh または EC2 Instance Connect CLI 経由で接続するアクセス許可を付与します。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2InstanceConnect.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2InstanceConnect.html)」を参照してください。
## AWS マネージドポリシー: Ec2InstanceConnectEndpoint
このポリシーは **AWSServiceRoleForEC2InstanceConnect** というサービスリンクロールにアタッチされ、EC2 Instance Connect エンドポイントがユーザーに変わってアクションを実行できるようにします。詳細については「[EC2 Instance Connect エンドポイントのサービスにリンクされたロール](eice-slr.md)」を参照してください。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンス*」の「[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/Ec2InstanceConnectEndpoint.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/Ec2InstanceConnectEndpoint.html)」を参照してください。このポリシーの更新の詳細については、「[Amazon EC2 での AWS 管理ポリシーに関する更新](#security-iam-awsmanpol-updates)」を参照してください。
## Amazon EC2 での AWS 管理ポリシーに関する更新
Amazon EC2 の AWS 管理ポリシーに対する更新の詳細について、このサービスがこれらの変更の追跡を開始した以降のものを示します。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSEC2CapacityManagerServiceRolePolicy](#security-iam-awsmanpol-AWSEC2CapacityManagerServiceRolePolicy) - 新しいポリシー | Amazon EC2 は、ユーザーがキャパシティリソースを管理できるようにし、ユーザーに代わって AWS Organizations と統合するために、このポリシーを追加しました。 | 2025 年 10 月 15 日 |
| [AmazonEC2ImageReferencesAccessPolicy](#security-iam-awsmanpol-AmazonEC2ImageReferencesAccessPolicy) - 新しいポリシー | Amazon EC2 は、EC2 DescribeImageReferences API でサポートされているすべてのリソースタイプをスキャンするアクセス許可を提供するために、このポリシーを追加しました。 | 2025 年 8 月 26 日 |
| [Ec2InstanceConnectEndpoint](#Ec2InstanceConnectEndpoint) - ポリシーを更新 | 既存の Instance Connect エンドポイントの変更をサポートするために、Amazon EC2 はこのポリシーを更新し、EC2 Instance Connect エンドポイントによって作成されたネットワークインターフェイスで IPv6 アドレスの割り当てと割り当て解除、およびセキュリティグループの変更を行うためのアクセス許可を追加しました。また、Amazon EC2 はこのポリシーを更新して、Null 条件演算子を StringLike 条件演算子に置き換えました。 | 2025 年 7 月 31 日 |
| [EC2FastLaunchServiceRolePolicy](#security-iam-awsmanpol-EC2FastLaunchServiceRolePolicy) - ポリシーを更新 | 孤立したリソースの発生を防ぐため、Amazon EC2 ではこのポリシーが更新され、ボリューム、ボリューム属性、ネットワークインターフェイスを記述し、EC2 Fast Launch によって作成されたボリュームおよびネットワークインターフェイスを削除するアクセス許可が追加されました。 | 2025 年 7 月 17 日 |
| [EC2FastLaunchFullAccess](#security-iam-awsmanpol-EC2FastLaunchFullAccess) - ポリシーを更新 | Amazon EC2 でこのポリシーが更新され、起動テンプレートの作成オペレーションと変更オペレーションが包含されました。これは、ネットワークとセキュリティグループのリソースを作成する、イングレスルールを承認する、および EC2 Fast Launch が作成したリソースを削除するためのものです。また、CloudFormation スタックを記述して作成し、EC2 Fast Launch が作成したスタックを削除することもできます。 | 2025 年 5 月 14 日 |
| [EC2FastLaunchServiceRolePolicy](#security-iam-awsmanpol-EC2FastLaunchServiceRolePolicy) - ポリシーを更新 | Amazon EC2 は、このポリシーを更新して EC2 Fast Launch のイベントルールを作成して管理するための Amazon EventBridge アクセスを追加しました。また、EC2 Fast Launch は、CloudFormation スタックの記述、AWS License Manager に関連付けられている AMI からのインスタンスの起動に加えて、作成した AWS KMS グラントの中で廃止できるもののリストの取得や、作成した起動テンプレートの削除も実行できるようになりました。 | 2025 年 5 月 14 日 |
| [AWSEC2CapacityReservationFleetRolePolicy](#security-iam-awsmanpol-AWSEC2CapacityReservationFleetRolePolicy) – アクセス許可の更新 | Amazon EC2 では、 ArnLike 条件演算子の代わりに StringLike 条件演算子を使用するように AWSEC2CapacityReservationFleetRolePolicy 管理ポリシーを更新しました。 | 2025 年 3 月 3 日 |
| [AmazonEC2ReadOnlyAccess](#security-iam-awsmanpol-AmazonEC2ReadOnlyAccess) – アクセス許可を追加 | Amazon EC2 は GetSecurityGroupsForVpcオペレーションを使用してセキュリティグループを取得できるアクセス許可を追加しました。 | 2024 年 12 月 27 日 |
| [EC2FastLaunchFullAccess](#security-iam-awsmanpol-EC2FastLaunchFullAccess) - 新しいポリシー | Amazon EC2 ではインスタンスから EC2 Fast Launch 機能に関連する API アクションを実行するために、このポリシーが追加されました。このポリシーはEC2 Fast Launch が有効になっている AMI から起動したインスタンスのインスタンスプロファイルにアタッチできます。 | 2024 年 5 月 14 日 |
| [AWSEC2VssSnapshotPolicy](#security-iam-awsmanpol-AWSEC2VssSnapshotPolicy) - 新しいポリシー | Amazon EC2 で、Amazon マシンイメージ (AMI) および EBS スナップショットにタグを作成および追加するアクセス許可を含む AWSEC2VssSnapshotPolicy ポリシーが追加されました。 | 2024 年 3 月 28 日 |
| [Ec2InstanceConnectEndpoint](#Ec2InstanceConnectEndpoint) - 新しいポリシー | Amazon EC2 は Ec2InstanceConnectEndpoint ポリシーを追加しました。このポリシーは、AWSServiceRoleForEC2InstanceConnect サービスにリンクされたロールにアタッチされ、EC2 Instance Connect エンドポイントを作成するときに Amazon EC2 がユーザーに代わってアクションを実行できるようにします。 | 2023 年 1 月 24 日 |
| [EC2FastLaunchServiceRolePolicy](#security-iam-awsmanpol-EC2FastLaunchServiceRolePolicy) - 新しいポリシー | Amazon EC2 で、EC2 Fast Launch 機能が追加され、事前プロビジョニングされたスナップショットのセットを作成することにより、Windows AMI がインスタンスをより速く起動できるようになりました。 | 2021 年 11 月 26 日 |
| Amazon EC2 が変更の追跡を開始しました。 | Amazon EC2 が AWS 管理ポリシーの変更の追跡を開始しました | 2021 年 3 月 1 日 |
# Amazon EC2 の IAM ロール
アプリケーションは AWS 認証情報を使用して API リクエストに署名する必要があります。したがって、アプリケーションデベロッパーである場合、EC2 インスタンスで実行するアプリケーションの認証情報を管理する戦略が必要です。例えば、AWS 認証情報をインスタンスに安全に配布することで、他のユーザーから認証情報を保護しながら、それらのインスタンスのアプリケーションで認証情報を使用してリクエストに署名できます。ただし、各インスタンスに認証情報を安全に配布することは難しく、特に AWS がユーザーの代わりに作成するスポットインスタンスや Auto Scaling グループのインスタンスなどではそれが顕著です。また、AWS 認証情報を循環させる場合、各インスタンスの認証情報を更新できる必要もあります。
アプリケーションが使用するセキュリティ認証情報をお客様が管理する必要なく、アプリケーションがインスタンスから API リクエストを安全に作成できるように、IAM ロールをデザインしました。AWS 認証情報を作成および配布する代わりに、以下の方法で、IAM ロールを使用して API リクエストを作成するアクセス許可を委任できます。
1. IAM ロールを作成します。
1. ロールを行うアカウントまたは AWS のサービスを定義する
1. ロールを引き受けた後で、アプリケーションで使用できる API アクションおよびリソースを定義します。
1. インスタンスの起動時にロールを指定するか、既存のインスタンスにロールをアタッチします。
1. アプリケーションで一時的な認証情報のセットを取得して使用します。
例えば、IAM ロールを使用し、Amazon S3 のバケットを使用する必要のあるインスタンスで実行中のアプリケーションに、アクセス許可を与えることができます。JSON 形式のポリシーを作成することにより、IAM ロールのアクセス許可を指定できます。これらのポリシーは ユーザー用に作成するポリシーに類似しています。ロールを変更すると、その変更はすべてのインスタンスに反映されます。
**注記**
Amazon EC2 IAM ロールの認証情報はロールで設定された最大セッション期間の対象にはなりません。詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けることができない](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールを作成するとき、アプリケーションが必要とする特定の API コールへのアクセスを制限する最小特権の IAM ポリシーを関連付けます。Windows 間の通信では明確に定義されドキュメント化された Windows グループとロールを使用して、Windows インスタンス間のアプリケーションレベルのアクセスを許可します。グループとロールを使用すると、顧客は最小特権のアプリケーションと NTFS フォルダレベルのアクセス許可を定義して、アプリケーション固有の要件へのアクセスを制限できます。
インスタンスにアタッチできる IAM ロールは 1 つだけですが、同じロールを複数のインスタンスにアタッチできます。IAM ロールの作成と使用の詳細については、「*IAM ユーザーガイド*」の「[ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。
リソースレベルのアクセス許可を IAM ポリシーに適用して、インスタンスの IAM ロールのアタッチ、置換、またはデタッチをユーザーに許可するかどうを制御できます。詳細については、[Amazon EC2 API アクションでサポートされるリソースレベルのアクセス許可](iam-policies-for-amazon-ec2.md#ec2-supported-iam-actions-resources)と[例: IAM ロールの使用](ExamplePolicies_EC2.md#iam-example-iam-roles)の例を参照してください。
**Topics**
+ [インスタンスプロファイル](#ec2-instance-profile)
+ [ユースケースに対するアクセス権限](#generate-policy-for-iam-role)
+ [セキュリティ認証情報の取得](instance-metadata-security-credentials.md)
+ [ロールをインスタンスにアタッチするためのアクセス権限](permission-to-pass-iam-roles.md)
+ [ロールをインスタンスにアタッチする](attach-iam-role.md)
+ [インスタンスアイデンティティロール](#ec2-instance-identity-roles)
## インスタンスプロファイル
Amazon EC2 はIAM ロールのコンテナとして*インスタンスプロファイル*を使用します。IAM コンソールを使用して IAM ロールを作成すると、コンソールによりインスタンスプロファイルが自動的に作成され、対応するロールと同じ名前が付けられます。Amazon EC2 コンソールを使用して IAM ロールを持つインスタンスを起動する場合、またはインスタンスに IAM ロールをアタッチする場合はインスタンスプロファイル名のリストに基づいてロールを選択してください。
AWS CLI、API、または AWS SDK を使用してロールを作成する場合、ロールとインスタンスプロファイルを別個のアクションとして作成します。名前は異なる可能性があります。次に AWS CLI、API、または AWS SDK を使用して IAM ロールを持つインスタンスを起動する場合、またはインスタンスに IAM ロールをアタッチする場合はインスタンスプロファイル名を指定します。
インスタンスプロファイルに含めることができる IAM ロールの数は 1 つのみです。IAM ロールを複数のインスタンス プロファイルに含めることができます。
インスタンスのアクセス許可を更新するには、インスタンスプロファイルを置き換えます。この変更が有効になるまでに最大 1 時間の遅延が発生するため、インスタンスプロファイルからロールを削除することはお勧めしません。
詳細については、「*IAM ユーザーガイド*」の「[インスタンスプロファイルの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)」を参照してください。
## ユースケースに対するアクセス権限
アプリケーションの IAM ロールを最初に作成するときに、必要な範囲を超えたアクセス権限を付与することがあります。本番環境でアプリケーションを起動する前に、IAM ロールのアクセスアクティビティに基づく IAM ポリシーを生成できます。IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、きめ細かなアクセス権限で管理ポリシーを作成し、それを IAM ロールにアタッチできます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス権限のみを付与します。これは[最小特権の付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)のベストプラクティスに準拠するのに役立ちます。詳細については、「*IAM ユーザーガイド*」の「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。
# インスタンスメタデータからのセキュリティ認証情報の取得
インスタンスのアプリケーションはインスタンスメタデータアイテム `iam/security-credentials/`*role-name* のロールから提供されたセキュリティ認証情報を取得します。アプリケーションにはロールに関連付けられたセキュリティ認証情報によって、ロールに対して定義したアクションおよびリソースのアクセス許可が付与されます。これらのセキュリティ認証情報は一時的なものであり、私たちが自動的に循環させます。新しい認証情報は古い認証情報が失効する少なくとも 5 分前から有効になるようにします。
インスタンスのメタデータの詳細については[インスタンスメタデータを使用して EC2 インスタンスを管理する](ec2-instance-metadata.md)を参照してください。
**警告**
IAM ロールでインスタンスメタデータを使用するサービスを使用する場合はサービスで HTTP 呼び出しが行われるときに認証情報を公開しないように注意する必要があります。認証情報を公開できるサービスの種類にはHTTP プロキシ、HTML/CSS 検証サービス、および XML インクルードをサポートする XML プロセッサーが含まれます。
Amazon EC2 ワークロードでは次に説明する方法を使用してセッション認証情報を取得することをお勧めします。これらの認証情報により、インスタンスに既に関連付けられている同じロールを引き受けるために `sts:AssumeRole` を使用する必要なしに、ワークロードが AWS API リクエストを実行できるようにすることができます。属性ベースのアクセス制御 (ABAC) のためにセッションタグを渡す必要がある場合や、ロールの許可をさらに制限するためにセッションポリシーを渡す必要がある場合でない限り、このようなロール引き受け呼び出しは不要です。これは同じ一時的なロールセッション認証情報の新しいセットを作成するためです。
ワークロードがロールを使用してそれ自体を引き受ける場合はその旨を明示的に許可する信頼ポリシーを作成する必要があります。信頼ポリシーを作成しない場合、`AccessDenied` エラーが発生します。詳細については、「*IAM ユーザーガイド*」の「[ロールの信頼ポリシーの変更](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)」を参照してください。
------
#### [ IMDSv2 ]
**Linux**
次のコマンドを Linux インスタンスから実行し、IAM ロールのセキュリティ認証情報を取得します。
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
**Server**
次のコマンドレットを Windows インスタンスから実行し、IAM ロールのセキュリティ認証情報を取得します。
```
[string]$token = Invoke-RestMethod `
-Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} `
-Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod `
-Headers @{"X-aws-ec2-metadata-token" = $token} `
-Method GET -Uri http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
------
#### [ IMDSv1 ]
**Linux**
次のコマンドを Linux インスタンスから実行し、IAM ロールのセキュリティ認証情報を取得します。
```
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
**Server**
次のコマンドレットを Windows インスタンスから実行し、IAM ロールのセキュリティ認証情報を取得します。
```
Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
```
------
以下は出力の例です。セキュリティ認証情報を取得できない場合は「*IAM ユーザーガイド*」の「[EC2 インスタンスにある一時的なセキュリティ認証情報にアクセスできない](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-ec2.html#troubleshoot_iam-ec2_no-keys)」を参照してください。
```
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
"SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token" : "token",
"Expiration" : "2017-05-17T15:09:54Z"
}
```
インスタンスで実行されるアプリケーション、AWS CLI、および Tools for Windows PowerShell コマンドのために、一時的なセキュリティ認証情報を明示的に取得する必要はありません。AWS SDK、AWS CLI、および Tools for Windows PowerShell はEC2 インスタンスメタデータサービスから自動的に認証情報を取得し、使用します。一時的なセキュリティ認証情報を使用してインスタンスの外部で呼び出しを行う (IAM ポリシーをテストするなど) にはアクセスキー、秘密キー、およびセッショントークンを提供する必要があります。詳細については、「*IAM ユーザーガイド*」の「[AWS リソースへのアクセスを要求するための一時的なセキュリティ認証情報の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)」を参照してください。
# IAM ロールをインスタンスにアタッチするためのアクセス権限を付与する
AWS アカウントの ID (IAM ユーザーなど) にはIAM ロールを使用して Amazon EC2 インスタンスを起動する、IAM ロールをインスタンスにアタッチする、インスタンスの IAM ロールを置き換える、またはインスタンスから IAM ロールをデタッチするための特定のアクセス権限が必要です。必要に応じて、次の API アクションを使用するためのアクセス権限を付与する必要があります。
+ `iam:PassRole`
+ `ec2:AssociateIamInstanceProfile`
+ `ec2:DisassociateIamInstanceProfile`
+ `ec2:ReplaceIamInstanceProfileAssociation`
**注記**
`iam:PassRole` のリソースを `*` として指定すると、任意の IAM ロールをインスタンスに渡すためのアクセス権が付与されます。[最小特権](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)のベストプラクティスに従うには以下のポリシー例に示すように、`iam:PassRole` を使用して特定の IAM ロールの ARN を指定します。
**プログラムによるアクセス用のポリシー例**
次の IAM ポリシーでは AWS CLI または Amazon EC2 API を使用して、IAM ロールを使用してインスタンスを起動したり、IAM ロールをインスタンスにアタッチしたり、インスタンスの IAM ロールを置き換えたりするためのアクセス権限を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:RunInstances",
"ec2:AssociateIamInstanceProfile",
"ec2:DisassociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/DevTeam*"
}
]
}
```
------
**コンソールアクセスの追加要件**
Amazon EC2 コンソールを使用して同じタスクを完了するためのアクセス権限を付与するには`iam:ListInstanceProfiles` API アクションも含める必要があります。
# インスタンスへの IAM ロールのアタッチ
IAM ロールはインスタンスの起動時または起動後に作成してインスタンスにアタッチできます。IAM ロールを置き換えたりデタッチしたりすることもできます。
**インスタンスの起動中に IAM ロールを作成してアタッチする (推奨)**
1. EC2 インスタンスの起動中に **[高度な詳細]** を展開します。
1. **[IAM インスタンスプロファイル]** セクションで、**[新しい IAM ロールを作成]** を選択します。
1. 以下を実行できるインラインロールの作成フォームが開きます。
+ **[ロール名]** を指定する (例: `EC2-S3-Access-Role`)
+ AWS マネージドポリシーを選択するか、インスタンス用のカスタムポリシーを作成することで許可を定義する
例えば、S3 へのアクセス権を付与するには `AmazonS3ReadOnlyAccess` マネージドポリシーを選択します。
+ `ec2.amazonaws.com` によるロールの引き受けを許可する信頼ポリシーを確認する
+ メタデータ用のオプションのタグを追加する
1. [**ロールの作成**] を選択してください。
新しく作成されたロールが自動的に選択され、インスタンスの起動時にインスタンスプロファイル経由でインスタンスにアタッチされます。
**注記**
インスタンスの起動中にコンソールを使用してロールを作成するときは、ロールと同じ名前のインスタンスプロファイルが自動的に作成されます。インスタンスプロファイルは、起動時に IAM ロール情報をインスタンスに渡すコンテナです。
**重要**
インスタンスにアタッチできる IAM ロールは 1 つだけですが、同じロールを複数のインスタンスにアタッチできます。
アプリケーションが必要とする特定の API コールへのアクセスを制限する最小特権の IAM ポリシーを関連付けてください。
IAM ロールの作成と使用の詳細については、「*IAM ユーザーガイド*」の「[ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。
**インスタンスの起動中に既存の IAM ロールをアタッチする**
Amazon EC2 コンソールを使用して起動時に IAM ロールをインスタンスにアタッチするには、**[高度な詳細]** を展開します。**[IAM インスタンスプロファイル]** で、ドロップダウンリストから IAM ロールを選択します。
**注記**
IAM コンソールを使用して IAM ロールを作成した場合はインスタンスプロファイルが自動的に作成され、ロールと同じ名前が付けられています。AWS CLI、API、または AWS SDK を使用して IAM ロールを作成した場合はインスタンスプロファイルにロールと異なる名前を付けた可能性があります。
実行中または停止しているインスタンスに IAM ロールをアタッチできます。インスタンスに既に IAM ロールがアタッチされている場合はそれを新しい IAM ロールに置き換える必要があります。
------
#### [ Console ]
**IAM ロールをインスタンスにアタッチするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択してください。
1. [**アクション**] メニューで、[**セキュリティ**]、[**IAM ロールの変更**] の順に選択してください。
1. **[IAM ロール]** で IAM インスタンスプロファイルを選択してください。
1. **[IAM ロールの更新]** を選択してください。
------
#### [ AWS CLI ]
**IAM ロールをインスタンスにアタッチするには**
[associate-iam-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) コマンドを使用して、IAM ロールをインスタンスにアタッチします。インスタンスプロファイルを指定する際にはインスタンスプロファイルの Amazon リソースネーム (ARN) を使用することも、そのインスタンスプロファイルの名前を使用することもできます。
```
aws ec2 associate-iam-instance-profile \
--instance-id i-1234567890abcdef0 \
--iam-instance-profile Name="TestRole-1"
```
------
#### [ PowerShell ]
**IAM ロールをインスタンスにアタッチするには**
[Register-EC2IamInstanceProfile](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2IamInstanceProfile.html) コマンドレットを使用します。
```
Register-EC2IamInstanceProfile `
-InstanceId i-1234567890abcdef0 `
-IamInstanceProfile_Name TestRole-1
```
------
既に IAM ロールがアタッチされているインスタンスで IAM ロールを置き換えるには、インスタンスが実行されている必要があります。既存のロールをデタッチしないでインスタンスの IAM ロールを変更する場合に、これを行うことができます。例えば、インスタンスで実行しているアプリケーションが実行する API アクションが中断されないようにするために、これを行うことができます。
------
#### [ Console ]
**インスタンスの IAM ロールを置き換えるには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択してください。
1. [**アクション**] メニューで、[**セキュリティ**]、[**IAM ロールの変更**] の順に選択してください。
1. **[IAM ロール]** で IAM インスタンスプロファイルを選択してください。
1. **[IAM ロールの更新]** を選択してください。
------
#### [ AWS CLI ]
**インスタンスの IAM ロールを置き換えるには**
1. 必要に応じて、[describe-iam-instance-profile-associations](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) コマンドを使用して、関連付け ID を取得します。
```
aws ec2 describe-iam-instance-profile-associations \
--filters Name=instance-id,Values=i-1234567890abcdef0 \
--query IamInstanceProfileAssociations.AssociationId
```
1. [replace-iam-instance-profile-association](https://docs.aws.amazon.com/cli/latest/reference/ec2/replace-iam-instance-profile-association.html) コマンドを使用します。既存のインスタンスプロファイルの関連付け ID と、新しいインスタンスプロファイルの ARN または名前を指定します。
```
aws ec2 replace-iam-instance-profile-association \
--association-id iip-assoc-0044d817db6c0a4ba \
--iam-instance-profile Name="TestRole-2"
```
------
#### [ PowerShell ]
**インスタンスの IAM ロールを置き換えるには**
1. 必要に応じて、[Get-EC2IamInstanceProfileAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2IamInstanceProfileAssociation.html) コマンドレットを使用して、関連付け ID を取得します。
```
(Get-EC2IamInstanceProfileAssociation -Filter @{Name="instance-id"; Values="i-0636508011d8e966a"}).AssociationId
```
1. [Set-EC2IamInstanceProfileAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Set-EC2IamInstanceProfileAssociation.html) コマンドレットを使用します。既存のインスタンスプロファイルの関連付け ID と、新しいインスタンスプロファイルの ARN または名前を指定します。
```
Set-EC2IamInstanceProfileAssociation `
-AssociationId iip-assoc-0044d817db6c0a4ba `
-IamInstanceProfile_Name TestRole-2
```
------
実行中または停止中のインスタンスから IAM ロールをデタッチできます。
------
#### [ Console ]
**インスタンスから IAM ロールをデタッチするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択してください。
1. [**アクション**] メニューで、[**セキュリティ**]、[**IAM ロールの変更**] の順に選択してください。
1. [**AM ロール**] で、[**IAM ロールがありません**] を選択してください。
1. **[IAM ロールの更新]** を選択してください。
1. 確認を求められたら、「**Detach**」と入力してから、**[デタッチ]** を選択してください。
------
#### [ AWS CLI ]
**インスタンスから IAM ロールをデタッチするには**
1. 必要に応じて、[describe-iam-instance-profile-associations](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) を使用して、デタッチする IAM インスタンスプロファイルの関連付け ID を取得します。
```
aws ec2 describe-iam-instance-profile-associations \
--filters Name=instance-id,Values=i-1234567890abcdef0 \
--query IamInstanceProfileAssociations.AssociationId
```
1. [disassociate-iam-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html) コマンドを使用します。
```
aws ec2 disassociate-iam-instance-profile --association-id iip-assoc-0044d817db6c0a4ba
```
------
#### [ PowerShell ]
**インスタンスから IAM ロールをデタッチするには**
1. 必要に応じて、[Get-EC2IamInstanceProfileAssociation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2IamInstanceProfileAssociation.html) を使用して、デタッチする IAM インスタンスプロファイルの関連付け ID を取得します。
```
(Get-EC2IamInstanceProfileAssociation -Filter @{Name="instance-id"; Values="i-0636508011d8e966a"}).AssociationId
```
1. [Unregister-EC2IamInstanceProfile](https://docs.aws.amazon.com/powershell/latest/reference/items/Unregister-EC2IamInstanceProfile.html) コマンドレットを使用します。
```
Unregister-EC2IamInstanceProfile -AssociationId iip-assoc-0044d817db6c0a4ba
```
------
## Amazon EC2 インスタンスのインスタンスアイデンティティロール
起動する各 Amazon EC2 インスタンスにはインスタンスアイデンティティを表す*インスタンスアイデンティティロール*があります。インスタンスアイデンティティロールは IAM ロールの一種です。インスタンス ID ロールを使用するように統合されている AWS サービスと機能はそのロールを使用してサービスのインスタンスを識別できます。
インスタンスアイデンティティロール認証情報は`/identity-credentials/ec2/security-credentials/ec2-instance` のインスタンスメタデータサービス (IMDS) からアクセスできます。認証情報はAWS 一時アクセスキー ID およびセッショントークンで構成されています。これらはインスタンス ID ロールを使用する AWS サービスへの AWS Sigv4 リクエストに署名するために使用されます。認証情報はインスタンスアイデンティティロールを使用するサービスまたは機能がインスタンスで有効になっているかどうかにかかわらず、インスタンスメタデータに存在します。
インスタンス ID ロールはインスタンスの起動時に自動的に作成され、ロール信頼ポリシー文書はなく、ID ポリシーやリソースポリシーの対象にもなりません。
### サポートされるサービス
AWS サービスはインスタンス ID ロールを使用します。
+ **Amazon EC2** – [EC2 Instance Connect](connect-linux-inst-eic.md) はインスタンス ID ロールを使用して Linux インスタンスのホストキーを更新します。
+ **Amazon GuardDuty** — [ランタイムモニタリング](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html)はインスタンスアイデンティティロールを使用して、ランタイムエージェントが GuardDuty VPC エンドポイントにセキュリティテレメトリを送信できるようにします。
+ **AWS Lambda** – [Lambda マネージドインスタンス](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html)は、ライフサイクルフック、テレメトリ、アーティファクトディストリビューションにインスタンス ID ロールを使用します。
+ **AWS Security Token Service (AWS STS)** - インスタンス ID ロールの認証情報は AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html) アクションで使用できます。
+ **AWS Systems Manager** - [デフォルトのホスト管理設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-default-host-management-configuration.html)を使用する場合、AWS Systems Manager はインスタンスアイデンティティロールによって提供された ID を使用して EC2 インスタンスを登録します。インスタンスを識別すると、システムマネージャーは `AWSSystemsManagerDefaultEC2InstanceManagementRole` IAM ロールをインスタンスに渡すことができます。
インスタンス ID ロールはインスタンス ID ロールと統合されていないため、他の AWS サービスや機能では使用できません。
### インスタンスアイデンティティロール ARN
インスタンスアイデンティティロール ARN は次の形式です。
```
arn:aws-partition:iam::account-number:assumed-role/aws:ec2-instance/instance-id
```
例:
```
arn:aws:iam::0123456789012:assumed-role/aws:ec2-instance/i-1234567890abcdef0
```
ARN の詳細については「IAM ユーザーガイド」の「[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)」を参照してください。
# Amazon EC2 Windows インスタンスの更新管理
弊社はEC2 インスタンスのオペレーティングシステムやアプリケーションに対するパッチ適用やそれらの更新およびセキュリティ確保を定期的に行うよう推奨しています。[AWS Systems Managerパッチマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html)を使うと、オペレーティングシステムとアプリケーションの双方に関するセキュリティ関連更新のインストールプロセスを自動化できます。
Auto Scaling グループの EC2 インスタンスの場合、[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-patchasginstance.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-patchasginstance.html) ランブックを使用すると、パッチ適用中のインスタンスが置き換えられるのを防ぐことができます。代わりに、アプリケーションベンダーが提供している、自動更新サービスまたは推奨更新インストールプロセスを使用することもできます。
**リソース**
+ **AL2023** – 「Amazon Linux 2023 ユーザーガイド」の「[AL2023 の更新](https://docs.aws.amazon.com/linux/al2023/ug/updating.html)」。**
+ **AL2** – 「Amazon Linux 2 ユーザーガイド」の「[Amazon Linux 2 インスタンスでのソフトウェアの管理](https://docs.aws.amazon.com/linux/al2/ug/managing-software.html)」。**
+ **Windows インスタンス** – [更新管理](ec2-windows-security-best-practices.md#ec2-windows-update-management)。
# Windows インスタンスにおけるセキュリティのベストプラクティス
Windows インスタンスにおける以下のセキュリティのベストプラクティスに従うことをお勧めします。
**Topics**
+ [高レベルのセキュリティのベストプラクティス](#high-level-security)
+ [更新管理](#ec2-windows-update-management)
+ [設定管理](#configuration-management)
+ [変更管理](#change-management)
+ [Amazon EC2 Windows インスタンスでの監査とアカウンタビリティ](#audit-accountability)
## 高レベルのセキュリティのベストプラクティス
Windows インスタンスにおける以下の高レベルのセキュリティベストプラクティスに従う必要があります。
+ **最小アクセス** – 想定される信頼できるシステムと場所へのアクセスのみを許可します。これはActive Directory、Microsoft ビジネス生産性サーバーなどのすべての Microsoft 製品、およびリモートデスクトップサービス、リバースプロキシサーバー、IIS ウェブサーバーなどのインフラストラクチャサービスに適用されます。Amazon EC2 インスタンスセキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、Amazon VPC パブリック/プライベートサブネットなど、AWS の機能を使用して、アーキテクチャ内の複数の場所でセキュリティを階層化します。Windows インスタンス内で、顧客は Windows Firewall を使用して、デプロイ内で多層防御戦略をさらに階層化できます。システムが設計どおりに機能するために必要な OS コンポーネントとアプリケーションのみをインストールします。インフラストラクチャ全体のローカルおよびリモートのリソースにアクセスするために、IIS などのインフラストラクチャサービスをサービスアカウントで動作するように設定するか、アプリケーションプール ID などの機能を使用するように設定します。
+ **最小特権** – インスタンスとアカウントがそれらの機能を実行するのに必要な権限の最小セットを決定します。サーバーとユーザーにこれらの定義済みのアクセス許可のみが付与されるように制限します。ロールベースのアクセスコントロールなどの手法を使用して、管理アカウントのパブリック面を減らし、タスクを実行するための最も制限されたロールを作成します。NTFS 内の暗号化ファイルシステム (EFS) などの OS 機能を使用して、保管時の機密データを暗号化し、アプリケーションとユーザーのそのデータへのアクセスをコントロールします。
+ **設定管理** – ウイルス対策、マルウェア対策、侵入検知/防止、ファイル整合性モニタリングなど、最新のセキュリティパッチとホストベースの保護スイートを組み込んだベースラインサーバー設定を作成します。記録されている最新のベースラインに対して各サーバーを評価し、逸脱を識別して、フラグを付けます。適切なログおよび監査データを生成して安全に保存するように各サーバーが設定されていることを確認します。
+ **変更管理** – サーバー設定ベースラインに対する変更を制御するプロセスを作成し、完全に自動化された変更プロセスを目指します。また、Windows PowerShell DSC で Just Enough Administration (JEA) を活用して、管理アクセスを最小限必要な機能に制限します。
+ **パッチ管理** – EC2 インスタンス上のオペレーティングシステムやアプリケーションに対して定期的にパッチを適用し、更新し、セキュリティを確保するプロセスを実装します。
+ **監査ログ** – Amazon EC2 インスタンスに対するアクセスとすべての変更を監査して、サーバーの整合性を検証し、承認された変更のみが行われるようにします。[IIS の拡張ログ記録](https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/enhanced-logging-for-iis85)などの機能を活用して、デフォルトのログ機能を強化します。VPC Flow Logs や AWS などの AWS CloudTrail 機能もネットワークアクセス (許可/拒否されたリクエストや API コールなど) の監査に利用できます。
## 更新管理
Amazon EC2 で Windows を実行した場合の最良の結果を得るには以下のベストプラクティスを実践することをお勧めします。
+ [Configure Windows Update](#windows-update)
+ [Update drivers](#drivers)
+ [Use the latest Windows AMIs](#AMI)
+ [Test performance before migration](#test)
+ [Update launch agents](#agents)
+ 更新をインストールした後、Windows インスタンスを再起動します。詳細については「[Amazon EC2 インスタンスを再起動する](ec2-instance-reboot.md)」を参照してください。
Windows インスタンスを Windows Server の新しいバージョンにアップグレードまたは移行する方法については「[EC2 Windows インスタンスのより新しいバージョンの Windows Server へのアップグレード](serverupgrade.md)」を参照してください。
**Windows Update の設定**
デフォルトではAWS Windows Server AMI から起動されたインスタンスは Windows Update による更新が適用されません。
**Windows ドライバーを更新する**
すべての Windows EC2 インスタンスでドライバーを最新の状態に維持し、最新の問題修正とパフォーマンス強化がフリート全体に適用されるようにします。インスタンスタイプによってはAWS PV ドライバー、Amazon ENA ドライバー、AWS NVMe ドライバーを更新する必要があります。
+ [SNS トピック](xen-drivers-overview.md#drivers-subscribe-notifications)を使用して、ドライバーの新規リリースの最新情報を受け取ります。
+ AWS Systems Manager 自動化ランブック [AWSSupport-UpgradeWindowsAWSDrivers](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-upgradewindowsawsdrivers.html) を使用して、インスタンス全体で更新を簡単に適用できます。
**最新の Windows AMI を使用してインスタンスを起動する**
AWS では最新の OS パッチ、ドライバー、起動エージェントを備えた新しい Windows AMI が毎月リリースされています。新しいインスタンスを起動する際、または独自のカスタムイメージを作成する際は最新の AMI を使用してください。
+ AWS Windows AMI の各リリースに対する更新を表示するには「[AWS Windows AMI バージョン履歴](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/ec2-windows-ami-version-history.html)」を参照してください。
+ 利用可能な最新の AMI を使用してビルドするには「[Systems Manager パラメータストアを使用した最新の Windows AMI のクエリ](https://aws.amazon.com/blogs/mt/query-for-the-latest-windows-ami-using-systems-manager-parameter-store/)」を参照してください。
+ データベースのインスタンスを起動するのに使用できる特殊な Windows AMI とコンプライアンス強化のユースケースの詳細については「AWS Windows AMI リファレンス」の「[専用の Windows AMI](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/specialized-windows-amis.html)」を参照してください。**
**移行前にシステム/アプリケーションパフォーマンスをテストする**
エンタープライズアプリケーションを AWSに移行するには多くの変更や設定が使用になる場合があります。EC2 ソリューションのパフォーマンステストを常に実施して、以下を確実にします。
+ インスタンスサイズ、拡張ネットワーク、テナンシー (共有または専有) などのインスタンスタイプが適切に構成されている。
+ インスタンストポロジーがワークロードに対し適切であり、必要に応じて高パフォーマンス機能 (専有テナンシー、プレイスメントグループ、インスタンスストアボリューム、ベアメタルなど) を活用します。
**EC2Launch v2 の最新バージョンのインストール**
最新の機能強化をフリート全体に適用されるように、最新の EC2Launch v2 エージェントにインストールします。詳細については「[EC2Launch v2 をインストールする](ec2launch-v2-install.md)」を参照してください。
フリートが混在している場合、あるいは EC2Launch (Windows Server 2016 または 2019) エージェントまたは EC2 Config (レガシー OS のみ) エージェントを引き続き使用する場合は各エージェントの最新のバージョンに更新します。
自動更新はWindows Server バージョンと起動エージェントの次の組み合わせでサポートされます。**[Amazon EC2 起動エージェント]** の [SSM Quick Setup ホスト管理](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html)コンソールで自動更新にオプトインできます。
| Windows のバージョン | EC2Launch v1 | EC2Launch v2 |
| --- | --- | --- |
| 2016 | ✓ | ✓ |
| 2019 | ✓ | ✓ |
| 2022 | | ✓ |
+ EC2Launch v2 への更新の詳細については「[EC2Launch v2 の最新バージョンのインストール](ec2launch-v2-install.md)」を参照してください。
+ EC2Config を手動で更新する方法については「[EC2Config の最新バージョンのインストール](UsingConfig_Install.md)」を参照してください。
+ EC2Launch を手動で更新する方法については「[EC2Launch の最新バージョンのインストール](ec2launch-download.md)」を参照してください。
## 設定管理
Amazon マシンイメージ (AMI) はAmazon EC2 インスタンスの初期設定を提供します。これにはWindows OS とオプションの顧客固有のカスタマイズ (アプリケーションやセキュリティ管理など) が含まれます。カスタマイズされたセキュリティ設定ベースラインを含む AMI カタログを作成することで、すべての Windows インスタンスが標準のセキュリティコントロールを使用して起動されるようにします。セキュリティベースラインはAMI にベイクしたり、EC2 インスタンスの起動時に動的にブートストラップされるようにしたり、AWS Service Catalog ポートフォリオを介して一様に配布される製品としてパッケージ化したりすることができます。AMI のセキュリティ保護の詳細については[AMI 構築のベストプラクティス](https://docs.aws.amazon.com/marketplace/latest/userguide/best-practices-for-building-your-amis.html)を参照してください。
各 Amazon EC2 インスタンスは組織のセキュリティ標準に準拠する必要があります。不要な Windows のロールや機能をインストールしないでください。また、悪意のあるコードから保護するソフトウェア (ウイルス対策、マルウェア対策、エクスプロイト緩和)、ホストの整合性をモニタリングするソフトウェア、侵入検知を実行するソフトウェアをインストールしてください。OS のセキュリティ設定をモニタリングおよび維持し、重要な OS ファイルの整合性を保護し、セキュリティベースラインからの逸脱について警告するように、セキュリティソフトウェアを設定します。Microsoft や Center for Internet Security (CIS)、米国国立標準技術研究所 (NIST) が公開している推奨セキュリティ設定ベンチマークの実装を検討してください。特定のアプリケーションサーバーに、他の Microsoft ツール ([Best Practice Analyzer for SQL Server](https://www.microsoft.com/en-us/download/details.aspx?id=29302) など) を使用することを検討してください。
AWS ユーザーは Amazon Inspector 評価を実行して、Amazon EC2 インスタンスにデプロイされたアプリケーションのセキュリティとコンプライアンスを向上させることもできます。Amazon Inspector はアプリケーションの脆弱性やベストプラクティスからの逸脱を自動的に評価します。また、一般的なセキュリティコンプライアンス標準 (PCI DSS など) と脆弱性定義にマッピングされた数百のルールのナレッジベースを含みます。組み込みルールの一例として、リモートルートログインが有効になっているかどうかや、脆弱なソフトウェアバージョンがインストールされているかどうかを確認するものがあります。これらのルールは AWS のセキュリティ調査担当者が定期的に更新しています。
Windows インスタンスを保護する場合はActive Directory ドメインサービスを実装して、分散した場所でスケーラブル、セキュア、管理可能なインフラストラクチャを有効にすることをお勧めします。さらに、Amazon EC2 コンソールまたはなどの Amazon EC2 プロビジョニングツールからインスタンスを起動したら、設定ドリフトが生じた場合に備えて、Microsoft Windows PowerShell DSCAWS CloudFormation などのネイティブ OS 機能を利用して設定状態を維持することをお勧めします。
## 変更管理
最初のセキュリティベースラインが起動時に Amazon EC2 インスタンスに適用された後、仮想マシンのセキュリティを維持するように、Amazon EC2 の進行中の変更を制御します。AWS リソース (セキュリティグループ、ルートテーブル、ネットワーク ACL など) に対する変更、OS およびアプリケーション設定 (Windows またはアプリケーションパッチ、ソフトウェアアップグレード、設定ファイルなど) に対する変更を承認して組み込むための、変更管理プロセスを確立します。
AWS にはAWS リソース (AWS CloudTrail、AWS Config、CloudFormation、AWS Elastic Beanstalk を含む) の他に、Systems Center Operations Manager および System Center Virtual Machine Manager の管理パックに対する変更を管理できるようにするいくつかのツールが用意されています。Microsoft から毎月第 2 火曜日に (または必要に応じて) Windows パッチがリリースされ、AWS はMicrosoft がパッチをリリースしてから 5 日以内に、AWS で管理されるすべての Windows AMI を更新します。したがって重要になるのはすべてのベースライン AMI に継続的にパッチを適用し、最新の AMI ID で CloudFormation テンプレートと Auto Scaling グループ設定を更新し、インスタンスのパッチ管理の実行を自動化するツールを実装することです。
Microsoft はWindows OS およびアプリケーションの変更を管理するためのいくつかのオプションを提供しています。例えば、SCCM はライフサイクル全体の環境の変更に対応しています。ビジネスの要件に応じて、変更がアプリケーション SLA、容量、セキュリティ、ディザスタリカバリ手順に与える影響を制御するツールを選択してください。手動の変更を避け、代わりに自動設定管理ソフトウェアやコマンドラインツール (EC2 Run Command や Windows PowerShell など) を活用して、スクリプト化された繰り返し可能な変更プロセスを実装します。この要件を満たすのに役立つように、Windows インスタンスに対するすべての操作の拡張ログ記録が有効になっている踏み台ホストを使用して、すべてのイベントとタスクが自動的に記録されるようにします。
## Amazon EC2 Windows インスタンスでの監査とアカウンタビリティ
AWS CloudTrail、AWS Config、AWS Config ルール にはAWS リソースの変更を監査するための監査および変更追跡機能が用意されています。ローカルログファイルを一元ログ管理システムに送信し、セキュリティおよび運用動作分析のためにログデータを保存するように、Windows イベントログを設定します。Microsoft System Center Operations Manager (SCOM) はWindows インスタンスにデプロイされた Microsoft アプリケーションに関する情報を集計し、事前設定されたカスタムルールセットをアプリケーションのロールとサービスに基づいて適用します。System Center Management Pack は SCOM に基づいて構築され、アプリケーション固有のモニタリングと設定のガイダンスを提供します。これらの [Management Pack](https://learn.microsoft.com/en-us/archive/technet-wiki/16174.microsoft-management-packs) はWindows Server Active Directory、SharePoint Server 2013、Exchange Server 2013、Lync Server 2013、SQL Server 2014 など多くのサーバーとテクノロジーをサポートしています。
顧客はMicrosoft システム管理ツールに加えて、Amazon CloudWatch を使用して、インスタンスの CPU 使用率、ディスクパフォーマンス、ネットワーク I/O をモニタリングし、ホストおよびインスタンスのステータスチェックを実行できます。EC2Config、EC2Launch、および EC2Launch v2 エージェントではWindows インスタンスのその他の高度な機能にアクセスできます。例えば、Windows システム、セキュリティ、アプリケーション、インターネットインフォメーションサービス (IIS) のログを CloudWatch Logs にエクスポートし、Amazon CloudWatch メトリクスおよびアラームと統合できます。顧客は Windows パフォーマンスカウンターを Amazon CloudWatch カスタムメトリクスにエクスポートするスクリプトを作成することもできます。
# Amazon EC2 のキーペアと Amazon EC2 インスタンス
キーペアにはプライベートキーと公開キーを含んでおり、 Amazon EC2 インスタンスへの接続時の身分証明に使用する、セキュリティ認証情報のセットを構成しています。Linux インスタンスの場合、プライベートキーを使用すると、インスタンスに安全に SSH 接続できます。Windows インスタンスの場合、管理者パスワードを復号化するにはプライベートキーが必要です。これを使用してインスタンスに接続します。
次の図に示すように、パブリックキーは Amazon EC2 によりお客様のインスタンス内に保管されます。またプライベートキーはお客様自身が保管します。プライベートキーを所有するすべてのユーザーはキーペアを使用するインスタンスに接続できるため、プライベートキーを安全な場所に保存することが重要です。
![\[キーペアはお客様のコンピュータのプライベートキーとインスタンスのパブリックキーで構成されます。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ec2-key-pair.png)
インスタンスを起動するときに、[キーペアを指定](ec2-instance-launch-parameters.md#liw-key-pair)することで、キーペアを必要とするメソッドを使用してインスタンスに接続できるようになります。セキュリティの管理方法に応じて、すべてのインスタンスに同じ key pair を指定することも、異なるキーペアを指定することもできます。
Linux インスタンスではインスタンスを初めて起動する際に、起動時に指定したパブリックキーが Linux インスタンス上で `~/.ssh/authorized_keys` 内のエントリに配置されます。SSH を使用して Linux インスタンスに接続する際のログインにはパブリックキーに対応するプライベートキーを指定する必要があります。
EC2 インスタンスへの接続の詳細については「[EC2 インスタンスに接続する](connect.md)」を参照してください。
**重要**
Amazon EC2 ではプライベートキーのコピーが保持されないため、プライベートキーを失った場合、復元することはできません。ただし、プライベートキーを失くしたインスタンスに接続する方法はまだあります。詳細については「[プライベートキーを紛失しました。自分のインスタンスに接続するにはどうすればよいですか?](TroubleshootingInstancesConnecting.md#replacing-lost-key-pair)」を参照してください。
キーペアの代わりに、インタラクティブなワンクリックのブラウザベースのシェルまたは AWS Command Line Interface (AWS CLI) を使用してインスタンスに接続するために、[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) を使用できます。
**Topics**
+ [Amazon EC2 インスタンスのキーペアを作成する](create-key-pairs.md)
+ [キーペアの詳細表示](describe-keys.md)
+ [キーペアの削除](delete-key-pair.md)
+ [Linux インスタンスでパブリックキーを追加または置き換える](replacing-key-pair.md)
+ [キーペアのフィンガープリントを確認する](verify-keys.md)
# Amazon EC2 インスタンスのキーペアを作成する
Amazon EC2 を使用してキーペアを作成できます。またはサードパーティー製のツールを使用して、キーペアを作成してから、Amazon EC2 にインポートすることもできます。
Amazon EC2 はLinux および Windows インスタンスで 2048-bit SSH-2 RSA キーをサポートしています。Amazon EC2 はLinux インスタンスでは ED25519 キーもサポートしています。
キーペアの作成後にインスタンスに接続する方法については「[SSH を使用した Linux インスタンスへの接続](connect-to-linux-instance.md)」と「[RDP を使用した Windows インスタンスへの接続](connecting_to_windows_instance.md)」を参照してください。
**Topics**
+ [Amazon EC2 を使用してキーペアを作成する](#having-ec2-create-your-key-pair)
+ [AWS CloudFormation を使用してキーペアを作成する](#create-key-pair-cloudformation)
+ [サードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートする](#how-to-generate-your-own-key-and-import-it-to-aws)
## Amazon EC2 を使用してキーペアを作成する
Amazon EC2 を使用してキーペアを作成すると、パブリックキーは Amazon EC2 内に保存されます。プライベートキーは自分で保存します。
リージョンごとに最大 5,000 のキーペアを作成できます。増加をリクエストするにはサポートケースを作成します。詳細については、「*サポート ユーザーガイド*」の「[サポートケースの作成](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)」を参照してください。
------
#### [ Console ]
**Amazon EC2 を使用してキーペアを作成するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインの [**Network & Security**] で、[**Key Pairs**] を選択してください。
1. [**キーペアの作成**] を選択してください。
1. [**Name (名前)**] に、キーペアのわかりやすい名前を入力してください。Amazon EC2 はキー名として指定した名前にパブリックキーを関連付けます。キー名には最大 255 文字の ASCII 文字を含めることができます。先頭または末尾にスペースを含めることはできません。
1. 使用しているオペレーティングシステムに適したキーペアのタイプを選択してください。
(Linux インスタンス) **[キーペアのタイプ]**で **[RSA]** または **[ED25519]** を選択してください。
(Windows インスタンス) **[キーペアのタイプ]** で **[RSA]** を選択してください。Windows インスタンスでは **ED25519** キーはサポートされていません。
1. [**Private key ファイル形式**] に、プライベートキーを保存する形式を選択してください。OpenSSH で使用できる形式でプライベートキーを保存するには[**pem**] を選択してください。プライベートキーを PuTTY で使用できる形式で保存するには[**ppk**] を選択してください。
1. タグを追加するには[タグの追加] ページで **[タグの追加]** をクリックし、タグのキーと値を入力してください。各タグについて、これを繰り返します。
1. [**キーペアの作成**] を選択してください。
1. ブラウザによって秘密キーファイルが自動的にダウンロードされます。ベースファイル名はキーペアの名前として指定した名前で、ファイル名拡張子は選択したファイル形式によって決まります。ダウンロードしたプライベートキーのファイルを安全な場所に保存します。
**重要**
プライベートキーのファイルを保存できるのはこのタイミングだけです。
1. macOS または Linux コンピュータの SSH クライアントを使用して Linux インスタンスに接続する予定がある場合は自分以外のユーザーが読み込むことができないように、次のコマンドを使用してプライベートキーファイルの許可を設定します。
```
chmod 400 key-pair-name.pem
```
これらのアクセス権限を設定しないと、このキーペアを使用してインスタンスに接続できません。詳細については「[エラー: Unprotected Private キー ファイル (保護されていないプライベートキーファイル)](TroubleshootingInstancesConnecting.md#troubleshoot-unprotected-key)」を参照してください。
------
#### [ AWS CLI ]
**Amazon EC2 を使用してキーペアを作成するには**
1. [https://docs.aws.amazon.com/cli/latest/reference/ec2/create-key-pair.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-key-pair.html) コマンドを使用し、次のようにキーペアを生成してプライベートキーを `.pem` ファイルに保存します。`--query` オプションはプライベートキーのマテリアルを出力に表示します。`--output` オプションは指定されたファイルにプライベートキーのマテリアルを保存します。拡張子は、キー形式に応じて`.ppk` または `.pem` のいずれかである必要があります。プライベートキーには公開キーの名前とは異なる名前を指定できますが、使いやすくするために、同じ名前を使用してください。
```
aws ec2 create-key-pair \
--key-name my-key-pair \
--key-type rsa \
--key-format pem \
--query "KeyMaterial" \
--output text > my-key-pair.pem
```
1. macOS または Linux コンピュータの SSH クライアントを使用して Linux インスタンスに接続する予定がある場合は自分以外のユーザーが読み込むことができないように、次のコマンドを使用してプライベートキーファイルの許可を設定します。
```
chmod 400 key-pair-name.pem
```
これらのアクセス権限を設定しないと、このキーペアを使用してインスタンスに接続できません。詳細については「[エラー: Unprotected Private キー ファイル (保護されていないプライベートキーファイル)](TroubleshootingInstancesConnecting.md#troubleshoot-unprotected-key)」を参照してください。
------
#### [ PowerShell ]
**Amazon EC2 を使用してキーペアを作成するには**
以下の [https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2KeyPair.html) コマンドレットを使用してキーを生成し、`.pem` または `.ppk` ファイルに保存します。**Out-File** コマンドレットは、プライベートキーのマテリアルを拡張機能とともにファイルに保存します。拡張子は、キー形式に応じて`.ppk` または `.pem` のいずれかである必要があります。プライベートキーには公開キーの名前とは異なる名前を指定できますが、使いやすくするために、同じ名前を使用してください。
```
(New-EC2KeyPair `
-KeyName "my-key-pair" `
-KeyType "rsa" `
-KeyFormat "pem").KeyMaterial | Out-File -Encoding ascii -FilePath C:\path\my-key-pair.pem
```
------
## AWS CloudFormation を使用してキーペアを作成する
CloudFormation を使用して新しいキーペアを作成すると、プライベートキーは AWS Systems Manager パラメータストアに保存されます。パラメータ名の形式は次のとおりです。
```
/ec2/keypair/key_pair_id
```
詳細については「*AWS Systems Manager ユーザーガイド*」の「[AWS Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)」を参照してください。
**CloudFormation を使用してキーペアを作成するには**
1. テンプレートに [AWS::EC2::KeyPair](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-keypair.html) リソースを指定します。
```
Resources:
NewKeyPair:
Type: 'AWS::EC2::KeyPair'
Properties:
KeyName: new-key-pair
```
1. キーペアの ID を取得するには次のように [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) コマンドを使用します。
```
aws ec2 describe-key-pairs --filters Name=key-name,Values=new-key-pair --query KeyPairs[*].KeyPairId --output text
```
以下は出力の例です。
```
key-05abb699beEXAMPLE
```
1. キーのパラメータを取得するために、次のように [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-parameter.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-parameter.html) コマンドを使用して、キーマテリアルを `.pem` ファイルに保存します。
```
aws ssm get-parameter --name /ec2/keypair/key-05abb699beEXAMPLE --with-decryption --query Parameter.Value --output text > new-key-pair.pem
```
**必要な IAM 許可**
CloudFormation がユーザーに代わって Parameter Store パラメータを管理できるようにするにはCloudFormation またはユーザーにより引き受けられた IAM ロールは次の許可を持っている必要があります。
+ `ssm:PutParameter` – プライベートキーマテリアル用パラメーターの削除を許可します。
+ `ssm:DeleteParameter` - プライベートキーマテリアルを保存したパラメータの削除する許可を付与します。この権限はキーペアが CloudFormation によってインポートまたは作成されたかに関係なく必要です。
スタックによって作成またはインポートされたキーペアを CloudFormation が削除する場合、CloudFormation がキーペアをインポートする際ではなく、キーペアを作成する際にのみパラメーターを作成する場合でも権限チェックが実行され、パラメータを削除する権限があるかどうかが判断されます。CloudFormation はアカウント内のどのパラメータとも一致しない偽造パラメータ名を使用して必要なアクセス許可をテストします。そのため、`AccessDeniedException` エラーメッセージに偽造されたパラメータ名が表示されることがあります。
## サードパーティー製のツールを使用してキーペアを作成し、Amazon EC2 にパブリックキーをインポートする
Amazon EC2 を使用してキーペアを作成する代わりに、サードパーティー製のツールで RSA または ED25519 のキーペアを作成してから、パブリックキーを Amazon EC2 にインポートすることもできます。
**キーペアの要件**
+ サポートされている型:
+ (Linux と Windows) RSA
+ (Linux のみ) ED25519
**注記**
Windows インスタンスでは ED25519 キーはサポートされていません。
+ Amazon EC2 は DSA キーを受け付けません。
+ サポートされる形式:
+ OpenSSH パブリックキー形式 (Linux の場合、`~/.ssh/authorized_keys` の形式)
+ (Linux のみ) EC2 Instance Connect API の使用中に SSH を使用して接続する場合はSSH2 形式もサポートされます。
+ SSH プライベートキーファイル形式は PEM または PPK である必要があります
+ (RSA のみ)Base64 でエンコードされた DER 形式
+ SSH パブリックキーファイル形式 [[RFC4716](https://www.ietf.org/rfc/rfc4716.txt)] で指定
+ サポートされている長さ:
+ 1024、2048、および 4096。
+ (Linux のみ) EC2 Instance Connect API の使用中に SSH を使用して接続する場合は長さ 2048 および 4096 がサポートされます。
**サードパーティーツールを使用してキーペアを作成するには**
1. 選択したサードパーティ製のツールでキーペアを生成します。例えば、**ssh-keygen** (標準 OpenSSH インストールで提供されるツール) を使用しできます。また、Java、Ruby、Python などのさまざまなプログラミング言語ではキーペアの作成に使用できる標準ライブラリが提供されています。
**重要**
プライベートキーはPEM または PPK 形式である必要があります。例えば、`ssh-keygen -m PEM` を使用して OpenSSH キーを PEM 形式で生成します。
1. ローカルファイルにパブリックキーを保存します。例えば、`~/.ssh/my-key-pair.pub` (Linux、macOS) または `C:\keys\my-key-pair.pub` (Windows)。このファイル名の拡張子は重要ではありません。
1. `.pem` または `.ppk` 拡張子を持つローカルファイルにプライベートキーを保存します。例えば、`~/.ssh/my-key-pair.pem` または `~/.ssh/my-key-pair.ppk` (Linux、macOS)、あるいは `C:\keys\my-key-pair.pem` または `C:\keys\my-key-pair.ppk` (Windows)。インスタンスへの接続に使用するツールによっては特定のファイル形式が必要になるため、ファイル拡張子は重要です。OpenSSH には `.pem` ファイルが必要であり、PuTTY には `.ppk` ファイルが必要です。
**重要**
プライベートキーファイルを安全な場所に保存します。インスタンスと対応するプライベートキーの起動時には毎回インスタンスに接続するたびに、パブリックキーの名前を入力する必要があります。
キーペアを作成したら、次のいずれかの方法を使用してパブリックキーを Amazon EC2 にインポートします。
------
#### [ Console ]
**パブリックキーを Amazon EC2 にインポートするには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**キーペア**] を選択してください。
1. [**Import Key Pair (キーペアのインポート)**] を選択してください。
1. [**Name (名前)**] に、パブリックキーのわかりやすい名前を入力してください。名前には最大 255 文字の ASCII 文字を含めることができます。先頭または末尾にスペースを含めることはできません。
**注記**
EC2 コンソールからインスタンスに接続すると、コンソールはプライベートキーファイルの名前としてこの名前が提示します。
1. [**Browse (参照)**] を選択してパブリックキーに移動して選択するか、パブリックキーのコンテンツを [**Public key contents (パブリックキーのコンテンツ)**] フィールドに貼り付けます。
1. [**Import Key Pair (キーペアのインポート)**] を選択してください。
1. インポートしたパブリックキーがキーペアのリストに表示されていることを確認します。
------
#### [ AWS CLI ]
**パブリックキーを Amazon EC2 にインポートするには**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/import-key-pair.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/import-key-pair.html) コマンドを使用します。
```
aws ec2 import-key-pair \
--key-name my-key-pair \
--public-key-material fileb://path/my-key-pair.pub
```
**キーペアが正常にインポートされたことを確認するには**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) コマンドを使用します。
```
aws ec2 describe-key-pairs --key-names my-key-pair
```
------
#### [ PowerShell ]
**パブリックキーを Amazon EC2 にインポートするには**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Import-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Import-EC2KeyPair.html) コマンドレットを使用します。
```
$publickey=[Io.File]::ReadAllText("C:\Users\TestUser\.ssh\id_rsa.pub")
Import-EC2KeyPair `
-KeyName my-key-pair `
-PublicKey $publickey
```
**キーペアが正常にインポートされたことを確認するには**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html) コマンドレットを使用します。
```
Get-EC2KeyPair -KeyName my-key-pair
```
------
# キーペアの詳細表示
Amazon EC2 に保存されているキーペアの詳細情報を表示できます。また、パブリックキーマテリアルを取得し、起動時に指定されたパブリックキーを特定することもできます。
**Topics**
+ [キーペアの詳細表示](#describe-public-key)
+ [パブリックキーマテリアルを取得する](#retrieving-the-public-key)
+ [起動時に指定されたパブリックキーを特定する](#identify-key-pair-specified-at-launch)
## キーペアの詳細表示
Amazon EC2 に保存されているパブリックキーに関する次の情報を表示できます。パブリックキーの名前、ID、キーの種類、フィンガープリント、パブリックキーのマテリアル、Amazon EC2 によるキーの作成日時 (UTC タイムゾーン) (キーがサードパーティのツールで作成された場合はそのキーが Amazon EC2 にインポートされた日時)、およびパブリックキーに関連付けられているすべてのタグ。
------
#### [ Console ]
**キーペアに関する情報を表示するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. 左側のナビゲータで、**[Key Pairs]** (キーペア) を選択してください。
1. **[Key pairs]** (キーペア) テーブルで各パブリックキーに関する情報を確認できます。
![\[キーペアテーブル。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/key-pairs-describe-console.png)
1. パブリックキーのタグを表示するにはキーの横にあるチェックボックスをオンにし、**[アクション]** および **[タグの管理]** を選択してください。
------
#### [ AWS CLI ]
**キーペアに関する情報を表示するには**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) コマンドを使用します。
```
aws ec2 describe-key-pairs --key-names key-pair-name
```
------
#### [ PowerShell ]
**キーペアに関する情報を表示するには**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html) コマンドレットを使用します。
```
Get-EC2KeyPair -KeyName key-pair-name
```
------
## パブリックキーマテリアルを取得する
キーペアのパブリックキーマテリアルを取得できます。以下はパブリックキーの例です。こちらは、読みやすいように改行が追加されています。
```
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
```
------
#### [ Private key ]
**ssh-keygen を使用してパブリックキーマテリアルを取得するには (Linux)**
ローカルの Linux または macOS コンピュータで、**ssh-keygen** コマンドを使用します。プライベートキーをダウンロードしたパスを指定します (`.pem` ファイル)。
```
ssh-keygen -y -f /path_to_key_pair/my-key-pair.pem
```
この **ssh-keygen** コマンドが失敗した場合は、次の **chmod** コマンドを実行して、プライベートキーファイルに必要なアクセス許可があることを確認します。
```
chmod 400 key-pair-name.pem
```
**PuTTYgen を使用してパブリックキーマテリアルを取得するには (Windows)**
ローカルの Windows コンピュータで、PuTTYgen を起動します。**[ロード]** を選択します。プライベートキーファイル (`.ppk` または `.pem`) を選択してください。PuTTYgen の [**Public key for pasting into OpenSSH authorized\$1keys ファイル**] にパブリックキーが表示されます。パブリックキーは[**パブリックキーの保存**] を選択してファイルの名前を指定し、ファイルを保存後、そのファイルを開いて表示することもできます。
------
#### [ AWS CLI ]
**パブリックキーマテリアルを取得するには**
次の [describe-key-pairs](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) コマンドを使用し、`--include-public-key` オプションを指定します。
```
aws ec2 describe-key-pairs \
--key-names key-pair-name \
--include-public-key \
--query "KeyPairs[].PublicKey"
```
------
#### [ PowerShell ]
**パブリックキーマテリアルを取得するには**
[Get-EC2KeyPair](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2KeyPair.html) コマンドレットを使用します。
```
(Get-EC2KeyPair -KeyName key-pair-name -IncludePublicKey $true).PublicKey
```
------
#### [ IMDSv2 ]
**Linux**
次のコマンドを Linux インスタンスから実行します。
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
**Server**
次のコマンドレットを Windows インスタンスから実行します。
```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
------
#### [ IMDSv1 ]
**Linux**
次のコマンドを Linux インスタンスから実行します。
```
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
**Server**
次のコマンドレットを Windows インスタンスから実行します。
```
Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
```
------
## 起動時に指定されたパブリックキーを特定する
インスタンスを起動する際にパブリックキーを指定した場合、インスタンスによりパブリックキー名が記録されます。インスタンスのパブリックキーを変更したり、パブリックキーを追加したりしても、インスタンスで報告されたパブリックキー名は変更されません。
------
#### [ Console ]
**インスタンスの起動時に指定されたパブリックキーを特定するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. インスタンスを選択します。
1. **[詳細]** タブの **[インスタンスの詳細]** で、**[起動時に割り当てられたキーペア]** を見つけます。
------
#### [ AWS CLI ]
**インスタンスの起動時に指定されたパブリックキーを特定するには**
次の [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) コマンドを使用します。
```
aws ec2 describe-instances \
--instance-id i-1234567890abcdef0 \
--query "Reservations[].Instances[].KeyName" \
--output text
```
以下は出力の例です。
```
key-pair-name
```
------
#### [ PowerShell ]
**インスタンスの起動時に指定されたパブリックキーを特定するには**
[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) コマンドレットを使用します。
```
(Get-EC2Instance -InstanceId i-1234567890abcdef0).Instances | Select KeyName
```
以下は出力の例です。
```
KeyName
-------
key-pair-name
```
------
# キーペアの削除
キーペアは削除できます。これにより、Amazon EC2 に保存されているパブリックキーは削除されます。キーペアを削除しても、対応するプライベートキーは削除されません。
以下の方法でパブリックキーを削除すると、キーペアの[作成](create-key-pairs.md#having-ec2-create-your-key-pair)時または[インポート](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws)時に Amazon EC2 に保存されたパブリックキーのみが削除されます。パブリックキーをインスタンスに追加していた場合、パブリックキーを削除しても、インスタンスの起動時またはそれ以降に、インスタンスからパブリックキーが削除されることはありません。ローカルコンピュータのプライベートキーも削除されません。Amazon EC2 から削除したパブリックキーを使用してインスタンスを起動していた場合、プライベートキー (`.pem`) ファイルを保持している限り、引き続きインスタンスに接続できます。
**重要**
Auto Scaling グループ (Elastic Beanstalk 環境など) を使用している場合、関連する起動テンプレートまたは起動設定に削除するパブリックキーが指定されていないことを確認します。Amazon EC2 Auto Scaling が異常なインスタンスを検出した場合、代替インスタンスを起動します。ただし、パブリックキーが見つからない場合、インスタンスの起動は失敗します。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[起動テンプレート](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html)」を参照してください。
------
#### [ Console ]
**Amazon EC2 上のパブリックキーを削除するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**キーペア**] を選択してください。
1. 削除するキーペアを選択し、**[Actions]** (アクション)、**[Delete]** (削除) の順に選択してください。
1. 確認フィールドで、`Delete` を入力し、[**Delete (削除)**] を選択してください。
------
#### [ AWS CLI ]
**Amazon EC2 上のパブリックキーを削除するには**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-key-pair.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-key-pair.html) コマンドを使用します。
```
aws ec2 delete-key-pair --key-name my-key-pair
```
------
#### [ PowerShell ]
**Amazon EC2 上のパブリックキーを削除するには**
[https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2KeyPair.html](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2KeyPair.html) コマンドレットを使用します。
```
Remove-EC2KeyPair -KeyName my-key-pair
```
------
# Linux インスタンスでパブリックキーを追加または置き換える
| |
| --- |
| プライベートキーを紛失した場合、キーペアを使用するインスタンスへのアクセスができなくなります。起動時に指定したキーペアとは異なるキーペアを使用してインスタンスに接続する方法の詳細については「[プライベートキーを紛失しました](TroubleshootingInstancesConnecting.md#replacing-lost-key-pair)」を参照してください。 |
インスタンスを起動するとき、[キーペアを指定](ec2-instance-launch-parameters.md#liw-key-pair)できます。起動時にキーペアを指定した場合、インスタンスを初めて起動すると、パブリックキーマテリアルが Linux インスタンスの `~/.ssh/authorized_keys` 内のエントリに配置されます。SSH を使用して Linux インスタンスに最初に接続するときは、デフォルトユーザーと、お使いの Linux インスタンスに保存されているパブリックキーに対応するプライベートキーを指定する必要があります。
インスタンスに接続した後、インスタンスのデフォルトシステムアカウントへのアクセスに使用されるキーペアを変更するにはインスタンスに新しいパブリックキーを追加するか、インスタンスでパブリックキー (既存のパブリックキーを削除して新しいパブリックキーを追加します) を置き換えます。インスタンスからすべてのパブリックキーを削除することもできます。
次の場合に、キーペアを追加するか、交換できます。
+ 例えば、組織のユーザーが、別のキーペアを使用してシステムユーザーにアクセスする必要がある場合はパブリックキーをインスタンスに追加できます。
+ プライベートキー (`.pem` ファイル) のコピーを持つユーザーがインスタンスに接続するのを防ぐには (例えば、組織を去った場合)、インスタンスのパブリックキーを削除し、新しいものに交換することができます。
+ インスタンスから Linux AMI を作成すると、パブリックキーマテリアルがインスタンスから AMI にコピーされます。AMI からインスタンスを起動すると、新しいインスタンスは元のインスタンスからのパブリックキーを含みます。プライベートキーを持つユーザーが新しいインスタンスに接続できないようにするにはAMI を作成する前に、元のインスタンスからパブリックキーを削除します。**
次の手順を使用して、デフォルトのユーザー (例: `ec2-user`) のキーペアを変更します。インスタンスにユーザーを追加する方法についてはインスタンスのオペレーティングシステムのドキュメントを参照してください。
**キーペアの追加または交換**
1. [Amazon EC2 コンソール](create-key-pairs.md#having-ec2-create-your-key-pair)または[サードパーティー製のツール](create-key-pairs.md#how-to-generate-your-own-key-and-import-it-to-aws)で、新しいキーペアを作成します。
1. 新しいキーペアからパブリックキーを取得します。詳細については、「[パブリックキーマテリアルを取得する](describe-keys.md#retrieving-the-public-key)」を参照してください。
1. [インスタンスに接続します](connect-to-linux-instance.md)。
1. インスタンスで、任意のテキストエディタを使用して `.ssh/authorized_keys` ファイルを開きます。既存のパブリックキー情報の下の新しいキーペアからパブリックキー情報を貼り付け、ファイルを保存します。
1. インスタンスから切断します。新しいキーペアのプライベートキーファイルを使用してインスタンスに接続できることを確認します。
1. 自動スケーリング、EC2 フリート、起動テンプレートのいずれかを使用してインスタンスを起動する場合は、置き換えるキーペアが起動テンプレートまたは起動設定で指定されているかどうかを確認します。指定されていないとインスタンスの起動は失敗します。
1. (オプション) 既存のキーペアを交換している場合はインスタンスに接続し、`.ssh/authorized_keys` ファイルからオリジナルのキーペアのパブリックキー情報を削除します。
**インスタンスからパブリックキーを削除するには**
1. [インスタンスに接続します](connect-to-linux-instance.md)。
1. 任意のテキストエディタを使用して、インスタンス上にある `.ssh/authorized_keys` ファイルを開きます。パブリックキーの情報を削除し、ファイルを保存します。
**警告**
インスタンスからすべてのパブリックキーを削除してインスタンスを切断すると、別のログイン方法を設定していない限り、インスタンスに再度接続することはできません。
# キーペアのフィンガープリントを確認する
キーペアのフィンガープリントを確認するにはAmazon EC2 コンソールの **[キーペア]** ページに表示される、または [describe-key-pair](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-key-pairs.html) コマンドによって返されるフィンガープリントを、ローカルコンピュータのプライベートキーを使用して生成したフィンガープリントと比較します。これらのフィンガープリントは一致するはずです。
Amazon EC2 がフィンガープリントを計算するとき、Amazon EC2 はフィンガープリントに `=` 文字でパディングを追加することがあります。**ssh-keygen** などのその他のツールではこのパディングを省略することがあります。
キーペアのフィンガープリントではなく Linux EC2 インスタンスのフィンガープリントを検証しようとしている場合は「[インスタンスのフィンガープリントを取得する](connection-prereqs-general.md#connection-prereqs-fingerprint)」を参照してください。
## フィンガープリントの計算方法
Amazon EC2 はRSA および ED25519 キーペアのフィンガープリントを計算するために、さまざまなハッシュ関数を使用します。さらに、RSA キーペアの場合、Amazon EC2 はキーペアが Amazon EC2 によって作成されたか、Amazon EC2 にインポートされたかに応じて、異なるハッシュ関数を使用して異なる方法でフィンガープリントを計算します。
次の表はAmazon EC2 で作成され、Amazon EC2 にインポートされた RSA および ED25519 キーペアの、フィンガープリントの計算に使用されるハッシュ関数の一覧です。
**(Linux インスタンス) フィンガープリントの計算に使用されるハッシュ関数**
| キーペアのソース | RSA キーペア (Windows および Linux) | ED25519 キーペア (Linux) |
| --- | --- | --- |
| Amazon EC2 によって作成された | SHA-1 | SHA-256 |
| Amazon EC2 にインポートされた | MD5¹ | SHA-256 |
¹ パブリック RSA キーを Amazon EC2 にインポートした場合、フィンガープリントはMD5 ハッシュ関数を使用して計算されます。これはサードパーティーのツールを使用する、Amazon EC2 を使用して作成した既存のプライベートキーから新しいパブリックキーを生成するなど、キーペアの作成方法に関係なく当てはまります。
## 異なるリージョンで同じキーペアを使用する場合
同じキーペアを使用して、異なる AWS リージョン にあるインスタンスに接続する場合は使用するすべてのリージョンにパブリックキーをインポートする必要があります。Amazon EC2 を使用してキーペアを作成する場合、パブリックキーを他のリージョンにインポートできるよう、[パブリックキーマテリアルを取得する](describe-keys.md#retrieving-the-public-key) することができます。
**注記**
Amazon EC2 を使用して RSA キーペアを作成した場合、Amazon EC2 プライベートキーからパブリックキーを生成すると、インポートされたパブリックキーのフィンガープリントは元のパブリックキーとは異なるものになります。これはAmazon EC2 を使用して作成された元の RSA キーのフィンガープリントは SHA-1 ハッシュ関数を使用して計算されるのに対し、インポートされた RSA キーのフィンガープリントは MD5 ハッシュ関数を使用して計算されるためです。
ED25519 キーペアでは同じ SHA-256 ハッシュ関数を使用してフィンガープリントが計算されるため、Amazon EC2 で作成されたか、Amazon EC2 にインポートされたかにかかわらず、フィンガープリントは同一になります。
## プライベートキーからフィンガープリントを生成する
ローカルマシンのプライベートキーからフィンガープリントを生成するには次のいずれかのコマンドを使用します。
Windows ローカルマシンを使用している場合、Windows Subsystem for Linux (WSL) を使用して、次のコマンドを実行できます。[Windows 10 インストールガイド](https://learn.microsoft.com/en-us/windows/wsl/install)の手順を使用して、WSL と Linux ディストリビューションをインストールします。手順の例ではLinux の Ubuntu ディストリビューションをインストールしますが、任意のディストリビューションをインストールできます。コンピュータを再起動して変更を有効にすることが求められます。
+ **Amazon EC2 を使用してキーペアを作成した場合**
次の例のように、OpenSSL ツールを使用してフィンガープリントを生成します。
RSA キーペアの場合:
```
openssl pkcs8 -in path_to_private_key -inform PEM -outform DER -topk8 -nocrypt | openssl sha1 -c
```
(Linux インスタンス) ED25519 キーペアの場合:
```
ssh-keygen -l -f path_to_private_key
```
+ **(RSA キーペアのみ) パブリックキーを Amazon EC2 にインポートした場合**
キーペアの作成方法 (サードパーティーのツールを使用する、Amazon EC2 を使用して作成した既存のプライベートキーから新しいパブリックキーを生成するなど) に関係なく、この手順に従うことができます。
次の例のように、OpenSSL ツールを使用してフィンガープリントを生成します。
```
openssl rsa -in path_to_private_key -pubout -outform DER | openssl md5 -c
```
+ **OpenSSH 7.8 以降を使用して OpenSSH キーペアを作成し、パブリックキーを Amazon EC2 にインポートした場合**
次の例のように、**ssh-keygen** を使用してフィンガープリントを生成します。
RSA キーペアの場合:
```
ssh-keygen -ef path_to_private_key -m PEM | openssl rsa -RSAPublicKey_in -outform DER | openssl md5 -c
```
(Linux インスタンス) ED25519 キーペアの場合:
```
ssh-keygen -l -f path_to_private_key
```
# EC2 インスタンスの Amazon EC2 セキュリティグループ
*セキュリティグループ*は、EC2 インスタンスの仮想ファイアウォールとして機能し、受信トラフィックと送信トラフィックを制御します。インバウンドルールはインスタンスへの受信トラフィックを制御し、アウトバウンドルールはインスタンスからの送信トラフィックをコントロールします。インスタンスの起動時に 1 つ以上のセキュリティグループを指定できます。セキュリティグループを指定しない場合、Amazon EC2 はデフォルトの VPC のセキュリティグループを使用します。インスタンスを起動した後、そのセキュリティグループを変更することができます。
セキュリティは、AWS とお客様の間の共有責任です。詳細については、[セキュリティとコンプライアンスの目標を満たすように Amazon EC2 を設定し、Amazon EC2 リソースの保護に役立つ他の サービスの使用方法を学びます。](ec2-security.md)を参照してください。AWS は、インスタンスをセキュリティで保護するためのツールの 1 つとしてセキュリティグループを提供しています。このセキュリティグループをセキュリティニーズに合わせて設定する必要があります。セキュリティグループでは十分に満たせない要件がある場合は、セキュリティグループの使用に加えて、どのインスタンスでも独自のファイアウォールを使用できます。
**料金**
セキュリティグループは追加料金なしで使用できます。
**Topics**
+ [概要:](#security-group-basics)
+ [Amazon EC2 インスタンス用のセキュリティグループの作成](creating-security-group.md)
+ [Amazon EC2 インスタンスのセキュリティグループの変更](changing-security-group.md)
+ [Amazon EC2 セキュリティグループの削除](deleting-security-group.md)
+ [Amazon EC2 セキュリティグループの接続の追跡](security-group-connection-tracking.md)
+ [さまざまなユースケースのセキュリティグループのルール](security-group-rules-reference.md)
## 概要:
各インスタンスは複数のセキュリティグループに関連付けることができ、各セキュリティグループは複数のインスタンスに関連付けることができます。各セキュリティグループに対してルールを追加し、関連付けられたインスタンスに対するトラフィックを許可します。セキュリティグループのルールはいつでも変更することができます。新規または変更したルールは、セキュリティグループに関連付けられたすべてのインスタンスに自動的に適用されます。トラフィックがインスタンスに到達することを許可するかどうかを Amazon EC2 が判断するとき、インスタンスに関連付けられているすべてのセキュリティグループのすべてのルールを評価します。詳細については、「*Amazon VPC ユーザーガイド*」の「[セキュリティグループルール](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)」を参照してください。
次の図は、サブネット、インターネットゲートウェイ、セキュリティグループを備えた VPC を示しています。サブネットには EC2 インスタンスが含まれています。セキュリティグループはインスタンスに関連付けられています。インスタンスに到達するトラフィックは、セキュリティグループのルールで許可されているトラフィックだけです。例えば、使用しているネットワークからの SSH トラフィックを許可するルールがセキュリティグループに含まれている場合は、使用しているコンピュータからインスタンスに SSH で接続できます。関連付けられたリソースからのすべてのトラフィックを許可するルールがセキュリティグループに含まれている場合、各インスタンスは他のインスタンスから送信されたすべてのトラフィックを受信できます。
![\[セキュリティグループを持つ VPC。サブネット内の EC2 インスタンスは、セキュリティグループに関連付けられています。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ec2-security-groups.png)
セキュリティグループはステートフルです。インスタンスからリクエストを送信すると、そのリクエストに対するレスポンストラフィックは、セキュリティグループのインバウンドルールにかかわらず、流入できます。また、許可されたインバウンドトラフィックに対する応答 (戻りのトラフィック) は、アウトバウンドルールにかかわらずアウト側に対し通過することができます。詳細については、[接続追跡](security-group-connection-tracking.md)を参照してください。
# Amazon EC2 インスタンス用のセキュリティグループの作成
セキュリティグループは、関連付けられたインスタンスのファイアウォールとして動作し、インバウンドトラフィックとアウトバウンドトラフィックの両方をインスタンスレベルでコントロールします。SSH (Linux インスタンス) または RDP (Windows インスタンス) を使用してインスタンスに接続できるようにするルールをセキュリティグループに追加できます。また、ウェブサーバー宛ての HTTP および HTTPS トラフィックなど、クライアントトラフィックを許可するルールを追加することもできます。
インスタンスを起動する際に、インスタンスにセキュリティグループを関連付けることができます。関連付けられたセキュリティグループのルールを追加または削除すると、それらの変更は、そのセキュリティグループを関連付けたすべてのインスタンスに自動的に適用されます。
インスタンスを起動した後、追加のセキュリティグループを関連付けることができます。詳細については、[Amazon EC2 インスタンスのセキュリティグループの変更](changing-security-group.md)を参照してください。
インバウンドおよびアウトバウンドのセキュリティグループルールは、セキュリティグループの作成時に追加することも、後で追加することもできます。詳細については、[セキュリティグループルールの設定](changing-security-group.md#add-remove-security-group-rules)を参照してください。セキュリティグループに追加できるルールの例については、「[さまざまなユースケースのセキュリティグループのルール](security-group-rules-reference.md)」を参照してください。
**考慮事項**
+ 新しいセキュリティグループには、すべてのトラフィックがリソースを離れることを許可するアウトバウンドルールのみで開始されます。任意のインバウンドトラフィックを許可するには、またはアウトバウンドトラフィックを制限するには、ルールを追加する必要があります。
+ 送信元でインスタンスに対する SSH または RDP アクセスを許可するルールを設定する場合、任意の場所からのアクセスは許可しないでください。これを許可すると、インターネット上のすべての IP アドレスからのインスタンスに対するこのアクセスを許可することになります。この状態は、テスト環境での短時間の使用であれば許容できますが、実稼働環境においては安全ではありません。
+ 特定のポートに複数のルールがある場合、Amazon EC2 が最も許容度の大きいルールを適用します。例えば、IP アドレス 203.0.113.1 からの TCP ポート 22 (SSH) に対するアクセスを許可するルールと、任意の場所からの TCP ポート 22 に対するアクセスを許可する別のルールがある場合、全員が TCP ポート 22 にアクセスできます。
+ 1 つのインスタンスには複数のセキュリティグループを関連付けることができます。そのため、1 つのインスタンスに数百のルールが適用される場合があります。結果として、インスタンスにアクセスするときに問題が発生する可能性があります。そのため、ルールは可能な限り要約することをお勧めします。
+ ルールに送信元または送信先としてセキュリティグループを指定する場合、ルールはセキュリティグループに関連付けられているすべてのインスタンスに影響します。着信トラフィックは、ソースセキュリティグループに関連付けられたインスタンスのプライベート IP アドレスに基づいて許可されます (パブリック IP アドレスまたは Elastic IP アドレスは考慮されません)。IP アドレスについては、[Amazon EC2 インスタンスの IP アドレス指定](using-instance-addressing.md)を参照してください。
+ デフォルトで、Amazon EC2 はポート 25 のトラフィックをブロックします。詳細については、[ポート 25 を使用した E メール送信の制限](ec2-resource-limits.md#port-25-throttle)を参照してください。
------
#### [ Console ]
**セキュリティグループを作成するには**
1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。
1. ナビゲーションペインで、[**Security Groups**] を選択してください。
1. **[セキュリティグループの作成]** を選択してください。
1. セキュリティグループの分かりやすい名前と簡単な説明を入力します。セキュリティグループの作成後に名前と説明を変更することはできません。
1. **[VPC]** で、Amazon EC2 インスタンスを実行する VPC を選択します。
1. (オプション) インバウンドルールを追加するには、**[インバウンドルール]** を選択します。ルールごとに、**[ルールの追加]** を選択し、プロトコル、ポート、および送信元を指定します。例えば、SSH トラフィックを許可するには、**[タイプ]** に **[SSH]** を選択し、**[送信元]** にコンピュータまたはネットワークのパブリック IPv4 アドレスを指定します。
1. (オプション) アウトバウンドルールを追加するには、**[アウトバウンドルール]** を選択します。ルールごとに、**[ルールの追加]** を選択し、プロトコル、ポート、および送信先を指定します。追加しない場合は、デフォルトのルールをそのまま使用でき、すべてのアウトバウンドトラフィックを許可します。
1. (オプション) タグを追加するには、**[Add new tag]** (新しいタグを追加) を選択し、そのタグのキーと値を入力します。
1. [**セキュリティグループの作成**] を選択します。
------
#### [ AWS CLI ]
**セキュリティグループを作成するには**
次の [create-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html) コマンドを使用します。
```
aws ec2 create-security-group \
--group-name my-security-group \
--description "my security group" \
--vpc-id vpc-1234567890abcdef0
```
ルールを追加する例については、「[セキュリティグループルールの設定](changing-security-group.md#add-remove-security-group-rules)」を参照してください。
------
#### [ PowerShell ]
**セキュリティグループを作成するには**
[New-EC2SecurityGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2SecurityGroup.html) コマンドレットを使用します。
```
New-EC2SecurityGroup `
-GroupName my-security-group `
-Description "my security group" `
-VpcId vpc-1234567890abcdef0
```
ルールを追加する例については、「[セキュリティグループルールの設定](changing-security-group.md#add-remove-security-group-rules)」を参照してください。
------
# Amazon EC2 インスタンスのセキュリティグループの変更
Amazon EC2 インスタンスのセキュリティグループは、インスタンスの起動時に指定できます。インスタンスを起動した後、セキュリティグループを追加または削除することができます。また、関連付けられたセキュリティグループのセキュリティグループルールは、いつでも追加、削除、編集できます。
セキュリティグループはネットワークインターフェイスに関連付けられます。セキュリティグループを追加または削除すると、プライマリネットワークインターフェイスに関連付けられているセキュリティグループが変更されます。セカンダリネットワークインターフェイスに関連付けられているセキュリティグループも変更できます。詳細については、[ネットワークインターフェイス属性の変更](modify-network-interface-attributes.md)を参照してください。
**Topics**
+ [セキュリティグループの追加または削除](#add-remove-instance-security-groups)
+ [セキュリティグループルールの設定](#add-remove-security-group-rules)
## セキュリティグループの追加または削除
インスタンスを起動した後、関連付けられているセキュリティグループのリストに対し、セキュリティグループを追加または削除できます。複数のセキュリティグループをインスタンスに関連付けると、各セキュリティグループのルールが効率的に集約され、1 つのルールセットが作成されます。Amazon EC2 はこのルールセットを使用して、トラフィックを許可するかを判断します。
**要件**
+ インスタンスは、`running` または `stopped` 状態である必要があります。
------
#### [ Console ]
**インスタンスのセキュリティグループを変更するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**インスタンス**] を選択します。
1. インスタンスを選択し、[**アクション**]、[**セキュリティ**]、[**セキュリティグループの変更**] の順に選択します。
1. [**関連付けられたセキュリティグループ**] で、リストからセキュリティグループを選択し、[**セキュリティグループを追加**] を選択します。
すでに関連付けられているセキュリティグループを削除するには、そのセキュリティグループで [**削除**] を選択します。
1. **[保存]** を選択します。
------
#### [ AWS CLI ]
**インスタンスのセキュリティグループを変更するには**
次の [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) コマンドを使用します。
```
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--groups sg-1234567890abcdef0
```
------
#### [ PowerShell ]
**インスタンスのセキュリティグループを変更するには**
[Edit-EC2InstanceAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2InstanceAttribute.html) コマンドレットを使用します。
```
Edit-EC2InstanceAttribute `
-InstanceId i-1234567890abcdef0 `
-Group sg-1234567890abcdef0
```
------
## セキュリティグループルールの設定
セキュリティグループを作成したら、そのセキュリティグループルールを追加、更新、削除できます。ルールを追加、更新、または削除すると、その変更は、セキュリティグループに関連付けられているリソースに自動的に適用されます。
セキュリティグループに追加できるルールの例については、[さまざまなユースケースのセキュリティグループのルール](security-group-rules-reference.md)を参照してください。
**必要なアクセス許可**
作業を開始する前に、必要なアクセス許可があることを確認してください。詳細については、[例: セキュリティグループの操作](iam-policies-ec2-console.md#ex-security-groups)を参照してください。
**プロトコルとポート**
+ コンソールでは、事前定義されたタイプを選択すると、**プロトコル**と**ポート範囲**が指定されます。ポート範囲を入力するには、**[カスタム TCP]** または **[カスタム UDP]** のいずれかのカスタムタイプを選択する必要があります。
+ AWS CLI では、`--protocol` オプションおよび `--port` オプションを使用して、単一のポートを持つ単一のルールを追加できます。複数のルール、またはポート範囲を持つルールを追加するには、代わりに `--ip-permissions` オプションを使用します。
**送信元と送信先**
+ コンソールでは、インバウンドルールの送信元またはアウトバウンドルールの送信先として、以下を指定できます。
+ **[カスタム]** – IPv4 CIDR ブロック、IPv6 CIDR ブロック、セキュリティグループ、またはプレフィックスリスト。
+ **[Anywhere-IPv4]** – 0.0.0.0/0 IPv4 CIDR ブロック。
+ **[Anywhere-IPv6]** – ::/0 IPv6 CIDR ブロック。
+ **[マイ IP]** – ローカルコンピュータのパブリック IPv4 アドレス。
+ AWS CLI では、`--cidr` オプションを使用して IPv4 CIDR ブロックを指定するか、`--source-group` オプションを使用してセキュリティグループを指定できます。プレフィックスリストまたは IPv6 CIDR ブロックを指定するには、`--ip-permissions` オプションを使用します。
**警告**
ポート 22 (SSH) または 3389 (RDP) のインバウンドルールを追加する場合は、特定の IP アドレス、またはインスタンスへのアクセスを必要とするアドレスの範囲のみを許可することを強くお勧めします。**[Anywhere-IPv4]** を選択すると、すべての IPv4 アドレスからのトラフィックが、指定されたプロトコルを使用してインスタンスにアクセスできるようになります。**[Anywhere-IPv6]** を選択すると、すべての IPv6 アドレスからのトラフィックが、指定されたプロトコルを使用してインスタンスにアクセスできるようになります。
------
#### [ Console ]
**セキュリティグループのルールを設定するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. ナビゲーションペインで、[**Security Groups**] を選択します。
1. セキュリティグループを選択します。
1. インバウンドルールを編集するには、**[アクション]** または **[インバウンドルール]** タブから **[インバウンドルールを編集]** を選択します。
1. ルールを追加するには、**[ルールを追加]** を選択し、ルールのタイプ、プロトコル、ポート、および送信元を入力します。
タイプが TCP または UDP の場合は、許可するポート範囲を入力する必要があります。カスタムの ICMP の場合は、[**プロトコル**] から ICMP タイプ名を選択し、該当するものがある場合は [**ポート範囲**] からコード名を選択します。その他のタイプについては、プロトコルとポート範囲は自動的に設定されます。
1. ルールを更新するには、必要に応じてプロトコル、説明、送信元を変更します。ただし、送信元のタイプを変更することはできません。例えば、送信元が IPv4 CIDR ブロックの場合、IPv6 CIDR ブロック、プレフィックスリスト、またはセキュリティグループを指定することはできません。
1. ルールを削除するには、**[削除]** ボタンを選択します。
1. アウトバウンドルールを編集するには、**[アクション]** または **[アウトバウンドルール]** タブから **[アウトバウンドルールを編集]** を選択します。
1. ルールを追加するには、**[ルールを追加]** を選択し、ルールのタイプ、プロトコル、ポート、および送信先を入力します。オプションとして説明を入力することもできます。
タイプが TCP または UDP の場合は、許可するポート範囲を入力する必要があります。カスタムの ICMP の場合は、[**プロトコル**] から ICMP タイプ名を選択し、該当するものがある場合は [**ポート範囲**] からコード名を選択します。その他のタイプについては、プロトコルとポート範囲は自動的に設定されます。
1. ルールを更新するには、必要に応じてプロトコル、説明、送信元を変更します。ただし、送信元のタイプを変更することはできません。例えば、送信元が IPv4 CIDR ブロックの場合、IPv6 CIDR ブロック、プレフィックスリスト、またはセキュリティグループを指定することはできません。
1. ルールを削除するには、**[削除]** ボタンを選択します。
1. [**ルールの保存**] を選択します。
------
#### [ AWS CLI ]
**セキュリティグループルールを追加するには**
[authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html) コマンドを使用して、インバウンドルールを追加します。次の例では、指定されたプレフィックスリストの CIDR ブロックからの、インバウンド SSH トラフィックを許可します。
```
aws ec2 authorize-security-group-ingress \
--group-id sg-1234567890abcdef0 \
--ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,PrefixListIds=[{PrefixListId=pl-f8a6439156EXAMPLE}]'
```
[authorize-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-egress.html) コマンドを使用して、アウトバウンドルールを追加します。次の例では、指定されたセキュリティグループを持つインスタンスへの、ポート 80 でのアウトバウンド TCP トラフィックを許可します。
```
aws ec2 authorize-security-group-egress \
--group-id sg-1234567890abcdef0 \
--ip-permissions 'IpProtocol=tcp,FromPort=80,ToPort=80,UserIdGroupPairs=[{GroupId=sg-0aad1c26bb6EXAMPLE}]'
```
**セキュリティグループルールを削除するには**
インバウンドルールを削除するには、次の [revoke-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-ingress.html) コマンドを使用します。
```
aws ec2 revoke-security-group-egress \
--group id sg-1234567890abcdef0 \
--security-group-rule-ids sgr-09ed298024EXAMPLE
```
アウトバウンドルールを削除するには、次の [revoke-security-group-egress](https://docs.aws.amazon.com/cli/latest/reference/ec2/revoke-security-group-egress.html) コマンドを使用します。
```
aws ec2 revoke-security-group-ingress \
--group id sg-1234567890abcdef0 \
--security-group-rule-ids sgr-0352250c1aEXAMPLE
```
**セキュリティグループのルールを変更するには**
[modify-security-group-rules](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-security-group-rules.html) コマンドを使用します。次の例では、指定されたセキュリティグループルールの IPv4 CIDR ブロックを変更します。
```
aws ec2 modify-security-group-rules \
--group id sg-1234567890abcdef0 \
--security-group-rules 'SecurityGroupRuleId=sgr-09ed298024EXAMPLE,SecurityGroupRule={IpProtocol=tcp,FromPort=80,ToPort=80,CidrIpv4=0.0.0.0/0}'
```
------
#### [ PowerShell ]
**セキュリティグループルールを追加するには**
インバウンドルールを追加するには、[Grant-EC2SecurityGroupIngress](https://docs.aws.amazon.com/powershell/latest/reference/items/Grant-EC2SecurityGroupIngress.html) コマンドレットを使用します。次の例では、指定されたプレフィックスリストの CIDR ブロックからの、インバウンド SSH トラフィックを許可します。
```
$plid = New-Object -TypeName Amazon.EC2.Model.PrefixListId
$plid.Id = "pl-f8a6439156EXAMPLE"
Grant-EC2SecurityGroupIngress `
-GroupId sg-1234567890abcdef0 `
-IpPermission @{IpProtocol="tcp"; FromPort=22; ToPort=22; PrefixListIds=$plid}
```
アウトバウンドルールを追加するには、[Grant-EC2SecurityGroupEgress](https://docs.aws.amazon.com/powershell/latest/reference/items/Grant-EC2SecurityGroupEgress.html) コマンドレットを使用します。次の例では、指定されたセキュリティグループを持つインスタンスへの、ポート 80 でのアウトバウンド TCP トラフィックを許可します。
```
$uigp = New-Object -TypeName Amazon.EC2.Model.UserIdGroupPair
$uigp.GroupId = "sg-0aad1c26bb6EXAMPLE"
Grant-EC2SecurityGroupEgress `
-GroupId sg-1234567890abcdef0 `
-IpPermission @{IpProtocol="tcp"; FromPort=80; ToPort=80; UserIdGroupPairs=$uigp}
```
**セキュリティグループルールを削除するには**
インバウンドルールを削除するには、[Revoke-EC2SecurityGroupIngress](https://docs.aws.amazon.com/powershell/latest/reference/items/Revoke-EC2SecurityGroupIngress.html) コマンドレットを使用します。
```
Revoke-EC2SecurityGroupIngress `
-GroupId sg-1234567890abcdef0 `
-SecurityGroupRuleId sgr-09ed298024EXAMPLE
```
アウトバウンドルールを削除するには、[Revoke-EC2SecurityGroupEgress](https://docs.aws.amazon.com/powershell/latest/reference/items/Revoke-EC2SecurityGroupEgress.html) コマンドレットを使用します。
```
Revoke-EC2SecurityGroupEgress `
-GroupId sg-1234567890abcdef0 `
-SecurityGroupRuleId sgr-0352250c1aEXAMPLE
```
**セキュリティグループのルールを変更するには**
[Edit-EC2SecurityGroupRule](https://docs.aws.amazon.com/powershell/latest/reference/items/Edit-EC2SecurityGroupRule.html) コマンドレットを使用します。次の例では、指定されたセキュリティグループルールの IPv4 CIDR ブロックを変更します。
```
$sgrr = New-Object -TypeName Amazon.EC2.Model.SecurityGroupRuleRequest
$sgrr.IpProtocol = "tcp"
$sgrr.FromPort = 80
$sgrr.ToPort = 80
$sgrr.CidrIpv4 = "0.0.0.0/0"
$sgr = New-Object -TypeName Amazon.EC2.Model.SecurityGroupRuleUpdate
$sgr.SecurityGroupRuleId = "sgr-09ed298024EXAMPLE"
$sgr.SecurityGroupRule = $sgrr
Edit-EC2SecurityGroupRule `
-GroupId sg-1234567890abcdef0 `
-SecurityGroupRule $sgr
```
------
# Amazon EC2 セキュリティグループの削除
Amazon EC2 インスタンスで使用するために作成したセキュリティグループの使用が済んだら、削除できます。
**要件**
+ セキュリティグループをインスタンスまたはネットワークインターフェイスに関連付けることはできません。
+ 別のセキュリティグループのルールでセキュリティグループを参照することはできません。
------
#### [ Console ]
**セキュリティグループを削除するには**
1. Amazon EC2 コンソールの [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) を開いてください。
1. (オプション) セキュリティグループがインスタンスに関連付けられていないことを確認するには、以下の操作を実行します。
1. ナビゲーションペインで、[**Security Groups**] を選択してください。
1. 削除するセキュリティグループの ID をコピーします。
1. ナビゲーションペインで、[**インスタンス**] を選択してください。
1. 検索バーで、**[セキュリティグループ ID が次と等しい]** フィルターを追加し、セキュリティグループの ID を貼り付けます。結果がない場合、セキュリティグループはインスタンスに関連付けられていません。それ以外の場合、セキュリティグループを削除するには、セキュリティグループの関連付けを解除する必要があります。
1. ナビゲーションペインで、[**Security Groups**] を選択してください。
1. セキュリティグループを選択して、**[アクション]**、**[セキュリティグループを削除]** を選択します。
1. 複数のセキュリティグループを選択した場合は、確認を求められます。一部のセキュリティグループを削除できない場合は、削除されるかどうかを示す、各セキュリティグループのステータスが表示されます。削除を確認するには、「**Delete**」と入力します。
1. **[削除]** を選択します。
------
#### [ AWS CLI ]
**セキュリティグループを削除するには**
次の [delete-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/delete-security-group.html) コマンドを使用します。
```
aws ec2 delete-security-group --group-id sg-1234567890abcdef0
```
------
#### [ PowerShell ]
**セキュリティグループを削除するには**
[Remove-EC2SecurityGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Remove-EC2SecurityGroup.html) コマンドレットを使用します。
```
Remove-EC2SecurityGroup -GroupId sg-1234567890abcdef0
```
------
# Amazon EC2 セキュリティグループの接続の追跡
セキュリティグループは、接続追跡を使用してインスタンスを出入りするトラフィックに関する情報を追跡します。ルールはトラフィックの接続の状態に基づいて適用され、トラフィックを許可するか拒否するかが判断されます。このアプローチでは、セキュリティグループはステートフルです。これは、セキュリティグループのアウトバウンドルールにかかわらず、インバウンドトラフィックに対するレスポンスがインスタンスから送信されることを許可することを意味します。逆も同じです。
例えば、自宅のコンピュータからインスタンスに対し netcat や同様の ICMP コマンドを開始する場合を考えます。この時、インバウンドセキュリティグループは、ICMP トラフィックを許可しているとします。接続に関する情報 (ポート情報を含む) が追跡されます。コマンドに対するインスタンスからのレスポンストラフィックは、新しいリクエストではなく確立済みの接続として追跡されます。また、セキュリティグループのアウトバウンドルールが、アウトバウンドの ICMP トラフィックを制限している場合でも、このトラフィックはインスタンスから外部に出力されることが許されます。
TCP、UDP、または ICMP 以外のプロトコルの場合は、IP アドレスとプロトコル番号のみが追跡されます。インスタンスが別のホストにトラフィックを送信し、そのホストが 600 秒以内に同じタイプのトラフィックをインスタンスに送信した場合、インスタンスのセキュリティグループはインバウンドセキュリティグループルールに関係なく、そのトラフィックを受け入れます。そのトラフィックが元のトラフィックのレスポンストラフィックとみなされるからです。
セキュリティグループルールを変更しても、そのルールで追跡された接続がすぐに中断されることはありません。セキュリティグループは、既存の接続がタイムアウトするまで引き続きパケットを許可します。トラフィックをすぐに中断するか、追跡状態に関係なくすべてのトラフィックをファイアウォールルールの対象にするには、サブネットにネットワーク ACL を使用します。ネットワーク ACL はステートレスであるため、レスポンスのトラフィックを自動的には許可しません。いずれかの方向のトラフィックをブロックするネットワーク ACL を追加すると、既存の接続が切断されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[ネットワーク ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
**注記**
セキュリティグループは、「VPC \$12 IP アドレス」(「*Amazon Route 53 デベロッパーガイド*」の「[Amazon Route 53 Resolver とは](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)」を参照)、または「AmazonProvidedDNS」(「*Amazon Virtual Private Cloud ユーザーガイド*」の「[DHCP オプションセットの使用](https://docs.aws.amazon.com/vpc/latest/userguide/DHCPOptionSet.html)」を参照) と呼ばれることもある Route 53 Resolver から送受信される DNS トラフィックに影響を及ぼすことはありません。Route 53 Resolver で DNS リクエストをフィルタリングしたい場合は、Route 53 Resolver DNS ファイアウォールを有効にできます (「*Amazon Route 53 デベロッパーガイド*」の「[Route 53 Resolver DNS ファイアウォール](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)」を参照)。
## 追跡されていない接続
すべてのトラフィックフローが追跡されるわけではありません。セキュリティグループのルールがすべてのトラフィック (0.0.0.0/0 または ::/0) の TCP または UDP フローを許可していて、片方の方向には任意のポート (0～65535) のすべての応答トラフィック (0.0.0.0/0 または ::/0) を許可するルールがある場合、そのトラフィックフローは[自動的に追跡される接続](#automatic-tracking)の一部でない限り追跡されません。追跡されていないフローのレスポンストラフィックは、追跡情報ではなく、レスポンストラフィックを許可するインバウンドルールまたはアウトバウンドルールに基づいて許可されます。
追跡されていないトラフィックフローは、そのフローを有効にするルールが削除または変更されるとすぐに中断されます。例えば、オープン (0.0.0.0/0) のアウトバウンドルールがあり、インスタンスへのすべて(0.0.0.0/0) のインバウンドの SSH (TCP ポート 22) トラフィックを許可するルールを削除した場合 (または接続を許可しないように変更した場合)、インスタンスへの既存の SSH 接続はすぐに中断されます。接続はそれまで追跡されていないため、この変更によって接続が切断されます。一方、最初に細かく SSH 接続を許可する (つまり、接続を追跡する) インバウンドルールがある場合、現在の SSH クライアントのアドレスからの新しい接続を許可しないようにルールを変更しても、既存の SSH 接続は追跡対象であるため中断されません。
## 自動的に追跡される接続
セキュリティ グループの構成で追跡が必要ない場合でも、次の方法で行われた接続は自動的に追跡されます。
+ Egress-Only インターネットゲートウェイ
+ Global Accelerator アクセラレーター
+ NAT ゲートウェイ
+ Network Firewall ファイアウォールのエンドポイント
+ Network Load Balancer
+ AWS PrivateLink (インターフェイス VPC エンドポイント)
+ AWS Lambda (Hyperplane Elastic Network Interface)
+ DynamoDB のゲートウェイエンドポイント – DynamoDB への各接続は 2 つの conntrack エントリを消費します。
## 追跡できる接続の最大数
Amazon EC2 では、インスタンスごとに追跡できる接続の最大数が定義されています。追跡が最大数に達すると、新しい接続が確立されることはないため、送受信されるパケットはすべてドロップされます。この場合、パケットを送受信するアプリケーションは正しく通信できません。`conntrack_allowance_available` ネットワークパフォーマンスメトリクスを使用して、そのインスタンスタイプでまだ利用可能な接続トラッキングの数を判断します。
インスタンスのネットワークトラフィックが追跡可能な接続の最大数を超えたために、パケットがドロップされたかどうかを判断するには、ネットワークパフォーマンスメトリクス `conntrack_allowance_exceeded` を参照します。詳細については、[EC2 インスタンスでの ENA 設定のネットワークパフォーマンスのモニタリング](monitoring-network-performance-ena.md)を参照してください。
Elastic Load Balancing を実行している際にインスタンスごとに追跡できる接続の最大数を超える場合は、ロードバランサーに登録されているインスタンスの数、あるいは登録されているインスタンスのサイズのいずれかをスケールすることをお勧めします。
## 接続追跡のベストプラクティス
トラフィックが特定のネットワークインターフェースからインスタンスに入り、別のネットワークインターフェースから外に出る、非対称ルーティングでは、フローを追跡した場合に、インスタンスが達成できるピークパフォーマンスが低下する可能性があります。
セキュリティグループで接続追跡が有効になっている場合にピークパフォーマンスを維持して接続管理を最適化するには、次の設定をお勧めします。
+ 可能であれば、非対称ルーティングトポロジーは避けてください。
+ フィルタリングにセキュリティグループを使用する代わりに、ネットワーク ACL を使用します。
+ 接続追跡でセキュリティグループを使用する必要がある場合は、可能な限り短い接続追跡のアイドル状態タイムアウトを設定します。接続追跡のアイドル状態タイムアウトの詳細については、次のセクションを参照してください。
+ Nitrov6 インスタンスではデフォルトのタイムアウト時間が短いため、存続期間の長い接続 (データベース接続プール、永続的な HTTP 接続、ストリーミングワークロードなど) を持つアプリケーションは、インスタンス起動時に適切な `TcpEstablishedTimeout` 値を設定する必要があります。
+ 存続期間の長い接続の場合は、接続を開いたままにして追跡状態を維持するために TCP キープアライブを 5 分未満の間隔で送信するように設定します。これにより、アイドルタイムアウトによる接続のドロップを防ぎ、接続の再確立のオーバーヘッドを削減できます。
Nitro システムによるパフォーマンスチューニングの詳細については、[Nitro System のパフォーマンスチューニングに関する考慮事項](ena-nitro-perf.md)を参照してください。
## アイドル接続追跡タイムアウト
セキュリティグループは、確立された各接続を追跡し、リターンパケットが期待どおりに配信されることを保証します。インスタンスごとに追跡できる接続の最大数があります。接続がアイドル状態のままになると、接続追跡が使い果たされることで接続が追跡されなくなり、また、パケットがドロップされる原因となります。Elastic Network Interface では、アイドル接続の追跡にタイムアウトを設定できます。
**注記**
この機能は、[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)でのみ使用できます。Nitrov6 世代インスタンスでアプリケーションをテストするには、本番環境にデプロイする前に、`350` 2 番目のデフォルトの接続追跡タイムアウトを短くする必要があります。
設定可能なタイムアウトは 3 つ用意されています。
+ **TCP 確立タイムアウト**: 確立された状態のアイドル TCP 接続のタイムアウト (秒単位)。
+ 最小: `60` 秒
+ 最大: `432000` 秒
+ デフォルト: [Nitrov6](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) インスタンスタイプ (P6e-GB200 を除く) の場合、`350` 秒。その他のインスタンスタイプ (P6e-GB200 を含む) の場合、`432000` 秒。
+ 推奨: `432000` 秒未満
+ **UDP タイムアウト**: 単一方向、または 1 つのリクエスト-レスポンストランザクションのみのトラフィックが発生した、アイドル状態にある UDP フローのタイムアウト (秒単位)。
+ 最小: `30` 秒
+ 最大: `60` 秒
+ デフォルト: `30` 秒
+ **UDP ストリームタイムアウト**: 複数のリクエスト-レスポンストランザクションが発生したストリームとして分類される、アイドル状態にある UDP フローのタイムアウト (秒単位)。
+ 最小: `60` 秒
+ 最大: `180` 秒
+ デフォルト: `180` 秒
以下のいずれかに当てはまる場合は、デフォルトのタイムアウトの変更が必要になる場合があります。
+ [Amazon EC2 のネットワークパフォーマンスメトリクスを使用して追跡接続をモニタリング](monitoring-network-performance-ena.md)している場合は、*conntrack\$1allowance\$1exceeded* および *conntrack\$1allowance\$1available* メトリクスにより、ドロップされたパケットと追跡された接続使用率をモニタリングできるようになります。これにより、スケールアップまたはスケールアウトアクションにより EC2 インスタンスの容量を事前に管理し、パケットのドロップが発生する前にネットワーク接続の需要を満たすことができます。EC2 インスタンスで *conntrack\$1allowance\$1exceeded* のドロップが観測された場合は、不適切なクライアントやネットワークのミドルボックスが原因で TCP/UDP セッションの使用期間が長くなりすぎることを考慮して、TCP 確立のタイムアウトを低く設定すると、メリットが得られる場合があります。
+ 通常、ロードバランサーまたはファイアウォールの TCP Established アイドルタイムアウトは、60 分～90 分の範囲に設定されています。ネットワークファイアウォールなどのアプライアンスからの、非常に多くの (10万件を超える) 接続を処理することが予想されるワークロードを実行している場合は、EC2 ネットワークインターフェイスでも同様のタイムアウトを設定することをお勧めします。
+ 非対称ルーティングトポロジを使用するワークロードを実行している場合は、TCP 確立アイドルタイムアウトを 60 秒に設定することをお勧めします。
+ 主に UDP を使用してリクエストを処理するサービス (例えば DNS、SIP、SNMP、Syslog、Radius) など、接続数が多いワークロードを実行している場合、「UDP ストリーム」のタイムアウトを 60 秒に設定すると、既存の容量のスケール対パフォーマンス比が向上し、グレーな障害を防ぐことができます。
+ Network Load Balancer を経由する TCP/UDP 接続では、すべての接続が追跡されます。TCP フローのアイドルタイムアウト値は 350 秒、UDP フローのアイドルタイムアウト値は 120 秒で、インターフェイスレベルのタイムアウト値により変化します。ロードバランサーのデフォルトよりもタイムアウトを柔軟にするために、ネットワークインターフェイスレベルでタイムアウトを設定することもできます。
以下の操作を行う際には、接続追跡のタイムアウト設定のオプションが用意されています。
+ [ネットワークインターフェイスの作成](create-network-interface.md)
+ [ネットワークインターフェイス属性の変更](modify-network-interface-attributes.md)
+ [EC2 インスタンスの起動](ec2-instance-launch-parameters.md#liw-network-settings)
+ [EC2 インスタンスの起動テンプレートの作成](ec2-instance-launch-parameters.md#liw-network-settings)
## 例
次の例では、セキュリティグループに TCP および ICMP トラフィックを許可するインバウンドルールと、すべてのアウトバウンドトラフィックを許可するアウントバウンドルールがあります。
**インバウンド**
| プロトコルのタイプ | ポート番号 | ソース |
| --- | --- | --- |
| TCP | 22 (SSH) | 203.0.113.1/32 |
| TCP | 80 (HTTP) | 0.0.0.0/0 |
| TCP | 80 (HTTP) | ::/0 |
| ICMP | すべて | 0.0.0.0/0 |
**アウトバウンド**
| プロトコルのタイプ | ポート番号 | 目的地 |
| --- | --- | --- |
| すべて | すべて | 0.0.0.0/0 |
| すべて | すべて | ::/0 |
インスタンスまたはネットワークインターフェイスに対して直接ネットワーク接続を確立した場合、追跡動作は次のようになります。
+ インバウンドルールでは 203.0.113.1/32 からのトラフィックのみ許可されるため、ポート 22 のインバウンドおよびアウトバウンド TCP トラフィック (SSH) は追跡されますが、必ずしもすべての IP アドレス (0.0.0.0/0) が追跡されるとは限りません。
+ インバウンドルールとアウトバウンドルールですべての IP アドレスからのトラフィックが許可されるため、ポート 80 (HTTP) のインバウンドおよびアウトバウンド TCP トラフィックは追跡されません。
+ ICMP トラフィックは常に追跡されます。
IPv4 トラフィックのアウトバウンドルールを削除すると、ポート 80 (HTTP) のトラフィックを含めすべてのインバウンドおよびアウトバウンド IPv4 トラフィックが追跡されます。IPv6 トラフィックのアウトバウンドルールを削除すると、IPv6 トラフィックでも同じことが起きます。
# さまざまなユースケースのセキュリティグループのルール
セキュリティグループを作成し、そのセキュリティグループに関連付けられたインスタンスのロールを反映したルールを追加できます。例えば、ウェブサーバーとして構成されているインスタンスには、インバウンドの HTTP および HTTPS アクセスを許可するセキュリティグループルールが必要です。同様に、データベースのインスタンスには、データベースのタイプに対するアクセス (MySQL のポート 3306 でのアクセスなど) を許可するルールが必要です。
以下は、特定の種類のアクセスのセキュリティグループに追加できるルールの種類の例です。
**Topics**
+ [ウェブサーバールール](#sg-rules-web-server)
+ [データベースサーバールール](#sg-rules-db-server)
+ [コンピュータからのインスタンスへの接続ルール](#sg-rules-local-access)
+ [同じセキュリティグループを持つインスタンスからインスタンスに接続するためのルール](#sg-rules-other-instances)
+ [Ping/ICMP のルール](#sg-rules-ping)
+ [DNS サーバールール](#sg-rules-dns)
+ [Amazon EFS ルール](#sg-rules-efs)
+ [Elastic Load Balancing ルール](#sg-rules-elb)
手順については、「[セキュリティグループを作成する](creating-security-group.md)」および「[セキュリティグループルールの設定](changing-security-group.md#add-remove-security-group-rules)」を参照してください。
## ウェブサーバールール
次のインバウンドルールでは、任意の IP アドレスからの HTTP および HTTPS アクセスを許可します。VPC が IPv6 に対して有効になっている場合、IPv6 アドレスからインバウンド HTTP および HTTPS トラフィックを制御するルールを追加できます。
| プロトコルのタイプ | プロトコル番号 | ポート | 送信元 IP | コメント |
| --- | --- | --- | --- | --- |
| TCP | 6 | 80 (HTTP) | 0.0.0.0/0 | 任意の IPv4 アドレスからのインバウンド HTTP アクセスを許可します |
| TCP | 6 | 443 (HTTPS) | 0.0.0.0/0 | 任意の IPv4 アドレスからのインバウンド HTTPS アクセスを許可します |
| TCP | 6 | 80 (HTTP) | ::/0 | 任意の IPv6 アドレスからのインバウンド HTTP アクセスを許可します |
| TCP | 6 | 443 (HTTPS) | ::/0 | 任意の IPv6 アドレスからのインバウンド HTTPS アクセスを許可します |
## データベースサーバールール
次のインバウンドルールは、インスタンスで実行中のデータベースのタイプに応じて、データベースアクセス用に追加するルールの例です。Amazon RDS インスタンスの詳細については、[Amazon RDS ユーザーガイド](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/)を参照してください。
ソース IP には、次のいずれかを指定します。
+ ローカルネットワークの特定の IP アドレスまたは IP アドレス範囲 (CIDR ブロック表記)
+ データベースにアクセスするインスタンスのグループのセキュリティグループ ID
| プロトコルのタイプ | プロトコル番号 | ポート | コメント |
| --- | --- | --- | --- |
| TCP | 6 | 1433 (MS SQL) | Amazon RDS インスタンス上など、Microsoft SQL Server データベースにアクセスするデフォルトのポート |
| TCP | 6 | 3306 (MYSQL/Aurora) | Amazon RDS インスタンス上など、MySQL または Aurora データベースにアクセスするデフォルトのポート |
| TCP | 6 | 5439 (Redshift) | Amazon Redshift クラスターデータベースにアクセスするデフォルトのポート。 |
| TCP | 6 | 5432 (PostgreSQL) | Amazon RDS インスタンス上など、PostgreSQL データベースにアクセスするデフォルトのポート |
| TCP | 6 | 1521 (Oracle) | Amazon RDS インスタンス上など、Oracle データベースにアクセスするデフォルトのポート |
必要に応じて、データベースサーバーからのアウトバウンドトラフィックを制限できます。例えば、ソフトウェアの更新ではインターネットへのアクセスを許可し、その他のトラフィックはすべて制限することができます。最初に、すべてのアウトバンドトラフィックを許可するデフォルトのアウトバウンドルールを削除する必要があります。
| プロトコルのタイプ | プロトコル番号 | ポート | 送信先 IP | コメント |
| --- | --- | --- | --- | --- |
| TCP | 6 | 80 (HTTP) | 0.0.0.0/0 | 任意の IPv4 アドレスへのアウトバウンド HTTP アクセスを許可します |
| TCP | 6 | 443 (HTTPS) | 0.0.0.0/0 | 任意の IPv4 アドレスへのアウトバウンド HTTPS アクセスを許可します |
| TCP | 6 | 80 (HTTP) | ::/0 | (IPv6 が有効な VPC のみ) 任意の IPv6 アドレスへのアウトバウンド HTTP アクセスを許可します |
| TCP | 6 | 443 (HTTPS) | ::/0 | (IPv6 が有効な VPC のみ)、任意の IPv6 アドレスへのアウトバウンド HTTPS アクセスを許可します |
## コンピュータからのインスタンスへの接続ルール
インスタンスに接続するには、セキュリティグループに SSH アクセス (Linux インスタンスの場合) または RDP アクセス (Windows インスタンスの場合) を許可するインバウンドルールが必要です。
| プロトコルのタイプ | プロトコル番号 | ポート | 送信元 IP |
| --- | --- | --- | --- |
| TCP | 6 | 22 (SSH) | ローカルコンピュータのパブリック IPv4 アドレス、またはローカルネットワークの IP アドレスの範囲。VPC が IPv6 に対して有効で、インスタンスに IPv6 アドレスがある場合、IPv6 アドレスまたは範囲を入力できます。 |
| TCP | 6 | 3389 (RDP) | ローカルコンピュータのパブリック IPv4 アドレス、またはローカルネットワークの IP アドレスの範囲。VPC が IPv6 に対して有効で、インスタンスに IPv6 アドレスがある場合、IPv6 アドレスまたは範囲を入力できます。 |
## 同じセキュリティグループを持つインスタンスからインスタンスに接続するためのルール
同じセキュリティグループに関連付けられたインスタンスが相互に通信できるようにするには、そのためのルールを明示的に追加する必要があります。
**注記**
ミドルボックスアプライアンスを介して異なるサブネット内の 2 つのインスタンス間のトラフィックを転送するようにルートを設定するには、両方のインスタンスのセキュリティグループでインスタンス間のトラフィックがフローできるようにする必要があります。各インスタンスのセキュリティグループは、他のインスタンスのプライベート IP アドレス、または他のインスタンスを含むサブネットの CIDR 範囲を送信元として参照する必要があります。他のインスタンスのセキュリティグループを送信元として参照する場合、インスタンス間のトラフィックは許可されません。
次の表は、関連付けられたインスタンスの相互通信を可能にするセキュリティグループのインバウンドルールを示します。このルールでは、すべてのタイプのトラフィックが許可されます。
| プロトコルのタイプ | プロトコル番号 | ポート | 送信元 IP |
| --- | --- | --- | --- |
| -1 (すべて) | -1 (すべて) | -1 (すべて) | セキュリティグループの ID、または他のインスタンスを含むサブネットの CIDR 範囲 (注を参照)。 |
## Ping/ICMP のルール
**ping** コマンドは、ICMP トラフィックの一種です。インスタンスで Ping を実行するには、次のインバウンド ICMP ルールのうち 1 つを追加する必要があります。
| タイプ | プロトコル | ソース |
| --- | --- | --- |
| カスタム ICMP - IPv4 | エコーリクエスト | お使いのコンピュータのパブリック IPv4 アドレス、特定の IPv4 アドレス、または任意の場所の IPv4 あるいは IPv6 アドレス。 |
| すべての ICMP - IPv4 | IPv4 ICMP (1) | お使いのコンピュータのパブリック IPv4 アドレス、特定の IPv4 アドレス、または任意の場所の IPv4 あるいは IPv6 アドレス。 |
**ping6** コマンドを使用してインスタンスの IPv6 アドレスに ping を実行するには、次のインバウンド ICMPv6 ルールを追加する必要があります。
| タイプ | プロトコル | ソース |
| --- | --- | --- |
| すべての ICMP - IPv6 | IPv6 ICMP (58) | お使いのコンピュータの IPv6 アドレス、特定の IPv4 アドレス、または任意の場所の IPv4 あるいは IPv6 アドレス。 |
## DNS サーバールール
DNS サーバーとして EC2 インスタンスをセットアップした場合、TCP および UDP のトラフィックがポート 53 経由で DNS サーバーに到達できるようにする必要があります。
ソース IP には、次のいずれかを指定します。
+ ネットワークの IP アドレスまたは IP アドレス範囲 (CIDR ブロック表記)
+ ネットワークで、DNS サーバーにアクセスする必要がある一連のインスタンスのセキュリティグループの ID
| プロトコルのタイプ | プロトコル番号 | ポート |
| --- | --- | --- |
| TCP | 6 | 53 |
| UDP | 17 | 53 |
## Amazon EFS ルール
Amazon EC2 インスタンスで Amazon EFS ファイルシステムを使用している場合、Amazon EFS マウントターゲットに関連付けるセキュリティグループは、NFS プロトコル経由のトラフィックを許可する必要があります。
| プロトコルのタイプ | プロトコル番号 | ポート | 送信元 IP | コメント |
| --- | --- | --- | --- | --- |
| TCP | 6 | 2049 (NFS) | セキュリティグループの ID | このセキュリティグループに関連付けられたリソース (マウントターゲットを含む) からのインバウンド NFS アクセスを許可します。 |
Amazon EC2 インスタンスに Amazon EFS ファイルシステムをマウントするには、インスタンスに接続する必要があります。したがって、インスタンスに関連付けられているセキュリティグループには、ローカルコンピュータまたはローカルネットワークからのインバウンド SSH を許可するルールが必要です。
| プロトコルのタイプ | プロトコル番号 | ポート | 送信元 IP | コメント |
| --- | --- | --- | --- | --- |
| TCP | 6 | 22 (SSH) | ローカルコンピュータの IP アドレス範囲、またはネットワークの IP アドレス範囲 (CIDR ブロック表記)。 | ローカルコンピュータからのインバウンド SSH アクセスを許可します。 |
## Elastic Load Balancing ルール
EC2 インスタンスをロードバランサーに登録する場合、ロードバランサーに関連付けられたセキュリティグループは、インスタンスとの通信を許可する必要があります。詳細については、「Elastic Load Balancing ドキュメント」の次のトピックを参照してください。
+ [Application Load Balancer のセキュリティグループ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-update-security-groups.html)
+ [Network Load Balancer のセキュリティグループ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-security-groups.html)
+ [Classic Load Balancer のセキュリティグループの設定](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-vpc-security-groups.html)
# Amazon EC2 インスタンスの NitroTPM
Nitro Trusted Platform Module (NitroTPM) は[AWS Nitro System](https://aws.amazon.com//ec2/nitro/) によって提供され [TPM 2.0 仕様](https://trustedcomputinggroup.org/resource/trusted-platform-module-2-0-a-brief-introduction/)に準拠した仮想デバイスです。インスタンスの認証に使用されるアーティファクト (パスワード、証明書、暗号化キーなど) を安全に保存します。NitroTPM はキーを生成し、暗号化機能 (ハッシング、署名、暗号化、復号化など) に使用できます。
NitroTPM は*測定されたブート*を提供します。これはブートローダーとオペレーティングシステムがすべてのブートバイナリの暗号化ハッシュを作成し、それらを NitroTPM 内部プラットフォーム構成レジスタ (PCR) の以前の値と組み合わせるプロセスです。測定されたブートを使用することで、NitroTPM から署名された PCR 値を取得し、それらを使用してインスタンスのブートソフトウェアの整合性をリモートエンティティに証明することができます。これはリモート*認証*と呼ばれます。
NitroTPM を使用することで、キーおよびシークレットに特定の PCR 値をタグ付けできるため、PCR の値、つまりインスタンスの整合性が変更された場合にそれらにアクセスすることはできません。この特別な形式の条件付きアクセスは*封印および開封*と呼ばれます。[BitLocker](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/) などのオペレーティングシステムのテクノロジーはNitroTPM を使用してドライブの復号化キーを封印し、オペレーティングシステムが正しく起動し、正常な状態である場合にのみドライブを復号化できます。
NitroTPM を使用するにはNitroTPM サポート用に設定された [Amazon マシンイメージ (AMI)](AMIs.md) を選択してから、その AMI を使用して [Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)を起動する必要があります。Amazon のビルド済みの AMI を選択できるほか、自分で作成することもできます。
**料金**
NitroTPM を使用しても追加コストはかかりません。お客様は使用した基本リソースに対してのみ、料金を支払います。
**Topics**
+ [要件](enable-nitrotpm-prerequisites.md)
+ [NitroTPM 用の Linux AMI の有効化](enable-nitrotpm-support-on-ami.md)
+ [AMI が NitroTPM に対して有効になっていることを確認する](verify-nitrotpm-support-on-ami.md)
+ [NitroTPM の使用を有効化または停止する](nitrotpm-instance.md)
+ [インスタンスが NitroTPM に対して有効になっていることを検証する](verify-nitrotpm-support-on-instance.md)
+ [公開承認キーを取得する](retrieve-ekpub.md)
# Amazon EC2 インスタンスで NitroTPM を使用するための要件
NitroTPM を有効にしたインスタンスを起動するには以下の要件を満たしている必要があります。
**Topics**
+ [AMI](#nitrotpm-ami)
+ [インスタンスのタイプ](#nitrotpm-instancetypes)
+ [考慮事項](#nitrotpm-considerations)
## AMI
AMI では NitroTPM が有効になっている必要があります。
**Linux AMI**
事前設定済みの AMI はありません。独自の AMI を設定する必要があります。詳細については「[NitroTPM 用の Linux AMI の有効化](enable-nitrotpm-support-on-ami.md)」を参照してください。
**Windows AMI**
Microsoft キーを使用して NitroTPM および UEFI Secure Boot 用に事前設定された AWS Windows AMIを見つけるには、「*AWSWindows AMI リファレンス*」の「[NitroTPM と UEFI Secure Boot で設定された Windows Server AMI を見つける](https://docs.aws.amazon.com/ec2/latest/windows-ami-reference/ami-windows-tpm.html#ami-windows-tpm-find)」をご覧ください。
**注記**
**オペレーティングシステム** - AMI にはTPM 2.0 Command Response Buffer (CRB) ドライバーを搭載したオペレーティングシステムが含まれている必要があります。現在のほとんどのオペレーティングシステムにはTPM 2.0 CRB ドライバーが含まれています。
**UEFI ブートモード** — AMI が UEFI ブートモード用に設定されている必要があります。詳細については「[Amazon EC2 インスタンスの UEFI 安全ブート](uefi-secure-boot.md)」を参照してください。
## インスタンスのタイプ
次の仮想化インスタンスタイプのいずれかを使用する必要があります。
+ **汎用**: M5、M5a、M5ad、M5d、M5dn、M5n、M5zn、M6a、M6g、M6gd、M6i、M6id、M6idn、M6in、M7a、M7g、M7gd、M7i、M7i-flex、M8a、M8azn、M8g、M8gb、M8gd、M8gn、M8i、M8id、M8i-flex、T3、T3a、T4g
+ **コンピューティング最適化**: C5、C5a、C5ad、C5d、C5n、C6a、C6g、C6gd、C6gn、C6i、C6id、C6in、C7a、C7g、C7gd、C7gn、C7i、C7i-flex、C8a、C8g、C8gb、C8gd、C8gn、C8i、C8id、C8i-flex
+ **メモリ最適化**: R5、R5a、R5ad、R5b、R5d、R5dn、R5n、R6a、R6g、R6gd、R6i、R6id、R6idn、R6in、R7a、R7g、R7gd、R7i、R7iz、R8a、R8g、R8gb、R8gd、R8gn、R8i、R8id、R8i-flex、U7i-6tb、U7i-8tb、U7i-12tb、U7in-16tb、U7in-24tb、U7in-32tb、X2idn、X2iedn、X2iezn、X8g、X8aedz、X8i、z1d
+ **ストレージ最適化**: D3、D3en、I3en、I4i、I7i、I7ie、I8g、I8ge、Im4gn
+ **高速コンピューティング**: F2、G4dn、G5、G6、G6e、G6f、Gr6、Gr6f、G7e、Inf1、Inf2、P5、P5e、P5en、P6-B200、P6-B300、Trn2、Trn2u
+ **ハイパフォーマンスコンピューティング: **Hpc6a、Hpc6id、Hpc8a
## 考慮事項
以下の考慮事項はNitroTPM を使用する場合に適用されます。
+ NitroTPM が有効な AMI を使用してインスタンスを起動した後、インスタンスタイプを変更する場合は選択した新しいインスタンスタイプも NitroTPM をサポートしている必要があります。
+ NitrotPM ベースキーで暗号化された BitLocker ボリュームはオリジナルインスタンスでのみ使用できます。
+ NitroTPM 状態は Amazon EC2 コンソールには表示されません。
+ NitroTPM 状態は [Amazon EBS スナップショット](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html)には含まれていません。
+ NitroTPM 状態は [VM Import/Export](https://docs.aws.amazon.com/vm-import/latest/userguide/) イメージには含まれていません。
+ NitroTPM はAWS Outposts、Local Zones、または Wavelength Zone ではサポートされていません。
# NitroTPM 用の Linux AMI の有効化
インスタンスの NitroTPM を有効にするにはNitroTPM が有効な AMI を使用してインスタンスを起動する必要があります。Linux AMI を登録するときに、Linux AMI に NitroTPM サポートを設定する必要があります。NitroTPM サポートを後で設定することはできません。
NitroTPM サポートのために事前設定されている Windows AMI のリストについては「[Amazon EC2 インスタンスで NitroTPM を使用するための要件](enable-nitrotpm-prerequisites.md)」を参照してください。
[RegisterImage](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RegisterImage.html) API を使用して NitroTPM を設定して AMI を作成する必要があります。Amazon EC2 コンソールまたは VM Import/Export を使用することはできません。
**NitroTPM 用の Linux AMI を有効にするには**
1. 必要な Linux AMI を使用して一時インスタンスを起動します。ルートボリュームの ID を書き留めます。この ID はコンソールのインスタンスの **[ストレージ] **タブにあります。
1. インスタンスが `running` 状態になったら、インスタンスのルートボリュームのスナップショットを作成します。詳細については、「[EBS ボリュームのスナップショットを作成する](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-create-snapshot.html)」を参照してください。
1. 作成したスナップショットを AMI として登録します。ブロックデバイスマッピングで、ルートボリューム用に作成したスナップショットを指定します。
[register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) コマンドの例を次に示します。`--tpm-support` で、`v2.0` を指定します。`--boot-mode` で、`uefi` を指定します。
```
aws ec2 register-image \
--name my-image \
--boot-mode uefi \
--architecture x86_64 \
--root-device-name /dev/xvda \
--block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-0abcdef1234567890} \
--tpm-support v2.0
```
[Register-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Register-EC2Image.html) コマンドレットの例を次に示します。
```
$block = @{SnapshotId=snap-0abcdef1234567890}
Register-EC2Image `
-Name my-image `
-Architecture "x86_64" `
-RootDeviceName /dev/xvda `
-BlockDeviceMapping @{DeviceName="/dev/xvda";Ebs=$block} `
-BootMode Uefi `
-TpmSupport V20
```
1. ステップ 1 で起動した一時インスタンスを終了します。
# AMI が NitroTPM に対して有効になっていることを確認する
インスタンスの NitroTPM を有効にするにはNitroTPM が有効な AMI を使用してインスタンスを起動する必要があります。イメージを記述して、NitroTPM で有効になっていることを確認できます。AMI 所有者の場合は、`tpmSupport` イメージ属性を記述できます。
Amazon EC2 コンソールには、`TpmSupport` は表示されません。
------
#### [ AWS CLI ]
**NitroTPM が有効になっていることを確認するには**
[describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) コマンドを使用します。
```
aws ec2 describe-images \
--image-ids ami-0abcdef1234567890 \
--query Images[*].TpmSupport
```
NitroTPM が AMI に対して有効になっている場合、出力は次のとおりです。TPM が有効になっていない場合、出力は空です。
```
[
"v2.0"
]
```
また、AMI 所有者の場合は、[describe-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-image-attribute.html) コマンドと `tpmSupport` 属性を使用できます。
```
aws ec2 describe-image-attribute \
--image-id ami-0abcdef1234567890 \
--attribute tpmSupport
```
以下は出力の例です。
```
{
"ImageId": "ami-0abcdef1234567890",
"TpmSupport": {
"Value": "v2.0"
}
}
```
**NitroTPM が有効になっている AMI を検索するには**
次の例では、NitroTPM が有効になっている AMI の ID が一覧表示されています。
```
aws ec2 describe-images \
--owners self \
--filters Name=tpm-support,Values=v2.0 \
--query Images[].ImageId
```
------
#### [ PowerShell ]
**NitroTPM が有効になっていることを確認するには**
[Get-EC2Image](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Image.html) コマンドレットを使用します。
```
Get-EC2Image `
-ImageId ami-0abcdef1234567890 | Select TpmSupport
```
NitroTPM が AMI に対して有効になっている場合、出力は次のとおりです。TPM が有効になっていない場合、出力は空です。
```
TpmSupport
----------
v2.0
```
または、AMI 所有者の場合は、[Get-EC2ImageAttribute](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2ImageAttribute.html) コマンドレットと `tpmSupport` 属性を使用できます。
```
Get-EC2ImageAttribute `
-ImageId ami-0abcdef1234567890 `
-Attribute tpmSupport
```
**NitroTPM が有効になっている AMI を検索するには**
次の例では、NitroTPM が有効になっている AMI の ID が一覧表示されています。
```
Get-EC2Image `
-Owner self `
-Filter @{Name="tpm-support; Values="v2.0"} | Select ImageId
```
------
# Amazon EC2 インスタンスでの NitroTPM の使用を有効化または停止する
NitroTPM に対して Amazon EC2 インスタンスを有効にできるのは起動時のみです。NitroTPM に対してインスタンスを有効にすると、無効にすることはできません。NitroTPM を使用する必要がなくなった場合はオペレーティングシステムを設定してその使用を停止する必要があります。
**Topics**
+ [NitroTPM を有効にしてインスタンスを起動する](#launch-instance-with-nitrotpm)
+ [インスタンスでの NitroTPM の使用を停止する](#disable-nitrotpm-support-on-instance)
## NitroTPM を有効にしてインスタンスを起動する
[前提条件](enable-nitrotpm-prerequisites.md)を使用してインスタンスを起動すると、インスタンスで NitroTPM が自動的に有効になります。インスタンスで NitroTPM を有効にできるのは起動時のみです。インスタンスの起動方法についての詳細は[Amazon EC2 インスタンスの起動](LaunchingAndUsingInstances.md) を参照してください。
## インスタンスでの NitroTPM の使用を停止する
NitroTPM を有効にしてインスタンスを起動した後はそのインスタンスに対する NitroTPM を無効にすることはできません。ただし、次のツールを使用して、インスタンスで TPM 2.0 デバイスドライバーを無効にすることで、NitroTPM の使用をオペレーティングシステムで停止するよう設定できます。
+ **Linux インスタンス**の場合はtpm-tools を使用します。
+ **Windows インスタンス**の場合は TPM 管理コンソールの tpm.msc) を使用します。
デバイスドライバーを無効化する方法の詳細についてはオペレーティングシステムのドキュメントを参照してください。
# Amazon EC2 インスタンスが NitroTPM に対して有効になっていることを検証する
Amazon EC2 インスタンスが NitroTPM に対して有効であるかどうかを確認できます。インスタンスで NitroTPM サポートが有効になっている場合、コマンドは `"v2.0"` を返します。それ以外の場合、`TpmSupport` フィールドは出力に表示されません。
Amazon EC2 コンソールには `TpmSupport` フィールドは表示されません。
------
#### [ AWS CLI ]
**インスタンスが NitroTPM に対して有効になっているかどうかを検証するには**
[describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html) コマンドを使用します。
```
aws ec2 describe-instances \
--instance-ids i-1234567890abcdef0 \
--query Reservations[].Instances[].TpmSupport
```
------
#### [ PowerShell ]
**インスタンスが NitroTPM に対して有効になっているかどうかを検証するには**
[Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html) コマンドレットを使用します。
```
(Get-EC2Instance `
-InstanceId i-1234567890abcdef0).Instances.TpmSupport
```
------
## Windows インスタンスでの NitroTPM アクセスの確認
**(Windows インスタンスのみ) Windows が NitroTPM にアクセスできるかどうかを検証するには**
1. [EC2 Windows インスタンスに接続します。](connecting_to_windows_instance.md)
1. インスタンスで、tpm.msc プログラムを実行します。
**[TPM Management on Local Computer]** (ローカルコンピュータでの TPM 管理) ウィンドウが開きます。
1. **[TPM Manufacturer Information]** (TPM 製造元の情報) フィールドをチェックします。フィールドには製造元の名前とインスタンスの NitroTPM バージョンが含まれます。
![\[TPM Management on Local Computer (ローカルコンピュータ上の TPM 管理) ウィンドウおよびインスタンスに NitroTPM バージョンを示す TPM Manufacturer (TPM 製造元情報)フィールド。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/tpm-1.png)
# EC2 インスタンスの公開承認キーを取得する
インスタンスの公開承認キーは、いつでも安全に取得できます。
------
#### [ AWS CLI ]
**インスタンスの公開承認キーを取得する方法**
[get-instance-tpm-ek-pub](https://docs.aws.amazon.com/cli/latest/reference/ec2/get-instance-tpm-ek-pub.html) コマンドを使用します。
**例 1**
以下の例では、指定したインスタンスの `rsa-2048` 公開承認鍵を `tpmt` 形式で取得しています。
```
aws ec2 get-instance-tpm-ek-pub \
--instance-id i-1234567890abcdef0 \
--key-format tpmt \
--key-type rsa-2048
```
以下は出力例です。
```
{
"InstanceId": "i-01234567890abcdef",
"KeyFormat": "tpmt",
"KeyType": "rsa-2048",
"KeyValue": "AAEACwADALIAIINxl2dEhLEXAMPLEUal1yT9UtduBlILZPKh2hszFGmqAAYAgABDA
EXAMPLEAAABAOiRd7WmgtdGNoV1h/AxmW+CXExblG8pEUfNm0LOLiYnEXAMPLERqApiFa/UhvEYqN4
Z7jKMD/usbhsQaAB1gKA5RmzuhSazHQkax7EXAMPLEzDthlS7HNGuYn5eG7qnJndRcakS+iNxT8Hvf
0S1ZtNuItMs+Yp4SO6aU28MT/JZkOKsXIdMerY3GdWbNQz9AvYbMEXAMPLEPyHfzgVO0QTTJVGdDxh
vxtXCOu9GYf0crbjEXAMPLEd4YTbWdDdgOKWF9fjzDytJSDhrLAOUctNzHPCd/92l5zEXAMPLEOIFA
Ss50C0/802c17W2pMSVHvCCa9lYCiAfxH/vYKovAAE="
}
```
**例 2**
以下の例では、指定したインスタンスの `rsa-2048` 公開承認鍵を `der` 形式で取得しています。
```
aws ec2 get-instance-tpm-ek-pub \
--instance-id i-1234567890abcdef0 \
--key-format der \
--key-type rsa-2048
```
以下は出力例です。
```
{
"InstanceId": "i-1234567890abcdef0",
"KeyFormat": "der",
"KeyType": "rsa-2048",
"KeyValue": "MIIBIjANBgEXAMPLEw0BAQEFAAOCAQ8AMIIBCgKCAQEA6JF3taEXAMPLEXWH8DGZb4
JcTFuUbykRR82bQs4uJifaKSOv5NGoEXAMPLEG8Rio3hnuMowP+6xuGxBoAHWAoDlGbO6FJrMdEXAMP
LEnYUHvMO2GVLsc0a5ifl4buqcmd1FxqRL6I3FPwe9/REXAMPLE0yz5inhI7ppTbwxP8lmQ4qxch0x6
tjcZ1Zs1DP0EXAMPLERUYLQ/Id/OBU7RBNMlUZ0PGG/G1cI670Zh/RytuOdx9iEXAMPLEtZ0N2A4pYX
1+PMPK0lIOGssA5Ry03Mc8J3/3aXnOD2/ASRQ4gUBKznQLT/zTZEXAMPLEJUe8IJr2VgKIB/Ef+9gqi
8AAQIDAQAB"
}
```
------
#### [ PowerShell ]
**インスタンスの公開承認キーを取得する方法**
[Get-EC2InstanceTpmEkPub](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2InstanceTpmEkPub.html) コマンドレットを使用します。
**例 1**
以下の例では、指定したインスタンスの `rsa-2048` 公開承認鍵を `tpmt` 形式で取得しています。
```
Get-EC2InstanceTpmEkPub `
-InstanceId i-1234567890abcdef0 `
-KeyFormat tpmt `
-KeyType rsa-2048
```
**例 2**
以下の例では、指定したインスタンスの `rsa-2048` 公開承認鍵を `der` 形式で取得しています。
```
Get-EC2InstanceTpmEkPub `
-InstanceId i-1234567890abcdef0 `
-KeyFormat der `
-KeyType rsa-2048
```
------
# Amazon EC2 インスタンス構成証明
アテステーションは、信頼できるソフトウェア、ドライバー、ブートプロセスのみが Amazon EC2 インスタンスで実行されていることを任意の当事者に暗号的に証明できるプロセスです。Amazon EC2 インスタンス構成証明は、Nitro Trusted Platform Module (NitroTPM) と *構成証明可能 AMI* によって実現されます。
アテステーションの最初のステップは、**構成証明可能 AMI を構築し**、その AMI の*リファレンス測定値*を決定することです。構成証明可能 AMI は、アテステーションのためにゼロから構築された AMI です。リファレンス測定値は、AMI に含めたすべてのソフトウェアと設定の測定値です。リファレンス測定値を取得する方法の詳細については、「[サンプルイメージの説明を作成する](build-sample-ami.md)」を参照してください。
![\[構成証明可能 AMI を使用したリファレンス測定値の生成。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/attestable-ami.PNG)
次のステップでは、構成証明可能 AMI を使用して [Nitro-TPM 対応 EC2 インスタンス](enable-nitrotpm-prerequisites.md#nitrotpm-instancetypes)を起動します。インスタンスを起動したら、[NitroTPM ツール](attestation-get-doc.md)を使用して*アテステーションドキュメント*を生成できます。次に、アテステーションドキュメントからの EC2 インスタンスの実際の測定値とリファレンス測定値を比較して、インスタンスに信頼できるソフトウェアと設定があるかどうかをチェックできます。
構成証明可能 AMI の作成プロセス中に生成されたリファレンス測定値をインスタンスの構成証明ドキュメントに含まれる測定値と比較することで、信頼できるソフトウェアとコードのみがインスタンスで実行されていることを検証できます。
![\[アテステーションドキュメントの生成。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/attestation-document.PNG)
## AWS KMS との統合
測定値の比較プロセスを容易にするために、アテステーションドキュメントの検証ツールとして AWS Key Management Service (AWS KMS) を使用できます。AWS KMS では、リファレンス測定値に一致する測定値をアテステーションドキュメントに提供する場合にのみ、KMS キーを使用した特定のオペレーションを許可するアテステーションベースの KMS キーポリシーを作成できます。これを行うには、リファレンス測定値を条件キー値として使用する特定の条件キーを KMS キーポリシーに追加し、条件キーが満たされた場合に許可される KMS オペレーションを指定します。
KMS キーを使用して KMS オペレーションを実行する場合、アテステーションドキュメントを KMS リクエストにアタッチする必要があります。そうすると、AWS KMS は、アテステーションドキュメントからの測定値を KMS キーポリシーのリファレンス測定値と照合し、測定値が一致する場合にのみキーアクセスを許可します。
さらに、インスタンスのアテステーションドキュメントを生成するときは、所有するキーペアのパブリックキーを指定する必要があります。指定されたパブリックキーは、アテステーションドキュメントに含まれています。AWS KMS がアテステーションドキュメントを検証し、復号オペレーションを許可すると、返される前にアテステーションドキュメントに含まれるパブリックキーを使用してレスポンスが自動的に暗号化されます。これにより、レスポンスは、アテステーションドキュメントに含まれるパブリックキーに一致するプライベートキーでのみ復号し使用できます。
これにより、信頼できるソフトウェアとコードを実行しているインスタンスのみが KMS キーを使用して暗号オペレーションを実行できます。
## 分離されたコンピューティング環境のアテステーション
一般に、EC2 インスタンスを**分離されたコンピューティング環境**として構築および設定できます。これにより、管理者やユーザーが EC2 インスタンスで処理されているデータにアクセスするためのインタラクティブなアクセスやメカニズムが提供されることはありません。EC2 インスタンスアテステーションを使用すると、インスタンスが分離されたコンピューティング環境として実行されていることをサードパーティーまたはサービスに証明できます。詳細については、「[自社のオペレーターからデータを分離する](isolate-data-operators.md)」を参照してください。
例については、分離されたコンピューティング環境を作成する [Amazon Linux 2023 のサンプルイメージの説明](build-sample-ami.md)を参照してください。このサンプルイメージの説明を出発点にして、要件を満たすようにカスタマイズできます。
## AWS 責任共有モデル
NitroTPM と構成証明可能 AMI は、EC2 インスタンスでアテステーションを設定および構成するのに役立つ構成要素です。お客様は、それぞれのユースケースに合わせて AMI を設定する責任があります。詳細については、「[AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)」を参照してください。
**Topics**
+ [AWS KMS との統合](#attestation-kms)
+ [分離されたコンピューティング環境のアテステーション](#attestation-isolated-compute-environments)
+ [AWS 責任共有モデル](#attestation-shared-responsibility)
+ [構成証明可能 AMI](attestable-ami.md)
+ [アテステーション用に AWS KMS を準備する](prepare-attestation-service.md)
+ [NitroTPM アテステーションドキュメントを取得する](attestation-get-doc.md)
+ [AWS KMS との統合](attestation-attest.md)
+ [自社のオペレーターからデータを分離する](isolate-data-operators.md)
# 構成証明可能 AMI
構成証明可能 AMI は、すべてのコンテンツを表す対応する暗号化ハッシュを持つ Amazon マシンイメージ (AMI) です。ハッシュは AMI の作成プロセス中に生成され、アプリケーション、コード、起動プロセスなど、その AMI のコンテンツ全体に基づいて計算されます。
## Attestable State の維持
インスタンスの測定値は、初期起動状態に基づいています。起動後にインスタンスでソフトウェアまたはコードが変更され、再起動後も保持されていると、再起動後にインスタンスの測定値が変更されます。測定値が変更されると、構成証明可能 AMI のリファレンス測定値から逸脱し、インスタンスの再起動後にインスタンスは AWS KMS に対して正常にアテステーションができなくなります。したがって、構成証明可能 AMI が役立つように、インスタンスは再起動後に元のブート状態に戻る必要があります。
常に元のブート状態に戻るようにすると、インスタンスは再起動後に正常にアテステーションができます。次のユーティリティを使用して、再起動後もインスタンスのアテステーションを可能にできます。
+ `erofs` – 拡張読み取り専用ファイルシステム。このユーティリティにより、ルートファイルシステムが読み取り専用になります。このユーティリティを使用すると、`/etc`、`/run`、`/var` などのファイルシステムへの書き込みはメモリに保存され、インスタンスの再起動時に失われるため、ルートファイルシステムは元の起動状態のままになります。詳細については、[erofs のドキュメント](https://docs.kernel.org/filesystems/erofs.html)を参照してください。
+ `dm-verity` – 読み取り専用ルートファイルシステムの整合性を保護します。このユーティリティはファイルシステムブロックのハッシュを計算し、カーネルコマンドラインに保存します。これにより、カーネルは起動時にファイルシステムの整合性を検証できます。詳細については、[dm-verity のドキュメント](https://docs.kernel.org/admin-guide/device-mapper/verity.html)を参照してください。
## 構成証明可能 AMI を作成するための要件
構成証明可能 AMI には以下の要件があります。
+ **ベースとなるオペレーティングシステム** – Amazon Linux 2023 および [NixOS](https://github.com/aws/nitrotpm-attestation-samples)
+ **アーキテクチャ** – `x86_64` または `arm64` アーキテクチャ
+ **TPM サポート** – NitroTPM を有効にする必要があります。詳細については、「[Amazon EC2 インスタンスで NitroTPM を使用するための要件](enable-nitrotpm-prerequisites.md)」を参照してください。
+ **ブートモード** – UEFI ブートモードを有効にする必要があります。
**Topics**
+ [Attestable State の維持](#maintain-attestability)
+ [構成証明可能 AMI を作成するための要件](#ami-attestable-requirements)
+ [構成証明可能 AMI の作成](#sample-ami)
+ [サンプルイメージの説明を作成する](build-sample-ami.md)
+ [Amazon Linux 2023 のサンプルイメージの説明](al2023-isolated-compute-recipe.md)
+ [サンプルイメージの説明をカスタマイズする](customize-sample-ami.md)
+ [PCR 測定値を計算する](create-pcr-compute.md)
## 構成証明可能 AMI の作成
構成証明可能 AMI を作成するには、[KIWI Next Generation (KIWI NG)](https://osinside.github.io/kiwi/) で Amazon Linux 2023 を使用する必要があります。Amazon Linux 2023 は、KIWI NG を使用して構成証明可能 AMI を構築するために必要なすべてのソフトウェアとユーティリティを提供します。
KIWI NG は、事前設定された Linux ベースのイメージを構築するためのオープンソースツールです。KIWI NG は、イメージの内容を定義する XML による*イメージの説明*を使用します。イメージの説明では、特定のユースケース向けにすぐに使用できる AMI を構築するために実行するベースオペレーティングシステム、ソフトウェア、カーネル設定、スクリプトを指定します。
AMI のビルド時は、`nitro-tpm-pcr-compute` ユーティリティを使用して、KIWI NG によって生成された Unified Kernel Image (UKI) に基づいてリファレンス測定値を生成する必要があります。`nitro-tpm-pcr-compute` ユーティリティの使用に関する詳細については、「[カスタム AMI の PCR 測定値を計算する](create-pcr-compute.md)」を参照してください。
AWS は、分離されたコンピューティング環境で EC2 インスタンスを設定するために必要なすべての設定を含む Amazon Linux 2023 のサンプルイメージの説明を提供します。詳細については、「[Amazon Linux 2023 のサンプルイメージの説明を作成する](build-sample-ami.md)」を参照してください。
# Amazon Linux 2023 のサンプルイメージの説明を作成する
AWS は、ワークロード用に独自のカスタム構成証明可能 AMI を作成するための出発点として使用できる Amazon Linux 2023 のサンプルイメージの説明を提供します。サンプルイメージの説明には、ベースオペレーティングシステムとしての Amazon Linux 2023、ファイルシステムのイミュータビリティ用の `dm-verity` と `erofs` の設定が含まれ、分離されたコンピューティング環境を作成するためにすべてのインタラクティブアクセス (SSH、EC2 インスタンス接続、シリアルコンソールなど) が削除されます。サンプルイメージの説明の詳細については、[Github リポジトリ](https://github.com/amazonlinux/kiwi-image-descriptions-examples)を参照してください。
サンプルイメージの説明では、NitroTPM ツール (`nitro-tpm-pcr-compute` および `nitro-tpm-attest`) が `/usr/bin/` ディレクトリのビルド済みイメージに自動的にインストールされます。これにより、AMI から起動されたインスタンスにツールがプリインストールされます。
サンプルイメージの説明には、リファレンス測定値の生成に必要なコマンドを含むスクリプトである `edit_boot_install.sh` が含まれています。スクリプトは、KIWI NG によって作成された raw ディスクイメージファイル (`.raw`) をループバックデバイスにマウントし、UKI (`.efi` ファイル拡張子を持つ) を見つけ、`nitro-tpm-pcr-compute` ユーティリティを実行して AMI のリファレンス測定値を生成します。スクリプトは、ビルド時に KIWI NG によって自動的に実行されます。
このチュートリアルでは、サンプルイメージの説明を作成して構成証明可能 AMI を作成する方法を示します。
独自のイメージの説明の作成に関する詳細については、次の KIWI NG ドキュメントを参照してください。
+ [クイックスタート](https://osinside.github.io/kiwi/quickstart.html)
+ [イメージの説明](https://osinside.github.io/kiwi/image_description.html)
+ [Amazon Linux 2023 のサンプルイメージの説明](https://github.com/amazonlinux/kiwi-image-descriptions-examples)
前提条件
このチュートリアルを完了するには、IAM アイデンティティに次の許可が必要です。
+ `arn:aws:ec2:*::snapshot/*` に対する `ebs:CompleteSnapshot`、`ebs:StartSnapshot`、`ebs:PutSnapshotBlock`
+ すべてのリソースの `ec2:RegisterImage`
**KIWI NG を使用して Amazon Linux 2023 のサンプルイメージの説明を構築するには**
1. 最新の AL2023 AMI を使用して Amazon EC2 インスタンスを起動する インスタンスに AMI を構築するのに十分なストレージスペースを確保するために、少なくとも 12 GB のストレージをプロビジョニングしてください。
1. 必要な依存ファイルをインストールします。次のコマンドは、次のユーティリティをインストールします。
+ `kiwi-cli`
+ `veritysetup`
+ `erofs-utils`
+ `aws-nitro-tpm-tools`
```
sudo dnf install -y kiwi-cli python3-kiwi kiwi-systemdeps-core python3-poetry-core qemu-img veritysetup erofs-utils git cargo aws-nitro-tpm-tools
```
1. `coldsnap` ユーティリティをインストールします。このユーティリティを使用すると、raw イメージデータから Amazon EBS スナップショットを作成できます。このユーティリティを使用して、KIWI NG によって作成された raw ディスクイメージファイルから EBS スナップショットを作成します。
```
git clone https://github.com/awslabs/coldsnap.git
cd coldsnap
cargo install --locked coldsnap
cd ..
```
1. サンプルイメージの説明ファイルを取得します。
```
sudo dnf install kiwi-image-descriptions-examples
```
サンプルイメージの説明ファイルは、`/usr/share/kiwi-image-descriptions-examples/al2023/attestable-image-example` のディレクトリにダウンロードされます。
1. KIWI NG `system build` コマンドを使用してサンプルイメージの説明を作成します。次のコマンドは、`./image` ディレクトリに raw ディスクイメージファイルを作成します。
```
sudo kiwi-ng \
--color-output \
--loglevel 0 \
system build \
--description /usr/share/kiwi-image-descriptions-examples/al2023/attestable-image-example \
--target-dir ./image
```
詳細については、[kiwi-ng system build](https://osinside.github.io/kiwi/commands/system_build.html) のドキュメントを参照してください。
1. AMI のリファレンス測定値を取得します。測定値は、前のステップのイメージのビルド時に `nitro-tpm-pcr-compute` ユーティリティによって生成されます。リファレンス測定値は、`./image/pcr_measurements.json` というファイルにあります。
測定値は、次の JSON 形式で提供されます。
```
{
"Measurements": {
"HashAlgorithm": "SHA384 { ... }",
"PCR4": "PCR4_measurement",
"PCR7": "PCR7_measurement",
"PCR12": "PCR12_measurement"
}
}
```
1. `coldsnap` ユーティリティを使用して、KIWI NG によって作成された raw ディスクイメージを EBS スナップショットにアップロードします。コマンドはスナップショット ID を返します。次のステップで必要になるため、ID を書きとめておきます。
```
SNAPSHOT=$(.cargo/bin/coldsnap upload ./image/al2023*.raw)
echo "Created snapshot: $SNAPSHOT"
```
`coldsnap` ユーティリティの詳細については、[コールドスナップ GitHub リポジトリ](https://github.com/awslabs/coldsnap)を参照してください。
1. 前のステップのスナップショットを使用して、TPM 2.0 対応 AMI を UEFI ブートモードで登録します。`--architecture` には、Intel の場合は `x86_64`、Graviton の場合は `arm64` を指定します。
```
aws ec2 register-image \
--name "attestable_isolated_al2023_ami" \
--virtualization-type hvm \
--boot-mode uefi \
--architecture x86_64|arm64 \
--root-device-name /dev/xvda \
--block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=${SNAPSHOT}} \
--tpm-support v2.0 \
--ena-support
```
# Amazon Linux 2023 のサンプルイメージの説明
Amazon Linux 2023 のサンプルイメージの説明には、次の特性があります。
1. **Unified Kernel Image (UKI) ブート** – カーネル、`initrd`、およびブートパラメータを 1 つのイミュータブルイメージに結合する単一の署名付きバイナリを使用してブートします。
1. **読み取り専用ルートファイルシステム** – dm-verity 保護で拡張読み取り専用ファイルシステム (`erofs`) を使用して、ルートファイルシステムを変更できなくし、暗号整合性の検証を維持します。
1. **一時オーバーレイファイルシステム** – `/etc`、`/run`、`/var` などのディレクトリへの一時的な書き込みを許可する一時オーバーレイファイルシステムを作成します。このオーバーレイファイルシステムはメモリにのみ存在するため、インスタンスの再起動時にすべての変更が自動的に失われるため、システムは元の信頼された状態に戻ります。
1. **無効なリモートアクセス方法** – リモートアクセスを防ぐために、次のリモートアクセスメカニズムを削除します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/al2023-isolated-compute-recipe.html)
\$1 詳細については、「[イメージ説明の要素](https://osinside.github.io/kiwi/image_description/elements.html#packages-ignore)」を参照してください。
# ワークロードに合わせてAmazon Linux 2023 のサンプルイメージの説明をカスタマイズする
Amazon Linux 2023 のサンプルイメージの説明をカスタマイズし、特定のワークロードに必要なソフトウェアパッケージ、スクリプト、ファイルを含めることができます。カスタマイズは、KIWI NG イメージの説明のさまざまな要素に追加または変更することで実現されます。
**Topics**
+ [リポジトリ管理](#prepare-custom-image-repos)
+ [パッケージ管理](#customize-sample-ami-packages)
+ [ファイルとディレクトリの追加](#customize-sample-ami-overlay)
+ [カスタムスクリプトの追加](#customize-sample-ami-script)
## リポジトリ管理
デフォルトでは、サンプルイメージの説明には、Amazon Linux 2023 コアリポジトリのミラーエンドポイントを指す単一の `` 要素が含まれています。必要に応じて、必要なソフトウェアをインストールする他のリポジトリへの参照を追加できます。
サンプルイメージの説明では、`` 要素で定義されている `dnf` パッケージマネージャーを使用します。
リポジトリの追加の詳細については、「[リポジトリのセットアップ](https://osinside.github.io/kiwi/concept_and_workflow/repository_setup.html)」を参照してください。
## パッケージ管理
デフォルトでは、サンプルイメージの説明には、`erofs` 読み取り専用ファイルシステムを持つ分離されたコンピューティング環境用の Amazon Linux 2023 構成証明可能 AMI を作成するために必要なすべてのパッケージが含まれています。
イメージの説明の `` 要素に追加することで、イメージの説明に追加のソフトウェアパッケージを含めることができます。`` 要素は、AMI にインストールする必要があるすべてのソフトウェアを定義します。
`` 要素を使用して、特定のソフトウェアパッケージをアンインストールまたは削除することもできます。
イメージの説明でパッケージを追加または削除する方法の詳細については、「[パッケージの追加と削除](https://osinside.github.io/kiwi/concept_and_workflow/packages.html#)」を参照してください。
## ファイルとディレクトリの追加
サンプルイメージの説明には、オーバーレイツリーディレクトリ (`/root/`) が含まれています。オーバーレイツリーディレクトリは、イメージビルドプロセス中にイメージにコピーされるファイルとディレクトリを含むディレクトリです。オーバーレイツリーディレクトリに配置するファイルとディレクトリは、イメージビルドプロセス中にイメージのルートファイルシステムに直接コピーされます。
すべてのパッケージがインストールされると、オーバーレイツリーディレクトリがイメージにコピーされます。新しいファイルが追加され、既存のファイルが上書きされます。
## カスタムスクリプトの追加
サンプルイメージの説明には、単一のカスタムスクリプト `edit_boot_install.sh` が含まれています。このスクリプトには、イメージの内容に基づいてリファレンス測定値を生成する `nitro-tpm-pcr-compute` ユーティリティの実行に必要なコマンドが含まれています。このスクリプトは、ブートローダーのインストール直後に呼び出されます。
必要に応じて、イメージの説明に独自のカスタムスクリプトを含めて、イメージビルドプロセス中またはイメージの最初の起動時にタスクまたは設定を実行できます。スクリプトを使用すると、イメージの説明だけでは実現できない方法でイメージをカスタマイズできます。
イメージの説明にカスタムスクリプトを含めるには、スクリプトのタイプに基づいてスクリプトに正しく名前を付け、`appliance.kiwi` ファイルと同じディレクトリに追加する必要があります。KIWI NG は、スクリプトの名前が正しくて正しい場所に配置されていれば、スクリプトを自動的に検出して実行します。イメージの説明ファイルでスクリプトを明示的に参照する必要はありません。
KIWI NG でサポートされているスクリプトの詳細については、「[ユーザー定義スクリプト](https://osinside.github.io/kiwi/concept_and_workflow/shell_scripts.html)」を参照してください。
# カスタム AMI の PCR 測定値を計算する
`nitro-tpm-pcr-compute` ユーティリティを使用すると、Unified Kernel Image (UKI) に基づいて、ビルド時に構成証明可能 AMI のリファレンス測定値を生成できます。
Amazon Linux 2023 のサンプルイメージの説明では、`/usr/bin/` ディレクトリのビルド済みイメージにユーティリティが自動的にインストールされます。サンプルイメージの説明には、イメージのビルド時にユーティリティを実行してリファレンス測定値を生成するために必要なコマンドを含むスクリプトも含まれています。サンプルイメージの説明を使用している場合は、ユーティリティをインストールしたり、手動で実行したりする必要はありません。詳細については、「[Amazon Linux 2023 のサンプルイメージの説明を作成する](build-sample-ami.md)」を参照してください。
## `nitro-tpm-pcr-compute` ユーティリティをインストールする
Amazon Linux 2023 を使用している場合は、次のように Amazon Linux リポジトリから `nitro-tpm-pcr-compute` ユーティリティをインストールできます。
```
sudo yum install aws-nitro-tpm-tools
```
ツールは `/usr/bin` ディレクトリにインストールされます。
## `nitro-tpm-pcr-compute` ユーティリティを使用する
ユーティリティは、リファレンス測定値を生成するための単一のコマンド `nitro-tpm-pcr-compute` を提供します。
コマンドの実行時に以下を指定する必要がありますます。
+ Unified Kernel Image (`UKI.efi`) – 標準ブートと UEFI に必要です。
**構成証明可能 AMI のリファレンス測定値を生成するには:**
次のコマンドとパラメータを使用します。
```
/usr/bin/nitro-tpm-pcr-compute \
--image UKI.efi
```
ユーティリティは、リファレンス測定値を次の JSON 形式で返します。
```
{
"Measurements": {
"HashAlgorithm": "SHA384 { ... }",
"PCR4": "PCR4_measurement",
"PCR7": "PCR7_measurement",
"PCR12": "PCR12_measurement"
}
}
```
`nitro-tpm-pcr-compute` ユーティリティの使用方法の実例については、[Amazon Linux 2023 のサンプルイメージの説明](build-sample-ami.md)に含まれている `edit_boot_install.sh` スクリプトを参照してください。
# アテステーション用に AWS KMS を準備する
**注記**
サードパーティーのサービスに対してアテステーションを行う場合は、アテステーションドキュメントを受信、解析、検証するための独自のカスタムメカニズムを構築する必要があります。詳細については、「[NitroTPM アテステーションドキュメントを検証する](nitrotpm-attestation-document-validate.md)」を参照してください。
構成証明可能 AMI を作成したら、Amazon EC2 インスタンスからのリクエストを検証するために使用できるリファレンス測定値が必要です。AWS KMS には、NitroTPM によるアテステーションのサポートが組み込まれています。
シークレットデータの暗号化に使用した AWS KMS キーでは、構成証明可能 AMI の作成プロセス中に生成したリファレンス測定値に一致する測定値を使用するアテステーションドキュメントが API リクエストに含まれている場合にのみ、キーアクセスを許可するキーポリシーを追加します。標準ブートには PCR4 および PCR12 測定値を使用し、安全ブートには PCR7 測定値を使用します。これにより、構成証明可能 AMI を使用して起動されたインスタンスからのリクエストのみが、AWS KMS キーを使用して暗号オペレーションを実行できます。
AWS KMS には、NitroTPM KMS キーポリシーのアテステーションベースの条件を作成できる `kms:RecipientAttestation:NitroTPMPCR4`、`kms:RecipientAttestation:NitroTPMPCR7`、`kms:RecipientAttestation:NitroTPMPCR12` 条件キーが用意されています。詳細については、「[Condition keys for NitroTPM](https://docs.aws.amazon.com/kms/latest/developerguide/conditions-nitro-tpm.html)」を参照してください。
例えば、次の AWS KMS キーポリシーでは、`MyEC2InstanceRole` インスタンスプロファイルがアタッチされたインスタンスからリクエストが発生し、特定の PCR 4 値および PCR 12 値を含むアテステーションドキュメントがリクエストに含まれている場合にのみ、キーアクセスを許可します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow requests from instances with attested AMI only",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/MyEC2InstanceRole"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:GenerateRandom"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"kms:RecipientAttestation:NitroTPMPCR4":"EXAMPLE6b9b3d89a53b13f5dfd14a1049ec0b80a9ae4b159adde479e9f7f512f33e835a0b9023ca51ada02160EXAMPLE",
"kms:RecipientAttestation:NitroTPMPCR12":"000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
}
}
]
}
```
# NitroTPM アテステーションドキュメントを取得する
アテステーションドキュメントは、NitroTPM アテステーションプロセスの主要なコンポーネントです。これには、インスタンスのアイデンティティを検証し、信頼できるソフトウェアのみを実行していることを証明するために使用できる一連の暗号化測定値が含まれています。AWS KMS を持つアテステーションドキュメントを使用して、NitroTPM アテステーションの組み込みサポートを利用したり、独自の暗号化アテステーションメカニズムを構築したりできます。
`nitro-tpm-attest` ユーティリティを使用すると、実行時に Amazon EC2 インスタンスの署名付き NitroTPM アテステーションドキュメントを取得できます。
Amazon Linux 2023 のサンプルイメージの説明では、`/usr/bin/` ディレクトリのビルド済みイメージにユーティリティが自動的にインストールされます。これにより、AMI を使用して起動されたインスタンスにユーティリティがプリインストールされます。ユーティリティを手動でインストールする必要はありません。詳細については、「[Amazon Linux 2023 のサンプルイメージの説明を作成する](build-sample-ami.md)」を参照してください。
**Topics**
+ [`nitro-tpm-attest` ユーティリティをインストールする](#nitro-tpm-attest-install)
+ [`nitro-tpm-attest` ユーティリティを使用する](#nitro-tpm-attest-use)
+ [NitroTPM アテステーションドキュメント](nitrotpm-attestation-document-content.md)
+ [アテステーションドキュメントを検証する](nitrotpm-attestation-document-validate.md)
## `nitro-tpm-attest` ユーティリティをインストールする
Amazon Linux 2023 を使用している場合は、次のように Amazon Linux リポジトリから `nitro-tpm-attest` ユーティリティをインストールできます。
```
sudo yum install aws-nitro-tpm-tools
```
## `nitro-tpm-attest` ユーティリティを使用する
ユーティリティには、アテステーションドキュメントを取得するための単一のコマンド `nitro-tpm-attest` が用意されています。コマンドからは、Concise Binary Object Representation (CBOR) でエンコードされ、CBOR Object Signing and Encryption (COSE) を使用して署名されたアテステーションドキュメントが返されます。
コマンドの実行時に以下のパラメータをオプションで指定できます。
+ `public-key` – レスポンスデータが返される前に暗号化するために AWS KMS または外部サービスが使用できるパブリックキー。これにより、プライベートキーを所有している本来の受信者のみがデータを復号できます。例えば、AWS KMS でアテステーションを行う場合、サービスはアテステーションドキュメントのパブリックキーを使用してプレーンテキストデータを暗号化し、結果の暗号文をレスポンスの `CiphertextForRecipient` フィールドに返します。RSA キーのみがサポートされています。
+ `user-data` – ユーザーデータを使用して、追加の署名付きデータを外部サービスに配信できます。このユーザーデータは、リクエスト元のインスタンスと外部サービスとの間で合意されたプロトコルを完了するために使用できます。AWS KMS でのアテステーションには使用されません。
+ `nonce` – ノンスを使用してインスタンスと外部サービス間のチャレンジレスポンス認証を設定し、なりすまし攻撃を防ぐことができます。ノンスを使用すると、外部サービスは、インスタンスとライブでやり取りしていて、古いアテステーションドキュメントを再利用している偽装者とのやり取りではないことを確認できます。AWS KMS でのアテステーションには使用されません。
**アテステーションドキュメントを取得するには**
以下のコマンドとオプションのパラメータを使用します。
```
/usr/bin/nitro-tpm-attest \
--public-key rsa_public_key \
--user-data user_data \
--nonce nonce
```
RSA キーペアを生成する方法と、パブリックキーによるアテステーションをリクエストする方法を示す完全な例については、[nitro-tpm-attest GitHub リポジトリ](https://github.com/aws/NitroTPM-Tools/)を参照してください。
# NitroTPM アテステーションドキュメントの内容
アテステーションドキュメントは NitroTPM によって生成され、Nitro Hypervisor によって署名されます。これには、Amazon EC2 インスタンスに関連する一連のプラットフォーム設定レジスタ (PCR) 値が含まれます。アテステーションドキュメントには、次の PCR が含まれています。
**重要**
PCR0 と PCR1 は通常、AWS によって制御される初期ブートコードを測定するために使用されます。初期ブートコードを安全に更新できるように、これらの PCR の値は常に一定です。
+ `PCR0` – コアシステムファームウェア実行可能コード
+ `PCR1` – コアシステムファームウェアデータ
+ `PCR2` – 拡張またはプラグ可能な実行可能コード
+ `PCR3` – 拡張またはプラグ可能なファームウェアデータ
+ `PCR4` – ブートマネージャーコード
+ `PCR5` – ブートマネージャーコード設定とデータおよび GPT パーティションテーブル
+ `PCR6` – ホストプラットフォームの製造元の詳細
+ `PCR7` – セキュアブートポリシー
+ `PCR8 - 15` – 静的オペレーティングシステムで使用するために定義
+ `PCR16` – デバッグ
+ `PCR23` – アプリケーションのサポート
**PCR4**、**PCR7**、**PCR12** は、構成証明可能 AMI を使用してインスタンスが起動されたことを検証するために特別に使用されます。PCR4 および PCR12 は標準ブートで検証するために使用でき、PCR7 は安全ブートで検証するために使用できます。
+ **PCR4 (ブートマネージャーコード)** – インスタンスが起動すると、NitroTPM は UEFI 環境によって実行されるすべてのバイナリの暗号化ハッシュを作成します。構成証明可能 AMI では、これらのブートバイナリはハッシュを埋め込み、一致するハッシュを持たないバイナリの今後のロードを防ぎます。このようにして、単一のブートバイナリハッシュは、インスタンスが今後実行するコードを正確に記述できます。
+ **PCR7 (セキュアブートポリシー)** – UEFI ブートバイナリは、UEFI セキュアブート署名キーで署名できます。UEFI セキュアブートが有効になっている場合、UEFI は設定されたポリシーと一致しない UEFI ブートバイナリの実行を禁止します。PCR7 には、インスタンスの UEFI セキュアブートポリシーのハッシュが含まれています。
インスタンスの更新全体で保持される単一の KMS ポリシーを維持する必要がある場合は、PCR7 に対して検証して UEFI セキュアブート証明書を検証するポリシーを作成できます。そうすると、構成証明可能 AMI の作成時に、証明書を使用してブートバイナリに署名し、AMI の UEFI データで許可された唯一の証明書としてインストールできます。このモデルでは、古い (信頼済でない) AMI から起動されたインスタンスが KMS ポリシーを通過しないようにするには、新しい証明書を生成し、ポリシーにインストールして AMI を更新する必要があることに注意してください。
+ **PCR12** — UEFI ブートバイナリに渡されるコマンドラインのハッシュを含みます。コマンドラインが変更されていないことを検証するために、標準ブートにおいて PCR4 と組み合わせることが必要です。
# NitroTPM アテステーションドキュメントを検証する
**注記**
このトピックは、サードパーティーのキー管理サービスを使用していて、独自のアテステーションドキュメント検証メカニズムを構築する必要があるユーザーを対象としています。
このトピックでは、NitroTPM アテステーションフロー全体の概要を詳しく説明します。また、アテステーションドキュメントがリクエストされたときに AWS Nitro システムによって生成される内容と、キー管理サービスがアテステーションドキュメントを処理する方法について説明します。
**Topics**
+ [アテステーションドキュメント](#doc-def)
+ [アテステーションドキュメントの検証](#validation-process)
アテステーションの目的は、実行中のコードと設定に基づいて、インスタンスが信頼できるエンティティであることを証明することです。インスタンスの信頼の根源は、アテステーションドキュメントを提供する AWS Nitro システム内にあります。
アテステーションドキュメントは AWS Nitro Attestation Public Key Infrastructure (PKI) によって署名されます。PKI には、任意のサービスに組み込むことができる公開認証機関が含まれます。
## アテステーションドキュメント
アテステーションドキュメントは Concise Binary Object Representation (CBOR) でエンコードされ、CBOR Object Signing and Encryption (COSE) を使用して署名されます。
CBOR の詳細については、「[RFC 8949: Concise Binary Object Representation (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html)」を参照してください。
### アテステーションドキュメントの仕様
以下は、アテステーションドキュメントの構造を示しています。
```
AttestationDocument = {
module_id: text, ; issuing Nitro hypervisor module ID
timestamp: uint .size 8, ; UTC time when document was created, in
; milliseconds since UNIX epoch
digest: digest, ; the digest function used for calculating the
; register values
nitrotpm_pcrs: { + index => pcr }, ; map of PCRs at the moment the Attestation Document was generated
certificate: cert, ; the public key certificate for the public key
; that was used to sign the Attestation Document
cabundle: [* cert], ; issuing CA bundle for infrastructure certificate
? public_key: user_data, ; an optional DER-encoded key the attestation
; consumer can use to encrypt data with
? user_data: user_data, ; additional signed user data, defined by protocol
? nonce: user_data, ; an optional cryptographic nonce provided by the
; attestation consumer as a proof of authenticity
}
cert = bytes .size (1..1024) ; DER encoded certificate
user_data = bytes .size (0..1024)
pcr = bytes .size (32/48/64) ; PCR content
index = 0..31
digest = "SHA384"
```
アテステーションドキュメントのオプションパラメータ (`public_key`、`user_data`、および `nonce`) を使用して、アテステーションを行うインスタンスと外部サービスの間にカスタム検証プロトコルを確立できます。
## アテステーションドキュメントの検証
Nitro Hypervisor からアテステーションドキュメントをリクエストすると、署名されたアテステーションドキュメントを含むバイナリ BLOB を受け取ります。署名付きアテステーションドキュメントは、CBOR エンコードされ、 COSE 署名 (COSE\$1Sign1 署名構造を使用) されたオブジェクトです。全体的な検証プロセスには、次のステップが含まれます。
1. CBOR オブジェクトをデコードし、COSE\$1Sign1 構造にマッピングします。
1. COSE\$1Sign1 構造からアテステーションドキュメントを抽出します。
1. 証明書のチェーンを確認します。
1. アテステーションドキュメントが正しく署名されていることを確認します。
アテステーションドキュメントは、商用 AWS パーティションのルート証明書を含む AWS Nitro Attestation PKI によって署名されます。ルート証明書は [https://aws-nitro-enclaves.amazonaws.com/AWS\$1NitroEnclaves\$1Root-G1.zip](https://aws-nitro-enclaves.amazonaws.com/AWS_NitroEnclaves_Root-G1.zip) からダウンロードでき、次のフィンガープリントを使用して検証できます。
```
64:1A:03:21:A3:E2:44:EF:E4:56:46:31:95:D6:06:31:7E:D7:CD:CC:3C:17:56:E0:98:93:F3:C6:8F:79:BB:5B
```
ルート証明書は AWS Certificate Manager Private Certificate Authority (AWS Private CA) プライベートキーに基づいており、有効期間は 30 年です。PCA のサブジェクトの形式は次のとおりです。
```
CN=aws.nitro-enclaves, C=US, O=Amazon, OU=AWS
```
**Topics**
+ [COSE と CBOR](#COSE-CBOR)
+ [セマンティックの有効性](#semantic-validation)
+ [証明書の有効性](#cert-validity)
+ [証明書チェーンの有効性](#chain)
### COSE と CBOR
通常、COSE\$1Sign1 署名構造は、1 つの署名のみがメッセージに配置される場合に使用されます。コンテンツと署名を処理するパラメータは、COSE\$1Sign を分離するのではなく、保護されたヘッダーに配置されます。構造は、使用するコンテキストに応じて、タグ付けまたはタグ無しのいずれかでエンコードできます。タグ付きの COSE\$1Sign1 構造は、CBOR タグ 18 によって識別されます。
本文、署名、および本文と署名に関する情報を保持する CBOR オブジェクトは、COSE\$1Sign1 構造と呼ばれます。COSE\$1Sign1 構造は CBOR 配列です。配列には、次のフィールドが含まれます。
```
[
protected: Header,
unprotected: Header,
payload: This field contains the serialized content to be signed,
signature: This field contains the computed signature value.
]
```
アテステーションドキュメントのコンテキストでは、配列には以下が含まれます。
```
18(/* COSE_Sign1 CBOR tag is 18 */
{1: -35}, /* This is equivalent with {algorithm: ECDS 384} */
{}, /* We have nothing in unprotected */
$ATTESTATION_DOCUMENT_CONTENT /* Attestation Document */,
signature /* This is the signature */
)
```
CBOR の詳細については、「[RFC 8949: Concise Binary Object Representation (CBOR)](https://www.rfc-editor.org/rfc/rfc8949.html)」を参照してください。
### セマンティックの有効性
アテステーションドキュメントには、常に次の順序で CA バンドルがあります。
```
[ ROOT_CERT - INTERM_1 - INTERM_2 .... - INTERM_N]
0 1 2 N - 1
```
この順序は、「[Java PKI プログラマーズガイド](https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html)」の Java の CertPath など、既存のツールによっては順序が異なる必要がある場合があることに注意してください。
証明書を検証するには、アテステーションドキュメント CA バンドルから開始し、必要なチェーンを生成します。ここで、`TARGET_CERT` はアテステーションドキュメントの証明書です。
```
[TARGET_CERT, INTERM_N, ..... , INTERM_2, INTERM_1, ROOT_CERT]
```
### 証明書の有効性
チェーン内のすべての証明書について、現在の日付が証明書で指定された有効期間内であることを確認する必要があります。
### 証明書チェーンの有効性
一般的に、ある CA によって署名されたパブリックキー所有者の証明書と、他の CA によって署名された CA の追加の証明書 (無くてもよく、複数でもよい) で構成される、複数の証明書のチェーンが必要になる場合があります。パブリックキーユーザーは限られた数の保証された CA パブリックキーでのみ初期化されるため、認証パスと呼ばれるこのようなチェーンが必要です。インターネット PKI の認証パスの検証手順は、X.509 で提供されているアルゴリズムに基づいています。認証パス処理は、サブジェクト識別名および/またはサブジェクト代替名と、サブジェクトパブリックキーとの間のバインドを検証します。バインドは、そのパスを構成する証明書で指定された制約と、証明書利用者によって指定された入力によって制限されます。基本的な制約とポリシー制約の拡張により、認証パス処理ロジックで意思決定プロセスを自動化できます。
**注記**
検証を実行するときは CRL を無効にする必要があります。
ルートパスと生成された証明書チェーンから Java の使用を開始する場合、チェーンの検証は次のようになります。
```
validateCertsPath(certChain, rootCertficate) {
/* The trust anchor is the root CA to trust */
trustAnchors.add(rootCertificate);
/* We need PKIX parameters to specify the trust anchors
* and disable the CRL validation
*/
validationParameters = new PKIXParameters(trustAnchors);
certPathValidator = CertPathValidator.getInstance(PKIX);
validationParameters.setRevocationEnabled(false);
/* We are ensuring that certificates are chained correctly */
certPathValidator.validate(certPath, validationParameters);
}
```
# AWS KMS との統合
インスタンスには、NitroTPM から取得したアテステーションドキュメントを使用して AWS KMS API リクエストを行うことができるアプリケーションが必要です。アテステーションドキュメントを使用してリクエストを行うと、AWS KMS は提供されたアテステーションドキュメントの測定値を KMS キーポリシーのリファレンス測定値と照合します。リクエストは、アテステーションドキュメントの測定値が KMS キーポリシーのリファレンス測定値と一致する場合にのみ許可されます。
アテステーションドキュメントを使用して [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)、[DeriveSharedSecret](https://docs.aws.amazon.com/kms/latest/APIReference/API_DeriveSharedSecret.html)、[GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)、[GenerateDataKeyPair](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKeyPair.html)、または [GenerateRandom](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateRandom.html) の API オペレーションを呼び出す場合、これらの API は、アテステーションドキュメント由来のパブリックキーのレスポンス内にあるプレーンテキストを暗号化し、プレーンテキストの代わりに暗号文を返します。この暗号文は、インスタンス内に生成された対応するプライベートキーを使用してのみ復号できます。
詳細については、「*AWS Key Management Service デベロッパーガイド*」の[「NitroTPM の暗号化アテステーション](https://docs.aws.amazon.com/kms/latest/developerguide/services-nitro-enclaves.html)」を参照してください。
**注記**
サードパーティーのサービスに対してアテステーションを行う場合は、アテステーションドキュメントを受信、解析、検証するための独自のカスタムメカニズムを構築する必要があります。詳細については、「[NitroTPM アテステーションドキュメントを検証する](nitrotpm-attestation-document-validate.md)」を参照してください。
# 自社のオペレーターからデータを分離する
AWS Nitro System には、[ゼロオペレーターがアクセス](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/no-aws-operator-access.html)があります。AWS システムまたはユーザーが Amazon EC2 Nitro ホストにログインしたり、EC2 インスタンスのメモリにアクセスしたり、ローカルの暗号化されたインスタンスストレージまたはリモートの暗号化された Amazon EBS ボリュームに保存されている顧客データにアクセスしたりするためのメカニズムはありません。
高度の機密データを処理するときは、自社のオペレーターでも EC2 インスタンスにアクセスできないようにして、そのデータへのアクセスを制限することを検討してください。
分離されたコンピューティング環境を提供するように設定されたカスタム構成証明可能 AMI を作成できます。AMI の設定は、ワークロードとアプリケーションの要件によって異なります。AMI を構築して分離されたコンピューティング環境を作成するときは、以下のベストプラクティスを考慮してください。
+ オペレーターまたはユーザーがインスタンスにアクセスできないように、**すべてのインタラクティブアクセスを削除**します。
+ **信頼できるソフトウェアとコードのみ**が AMI に含まれているようにします。
+ アクセスをブロックするようにインスタンス内の**ネットワークファイアウォールを設定**します。
+ すべてのストレージおよびファイルシステムを**読み取り専用かつイミュータブルな状態**にします。
+ 認証され、認可され、ログに記録された API コールに**インスタンスへのアクセスを制限**します。
# インタラクティブアクセスを持たない構成証明可能 AMI の更新
分離されたコンピューティング環境 AMI を使用してインスタンスを起動すると、ユーザーやオペレーターがインスタンスに接続できなくなります。つまり、起動後にインスタンスにソフトウェアをインストールまたは更新する方法はありません。
新しいソフトウェアまたはソフトウェア更新が必要な場合は、必要なソフトウェアまたはソフトウェア更新を含む新しい構成証明可能 AMI を作成する必要があります。次に、その AMI を使用して新しいインスタンスを起動するか、元のインスタンスでルートボリュームの置換を実行します。AMI にソフトウェアの変更が適用されると、新しいハッシュが生成されます。
次のアクションを実行すると、NitroTPM アテステーションドキュメントのリファレンス測定値が変更されます。
+ 構成証明可能 AMI で起動されたインスタンスの停止と起動
+ 別の AMI でルートボリュームの置換を実行する
これらのアクションを実行する場合は、新しいリファレンス測定値でアテステーションサービスを更新する必要があります。例えば、アテステーションに AWS KMS を使用している場合は、KMS キーポリシーを新しいリファレンス測定値に更新する必要があります。
インスタンスは、インスタンスライフサイクル全体で NitroTPM キーマテリアルを保持し、停止/起動およびルートボリューム置換オペレーションを通じて保持します。
# Windows インスタンスの クレデンシャルガード
AWS Nitro System は Amazon Elastic Compute Cloud (Amazon EC2) Windows インスタンスの クレデンシャルガード をサポートしています。クレデンシャルガード は Windows 仮想化ベースのセキュリティ (VBS) 機能です。これにより、Windows カーネルの保護だけでなく、Windows ユーザー認証情報やコードインテグリティの適用などのセキュリティ資産を保護するための隔離環境を構築できます。EC2 Windows インスタンスを実行すると、クレデンシャルガード は AWS Nitro System を使用して、Windows ログイン認証情報がオペレーティングシステムのメモリから抽出されないように保護します。
**Topics**
+ [前提条件](#credential-guard-prerequisites)
+ [サポートされているインスタンスを起動する](#credential-guard-launch-instance)
+ [メモリインテグリティの無効化](#disable-memory-integrity)
+ [クレデンシャルガード を有効にする](#turn-on-credential-guard)
+ [クレデンシャルガード が実行されていることを確認する](#verify-credential-guard)
## 前提条件
クレデンシャルガード を使用するにはWindows インスタンスが 次の前提条件を満たす必要があります。
**Amazon マシンイメージ (AMI)**
NitroTPM と UEFI 安全ブート を有効にするにはAMI を事前に設定しておく必要があります。サポートされている AMI の詳細については[Amazon EC2 インスタンスで NitroTPM を使用するための要件](enable-nitrotpm-prerequisites.md)を参照してください。
**メモリインテグリティ**
*ハイパーバイザー保護コードインテグリティ (HVCI)* または*ハイパーバイザー強制コードインテグリティ*とも呼ばれる*メモリーインテグリティ*はサポートされていません。認証情報ガードを有効にする前に、この機能が無効になっていることを確認する必要があります。詳細については[メモリインテグリティの無効化](#disable-memory-integrity)を参照してください。
**インスタンスタイプ**
次のインスタンスタイプは特段の記載がない限り、すべてのサイズで クレデンシャルガード をサポートしています: `C5`、`C5d`、`C5n`、`C6i`、`C6id`、`C6in`、`C7i`、`C7i-flex`、`M5`、`M5d`、`M5dn`、`M5n`、`M5zn`、`M6i`、`M6id`、`M6idn`、`M6in`、`M7i`、`M7i-flex`、`R5`、`R5b`、`R5d`、`R5dn`、`R5n`、`R6i`、`R6id`、`R6idn`、`R6in`、`R7i`、`R7iz`、`T3`。
+ NitroTPM には共通して必須インスタンスタイプがいくつかありますが、クレデンシャルガード をサポートするにはインスタンスタイプが上記のインスタンスタイプのいずれかである必要があります。
+ クレデンシャルガード は以下ではサポートされていません。
+ ベアメタルインスタンス。
+ 次のインスタンスタイプ: `C7i.48xlarge`、`M7i.48xlarge`、`R7i.48xlarge`。
インスタンスタイプの詳細については、「[Amazon EC2 インスタンスタイプガイド](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-types.html)」を参照してください。
## サポートされているインスタンスを起動する
Amazon EC2 コンソールまたは AWS Command Line Interface (AWS CLI) を使用して、クレデンシャルガード をサポートしているインスタンスを起動できます。インスタンスを起動するにはAWS リージョン ごとに固有の互換性のある AMI ID が必要です。
**ヒント**
以下のリンクを使用すると、Amazon EC2 コンソールで Amazon が提供する AMI と互換性のあるインスタンスを検出して起動できます。
[https://console.aws.amazon.com/ec2/v2/home?#Images:visibility=public-images;v=3;search=:TPM-Windows_Server;ownerAlias=amazon](https://console.aws.amazon.com/ec2/v2/home?#Images:visibility=public-images;v=3;search=:TPM-Windows_Server;ownerAlias=amazon)
------
#### [ Console ]
**インスタンスを起動するには**
サポートされているインスタンスタイプと事前設定された Windows AMI を指定し、ステップに従って[インスタンスを起動](ec2-launch-instance-wizard.md)します。
------
#### [ AWS CLI ]
**インスタンスを起動するには**
[https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) コマンドを使用して、サポートされているインスタンスタイプと事前設定された Windows AMI を使用してインスタンスを起動します。
```
aws ec2 run-instances \
--image-id resolve:ssm:/aws/service/ami-windows-latest/TPM-Windows_Server-2022-English-Full-Base \
--instance-type c6i.large \
--region us-east-1 \
--subnet-id subnet-0abcdef1234567890
--key-name key-name
```
------
#### [ PowerShell ]
**インスタンスを起動するには**
[https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html](https://docs.aws.amazon.com/powershell/latest/reference/items/New-EC2Instance.html) コマンドを使用して、サポートされているインスタンスタイプと事前設定された Windows AMI を使用してインスタンスを起動します。
```
New-EC2Instance `
-ImageId resolve:ssm:/aws/service/ami-windows-latest/TPM-Windows_Server-2022-English-Full-Base `
-InstanceType c6i.large `
-Region us-east-1 `
-SubnetId subnet-0abcdef1234567890 `
-KeyName key-name
```
------
## メモリインテグリティの無効化
サポートされているシナリオではローカルグループポリシーエディタを使用してメモリインテグリティを無効にできます。次のガイダンスは**[仮想化ベースのコードインテグリティ保護]** で各構成設定に適用できます。
+ **ロックなしで有効** — メモリインテグリティを無効にするには設定を **[無効]** に変更します。
+ **UEFI ロックで有効** — メモリインテグリティは UEFI ロックで有効になっています。UEFI ロックで一度有効にすると、メモリの整合性を無効にすることはできません。メモリインテグリティを無効にして新しいインスタンスを作成し、サポートされていないインスタンスが使用されていない場合は終了することをお勧めします。
**ローカルグループポリシーエディタでメモリの整合性を無効にするには**
1. リモートデスクトッププロトコル (RDP) を使用して、管理者権限を持つユーザーアカウントとしてインスタンスに接続します。詳細については[RDP クライアントを使用して Windows インスタンスに接続する](connect-rdp.md)を参照してください。
1. スタートメニューを開き、**cmd** を検索してコマンドプロンプトを起動します。
1. 次のコマンドを実行して、ローカルグループポリシーエディタ `gpedit.msc` を開きます。
1. ローカルグループポリシーエディタで、**[コンピュータの構成]**、**[管理用テンプレート]**、**[システム]**、**[デバイスガード]** の順に選択してください。
1. **[仮想化ベースのセキュリティを有効にする]** を選択してから、**[ポリシー設定の編集]** を選択してください。
1. **[仮想化ベースのコードインテグリティ保護]** の設定ドロップダウンを開き、**[無効]** を選択し、**[適用]** を選択してください。
1. インスタンスを再起動して、変更を適用します。
## クレデンシャルガード を有効にする
サポートされているインスタンスタイプと互換性のある AMI を使用して Windows インスタンスを起動し、メモリの整合性が無効になっていることを確認すると、認証情報ガードを有効にできます。
**重要**
次の手順を実行して クレデンシャルガード を有効にするには管理者権限が必要です。
**クレデンシャルガード を有効にするには**
1. リモートデスクトッププロトコル (RDP) を使用して、管理者権限を持つユーザーアカウントとしてインスタンスに接続します。詳細については[RDP クライアントを使用して Windows インスタンスに接続する](connect-rdp.md)を参照してください。
1. スタートメニューを開き、**cmd** を検索してコマンドプロンプトを起動します。
1. 次のコマンドを実行して、ローカルグループポリシーエディタ `gpedit.msc` を開きます。
1. ローカルグループポリシーエディタで、**[コンピュータの構成]**、**[管理用テンプレート]**、**[システム]**、**[デバイスガード]** の順に選択してください。
1. **[仮想化ベースのセキュリティを有効にする]** を選択してから、**[ポリシー設定の編集]** を選択してください。
1. **[仮想化ベースのセキュリティを有効にする]** メニューで **[有効]** を選択してください。
1. **[プラットフォームセキュリティレベルの選択]** では**[安全ブート と DMA 保護]** を選択してください。
1. **[クレデンシャルガード の設定]** では**[UEFI ロックで有効]** を選択してください。
**注記**
残りのポリシー設定は クレデンシャルガード を有効にするために必要ないため、**[未構成]** のままにしておくことができます。
以下の画像は前述のように構成された VBS 設定を示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/vbs-credential-guard-gpo-enabled.png)
1. インスタンスを再起動して、設定を適用します。
## クレデンシャルガード が実行されていることを確認する
Microsoft システム情報 (`Msinfo32.exe`) ツールを使用して、クレデンシャルガード が実行されていることを確認できます。
**重要**
クレデンシャルガード を有効にするために必要なポリシー設定の適用を完了するにはまずインスタンスを再起動する必要があります。
**クレデンシャルガード が実行されていることの確認するには**
1. リモートデスクトッププロトコル (RDP) を使用してインスタンスに接続します。詳細については[RDP クライアントを使用して Windows インスタンスに接続する](connect-rdp.md)を参照してください。
1. インスタンス用の RDP セッションで、スタートメニューを開いて、**cmd** を検索して、コマンドプロンプトを開始します。
1. 次のコマンドを実行して、システム情報を開きます: `msinfo32.exe`
1. Microsoft システム情報ツールにはVBS 設定の詳細が一覧表示されます。仮想化ベースのセキュリティサービスの横に、**[クレデンシャルガード]** が **[実行中]** と表示されていることを確認します。
次の画像はVBS が前述のように実行されていることを示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/vbs-credential-guard-msinfo32-enabled.png)
# インターフェイス VPC エンドポイントを使用して Amazon EC2 にアクセスします。
VPC 内のリソースと Amazon EC2 API の間にプライベート接続を作成することで、VPC のセキュリティ体制を向上させることができます。インターネットゲートウェイ、NAT デバイス、VPN 接続、または Direct Connect 接続を使用せずに、VPC 内にあるかのように Amazon EC2 API にアクセスできます。VPC 内の EC2 インスタンスは、Amazon EC2 API にアクセスするためにパブリック IP アドレスを必要としません。
詳細については「*AWS PrivateLink ガイド*」の「[Access AWS のサービス through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。
**Topics**
+ [インターフェイス VPC エンドポイントを作成する](#create-endpoint)
+ [エンドポイントポリシーを作成する](#endpoint-policy)
## インターフェイス VPC エンドポイントを作成する
以下のサービス名を使用して、Amazon EC2 のインターフェイス エンドポイントを作成します。
+ **com.amazonaws.*region*.ec2** — Amazon EC2 API アクションのエンドポイントを作成します。
詳細については、「*AWS PrivateLink ガイド*」の「[インターフェイス VPC エンドポイントを使用して AWS のサービス にアクセスする](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」を参照してください。
## エンドポイントポリシーを作成する
エンドポイントポリシーはインターフェイスエンドポイントにアタッチできる IAM リソースです。デフォルトのエンドポイントポリシーではインターフェイスエンドポイント経由での Amazon EC2 API へのフルアクセスが許可されています。VPC から Amazon EC2 API へのアクセス許可をコントロールするにはカスタムエンドポイントポリシーをインターフェイスエンドポイントにアタッチします。
エンドポイントポリシーは以下の情報を指定します。
+ アクションを実行できるプリンシパル。
+ 実行可能なアクション。
+ このアクションを実行できるリソース。
**重要**
デフォルト以外のポリシーが Amazon EC2 のインターフェイス VPC エンドポイントに適用されると、`RequestLimitExceeded` からの失敗したリクエストなど、特定の失敗した API リクエストが AWS CloudTrail または Amazon CloudWatch にログ記録されない場合があります。
詳細については、「*AWS PrivateLink ガイド*」の「[Control access to services using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。
次の例は暗号化されていないボリュームを作成したり、暗号化されていないボリュームでインスタンスを起動したりするアクセス許可を拒否する VPC エンドポイントポリシーを示しています。このポリシー例では他のすべての Amazon EC2 のアクションを実行するアクセス許可も付与しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": [
"ec2:CreateVolume"
],
"Effect": "Deny",
"Resource": "*",
"Principal": "*",
"Condition": {
"Bool": {
"ec2:Encrypted": "false"
}
}
},
{
"Action": [
"ec2:RunInstances"
],
"Effect": "Deny",
"Resource": "*",
"Principal": "*",
"Condition": {
"Bool": {
"ec2:Encrypted": "false"
}
}
}]
}
```
------