안녕하세요,
저는 Discourse 설치에 처음 입문한 사용자입니다. 최근 Digital Ocean Droplet에서 회사 포럼/커뮤니티 페이지로 사용하기 위해 설치를 완료했습니다.
설치 과정에서 SMTP 비밀번호 입력 항목이 보호되어 있지 않고, app.yml 파일에 평문으로 저장되어 있다는 점을 발견했습니다.
이는 잠재적인 보안 문제로 보입니다. 하지만 저는 네트워크/보안 전문가가 아니므로 여러 가지 이유로 이것이 정상적인 것일 수도 있습니다. 다만 IT 매니저를 안심시키기 위해서는 이렇게 처리되는 이유를 더 잘 이해하는 것이 도움이 될 것 같습니다.
Discourse는 많은 기업에서 널리 사용되고 있으므로, 이 주제는 이미 충분히 다루어졌을 것으로 추정합니다.
도움 주시면 감사하겠습니다.
감사합니다!
Jason
신뢰할 수 없는 사람이 당신의 app.yml 파일에 접근할 수 있다면, SMTP 비밀번호는 당신이 걱정해야 할 것 중 가장 사소한 문제에 불과합니다.
이를 보호하기 위해 어떤 방법을 제안하시겠습니까?
해시(Hash)는 단방향이며, 원래 데이터로 되돌릴 수 없습니다.
사용자 비밀번호가 해시되는 이유는 되돌릴 필요가 없기 때문입니다. 데이터베이스에 저장된 비밀번호 해시는 사용자가 로그인하려고 할 때만 참조됩니다. 사용자가 입력한 비밀번호의 해시를 해당 사용자 기록에 저장된 비밀번호 해시와 비교합니다.
SMTP 비밀번호나 API 키와 같은 항목이 평문(plain text)으로 저장되는 경우가 꽤 흔합니다. 이러한 항목은 원래 형태로 전송되어야 하므로, 해시 처리하면 사용할 수 없게 됩니다. 제3자가 비밀번호의 해시를 받아들이는 경우라면, 보호 수단으로서 해시를 사용하는 데 아무런 이점이 없습니다.
위에서 Jay가 말했듯이, 서버의 물리적 무결성이 손상되어 app.yml 파일에 접근할 수 있게 된다면, SMTP 비밀번호를 재설정해야 하는 것보다 훨씬 더 큰 문제에 직면하게 됩니다.
여기서 중요한 주의사항 하나를 말씀드리자면, SMTP 비밀번호를 다른 어디에도 사용해서는 안 됩니다. 이는 Discourse에만 국한된 이야기가 아니라, 모든 시스템과 모든 계정에 적용되는 좋은 보안 관행입니다.
제이가 말했듯이, 누군가가 당신의 app.yml 파일에 접근할 수 있다면 다른 문제가 있습니다. 이는 해당 사람이 당신의 프로덕션 데이터베이스를 포함한 서버에 전체 루트(root) 접근 권한을 가지고 있음을 의미합니다.
여기서 가장 좋은 방법은 서버가 안전하게 보호되고 있는지 확인하는 것입니다.
안녕하세요, 모두. 답변해 주셔서 감사합니다.
서버 보호가 1차 방어선이라는 점에는 동의합니다. 다만 이 경우 제 관리 범위를 벗어나는 문제입니다. 저는 Digital Ocean Droplet에 Discourse를 설치해 사용하고 있기 때문입니다.
@Stephen - SMTP 비밀번호에 대한 배경 정보를 알려 주셔서 감사합니다. 이러한 용도로는 평문으로 저장하는 것이 일반적이라는 점을 몰랐습니다. 말씀드린 것처럼 이 부분은 제 전문 분야가 아닙니다. 다만 눈에 띄어서 궁금해서 질문해 보았습니다.
감사합니다!
Jason
정확히 그렇지는 않아요 
SSH 키로만 로그인을 제한하고, 방화벽을 실행 상태로 유지하며, 보안 패치가 정기적으로 적용되도록 할 수 있습니다. 이는 Droplet의 보안을 강화하는 데 상당한 비중을 차지하는 부분입니다.
맞습니다. 그리고 파일 시스템을 암호화하지 않았다면(이는 구현이 어렵습니다) 그들에게도 신뢰를 두어야 합니다. 그들은 서버와 네트워크에 물리적 접근 권한을 가지고 있습니다.
설명했듯이, 비밀번호만 있으면 사용할 수 있습니다.