여러분은 최종 데모 이틀 전에 DB를 해킹 당해본 적이 있나요?

때는 바야흐로 그룹 프로젝트 최종 발표 D-2.. 한마디로 진짜 왕바쁜 때였다. 그런데 프론트 팀원이 갑자기 "어?" 금기어를 외치더니 "혹시 서버 잘 되나요 지금?" 이렇게 여쭤보셨다. 서버는 문제 없었다. 근데 프론트엔드 팀원 분 말씀으로는 로그인이 안 된다는 거였다. 회원가입을 전에 해놓은 사용자인데 회원가입 되어있지 않은 사용자라고 HTTP Response가 오길래 혹시 몰라 DB를 확인해보니 DB가 깨끗하게 지워져있었다.

처음에는 로그가 쌓여서 문제가 생겼나 싶었다. 애꿎은 로그관리를 갑자기 하기 시작했다 시간도 없는데.. 그래서 이제 괜찮겠지 싶었는데 30분 정도 있다가 그 사이에 또 회원가입 된 사용자가 없어졌다는 것이었다..

아 이거 뭔가 잘못됐다 싶어서 다시 살펴보다 혹시 몰라 DB 커넥션을 봤는데

👀... READ_ME_TO_RECOVER_YOUR_DATA ..? 이자식들 이거 보는 순간 헛웃음 났다. 사실 이날부터 몇 주 전쯤에 네부캠 사람들 중 꽤 여러 사람이 NCP 해킹을 당했던 적이 있었다. 이때만 해도 내 일은 아니겠거니와 싶었는데.. 어림도 없지!

아주 바빴을 때라 화가 많이 났지만.. 사실 기존의 DB의 경우 보안을 거의 고려하지 않고 구축하긴 했었다. 그렇다. 내 잘못이었다.. 진짜 내 잘못임... 거의 대문을 활짝 열어둔 수준 ㅋ.ㅋ

팀원들도 적잖이 당황하고 기억에 남았는지 동료평가에 DB 해킹 당해서 열심히 복구한 내용을 많이 칭찬해주셨다.

하지만... 이것은 칭찬 받은 일이 아니고...ㅋ.ㅋ 진작 잘 했어야했는데 너무 프로젝트라고 간단하게 해놓고 쓰다가 큰코 닥친 격..

반성은 뒤로하고 아무튼 다시 DB를 구축할 때는 이제 진짜 해킹되면 안되기 때문에 여러 가지 방법을 고려해서 구축을 했었다. 그 과정을 정리해보려고 한다.

✅ 기존 DB

과연 해킹당한 DB는 어떻게 구축했던 것일까.. 그냥 서버 instance에 MongoDB 깔아둔 뒤에 사용했다. 서버도 인바운드 규칙을 꼼꼼하게 적용하지 않아서 여러 IP 주소와 포트를 활용해 접근할 수 있는 상태였다. MongoDB도 Password 설정을 따로 하지 않고 바로 접근할 수 있게 설정되어 있었다.

쉽게 말해 우리끼리 진행하는 프로젝트다보니까 보안 관련 부분보다는 바로바로 구현에만 집중했고 덕분에 뒤통수를 세게 맞은 것이었다. 뼈아픈 경험.. 다시는 이러지 않겠다고 다짐하며 DB 구축에 나선다..