M achine-to-machine アイデンティティ管理 - AWS 規範ガイダンス
EC2 インスタンスプロファイルAmazon Cognito クライアント認証情報の付与mTLS 接続IAM Roles Anywhere

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

M achine-to-machine アイデンティティ管理

M achine-to-machine (M2M) 認証を使用すると、AWS で実行されるサービスとアプリケーションは、相互に安全に通信してリソースとデータにアクセスできます。マシン認証システムは、長期的な静的認証情報を使用する代わりに、一時的な認証情報またはトークンを発行して、信頼できるマシンを識別します。これにより、人間の介入なしに環境の特定の部分にアクセスできるマシンを正確に制御できます。適切に設計されたマシン認証は、広範な認証情報の公開を制限し、アクセス許可の動的な取り消しを可能にし、認証情報のローテーションを簡素化することで、セキュリティ体制を向上させるのに役立ちます。マシン認証の一般的な方法には、EC2 インスタンスプロファイル、Amazon Cognito クライアント認証情報付与、相互認証 TLS (mTLS) 接続、IAM Roles Anywhere などがあります。このセクションでは、AWS で安全かつスケーラブルな M2M 認証フローを実装するためのガイダンスを提供します。

EC2 インスタンスプロファイル

Amazon Elastic Compute Cloud (Amazon EC2) で実行されているアプリケーションまたはサービスで AWS APIs、EC2 インスタンスプロファイルの使用を検討してください。インスタンスプロファイルを使用すると、EC2 インスタンスで実行されるアプリケーションは、静的で存続期間の長い IAM アクセスキーを必要とせずに、他の AWS のサービスに安全にアクセスできます。代わりに、IAM ロールをインスタンスに割り当てて、インスタンスプロファイルを通じて必要なアクセス許可を付与する必要があります。EC2 インスタンスは、インスタンスプロファイルから一時的なセキュリティ認証情報を自動的に取得して、他の AWS のサービスにアクセスできます。 

このシナリオを以下に図表で示します。

machine-to-machine ID 管理に EC2 インスタンスプロファイルを使用する

  1. AWS API を呼び出す必要がある EC2 インスタンス上のアプリケーションは、インスタンスメタデータ項目 からロールによって提供されるセキュリティ認証情報を取得しますiam/security-credentials/<role-name>。 

  2. アプリケーションはAccessKeyId、AWS API リクエストの署名に使用できる SecretAccessKey、、および シークレットトークンを受け取ります。

  3. アプリケーションは AWS API を呼び出します。ロールが API アクションを許可すると、リクエストは成功します。

AWS リソースでの一時的な認証情報の使用の詳細については、IAM ドキュメントの「AWS リソースでの一時的な認証情報の使用」を参照してください。

利点

  • セキュリティを強化しました。この方法では、EC2 インスタンスへの長期的な認証情報の配布を回避できます。認証情報は、インスタンスプロファイルを通じて一時的に提供されます。 

  • 簡単な統合。インスタンスで実行されるアプリケーションは、追加のコーディングや設定を行うことなく、認証情報を自動的に取得できます。AWS SDKs、インスタンスプロファイル認証情報を自動的に使用します。

  • 動的アクセス許可。インスタンスプロファイルに割り当てられた IAM ロールを更新することで、インスタンスで使用できるアクセス許可を変更できます。更新されたアクセス許可を反映する新しい認証情報が自動的に取得されます。 

  • ローテーション。AWS は一時的な認証情報を自動的にローテーションして、認証情報が侵害されるリスクを軽減します。 

  • 取り消し。インスタンスプロファイルからロールの割り当てを削除することで、認証情報をすぐに取り消すことができます。

