@Mia
캐시 설정 관리 기능, ERD의 만료기간 속성의 관리 구조를 검토하던 중 의문이 발생했다.
Main 측에서 각 Response에 대해 Cache-control:max-age를 설정해 보내주어서 캐시에서는 그 값을 보고 만료 기간을 파악하는 것이 일반적이다.
해당 기능은 ADMIN 권한을 필요로 하는 OPEN API를 통해 메인 서버가 캐쉬 접근한다는 것인데 이는 ADMIN 권한을 필요로 하는 OPEN API가 Cache에 존재한다는 것이기 때문에 보안 상의 취약점을 야기할 수 있다.
Main 측에서 ADMIN 영역의 API를 생성해서 AWS SSH 등을 통해서 접근하고 캐시는 Open된 Client 영역의 API만 Handling 하는 것이 보안 상 더 안전한 것 같다.
관련 이미지
문의가 필요
캐시 TTL 관리 기능에 대해 검토하다가 문의를 드립니다.해당 기능을 Cache Server에 둔다는 점은 ADMIN인 MAIN Server 영역에서 인증을 통한 API를 통해 캐시 데이터의 만료 기간을 다룬 다는 것으로 보입니다.기존 Main Server에서는 API에 대하여 Cache-control:max-age 등을 활용한 만료 값을 제공하지 않는 형태인가요?
모든 요청을 Cache Server를 통해서 Request Handling을 하기를 원하시던 것으로 요구사항으로 이해한 상태인데, 해당 기능을 캐시 서버에 둔다는 점은 아래 사진과 같은 형태로 ADMIN 영역의 API를 캐쉬 서버에 두고 Main이 JWT등을 활용한 인증을 통해 해당 영역에 접근한다는 것으로 보입니다.이는 ADMIN영역의 API가 Client에게 공개되는 Cache Server에 있다는 점에서 해당 토큰 값만 탈취할 수 있다면 보안상의 취약점이 발생할 수 있을 것으로 보입니다.
캐시 서버가 모든 Request에 대해서 Main전에 거치는 구조라면 ADMIN 영역에 해당하는 API를 Main에 구축하고 EC2 SSH 등을 활용해서 해당 영역에 접근하고 Cache Server는 Client 영역에 해당하는 부분만 Main Server와 링크 해준다면 보안상 더 우월성을 가져갈 수 있을 것 같습니다. 이에 대해서 의견을 듣고 싶습니다.
좋은 지적이시네요. 원래 말씀하신 방법이 가장 안전한 방법이긴 합니다. 하지만 서비스를 개발할 때 운영 상 이점도 생각하셔야 합니다. 저희 Admin 프로그램에서 많은 정보를 생성 / 수정 / 삭제를 하는데 그게 캐시 서버 때문에 바로 반영이 안되면 관리하는 입장에서는 상당히 불편합니다. 특히 Admin 프로그램은 개발을 모르는 사람이 해당 프로그램을 관리하고자 만든 것이라서 바로 데이터가 반영 안된다고 느껴지면 결국 개발자에게 요청할 수밖에 없고요. 그리고 그 기능은 수정, 삭제 등의 기능이 발생하면 캐싱 서버 자체적으로 해당 데이터와 연결되는 다양한 데이터를 업데이트 해주어야 정상적인 운영이 가능합니다. 즉 저희 Service Flow를 정확하게 알아야 하는데 그러면 규모가 더욱 커질 수 밖에 없습니다.