Defaults.Exposed › 수정 › HSTS (Strict-Transport-Security)

HSTS (Strict-Transport-Security) 수정 방법

HSTS는 웹사이트가 모든 방문자의 브라우저에 주는 한 줄의 지시입니다: '항상 보안 암호화 연결로 돌아오세요 — 비보안 연결은 절대 안 됩니다.' 이 설정이 없으면 공유 Wi-Fi에서 자물쇠가 조용히 제거될 수 있고, 사이트에 대한 첫 방문이 노출됩니다.

비즈니스에 미치는 핵심 영향: HTTPS(자물쇠)를 갖추는 것과 이를 강제하는 것은 다릅니다. HSTS가 없으면 같은 Wi-Fi의 공격자가 고객의 연결을 일반 암호화되지 않은 HTTP로 조용히 다운그레이드하여 로그인 정보, 카드 정보, 양식 데이터를 캡처할 수 있습니다. 비용을 지불하고 있을 수도 있는 SSL 인증서가 우회됩니다. 수정은 무료이며 사이트를 담당하는 사람에게 약 15분이면 됩니다.

발생 가능한 비용

• 카페, 호텔, 공항, 컨퍼런스 Wi-Fi에 있는 고객은 화면에 아무런 경고 없이 귀사 사이트 연결이 조용히 다운그레이드되어 데이터를 읽힐 수 있습니다.
• HTTPS가 있고 자물쇠도 있지만 HSTS 없이는 공격자가 단순히 우회할 수 있습니다. 인증서가 거짓된 안전감을 줍니다.
• 사이트에 대한 첫 방문(HTTPS로 리디렉션되기 전)이 공격자가 노리는 취약점입니다 — HSTS가 모든 재방문에 대해 이를 닫는 것입니다.
• 보안 설문지, 사이버 보험 양식, 또는 기업 구매자 체크리스트가 'HSTS 없음'을 표시하고 수정될 때까지 거래를 보류합니다.
• 값을 잘못 설정하면(너무 짧게) 최악의 상황이 됩니다: 설정된 것처럼 보이지만 실질적인 보호가 거의 없습니다.

중요한 이유. HTTPS는 연결이 암호화된 후 이를 보호합니다 — 하지만 브라우저가 사용하도록 강제하지 않습니다. 공격자는 'SSL 스트리핑'으로 이 격차를 악용합니다: 공유 네트워크에서 방문자를 비보안 HTTP에 조용히 유지하고 모든 것을 읽습니다. HSTS는 브라우저에게 귀사 도메인에 대해 일반 HTTP를 거부하고, 오랫동안 거부하도록 지시하여 첫 방문 이후 격차가 닫힙니다.

쉬운 설명

귀사는 거의 확실히 HTTPS — 브라우저 표시줄의 작은 자물쇠 — 를 가지고 있습니다. 좋습니다. 하지만 거의 아무도 알려주지 않는 부분이 있습니다: HTTPS를 갖추는 것과 이를 강제하는 것은 다릅니다.

HTTPS는 브라우저가 사용하기로 결정한 후 연결을 암호화합니다. HSTS — HTTP Strict Transport Security 약자 — 는 브라우저가 항상 사용하도록 만드는 지시입니다. 웹사이트가 모든 방문자에게 보내는 단일 보이지 않는 줄로, 사실상 이렇게 말합니다:

“지금부터 내 도메인에서는 보안 연결로만 통신하세요. 비보안 연결은 절대 안 됩니다. 시도조차 하지 마세요.”

브라우저는 이를 기억하고 귀하가 지정한 기간 동안 — 일반적으로 1년 — 이를 따릅니다. 방문자의 첫 번째 보안 방문 이후 브라우저는 무언가가 강제하더라도 귀사 사이트를 일반 암호화되지 않은 HTTP로 로드하는 것을 단순히 거부합니다.

HSTS 없이는 그 “항상 보안 버전 사용” 규칙이 존재하지 않으며 공격자는 정확히 이 격차를 악용하는 방법을 알고 있습니다.

비즈니스 피해 사례

1. 카페 결제. 고객이 카페 Wi-Fi에서 상점을 열고 결제하려 합니다. 같은 네트워크의 공격자가 고객을 HTTPS 대신 일반 HTTP에 유지하는 무료로 공개된 도구를 실행합니다. 고객은 정상적인 귀사 사이트처럼 보이는 것을 봅니다 — 경고도, 깨진 자물쇠도 없습니다 — 그리고 카드 정보를 입력합니다. 공격자가 모든 키 입력을 읽습니다.

