CSP(콘텐츠 보안 정책) 는 웹 브라우저에 구현된 보안 기능으로, 크로스 사이트 스크립팅(XSS) 및 데이터 인젝션 공격 등 다양한 유형의 공격으로부터 웹사이트와 웹 애플리케이션을 보호합니다. CSP는 웹 페이지에서 로드하거나 실행할 수 있는 다양한 유형의 콘텐츠 소스를 제어하고 제한합니다. 이러한 유형의 콘텐츠에는 다음이 포함됩니다:
- 스크립트
- 스타일시트
- Images
이 글에서는 먼저 CSP가 어떻게 작동하는지 살펴보겠습니다. CSP를 보다 효과적이고 동적으로 사용하려면 서버에서 일부 연산을 수행해야 합니다. 하지만 이러한 계산을 엣지로 이동하여 지연 시간을 줄이고 최적의 최종 사용자 경험을 보장할 수 있습니다. 또한 이러한 엣지 컴퓨팅 솔루션이 어떻게 작동하는지 살펴보겠습니다.
자세히 알아볼 준비가 되셨나요? CSP의 작동 원리를 이해하는 것부터 시작하겠습니다.
CSP 작동 방식
CSP는 일반적으로 서버 측에 Content-Security-Policy 헤더를 HTTP 응답에 추가합니다. 이는 웹 서버가 웹 페이지를 요청하는 사용자에게 전송합니다. 이 헤더는 페이지에서 콘텐츠를 로드하고 실행할 때 브라우저가 따라야 하는 규칙을 지정합니다.
설정의 예 Content-Security-Policy 헤더
Node.js 에서 Express로 작업한다고 가정해 보겠습니다. CSP 헤더를 다음과 같이 설정합니다:
const express = require('express'); |
Flask에 Python 을 사용하는 경우 코드는 다음과 같습니다:
app = Flask(__name__) |
지시문으로 작업하기
각 CSP 헤더에는 여러 개의 지시어가 있을 수 있으며, 각 지시어는 제공된 설정 유형에 적합한 값을 가질 수 있습니다. 이러한 지시어는 다양한 유형의 리소스에 대한 보안 규칙을 정의합니다. 예를 들어 script-src 지시문은 스타일시트에 허용된 소스를 지정합니다.
다음 CSP 헤더를 고려하세요:
Content-Security-Policy: default-src 'self'; script-src 'self' https://static.example.com; style-src 'self' 'unsafe-inline'; |
위의 헤더에는 세 개의 지시문이 있으며, 각 지시문에는 값이 함께 표시됩니다.
- The
default-src지시어를'self'는 기본적으로 모든 콘텐츠가 페이지 자체와 동일한 원본에서 로드되도록 지정합니다. - The
script-src지시어를 사용하면 동일한 오리진에서 스크립트를 로드할 수 있습니다('self') 및 지정된 외부 소스(https://static.example.com). - The
style-src지시문을 사용하면 동일한 원본에서 스타일시트를 로드할 수 있으며 인라인 스타일도 허용합니다.
사용 가능한 지시어 목록은 실제로 매우 광범위합니다. 여기에서 확인할 수 있습니다. 지시어는 다음과 같습니다:
font-src: 다음을 사용하여 로드된 글꼴의 소스@font-faceframe-src: 다음과 같은 요소에 로드된 중첩된 브라우징 컨텍스트의 소스<frame>그리고<iframe>img-src: 이미지 및 파비콘 소스
CSP를 HTML에 연결하기
서버에서 CSP 헤더가 설정되면 브라우저는 웹 페이지에서 리소스를 로드할 때 이러한 규칙을 적용합니다.
개발자는 HTML 소스에서 스크립트나 스타일시트와 같은 요소를 인라인으로 추가하거나 동일한 출처 또는 다른 곳에서 리소스를 참조하여 추가할 수 있습니다. 그러면 브라우저는 CSP 헤더를 확인하여 이러한 리소스가 정의된 규칙을 준수하는지 확인합니다. CSP에서 리소스를 허용하지 않는 경우 브라우저는 해당 리소스의 포함 및 실행을 차단합니다.
모든 요청에 고유
CSP 헤더가 정의되는 방식 때문에 일반적으로 특정 웹 페이지에 대한 모든 요청에 걸쳐 일관성을 유지합니다. 단일 페이지의 각 요청에 대한 세부 정보와 지시문은 해당 페이지의 후속 요청마다 동일하게 적용됩니다.
그렇다면 흥미로운 질문이 생깁니다: 동적 인라인 스크립트 및 스타일을 어떻게 처리할까요? 모든 인라인 스크립트 및 스타일을 포함하지 않고 특정 인라인 스크립트 및 스타일의 실행을 허용하고 싶을 수 있습니다.
이 시나리오에서는 논스 값이나 해시를 도입하여 스크립트나 스타일의 소스가 CSP에 명시적으로 나열되어 있지 않더라도 CSP 헤더에 지정된 논스 또는 해시 값과 일치하는 한 실행될 수 있도록 할 수 있습니다.
이러한 논스 값 또는 해시는 요청할 때마다 변경될 수 있으므로 고유하게 만들 수 있습니다. 따라서 서버에서 생성하고 관리해야 합니다. 하지만 이러한 논스나 해시를 서버에서 실행해야 한다고 해서 반드시 사이트의 메인 서버에서 실행할 필요는 없습니다. 이것이 바로 엣지 컴퓨팅이 필요한 이유입니다.
엣지 컴퓨팅이란 무엇인가요?
엣지 컴퓨팅은 기본적으로 일부 컴퓨팅을 최종 사용자와 지리적으로 가까운 네트워크의 외부 엣지에서 실행하도록 설정할 수 있다는 개념입니다. 기본적으로 분산 컴퓨팅의 일종으로, 인터넷을 통해서도 실시간 컴퓨팅 속도에 근접하고 네트워크 지연 시간을 줄일 수 있습니다.
엣지 컴퓨팅을 사용하면 CSP 헤더의 논스와 해시를 최종 사용자에게 더 가깝게 생성하여 사이트 보안을 위해 대기해야 하는 시간을 줄일 수 있습니다.
엣지 컴퓨팅이 CSP에 도움이 되는 방법
CSP가 사이트 속도를 저하시키는 주요 이유 중 하나는 헤더의 논스로 인해 캐시가 누락되어 고객의 브라우저가 서버까지 이동해야 사이트가 최신 헤더를 제대로 생성할 수 있기 때문입니다. 이 문제를 해결하기 위해 엣지 인스턴스에서 동적 CSP 논스 생성기를 구현할 수 있습니다. 이렇게 하면 보안을 유지하면서 캐싱을 여전히 유용하게 사용할 수 있는 방법이 제공됩니다.
이 접근 방식의 장점은 다음과 같습니다:
- 지연 시간 단축: 엣지 컴퓨팅 인스턴스가 논스를 생성하여 요청에 삽입합니다. 이제 논스가 삽입된 요청은 계속해서 캐시로 이동하므로 요청이 있을 때마다 새로운 응답을 가져오기 위해 원본 서버에 접속할 필요가 없습니다.
- 분산 보안: 엣지 컴퓨팅을 사용하면 고객이 시스템의 기본 서버 및 애플리케이션 코드와 상호 작용하기 전에 추가적인 보안 계층을 확보할 수 있습니다. 애플리케이션에 취약점이 있더라도 CSP 논스를 계산하는 엣지 컴퓨팅은 추가적인 보안 계층을 제공하여 잠재적인 문제를 완화하는 데 도움을 줍니다.
- 유지 관리의 용이성: 서버리스 접근 방식으로 엣지에서 CSP 헤더에 대한 동적 논스를 관리하면 유지 관리 작업이 간소화됩니다. 특히 애플리케이션 코드를 수정하지 않고도 CSP 정책을 관리할 수 있습니다. 또한 일반적으로 특별한 코드 배포 없이도 중앙 제어 시스템에서 이러한 종류의 변경 사항을 관리할 수 있습니다. 이러한 엣지 컴퓨팅 기능은 여러 독립적인 애플리케이션에서도 사용할 수 있으므로 각 애플리케이션에서 작업하는 특정 팀으로부터 문제를 분리하고 보안 전문가가 올바른 논스 생성이 일어나고 있는지 확인할 수 있습니다.
결론
엣지 컴퓨팅 사용에 대해 자세히 알아보고 싶으신가요? 그렇다면 Akamai의 주요 제품 몇 가지를 확인해 보세요. 특히 엣지워커는 네트워크 엣지에 서버를 직접 배포하는 복잡한 과정 없이도 이 글에서 설명한 것과 같은 작업을 수행할 수 있는 서버리스 환경을 구축할 수 있습니다.
직접 사용해 볼 준비가 되셨다면 지금 무료 체험판에 가입하세요! 이제 캐싱 체계를 망치지 않는 더 나은 CSP 헤더로 사이트를 보호할 시간입니다!
내용