Cloudflare · 보안

막는 장치가 각각 무엇을 보는지 구분한 글을 먼저 보시는 편이 낫습니다. 요청 하나하나의 내용을 검사하는 장치와 트래픽의 양과 형태를 걸러 내는 장치는 대상이 서로 달라, 한쪽을 켠 것으로 다른 쪽까지 해결됐다고 읽으면 빈 곳이 그대로 남습니다. 구분이 잡힌 뒤에 계정 권한과 구성 점검을 다룬 글로 넘어가면 무엇이 남아 있는지 보입니다.

사례와 수치는 싣지 않습니다. 이 주제에서 공개할 수 있는 증빙 자료를 갖고 있지 않아, 검증할 수 없는 숫자를 적는 대신 원리와 적용 조건, 그리고 한계까지만 씁니다. 그래서 글은 어떤 제품이 얼마나 막았는지가 아니라 무엇이 걸러지고 무엇이 남는지를 설명합니다.

도입만으로 끝나는 문제는 많지 않습니다. 방화벽은 요청의 모양을 보지 애플리케이션의 논리를 이해하지 못하고, 앞단에 검사 계층을 두어도 원본 서버 주소가 드러나 있으면 그것을 건너뛰는 경로가 남습니다. 그래서 각 글은 도입한 뒤에 확인할 항목을 함께 두고, 다른 계층에서 풀어야 하는 문제는 그렇게 밝혀 적습니다.

AWS 앞단에 검사 계층을 두었다면 두 계층이 겹치는 지점을 다룬 글이 맞습니다. 원본 주소 노출, 접속자 주소가 바뀌어 차단 규칙과 로그가 엉뚱한 대상을 가리키는 문제, 캐시가 두 겹이 되는 문제가 그 자리에서 생기는데 화면상으로는 정상으로 보입니다. 구성 직후에 확인 절차를 넣어 두지 않으면 한동안 발견되지 않습니다.

설정을 켜 두었는데 실제로 걸러지고 있는지 확인되지 않을 때는 전문가 확인이 필요합니다. 규칙이 의도대로 동작하는지, 우회 경로가 남아 있는지는 외부에서 보이는 신호만으로 전부 판단되지 않고 구성과 로그를 함께 봐야 합니다. 그 앞 단계는 도메인만 입력하면 외부에서 보이는 설정을 확인해 주는 무료 도구로 먼저 좁히실 수 있습니다.