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

# 初期ユーザーを追加する
<a name="add-initial-users"></a>

ユーザーに AWS アカウントアクセスを許可するには、2 つの方法があります。
+ IAM ID (ユーザー、グループ、ロール)
+ の使用などによる ID フェデレーション AWS IAM アイデンティティセンター

小規模な企業やシングルアカウント環境では、新しい人が入社したときに管理者が IAM ユーザーを作成するのが一般的です。IAM ユーザーに関連付けられたアクセスキーとシークレットキーの認証情報は、有効期限がないため、長期認証情報と呼ばれます。ただし、攻撃者がこれらの認証情報を侵害した場合、そのユーザー用に新しい認証情報を生成する必要があるため、セキュリティのベストプラクティスとして推奨されていません。にアクセスするもう 1 つの方法は、[IAM ロール](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/)を使用すること AWS アカウント です。[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) を使用して、設定した時間が経過すると有効期限が切れる短期認証情報を一時的にリクエストすることもできます。

[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) AWS アカウント を使用して、 へのユーザーアクセスを管理できます。従業員や契約社員ごとに個別のユーザーアカウントを作成したり、各自のパスワードや多要素認証 (MFA) ソリューションを管理したり、グループ化してアクセスを管理したりできます。MFA を設定するときは、認証アプリケーションなどのソフトウェアトークンを使用するか、YubiKey デバイスなどのハードウェアトークンを使用できます。

IAM アイデンティティセンターは、Okta、JumpCloud、Ping ID などの外部 ID プロバイダー (IdP) からのフェデレーションもサポートしています。詳細については、「[Supported identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。外部 IdP とフェデレーションすることで、アプリケーション全体のユーザー認証を管理し、IAM アイデンティティセンターを使用して特定の AWS アカウントへのアクセスを認可できます。

## ベストプラクティス
<a name="users-best-practices"></a>
+ ユーザーアクセスの設定は、「[セキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」(IAM ドキュメント) を順守します。
+ アカウントアクセスを個々のユーザーではなくグループごとに管理します。IAM アイデンティティセンターに、各ビジネス機能を代表する新しいグループを作成します。例えば、エンジニアリング、財務、営業、製品管理のグループなどです。
+ 多くの場合、すべての AWS アカウント にアクセス (多くは読み取り専用アクセス) する必要のあるユーザーと、1 つの AWS アカウントへのアクセス権を必要とするユーザーを分けることで、グループを定義します。グループに関連付けられた AWS アカウント および アクセス許可を簡単に識別できるように、 グループには次の命名規則を使用することをお勧めします。

  `<prefix>-<account name>-<permission set>`
+ 例えば、`AWS-A-dev-nonprod-DeveloperAccess` グループの場合、`AWS-A` が 1 つのアカウントへのアクセスを示すプレフィックスです。`dev-nonprod` がアカウント名で、`DeveloperAccess` がグループに割り当てられた許可セットです。`AWS-O-BillingAccess` グループの場合、`AWS-O` が組織全体へのアクセスを示すプレフィックスで、`BillingAccess` がグループの許可セットを示しています。この例では、グループは組織全体にアクセスできるため、グループ名にはアカウント名が含まれていません。
+ 外部の SAML ベースの IdP で IAM アイデンティティセンターを使用していて、MFA が必要な場合は、属性ベースのアクセス制御 (ABAC) を使用して、認証方法を IdP から IAM アイデンティティセンターに渡すことができます。属性は SAML アサーションを通じて送信されます。詳細については、「[Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。

  Microsoft Azure Active Directory や Okta などの多くの IdP は、SAML アサーション内で認証方法リファレンス (`amr`) クレームを使用して、ユーザーの MFA ステータスを IAM アイデンティティセンターに渡すことができます。MFA ステータスのアサートに使用されるクレームとその形式は IdP によって異なります。詳細については、IdP のドキュメントを参照してください。

  IAM Identity Center では、 AWS リソースにアクセスできるユーザーを決定するアクセス許可セットポリシーを作成できます。ABAC を有効にして属性を指定すると、IAM アイデンティティセンターは認証されたユーザーの属性値を IAM に渡し、ポリシー評価で使用できるようにします。詳細については、「[Create permission policies for ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。次の例に示すように、`aws:PrincipalTag` 条件キーを使用して MFA のアクセス制御ルールを作成します。

  ```
  "Condition": {
    "StringLike": { "aws:PrincipalTag/amr": "mfa" }
  }
  ```