정적 웹 사이트는 이미 렌더링된 콘텐츠를 저장하므로 데이터베이스에 액세스하거나 복잡한 스크립트를 실행하거나 사용자가 페이지를 요청할 때마다 런타임 엔진에 의존할 필요가 없습니다.
이는 로드 시간과 보안 면에서 분명한 이점으로 해석됩니다. 정적 페이지는 서버 시간을 많이 절약하고 취약성이 적습니다. 이는 차례로 검색 엔진이 동적 페이지보다 정적 페이지의 순위를 더 높게 지정한다는 것을 의미합니다.
SEO 전문가들은 찰나의 순간이 완전한 성공과 완전한 실패를 가르는 세상에서 더 나은 경쟁을 위해 가능한 한 정적 콘텐츠로 눈을 돌리고 있습니다. 정적 콘텐츠 배포는 마케팅 전략가 사이에서 유행어가 되었으며 IT 직원은 눈에 덜 취약한 지점이 있다는 사실을 좋아합니다.
그러나 주의하십시오. 100% 해킹 방지가 되지 않으므로 웹 사이트에 정적 콘텐츠를 배포할 계획이라면 보안을 유지하기 위해 따라야 하는 몇 가지 모범 사례가 있습니다.
보안 헤더는 웹 서버가 제공하는 콘텐츠에 추가하는 메타데이터, 오류 코드, 캐시 규칙 등의 팩인 HTTP 응답 헤더의 하위 집합으로, 브라우저에 수행할 작업과 수신 콘텐츠를 처리하는 방법을 알려주도록 설계되었습니다. 모든 브라우저가 모든 보안 헤더를 지원하는 것은 아니지만 해커가 취약점을 악용하지 못하도록 막는 기본적인 보안 조치를 제공하는 아주 일반적인 작은 집합이 있습니다.
X-Frame-옵션: SAMEORIGIN
X-Frame-Options 헤더는 사이트에서 iframe에 의해 부과되는 위험을 비활성화하거나 완화하기 위한 것입니다. Iframe은 해커가 합법적인 클릭을 포착하고 방문자를 원하는 URL로 안내하는 데 사용할 수 있습니다. iframe의 오용을 방지하는 다양한 방법이 있습니다.
OWASP(Open Web Application Security Project)에서 권장하는 모범 사례는 동일한 출처에 있는 누군가만 iframe을 사용할 수 있도록 하는 SAMEORIGIN 매개변수와 함께 이 헤더를 사용할 것을 제안합니다. 다른 옵션은 iframe을 완전히 비활성화하는 DENY와 iframe에 페이지를 넣을 수 있는 특정 URL만 허용하는 ALLOW-FROM입니다.
Apache 및 Nginx에 대한 구현 가이드를 확인하세요.
X-XSS-보호: 1; 모드=차단
X-XSS-Protection 헤더는 사이트 간 스크립팅으로부터 웹사이트를 보호하도록 설계되었습니다. 이 헤더 기능은 두 가지 방법으로 구현할 수 있습니다.
- X-XSS-보호: 1
- X-XSS-보호: 1; 모드=차단
첫 번째는 요청에서 웹 서버로의 스크립트를 필터링하지만 어쨌든 페이지를 렌더링하는 더 관대합니다. 두 번째 방법은 요청에서 X-XSS 스크립트가 감지되면 전체 페이지를 차단하므로 더 안전합니다. 이 두 번째 옵션은 OWASP 권장 모범 사례입니다.
X-Content-Type-Options: nosniff
이 헤더는 브라우저가 콘텐츠를 스캔하고 헤더가 지시하는 것과 다르게 응답할 수 있도록 하는 기능인 MIME “스니핑”의 사용을 방지합니다. 이 헤더가 있는 경우 브라우저는 콘텐츠 유형을 미리 “스니핑”하여 유추하는 대신 지침에 따라 콘텐츠 유형을 설정해야 합니다.
이 헤더를 적용하는 경우 콘텐츠 유형이 정적 웹사이트의 각 페이지에 올바르게 적용되었는지 다시 확인해야 합니다.
콘텐츠 유형: 텍스트/html; 문자 집합=utf-8
이 행은 HTTP 프로토콜 버전 1.0부터 HTML 페이지에 대한 요청 및 응답 헤더에 추가됩니다. 모든 태그가 브라우저에서 렌더링되고 웹 페이지에 결과가 표시되도록 설정합니다.
TLS 인증서 사용
SSL/TLS 인증서는 웹 서버가 보안 HTTPS 프로토콜을 통해 웹 브라우저에 보내는 데이터를 암호화할 수 있도록 하기 때문에 모든 웹 사이트에 필수입니다. 그렇게 하면 여행 중에 데이터가 가로채어 읽을 수 없게 되며 이는 사용자 개인 정보를 보호하고 웹 사이트를 보호하는 데 필수적입니다. 정적 웹사이트는 방문자의 개인 정보를 저장하지 않지만 방문자가 요청한 정보는 원치 않는 감시자가 볼 수 없도록 하는 것이 중요합니다.
웹 사이트에서 암호화를 사용하는 것은 대부분의 웹 브라우저에서 안전한 사이트로 표시하는 데 필요하며 EU의 GDPR(일반 데이터 보호 규정)을 준수하려는 웹 사이트의 경우 필수입니다. 법에는 SSL 인증서를 사용해야 한다고 구체적으로 명시되어 있지는 않지만 규정의 개인 정보 보호 요구 사항을 충족하는 가장 간단한 방법입니다.
보안 측면에서 SSL 인증서를 사용하면 기관에서 웹사이트의 소유권을 확인하고 해커가 웹사이트의 가짜 버전을 만드는 것을 방지할 수 있습니다. SSL 인증서를 사용하면 웹사이트 방문자가 게시자의 진위를 확인할 수 있으며 아무도 웹사이트에서 자신의 활동을 염탐할 수 없다는 확신을 가질 수 있습니다.
좋은 소식은 인증서 비용이 많이 들지 않는다는 것입니다. 사실, 당신은에서 무료로 얻을 수 있습니다 ZeroSSL 또는 프리미엄 제품을 구입하십시오. SSL 스토어.
DDoS 보호 배포
DDoS(분산 서비스 거부) 공격이 최근 보편화되고 있습니다. 이러한 유형의 공격에서는 서버가 포화 상태가 되어 단순히 작동을 거부할 때까지 수많은 요청으로 서버를 압도하는 데 분산 장치 세트가 사용됩니다. 웹 사이트에 정적 콘텐츠가 있는지 여부는 중요하지 않습니다. 필요한 조치를 취하지 않으면 웹 서버가 DDoS 공격의 희생자가 될 수 있습니다.
웹 사이트에서 DDoS 보호를 구현하는 가장 쉬운 방법은 보안 서비스 공급자가 모든 사이버 위협을 처리하도록 하는 것입니다. 이 서비스는 침입 탐지, 바이러스 백신 서비스, 취약점 검색 등을 제공하므로 실제로 위협에 대해 걱정할 필요가 없습니다.
이러한 포괄적인 솔루션은 비용이 많이 들 수 있지만 DPaaS(DDoS Protection as a Service)와 같이 보다 저렴한 비용으로 보다 집중적인 솔루션도 있습니다. 그러한 서비스를 제공하는지 호스팅 제공업체에 문의해야 합니다.
보다 저렴한 솔루션은 Akamai에서 제공하는 것과 같은 클라우드 기반 DDoS 보호 서비스입니다. 수쿠리, 또는 Cloudflare. 이러한 서비스는 DDoS 공격을 조기에 탐지 및 분석하고 이러한 공격을 필터링 및 우회합니다. 즉, 악성 트래픽을 사이트에서 다른 곳으로 다시 라우팅합니다.
안티 DDoS 솔루션을 고려할 때 네트워크 용량에 주의해야 합니다. 이 매개변수는 보호 기능이 견딜 수 있는 공격 강도를 나타냅니다.
취약한 JavaScript 라이브러리 피하기
웹 사이트에 정적 콘텐츠가 있더라도 보안 위험을 부과하는 JavaScript 라이브러리를 사용할 수 있습니다. 일반적으로 이러한 라이브러리의 20%가 웹사이트를 더 취약하게 만드는 것으로 간주됩니다. 다행히도 에서 제공하는 서비스를 사용할 수 있습니다. 취약점 DB 특정 라이브러리가 안전한지 확인하기 위해. 데이터베이스에서 알려진 많은 취약점에 대한 자세한 정보와 지침을 찾을 수 있습니다.
특정 라이브러리에 취약점이 있는지 확인하는 것 외에도 잠재적인 위험에 대한 수정을 제공하는 JavaScript 라이브러리에 대한 다음 모범 사례 목록을 따를 수 있습니다.
- 외부 라이브러리 서버를 사용하지 마십시오. 대신 웹 사이트를 호스팅하는 동일한 서버에 라이브러리를 저장하십시오. 외부 라이브러리를 사용해야 하는 경우 블랙리스트 서버의 라이브러리 사용을 피하고 외부 서버의 보안을 주기적으로 확인하십시오.
- JavaScript 라이브러리에 대한 버전 관리를 사용하고 각 라이브러리의 최신 버전을 사용하는지 확인하십시오. 버전 관리가 옵션이 아닌 경우 적어도 알려진 취약점이 없는 버전을 사용해야 합니다. 당신이 사용할 수있는 은퇴.js 취약한 버전의 사용을 감지합니다.
- 귀하의 웹사이트가 귀하가 모르는 외부 라이브러리를 사용하고 있는지 정기적으로 확인하십시오. 이렇게 하면 해커가 원치 않는 라이브러리 제공자에 대한 링크를 삽입했는지 알 수 있습니다. 인젝션 공격은 정적 웹사이트에서 일어날 가능성이 거의 없지만 가끔 이 검사를 수행하는 것은 해가 되지 않습니다.
백업 전략 구현
정적 웹사이트는 변경될 때마다 콘텐츠를 항상 안전하게 백업해야 합니다. 백업 사본은 안전하게 저장되어야 하며 충돌이 발생한 경우 웹사이트를 복원해야 하는 경우에 쉽게 액세스할 수 있어야 합니다. 정적 웹 사이트를 백업하는 방법은 여러 가지가 있지만 일반적으로 수동 및 자동으로 분류할 수 있습니다.
웹 사이트 콘텐츠가 자주 변경되지 않는 경우 수동 백업 전략이 적절할 수 있습니다. 콘텐츠를 변경할 때마다 새 백업을 만드는 것을 기억하면 됩니다. 호스팅 계정을 관리할 제어판이 있는 경우 해당 제어판에서 백업 옵션을 찾을 가능성이 매우 높습니다. 그렇지 않은 경우 항상 FTP 클라이언트를 사용하여 모든 웹 사이트 콘텐츠를 로컬 장치에 다운로드하여 안전하게 보관하고 필요한 경우 복원할 수 있습니다.
물론 웹 사이트 관리 작업을 최소한으로 유지하려면 자동 백업 옵션을 사용하는 것이 좋습니다. 그러나 자동 백업은 일반적으로 호스팅 제공업체에서 프리미엄 기능으로 제공하므로 웹사이트를 안전하게 유지하는 데 드는 총 비용이 추가됩니다.
백업을 위해 클라우드 개체 스토리지 사용을 고려할 수 있습니다.
신뢰할 수 있는 호스팅 제공업체 사용
웹사이트가 원활하고 신속하게 작동함과 동시에 해킹을 당하지 않기 위해서는 안정적인 웹 호스팅 서비스가 필요합니다. 대부분의 웹 호스팅 리뷰는 속도, 가동 시간 및 고객 지원에 대한 수치와 비교를 보여주지만 웹사이트 보안을 고려할 때 주의 깊게 관찰해야 하는 몇 가지 측면이 있으며 서비스를 고용하기 전에 공급자에게 문의해야 합니다.
- 소프트웨어 보안: 소프트웨어 업데이트가 어떻게 처리되는지 알아야 합니다. 예를 들어 모든 소프트웨어가 자동으로 업데이트되거나 각 업데이트가 배포되기 전에 테스트 프로세스를 거친 경우입니다.
- DDoS 보호: 이러한 종류의 보호가 호스팅 서비스에 포함된 경우 구현 방법에 대한 세부 정보를 요청하여 웹 사이트 요구 사항을 충족하는지 확인하십시오.
- SSL 가용성 및 지원: 대부분의 경우 인증서는 호스팅 제공업체에서 관리하므로 제공하는 인증서의 종류와 인증서 갱신 정책을 확인해야 합니다.
- 백업 및 복원: 많은 호스팅 제공업체는 자동화된 백업 서비스를 제공합니다. 이는 백업 작성, 저장 및 업데이트 유지에 대해 실질적으로 잊어버릴 수 있기 때문에 좋은 일입니다. 그러나 그러한 서비스의 비용을 고려하고 콘텐츠를 스스로 백업하는 데 드는 노력과 비교해 보십시오.
- 맬웨어 보호: 신뢰할 수 있는 호스팅 제공업체는 정기적인 맬웨어 검사를 수행하고 파일 무결성을 모니터링하여 맬웨어로부터 서버를 보호해야 합니다. 공유 호스팅의 경우 호스팅 제공자는 계정 격리를 사용하여 인접 웹 사이트 간에 악성 코드 감염이 전파되는 것을 방지하는 것이 바람직합니다.
- 방화벽 보호: 호스팅 제공업체는 적대적인 트래픽을 차단하는 방화벽을 배포하여 호스팅하는 웹사이트의 보안 수준을 높일 수 있습니다.
안정적인 정적 사이트 호스팅 플랫폼을 확인하십시오.
강력한 암호 정책 시행
정적 사이트에는 데이터베이스나 관리되는 콘텐츠 시스템이 없기 때문에 관리할 사용자 이름과 암호가 더 적습니다. 그러나 정적 콘텐츠를 업데이트하는 데 사용할 호스팅 또는 FTP 계정에 대한 암호 정책을 적용해야 합니다.
비밀번호에 대한 모범 사례는 다음과 같습니다.
- 주기적으로 변경
- 최소 암호 길이를 설정합니다.
- 특수문자 및 숫자와 함께 대문자/소문자 조합 사용
- 이메일이나 문자 메시지로 의사 소통하지 마십시오.
또한 관리 계정의 기본 암호는 처음부터 변경해야 합니다. 이는 해커가 쉽게 악용할 수 있는 일반적인 오류입니다. 비밀번호 분실을 두려워하지 마십시오. 암호 관리자를 사용하여 안전하게 관리하십시오.
정체하자
몇 년 전만 해도 동적 콘텐츠가 대세였습니다. 모든 것이 쉽게 변경되고 업데이트되어 몇 초 안에 전체 웹사이트를 재설계할 수 있었습니다. 그런데 속도가 최우선이 되었고, 정적인 콘텐츠가 갑자기 다시 멋있어졌습니다.
그런 의미에서 모든 웹사이트 보안 관행을 재평가해야 합니다. 고려해야 할 측면이 더 적지만 이에 대해 긴장을 늦추어서는 안 됩니다. 이 모범 사례 목록은 정적 웹 사이트를 안전하고 건전하게 유지하기 위한 자체 체크리스트를 만드는 데 확실히 도움이 될 것입니다.