2. 출장 중 직원. 직원이 호텔이나 공항에서 관리자 패널이나 웹메일에 로그인합니다. 같은 다운그레이드 트릭이 사용자 이름과 비밀번호를 캡처합니다.

3. 지연된 거래. 더 큰 고객사가 서명 전 표준 보안 설문지를 보냅니다. 한 줄에서 웹사이트가 HSTS를 통해 HTTPS를 시행하는지 묻습니다. IT 담당자가 “아니오”라고 답해야 하고 조달 과정이 중단됩니다.

4. 사이버 보험 또는 규정 준수 검사. 보험사의 스캔 또는 데이터 보호 입장을 검토하는 감사자가 없는 헤더를 표시합니다.

5. 거짓된 안전감. SSL 비용을 지불하고, 자물쇠가 표시되며, 모든 사람이 사이트가 안전하다고 가정합니다. 고객이 공유 네트워크에 있을 때 — 가장 취약하고 이상한 점을 발견할 가능성이 가장 낮을 때 — 실제로 위험합니다.

실제 작동 방식

웹사이트가 페이지를 보낼 때 보이지 않는 “헤더” — 브라우저가 읽지만 방문자에게 표시되지 않는 추가 지시 — 도 함께 보냅니다. HSTS는 그 헤더 중 하나입니다:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

세 부분이 중요합니다:

• max-age — 브라우저가 HTTPS를 강제해야 하는 기간(초 단위). 31536000은 1년. 너무 짧으면 거의 도움이 되지 않습니다.
• includeSubDomains — 규칙을 모든 하위 도메인(shop., app., mail. 등)으로 확장.
• preload — 브라우저에 내장된 마스터 목록에 도메인을 포함시켜 첫 요청에서도 보호.

점수 체계

수정 방법 (무료, 약 15분)

사이트를 담당하는 사람에게 이 섹션을 전달하세요 — 수정은 무료입니다.

중요한 순서 규칙: HSTS는 고정적입니다. 활성화 후 브라우저는 전체 max-age 동안 귀사 도메인에 대해 일반 HTTP를 거부합니다. 메인 사이트와 모든 하위 도메인에서 HTTPS가 올바르게 작동하는지 확인한 후 광범위하게 켜세요. 안전한 경로: 짧은 값으로 테스트 → 이상 없음 확인 → 1년으로 높이기.

1단계 — HTTPS가 이미 모든 곳에서 작동하는지 확인

사이트와 주요 하위 도메인을 https://로 방문하여 유효한 인증서로 깔끔하게 로드되는지 확인합니다.

2단계 — 헤더 추가(플랫폼 선택)

Cloudflare: **SSL/TLS → 엣지 인증서 → HTTP Strict Transport Security(HSTS)**에서 활성화.

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Microsoft IIS:

<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />

3단계 — 소규모로 테스트한 후 확정

max-age=300(5분)으로 시작합니다. 사이트가 모든 곳에서 여전히 완벽하게 로드되는지 확인합니다. 그런 다음 max-age=31536000(1년)으로 높이세요.

4단계(선택 사항, 골드 스탠다드) — preload

includeSubDomains가 있는 1년 헤더를 잠시 실행한 후 hstspreload.org에서 도메인을 제출하여 브라우저에 내장시킬 수 있습니다.

흔한 실수

• max-age를 너무 짧게 설정. 몇 분이나 몇 시간의 값은 설정된 것처럼 보이지만 거의 보호가 없습니다.
• 하위 도메인이 HTTPS 준비되기 전에 includeSubDomains 활성화. 하위 도메인이 HTTPS에 없다면 고정 규칙이 방문자에게 도달할 수 없게 만들 수 있습니다.
• HSTS를 추가했지만 HTTP에서 HTTPS로의 리디렉션이 없음. HSTS는 방문자가 보안 버전에 도달한다고 가정합니다.
• “철저하게” 하려고 preload로 바로 건너뜀. Preload는 취소하기 어렵습니다. 안정적인 1년 헤더 이후에 점진적으로 진행하세요.
• 자물쇠가 이미 커버한다고 가정. 자물쇠와 HSTS는 다른 것입니다.

FAQ