AWS - Basic Information

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로부터 영웅까지 AWS 해킹을 배우세요**!

HackTricks를 지원하는 다른 방법:

• 회사가 HackTricks에 광고되길 원하거나 HackTricks를 PDF로 다운로드하려면 구독 요금제를 확인하세요!

• 공식 PEASS & HackTricks 스왜그를 구매하세요

• The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션

• 💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

조직 계층

계정

AWS에는 루트 계정이 있습니다. 이 계정은 조직의 모든 계정의 상위 컨테이너입니다. 그러나 리소스를 배포하는 데 해당 계정을 사용할 필요는 없습니다. 서로 다른 AWS 인프라를 분리하기 위해 다른 계정을 생성할 수 있습니다.

보안 측면에서 매우 흥미로운데, 한 계정이 다른 계정의 리소스에 액세스할 수 없습니다 (특별히 생성된 브릿지를 제외하고). 이렇게 함으로써 배포 사이에 경계를 생성할 수 있습니다.

따라서 조직 내에는 두 가지 유형의 계정이 있습니다 (AWS 계정 및 사용자 계정이 아닌 계정): 관리 계정으로 지정된 단일 계정과 하나 이상의 회원 계정.

• **관리 계정(루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음을 수행할 수 있습니다:

• 조직 내에서 계정 생성

• 기존 계정을 조직에 초대

• 조직에서 계정 제거

• 초대 관리

• 조직 내 엔티티(루트, OUs 또는 계정)에 정책 적용

• 지원되는 AWS 서비스와 통합하여 조직 내 모든 계정에 서비스 기능 제공을 활성화

• 이 루트 계정/조직을 만들 때 사용한 이메일과 비밀번호를 사용하여 루트 사용자로 로그인할 수 있습니다.

관리 계정은 지불 계정의 책임을 갖고 있으며 회원 계정이 발생하는 모든 요금을 지불해야 합니다. 조직의 관리 계정을 변경할 수 없습니다.

• 회원 계정은 조직 내의 나머지 모든 계정을 구성합니다. 한 계정은 한 번에 한 조직의 회원이 될 수 있습니다. 계정에 정책을 첨부하여 해당 계정에만 제어를 적용할 수 있습니다.

• 회원 계정은 유효한 이메일 주소를 사용해야 하며 이름을 가질 수 있으며 일반적으로 청구를 관리할 수 없습니다(하지만 액세스 권한을 부여받을 수 있음).

aws organizations create-account --account-name testingaccount --email [e-mail]

조직 단위

계정은 조직 단위 (OU) 에 그룹화될 수 있습니다. 이렇게 하면 조직 단위에 대한 정책을 만들어 모든 하위 계정에 적용할 수 있습니다. OU는 다른 OU를 하위 계정으로 가질 수 있다는 점을 유의하십시오.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

서비스 제어 정책 (SCP)

**서비스 제어 정책 (SCP)**은 SCP가 영향을 미치는 계정에서 사용자 및 역할이 사용할 수 있는 서비스 및 작업을 지정하는 정책입니다. SCP는 IAM 권한 정책과 유사하지만 어떤 권한도 부여하지 않습니다. 대신 SCP는 조직, 조직 단위(OU) 또는 계정에 대한 최대 권한을 지정합니다. SCP를 조직 루트 또는 OU에 첨부하면 회원 계정의 엔티티에 대한 권한을 제한합니다.

이것은 루트 사용자조차도 멈출 수 있는 유일한 방법입니다. 예를 들어, 사용자가 CloudTrail을 비활성화하거나 백업을 삭제하는 것을 막는 데 사용될 수 있습니다. 이를 우회하는 유일한 방법은 SCP를 구성하는 마스터 계정도 침해하는 것입니다(마스터 계정은 차단할 수 없음).

SCP는 계정의 주체를 제한하므로 다른 계정에는 영향을 미치지 않습니다. 이는 SCP가 s3:GetObject를 거부해도 사람들이 귀하의 계정의 공개 S3 버킷에 액세스하는 것을 막지 않는다는 것을 의미합니다.

SCP 예시:

• 루트 계정 전체 거부

• 특정 지역만 허용

• 화이트리스트된 서비스만 허용

• GuardDuty, CloudTrail 및 S3 Public Block Access 비활성화 거부

• 보안/사고 대응 역할 삭제 또는 수정 거부

• 백업 삭제 거부

• IAM 사용자 및 액세스 키 생성 거부

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html에서 JSON 예시를 찾을 수 있습니다.

ARN

**Amazon Resource Name(ARN)**은 AWS 내의 모든 리소스가 갖는 고유한 이름으로, 다음과 같이 구성됩니다:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

AWS에는 4개의 파티션이 있지만 호출할 수 있는 방법은 3가지뿐입니다:

• AWS 표준: aws

• AWS 중국: aws-cn

• AWS 미국 공공 인터넷 (GovCloud): aws-us-gov

• AWS 비밀 (미국 분류): aws

IAM - Identity and Access Management

IAM은 AWS 계정 내에서 인증, 인가 및 액세스 제어를 관리할 수 있게 해주는 서비스입니다.

• 인증 - 신원을 정의하고 해당 신원을 확인하는 과정입니다. 이 과정은 식별 및 확인으로 세분화될 수 있습니다.

• 인가 - 인증된 후 시스템 내에서 신원이 액세스할 수 있는 내용을 결정합니다.

• 액세스 제어 - 안전한 리소스에 액세스하는 방법과 과정입니다.

IAM은 신원의 인증, 인가 및 액세스 제어 메커니즘을 관리, 제어 및 조정할 수 있는 능력으로 정의될 수 있습니다.

AWS 계정 루트 사용자

Amazon Web Services (AWS) 계정을 처음 생성할 때 계정 내 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한을 갖는 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _루트 사용자_이며 계정 생성 시 사용한 이메일 주소와 암호로 로그인하여 액세스할 수 있습니다.

새로운 관리자 사용자는 루트 사용자보다 더 적은 권한을 갖습니다.

보안적인 측면에서, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 권장됩니다.

IAM 사용자

IAM _사용자_는 AWS에서 생성하는 엔티티로, AWS와 상호 작용하는 사람 또는 애플리케이션을 나타내는 역할을 합니다. AWS에서 사용자는 이름과 자격 증명(암호 및 최대 두 개의 액세스 키)으로 구성됩니다.

IAM 사용자를 생성하면 적절한 권한 정책이 부착된 사용자 그룹의 구성원으로 만들어 권한을 부여하거나 사용자에게 직접 정책을 부착하여 권한을 부여할 수 있습니다.

사용자는 콘솔을 통해 로그인할 때 MFA를 활성화할 수 있습니다. MFA가 활성화된 사용자의 API 토큰은 MFA로 보호되지 않습니다. 사용자의 API 키 액세스를 MFA로 제한하려면 정책에서 특정 작업을 수행하기 위해 MFA가 필요하다는 것을 명시해야 합니다(예시 여기).

CLI

• 액세스 키 ID: AKHDNAPO86BSHKDIRYT와 같은 20자의 무작위 대문자 알파벳 및 숫자

• 비밀 액세스 키 ID: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU와 같은 40자의 무작위 대소문자 문자(분실된 비밀 액세스 키 ID를 검색할 수 없습니다).

액세스 키를 변경해야 하는 경우 다음 절차를 따라야 합니다: 새 액세스 키 생성 -> 새 키를 시스템/애플리케이션에 적용 -> 원래 키를 비활성화로 표시 -> 새 액세스 키가 작동하는지 테스트 및 확인 -> 이전 액세스 키 삭제

MFA - Multi Factor Authentication

기존 방법(예: 암호)에 추가 인증 요소를 생성하여 다중 요소 수준의 인증을 만드는 데 사용됩니다. 무료 가상 애플리케이션 또는 물리적 장치를 사용할 수 있습니다. Google 인증과 같은 앱을 사용하여 AWS에서 MFA를 활성화할 수 있습니다.

MFA 조건이 있는 정책은 다음에 부착할 수 있습니다:

• IAM 사용자 또는 그룹

• Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 리소스

• 사용자가 가정할 수 있는 IAM 역할의 신뢰 정책

MFA를 확인하는 리소스에 CLI를 통해 액세스하려면 **GetSessionToken**을 호출해야 합니다. 이렇게 하면 MFA에 관한 정보가 포함된 토큰이 제공됩니다. AssumeRole 자격 증명에는 이 정보가 포함되지 않습니다.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

여기에서 명시된 것와 같이 MFA를 사용할 수 없는 다양한 경우가 있습니다.

IAM 사용자 그룹

IAM 사용자 그룹은 한 번에 여러 사용자에게 정책을 첨부하는 방법으로, 해당 사용자들의 권한을 관리하기 쉽게 만들 수 있습니다. 역할과 그룹은 그룹의 일부가 될 수 없습니다.

사용자 그룹에 신원 기반 정책을 첨부하여 사용자 그룹의 모든 사용자가 정책의 권한을 받을 수 있습니다. 그룹은 인증이 아닌 권한과 관련이 있으므로 정책(예: 리소스 기반 정책)에서 그룹을 주체로 식별할 수 없습니다.

사용자 그룹의 중요한 특징은 다음과 같습니다:

• 그룹은 여러 사용자를 포함할 수 있으며, 사용자는 여러 그룹에 속할 수 있습니다.

• 사용자 그룹은 중첩될 수 없습니다. 그룹에는 사용자만 포함될 수 있습니다.

• AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹이 없습니다. 그와 같은 사용자 그룹을 만들고 각 새 사용자를 할당해야 합니다.

• 사용자가 속할 수 있는 그룹의 수와 크기 등 AWS 계정의 IAM 리소스 수에는 제한이 있습니다. 자세한 내용은 IAM 및 AWS STS 할당량을 참조하십시오.

IAM 역할

IAM 역할은 사용자와 매우 유사하며, AWS에서 무엇을 할 수 있는지를 결정하는 권한 정책을 가진 신원입니다. 그러나 역할은 자격 증명(암호 또는 액세스 키)이 없습니다. 한 사람과 고유하게 연결되는 대신, 역할은 **필요한 누구나(그리고 충분한 권한이 있는 경우)**가 임시로 가질 수 있는 것으로 의도되어 있습니다. IAM 사용자는 특정 작업을 위해 다른 권한을 일시적으로 부여하기 위해 역할을 가정할 수 있습니다. 역할은 IAM 대신 외부 신원 제공자를 사용하여 로그인하는 **연합 사용자**에 할당될 수 있습니다.

IAM 역할은 두 가지 유형의 정책으로 구성됩니다: 신뢰 정책(비어 있을 수 없음, 역할을 가정할 수 있는 사용자를 정의) 및 권한 정책(비어 있을 수 없음, 무엇에 액세스할 수 있는지를 정의).

AWS 보안 토큰 서비스 (STS)

AWS 보안 토큰 서비스 (STS)는 임시, 제한된 권한 자격 증명 발급을 용이하게 하는 웹 서비스입니다. 특히 다음을 위해 특별히 제작되었습니다:

IAM의 임시 자격 증명

임시 자격 증명은 주로 IAM 역할과 함께 사용되지만 다른 용도도 있습니다. 더 제한된 권한 집합을 가진 임시 자격 증명을 요청할 수 있습니다. 이를 통해 더 제한된 자격 증명으로 허용되지 않는 작업을 실수로 수행하는 것을 방지할 수 있습니다. 임시 자격 증명의 장점은 자격 증명이 일정 기간 후 자동으로 만료된다는 것입니다. 자격 증명이 유효한 기간을 제어할 수 있습니다.

정책

정책 권한

권한을 할당하는 데 사용됩니다. 두 가지 유형이 있습니다:

• AWS 관리 정책(AWS에서 사전 구성)

• 고객 관리 정책: 사용자가 구성합니다. AWS 관리 정책을 기반으로 정책을 생성할 수 있습니다(하나를 수정하고 자체 정책을 만들거나 권한을 부여하고 거부하는 데 도움이 되는 GUI 뷰인 정책 생성기를 사용하거나 직접 작성).

기본 액세스는 거부됩니다. 명시적 역할이 지정된 경우에만 액세스가 허용됩니다. 단일 "거부"가 존재하면 "허용"을 무시하며, 기본적으로 허용되는 AWS 계정의 루트 보안 자격 증명을 사용하는 요청을 제외합니다.

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

글로벌 필드는 모든 서비스에서 조건으로 사용할 수 있는 필드에 대해 문서화되어 있습니다. 특정 필드는 각 서비스별 조건으로 사용할 수 있는 필드에 대해 문서화되어 있습니다.

인라인 정책

이 유형의 정책은 사용자, 그룹 또는 역할에 직접 할당됩니다. 그런 다음, 다른 사람이 사용할 수 있는 다른 정책과 마찬가지로 정책 목록에 나타나지 않습니다. 인라인 정책은 정책과 적용된 신원 간의 엄격한 일대일 관계를 유지하려는 경우 유용합니다. 예를 들어, 정책의 권한이 의도된 대상이 아닌 다른 신원에게 실수로 할당되지 않도록 하려는 경우입니다. 인라인 정책을 사용하면 정책의 권한이 잘못된 신원에 부착되지 않습니다. 또한 AWS Management Console을 사용하여 해당 신원을 삭제하면 신원에 포함된 정책도 삭제됩니다. 이는 그들이 주체 엔티티의 일부이기 때문입니다.

리소스 버킷 정책

이것은 리소스에 정의할 수 있는 정책입니다. AWS의 모든 리소스가 이를 지원하는 것은 아닙니다.

주체가 명시적으로 거부하지 않은 경우, 리소스 정책이 접근을 허용하면 허용됩니다.

IAM 바운더리

IAM 바운더리는 사용자 또는 역할이 액세스해야 하는 권한을 제한하는 데 사용할 수 있습니다. 이렇게 하면 사용자에게 다른 정책에 의해 부여된 다른 권한 집합이 있더라도 해당 작업은 실패합니다.

바운더리는 사용자에 부착된 정책일 뿐이며 사용자 또는 역할이 가질 수 있는 최대 권한을 나타냅니다. 따라서 사용자가 관리자 액세스 권한을 가지고 있더라도, 바운더리가 S3 버킷을 읽기만 할 수 있다고 지정하면 그것이 사용자가 할 수 있는 최대입니다.

이것, SCPs 및 최소 권한 원칙을 준수하는 것은 사용자가 필요한 권한보다 많은 권한을 가지지 않도록 제어하는 방법입니다.

세션 정책

세션 정책은 역할이 가정될 때 설정되는 정책입니다. 이는 해당 세션에 대한 IAM 바운더리와 같을 것입니다: 즉, 세션 정책은 권한을 부여하지 않고 정책에서 지정된 권한으로 제한합니다 (역할이 가진 최대 권한이 됩니다).

이것은 보안 조치에 유용합니다: 관리자가 매우 특권이 있는 역할을 가정할 때 세션이 침해당할 경우 세션 정책에서 지정된 권한만으로 제한할 수 있습니다.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

기본적으로 AWS는 세션에 세션 정책을 추가할 수 있습니다. 이는 제3의 이유로 생성될 세션에 대해 해당됩니다. 예를 들어, 인증되지 않은 코그니토 가정 역할의 경우, 기본적으로 (향상된 인증을 사용하여) AWS는 세션 정책이 포함된 세션 자격 증명을 생성합니다. 이는 세션이 액세스할 수 있는 서비스를 다음 목록으로 제한합니다.

따라서 어떤 시점에서 "... 세션 정책이 ...을 허용하지 않기 때문에"라는 오류가 발생하고 역할이 작업을 수행할 수 있는 액세스 권한이 있는 경우, 해당 작업을 방지하는 세션 정책이 있는 것입니다.

신원 연합

신원 연합은 외부 신원 제공자에서 AWS로 사용자가 AWS 사용자 자격 증명을 제공하지 않고도 안전하게 AWS 리소스에 액세스할 수 있도록 합니다. 신원 제공자의 예로는 회사의 Microsoft Active Directory(via SAML) 또는 OpenID 서비스(예: Google)가 있습니다. 연합 액세스를 통해 해당 사용자는 AWS에 액세스할 수 있습니다.

이 신뢰를 구성하려면 IAM 신원 제공자(SAML 또는 OAuth)가 생성되어 다른 플랫폼을 신뢰하도록 설정됩니다. 그런 다음 적어도 하나의 IAM 역할이(신뢰하는 쪽) 신원 제공자에 할당됩니다. 신뢰된 플랫폼의 사용자가 AWS에 액세스하면 해당 역할로 액세스하게 됩니다.

그러나 보통은 제3자 플랫폼의 사용자 그룹에 따라 다른 역할을 부여하고 싶을 것입니다. 그럼 제3자 신원 제공자가 여러 IAM 역할을 신뢰하도록 하고, 제3자 플랫폼은 사용자가 한 역할 또는 다른 역할을 가정할 수 있도록 합니다.

IAM 신원 센터

AWS IAM 신원 센터(AWS Single Sign-On의 후속 제품)는 AWS Identity and Access Management (IAM)의 기능을 확장하여 사용자의 AWS 계정 및 클라우드 애플리케이션에 대한 액세스를 관리하는 중앙 위치를 제공합니다.

로그인 도메인은 <user_input>.awsapps.com와 같을 것입니다.

사용자를 로그인시키기 위해 사용할 수 있는 3가지 신원 소스는 다음과 같습니다:

• 신원 센터 디렉터리: 일반 AWS 사용자

• Active Directory: 다양한 커넥터 지원

• 외부 신원 제공자: 외부 신원 제공자(IdP)에서 모든 사용자 및 그룹이 제공됨

가장 간단한 경우인 신원 센터 디렉터리의 경우, 신원 센터에 사용자 및 그룹 목록이 있고, 조직의 모든 계정 중 하나에 정책을 할당할 수 있습니다.

신원 센터 사용자/그룹에 계정에 액세스 권한을 부여하려면, 신원 센터를 신뢰하는 SAML 신원 제공자가 생성되고, 대상 계정에는 해당 정책을 신뢰하는 역할이 생성됩니다.

AwsSSOInlinePolicy

IAM 신원 센터에서 생성된 역할에 인라인 정책을 통해 권한을 부여할 수 있습니다. AWS 신원 센터에서 인라인 정책을 가진 계정에 생성된 역할은 **AwsSSOInlinePolicy**라는 인라인 정책에 이러한 권한을 갖게 됩니다.

따라서 **AwsSSOInlinePolicy**라는 인라인 정책이 있는 2개의 역할을 본다고 해서 동일한 권한을 가지고 있는 것은 아닙니다.

계정 간 신뢰 및 역할

사용자(신뢰하는 쪽)는 일부 정책을 가진 계정 간 역할을 생성하고, 그런 다음 다른 사용자(신뢰받는 쪽)에게 새 역할 정책에서 지정된 액세스만 허용하도록 허용할 수 있습니다. 이를 위해 새 역할을 생성하고 Cross Account Role을 선택하면 됩니다. Cross-Account Access용 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 액세스 제공 및 소유한 계정과 제3자 AWS 계정 간의 액세스 제공입니다. 일반적으로 신뢰할 사용자를 지정하고 일반적인 것을 사용하지 않는 것이 좋습니다. 그렇지 않으면 다른 인증된 사용자(연합된 사용자 등)도 이 신뢰를 남용할 수 있습니다.

AWS Simple AD

지원되지 않는 사항:

• 신뢰 관계

• AD 관리 센터

• 전체 PS API 지원

• AD 재활용통

• 그룹 관리 서비스 계정

• 스키마 확장

• OS 또는 인스턴스에 직접 액세스 불가

웹 연합 또는 OpenID 인증

앱은 일시적 자격 증명을 생성하기 위해 AssumeRoleWithWebIdentity를 사용합니다. 그러나 이는 AWS 콘솔에 액세스하는 것이 아니라 AWS 내의 리소스에 액세스하는 것을 허용합니다.

기타 IAM 옵션

• 최소 길이 및 암호 요구 사항과 같은 암호 정책 설정 옵션을 설정할 수 있습니다.

• 현재 자격 증명에 대한 정보를 포함하는 **"자격 증명 보고서"**를 다운로드할 수 있습니다(사용자 생성 시간, 암호 사용 여부 등). 자격 증명 보고서는 최대 4시간마다 생성할 수 있습니다.

AWS Identity and Access Management (IAM)은 AWS 전체에서 세밀한 액세스 제어를 제공합니다. IAM을 사용하면 누가 어떤 서비스 및 리소스에 액세스할 수 있는지 및 어떤 조건에서 액세스할 수 있는지를 지정할 수 있습니다. IAM 정책을 사용하여 귀사의 인력 및 시스템에 대한 권한을 관리하여 최소 권한 원칙을 보장할 수 있습니다.

IAM ID 접두사

이 페이지에서 키의 IAM ID 접두사를 찾을 수 있습니다:

ABIA	AWS STS 서비스 베어러 토큰
ACCA	컨텍스트별 자격 증명
AGPA	사용자 그룹
AIDA	IAM 사용자
AIPA	Amazon EC2 인스턴스 프로필
AKIA	액세스 키
ANPA	관리 정책
ANVA	관리 정책의 버전
APKA	공개 키
AROA	역할
ASCA	인증서
ASIA	임시 (AWS STS) 액세스 키 ID는 이 접두사를 사용하지만, 비밀 액세스 키 및 세션 토큰과만 결합하면 고유합니다.

계정 감사를 위한 권한 권장 사항

다음 권한은 다양한 메타데이터의 읽기 액세스를 부여합니다:

• arn:aws:iam::aws:policy/SecurityAudit

• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess

• codebuild:ListProjects

• config:Describe*

• cloudformation:ListStacks

• logs:DescribeMetricFilters

• directconnect:DescribeConnections

• dynamodb:ListTables

기타

CLI 인증

일반 사용자가 CLI를 통해 AWS에 인증하려면 로컬 자격 증명이 필요합니다. 기본적으로 ~/.aws/credentials에 수동으로 구성하거나 aws configure를 실행하여 구성할 수 있습니다. 해당 파일에는 여러 프로필이 포함될 수 있으며, aws cli를 사용할 때 프로필이 지정되지 않으면 해당 파일에 있는 **[default]**라는 프로필이 사용됩니다. 여러 프로필이 있는 자격 증명 파일 예시:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
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/config 파일을 사용하여 가정할 역할을 지정하고, 그런 다음 --profile 매개변수를 평소처럼 사용할 수 있습니다 (사용자에게는 가정 역할이 투명하게 수행됩니다). 구성 파일 예시:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

이 구성 파일을 사용하면 다음과 같이 aws cli를 사용할 수 있습니다:

aws --profile acc2 ...

만약 브라우저용으로 이와 유사한 것을 찾고 있다면 AWS Extend Switch Roles 확장 프로그램을 확인해보세요.

참고 자료

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html

• https://aws.amazon.com/iam/

• https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로**부터 **AWS 해킹**을 전문가로 배우세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 PDF로 HackTricks 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!

• 공식 PEASS & HackTricks 스왜그를 구매하세요

• The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션

• 💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.