GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
회사의 인터넷 연결 애플리케이션의 보안 관리자로서 CVE, 경고, 업데이트 및 패치의 일정한 주기를 관리하는 것이 일반적인 작업일 수 있습니다. 새로운 애플리케이션, 기능 및 API 엔드포인트를 포함하여 애플리케이션 스택에 지속적인 변화를 추가하고, 해야 할 일 목록은 압도적으로 느껴질 수 있습니다. 하루에 추가 작업을 추가하는 것은 이상적이지 않습니다. WAF가 도움이 될 수 있습니다. 대부분의 WAF를 사용하면 가상 패치 역할을 하는 규칙을 배포하여 패치를 배포할 준비가 되지 않았거나 패치가 존재하지 않을 때 취약점으로부터 보호할 수 있습니다. 이러한 패치를 사용하면 헤더, 쿼리 및 쿠키와 같은 각 요청 요소에 대해 별도의 규칙이 생성될 수 있습니다. 하지만 제로데이 취약점으로부터 보호하기 위한 도구로 시작된 것은 복잡성과 추가적인 관리 부담을 야기할 수 있습니다. 이제 모든 애플리케이션을 추적하는 것 외에도 WAF의 다양한 요소를 관리해야 합니다.
시간 절약 및 변경 사항 신속한 배포
WAF 솔루션에 SAM(Security Application Manager)과 SRM(Security Rules Manager)이라는 두 가지 새로운 기능을 도입하게 된 것을 기쁘게 생각합니다. Security Application Manager는 응용 프로그램 스택에서 이러한 복잡한 보안 업데이트 스트림을 보다 쉽게 관리할 수 있도록 하는 정책입니다. 이 기능은 업데이트, 패치, 취약점 및 개발 팀이 서로 다른 여러 소프트웨어 스택과 플랫폼에서 여러 응용 프로그램을 실행하는 경우에 가장 유용합니다.
SAM을 사용하면 하나의 규칙으로 동작을 복제할 수 있습니다. 시간이 절약되고 효율성이 향상되며 속도가 빨라집니다. 이제 많은 규칙을 관리 할 필요가 없습니다.
Sam은 SRM과 협력하여 악성 트래픽과 원치 않는 트래픽으로부터 애플리케이션을 보호합니다.
이전 버전에서는 미디어 제어 센터의 여러 섹션을 변경해야 사이트를 보호할 수 있었습니다. WAF 규칙을 구성하려면 규칙 엔진에서 WAF 인스턴스에 대한 규칙을 추가하고 WAF 인스턴스 관리자에서 프로필과 작업을 구성하고 WAF 프로파일 관리자에서 정책을 정의해야 했습니다. 속도 제한을 구성하려면 호스트 이름 및 경로 일치, 조건, 임계값 및 적용에 대한 규칙을 다른 섹션에서 구성해야 했습니다.
그림 1: 이전 버전에서는 아래에 나와 있는 Media Control Center 규칙 작성기 및 Media Control Center 보안 내에서 인스턴스를 구성해야 했습니다.
그림 2: Media Control Center 보안
새 버전에서는 SRM 및 SAM이 있는 Media Control Center의 보안 섹션에 모든 설정을 추가하여 이 접근 방식을 단순화했습니다.
그림 3: 보안 규칙 관리자
SRM 플랫폼에는 액세스 규칙, 관리 규칙, 속도 규칙 및 사용자 지정 규칙과 같은 모든 보호 규칙이 포함되어 있습니다.
SAM은 모든 특정 응용 프로그램과 보호 방법을 정의합니다. 보호할 애플리케이션, 사용할 SRM 규칙 및 규칙이 트리거될 때 발생할 작업 유형을 정의합니다.
이 모듈화된 보안 솔루션에는 다음과 같은 여러 가지 이점이 있습니다.
- 변경 사항을 보다 빠르게 배포할 수 있습니다.
- 관리는 보다 모듈적이고 직관적입니다. 특정 호스트 이름 및 URL 경로에 적용되는 규칙을 지정할 수 있습니다.
- 규칙을 한 번 구성하고 여러 응용 프로그램에서 규칙을 사용하면 시간을 절약할 수 있습니다.
- 보호 기능이 더욱 유연해지고 사용자 지정 규칙을 만들고 배포할 수 있습니다.
- 듀얼 WAF 모드와 같은 이전 버전의 모든 이점을 계속 사용할 수 있습니다.
마지막으로, WAF 플랫폼은 이제 다른 CDN 구성과 독립적으로 작동하는 독립 실행형 솔루션입니다.
새로운 WAF가 실제로 작동하는 모습을 살펴보겠습니다.
이 예에서는 가상 기업을 위한 세 가지 애플리케이션, 즉 블로그, 포럼 및 API를 보호합니다. 다음 도메인을 사용합니다.
- blog.example.com
- forums.example.com
- api.example.com
하나의 액세스 규칙, 하나의 관리 규칙 및 하나의 속도 규칙을 생성하여 모든 애플리케이션에서 공유합니다. API 애플리케이션에서만 사용하는 두 번째 속도 규칙을 생성합니다.
첫 번째 단계는 새 액세스 규칙을 만드는 것입니다.
이 액세스 규칙의 이름을 “모든 속성 ACL”로 지정했습니다. 그리고 우리는 HEAD를 사용하는 모든 요청을 차단하기 위해 허용된 HTTP 메소드 아래에서 HEAD를 선택 해제했습니다.
그림 4: 새 액세스 규칙 만들기
다음으로, 새로운 Rate Rule을 생성합니다.
이 속도 규칙을 “모든 속성 RL”로 명명하고 “IP 주소 및 사용자 에이전트” 속성에 적용하여 분당 50건의 요청 속도 제한을 적용했습니다.
그림 5: 새 Rate Rule 생성
그런 다음 API 애플리케이션에만 사용할 다른 속도 규칙을 만듭니다.
이 속도 규칙을 “API RL”로 명명하고 “IP 주소 및 사용자 에이전트” 속성에 적용하여 분당 10건의 요청 속도 제한을 적용했습니다.
그림 6: 새 Rate Rule 생성
마지막으로, 새 관리 규칙을 만듭니다.
이 규칙의 이름을 “모든 속성 관리”로 지정하고 설정 탭의 모든 기본값을 허용했습니다. 정책 탭에서 최신 Edgio 규칙 집합에 자동으로 옵트인하도록 선택했습니다. 그러면 최신 버전이 자동으로 사용됩니다.
그림 7: 새 관리되는 규칙 만들기
SRM에서 규칙을 만들었으므로 이제 SAM에서 세 개의 새 애플리케이션을 만듭니다. 블로그, 포럼 및 API 애플리케이션에 각각 하나의 애플리케이션이 있습니다.
각 새로운 애플리케이션에 대해 특정 호스트 이름(예: blog.example.com 입력하고 URL Pat(s)를 기본값으로 남겨두어 모든 경로에서 일치하도록 합니다.
각 SAM의 규칙 섹션에서 모든 속성 ACL 액세스 규칙, 모든 속성 관리 규칙 및 SRM에서 생성한 모든 속성 RL 속도 규칙을 다시 사용합니다. 규칙이 트리거될 때 수행할 작업으로 요청 차단을 선택합니다.
그림 8: 모든 속성 ACL 액세스 규칙 적용.
API 애플리케이션에만 API RL 속도 규칙을 적용합니다. 이 추가 규칙을 포함하도록 API 응용 프로그램을 편집하여 이를 수행합니다. 여기서 순서가 중요하므로 API RL Rule을 맨 위로 끌어다 놓습니다.
그림 9: API Rate Limiting Rule 적용
마지막으로, 각 애플리케이션에 대한 액세스 규칙, 속도 규칙 및 관리되는 규칙을 보여주는 SAM 구성의 최종 보기를 살펴보겠습니다.
그림 10: Security Application Manager 구성 요약
이제 Security Rules Manager에서 규칙을 생성하고 Security Application Manager 애플리케이션에 적용하는 방법을 배웠습니다. SAM을 사용하여 애플리케이션을 보호하는 데 사용할 수 있는 다양한 옵션과 기능을 살펴보시기 바랍니다.
WAF를 포함한 보안 솔루션에 대해 더 자세히 알아보려면 오늘 연결해 보겠습니다.
