홈페이지 보안은 이렇게 합니다 — 중소기업 기본

작은 회사 사이트인데, 정말 노려질까요?

저희가 운영·QA를 맡으며 가장 자주 듣는 말이 "우리는 털릴 게 없는데요"입니다. 그런데 실제 공격의 대부분은 누군가 우리 회사를 콕 집어 노린 게 아닙니다. 자동화된 봇이 인터넷 전체를 훑으며 오래된 플러그인, 약한 비밀번호, 노출된 관리자 페이지를 기계적으로 찾아냅니다. 회사 규모는 보지 않습니다. 봇에게 가치 있는 건 '훔칠 데이터'가 아니라 '뚫려서 마음대로 쓸 수 있는 서버 한 대'입니다.

뚫린 사이트는 스팸 메일 발송지가 되거나, 방문자에게 악성코드를 퍼뜨리거나, 문의 폼에 쌓인 고객 정보가 빠져나가는 통로가 됩니다. 그래서 저희는 보안을 '대기업만의 일'로 두지 않고, 모든 사이트의 기본 공정에 넣습니다. 제작과 운영을 한 흐름으로 보는 이유는 운영 파트가 일하는 방식에서 자세히 다룹니다.

그래서 가장 먼저 무엇을 하나요? — HTTPS

모든 사이트는 HTTPS로 시작합니다. HTTPS는 방문자의 브라우저와 우리 서버 사이에 오가는 정보를 암호화해, 같은 와이파이를 쓰는 누군가가 문의 내용이나 로그인 정보를 중간에서 엿보지 못하게 합니다. 요즘 브라우저는 HTTPS가 아닌 사이트에 '안전하지 않음' 경고를 띄우기 때문에, 보안만이 아니라 신뢰와 검색 노출 측면에서도 기본 중의 기본입니다.

다만 분명히 해두면, HTTPS는 출발선이지 결승선이 아닙니다. 통신은 암호화하지만, 사이트 안에서 일어나는 폼 스팸이나 약한 비밀번호, 오래된 플러그인 취약점은 HTTPS로 막히지 않습니다. "자물쇠 아이콘이 떴으니 안전하다"는 흔한 오해를, 저희는 인수인계 단계에서 꼭 바로잡습니다.

보안 헤더는 왜 챙기나요?

보안 헤더는 서버가 브라우저에게 "이 사이트에서는 이런 동작만 허용해 줘"라고 알려주는 작은 규칙들입니다. 눈에 보이지 않지만 효과가 큽니다. 저희가 기본으로 적용하는 항목은 이렇습니다.

• CSP(콘텐츠 보안 정책) — 우리가 지정한 출처의 스크립트·이미지만 실행·로드하게 막아, 외부에서 끼워 넣은 악성 스크립트가 돌아가지 못하게 합니다.
• X-Frame-Options — 우리 페이지가 다른 사이트의 보이지 않는 틀 안에 끼워져 클릭을 가로채이는 공격(클릭재킹)을 막습니다.
• X-Content-Type-Options · Referrer-Policy — 파일 형식을 멋대로 해석하거나, 방문 경로 정보가 불필요하게 새는 것을 줄입니다.

이 글 페이지의 소스에도 CSP 한 줄이 들어가 있습니다. 거창한 장비가 아니라, 설정 몇 줄로 공격 표면을 눈에 띄게 줄이는 작업입니다.

문의 폼에 스팸과 봇이 쏟아지는데요?

문의 폼은 외부에서 우리 서버로 데이터를 보낼 수 있는 입구라, 봇이 가장 먼저 두드리는 곳입니다. 저희는 사람을 괴롭히는 자물쇠형 캡차에 의존하기 전에 서버에서 먼저 거릅니다. 화면에 보이지 않는 함정 필드(허니팟)를 두어 봇만 채우게 하고, 같은 곳에서 짧은 시간에 반복 제출하면 속도 제한을 걸고, 들어온 값은 서버에서 한 번 더 검증합니다.

이 조합으로 자동 스팸 대부분을 걸러내면서도, 진짜 고객이 보낸 문의는 막힘없이 들어옵니다. 보안을 이유로 고객을 불편하게 만들면 문의 자체가 줄기 때문에, 저희는 '사람은 편하게, 봇은 어렵게'를 기준으로 잡습니다.

