프로젝트 최종 회고

김성훈·2023년 6월 29일

JobInterview 기술면접 면접

프로젝트

목록 보기

2/3

아키텍처의 전반적인 설명

우선 저희 팀의 아키텍처 - Task Management 는 기능적으로 칸반보드로 업무 관리를 하는 툴의 역할을 하도록 설계했습니다.

해당 아키텍처로 구성되는 프로그램은 Supervisor - PIC로 유저가 나뉘고, Supervisor 유저가 로그인을 하고나면 담당자 PIC 지정 부터 작업 상태, 작업 내용, 마감기한 등을 설정하는 툴입니다.

Route53에서 배포된 도메인을 웹브라우저를 통해 접속, Route53은 CloudFront에서 캐싱한 S3의 정적웹페이지를 사용자에게 제공
정적 웹페이지로부터 오는 트래픽을 메서드와 도메인 엔드 포인트 별로 분류해 로그인 요청 데이터는 인증 계층 Lambda로 보내고, 작업관리 요청 데이터는 VPC 경계의 ALB로 전송( ALB 외부 노출 방지 )
반응 트래픽은 API Gateway를 통해 원래의 클라이언트로 반환
API Gateway로부터 들어오는 요청을 현재 가동중인 ECS 서비스에 속한 EC2 컨테이너들로 전송
응답 트래픽은 API Gateway를 통해 원래의 클라이언트로 반환
작업 관리 CURD 트래픽을 EC2와 교환(ECS로 배포된 EC2 )
CRUD 요청을 ECS의 컨테이너로 전송
Aurora DB와 ECS가 소통하여 작업 관리 페이지에 들어오는 요청을 처리한다. ECS의 각 인스턴스가 사용자 요청에 따라 해당 DB에서 정보를 가져오거나 업데이트
ECS 인스턴스 성능과 사용량 모니터링을 위해 CloudWatch 사용
Aurora에 ECS 인스턴스와의 상호작용으로 작업이 처리되고 로그 데이터는 DynamoDB에 저장 -> Lambda로 전송-> 이벤트 알림 이메일 전송

마지막, Git Action은 GitHub 레포지토리에 push된 코드들을 자동으로 각 코드들이 배포되어야할 리소스로 배포합니다. CRUD이미지는 ECS 컨테이너로, 로그인요청처리와 로그이벤트코드는 각각의 람다 함수로, 프론트 웹페이지 코드는 s3 버킷으로 배포되도록 CI/CD 파이프라인을 구성했습니다.

프로젝트 안에서 본인이 맡은 업무

1. 프론트엔드

1.1 Amazon S3

로그인 페이지와 Task Management 페이지 저장

1.2 CloudFront 배포

1.3 Route 53 연결

Route 53 - CloudFront 배포의 값을 대체도메인으로 설정
이제 유저는 www.hoonology.click을 통해 접속을 할수 있게 됐다.

2. 인증 계층 설정

2.1 DynamoDB 테이블 생성

Supervisor 인증을 위한 유저 데이터 저장

2.2 Lambda 함수를 DynamoDB에 연결

인증은 로그인 시 입력한 email을 DynamoDB의 '파티션 키- 정렬키'와 비교하여
'일치 / 불일치' 여부를 판단 후 'statusCode'와 함께 로그인 '성공 / 실패'를 리턴한다.

Lambda 함수 - 'index.js'

2.3 API Gateway 생성

정적 웹사이트를 통해 들어온 로그인 요청 데이터(트래픽)의 인증 계층을 Lambda에 보내는 역할
이후 ALB를 통해 내부에서만 소통하도록 함 (VPC의 보안을 위함)

1. '/dynamo_user' 리소스에 'POST'메소드로 Lambda에 트리거 되도록 함
2. 루트 리소스에서 'GET','POST' 요청으로 ALB로 연결된 백엔드 값을 조회할 수 있도록 함
3. API 게이트웨이가 Lambda에 트리거된 것을 확인

4. 인증 확인( 로그인 성공 )

5. 루트 리소스에서 GET 요청에 따른 응답이 나온다.

