SEC03-BP01 アクセス要件を定義する - AWS Well-Architected フレームワーク
実装のガイダンスリソース

SEC03-BP01 アクセス要件を定義する

ワークロードの各コンポーネントやリソースには、管理者、エンドユーザー、またはその他のコンポーネントによるアクセスが必要です。各コンポーネントへのアクセス権のある人とマシンを明確に定義し、適切な ID のタイプと、認証および認可の方法を選択します。

一般的なアンチパターン:

  • シークレットをハードコーディングする、またはアプリケーション内に格納する

  • 各ユーザーにカスタムのアクセス許可を付与する

  • 永続的な認証情報を使用する

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

ワークロードの各コンポーネントやリソースには、管理者、エンドユーザー、またはその他のコンポーネントによるアクセスが必要です。各コンポーネントへのアクセス権のある人とマシンを明確に定義し、適切な ID のタイプと、認証および認可の方法を選択します。

組織内の AWS アカウントへの定期的なアクセスは、フェデレーションアクセスか一元化された ID プロバイダーを使用して提供する必要があります。また、アイデンティティ管理を一元化し、AWS へのアクセスを従業員のアクセスライフサイクルに統合するための確立されたプラクティスを整備する必要があります。例えば、従業員がアクセスレベルの異なる職種に異動するときは、そのグループメンバーシップも新しいアクセス要件を反映するように変更される必要があります。

非人間アイデンティティのアクセス要件を定義するときは、どのアプリケーションとコンポーネントがアクセスを必要としているか、またアクセス許可をどのように付与するかを決定します。推奨されるアプローチは、最小特権アクセスモデルで構築されたロールを使用する方法です。AWSマネージドポリシーは、最も一般的なユースケースをカバーする、事前定義済みの IAM ポリシーを提供します。

AWS Secrets Manager や AWS Systems Manager Parameter Store などの AWS のサービスは、IAM ロールを使用することが不可能な場合に、アプリケーションまたはワークロードからシークレットを安全に分離するのに役立ちます。Secrets Manager では、認証情報の自動ローテーションを確立できます。Secrets Manager でパラメータの作成時に指定した一意の名前を使用することで、スクリプト、コマンド、SSM ドキュメント、設定、自動化ワークフロー内のパラメータを参照できます。

AWS IAM Roles Anywhere を使用すると、AWS の外部で実行されるワークロード IAM における一時的セキュリティ認証情報を取得できます。ワークロードでは、AWS アプリケーションが AWS リソースにアクセスする際に使用するのと同じ IAM ポリシーと IAM ロールを使用できます。

可能な場合は、長期の静的な認証情報よりも、短期の一時的な認証情報を優先します。プログラムによるアクセスと長期的認証情報を持つユーザーが必要なシナリオでは、アクセスキーが最後に使用した情報を使用して、アクセスキーをローテーションおよび削除します。

AWS Management Console の外部で AWS を操作するには、ユーザーはプログラムによるアクセスが必要です。プログラマチックアクセス権を付与する方法は、AWS にアクセスしているユーザーのタイプによって異なります。

ユーザーにプログラマチックアクセス権を付与するには、以下のいずれかのオプションを選択します。

プログラマチックアクセス権を必要とするユーザー 目的 方法

ワークフォースアイデンティティ

(IAM アイデンティティセンターで管理されているユーザー)

 一時的な認証情報を使用して、AWS CLI、AWS SDK、または AWS API へのプログラマチックリクエストに署名します。

使用するインターフェイス用の手引きに従ってください。
IAM 一時的な認証情報を使用して、AWS CLI、AWS SDK、または AWS API へのプログラムによるリクエストに署名します。 「IAM ユーザーガイド」の「AWS リソースでの一時的な認証情報の使用」の指示に従ってください。
IAM

(非推奨)

長期的な認証情報を使用して、AWS CLI、AWS SDK、AWS API へのプログラムによるリクエストに署名します。

使用するインターフェイス用の手順に従ってください。

リソース

関連ドキュメント:

関連動画: