기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 초기 사용자 추가
<a name="add-initial-users"></a>

사용자에게 AWS 계정에 대한 액세스 권한을 부여하는 방법은 두 가지입니다.
+ IAM 보안 인증(예: 사용자, 그룹 및 역할)
+ 를 사용한 것과 같은 자격 증명 페더레이션 AWS IAM Identity Center

소규모 회사와 단일 계정 환경에서는 신규 직원이 입사할 때 관리자가 IAM 사용자를 생성하는 것이 일반적입니다. IAM 사용자에게 연결된 액세스 키와 시크릿 키 보안 인증 정보는 만료되지 않기 때문에 **장기 보안 인증 정보라고 합니다. 그러나 공격자가 해당 보안 인증 정보를 손상시킨 경우 사용자에 대한 새로운 보안 인증 정보 세트를 생성해야 하므로 이는 권장되는 보안 모범 사례가 아닙니다. 에 액세스하는 또 다른 방법은 [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 Identity Center는 Okta, JumpCloud, Ping Identity와 같은 외부 ID 제공업체(idP)와의 페더레이션을 지원합니다. 자세한 내용은 [Supported identity providers](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)(IAM Identity Center 설명서)를 참조하세요. 외부 IdP와 페더레이션하면 애플리케이션 간에 사용자 인증을 관리한 다음 IAM Identity Center를 사용하여 특정에 대한 액세스를 승인할 수 있습니다 AWS 계정.

## 모범 사례
<a name="users-best-practices"></a>
+ 사용자 액세스 구성에 대한 [보안 모범 사례](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)(IAM 설명서)를 준수합니다.
+ 개별 사용자가 아닌 그룹별로 계정 액세스를 관리합니다. IAM Identity Center에서 각 비즈니스 기능을 나타내는 새 그룹을 생성합니다. 예를 들어, 엔지니어링, 재무, 영업, 제품 관리를 위한 그룹을 생성할 수 있습니다.
+ 모든 AWS 계정 에 액세스(대개 읽기 전용 액세스)해야 하는 사용자와 단일 AWS 계정에 액세스해야 하는 사용자를 구분하여 그룹을 정의하는 경우가 많습니다. 그룹과 연결된 AWS 계정 및 권한을 쉽게 식별할 수 있도록 그룹에 다음 이름 지정 규칙을 사용하는 것이 좋습니다.

  `<prefix>-<account name>-<permission set>`
+ 예를 들어, `AWS-A-dev-nonprod-DeveloperAccess` 그룹의 경우 `AWS-A`는 단일 계정에 대한 액세스를 나타내는 접두사이고, `dev-nonprod`는 계정 이름이고, `DeveloperAccess`는 그룹에 할당된 권한 세트입니다. `AWS-O-BillingAccess` 그룹의 경우 `AWS-O` 접두사는 전체 조직에 대한 액세스를 나타내고 `BillingAccess`는 그룹에 대한 권한 세트를 나타냅니다. 이 예시에서는 그룹이 전체 조직에 액세스할 수 있기 때문에 그룹 이름에 계정 이름이 표시되지 않습니다.
+ 외부 SAML 기반 IdP와 함께 IAM Identity Center를 사용하고 있고 MFA를 요구하려는 경우 ABAC(속성 기반 액세스 제어)를 사용하여 IdP에서 IAM Identity Center로 인증 방법을 전달할 수 있습니다. 속성은 SAML 어설션을 통해 전송됩니다. 자세한 내용은 [Enable and configure attributes for access control](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)(IAM Identity Center 설명서)을 참조하세요.

  Microsoft Azure Active Directory 및 Okta와 같은 많은 IdP는 SAML 어설션 내의 `amr`(Authentication Method Reference) 클레임을 사용하여 사용자의 MFA 상태를 IAM Identity Center에 전달할 수 있습니다. MFA 상태를 확인하는 데 사용되는 클레임과 해당 형식은 IdP에 따라 다릅니다. 자세한 내용은 IdP 설명서를 참조하세요.

  그런 다음 IAM Identity Center에서 AWS 리소스에 액세스할 수 있는 사용자를 결정하는 권한 세트 정책을 생성할 수 있습니다. ABAC를 활성화하고 속성을 지정하면 IAM Identity Center가 정책 평가에 사용할 인증된 사용자의 속성 값을 IAM으로 전달합니다. 자세한 내용은 [Create permission policies for ABAC](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html)(IAM Identity Center 설명서)를 참조하세요. 다음 예와 같이 `aws:PrincipalTag` 조건 키를 사용하여 MFA에 대한 액세스 제어 규칙을 생성합니다.

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