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

# ベストプラクティス
<a name="auth-best-practices"></a>

このセクションでは、Amazon Location Service アプリケーションを保護し、認証の使用を最適化するためのベストプラクティスの概要を説明します。認証情報の分離、モニタリング、適切な制限を実装することで、セキュリティリスクを最小限に抑え、コストを管理できます。API キー、Amazon Cognito、および の選択に関するガイダンスについては AWS Identity and Access Management、「」を参照してください[認証方法の選択](auth-choose-method.md)。

## 認証情報管理
<a name="auth-bp-credential-management"></a>

適切な認証情報管理により、セキュリティリスクが軽減され、アクセスをローテーションまたは取り消す必要がある場合のオペレーションが簡素化されます。
+ **アプリケーションごとに個別の認証情報を使用する** – アプリケーションまたは環境 (開発、ステージング、本番稼働) ごとに個別の API キーまたは IAM ロールを作成します。これにより、認証情報が侵害された場合のブラスト半径が制限されます。
+ **最小特権の原則を適用する** – 各ユースケースに必要な最小限のアクセス許可のみを付与します。ワイルドカードを使用するのではなくAPIs とリソースへのアクセスを制限します。
+ **認証情報を定期的にローテーション**する – API キーを定期的にローテーションし、IAM ポリシーを確認します。未使用の認証情報はすぐに削除します。
+ **ソースコードに認証情報を公開しない** – API キー、Amazon Cognito ID プール IDs、およびその他の機密値を環境変数、シークレットマネージャー、または安全な設定ストアに保存します。バージョン管理にコミットしないでください。

## API キーの最適化
<a name="auth-bp-apikeys"></a>

API キーを使用すると、マップ、場所、およびルートリソースへの認証されていない読み取り専用アクセスを簡単に付与できます。セキュリティリスクを最小限に抑え、使用を最適化するには、以下のプラクティスに従います。
+ **アクションとリソースの制限** – API キーを作成するときは、アプリケーションに必要なアクションとリソースのみを指定します。たとえば、マップのみのアプリケーションは、マッププロバイダーリソースに対する`geo-maps:*`アクションのみを許可する必要があります。
+ **クライアント制限の適用** – ウェブアプリケーションのドメインリファラー制限、または Android および iOS アプリケーションのアプリケーション識別子制限を設定します。これにより、不正なオリジンでキーが使用されなくなります。詳細については、「[リクエストオリジン別の API キーの使用を制限する](#restrict-usage-by-origin)」を参照してください。
+ **有効期限の設定** – キーの有効期限を使用して定期的なローテーションを適用します。古いキーの有効期限が切れる前に新しいキーを作成し、アプリケーションを更新してから、古いキーを非アクティブ化します。
+ **キーごとの使用状況のモニタリング** – `ApiKeyName`ディメンションで CloudWatch メトリクスを使用して、各キーの使用状況を個別に追跡します。で予期しないスパイクにアラームを設定します`CallCount`。
+ **未使用のキーの削除** – API キーを定期的に監査し、使用されなくなったキーをすべて削除します。非アクティブ化された非アクティブなキーは、90 日後に削除できます。

## リクエストオリジン別の API キーの使用を制限する
<a name="restrict-usage-by-origin"></a>

特定のドメインまたはモバイルアプリケーションへのアクセスを制限するクライアント制限を使用して API キーを設定できます。ドメインで制限する場合、サービスは HTTP リファラーヘッダーが指定した値と一致する場合にのみリクエストを承認します。Android または Apple アプリケーションによって制限する場合、サービスはアプリケーション識別子の HTTP ヘッダーフィールドが指定した値と一致する場合にのみリクエストを承認します。

API キーの制限の詳細については、*Amazon Location Service API リファレンス*の[ApiKeyRestrictions](https://docs.aws.amazon.com/location/latest/APIReference/API_geoapikeys_ApiKeyRestrictions.html)」を参照してください。

 **Android アプリケーション識別子:** 
+ `X-Android-Package`:

  Android アプリケーションの一意の識別子。アプリの `build.gradle` ファイルで定義され、通常はリバースドメイン形式に従います。

  例:

   `com.mydomain.appname` 
+ `X-Android-Cert`:

  Android APK の署名に使用される署名証明書の SHA-1 ハッシュ。

  例:

   `BB:0D:AC:74:D3:21:E1:43:67:71:9B:62:91:AF:A1:66:6E:44:5D:75` 

 **Apple アプリケーション識別子:** 
+ `X-Apple-Bundle-Id`:

  Apple (iOS、macOS など) アプリケーションの一意の識別子。アプリケーションの `Info.plist` で定義され、通常はリバースドメイン形式に従います。

  例:

   `com.mydomain.appname` 

## Amazon Cognito 最適化
<a name="auth-bp-cognito"></a>

Amazon Cognito は、API キーよりも詳細なアクセスコントロールを提供し、認証されたユーザーと認証されていないユーザーの両方をサポートします。
+ **認証されていないロールの範囲を絞り込む** – 匿名アクセスに ID プールを使用する場合は、アプリケーションが必要とする特定の Amazon Location アクションとリソースのみを許可する IAM ポリシーをアタッチします。
+ **IP フィルタリングに条件キー**を使用する – IAM ポリシーに`aws:SourceIp`条件を追加して、必要に応じて既知の IP 範囲へのアクセスを制限します。
+ **ID プールを同じリージョンに保持する** – Amazon Location Service リソースと同じ AWS リージョンに Amazon Cognito ID プールを作成して、リージョン間のレイテンシーを回避し、適切なアクセスを確保します。
+ **可能な場合は認証された ID を使用する** – アプリケーションにサインインフローがある場合は、Amazon Cognito ユーザープールまたはフェデレーティッド ID を使用して、認証されていないアクセスに依存するのではなく、特定のアクセス許可を持つ認証されたロールを付与します。

## IAM 最適化
<a name="auth-bp-iam"></a>

サーバー側のアプリケーションと内部ツール AWS Identity and Access Management の場合は、 を使用してアクセスを完全に制御します。
+ **長期認証情報の代わりに IAM ロール**を使用する – AWS コンピューティングサービス (Amazon EC2、Lambda、Amazon ECS など) で実行されているアプリケーションの場合、IAM ロールを使用して一時的な認証情報を自動的に提供します。
+ **リソースレベルのアクセス許可を適用する** – ワイルドカードを使用するのではなく、ポリシーでリソース ARNs を指定します。たとえば、特定のトラッカーまたはジオフェンスコレクションリソースへのアクセスを制限します。
+ **ポリシー条件を使用する** – 特定のリージョンへのアクセスを制限する`aws:RequestedRegion`条件や、属性ベースのアクセスコントロール`aws:PrincipalTag`の条件を追加します。
+ **CloudTrail を有効にする** – を使用して AWS CloudTrail 、監査とコンプライアンスのためにすべての Amazon Location Service API コールをログに記録します。予期しないアクセスパターンがないかログを定期的に確認します。