아직 리버스 프록시 뒤에 있는 상태인데, 공식 설치 방법을 그대로 사용하면서 디스코스를 처리하는 템플릿과 몇 가지 다른 방식을 찾았어요.
곧 가이드를 작성할게요. 혹시 다른 분들도 사용하시거나 제가 다시 필요하게 될 때를 대비해서요 ㅋㅋ
다만 제 설치 환경은 Let’s Encrypt SSL을 사용하지 않아서 작은 문제가 하나 있어요. 발송된 이메일 활성화 링크에 https 대신 http가 들어가 있거든요. 모든 http 요청을 https로 리다이렉트하는 설정은 되어 있지만, 백엔드에서 https를 강제해서 모든 링크가 http가 아닌 https로 표시되도록 하고 싶어요.
수정: 찾아냈네요
DISCOURSE_FORCE_HTTPS: true
음… 리버스 프록시를 사용 중이니까 백엔드에 https를 보낼 이유가 있나요?
force https를 설정하면 Discourse가 자신의 모든 참조를 https로 사용하도록 합니다.
네, 하지만 왜 그런지에 대한 질문에는 답이 되지 않아요.
연결을 암호화하기 위해서입니다.
WAN → 리버스 프록시 = HTTPS
리버스 프록시 → 백엔드 = HTTPS
이렇게 하면 어떤 이유로든 제 서버실에 접근 권한이 있는 사람이 이더넷 케이블을 꽂아 트래픽을 명확하게 볼 수 없도록 합니다. 연결은 여전히 HTTPS를 유지하며, 침입자의 작업을 조금 더 어렵게 만듭니다. 저는 HTTPS 체인이 완전히 유지되기를 원합니다. WAN HTTPS → 리버스 프록시 HTTP → 백엔드 같은 방식은 원하지 않습니다.
그렇지 않으면 그것은 단순히 껍질 보안에 불과할 것입니다.
제로 트러스트, 제가 그 사람을 10년 이상 알고 있든与否입니다.
공감합니다. 만약 그 지점에서 신뢰가 전혀 없거나, 리버스 프록시를 게이트キー퍼로 유지하면서 보안 네트워크를 구축할 수 없는 상황이라면요.
모든 것이 가능한 가장 안전한 수준으로 보호되어 있습니다.
대부분의 보안 유출이 내부에서 발생한다는 사실을 알아차리지 못했나요? 이 방식을 통해 제 서버 보안이 완벽하게 차단되어 있음을 알 수 있으며, 유일한 취약점은 인간뿐입니다. 그리고 제 직원들은 이를 100% 이해하고 있습니다.
저는 몇몇 유명 클라우드 사용자를 보유하고 있으며, 만약 어떤 기적 같은 이유로 그들의 데이터가 유출된다 해도 제 서버 보안이 완벽하다는 것을 알기 때문에 카메라를 확인하여 데이터 유출의 원인이 누군지 정확히 파악할 수 있습니다.
제가 본 바로는 AWS도 비슷한 방식으로 운영하는 것 같습니다. 서버가 아무리 안전해도 인간이라는 취약점은 항상 우선적으로 고려해야 합니다. USB 스틱 하나면 모든 것이 끝이니까요.
왜냐하면 그렇게 하지 않으면, 예를 들어 https가 아닌 http로 연결되는 이메일 링크를 보내거나, https가 아닌 http로 이미지에 연결하는 문제가 발생할 수 있습니다. Discourse가 https임을 알 수 있는 경우 기본적으로 활성화되어 있습니다. 현재 이것이 기본값이 아닌 이유는 정확히 모르겠지만, http 링크가 하나라도 있으면 Discourse가 거의 작동하지 않기 때문에 그렇습니다.
이것은 리버스 프록시와 Discourse 사이의 연결에 관한 것이 아니라, Discourse가 스스로 생성하는 링크에 관한 것입니다.