3. 메시지 알림 서비스

3.1 SES에 이메일 주소 등록하고 보안인증을 한다.

보안인증을 완료한 이메일 자격증명을 SES에서 확인할 수 있다.

3.2 DynamoDB에 작업 상태 변경시 발생하는 로그를 기록하는 테이블 생성

3.3 DynamoDB의 테이블을 불러오는 Lambda 함수 생성

3.4 EventBridge를 생성하고 Lambda와 연결

DynamoDB에 저장된 로그가 EventBridge를 트리거로하여 Lambda 함수에 전달되고 그 값들을 조회할 수 있게 된다.

상태 변경 시, 이메일을 통해 로그가 수신됨을 확인할 수 있다.

내가 했던 트러블 슈팅

login.html - API Gateway - task.html 통신 오류 해결 과정

브라우저 개발자 콘솔에서 확인한 결과, API Gateway, Lambda, S3의 CORS 문제였다.

Lambda
- 코드 내에서 응답 코드의 헤더 부분에 CORS 설정을 해주었다.
S3
- 버킷 정책과, CORS 설정
API Gateway

이 과정에서 가장 애를 먹었다. 모든 CORS를 수정했는데도 불구하고 해결되지 않던 문제가 API 재배포를 하니 해결되었다.

아키텍처의 보안성에 대한 고려한 부분이 있는지

1. S3 정책

("Principal": "*")가 s3:GetObject 및 s3:PutObject 작업을 수행하도록 허용합니다. 즉, 버킷 이름을 아는 사람은 누구나 버킷에서 읽고 쓸 수 있습니다. 이는 심각한 보안 위험입니다.

해결

보안 주체를 버킷에 액세스해야 하는 특정 IAM 역할 또는 사용자로 제한합니다.
퍼블릭 읽기 액세스를 허용해야 하는 경우 S3 버킷에 대한 직접 액세스를 허용하는 대신 CloudFront와 같은 콘텐츠 전송 네트워크(CDN)를 사용합니다.

아래와 같이 정책을 업데이트하여 해결합니다.

{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity YOUR_OAI_ID"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::login-task/*"
        }
    ]
}

2. CORS 구성

CORS 구성은 모든 오리진("AllowedOrigins": ["*"]) 을 허용합니다. 이는 모든 웹사이트가 API에 요청할 수 있음을 의미합니다. 이로 인해 잠재적으로 민감한 데이터가 악성 웹사이트에 노출될 수 있습니다.

해결

허용된 출처를 API 액세스를 허용해야 하는 특정 도메인으로 제한합니다. 모든 도메인에서 API에 액세스해야 하는 경우 OAuth 또는 API 키와 같은 추가 보안 조치를 구현하는 것이 좋습니다.

3. Access-Control-Allow-Credentials: 'access-control-allow-credentials'

를 'true'로 설정하면 쿠키, HTTP 인증 및 클라이언트 측 SSL 인증서가 요청과 함께 전송됨을 의미합니다. 와일드카드 출처(*)와 결합하면 악성 웹사이트가 API에 인증된 요청을 할 수 있습니다.

해결

자격 증명을 사용해야 하는 경우 위에서 언급한 것처럼 허용된 원본을 제한해야 합니다. 또한 인증을 위해 쿠키 대신 토큰 또는 기타 메커니즘을 사용하는 것을 고려합니다.

4. 누락된 암호화

S3 버킷 정책 및 CORS 구성은 암호화 요구 사항을 지정하지 않습니다. 이것은 잠재적으로 민감한 데이터를 노출시킬 수 있습니다.

해결

모든 연결에 HTTPS를 사용합니다. S3의 경우 저장된 데이터에 대해 서버 측 암호화를 사용하는 것이 좋습니다.

이 시스템이 잘못 됐을 때 어떻게 되는지

많은 트래픽에 대한 대처

이 서비스 말고 다른 서비스를 사용할줄 아는가

김성훈

I wanna be your good partner

이전 포스트

Final Project - Task Management 회고

다음 포스트