Study/AHSS

AHSS 1주차 - S3 취약점 및 보안

AHSS - 1기 1주차

S3 보안

S3 접근 통제 방법 3가지

객체 & 버킷 액세스 제어 목록 ACL : 액세스 제어 목록(ACL)을 사용하여 버킷 및 객체 각각에 대한 액세스를 제어할 수 있습니다 < 사용 비권장

> 사용 비권장 이유

Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없습니다. 각 객체에 대해 액세스를 개별적으로 제어할 필요가 있는 드문 상황을 제외하고는 ACL을 비활성화한 채로 두는 것이 좋습니다. ACL을 비활성화하면 누가 객체를 버킷에 업로드했는지에 관계없이 정책을 사용하여 버킷의 모든 객체에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 객체 소유권 제어 및 버킷에 대해 ACL 사용 중지 섹션을 참조하세요.

버킷 정책 : 버킷 정책은 S3 작업, 요청자, 리소스 및 요청의 여러 측면(예: IP 주소)를 비롯한 다양한 조건을 기반으로 버킷 및 객체에 대한 중앙 집중식 액세스 제어를 제공
IAM 정책 : IAM 을 사용하여 S3 리소스에 대한 액세스를 관리할 수 있습니다.

S3 권한 설정 실습 & IAM Access Analyzer

실습을 위한 S3 버킷 배포 (CLI)

# S3 버킷 생성 mb(make bucket)
#aws s3 mb s3://버킷이름 --region ap-northeast-2
NICKNAME=<자신의닉네임>
NICKNAME=yeongil
aws s3 mb s3://ahss-$NICKNAME --region ap-northeast-2

# S3 버킷 조회
aws s3 ls
aws s3api get-public-access-block --bucket ahss-$NICKNAME**

**각종 S3 버킷 데이터 유출 보안 사고로 조회 및 접근할 수 없도록 기본적으로 차단되도록 변경.**

**테스트를 위해**

[AWS 콘솔] 퍼블릭 액세스 차단 편집 : (Uncheck) 모든 퍼블릭 액세스 차단 → ‘변경 사항 저장’ 클릭 ⇒ ‘확인’ 입력

[AWS 콘솔] 버킷에 텍스트 파일 3개 객체 파일 업로드

# 파일 생성
echo "memo1" > memo1.txt
echo "memo2" > memo2.txt
echo "memo3" > memo3.txt

# S3로 업로드
aws s3 cp memo1.txt s3://ahss-$NICKNAME
aws s3 cp memo2.txt s3://ahss-$NICKNAME
aws s3 cp memo3.txt s3://ahss-$NICKNAME

# 파일 확인
aws s3 ls s3://ahss-$NICKNAME --recursive --human-readable --summarize
aws s3api list-objects --bucket ahss-$NICKNAME | jq

업로드된 파일 확인

[AWS 콘솔] 객체 URL 주소 확인 → 버킷 액세스 방식 확인 : 가상 호스팅 방식, S3 액세스 포인트, S3://를 사용 - 링크

AccessDenied의 원인은??!

[EC2] 자신의 버킷 탐색

# 출력 결과의 원인을 유추해보자!
NICKNAME=<자신의닉네임>
NICKNAME=yeongil
aws s3 ls s3://ahss-$NICKNAME --human-readable
aws s3 ls s3://ahss-$NICKNAME --human-readable --no-sign-request

[AWS 콘솔] 권한 → 객체 소유권 편집 : ‘ACL 활성화’ , ‘버킷 소유자 선호’

[EC2] 자신의 버킷 탐색

# 탐색 실행
aws s3 ls s3://ahss-$NICKNAME --human-readable --no-sign-request

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo1.txt . --no-sign-request

[AWS 콘솔] 객체 별 권한 설정

memo1.txt : 모든사람(퍼블릭 액세스) - 객체 (Check 읽기) → ‘변경 사항 저장’
memo2.txt : 인증된 사용자 그룹(AWS 계정이 있는 모든 사용자) - 객체 (Check 읽기) → ‘변경 사항 저장’

버킷 새로고침 후 확인

