[새싹 성동 2기] Module Project 1 (24.11.08)- Review & Insight

일주일 간의 AWS 기초 이론 수업이 끝나고 

처음 모듈 프로젝트를 진행하고 끝냈다 

 

어떤 프로젝트를 할까 팀원분들과 고심했는데,

AWS 서비스를 구현해보는 걸 중점으로 WordPress를 활용하여 블로그페이지를 구현하기로 했다

 

EC2 인스턴스로 구현하는 팀과 serverless 아키텍처로 구현하는 팀으로 나뉘었는데, 

나는 serverless 팀에서 구현했다. 

 

우리 팀은 웹사이트 제작 업체라는 테마로,
처음 s3로 호스팅한 static website를 lambda로 마이그레이션,

severless로 구현된 웹사이트를 다시 EC2로 마이그레이션 한다는 시나리오 였다. 

 

AWS 서비스를 구현하기 전에 팀원 분이랑 상의하며, 아키텍처를 짜보기도 했다. 

 

- dynamic 웹 호스팅의 경우에는 API Gateway가 Lambda 함수를 호출하고, Lambda는 Bastion 호스트를 통해 RDS 데이터베이스와 통신하여 데이터를 처리

- Bastion 호스트는 외부 네트워크와의 접근을 제한해 RDS와의 안전한 연결을 보장

- API Gateway 앞단에 WAF를 배치해 악의적인 트래픽을 차단하고 보안을 강화했으며, CloudWatch가 WAF의 로그와 메트릭을 수집하여 트래픽 모니터링과 이상 감지를 지원

- CloudWatch에서 감지된 알림은 SNS를 통해 관리자에게 실시간으로 전달되어, 관리자가 문제를 신속하게 파악하고 대응할 수 있음

 

 

발표 후에, 강사님의 피드백에 따라 팀원 분과 다시 아키텍처를 고쳐보기도 했다 

 

개선사항

1) Region 추가되야됨 

2) lambda가 vpc에 포함되야됨

3) S3 - Static Web Hosting(게시판) 이 바로 client로 연결 되야함 (API Gateway와 연결될 필요 X) 

4) Bastion Host 두개 있을 필요 XXX - 한개로만 가능 

==> Bastion Host <-> RDS 연결되고 (필요한 경우:가용영역에 문제 생기거나 RDS 문제 생긴경우, RDS2(Replica)와 Bastion Host가 연결될 수 있음 

5) S3 for image <-> lambda 사이의 화살표 방향이 반대여야함 (람다함수를 통해 이미지 저장)

 

 

IAM, WAF, Cloud Watch, VPC, Lambda, EC2, RDS, S3, API Gateway, SNS 등의 많은 서비스를 실제로 구현해보면서,

왜 클라우드 환경이 필요하고 어떤 부분들을 고려해서 서비스를 선택하고 이용해야 하는지에 대한 전반적인 이해도가 높아진 것 같다.

 

다음에는 WAF Rule을 여러가지 생성해서, priority 적용하고, SNS를 email말고 실제로 많이 사용하는 slack 알람으로 연동하면 좋을 것 같다는 생각과 다짐을 했다..! 

 

 

Insignt from other groups 

lambda 함수 관련

- 내부에서 람다가 호출되는 경우, api gateway는 필요하지 않음

 

Q) lambda serverless 구조에 NAT Gateway가 꼭 필요한지? 

A) AWS EventBridge Lambda 서버리스 구조에서 NAT Gateway는 필수는 아님

-> VPC 외부 인터넷 접근: NAT Gateway 필요.

-> AWS 공용 서비스 접근만: VPC 엔드포인트로 NAT Gateway 대체 가능.

-> VPC 외부에서 실행: NAT Gateway 필요 없음.

 

AWS EventBridge

 

• 애플리케이션 간 데이터를 전달하는 대신, 이벤트를 통해 간접적으로 통신
• ex) S3에 파일이 업로드되면 Lambda가 트리거되도록 설정.

Amazon Cognito의 기능

: 자격증명 및 권한 조정 

==> react, 마운트 됐을때, 자격증명 설정 

==> IAM만 사용할시, access_key 노출 가능성이 있기 때문에 Cognito를 사용하여 보안을 강화

==> credential을 react에서 넣을 경우, 다 보임 --> server 단에 넣어야 브라우저에서 안보임 

 

보안 관련

1) 모든 보안 기능은 client와 server단이 항상 일치해야됨!

-> client단에서만 구현될 경우, 보안 기능이 제대로 작동하지 않음(프록시로 우회할 경우 뚫림) 

 

2) 업로드 공격

- S3에서 똑같은 파일명을 가진 사진을 업로드 할 경우, 에러 메세지 송출 & 파일 업로드를 막음

==> 서버에 저장될때 ,파일명이 그래도 노출 되면 안됨 (s3로 바로 올리지 않고, 서버로 먼저 올리고 데이터베이스에 저장)

 

(1)  크기,개수를 제한하지 않을 경우 

- 연결/저장소 서버 자원 고갈 

- "서비스 거부 공격" 

(ex) 임의로 큰 파일의 데이터를 올림  

 

(2) 종류를 제한하지 않을 경우

- 악성코드가 심어진 파일을 내려받을 경우 => 파일저장소가 바이러스의 전파구가 될 수 있음 

==> 파일 종류를 확인하는 방법 

1) 파일 확장자 - png, jpg

2) content-type - img/png 

3) content-length(DDos 공격) - POST 방식에서 본문 데이터

4) file의 magic number(=file signature) 

==> 프록시로 파일 확장자나 타입은 쉽게 변경이 가능하기 때문에 , file의 magic number(=file signature) 같은 것들을 사용하여 검증해야됨 !!중요한 파일 시스템인 경우 !! 

 

(3) 외부접근이 가능한 경로로 저장할 경우 

- 웹 서비스의 주도권을 탈취당할 수 있음 

 

업로드는 항상 다운로드와 함께 구현 & 취약점도 함께 고려해야함!! 

다운로드 취약점 - 경로조작 (지정된 경로에서 읽도록 해야됨) 

../를 통해 root로 도달이 가능 -> root에 도달하면 system 디렉토리를 제어할 수 있음 

==> 경로조작 문자열(../ 등)이 들어오지 않도록 하고, 지정된 경로에서만 다운로드가 가능해야함! 

저장되는 경로와 저장되는 파일명을 외부에서 알수 없도록 해야됨 & 내부에선 저장 + access 할수 있는 ID를 발급 

 

 

3) 보안그룹 네이밍 잘 활용하기, 인바운드&아웃바운드 규칙 잘 활용하기

IAM 권한 설정

Developer Role, Viewer Role, Admin Role에 따라 다른 권한 부여 (!최소 권한 원칙!)