gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

Browse Source
This commit is contained in:
Translator
2025-03-21 09:07:29 +00:00
parent 32a6626876
commit e09752ba8f
1 changed files with 53 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-basic-information/README.md
+53 -51
View File
@@ -10,11 +10,11 @@
AWS에는 **루트 계정**이 있으며, 이는 **조직의 모든 계정에 대한 부모 컨테이너**입니다. 그러나 리소스를 배포하기 위해 해당 계정을 사용할 필요는 없으며, **다른 계정을 생성하여 서로 다른 AWS** 인프라를 분리할 수 있습니다.
이는 **보안** 관점에서 매우 흥미롭습니다. **하나의 계정은 다른 계정의 리소스에 접근할 수 없습니다** (특별히 브리지가 생성되지 않는 한), 따라서 이 방법으로 배포 간의 경계를 만들 수 있습니다.
이는 **보안** 관점에서 매우 흥미로운데, **하나의 계정은 다른 계정의 리소스에 접근할 수 없기 때문**입니다(특별히 브리지가 생성되지 않는 한). 따라서 배포 간에 경계를 만들 수 있습니다.
따라서 **조직에는 두 가지 유형의 계정**이 있습니다 (우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
따라서 **조직에는 두 가지 유형의 계정**이 있습니다(우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
- **관리 계정 (루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
- **관리 계정(루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
- 조직 내에서 계정 생성
- 다른 기존 계정을 조직에 초대
@@ -26,27 +26,27 @@ AWS에는 **루트 계정**이 있으며, 이는 **조직의 모든 계정에
관리 계정은 **지불 계정의 책임**을 지며, 멤버 계정에서 발생하는 모든 요금을 지불할 책임이 있습니다. 조직의 관리 계정을 변경할 수 없습니다.
- **멤버 계정**은 조직의 나머지 모든 계정을 구성합니다. 계정은 한 번에 하나의 조직의 멤버일 수 있습니다. 계정에 정책을 연결하여 해당 계정에만 제어를 적용할 수 있습니다.
- 멤버 계정은 **유효한 이메일 주소를 사용해야** 하며 **이름**을 가질 수 있습니다. 일반적으로 청구를 관리할 수는 없지만 접근 권한이 부여될 수 있습니다.
- **멤버 계정**은 조직의 나머지 모든 계정을 구성합니다. 계정은 한 번에 하나의 조직의 멤버일 수 있습니다. 계정에 정책을 첨부하여 해당 계정에만 제어를 적용할 수 있습니다.
- 멤버 계정은 **유효한 이메일 주소를 사용해야 하며** **이름**을 가질 수 있으며, 일반적으로 청구를 관리할 수는 없지만 접근 권한이 부여될 수 있습니다.
```
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
```
### **조직 단위**
계정을 **조직 단위 (OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 **정책**을 생성할 수 있으며, 이 정책은 **모든 자식 계정에 적용됩니다**. OU는 다른 OU를 자식으로 가질 수 있습니다.
계정을 **조직 단위(OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 **정책**을 생성할 수 있으며, 이 정책은 **모든 자식 계정에 적용됩니다**. OU는 다른 OU를 자식으로 가질 수 있습니다.
```bash
# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
```
### Service Control Policy (SCP)
A **service control policy (SCP)**는 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 **IAM** 권한 정책과 유사하지만 **권한을 부여하지 않습니다**. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 **최대 권한**을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 **SCP가 구성원 계정의 엔터티에 대한 권한을 제한합니다**.
A **service control policy (SCP)**는 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스 및 작업을 지정하는 정책입니다. SCP는 **IAM** 권한 정책과 유사하지만 **권한을 부여하지 않습니다**. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 **최대 권한**을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 **SCP가 구성원 계정의 엔터티에 대한 권한을 제한합니다**.
이것은 **루트 사용자조차도 무언가를 하는 것을 막을 수 있는 유일한 방법**입니다. 예를 들어, 사용자가 CloudTrail을 비활성화하거나 백업을 삭제하는 것을 막는 데 사용할 수 있습니다.\
이를 우회하는 유일한 방법은 SCP를 구성하는 **마스터 계정**을 손상시키는 것입니다(마스터 계정은 차단할 수 없습니다).
> [!WARNING]
> **SCP는 계정의 주체를 제한할 뿐**이므로 다른 계정에는 영향을 미치지 않습니다. 이는 SCP가 `s3:GetObject`를 거부하더라도 사람들이 **귀하의 계정의 공개 S3 버킷에 접근하는 것을 막지 않습니다**.
> **SCP는 계정의 주체만 제한**하므로 다른 계정에는 영향을 미치지 않습니다. 이는 SCP가 `s3:GetObject`를 거부하더라도 사람들이 **귀하의 계정의 공개 S3 버킷에 접근하는 것을 막지 않습니다**.
SCP 예시:
@@ -55,7 +55,9 @@ SCP 예시:
- 화이트리스트된 서비스만 허용
- GuardDuty, CloudTrail 및 S3 공개 차단 액세스 비활성화를 거부
- 보안/사고 대응 역할이 삭제되거나 수정되는 것을 거부합니다.
- 보안/사고 대응 역할이 삭제되거나
수정되는 것을 거부합니다.
- 백업이 삭제되는 것을 거부합니다.
- IAM 사용자 및 액세스 키 생성을 거부합니다.
@@ -106,15 +108,15 @@ IAM은 AWS 계정 내 리소스에 대한 신원의 인증, 권한 부여 및
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
Amazon Web Services (AWS) 계정을 처음 생성하면 **모든** AWS 서비스와 리소스에 **완전한 액세스**를 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
Amazon Web Services (AWS) 계정을 처음 생성할 때, 모든 AWS 서비스와 리소스에 **완전한 액세스**를 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
새로운 **관리자 사용자**는 **루트 사용자보다 권한이 적습니다**.
보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 좋습니다.
보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 권장됩니다.
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
IAM _사용자_는 AWS에서 **사람이나 애플리케이션을 나타내기 위해 생성하는 엔터티**입니다. AWS의 사용자는 이름과 자격 증명(비밀번호 및 최대 두 개의 액세스 키)으로 구성됩니다.
IAM _사용자_는 AWS에서 **사람이나 애플리케이션을 나타내기 위해 생성하는 엔티티**입니다. AWS의 사용자는 이름과 자격 증명(비밀번호 및 최대 두 개의 액세스 키)으로 구성됩니다.
IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자 그룹의 구성원**으로 만들어 **권한**을 부여하거나, **정책을 사용자에게 직접 첨부**하여 권한을 부여합니다.
@@ -125,19 +127,19 @@ IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자
- **Access Key ID**: 20개의 무작위 대문자 알파벳 숫자 조합, 예: AKHDNAPO86BSHKDIRYT
- **Secret access key ID**: 40개의 무작위 대소문자 조합: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (잃어버린 비밀 액세스 키 ID를 복구할 수 없습니다).
**Access Key**를 **변경해야 할 때** 따라야 할 과정은 다음과 같습니다:\
**Access Key를 변경해야 할 때** 따라야 할 과정은 다음과 같습니다:\
_새 액세스 키 생성 -> 시스템/애플리케이션에 새 키 적용 -> 원래 키를 비활성화로 표시 -> 새 액세스 키가 작동하는지 테스트 및 확인 -> 이전 액세스 키 삭제_
### MFA - Multi Factor Authentication
기존 방법(예: 비밀번호) 외에 **인증을 위한 추가 요소를 생성**하는 데 사용되며, 따라서 다단계 인증 수준을 생성합니다.\
**무료 가상 애플리케이션이나 물리적 장치**를 사용할 수 있습니다. Google 인증과 같은 앱을 무료로 사용하여 AWS에서 MFA를 활성화할 수 있습니다.
**무료 가상 애플리케이션 또는 물리적 장치**를 사용할 수 있습니다. Google 인증과 같은 앱을 무료로 사용하여 AWS에서 MFA를 활성화할 수 있습니다.
MFA 조건이 있는 정책은 다음에 첨부될 수 있습니다:
- IAM 사용자 또는 그룹
- Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 리소스
- 사용자가 맡을 수 있는 IAM 역할의 신뢰 정책
- 사용자가 가정할 수 있는 IAM 역할의 신뢰 정책
**MFA를 확인하는** 리소스에 **CLI를 통해 접근**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
**`AssumeRole` 자격 증명에는 이 정보가 포함되어 있지 않습니다**.
@@ -148,9 +150,9 @@ As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credent
### [IAM 사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 **여러 사용자에게 정책을 동시에 연결하는** 방법으로, 이러한 사용자의 권한을 관리하기 쉽게 만들어 줍니다. **역할과 그룹은 그룹의 일부가 될 수 없습니다**.
IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)은 **여러 사용자에게 정책을 한 번에 연결하는** 방법으로, 이러한 사용자의 권한을 관리하기 쉽게 만들어 줍니다. **역할과 그룹은 그룹의 일부가 될 수 없습니다**.
**사용자 그룹에 신원 기반 정책을 연결**할 수 있어, 사용자 그룹의 **모든 사용자**가 **정책의 권한을 받게** 됩니다. **정책**(예: 리소스 기반 정책)에서 **`Principal`**로 **사용자 그룹**을 식별할 수 **없습니다**. 그룹은 인증이 아닌 권한과 관련이 있으며, 주체는 인증된 IAM 엔터티입니다.
**사용자 그룹에 ID 기반 정책을 연결**할 수 있어, 사용자 그룹의 **모든 사용자**가 **정책의 권한을 받게** 됩니다. **정책**(예: 리소스 기반 정책)에서 **`Principal`**로 **사용자 그룹**을 식별할 수 **없습니다**. 그룹은 인증이 아닌 권한과 관련이 있으며, 주체는 인증된 IAM 엔터티입니다.
사용자 그룹의 몇 가지 중요한 특성은 다음과 같습니다:
@@ -161,7 +163,7 @@ IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_group
### [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
IAM **역할**은 **사용자**와 매우 **유사**하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 **신원**입니다. 그러나 역할은 **자격 증명**(비밀번호 또는 액세스 키)이 없습니다. 역할은 한 사람과 고유하게 연결되는 것이 아니라, **필요한 사람(그리고 충분한 권한이 있는 사람)**이 **가정할 수 있도록** 설계되었습니다. **IAM 사용자는 특정 작업을 위해** 일시적으로 다른 권한을 취득하기 위해 역할을 **가정할 수 있습니다**. 역할은 IAM 대신 외부 신원 공급자를 사용하여 로그인하는 [**연합 사용자**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)에게 **할당될 수 있습니다**.
IAM **역할**은 **사용자**와 매우 **유사**하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 **신원**입니다. 그러나 역할은 **자격 증명**(비밀번호 또는 액세스 키)이 없습니다. 역할은 한 사람과 고유하게 연결되는 것이 아니라, **필요한 사람(그리고 충분한 권한이 있는 사람)**이 **가정할 수 있도록** 설계되었습니다. **IAM 사용자는 특정 작업을 위해** 일시적으로 다른 권한을 취득하기 위해 역할을 **가정할 수 있습니다**. 역할은 IAM 대신 외부 ID 공급자를 사용하여 로그인하는 [**연합 사용자**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)에게 **할당될 수 있습니다**.
IAM 역할은 **두 가지 유형의 정책**으로 구성됩니다: **비준 정책**(비어 있을 수 없음)으로 **누가 역할을 가정할 수 있는지를 정의**하고, **권한 정책**(비어 있을 수 없음)으로 **무엇에 접근할 수 있는지를 정의**합니다.
@@ -180,9 +182,9 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
권한을 할당하는 데 사용됩니다. 두 가지 유형이 있습니다:
- AWS 관리형 정책 (AWS에서 미리 구성)
- 고객 관리형 정책: 사용자가 구성합니다. AWS 관리형 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기를 사용하거나(권한을 부여하고 거부하는 데 도움을 주는 GUI 보기) 직접 작성할 수 있습니다.
- 고객 관리형 정책: 사용자가 구성. AWS 관리형 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기(권한을 부여하고 거부하는 데 도움이 되는 GUI 보기)를 사용하거나 직접 작성할 수 있습니다.
기본적으로 **접근이 거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
**기본적으로 접근은** **거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
**단일 "거부"가 존재하면 "허용"을 무시합니다**, AWS 계정의 루트 보안 자격 증명을 사용하는 요청은 기본적으로 허용됩니다.
```javascript
{
@@ -211,8 +213,8 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
#### 인라인 정책
이러한 종류의 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
인라인 정책은 **정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지**하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우연히 할당되지 않도록 확실히 하고 싶습니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
이러한 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
인라인 정책은 **정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지**하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우연히 할당되지 않도록 하고 싶습니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
#### 리소스 버킷 정책
@@ -246,18 +248,18 @@ aws sts assume-role \
### 아이덴티티 연합
아이덴티티 연합은 **AWS 외부의 아이덴티티 제공자에서 오는 사용자**가 AWS 리소스에 안전하게 접근할 수 있도록 하며, 유효한 IAM 사용자 계정의 AWS 사용자 자격 증명을 제공할 필요가 없습니다.\
아이덴티티 연합은 **AWS 외부의 아이덴티티 제공자에서 사용자**가 AWS 리소스에 안전하게 접근할 수 있도록 하여 유효한 IAM 사용자 계정의 AWS 사용자 자격 증명을 제공할 필요가 없습니다.\
아이덴티티 제공자의 예로는 귀사의 **Microsoft Active Directory** (via **SAML**) 또는 **OpenID** 서비스 (예: **Google**)가 있습니다. 연합된 접근은 그 안의 사용자들이 AWS에 접근할 수 있도록 합니다.
이 신뢰를 구성하기 위해 **IAM 아이덴티티 제공자 (SAML 또는 OAuth)**가 생성되어 **다른 플랫폼을 신뢰**합니다. 그런 다음, 최소한 하나의 **IAM 역할이 아이덴티티 제공자에 (신뢰하는) 할당됩니다**. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 언급된 역할로 접근하게 됩니다.
이 신뢰를 구성하기 위해 **IAM 아이덴티티 제공자(SAML 또는 OAuth)**가 생성되어 **다른 플랫폼을 신뢰**합니다. 그런 다음, 최소한 하나의 **IAM 역할이 아이덴티티 제공자에 할당(신뢰)**됩니다. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 언급된 역할로 접근하게 됩니다.
그러나 일반적으로 **제3자 플랫폼의 사용자 그룹에 따라 다른 역할을 부여하고 싶어할 것입니다**. 그러면 여러 **IAM 역할이 제3자 아이덴티티 제공자를 신뢰할 수 있으며**, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 가정하도록 허용하게 됩니다.
그러나 일반적으로 **제3자 플랫폼의 사용자 그룹에 따라 다른 역할을 부여**하고 싶을 것입니다. 그러면 여러 **IAM 역할이 제3자 아이덴티티 제공자를 신뢰**할 수 있으며, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 가정하도록 허용하게 됩니다.
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
### IAM 아이덴티티 센터
AWS IAM 아이덴티티 센터 (AWS Single Sign-On의 후속 제품)는 AWS 아이덴티티 및 접근 관리 (IAM)의 기능을 확장하여 **사용자 및 그들의 AWS** 계정 및 클라우드 애플리케이션에 대한 접근을 **중앙에서 관리할 수 있는 장소**를 제공합니다.
AWS IAM 아이덴티티 센터(AWS Single Sign-On의 후속 제품)는 AWS 아이덴티티 및 접근 관리(IAM)의 기능을 확장하여 **사용자 및 AWS** 계정과 클라우드 애플리케이션에 대한 접근을 **중앙에서 관리**할 수 있는 **중앙 장소**를 제공합니다.
로그인 도메인은 `<user_input>.awsapps.com`과 같은 형식이 될 것입니다.
@@ -265,23 +267,23 @@ AWS IAM 아이덴티티 센터 (AWS Single Sign-On의 후속 제품)는 AWS 아
- 아이덴티티 센터 디렉토리: 일반 AWS 사용자
- 액티브 디렉토리: 다양한 커넥터 지원
- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자 (IdP)에서 옵니다.
- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자(IdP)에서 옵니다.
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 가지고** 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 보유**하고 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
아이덴티티 센터 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 **아이덴티티 센터를 신뢰하는 SAML 아이덴티티 제공자가 생성되고**, **지정된 정책을 가진 아이덴티티 제공자를 신뢰하는 역할이 대상 계정에 생성됩니다**.
아이덴티티 센터 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 **아이덴티티 센터를 신뢰하는 SAML 아이덴티티 제공자가 생성**되고, **지정된 정책을 가진 아이덴티티 제공자를 신뢰하는 역할이 대상 계정에 생성**됩니다.
#### AwsSSOInlinePolicy
**IAM 아이덴티티 센터를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여하는 것이 가능합니다**. AWS 아이덴티티 센터에서 **인라인 정책을 가진 계정에서 생성된 역할**은 **`AwsSSOInlinePolicy`**라는 인라인 정책에서 이러한 권한을 가집니다.
**IAM 아이덴티티 센터를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여**할 수 있습니다. **AWS 아이덴티티 센터에서 인라인 정책을 가진 계정에서 생성된 역할**은 **`AwsSSOInlinePolicy`**라는 인라인 정책에서 이러한 권한을 가집니다.
따라서, **`AwsSSOInlinePolicy`**라는 인라인 정책을 가진 2개의 역할을 보더라도, **동일한 권한을 가지고 있다는 의미는 아닙니다**.
따라서, **`AwsSSOInlinePolicy`**라는 인라인 정책을 가진 2개의 역할을 보더라도, **동일한 권한을 가진다는 의미는 아닙니다**.
### 크로스 계정 신뢰 및 역할
**사용자** (신뢰하는)는 일부 정책을 가진 크로스 계정 역할을 생성한 다음, **다른 사용자** (신뢰받는)가 **그의 계정에 접근할 수 있도록 허용하지만, 오직 **새 역할 정책에 명시된 접근만 허용합니다**. 이를 생성하려면, 새 역할을 만들고 크로스 계정 역할을 선택하면 됩니다. 크로스 계정 접근을 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다.\
**사용자**(신뢰하는)는 일부 정책을 가진 크로스 계정 역할을 생성한 다음, **다른 사용자**(신뢰받는)가 **자신의 계정에 접근할 수 있도록 허용**하지만 **새 역할 정책에 명시된 접근만 허용**합니다. 이를 생성하려면 새 역할을 만들고 크로스 계정 역할을 선택하면 됩니다. 크로스 계정 접근을 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다.\
신뢰받는 사용자를 **구체적으로 지정하고 일반적인 내용을 넣지 않는 것이 좋습니다**. 그렇지 않으면, 연합된 사용자와 같은 다른 인증된 사용자가 이 신뢰를 남용할 수 있습니다.
### AWS Simple AD
@@ -291,7 +293,7 @@ AWS IAM 아이덴티티 센터 (AWS Single Sign-On의 후속 제품)는 AWS 아
- 신뢰 관계
- AD 관리 센터
- 전체 PS API 지원
- AD 재활용 빈
- AD 휴지통
- 그룹 관리 서비스 계정
- 스키마 확장
- OS 또는 인스턴스에 대한 직접 접근 없음
@@ -303,29 +305,29 @@ AWS IAM 아이덴티티 센터 (AWS Single Sign-On의 후속 제품)는 AWS 아
### 기타 IAM 옵션
- **비밀번호 정책 설정**을 통해 최소 길이 및 비밀번호 요구 사항과 같은 옵션을 설정할 수 있습니다.
- 현재 자격 증명에 대한 정보 (예: 사용자 생성 시간, 비밀번호 활성화 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드할 수 있습니다**. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
- 현재 자격 증명에 대한 정보(예: 사용자 생성 시간, 비밀번호 사용 가능 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드**할 수 있습니다. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
AWS 아이덴티티 및 접근 관리 (IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지**, 그리고 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해, 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지** 및 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
### IAM ID 접두사
[**이 페이지**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)에서 키의 성격에 따라 **IAM ID 접두사**를 찾을 수 있습니다:
| 식별자 코드 | 설명 |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ABIA | [AWS STS 서비스 베어러 토큰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| 식별자 코드 | 설명 |
| --------------- | ----------------------------------------------------------------------------------------------------------- |
| ABIA | [AWS STS 서비스 베어러 토큰](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
| ACCA | 컨텍스트 특정 자격 증명 |
| AGPA | 사용자 그룹 |
| AIDA | IAM 사용자 |
| AIPA | Amazon EC2 인스턴스 프로필 |
| AKIA | 액세스 키 |
| ANPA | 관리형 정책 |
| ANVA | 관리형 정책의 버전 |
| APKA | 공개 키 |
| AROA | 역할 |
| ASCA | 인증서 |
| ASIA | [임시 (AWS STS) 액세스 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과 조합해야만 고유합니다. |
| ACCA | 컨텍스트 특정 자격 증명 |
| AGPA | 사용자 그룹 |
| AIDA | IAM 사용자 |
| AIPA | Amazon EC2 인스턴스 프로필 |
| AKIA | 액세스 키 |
| ANPA | 관리형 정책 |
| ANVA | 관리형 정책의 버전 |
| APKA | 공개 키 |
| AROA | 역할 |
| ASCA | 인증서 |
| ASIA | [임시(AWS STS) 액세스 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과 조합하여야만 고유합니다. |
### 계정 감사에 권장되는 권한
@@ -345,7 +347,7 @@ AWS 아이덴티티 및 접근 관리 (IAM)는 AWS 전반에 걸쳐 **세밀한
### CLI 인증
일반 사용자가 CLI를 통해 AWS에 인증하기 위해서는 **로컬 자격 증명**이 필요합니다. 기본적으로 `~/.aws/credentials`에서 **수동으로** 구성하거나 **`aws configure`를 실행하여** 구성할 수 있습니다.\
해당 파일에는 여러 프로필을 가질 수 있으며, **aws cli**를 사용할 때 **프로필**이 지정되지 않으면, 해당 파일에서 **`[default]`**라는 이름의 프로필이 사용됩니다.\
해당 파일에는 여러 프로필을 가질 수 있으며, **aws cli**를 사용할 때 **프로필**이 지정되지 않으면 해당 파일에서 **`[default]`**라는 이름의 프로필이 사용됩니다.\
여러 프로필이 있는 자격 증명 파일의 예:
```
[default]
@@ -357,7 +359,7 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2
```
다른 **AWS 계정**에 접근해야 하고 귀하의 프로필이 **해당 계정 내에서 역할을 가정할 수 있는** 권한을 부여받았다면, 매번 수동으로 STS를 호출할 필요가 없습니다 (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) 및 자격 증명을 구성할 필요가 없습니다.
다른 **AWS 계정**에 접근해야 하고 귀하의 프로필이 **해당 계정 내에서 역할을 가정할 수 있는 권한**을 부여받았다면, 매번 수동으로 STS를 호출할 필요가 없습니다 (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) 및 자격 증명을 구성할 필요가 없습니다.
`~/.aws/config` 파일을 사용하여 [**가정할 역할을 지정**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)할 수 있으며, 그 후에는 평소처럼 `--profile` 매개변수를 사용할 수 있습니다 (사용자에게는 `assume-role`이 투명하게 수행됩니다).\
구성 파일 예: