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

This commit is contained in:
Translator
2025-04-11 00:28:25 +00:00
parent 77e06d85cf
commit 23e54abaef
4 changed files with 70 additions and 68 deletions

View File

@@ -12,7 +12,7 @@ AWS에는 **루트 계정**이 있으며, 이는 **조직의 모든 계정에
이는 **보안** 관점에서 매우 흥미로운데, **하나의 계정은 다른 계정의 리소스에 접근할 수 없기 때문**입니다(특별히 브리지가 생성되지 않는 한). 따라서 배포 간에 경계를 만들 수 있습니다.
따라서 **조직에는 두 가지 유형의 계정**이 있습니다(우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
따라서 조직에는 **두 가지 유형의 계정**이 있습니다(우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
- **관리 계정(루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:
@@ -26,36 +26,38 @@ 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 예시:
- 루트 계정을 완전히 거부
- 특정 지역만 허용
- 화이트리스트된 서비스만 허용
- GuardDuty, CloudTrail 및 S3 공개 차단 액세스 비활성화 거부
- GuardDuty, CloudTrail 및 S3 공개 차단 접근을 비활성화하는 것을 거부
- 보안/사고 대응 역할이 삭제되거나 수정되는 것을 거부합니다.
- 보안/사고 대응 역할이 삭제되거나
수정되는 것을 거부합니다.
- 백업이 삭제되는 것을 거부합니다.
- IAM 사용자 및 액세스 키 생성을 거부합니다.
@@ -66,17 +68,17 @@ SCP 예시:
A **resource control policy (RCP)**는 **AWS 조직 내 리소스에 대한 최대 권한**을 정의하는 정책입니다. RCP는 구문에서 IAM 정책과 유사하지만 **권한을 부여하지 않습니다**—다른 정책에 의해 리소스에 적용될 수 있는 권한을 제한할 뿐입니다. RCP를 조직 루트, 조직 단위(OU) 또는 계정에 연결하면 RCP는 영향을 받는 범위 내 모든 리소스에 대한 리소스 권한을 제한합니다.
이것은 **리소스가 미리 정의된 액세스 수준을 초과할 수 없도록 보장하는 유일한 방법**입니다—정체성 기반 또는 리소스 기반 정책이 너무 관대하더라도 말입니다. 이러한 제한을 우회하는 유일한 방법은 조직의 관리 계정에서 구성된 RCP를 수정하는 것입니다.
이것은 **리소스가 미리 정의된 접근 수준을 초과할 수 없도록 보장하는 유일한 방법**입니다—정체성 기반 또는 리소스 기반 정책이 너무 관대하더라도 말입니다. 이러한 제한을 우회하는 유일한 방법은 조직의 관리 계정에서 구성된 RCP를 수정하는 것입니다.
> [!WARNING]
> RCP는 리소스가 가질 수 있는 권한만 제한합니다. 주체가 할 수 있는 을 직접 제어하지는 않습니다. 예를 들어, RCP가 S3 버킷에 대한 외부 액세스를 거부하면, 버킷의 권한이 설정된 한계를 초과하는 작업을 허용하지 않도록 보장합니다—리소스 기반 정책이 잘못 구성되더라도 말입니다.
> RCP는 리소스가 가질 수 있는 권한만 제한합니다. 주체가 할 수 있는 을 직접 제어하지는 않습니다. 예를 들어, RCP가 S3 버킷에 대한 외부 접근을 거부하면, 해당 버킷의 권한이 설정된 한계를 초과하는 작업을 허용하지 않도록 보장합니다—리소스 기반 정책이 잘못 구성되더라도 말입니다.
RCP 예시:
- S3 버킷을 제한하여 귀하의 조직 내 주체만 접근할 수 있도록 합니다.
- KMS 키 사용을 신뢰할 수 있는 조직 계정에서만 작업을 허용하도록 제한합니다.
- SQS 큐의 권한을 제한하여 무단 수정을 방지합니다.
- Secrets Manager 비밀에 대한 액세스 경계를 시행하여 민감한 데이터를 보호합니다.
- S3 버킷을 제한하여 귀하의 조직 내 주체만 접근할 수 있도록
- KMS 키 사용을 신뢰할 수 있는 조직 계정에서만 작업을 허용하도록 제한
- SQS 큐의 권한을 제한하여 무단 수정을 방지
- Secrets Manager 비밀에 대한 접근 경계를 시행하여 민감한 데이터를 보호
예시는 [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)에서 확인하세요.
@@ -99,14 +101,14 @@ AWS에는 4개의 파티션이 있지만 이를 호출하는 방법은 3가지
IAM은 AWS 계정 내에서 **인증**, **권한 부여** 및 **액세스 제어**를 관리할 수 있게 해주는 서비스입니다.
- **인증** - 신원을 정의하고 그 신원을 검증하는 과정입니다. 이 과정은 식별 및 검증으로 세분화될 수 있습니다.
- **권한 부여** - 인증된 후 시스템 내에서 신원이 접근할 수 있는 것을 결정합니다.
- **액세스 제어** - 안전한 리소스에 대한 액세스가 부여되는 방법과 과정입니다.
- **권한 부여** - 신원이 시스템에 인증된 후 시스템 내에서 어떤 자원에 접근할 수 있는지를 결정합니다.
- **액세스 제어** - 안전한 자원에 대한 접근이 어떻게 부여되는지를 정의하는 방법과 과정입니다.
IAM은 AWS 계정 내 리소스에 대한 신원의 인증, 권한 부여 및 액세스 제어 메커니즘을 관리, 제어 및 통치하는 능력으로 정의될 수 있습니다.
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 계정 _**루트 사용자**_이며, **계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다**.
새로운 **관리자 사용자**는 **루트 사용자보다 권한이 적습니다**.
@@ -118,7 +120,7 @@ IAM _사용자_는 AWS에서 **사람이나 애플리케이션을 나타내기
IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 **사용자 그룹의 구성원**으로 만들어 **권한**을 부여하거나, **정책을 사용자에게 직접 첨부**하여 권한을 부여합니다.
사용자는 콘솔을 통해 **MFA로 로그인할 수 있습니다**. MFA가 활성화된 사용자의 API 토큰은 MFA로 보호되지 않습니다. **MFA를 사용하여 사용자 API 키의 액세스를 제한**하려면 특정 작업을 수행하기 위해 MFA가 필요하다는 것을 정책에 명시해야 합니다 (예시 [**여기**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
사용자는 콘솔을 통해 **MFA로 로그인할 수 있습니다**. MFA가 활성화된 사용자의 API 토큰은 MFA로 보호되지 않습니다. **MFA를 사용하여 사용자 API 키 접근을 제한**하려면 정책에서 특정 작업을 수행하기 위해 MFA가 필요하다 명시해야 합니다 (예시 [**여기**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
#### CLI
@@ -136,11 +138,11 @@ _새 액세스 키 생성 -> 시스템/애플리케이션에 새 키 적용 ->
MFA 조건이 있는 정책은 다음에 첨부될 수 있습니다:
- IAM 사용자 또는 그룹
- Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 리소스
- Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 자원
- 사용자가 가정할 수 있는 IAM 역할의 신뢰 정책
**MFA를 확인하는** 리소스**CLI를 통해 액세스**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
**`AssumeRole` 자격 증명에는 이 정보가 포함되어 있지 않습니다**.
**MFA를 확인하는** 자원**CLI를 통해 접근**하려면 **`GetSessionToken`**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.\
**`AssumeRole` 자격 증명에는 이 정보가 포함되어 있지 않음을 유의하십시오.**
```bash
aws sts get-session-token --serial-number <arn_device> --token-code <code>
```
@@ -154,16 +156,16 @@ IAM [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_group
사용자 그룹의 몇 가지 중요한 특성은 다음과 같습니다:
- 사용자 **그룹**은 **많은 사용자**를 **포함할 수 있으며**, **사용자**는 **여러 그룹에 속할 수 있습니다**.
- 사용자 **그룹**은 **많은 사용자**를 **포함할 수** 있으며, **사용자**는 **여러 그룹에 속할 수** 있습니다.
- **사용자 그룹은 중첩될 수 없습니다**; 사용자만 포함할 수 있으며, 다른 사용자 그룹은 포함할 수 없습니다.
- **AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹은 없습니다**. 그런 사용자 그룹을 원하면, 직접 생성하고 각 새로운 사용자를 할당해야 합니다.
- AWS 계정의 IAM 리소스 수, 예를 들어 그룹 수와 사용자가 속할 수 있는 그룹 수는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)을 참조하세요.
- AWS 계정의 IAM 리소스 수와 크기, 예를 들어 그룹 수와 사용자가 속할 수 있는 그룹 수는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)을 참조하세요.
### [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 대신 외부 ID 공급자를 사용하여 로그인하는 [**연합 사용자**](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 역할은 **두 가지 유형의 정책**으로 구성됩니다: **신뢰 정책**(비어 있을 수 없음)으로 **누가 역할을 가정할 수 있는지를 정의**하고, **권한 정책**(비어 있을 수 없음)으로 **무엇에 접근할 수 있는지를 정의**합니다.
IAM 역할은 **두 가지 유형의 정책**으로 구성됩니다: **비밀 정책**(비어 있을 수 없음)으로 **누가 역할을 가정할 수 있는지를 정의**하고, **권한 정책**(비어 있을 수 없음)으로 **무엇에 접근할 수 있는지를 정의**합니다.
#### AWS 보안 토큰 서비스 (STS)
@@ -179,11 +181,11 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
권한을 할당하는 데 사용됩니다. 두 가지 유형이 있습니다:
- AWS 관리 정책 (AWS에서 미리 구성)
- 고객 관리 정책: 사용자가 구성합니다. AWS 관리 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기(권한을 부여하고 거부하는 데 도움을 주는 GUI 보기)를 사용하거나 직접 작성할 수 있습니다.
- AWS 관리 정책 (AWS에서 미리 구성한 것)
- 고객 관리 정책: 사용자가 구성한 것. AWS 관리 정책을 기반으로 정책을 생성할 수 있습니다(그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기(권한을 부여하고 거부하는 데 도움을 주는 GUI 보기)를 사용하거나 직접 작성할 수 있습니다.
**기본적으로 접근은** **거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
**단일 "거부"가 존재하면 "허용"을 무시합니다**, AWS 계정의 루트 보안 자격 증명을 사용하는 요청(기본적으로 허용됨)을 제외하고.
기본적으로 **접근이 거부됩니다**, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다.\
**단일 "거부"가 존재하면 "허용"을 무시합니다**, AWS 계정의 루트 보안 자격 증명을 사용하는 요청기본적으로 허용됩니다.
```javascript
{
"Version": "2012-10-17", //Version of the policy
@@ -206,27 +208,27 @@ AWS 보안 토큰 서비스 (STS)는 **임시, 제한된 권한 자격 증명**
]
}
```
[서비스에서 조건으로 사용할 수 있는 전역 필드는 여기 문서화되어 있습니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
[서비스별로 조건으로 사용할 수 있는 특정 필드는 여기 문서화되어 있습니다](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
[전 세계에서 모든 서비스 조건으로 사용할 수 있는 필드는 여기에서 문서화되어 있습니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
[서비스별로 조건으로 사용할 수 있는 특정 필드는 여기에서 문서화되어 있습니다](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
#### 인라인 정책
이러한 종류의 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
이러한 정책은 **사용자, 그룹 또는 역할에 직접 할당**됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다.\
인라인 정책은 **정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지**하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우연히 할당되지 않도록 하고 싶습니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 함께 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
#### 리소스 버킷 정책
이것은 **리소스**에서 정의할 수 있는 **정책**입니다. **모든 AWS 리소스가 이를 지원하는 것은 아닙니다**.
주체가 이에 대한 명시적 거부가 없고, 리소스 정책이 접근을 허용하면, 그들은 허용됩니다.
주체가 이에 대한 명시적 거부가 없고, 리소스 정책이 그들에게 접근을 허용하면, 그들은 허용됩니다.
### IAM 경계
IAM 경계는 **사용자 또는 역할이 접근할 수 있는 권한을 제한하는 데 사용**될 수 있습니다. 이렇게 하면, **다른 정책**에 의해 사용자에게 다른 권한 세트가 부여되더라도, 그가 이를 사용하려고 할 경우 작업이 **실패**합니다.
경계는 사용자에게 첨부된 정책으로, **사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다**. 따라서, **사용자가 관리자 접근 권한을 가지고 있더라도**, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
경계는 사용자에게 첨부된 정책으로, **사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다**. 따라서 **사용자가 관리자 접근 권한을 가지고 있더라도**, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
**이것**, **SCPs** 및 **최소 권한 원칙**을 따르는 것은 사용자가 필요한 것보다 더 많은 권한을 가지지 않도록 제어하는 방법입니다.
**이것**과 **SCP** 및 **최소 권한 원칙**을 따르는 것은 사용자가 필요한 것보다 더 많은 권한을 가지지 않도록 제어하는 방법입니다.
### 세션 정책
@@ -240,24 +242,24 @@ aws sts assume-role \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]
```
기본적으로 **AWS는 세션을 생성할 때 세션 정책을 추가할 수 있습니다**. 예를 들어, [인증되지 않은 Cognito 가정 역할](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)에서는 기본적으로 (향상된 인증을 사용하여) AWS가 **세션 정책이 포함된 세션 자격 증명**을 생성하여 세션이 접근할 수 있는 서비스의 범위를 제한합니다 [**다음 목록으로**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
기본적으로 **AWS는 세션을 생성할 때 세션 정책을 추가할 수 있습니다**. 예를 들어, [인증되지 않은 cognito 가정 역할](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)에서는 기본적으로 (향상된 인증을 사용하여) AWS가 **세션 정책이 포함된 세션 자격 증명**을 생성하여 해당 세션이 접근할 수 있는 서비스의 범위를 제한합니다 [**다음 목록으로**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
따라서 "... 세션 정책이 ...을 허용하지 않기 때문에"라는 오류에 직면하게 되면, 역할이 해당 작업을 수행할 수 있는 접근 권한이 있음에도 불구하고 **세션 정책이 이를 방지하고 있기 때문입니다**.
따라서, 어느 시점에 "... 세션 정책이 ...을 허용하지 않기 때문에"라는 오류가 발생하고 역할이 해당 작업을 수행할 수 있는 경우, **세션 정책이 이를 방지하고 있기 때문입니다**.
### 아이덴티티 연합
아이덴티티 연합은 **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,24 +267,24 @@ AWS IAM 아이덴티티 센터(AWS Single Sign-On의 후속 제품)는 AWS 아
- 아이덴티티 센터 디렉토리: 일반 AWS 사용자
- 액티브 디렉토리: 다양한 커넥터 지원
- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자(IdP)에서 옵니다.
- 외부 아이덴티티 제공자: 모든 사용자 및 그룹이 외부 아이덴티티 제공자 (IdP)에서 옵니다.
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 보유하** 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
아이덴티티 센터 디렉토리의 가장 간단한 경우, **아이덴티티 센터는 사용자 및 그룹 목록을 가지** 있으며, **정책을 할당**하여 **조직의 모든 계정**에 적용할 수 있습니다.
아이덴티티 센터 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 **아이덴티티 센터를 신뢰하는 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 @@ IAM 아이덴티티 센터를 통해 생성된 역할에 **인라인 정책을
- 신뢰 관계
- AD 관리 센터
- 전체 PS API 지원
- AD 휴지통
- AD 재활용 빈
- 그룹 관리 서비스 계정
- 스키마 확장
- OS 또는 인스턴스에 대한 직접 접근 없음
@@ -302,10 +304,10 @@ IAM 아이덴티티 센터를 통해 생성된 역할에 **인라인 정책을
### 기타 IAM 옵션
- **비밀번호 정책 설정**에서 최소 길이 및 비밀번호 요구 사항과 같은 옵션을 설정할 수 있습니다.
- 현재 자격 증명에 대한 정보(예: 사용자 생성 시간, 비밀번호 사용 가능 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드할 수 있습니다**. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
- **비밀번호 정책 설정**을 통해 최소 길이 및 비밀번호 요구 사항과 같은 옵션을 설정할 수 있습니다.
- 현재 자격 증명에 대한 정보 (예: 사용자 생성 시간, 비밀번호 활성화 여부 등)를 포함한 **"자격 증명 보고서"를 다운로드할 수 있습니다**. 자격 증명 보고서는 최대 **4시간마다** 생성할 수 있습니다.
AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지**, 그리고 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
AWS 아이덴티티 및 접근 관리 (IAM)는 AWS 전반에 걸쳐 **세밀한 접근 제어**를 제공합니다. IAM을 사용하면 **누가 어떤 서비스와 리소스에 접근할 수 있는지**, 그리고 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해, 인력과 시스템에 대한 권한을 관리하여 **최소 권한 원칙**을 보장합니다.
### IAM ID 접두사
@@ -319,17 +321,17 @@ AWS 아이덴티티 및 접근 관리(IAM)는 AWS 전반에 걸쳐 **세밀한
| AGPA | 사용자 그룹 |
| AIDA | IAM 사용자 |
| AIPA | Amazon EC2 인스턴스 프로필 |
| AKIA | 접근 키 |
| ANPA | 관리 정책 |
| ANVA | 관리 정책의 버전 |
| AKIA | 액세스 키 |
| ANPA | 관리 정책 |
| ANVA | 관리 정책의 버전 |
| APKA | 공개 키 |
| AROA | 역할 |
| ASCA | 인증서 |
| ASIA | [임시(AWS STS) 접근 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 접근 키 및 세션 토큰과 조합하여만 고유합니다. |
| ASIA | [임시 (AWS STS) 액세스 키 ID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과 조합하여만 고유합니다. |
### 계정 감사에 권장되는 권한
음 권한은 메타데이터에 대한 다양한 읽기 접근을 부여합니다:
양한 메타데이터에 대한 읽기 접근을 부여하는 다음 권한:
- `arn:aws:iam::aws:policy/SecurityAudit`
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
@@ -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`이 투명하게 수행됩니다).\
구성 파일 예:
@@ -377,7 +379,7 @@ aws --profile acc2 ...
#### 임시 자격 증명 자동화
임시 자격 증명을 생성하는 애플리케이션을 악용하는 경우, 자격 증명이 만료될 때마다 몇 분마다 터미널에서 업데이트하는 것이 번거로울 수 있습니다. 이는 구성 파일에 `credential_process` 지시어를 사용하여 해결할 수 있습니다. 예를 들어, 취약한 웹앱이 있다면 다음과 같이 할 수 있습니다:
임시 자격 증명을 생성하는 애플리케이션을 악용하는 경우, 만료될 때마다 몇 분마다 터미널에서 이를 업데이트하는 것이 번거로울 수 있습니다. 이는 구성 파일에 `credential_process` 지시어를 사용하여 해결할 수 있습니다. 예를 들어, 취약한 웹앱이 있다면 다음과 같이 할 수 있습니다:
```toml
[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

View File

@@ -18,7 +18,7 @@ Lambda는 런타임에 자격 증명을 주입하기 위해 환경 변수를 사
### 다른 사용자의 Lambda URL 요청 훔치기
공격자가 Lambda 내부에서 RCE를 얻는 데 성공하면 다른 사용자의 Lambda에 대한 HTTP 요청을 훔칠 수 있습니다. 요청에 민감한 정보(쿠키, 자격 증명 등)가 포함되어 있다면, 이를 훔칠 수 있습니다.
공격자가 Lambda 내부에서 RCE를 얻는 데 성공하면, 다른 사용자의 Lambda에 대한 HTTP 요청을 훔칠 수 있습니다. 요청에 민감한 정보(쿠키, 자격 증명 등)가 포함되어 있다면, 이를 훔칠 수 있습니다.
{{#ref}}
aws-warm-lambda-persistence.md

View File

@@ -28,7 +28,7 @@ iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md
### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`)
이 경우 기존의 cloudformation 스택을 **악용하여** 업데이트하고 이전 시나리오처럼 권한을 상승시킬 수 있습니다:
이 경우 기존의 cloudformation 스택을 **악용하여** 업데이트하고 이전 시나리오와 같이 권한을 상승시킬 수 있습니다:
```bash
aws cloudformation update-stack \
--stack-name privesc \
@@ -43,7 +43,7 @@ aws cloudformation update-stack \
### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`
이 권한이 있지만 **`iam:PassRole`**이 없는 경우에도 **사용된 스택을 업데이트**하고 **이미 연결된 IAM 역할을 악용**할 수 있습니다. 업데이트 역할을 지정하지 마십시오에 대한 이전 섹션의 exploit 예제를 확인하십시오.
이 권한이 있지만 **`iam:PassRole`**이 없는 경우에도 **사용된 스택을 업데이트**하고 **이미 연결된 IAM 역할을 악용**할 수 있습니다. 업데이트에서 역할을 지정하지 마십시오.
`cloudformation:SetStackPolicy` 권한은 **스택에 대한 `UpdateStack` 권한을 부여**하고 공격을 수행하는 데 사용할 수 있습니다.
@@ -53,7 +53,7 @@ aws cloudformation update-stack \
역할을 **전달하고 ChangeSet을 생성 및 실행**할 수 있는 권한이 있는 공격자는 **새 cloudformation 스택을 생성/업데이트하고 cloudformation 서비스 역할을 악용**할 수 있습니다. CreateStack 또는 UpdateStack과 마찬가지로.
다음 exploit**ChangeSet 권한을 사용하여 스택을 생성하는**[ **CreateStack exploit의 변형**](#iam-passrole-cloudformation-createstack)입니다.
다음 공격**ChangeSet 권한을 사용하여 스택을 생성하는**[ **CreateStack 공격의 변형**](#iam-passrole-cloudformation-createstack)입니다.
```bash
aws cloudformation create-change-set \
--stack-name privesc \
@@ -105,11 +105,11 @@ aws cloudformation describe-stacks \
## AWS CDK
AWS cdk는 사용자가 이미 익숙한 언어로 인프라를 코드로 정의할 수 있도록 하는 도구 모음이며, 섹션을 쉽게 재사용할 수 있습니다. 그런 다음 CDK는 고급 코드를 Cloudformation 템플릿(yaml 또는 json)으로 변환합니다.
AWS cdk는 사용자가 이미 익숙한 언어로 인프라를 코드로 정의할 수 있도록 하는 도구 모음이며, 섹션을 쉽게 재사용할 수 있습니다. 그런 다음 CDK는 고급 코드를 (예: python) Cloudformation 템플릿(yaml 또는 json)으로 변환합니다.
CDK를 사용하려면 관리 사용자가 먼저 계정을 부트스트랩해야 하며, 이 과정에서 여러 IAM 역할이 생성됩니다. 여기에는 \*/\* 권한을 가진 *exec role*이 포함됩니다. 이러한 역할은 `cdk-<qualifier>-<name>-<account-id>-<region>` 형식의 이름 구조를 따릅니다. 부트스트랩은 계정당 지역별로 한 번만 수행해야 합니다.
기본적으로 CDK 사용자는 CDK를 사용하기 위해 필요한 역할을 나열할 수 있는 권한이 없으므로, 이를 수동으로 확인해야 합니다. 개발자의 머신이나 CI/CD 노드를 손상시키면 이러한 역할을 가정하여 `cfn-exec` 역할을 사용하여 CFN 템플릿을 배포할 수 있는 능력을 부여받아 계정을 완전히 손상시킬 수 있습니다.
기본적으로 CDK 사용자는 CDK를 사용하기 위해 필요한 역할을 나열할 수 있는 권한이 없으므로, 이를 수동으로 확인해야 합니다. 개발자의 머신이나 CI/CD 노드를 침해하면 이러한 역할을 가정하여 `cfn-exec` 역할을 사용하여 CFN 템플릿을 배포할 수 있는 능력을 부여받아 계정을 완전히 침해할 수 있습니다.
### 역할 이름 결정하기
@@ -117,7 +117,7 @@ CDK를 사용하려면 관리 사용자가 먼저 계정을 부트스트랩해
CDK 프로젝트를 빌드하고 배포하는 데 사용된 머신에 있는 경우, 프로젝트의 루트 디렉토리에서 `cdk.out/manafest.json`에서 가져올 수 있습니다.
또한 역할이 무엇인지에 대 좋은 추측을 할 수 있습니다. `qualifier`는 여러 인스턴스의 CDK 부트스트랩을 동시에 배포할 수 있도록 역할에 추가된 문자열이지만, 기본값은 하드코딩되어 `hnb659fds`입니다.
또한 역할이 무엇인지에 대 좋은 추측을 할 수 있습니다. `qualifier`는 여러 인스턴스의 CDK 부트스트랩을 동시에 배포할 수 있도록 역할에 추가된 문자열이지만, 기본값은 하드코딩되어 `hnb659fds`입니다.
```
# Defaults
cdk-hnb659fds-cfn-exec-role-<account-id>-<region>

View File

@@ -31,7 +31,7 @@ aws cloudformation list-stack-set-operation-results --stack-set-name <name> --op
```
### Privesc
다음 페이지에서 **cloudformation 권한을 용하여 권한 상승**하는 방법을 확인할 수 있습니다:
다음 페이지에서 **cloudformation 권한을 용하여 권한 상승**하는 방법을 확인할 수 있습니다:
{{#ref}}
../aws-privilege-escalation/aws-cloudformation-privesc/
@@ -49,7 +49,7 @@ aws cloudformation list-stack-set-operation-results --stack-set-name <name> --op
## Codestar
AWS CodeStar는 AWS에서 소프트웨어 개발 프로젝트를 생성, 관리 및 작업하는 서비스입니다. AWS CodeStar 프로젝트를 사용하여 AWS에서 애플리케이션을 신속하게 개발, 빌드 및 배포할 수 있습니다. AWS CodeStar 프로젝트는 프로젝트 개발 도구 체인을 위해 **AWS 서비스**를 생성하고 **통합**합니다. 선택한 AWS CodeStar 프로젝트 템플릿에 따라 해당 도구 체인에는 소스 제어, 빌드, 배포, 가상 서버 또는 서버리스 리소스 등이 포함될 수 있습니다. AWS CodeStar는 또한 프로젝트 사용자(팀원이라고 함)에 필요한 권한을 **관리**합니다.
AWS CodeStar는 AWS에서 소프트웨어 개발 프로젝트를 생성, 관리 및 작업하는 서비스입니다. AWS CodeStar 프로젝트를 사용하여 AWS에서 애플리케이션을 신속하게 개발, 빌드 및 배포할 수 있습니다. AWS CodeStar 프로젝트는 프로젝트 개발 도구 체인을 위해 **AWS 서비스를 생성하고 통합**합니다. 선택한 AWS CodeStar 프로젝트 템플릿에 따라 해당 도구 체인에는 소스 제어, 빌드, 배포, 가상 서버 또는 서버리스 리소스 등이 포함될 수 있습니다. AWS CodeStar는 또한 프로젝트 사용자(팀원이라고 함)에 필요한 권한을 **관리**합니다.
### Enumeration
```bash