proxy 구성해서 DELETE 요청 막기

jinwook han·2023년 9월 21일
0

사용했던 기술: elasticsearch, haproxy

(자세한 기술적인 글은 아니고, 간략한 과정을 기록했습니다)
proxy를 구성해서 DELETE 요청을 막았다.

문제

방화벽 권한을 가진 누구나 DELETE 요청을 할 수 있었다. 팀원 누구나 DELETE 요청을 할 수 있어 위험했다.

첫 시도

aws access policy를 사용해서 제어하려고 했다. ec2 role에서 온 요청이면 DELETE를 허용하고, 그 외의 요청은 모두 막고자 했다.
그렇게 되면 ec2에서 돌아가는 배치는 DELETE 요청을 할 수 있고, 팀원들이 보내는 curl 요청은 막을 수 있다.
하지만 위 방안으로 했을 때, 기존 트래픽에도 영향을 주므로 성능 테스트가 필요했다. access policy를 적용했을 때 latency 지연이 없는지 확인해야 했다.
게다가 local test에서는 access policy를 모킹할 수 있을지에 대한 방안도 필요했다.
성능 테스트에 대한 시간은 확보하지 못하고, access policy 모킹 문제도 해결하지 못한 채 문제를 방치했다.

장애

PUT 요청을 실수로 날려 장애가 일어났다.
장애가 일어난 이후 우리는 2주 안으로 포카요케를 통해 장애를 방지하기로 했다.

새로운 아이디어

팀원 중 한 분이 proxy를 구성하자고 아이디어를 냈다. 팀원이 직접 접근했던 기존 방화벽 정책은 폐기한다.
proxy에는 팀원 누구나 접근할 수 있다. 하지만 proxy에서 GET 요청 이외의 요청은 모두 막는다.
이 아이디어의 장점은 앞서 얘기한 access policy 방법과 비교하여 두 가지 장점이 있다.
1. 기존 트래픽에 영향을 주지 않는다. 성능 테스트에 대한 부담이 없어진다.
2. 모킹에 대한 고민을 할 필요가 없다. 코드에 영향을 주지 않는 인프라를 이용한 해결 방법이기 때문이다.

적용

장애가 일어난지 2주 안에 우리는 다음과 같은 작업을 하여 proxy를 적용했다.

  • proxy 구성 (GET 요청만 가능하도록 설정)
  • proxy에 팀원들이 접근할 수 있도록 권한 신청
  • 기존 방화벽 정책 폐기
    이제 DELETE, PUT 요청이 동작한다는 두려움 없이 로컬에서 마음껏 운영에 GET 요청을 할 수 있다.

배운 점

  • 기존 트래픽에 영향을 주지 않는 해결책은 분명한 장점이 있다. 물론 모든 경우에 이런 해결 방법을 쓸 수는 없을 것이다.
  • 인프라를 통해 문제를 해결하면, 로컬 모킹에 대한 고민을 하지 않아도 된다는 장점이 있다. 물론 관리 대상이 많아진다는 단점도 있다.

0개의 댓글

관련 채용 정보