단순 .env 파일 사용단순히 .env를 협의로만 관리할 경우 문제점FE에서 env sync 이슈를 해결할 수 있는 방법undefined를 허용하지 않는다.빌드 스크립트에서 값의 유무를 검사한다.secret managementsecret management 사용 이유와 Frontend 에서의 보안infisical 문서화Hashicorp Vault 문서화
단순 .env 파일 사용
단순히 .env를 협의로만 관리할 경우 문제점
env sync이슈가 항상 있을 수 있다.
새로운 기능이 추가되면서 새로운 환경변수가 추가되어야 한다던지, key 값 유효기간이 만료돼서 기존 키값에서 변경되어야 한다던지 등 env 값이 바뀔 수 있는 상황이 종종 있다.
이 경우에 모든 관련 개발자들이 이를 숙지하고 동시에 똑같이 반영을 해야하는데, 아무리 전파를 잘 하더라도 빼먹을 수 있는 가능성이 항상 존재한다.
이는 팀 규모가 커질 수록 이슈가 더 잦게 발생하게 된다.
FE에서 env sync 이슈를 해결할 수 있는 방법
undefined를 허용하지 않는다.
.env 자체는 git에 올리지 않지만, .env에 있는 값을 활용하는 코드 자체는 git에 올라간다.
즉 env를 활용하는 로직에서 값이 undefined 일 경우 예외를 던지도록 코드를 작성하면 필요한 키 값이 빠져있다는 것을 인지할 수 있다.
다만 env 값을 검증하는 코드를 빼먹는 휴먼에러가 있을 수 있고,
런타임에서 감지하는 방식이므로 배포 후에 이슈를 감지하게 된다는 문제점이 있다.
빌드 스크립트에서 값의 유무를 검사한다.
런타임에서 에러가 나는 것이 문제라면, 빌드 시에 검사하도록 하면 된다.
필요 값들을 >> .env 로 넣는 과정이 끝난 후 필요한 값들이 있는 지를 하나씩 검증하고, 없을 경우 빌드를 실패 시킨다.
이렇게 되면 배포 후에 런타임에서 터지는 경우를 방지할 수 있다.
다만 env를 추가하는 사람이 env와 코드만 추가할 게 아니라, 빌드 스크립트 쪽도 잘 수정 해줘야한다.
이 또한 휴먼에러를 완전히 배제할 수 없다. (담당자가 잘 숙지하고 있어야 할 뿐 아니라, 리뷰어들도 이를 꼼꼼히 검증해줘야 한다.)
secret management
Hashicorp Vault,AWS Secrets Manager,Google Cloud Secret Manager,infisical- 앞의 3개는 널리 알려진 솔루션
infisical은 그에 비해선 이제 알려지기 시작한 프로젝트
Hashicorp Vault와infisical은 오픈소스- ,
- 오픈소스이므로 self-hosting 하는 경우에는 무료이지만, 유료로 클라우드 서비스도 제공하고 있다.
secret management 사용 이유와 Frontend 에서의 보안
- 팀 규모가 커짐에 따라
.envsync 이슈를 가장 많이 체감하게 된다. - 새로운 env를 추가하거나 기존 키값을 변경해야 한다고 동료에게 전달했으나, 동료가 누락하는 경우
- secret management는 이를 아주 쉽게 해결해준다.
- fe에서는
.env파일이 제품에 포함된 채로 배포된다. - .env 파일을 깃에 올리진 않는다. 아주 최소한의 보안 목적으로
- 하지만 프로젝트 코드가 해당 값들을 참조해야 하므로, 실제 배포 시점에는 .env 값들을 포함해서 빌드를 하게 된다. 따라서 제품 내에는 .env 값들이 다 담겨있다.
- be는 제품 자체가 드러나진 않지만, fe는 제품 자체가 사용자에게 드러난다. 즉 client 측에서 리버싱을 통해 직접 해당 값들을 눈으로 확인할 수 있다.
- secret management는 1차적인 보안책이 된다.
- 제품 내에 영구적으로 존재하며, .env 파일이 할당된 곳을 찾으면 모든 env를 한번에 다 볼 수 있다는 문제점을, 이제는 secret management를 사용해서 필요할 때 필요한 값만 참조해서 볼 수 있게 변경되었으므로, 리버싱을 하더라도 .env와 같이 한번만 찾으면 끝나는 형태가 아니라, secret management 로직을 사용하는 모든 순간을 포착해서 하나씩 값을 수집해야 하는 번거로움을 줄 수 있다.
- 정적 리버싱으로는 해당 값을 볼 수 없어졌다. (.env는 정적리버싱으로도 다 드러남)
- secret management를 쓰더라도 해당 로직을 담는 코드들이 fe 프로덕트 내에 포함된다는 것은 동일하다. 따라서 리버서가 공수를 더 들이면 결국에는 원하는 값을 볼 수 있다는 것은 변함없다.
- 다음으로 추가할 수 있는 보안 방법은 자바스크립트 코드 난독화를 적용시키는 것이다.
- 이 또한 리버서의 분석 공수를 늘리는 목적이 크며, 결국에는 값을 볼 수 있다는 것을 해결하진 못한다.
- 난독화의 목적은
ㅅㅂ 이거 볼 바에 다른 거 본다생각이 들도록 리버서의 시간을 충분히 빼앗는 목적이 크다. - 공개되어도 되는 값만 프론트엔드에서 직접 사용한다.
- 개고생을 해서 Key 값을 결국 찾아냈다고 하더라도, 해당 Key 값으로 치명상을 입힐 수 없는 것들이라면 공격자가 추가로 할 수 있는 부분이 서비스 트래픽을 늘려서 과금을 더하도록 유도하는 것 외에는 별다른 타격을 입힐 수 없다.
- 즉 fe에서 key값을 직접 참조해서 사용해야 하는 경우에는 Key의 인증범위를 축소시켜서 사용해야 하며, key 값이 공개됐을 때 사용자 정보 누출, 핵심 코드 누출, 서비스 다운 등 치명상을 입힐 수 있는 주요 Key 값이라면 프론트엔드에서 직접 담으면 안되고, 백엔드를 통해서 기능을 사용하도록 해야 한다.
- 서버를 장악하지 않는 이상 백엔드 프로덕트를 뜯어볼 수 없으며, 키 값 자체로는 여러 권한을 가지더라도 외부에 공개되는 api 로직은 한정적인 기능만 수행하므로 가장 안전한 방식이라고 할 수 있다.