設計上の考慮事項

  • EC2 インスタンスは、アタッチされたインスタンスプロファイルを 1 つだけ持つことができます。

  • 最小特権の IAM ロールを使用します。インスタンスプロファイルの IAM ロールに、アプリケーションに必要なアクセス許可のみを割り当てます。最小限のアクセス許可から開始し、必要に応じて後でアクセス許可を追加します。 

  • ロールポリシーで IAM 条件を使用して、タグ、IP アドレス範囲、時刻などに基づいてアクセス許可を制限します。これにより、アプリケーションがアクセスできるサービスとリソースが制限されます。

  • 必要なインスタンスプロファイルの数を考慮してください。EC2 インスタンスで実行されるすべてのアプリケーションは、同じプロファイルを共有し、同じ AWS アクセス許可を持ちます。同じインスタンスプロファイルを複数の EC2 インスタンスに適用できるため、必要に応じてインスタンスプロファイルを再利用することで、管理オーバーヘッドを削減できます。

  • アクティビティをモニタリングします。AWS などのツールを使用して CloudTrail 、インスタンスプロファイルの認証情報を使用する API コールをモニタリングします。認証情報の侵害を示す可能性のある異常なアクティビティを監視します。 

  • 不要な認証情報を削除します。未使用のインスタンスプロファイルからロール割り当てを削除して、認証情報の使用を防ぎます。IAM アクセスアドバイザーを使用して、未使用のロールを特定できます。 

  • アクセスPassRole許可を使用して、ユーザーがインスタンスを起動するときに EC2 インスタンスに渡すことができるロールを制限します。これにより、ユーザーが付与されたアクセス許可よりも多くのアクセス許可を持つアプリケーションを実行できなくなります。

  • アーキテクチャが複数の AWS アカウントにまたがる場合は、あるアカウントの EC2 インスタンスが別のアカウントのリソースにアクセスする方法を検討してください。クロスアカウントロールを適切に使用して、長期的な AWS セキュリティ認証情報を埋め込むことなく、安全なアクセスを確保します。

  • インスタンスプロファイルを大規模に管理するには、次のいずれかのオプションを使用できます。

    • AWS Systems Manager Automation ランブックを使用して、インスタンスプロファイルと EC2 インスタンスの関連付けを自動化します。これは、起動時またはインスタンスの実行後に実行できます。

    • AWS コンソールで設定するのではなく、AWS CloudFormation を使用して、作成時に EC2 インスタンスにプログラムでインスタンスプロファイルを適用します。

  • VPC エンドポイントを使用して、EC2 インスタンスで実行されるアプリケーションから Amazon S3 や Amazon DynamoDB などのサポートされている AWS サービスにプライベートに接続することをお勧めします。 

Amazon Cognito クライアント認証情報の付与

Amazon Cognito は、マネージド型のカスタマー ID およびアクセス管理サービスです。Amazon Cognito は、OAuth 準拠の認証フローを提供します。これには、クライアント認証情報付与タイプを通じてユーザーではなく、マシンまたはアプリケーションを認証する機能が含まれます。この権限により、アプリケーションは一時的な AWS 認証情報を直接取得して AWS のサービスにアクセスできるようになります。Amazon Cognito クライアント認証情報は、人間のユーザーによる操作なしでアプリケーションに AWS アクセス許可を付与するための安全な方法です。アプリケーションは、クライアント ID とクライアントシークレットを Amazon Cognito トークンエンドポイントに提示します。代わりに、アクセストークンを受け取ります。このトークンを使用して、さまざまなリソースやサービスへの後続のリクエストを認証できます。このアクセスの範囲は、クライアント ID に関連付けられたアクセス許可によって決まります。リクエストを受け取るアプリケーションは、署名、有効期限のタイムスタンプ、対象者を確認してトークンを検証する必要があります。これらのチェックの後、アプリケーションはトークン内のクレームを検証することで、リクエストされたアクションが許可されていることを確認します。

次の図は、この方法を示しています。

machine-to-machine ID 管理に Amazon Cognito クライアント認証情報を使用する

  1. サーバー (リソースサーバー) からリソースをリクエストするアプリケーション (App Client) は、Amazon Cognito にトークンをリクエストします。

  2. Amazon Cognito ユーザープールはアクセストークンを返します。

  3. App Client は Resource Server にリクエストを送信し、アクセストークンを含めます。

  4. Resource Server は Amazon Cognito でトークンを検証します。

  5. 検証が成功し、リクエストされたアクションが許可されている場合、Resource Server はリクエストされたリソースで応答します。

利点

  • マシン認証。この方法では、ユーザーコンテキストやログインは必要ありません。アプリケーションはトークンで直接認証します。

  • 短期認証情報。アプリケーションは、まず Amazon Cognito からアクセストークンを取得し、次に時間制限付きアクセストークンを使用してリソースサーバーからデータにアクセスできます。

  • OAuth2 のサポート。この方法では、確立された OAuth2 標準に従っているため、不整合が軽減され、アプリケーション開発に役立ちます。

  • セキュリティを強化しました。クライアント認証情報の付与を使用すると、API キー認証メカニズムとは異なり、クライアント ID とクライアントシークレットがリソースサーバーに転送されないため、セキュリティが強化されます。クライアント ID とシークレットは共有され、Amazon Cognito を呼び出して時間制限付きアクセストークンを取得する場合にのみ使用されます。

  • スコープによるきめ細かなアクセスコントロール。アプリケーションは、スコープと追加のクレームを定義してリクエストし、特定のリソースのみへのアクセスを制限できます。

  • 監査証跡。によって収集された情報を使用して CloudTrail 、Amazon Cognito に対するリクエスト、リクエスト元の IP アドレス、リクエスト者、リクエスト日時などの詳細を確認できます。 

