Last updated
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
AWS에는 루트 계정이 있으며, 이는 조직의 모든 계정에 대한 부모 컨테이너입니다. 그러나 리소스를 배포하기 위해 해당 계정을 사용할 필요는 없으며, 다른 계정을 생성하여 서로 다른 AWS 인프라를 분리할 수 있습니다.
이는 보안 관점에서 매우 흥미로운데, 하나의 계정은 다른 계정의 리소스에 접근할 수 없기 때문입니다(특별히 브리지가 생성되지 않는 한). 따라서 배포 간에 경계를 만들 수 있습니다.
따라서 조직에는 두 가지 유형의 계정이 있습니다(우리는 AWS 계정에 대해 이야기하고 있으며 사용자 계정이 아닙니다): 관리 계정으로 지정된 단일 계정과 하나 이상의 멤버 계정입니다.
**관리 계정(루트 계정)**은 조직을 생성하는 데 사용하는 계정입니다. 조직의 관리 계정에서 다음 작업을 수행할 수 있습니다:
조직 내 계정 생성
다른 기존 계정을 조직에 초대
조직에서 계정 제거
초대 관리
조직 내의 엔터티(루트, OU 또는 계정)에 정책 적용
조직 내 모든 계정에서 서비스 기능을 제공하기 위해 지원되는 AWS 서비스와의 통합 활성화
이 루트 계정/조직을 생성하는 데 사용된 이메일과 비밀번호로 루트 사용자로 로그인할 수 있습니다.
관리 계정은 지불 계정의 책임을 지며, 멤버 계정에서 발생하는 모든 요금을 지불할 책임이 있습니다. 조직의 관리 계정을 변경할 수 없습니다.
멤버 계정은 조직 내의 나머지 모든 계정을 구성합니다. 계정은 한 번에 하나의 조직의 멤버일 수 있습니다. 계정에 정책을 부착하여 해당 계정에만 제어를 적용할 수 있습니다.
멤버 계정은 유효한 이메일 주소를 사용해야 하며 이름을 가질 수 있습니다. 일반적으로 청구를 관리할 수 없지만(접근 권한이 부여될 수 있음) 가능합니다.
계정은 **조직 단위(OU)**로 그룹화할 수 있습니다. 이렇게 하면 조직 단위에 대한 정책을 생성할 수 있으며, 이 정책은 모든 자식 계정에 적용됩니다. OU는 다른 OU를 자식으로 가질 수 있습니다.
A **service control policy (SCP)**는 SCP가 영향을 미치는 계정에서 사용자가 사용할 수 있는 서비스와 작업을 지정하는 정책입니다. SCP는 IAM 권한 정책과 유사하지만 권한을 부여하지 않습니다. 대신, SCP는 조직, 조직 단위(OU) 또는 계정에 대한 최대 권한을 지정합니다. SCP를 조직 루트 또는 OU에 연결하면 SCP는 구성원 계정의 엔티티에 대한 권한을 제한합니다.
이것은 루트 사용자조차도 무언가를 하는 것을 막을 수 있는 유일한 방법입니다. 예를 들어, 사용자가 CloudTrail을 비활성화하거나 백업을 삭제하는 것을 막는 데 사용할 수 있습니다. 이를 우회하는 유일한 방법은 SCP를 구성하는 마스터 계정도 손상시키는 것입니다(마스터 계정은 차단할 수 없습니다).
SCP는 계정의 주체만 제한하므로 다른 계정에는 영향을 미치지 않습니다. 이는 SCP가 s3:GetObject를 거부하더라도 사람들이 귀하의 계정에서 공개 S3 버킷에 접근하는 것을 막지 않습니다.
SCP 예시:
루트 계정을 완전히 거부
특정 지역만 허용
화이트리스트에 있는 서비스만 허용
GuardDuty, CloudTrail 및 S3 공개 차단 액세스 비활성화를 거부
보안/사고 대응 역할의 삭제 또는 수정 거부
백업 삭제 거부
IAM 사용자 및 액세스 키 생성 거부
JSON 예시는 https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html에서 확인하세요.
Amazon Resource Name은 AWS 내의 모든 리소스가 가지는 고유 이름으로, 다음과 같이 구성됩니다:
Note that there are 4 partitions in AWS but only 3 ways to call them:
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAM은 AWS 계정 내에서 인증, 권한 부여 및 액세스 제어를 관리할 수 있게 해주는 서비스입니다.
인증 - 신원을 정의하고 그 신원을 검증하는 과정입니다. 이 과정은 식별 및 검증으로 세분화될 수 있습니다.
권한 부여 - 인증된 후 시스템 내에서 신원이 접근할 수 있는 것을 결정합니다.
액세스 제어 - 안전한 리소스에 대한 액세스가 부여되는 방법과 과정입니다.
IAM은 AWS 계정 내 리소스에 대한 신원의 인증, 권한 부여 및 액세스 제어 메커니즘을 관리, 제어 및 통치하는 능력으로 정의될 수 있습니다.
Amazon Web Services (AWS) 계정을 처음 생성할 때, 계정 내 모든 AWS 서비스 및 리소스에 완전한 액세스를 가진 단일 로그인 신원으로 시작합니다. 이것이 AWS 계정 _루트 사용자_이며, 계정을 생성할 때 사용한 이메일 주소와 비밀번호로 로그인하여 접근합니다.
새로운 관리자 사용자는 루트 사용자보다 권한이 적습니다.
보안 관점에서 볼 때, 다른 사용자를 생성하고 이 사용자를 사용하는 것을 피하는 것이 권장됩니다.
IAM _사용자_는 AWS에서 사람이나 애플리케이션을 나타내기 위해 생성하는 엔티티입니다. AWS의 사용자는 이름과 자격 증명(비밀번호 및 최대 두 개의 액세스 키)으로 구성됩니다.
IAM 사용자를 생성할 때, 적절한 권한 정책이 첨부된 사용자 그룹의 구성원으로 만들어 권한을 부여하거나, 정책을 사용자에게 직접 첨부하여 권한을 부여합니다.
사용자는 콘솔을 통해 MFA로 로그인할 수 있습니다. MFA가 활성화된 사용자의 API 토큰은 MFA로 보호되지 않습니다. MFA를 사용하여 사용자의 API 키 접근을 제한하려면, 특정 작업을 수행하기 위해 MFA가 필요하다는 것을 정책에 명시해야 합니다 (예시 여기).
Access Key ID: 20개의 무작위 대문자 알파벳 숫자 조합, 예: AKHDNAPO86BSHKDIRYT
Secret access key ID: 40개의 무작위 대소문자 조합: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (잃어버린 비밀 액세스 키 ID를 복구할 수 없습니다).
Access Key를 변경해야 할 때 따라야 할 과정은 다음과 같습니다: 새 액세스 키 생성 -> 시스템/애플리케이션에 새 키 적용 -> 원래 키를 비활성화로 표시 -> 새 액세스 키가 작동하는지 테스트 및 검증 -> 이전 액세스 키 삭제
기존 방법(예: 비밀번호) 외에 인증을 위한 추가 요소를 생성하는 데 사용되며, 따라서 다단계 인증 수준을 생성합니다. 무료 가상 애플리케이션이나 물리적 장치를 사용할 수 있습니다. Google 인증기와 같은 앱을 사용하여 AWS에서 MFA를 무료로 활성화할 수 있습니다.
MFA 조건이 있는 정책은 다음에 첨부될 수 있습니다:
IAM 사용자 또는 그룹
Amazon S3 버킷, Amazon SQS 큐 또는 Amazon SNS 주제와 같은 리소스
사용자가 수용할 수 있는 IAM 역할의 신뢰 정책
MFA를 확인하는 리소스에 CLI를 통해 접근하려면 **GetSessionToken**을 호출해야 합니다. 그러면 MFA에 대한 정보가 포함된 토큰이 제공됩니다.
AssumeRole 자격 증명에는 이 정보가 포함되어 있지 않습니다.
As stated here, MFA를 사용할 수 없는 다양한 경우가 있습니다.
IAM 사용자 그룹은 여러 사용자에게 정책을 한 번에 연결하는 방법으로, 해당 사용자의 권한을 관리하기 쉽게 만들어 줍니다. 역할과 그룹은 그룹의 일부가 될 수 없습니다.
사용자 그룹에 신원 기반 정책을 연결할 수 있어, 사용자 그룹의 모든 사용자가 정책의 권한을 받습니다. 사용자 그룹을 정책의 Principal로 식별할 수 없습니다 (예: 리소스 기반 정책) 그룹은 인증이 아닌 권한과 관련이 있으며, 주체는 인증된 IAM 엔터티입니다.
사용자 그룹의 몇 가지 중요한 특성은 다음과 같습니다:
사용자 그룹은 많은 사용자를 포함할 수 있으며, 사용자는 여러 그룹에 속할 수 있습니다.
사용자 그룹은 중첩될 수 없습니다; 사용자만 포함할 수 있으며, 다른 사용자 그룹은 포함할 수 없습니다.
AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹은 없습니다. 그런 사용자 그룹을 원하면, 직접 생성하고 각 새 사용자를 할당해야 합니다.
AWS 계정의 IAM 리소스 수, 예를 들어 그룹 수와 사용자가 속할 수 있는 그룹 수는 제한되어 있습니다. 자세한 내용은 IAM 및 AWS STS 할당량을 참조하세요.
IAM 역할은 사용자와 매우 유사하며, AWS에서 **무엇을 할 수 있고 할 수 없는지를 결정하는 권한 정책을 가진 신원입니다. 그러나 역할은 자격 증명(비밀번호 또는 액세스 키)이 없습니다. 역할은 특정 개인과 고유하게 연결되는 것이 아니라, 필요한 누구나(충분한 권한이 있는 경우) 가정할 수 있도록 설계되었습니다. IAM 사용자는 특정 작업을 위해 임시로 다른 권한을 취득하기 위해 역할을 가정할 수 있습니다. 역할은 IAM 대신 외부 신원 공급자를 사용하여 로그인하는 연합 사용자에게 할당될 수 있습니다.
IAM 역할은 두 가지 유형의 정책으로 구성됩니다: 신뢰 정책, 비어 있을 수 없으며 누가 역할을 가정할 수 있는지를 정의하고, 권한 정책, 비어 있을 수 없으며 무엇에 접근할 수 있는지를 정의합니다.
AWS 보안 토큰 서비스 (STS)는 임시, 제한된 권한 자격 증명의 발급을 용이하게 하는 웹 서비스입니다. 이는 특히 다음을 위해 맞춤화되어 있습니다:
임시 자격 증명은 주로 IAM 역할과 함께 사용되지만, 다른 용도도 있습니다. 표준 IAM 사용자보다 더 제한된 권한 세트를 가진 임시 자격 증명을 요청할 수 있습니다. 이는 더 제한된 자격 증명으로 허용되지 않는 작업을 실수로 수행하는 것을 방지합니다. 임시 자격 증명의 장점은 설정된 기간 후에 자동으로 만료된다는 것입니다. 자격 증명이 유효한 기간을 제어할 수 있습니다.
권한을 할당하는 데 사용됩니다. 두 가지 유형이 있습니다:
AWS 관리 정책 (AWS에서 미리 구성한 정책)
고객 관리 정책: 사용자가 구성한 정책입니다. AWS 관리 정책을 기반으로 정책을 생성할 수 있습니다 (그 중 하나를 수정하고 자신의 것을 생성), 정책 생성기를 사용하거나 (권한을 부여하고 거부하는 데 도움을 주는 GUI 보기) 직접 작성할 수 있습니다.
기본적으로 접근은 거부됩니다, 명시적인 역할이 지정된 경우에만 접근이 허용됩니다. 단일 "거부"가 존재하면 "허용"을 무시합니다, AWS 계정의 루트 보안 자격 증명을 사용하는 요청은 기본적으로 허용됩니다.
The 전 세계에서 모든 서비스에 대한 조건으로 사용할 수 있는 필드는 여기에서 문서화되어 있습니다. 서비스별로 조건으로 사용할 수 있는 특정 필드는 여기에서 문서화되어 있습니다.
이러한 종류의 정책은 사용자, 그룹 또는 역할에 직접 할당됩니다. 따라서 다른 사용자가 사용할 수 있는 정책 목록에는 나타나지 않습니다. 인라인 정책은 정책과 적용되는 정체성 간의 엄격한 일대일 관계를 유지하고자 할 때 유용합니다. 예를 들어, 정책의 권한이 의도된 정체성 외의 다른 정체성에 우연히 할당되지 않도록 하고 싶습니다. 인라인 정책을 사용할 때, 정책의 권한은 잘못된 정체성에 우연히 연결될 수 없습니다. 또한, AWS Management Console을 사용하여 해당 정체성을 삭제할 때, 정체성에 내장된 정책도 삭제됩니다. 이는 그것들이 주체 엔티티의 일부이기 때문입니다.
이것은 리소스에서 정의할 수 있는 정책입니다. 모든 AWS 리소스가 이를 지원하는 것은 아닙니다.
주체가 이에 대한 명시적인 거부가 없고, 리소스 정책이 그들에게 접근을 허용하면, 그들은 허용됩니다.
IAM 경계는 사용자 또는 역할이 접근할 수 있는 권한을 제한하는 데 사용할 수 있습니다. 이렇게 하면, 다른 정책에 의해 사용자에게 다른 권한 세트가 부여되더라도, 그가 이를 사용하려고 할 경우 작업이 실패합니다.
경계는 사용자에게 첨부된 정책으로, 사용자 또는 역할이 가질 수 있는 최대 권한 수준을 나타냅니다. 따라서, 사용자가 관리자 접근 권한을 가지고 있더라도, 경계가 그가 S· 버킷만 읽을 수 있다고 나타내면, 그것이 그가 할 수 있는 최대입니다.
이것, SCPs 및 최소 권한 원칙을 따르는 것은 사용자가 필요 이상으로 많은 권한을 가지지 않도록 제어하는 방법입니다.
세션 정책은 역할이 가정될 때 설정되는 정책입니다. 이는 해당 세션에 대한 IAM 경계와 같습니다: 즉, 세션 정책은 권한을 부여하지 않지만 정책에 명시된 권한으로 제한합니다 (역할이 가진 최대 권한이 됩니다).
이는 보안 조치에 유용합니다: 관리자가 매우 특권이 있는 역할을 가정할 때, 세션이 손상될 경우를 대비하여 세션 정책에 명시된 권한만으로 제한할 수 있습니다.
Note that by default AWS might add session policies to sessions that are going to be generated because of third reasons. For example, in unauthenticated cognito assumed roles by default (using enhanced authentication), AWS will generate session credentials with a session policy that limits the services that session can access to the following list.
따라서, 만약 어느 시점에 "... because no session policy allows the ..."라는 오류에 직면하게 된다면, 그리고 역할이 해당 작업을 수행할 수 있는 접근 권한이 있다면, 이는 세션 정책이 이를 방지하고 있기 때문입니다.
Identity federation allows users from identity providers which are external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account. Identity provider의 예로는 귀사의 Microsoft Active Directory (via SAML) 또는 OpenID 서비스 (like Google)가 있습니다. 연합된 접근은 그 안의 사용자들이 AWS에 접근할 수 있도록 합니다.
이 신뢰를 구성하기 위해, IAM Identity Provider가 생성됩니다 (SAML 또는 OAuth), 이는 다른 플랫폼을 신뢰합니다. 그런 다음, 적어도 하나의 IAM 역할이 Identity Provider에 (신뢰하는) 할당됩니다. 신뢰된 플랫폼의 사용자가 AWS에 접근하면, 그는 언급된 역할로 접근하게 됩니다.
그러나 일반적으로는 사용자의 그룹에 따라 다른 역할을 부여하고 싶을 것입니다. 그런 다음, 여러 IAM 역할이 제3자 Identity Provider를 신뢰할 수 있으며, 제3자 플랫폼이 사용자가 하나의 역할 또는 다른 역할을 맡도록 허용하는 역할을 하게 됩니다.
AWS IAM Identity Center (AWS Single Sign-On의 후속 제품)는 AWS Identity and Access Management (IAM)의 기능을 확장하여 사용자 및 그들의 AWS 계정 및 클라우드 애플리케이션에 대한 관리를 통합하는 중앙 장소를 제공합니다.
로그인 도메인은 <user_input>.awsapps.com과 같은 형식이 될 것입니다.
사용자를 로그인시키기 위해 사용할 수 있는 3개의 아이덴티티 소스가 있습니다:
Identity Center Directory: 일반 AWS 사용자
Active Directory: 다양한 커넥터 지원
External Identity Provider: 모든 사용자 및 그룹이 외부 Identity Provider (IdP)에서 옵니다.
Identity Center 디렉토리의 가장 간단한 경우, Identity Center는 사용자 및 그룹 목록을 가지며 그들에게 정책을 할당할 수 있습니다 조직의 모든 계정에.
Identity Center 사용자/그룹에게 계정에 대한 접근을 부여하기 위해 Identity Center를 신뢰하는 SAML Identity Provider가 생성될 것이며, 지정된 정책으로 Identity Provider를 신뢰하는 역할이 대상 계정에 생성될 것입니다.
IAM Identity Center를 통해 생성된 역할에 인라인 정책을 통해 권한을 부여하는 것이 가능합니다. AWS Identity Center에서 인라인 정책을 가진 계정에 생성된 역할은 **AwsSSOInlinePolicy**라는 인라인 정책에서 이러한 권한을 가집니다.
따라서, **AwsSSOInlinePolicy**라는 인라인 정책을 가진 2개의 역할을 보더라도, 이는 동일한 권한을 가진다는 것을 의미하지 않습니다.
사용자 (신뢰하는)는 일부 정책을 가진 Cross Account Role을 생성한 다음, 다른 사용자 (신뢰받는)가 그의 계정에 접근하도록 허용할 수 있습니다. 그러나 새 역할 정책에 명시된 접근만 허용됩니다. 이를 생성하기 위해, 새 역할을 생성하고 Cross Account Role을 선택하면 됩니다. Cross-Account Access를 위한 역할은 두 가지 옵션을 제공합니다. 소유한 AWS 계정 간의 접근을 제공하거나, 소유한 계정과 제3자 AWS 계정 간의 접근을 제공합니다. 신뢰받는 사용자를 구체적으로 지정하고 일반적인 것을 사용하지 않는 것이 좋습니다. 그렇지 않으면, 연합된 사용자와 같은 다른 인증된 사용자가 이 신뢰를 남용할 수 있습니다.
지원되지 않음:
Trust Relations
AD Admin Center
Full PS API support
AD Recycle Bin
Group Managed Service Accounts
Schema Extensions
OS 또는 인스턴스에 대한 직접 접근 없음
앱은 AssumeRoleWithWebIdentity를 사용하여 임시 자격 증명을 생성합니다. 그러나 이는 AWS 콘솔에 대한 접근을 부여하지 않으며, AWS 내의 리소스에 대한 접근만 부여합니다.
비밀번호 정책 설정을 통해 최소 길이 및 비밀번호 요구 사항과 같은 옵션을 설정할 수 있습니다.
현재 자격 증명에 대한 정보(예: 사용자 생성 시간, 비밀번호 사용 가능 여부 등)를 포함한 "Credential Report"를 다운로드할 수 있습니다. 자격 증명 보고서는 최대 4시간마다 생성할 수 있습니다.
AWS Identity and Access Management (IAM)는 AWS 전반에 걸쳐 세밀한 접근 제어를 제공합니다. IAM을 사용하면 누가 어떤 서비스와 리소스에 접근할 수 있는지, 그리고 어떤 조건에서 접근할 수 있는지를 지정할 수 있습니다. IAM 정책을 통해, 최소 권한을 보장하기 위해 인력과 시스템에 대한 권한을 관리합니다.
이 페이지에서 키의 성격에 따라 IAM ID 접두사를 찾을 수 있습니다:
ABIA | |
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를 통해 AWS에 인증하기 위해서는 로컬 자격 증명이 필요합니다. 기본적으로 ~/.aws/credentials에서 수동으로 구성하거나 aws configure를 실행하여 구성할 수 있습니다.
해당 파일에는 하나 이상의 프로필을 가질 수 있으며, aws cli를 사용할 때 프로필이 지정되지 않으면, 해당 파일의 **[default]**라는 프로필이 사용됩니다.
하나 이상의 프로필이 있는 자격 증명 파일의 예:
If you need to access 다른 AWS 계정 and your profile was given access to 해당 계정 내에서 역할을 가정할 수 있는 권한, you don't need to call manually STS every time (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) and configure the credentials.
You can use the ~/.aws/config file to 어떤 역할을 가정할지 지정, and then use the --profile param as usual (the assume-role will be performed in a transparent way for the user).
A config file example:
이 구성 파일을 사용하여 aws cli를 다음과 같이 사용할 수 있습니다:
If you are looking for something similar to this but for the browser you can check the extension AWS Extend Switch Roles.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
