翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Machine-to-machine管理
Machine-to-machine (M2M) 認証により、AWS で実行されるサービスとアプリケーションは、相互に安全に通信してリソースとデータにアクセスできます。マシン認証システムは、長期的な静的認証情報を使用する代わりに、一時的な認証情報またはトークンを発行して、信頼できるマシンを識別します。これにより、人間の介入なしに環境の特定の部分にアクセスできるマシンを正確に制御できます。適切に設計されたマシン認証は、広範な認証情報の公開を制限し、アクセス許可の動的な取り消しを可能にし、認証情報のローテーションを簡素化することで、セキュリティ体制を向上させるのに役立ちます。マシン認証の一般的な方法には、EC2 インスタンスプロファイル、Amazon Cognito クライアント認証情報付与、相互認証 TLS (mTLS) 接続、IAM Roles Anywhere などがあります。このセクションでは、AWS に安全でスケーラブルな M2M 認証フローを実装するためのガイダンスを提供します。
EC2 インスタンスプロファイル
AWS API を呼び出す必要があるアプリケーションまたはサービスが Amazon Elastic Compute Cloud (Amazon EC2) で実行されている場合は、EC2 インスタンスプロファイルの使用を検討してください。 APIs インスタンスプロファイルを使用すると、EC2 インスタンスで実行されるアプリケーションは、静的で存続期間の長い IAM アクセスキーを必要とせずに、他の AWS のサービスに安全にアクセスできます。代わりに、IAM ロールをインスタンスに割り当てて、インスタンスプロファイルを通じて必要なアクセス許可を付与する必要があります。EC2 インスタンスは、インスタンスプロファイルから一時的なセキュリティ認証情報を自動的に取得して、他の AWS のサービスにアクセスできます。
このシナリオを以下に図表で示します。
-
AWS API を呼び出す必要がある EC2 インスタンス上のアプリケーションは、インスタンスメタデータ項目からロールによって提供されるセキュリティ認証情報を取得します
iam/security-credentials/<role-name>。 -
アプリケーションは
AccessKeyId、AWS API リクエストの署名に使用できる 、SecretAccessKey、および シークレットトークンを受け取ります。 -
アプリケーションは AWS API を呼び出します。ロールが API アクションを許可すると、リクエストは成功します。
AWS リソースでの一時的な認証情報の使用の詳細については、IAM ドキュメントの「AWS リソースでの一時的な認証情報の使用」を参照してください。
利点
-
セキュリティが向上しました。この方法では、EC2 インスタンスへの長期的な認証情報の配布を回避できます。認証情報は、インスタンスプロファイルを通じて一時的に提供されます。
-
簡単な統合。インスタンスで実行されるアプリケーションは、追加のコーディングや設定を行うことなく、認証情報を自動的に取得できます。AWS SDKsインスタンスプロファイル認証情報を自動的に使用します。
-
動的アクセス許可。インスタンスプロファイルに割り当てられた IAM ロールを更新することで、インスタンスで使用できるアクセス許可を変更できます。更新されたアクセス許可を反映する新しい認証情報が自動的に取得されます。
-
ローテーション。AWS は一時的な認証情報を自動的にローテーションして、認証情報が侵害されるリスクを軽減します。
-
取り消し。インスタンスプロファイルからロールの割り当てを削除することで、認証情報をすぐに取り消すことができます。
設計上の考慮事項
-
EC2 インスタンスにアタッチできるインスタンスプロファイルは 1 つだけです。
-
最小特権の IAM ロールを使用します。アプリケーションが必要とするアクセス許可のみをインスタンスプロファイルの IAM ロールに割り当てます。最小限のアクセス許可から開始し、必要に応じて後でアクセス許可を追加します。
-
ロールポリシーで IAM 条件を使用して、タグ、IP アドレス範囲、時刻などに基づいてアクセス許可を制限します。これにより、アプリケーションがアクセスできるサービスとリソースが制限されます。
-
必要なインスタンスプロファイルの数を検討してください。EC2 インスタンスで実行されるすべてのアプリケーションは、同じプロファイルを共有し、同じ AWS アクセス許可を持ちます。同じインスタンスプロファイルを複数の EC2 インスタンスに適用できるため、必要に応じてインスタンスプロファイルを再利用することで管理オーバーヘッドを削減できます。
-
アクティビティをモニタリングします。AWS CloudTrail などのツールを使用して、インスタンスプロファイル認証情報を使用する API コールをモニタリングします。認証情報の侵害を示す可能性のある異常なアクティビティに注意してください。
-
不要な認証情報を削除します。未使用のインスタンスプロファイルからロール割り当てを削除して、認証情報の使用を防止します。IAM アクセスアドバイザーを使用して、未使用のロールを識別できます。
-
ユーザーがインスタンスを起動するときに EC2 インスタンスに渡すことができるロールを制限するには、PassRole 許可を使用します。これにより、ユーザーが付与されたアクセス許可よりも多くのアクセス許可を持つアプリケーションを実行できなくなります。
-
アーキテクチャが複数の AWS アカウントにまたがる場合、あるアカウントの EC2 インスタンスが別のアカウントのリソースにアクセスする方法を検討してください。クロスアカウントロールを適切に使用して、長期的な AWS セキュリティ認証情報を埋め込むことなく、安全なアクセスを確保します。
-
インスタンスプロファイルを大規模に管理するには、次のいずれかのオプションを使用できます。
-
AWS Systems Manager Automation ランブックを使用して、インスタンスプロファイルと EC2 インスタンスの関連付けを自動化します。これは、起動時またはインスタンスの実行後に実行できます。
-
AWS CloudFormation を使用して、AWS コンソールで設定するのではなく、作成時に EC2 インスタンスにプログラムでインスタンスプロファイルを適用します。
-
-
VPC エンドポイントを使用して、EC2 インスタンスで実行されるアプリケーションから Amazon S3 や Amazon DynamoDB などのサポートされている AWS サービスにプライベートに接続することをお勧めします。
Amazon Cognito クライアント認証情報付与
Amazon Cognito
次の図は、この方法を示しています。
-
サーバー (Resource Server) からリソースをリクエストするアプリケーション (App Client) は、Amazon Cognito にトークンをリクエストします。
-
Amazon Cognito ユーザープールはアクセストークンを返します。
-
App Client は Resource Server にリクエストを送信し、アクセストークンを含めます。
-
Resource Server は Amazon Cognito でトークンを検証します。
-
検証が成功し、リクエストされたアクションが許可されている場合、Resource Server はリクエストされたリソースで応答します。
利点
-
マシン認証。この方法では、ユーザーコンテキストやログインは必要ありません。アプリケーションはトークンで直接認証します。
-
短期認証情報。アプリケーションは、まず Amazon Cognito からアクセストークンを取得し、次に時間制限付きアクセストークンを使用してリソースサーバーからデータにアクセスできます。
-
OAuth2 のサポート。この方法では、確立された OAuth2 標準に従っているため、不整合が軽減され、アプリケーション開発に役立ちます。
-
セキュリティを強化しました。クライアント認証情報付与を使用すると、API キー認可メカニズムとは異なり、クライアント ID とクライアントシークレットがリソースサーバーに転送されないため、セキュリティが強化されます。クライアント ID とシークレットは共有され、Amazon Cognito を呼び出して時間制限付きアクセストークンを取得する場合にのみ使用されます。
-
スコープによるきめ細かなアクセスコントロール。アプリケーションは、スコープと追加のクレームを定義してリクエストし、特定のリソースのみにアクセスを制限できます。
-
監査証跡。CloudTrail によって収集された情報を使用して、Amazon Cognito に対するリクエスト、リクエスト元の IP アドレス、リクエスト者、リクエスト日時などの詳細を確認できます。
設計上の考慮事項
-
各クライアント ID のアクセス範囲を慎重に定義し、必要最小限に制限します。スコープを絞り込むと、潜在的な脆弱性が軽減され、サービスが必要なリソースにのみアクセスできるようになります。
-
AWS Secrets Manager などの安全なストレージサービスを使用して認証情報を保存することで、クライアント IDs とシークレットを保護します。認証情報をソースコードにチェックインしないでください。
-
CloudTrail や CloudWatch などのツールを使用して、トークンのリクエストと使用状況をモニタリングおよび監査します。問題を示す可能性のある予期しないアクティビティパターンを監視します。
-
定期的なスケジュールでクライアントシークレットのローテーションを自動化します。ローテーションのたびに、新しいアプリケーションクライアントを作成し、古いクライアントを削除して、クライアント ID とシークレットを更新します。サービス通信を中断することなく、これらのローテーションを容易にします。
-
トークンエンドポイントリクエストにレート制限を適用して、不正使用やサービス拒否 (DoS) 攻撃を防止します。
-
セキュリティ違反が発生した場合にトークンを取り消すための戦略を用意します。トークンの有効期間は短くなりますが、侵害されたトークンはすぐに無効にする必要があります。
-
AWS CloudFormation を使用して、他の のサービスに対して認証する必要があるマシンを表す Amazon Cognito ユーザープールとアプリケーションクライアントをプログラムで作成します。
-
必要に応じて、パフォーマンス効率とコスト最適化を提供するためにトークンをキャッシュします。
-
アクセストークンの有効期限が組織のセキュリティ体制と一致していることを確認します。
-
カスタムリソースサーバーを使用する場合は、必ずアクセストークンを検証して、署名が有効であること、トークンの有効期限が切れていないこと、正しいスコープが存在することを確認します。必要に応じて、追加のクレームを確認します。
-
クライアント認証情報を大規模に管理するには、次のいずれかのオプションを使用できます。
-
すべてのクライアント認証情報の管理を 1 つの一元化された Amazon Cognito インスタンスに一元化します。これにより、複数の Amazon Cognito インスタンスの管理オーバーヘッドが削減され、設定と監査がよりシンプルになります。ただし、スケールを計画し、Amazon Cognito サービスクォータを考慮してください。
-
クライアント認証情報の責任をワークロードアカウントにフェデレーションし、複数の Amazon Cognito インスタンスを許可します。このオプションは柔軟性を高めますが、一元化されたオプションと比較してオーバーヘッドと全体的な複雑さを高めることができます。
-
mTLS 接続
相互 TLS (mTLS) 認証は、クライアントとサーバーの両方が TLS で証明書を使用して通信する前に相互に認証できるようにするメカニズムです。mTLS の一般的なユースケースには、規制の厳しい業界、モノのインターネット (IoT) アプリケーション、business-to-business (B2B) アプリケーションなどがあります。Amazon API Gateway は現在、既存の認可オプションに加えて mTLS をサポートしています。カスタムドメインで mTLS を有効にして、リージョン REST および HTTP APIs に対して認証できます。リクエストは、ベアラー、JSON ウェブトークン (JWTs) を使用するか、IAM ベースの認可でリクエストに署名することで承認できます。
次の図は、EC2 インスタンスで実行されているアプリケーションの mTLS 認証フローと、Amazon API Gateway で設定された API を示しています。
-
API Gateway は、パブリックに信頼された証明書を AWS Certificate Manager (ACM) に直接リクエストします。
-
ACM は認証機関 (CA) から証明書を生成します。
-
API を呼び出すクライアントは、API リクエストで証明書を提示します。
-
API Gateway は、作成した Amazon S3 トラストストアバケットをチェックします。このバケットには、API にアクセスするために信頼する X.509 証明書が含まれています。API Gateway がリクエストを続行するには、証明書の発行者とルート CA 証明書までの完全な信頼チェーンが信頼ストアにある必要があります。
-
クライアントの証明書が信頼されている場合、API Gateway はリクエストを承認し、 メソッドを呼び出します。
-
関連付けられた API アクション (この場合は AWS Lambda 関数) はリクエストを処理し、リクエスタに送信されるレスポンスを返します。
利点
-
M2M 認証。サービスは、共有シークレットやトークンを使用する代わりに、相互に直接認証します。これにより、静的認証情報を保存および管理する必要がなくなります。
-
改ざん防止。TLS 暗号化は、サービス間の転送中のデータを保護します。コミュニケーションを第三者が読み取ったり変更したりすることはできません。
-
簡単な統合。mTLS サポートは主要なプログラミング言語とフレームワークに組み込まれています。サービスは、最小限のコード変更で mTLS を有効にできます。
-
きめ細かなアクセス許可。サービスは特定の証明書のみを信頼するため、許可された発信者をきめ細かく制御できます。
-
取り消し。侵害された証明書はすぐに取り消すことができるため、信頼されなくなり、それ以上アクセスできなくなります。
設計上の考慮事項
-
API Gateway を使用する場合：
-
デフォルトでは、クライアントは API Gateway が API 用に生成する
execute-apiエンドポイントを使用して API を呼び出すことができます。クライアントが mTLS でカスタムドメイン名を使用してのみ API にアクセスできるようにするには、このデフォルトエンドポイントを無効にします。詳細については、API Gateway ドキュメントの「REST API のデフォルトエンドポイントを無効にする」を参照してください。 -
API Gateway は、証明書が取り消されたかどうかを検証しません。
-
REST API の mTLS を設定するには、最小 TLS バージョン 1.2 のリージョン別カスタムドメイン名を API に使用する必要があります。mTLS はプライベート APIs ではサポートされていません。
-
-
API Gateway の証明書は、独自の CA から発行することも、AWS Private Certificate Authority からインポートすることもできます。
-
サービス証明書を安全に発行、配布、更新、および取り消すプロセスを作成します。可能な場合は発行と更新を自動化します。M2M 通信の一方が API ゲートウェイである場合は、AWS Private CA と統合できます。
-
プライベート CA へのアクセスを保護します。CA を侵害すると、CA が発行したすべての証明書の信頼が損なわれます。
-
プライベートキーは、証明書とは別に安全に保存します。キーを定期的にローテーションして、侵害された場合の影響を制限します。
-
証明書が不要になった場合や侵害された場合は、すぐに失効させます。証明書失効リストを サービスに配布します。
-
可能な場合は、特定の目的またはリソースのみを対象とした証明書を発行して、侵害された場合にユーティリティを制限します。
-
CA または証明書失効リスト (CRL) インフラストラクチャの証明書の有効期限と停止に関する緊急時対応計画を立てます。
-
証明書の障害や停止がないかシステムをモニタリングします。問題を示す可能性のある障害の急増に注意してください。
-
AWS プライベート CA で AWS Certificate Manager (ACM) を使用している場合は、AWS CloudFormation を使用してパブリック証明書とプライベート証明書をプログラムでリクエストできます。
-
ACM を使用している場合は、AWS Resource Access Manager (AWS RAM) を使用して、セキュリティアカウントからワークロードアカウントに証明書を共有します。
IAM Roles Anywhere
マシンまたはシステムが AWS のサービスに接続する必要があるが、IAM ロールをサポートしていない場合は、M2M ID 管理に IAM Roles Anywhere を使用することをお勧めします。IAM Roles Anywhere は、パブリックキーインフラストラクチャ (PKI) を使用して一時的なセキュリティ認証情報を使用してワークロードへのアクセスを許可する IAM の拡張機能です。CA または AWS Private CA を介して発行できる X.509 証明書を使用して、CA と IAM Roles Anywhere の間にトラストアンカーを確立できます。IAM ロールと同様に、ワークロードはロールにアタッチされているアクセス許可ポリシーに基づいて AWS のサービスにアクセスできます。
次の図は、IAM Roles Anywhere を使用して AWS を外部リソースに接続する方法を示しています。
-
信頼アンカーを作成して、AWS アカウントとオンプレミスワークロードに証明書を発行する CA との間に信頼を確立します。証明書は、IAM Roles Anywhere でトラストアンカー (信頼のルート) として登録する CA によって発行されます。CA は、既存のパブリックキーインフラストラクチャ (PKI) システムの一部にすることも、AWS Private Certificate Authority
で作成して ACM で管理する CA にすることもできます。この例では、ACM を使用しています。 -
アプリケーションは IAM Roles Anywhere に認証リクエストを行い、パブリックキー (証明書にエンコード) と、対応するプライベートキーによって署名された署名を送信します。アプリケーションは、リクエストで引き受けるロールも指定します。
-
IAM Roles Anywhere はリクエストを受け取ると、まずパブリックキーで署名を検証し、次に証明書がトラストアンカーによって発行されたことを検証します。両方の検証が成功すると、アプリケーションが認証され、IAM Roles Anywhere はAWS Security Token Service (AWS STS) を呼び出して、リクエストで指定されたロールの新しいロールセッションを作成します。
-
IAM Roles Anywhere が提供する認証情報ヘルパーツールを使用して、証明書を使用して署名を作成するプロセスを管理し、エンドポイントを呼び出してセッション認証情報を取得します。このツールは、標準の JSON 形式で呼び出しプロセスに認証情報を返します。
-
IAM と PKI の間でこのブリッジ信頼モデルを使用することで、オンプレミスワークロードはこれらの一時的な認証情報 (アクセスキー、シークレットキー、セッショントークン) を使用して、IAM ロールを引き受け、長期的な認証情報を必要とせずに AWS リソースとやり取りします。これらの認証情報は、AWS CLI または AWS SDKs を使用して設定することもできます。
利点
-
永続的な認証情報はありません。アプリケーションには、広範なアクセス許可を持つ長期的な AWS アクセスキーは必要ありません。
-
きめ細かなアクセス。ポリシーは、特定のエンティティに対して引き受けることができる IAM ロールを決定します。
-
コンテキスト対応ロール。ロールは、認証されたエンティティの詳細に基づいてカスタマイズできます。
-
取り消し。信頼アクセス許可を取り消すと、エンティティがロールを引き受けることがすぐにブロックされます。
設計上の考慮事項
-
サーバーは証明書ベースの認証をサポートできる必要があります。
-
トラストアンカーが設定されたアカウント
aws:SourceAccountでaws:SourceArnまたは を使用するように信頼ポリシーをロックダウンすることをお勧めします。 -
プリンシパルタグは証明書の詳細から引き継がれます。これには、共通名 (CN)、サブジェクト代替名 (SAN)、サブジェクト、発行者が含まれます。
-
ACM を使用している場合は、AWS RAM を使用して、セキュリティアカウントからワークロードアカウントに証明書を共有します。
-
オペレーティングシステム (OS) ファイルシステムのアクセス許可を使用して、所有ユーザーへの読み取りアクセスを制限します。
-
ソースコントロールでキーをチェックしないでください。誤って変更セットに含めるリスクを軽減するために、ソースコードとは別に保存します。可能であれば、安全なストレージメカニズムの使用を検討してください。
-
証明書を更新および取り消すプロセスがあることを確認してください。