[EC2] 자신의 버킷 탐색

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo1.txt . --no-sign-request

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo2.txt . --no-sign-request

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo3.txt . --no-sign-request

결과는???! copy 성공!!

ACL을 사용하게 되면, 계정이 인증된 전세계 AWS 모든 사용자에게 자신의 버킷을 허용하게 되는 상황이니 조심하자!

[권장!]

[AWS 콘솔] 리소스 정책 : 버킷 정책 설정 - 편집 클릭 후 아래 내용 입력 후 ‘변경 사항 저장’

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ahss-닉네임/*"
        }
    ]
}

설정 후 aws cli 로 S3 버킷 정책 확인

aws s3api get-bucket-policy --bucket ahss-$NICKNAME | jq -r .Policy | jq

[EC2] 자신의 버킷 탐색 → 아래와 같은 (리소스 정책) 버킷 정책은 언제 필요할까?

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo1.txt . --no-sign-request

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo2.txt . --no-sign-request

# 파일 복사 실행 : 출력 결과의 원인을 유추해보자!
aws s3 cp s3://ahss-$NICKNAME/memo3.txt . --no-sign-request

IAM Access Analyzer 액세스 분석기

# 액세스 분석기 생성
#aws accessanalyzer create-analyzer --analyzer-name firstanalyzer --type ACCOUNT --output text --query arn
ANA_ARN=$(aws accessanalyzer create-analyzer --analyzer-name firstanalyzer --type ACCOUNT --output text --query arn)
echo $ANA_ARN

# S3 버킷 스캔 수행
aws accessanalyzer start-resource-scan --analyzer-arn $ANA_ARN --resource-arn arn:aws:s3:::ahss-$NICKNAME

# S3 버킷 스캔 결과 확인
aws accessanalyzer get-analyzed-resource --analyzer-arn $ANA_ARN --resource-arn arn:aws:s3:::ahss-$NICKNAME | jq
{
  "resource": {
    "resourceArn": "arn:aws:s3:::ahss-yeongil",
    "resourceType": "AWS::S3::Bucket",
    "createdAt": "2023-08-26T09:36:00.428000+00:00",
    "analyzedAt": "2023-08-26T09:38:56.698000+00:00",
    "updatedAt": "2023-08-26T09:36:00.428000+00:00",
    "isPublic": true,
    "actions": [
      "s3:GetObject"
    ],
    "sharedVia": [
      "POLICY"
    ],
    "status": "ACTIVE",
    "resourceOwnerAccount": "911283464785"
  }
}

버킷에 대한 퍼블릭 액세스 차단 설정

aws s3api put-public-access-block --bucket ahss-$NICKNAME --public-access-block-configuration \
"BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

실습 완료 후 액세스 분석기 삭제

aws accessanalyzer delete-analyzer  --analyzer-name firstanalyzer

실습 완료 후 사용한 리소스 삭제

# 버킷에 객체 모두 삭제
aws s3 rm s3://ahss-$NICKNAME --recursive

# 실습에 사용한 S3 버킷 삭제
aws s3 rb s3://ahss-$NICKNAME

# 확인
aws s3 ls

** recursive** ( 해당 명령어는 반드시 조심해서 사용하자!)

이 옵션을 사용하면 지정된 디렉터리 또는 접두사 아래의 모든 파일 또는 객체에 대해 명령이 수행됩니다. 다음 예제에서는 s3://my-bucket/path 및 모든 내용을 삭제합니다.

$ aws s3 rm s3://my-bucket/path --recursive

1주차 실습은 이렇게 마무리 되었다!

이외에 AWS 보안 컨설턴트인 Summit Route가 제공하는 AWS 보안 챌린지를 통해 본인의 AWS 보안에 대한 역량을 파악할 수 있도록 테스트 해보는 것도 좋은 방법!

http://flaws.cloud/

'Study > AHSS' 카테고리의 다른 글

AHSS - 2주차 IAM 취약점 및 보안 (0)	2023.09.08

Contents

당신이 좋아할만한 콘텐츠

AHSS - 2주차 IAM 취약점 및 보안 2023.09.08

새소식

인기 검색어