[AWS] Github에 AWS access key를 노출하면 일어나는 일 (따라하지 마세요)

따라할거라면 글을 끝까지 읽고 따라하세요

 

VIVA 프로젝트를 보면...

이렇게 사진을 업로드해야 하는 부분이 있다.

그래서 S3 bucket을 사용하고 있었는데

 

https://victorydntmd.tistory.com/70

[Node.js] AWS(1) - S3 사용하기 ( aws-sdk, multer-s3 모듈 )

이것과 비슷한 블로그를 봤을 것이다.

왜 이 블로그가 아닐 것이라면 여길 봤다면 난 Access key를 그렇게 노출하지 않았을테니까...

 

https://myunji.tistory.com/189?category=1154148 

[백엔드] React Native에서 Node.js로 이미지 보내기(feat. multer)

이때 로컬로 이미지 업로드를 구현하긴 했었다.

 

저기 있는 코드에서 storage 부분만 바꿔서

const multer = require('multer');
const multerS3 = require('multer-s3');
const aws = require('aws-sdk');
aws.config.loadFromPath(__dirname + "/../config/awsconfig.json");
const s3 = new aws.S3();

var storage = multerS3({ 
  s3: s3,
  bucket: 'viva-s3-capstone',
  acl: 'public-read',
  key: function (req, file, cb) {
    cb(null, Math.floor(Math.random() * 1000).toString() + Date.now() + '.' + file.originalname.split('.').pop());
  }
});
var upload = multer({ storage: storage });

이렇게 하면 로컬폴더가 아니라 우리의 S3 bucket에 이미지가 올라간다.

여기까진 잘했다. 하지만 난...

 

aws.config.loadFromPath(__dirname + "/../config/awsconfig.json");
const s3 = new aws.S3();

지금은 이렇게 바꿔놓은 이 부분을

 

aws.config.loadFromPath({
  accessKeyId: "엑세스 키",
  secretAccessKey: "비밀 키",
  region: "ap-northeast-2"
});
const s3 = new aws.S3();

이런식으로 아주 당당하게 노출하고 있었다.

그리고 이걸 프론트엔드와 공유해야하니 깃허브에 올렸다. 당연히 우리 레포지토리는 퍼블릭이었다.

 

그리고...

로 시작하는 긴 메일

AWS에서 메일을 보냈다. 대충 너네 키 노출됐는데 이거 보안상에 큰 문제 생기니까 당장 해결하라는...

아주 당황스러웠다. 왜냐면 우린 변방에 아주 하찮은 학부생들이었고 이걸 이렇게 알아채고 메일을 보내줄거란 생각은 하지 못했다.

 

이런 상황이 처음인지라 우린 당황하면서 일단 레포지토리를 private으로 바꾸고, AWS 계정 정보도 수정하고 bucket도 새로 만들고 아무튼 그랬다.

 

그리고 그땐 한참 YOLO 모델을 위해 라벨링에 집중하던 시기라 잊고 있었는데...

나중에 프로젝트를 제출할 때 소스코드를 제출해야 한다는 것이 떠올랐다.

 

그래서 이런식으로 key를 따로 빼고 gitignore까지 잘해서 업로드했다.

키와 관련된 정보가 안올라간 것을 확인하고 다시 public으로 돌렸는데

 

도대체 왜 노출됐다는건지 이해를 할 수 없었다. 분명히 없는걸 확인했는데?

하지만 난 여전히 겁이 많으므로 다시 private으로 돌리고 원인을 찾으러 떠났다.

 

원인은 내 커밋 히스토리에 있었다.

히스토리에 수정기록이 전부 있으니 당연히 원래 있던 키가 지워지는 과정까지 전부 남아있었고

그 곳에 내 엑세스 키가 여전히 남아있었던 것이다.

 

커밋 히스토리 지우는 법을 찾으러 떠났다...

https://donologue.tistory.com/373

github 잘못 올라간 파일 히스토리까지 삭제하기

답은 git filter-branch 명령어였다.

 

여기에 원하는 파일의 경로와 이름을 쓰면 깃 히스토리에서 그 파일이 들어간 히스토리만 지워준다고 한다.

내가 지워야하는 히스토리는 routes에 있는 파일 2개와 config에 있는 파일 1개였다.

 

저 블로그에 적혀있는대로

git filter-branch -f --index-filter 'git rm --cached --ignore-unmatch VIVA/routes/파일이름' --prune-empty -- --all

이걸 해줬고

 

git push origin main --force

이걸 했다.

 

지금보니 rm에 force에 무시무시한 명령어가 가득했는데 당황한 새벽의 나는 미처 알아채지 못했다.

아무튼 원래 52 commits 이었는데 이렇게 줄어든 것을 보고 히스토리 삭제도 확인하고 해결했다 싶었다.

 

근데 인텔리제이를 켜보니 세상에

파일이 로컬에서도 사라진 것이다.

 

난 rm이 히스토리만 지워주는 그런 것인줄 알았는데 로컬에서도 파일을 지워버렸다!

나에겐 백업본이 없었지만 다행히 이 레포지토리의 또다른 컨트리뷰터인 프론트 팀원이 파일을 갖고 있어 복구했다.

 

그리고 남은 두 파일에 대해선 미리 백업을 해두고 명령어를 입력했다.

만약 이 레포지토리의 컨트리뷰터가 나 하나였다면..? 그런 끔찍한 일은 상상하고 싶지 않다.

 

아무튼 git filter-branch 명령어를 사용하기전 filter할 파일을 반드시 백업해야한다.

 

난 앞으로 뭐든 삭제할 일이 있으면 무조건 백업할 것이다.

그리고 뭐든 key 어쩌구가 들어가는건 절대...올리지 않을 것이다.