設計上の考慮事項

  • 各クライアント ID のアクセス範囲を慎重に定義し、必要最小限に制限します。スコープを絞り込むと、潜在的な脆弱性が軽減され、サービスが必要なリソースにのみアクセスできるようになります。 

  • AWS Secrets Manager などの安全なストレージサービスを使用して認証情報を保存することで、クライアント IDs とシークレットを保護します。 AWS Secrets Manager 認証情報をソースコードにチェックインしないでください。

  • や などのツールを使用して、トークンのリクエストと使用状況を監視 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 を示しています。

EC2 インスタンスで実行されているアプリケーションの mTLS 認証

  1. API Gateway は、パブリックに信頼された証明書を AWS Certificate Manager (ACM) から直接リクエストします。

  2. ACM は認証機関 (CA) から証明書を生成します。

  3. API を呼び出すクライアントは、API リクエストで証明書を提示します。

  4. API Gateway は、作成した Amazon S3 トラストストアバケットをチェックします。このバケットには、API にアクセスするために信頼する X.509 証明書が含まれています。API Gateway がリクエストを続行するには、証明書の発行者とルート CA 証明書までの完全な信頼チェーンが信頼ストアにある必要があります。

  5. クライアントの証明書が信頼されている場合、API Gateway はリクエストを承認し、 メソッドを呼び出します。

  6. 関連付けられた 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 または証明書失効リスト (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 を外部リソースに接続する方法を示しています。

ID 管理に IAM Roles Anywhere machine-to-machine を使用する

  1. 信頼アンカーを作成して、AWS アカウントとオンプレミスワークロードに証明書を発行する CA との間に信頼を確立します。証明書は、IAM Roles Anywhere で信頼アンカー (信頼ルート) として登録する CA によって発行されます。CA は、既存のパブリックキーインフラストラクチャ (PKI) システムの一部にすることも、AWS Private Certificate Authority で作成して ACM で管理する CA にすることもできます。この例では、ACM を使用しています。

  2. アプリケーションは IAM Roles Anywhere に認証リクエストを行い、パブリックキー (証明書にエンコード) と、対応するプライベートキーによって署名された署名を送信します。アプリケーションは、リクエストで引き受けるロールも指定します。

  3. IAM Roles Anywhere はリクエストを受信すると、まずパブリックキーを使用して署名を検証し、次に証明書がトラストアンカーによって発行されたことを検証します。両方の検証が成功すると、アプリケーションは認証され、IAM Roles Anywhere は AWS Security Token Service (AWS STS) を呼び出して、リクエストで指定されたロールの新しいロールセッションを作成します。

  4. IAM Roles Anywhere が提供する認証情報ヘルパーツールを使用して、証明書を使用して署名を作成するプロセスを管理し、エンドポイントを呼び出してセッション認証情報を取得します。このツールは、標準の JSON 形式で呼び出しプロセスに認証情報を返します。

  5. IAM と PKI の間でこのブリッジ信頼モデルを使用することで、オンプレミスワークロードはこれらの一時的な認証情報 (アクセスキー、シークレットキー、セッショントークン) を使用して、IAM ロールを引き受け、長期的な認証情報を必要とせずに AWS リソースとやり取りします。これらの認証情報は、AWS CLI または AWS SDKs を使用して設定することもできます。

利点

  • 永続的な認証情報はありません。アプリケーションには、幅広いアクセス許可を持つ長期的な AWS アクセスキーは必要ありません。 

  • きめ細かなアクセス。ポリシーは、特定のエンティティに対して引き受けることができる IAM ロールを決定します。 

  • コンテキスト対応のロール。ロールは、認証されたエンティティの詳細に基づいてカスタマイズできます。

  • 取り消し。信頼アクセス許可を取り消すと、エンティティがロールを引き受けるのを直ちにブロックします。

設計上の考慮事項

  • サーバーは証明書ベースの認証をサポートできる必要があります。 

  • 信頼アンカーが設定されたアカウントaws:SourceAccountで aws:SourceArnまたは を使用するように信頼ポリシーをロックダウンすることをお勧めします。 

  • プリンシパルタグは証明書の詳細から引き継がれます。これには、共通名 (CN)、サブジェクト代替名 (SAN)、サブジェクト、発行者が含まれます。

  • ACM を使用している場合は、AWS RAM を使用して、セキュリティアカウントからワークロードアカウントに証明書を共有します。

  • オペレーティングシステム (OS) ファイルシステムのアクセス許可を使用して、所有ユーザーへの読み取りアクセスを制限します。

  • キーをソースコントロールにチェックインしないでください。誤って変更セットに含めるリスクを軽減するために、ソースコードとは別に保存します。可能であれば、安全なストレージメカニズムの使用を検討してください。

  • 証明書をローテーションして取り消すプロセスがあることを確認してください。