고객 개인정보는 어떻게 다루나요?

가장 안전하게 지키는 정보는 애초에 받지 않은 정보입니다. 그래서 저희는 세 가지 원칙으로 폼과 데이터 흐름을 설계합니다. 첫째, 수집 최소화 — 연락에 꼭 필요한 항목만 받고, "있으면 좋은" 항목은 과감히 뺍니다. 둘째, 고지와 동의 — 무엇을, 왜 받는지 알리고 동의를 받습니다. 셋째, 파기 — 목적을 다한 정보는 정해진 시점에 지웁니다.

실무에서 가장 흔한 허점은 의외로 단순합니다. 문의 내용이 담당자 메일함에 무기한 쌓이는 경우입니다. 그 메일함 비밀번호 하나가 뚫리면 그동안 받은 모든 고객 정보가 새어 나갑니다. 받는 항목을 줄이고 보관 기간을 정하는 것만으로도 위험은 크게 줄어듭니다. 운영 단계의 점검 항목은 유지·운영 안내에 정리해 두었습니다.

관리자·호스팅 접근은 어떻게 보호하나요?

사이트가 뚫리는 가장 흔한 통로는 정교한 해킹이 아니라 약한 비밀번호와 방치된 계정입니다. 저희는 관리자 페이지와 호스팅 계정에 대해 추측하기 어려운 비밀번호와 2단계 인증을 기본으로 권하고, 관리자 주소를 짐작하기 쉬운 기본 경로에 두지 않습니다. 또 작업이 끝난 외주·협력자 계정은 그때그때 회수해, 쓰지 않는 문을 열어두지 않습니다.

호스팅 콘솔, 도메인 관리, 결제 정보처럼 한 번 뚫리면 피해가 큰 접점일수록 접근 권한을 가진 사람을 적게 유지하는 것이 원칙입니다. 권한은 '많을수록 편한 것'이 아니라 '적을수록 안전한 것'으로 다룹니다.

백업과 업데이트는 왜 운영 내내 하나요?

아무리 잘 막아도 사고는 날 수 있습니다. 그래서 저희는 보안을 '뚫지 못하게 하는 일'과 '뚫려도 빨리 되돌리는 일' 두 축으로 봅니다. 후자의 핵심이 백업입니다. 사이트와 데이터를 주기적으로 백업하고, 실제로 복구가 되는지 확인합니다. 한 번도 복구를 시험해 보지 않은 백업은 백업이 아니기 때문입니다.

또 하나는 의존성 최신화입니다. 사이트가 쓰는 플러그인·라이브러리·서버 구성요소에는 시간이 지나며 알려진 취약점이 쌓입니다. 봇은 바로 그 '이미 알려진 구멍'을 노립니다. 그래서 사용하는 구성요소를 최소한으로 줄이고, 보안 업데이트가 나오면 호환성을 확인해 반영합니다. 발행 직전에 이 기본들을 함께 점검하는 항목은 오픈 전 점검 체크리스트에 담았고, 보안은 한 번 끝내는 공사가 아니라 운영하는 내내 점검하는 일하는 방식의 일부입니다.

한 줄로 정리하면?

중소기업 홈페이지 보안은 비싼 솔루션을 더 사는 일이 아니라, 위의 기본 일곱 가지를 빠짐없이 지키고 운영 중에도 손에서 놓지 않는 일입니다. 그리고 솔직히 말씀드리면, 그렇게 해도 100% 안전은 없습니다. 저희가 약속하는 건 완벽한 안전이 아니라, 뚫릴 확률을 크게 낮추고 사고가 나도 빠르게 복구하는 운영입니다. 지금 사이트가 이 기본을 갖췄는지 궁금하시면 무료 진단으로 점검해 드립니다.

제가 운영·QA에서 헤더를 점검할 때는 "이 헤더가 무엇을 막는가"를 한 줄로 설명하지 못하면 적용하지 않습니다. 그래서 저희가 실제로 거는 헤더와 그 역할을 이렇게 정리해 둡니다.

헤더만큼 자주 빠뜨리는 게 운영 중 점검이라, 저는 배포 직후 아래 항목을 매번 손으로 확인합니다.

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self'; style-src 'self' 'unsafe-inline'