티스토리 뷰
들어가며
파일 업로드의 이미지를 로컬에서 저장하지 않고 Aws S3에 이미지를 저장하기 위해서 accessKey, secretKey 발급받았다. 하지만 나의 실수로 인해 accessKey가 노출되어서 무작위 인스턴스과 요금이 발생하였다. 현재 나는 2개의 서버를 돌리고 있고 프리티어로 사용하여 천 원대의 요금을 내고 있다. 주위에 해커들이 있다는 것을 인지하기 위해서 글을 남기기로 마음먹었다.
1. Aws S3
클라이언트에서 여러 개의 파일을 서버로 보내고 MultipartFile 타입으로 받아서 고유 식별자 이름으로 S3 스토리지에 저장한다. S3 스토리지를 연결하기 위해서 accessKey, secretKey, region 필요하다. 이 정보들은 application.yml 파일 안에 설정 값들을 저장해두었다. 그리고 수정한 코드들을 깃허브에 push 하였다.
2. 무작위 인스턴스 생성(해커)
서버의 IP를 조회하기 위해 ec2 들어갔는데 1시간 전 새로운 인스턴스 5개가 생성되었다.
일단 인스턴스를 중지하고 종료하고 계정의 패스워드를 변경하였다. 하지만 갑자기 인스턴스가 생성하는 것 보았을 때 계정이 털린 게 아니라 엑세스 키 부분에서 의심이 됐다. 그래서 일단 엑세스 키를 삭제하고 IAM 사용자를 추가해서 필요한 권한(S3)에만 부여한 다음 접근키와 비밀키를 생성하였다. 엑세스 키가 어디에서 노출되었는지 확인하던 중 깃허브에 application.yml 파일이 있었다. 최대한 빨리. gitignore에 추가하고 그 전의 application.yml 파일들을 삭제하였다.
3. AWS 메일과 요금
메일을 간략하게 설명한다면 "너의 엑세스 키는 털렸다. Github에서 올린 파일에서 비밀 키가 온라인에서 공개적으로 사용하고 있다. 빨리 중지하지 않으면 AWS 계정이 일시 중지한다." AWS의 빠른 대처와 작은 실수를 캐치하는 부분이 되게 멋있었다. 나의 실수는 두 가지였다. 모든 곳에서 접근 가능한 Access Key 만든 것과 그 엑세스 키를 깃허브에 노출시킨 것이었다.
그래도 빠른 대처로 각 인스턴스의 1시간 정도의 요금을 내게 되었다.
4. 정리
1. 모든 곳에서 접근 가능한 Access Key 생성하지 않기
2. IAM에서도 권한 제어하기
3. 접근 키와 비밀 키는 절대로 노출시키지 않기
4. AWS 내부에서 문제가 생기면 메일 확인하기
'∙Server' 카테고리의 다른 글
EC2에서 디스크 용량 부족 문제로 발생한 API 오류 해결하기 (0) | 2024.09.10 |
---|---|
Nginx와 헬스체크를 활용한 무중단 배포하기 (0) | 2024.09.02 |
Nginx에서 SSL 인증서 갱신하기 (0) | 2023.11.10 |
Nginx 다중 도메인 서버 설정하기 (0) | 2023.11.07 |
NGINX + HTTPS 적용하기 (0) | 2022.05.10 |