사용 사례 - 정적 웹 호스팅 버킷
•
위 3가지 취약점 해소를 위해 단순하게 CloudFront 사용!
•
B. 버킷이 퍼블릭 공개라는 점 → 해결책
•
Origin Access Control을 이용하여 CloudFront To S3만 가능하도록 설정 (BY OAI)
•
이 OAI 설정은 S3를 퍼블릭으로 공개하지 않고도 Cloudfront를 통해서 S3에 퍼블릭하게 접근할 수 있음과 동시에 Cloudfront를 우회하여 S3에 직접 액세스할 수 없음(중요)을 의미합니다.
•
A. https가 아닌 http 통신을 해야 한다는 점 → 해결책
•
C. AWS S3의 엔드포인트 주소를 그대로 사용해야 한다는 점 → 해결책
IP Control
•
특정 IP에 대해서만 접근 제어하고 싶을때 But, CF를 통한 OAI 설정이 되어있는 경우 버킷 정책으로 IP 제어가 어렵다.
→ WAF 로 제어
•
WAF의 IP Set Rule을 통해서 IP 제어
사용사례 - 정적 리소스 파일 서빙용 버킷
•
S3 버킷을 정적 리소스 데이터인 css, js, jpg 등을 서빙하기 위한 웹 리소스 저장소로 사용하는 경우
사용 사례 - 원격 파일 저장용 버킷
•
원격지에서 S3로 파일을 업로드하거나 공유 목적으로 읽기를 허용해야 하는 경우
•
가능하다면 IP 제어로 접근 통제하는 것이 좋다
•
대부분의 경우는 동적 IP 인 경우가 많아 차선책으로 Referer로 헤더 검사
•
HTTP Header에 Custom Header인 ‘Check’: ‘woowa-check’ 값이 있는 경우만 접근 가능하도록 통제 BY WAF
—> 따라서, 버킷에 연결된 도메인 주소와 검사하고 있는 임의의 웹 헤더, 웹 헤더 값을 모두 알고 있어야 우회가 가능합니다. 따라서, 버킷에 연결된 도메인 주소와 검사하고 있는 임의의 웹 헤더, 웹 헤더 값을 모두 알고 있어야 우회할 수 있습니다.
사용 사례 - presigned-url를 활용한 버킷
특정 사람에게만 일시적으로 공유
•
버킷이 프라이빗이고 퍼블릭으로 오픈할 필요가 없기 때문에 CF를 붙이지 않아도 된다.
•
소스 IP에 대해서만 presigned-url 접속 제한.
◦
presigned-url은 GetObject로 접근
한 번만 호출하도록 공유
•
presigned-url로 호출된 해시된 파일을 다운로드(GetObject)가 발생한 경우 CloudWatch EventBridge가 이벤트를 잡아서 해당 파일 삭제
사용 사례 - 민감한 정보 저장용 버킷
•
이번 민감한 정보 저장용 버킷 사례에서 다뤄볼 예시는 AWS 멀티 계정(Multi Account)환경에서 서비스를 운영하는 상황을 가정하고 다루었습니다.
•
버킷 관리를 위한 태그 정책이 있어야 한다.!!
→ 버킷에 담긴 데이터라던지 특징을 파악할 수 있다.
→ 버킷명도 네이밍 룰도 있어야..
•
IAM / Role에 특정 버킷만 접근해야한다는 정보가 있어야 한다.
→ IAM Role과 Bucket Policy를 직접적으로 타겟을 서로 삼아서 지정하는 것이 안전한다.
(이쪽으로 접근하겠다. 이쪽으로의 접근을 허용하겠다..)
•
보안 계정을 별도로 생성해서 민감한 정보를 저장하는 버킷 관리
•
cross account 개념으로 필요한 리소스(서버)에서만 최소한의 권한으로 접근할 수 있다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:Put*",
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::{{보안 계정 민감 대상 버킷 이름=best-ljh-test-bucket}}/*",
"arn:aws:s3:::{{보안 계정 민감 대상 버킷 이름=best-ljh-test-bucket}}"
]
}
]
}
JSON
복사
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::{{서비스계정 번호}}:role/{{서비스계정 ec2 전용 IAM Role = woowa-iam-ec2-baemin-role }}"
},
"Action": [
"s3:Put*",
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::{{해당 민감 버킷 이름 = best-ljh-test-bucket}}",
"arn:aws:s3:::{{해당 민감 버킷 이름 = best-ljh-test-bucket}}/*"
]
}
]
}
JSON
복사
침해사고대응 관점에서 바라본 민감 정보 버킷 분리 보관의 이점
•
A Server의 Role에 PolicyDescribe 권한이 없다면 본인 계정에 대한 S3 버킷 목록만 조회되고 보안 계정내 S3 버킷 목록은 알 수 없다.
Q&A
•
모니터링 시스템에 업로드 후 분석
1.
보안 모니터링을 통해 Bucket Policy에 오류나 과다한 권한 확인. PutBucketPolicy가 발생했을 때 감지등…
2.
컴플라이언스 정책에 따라 구성.(민감한 정보 저장 버킷)
3.
IAM Role에 최소한의 정책만 설정
4.
S3에서 제공하는 암호화 기능 사용
•
보안 기능 우수하다. CloudTrail에서도 S3 감사 가능
•
그러나, 설정이 너무 많고 복잡하다보니 잠재적인 위험이 있을 수 있다.
•
S3 보안 모니터링은?
◦
CloudTrail을 통해서 SIEM으로 로그 수집
•
Origin은 최대한 숨기는 개념으로 바라봐야…
•
OAI 기능 → Origin을 숨기는 기능이다.
•
단순하게 퍼블릭 버킷은 없고 C/F를 통해서만 퍼블릭으로 오픈한다로 정책을 가져가는것이 보안측면에서 좋다. (모니터링도 쉽고..)
•
GuardDuty, CloudTrail
•
AccessDenied 이벤트 모니터링도 필요..
•
Access Key 관리
◦
IAM 관리자가 발급/관리 역할
◦
Access Key 라이프 사이클 설정 필요
◦
궁극적으로 Access Key를 미사용하는 아키텍처로 나아가야한다.
•
키 관리는 HashiCorp Vault + 자체 개발 기능