대규모 AWS WAF 거버넌스

자체 웹 애플리케이션 또는 API를 개발하고 운영하는 팀이 여러 팀으로 구성된 대규모 조직에서는 보호 기능이 취약하거나 전혀 없는 노출된 엔드포인트를 피하기 위해 팀 전체에서 보안 제어의 일관성을 유지하기 위한 도구와 프로세스를 사용합니다. AWS Firewall Manager는 조직에서 AWS WAF 및 Shield Advanced 배포를 관리하는 데 사용할 수 있는 도구입니다.

Firewall Manager를 사용하면 CloudFront 배포, ALB 또는 API Gateway와 같이 공개적으로 노출된 리소스 전체에 자동으로 배포되는 AWS WAF 또는 Shield Advanced 정책을 정의할 수 있습니다. 정책은 다음과 같이 구성됩니다.

• 적용되는 위치를 정의하는 범위: 어떤 유형의 리소스(CloudFront, ALB 등)인지? 특정 태그가 있는 리소스를 포함하거나 제외하는지? 포함하거나 제외할 계정 또는 조직 단위는 무엇인지?
• 적용할 WAF 규칙 그룹을 정의하는 규칙은 무엇인지? 중앙에서 로깅을 사용하도록 설정할지 여부, Shield Advanced 보호 기능을 추가할지 여부를 구성합니다.
• 정책 범위 내에서 리소스가 발견될 경우 수행할 작업을 정의하는 작업입니다. 예를 들어 자동으로 정책 규칙을 시행하거나 보고만 할 수 있습니다. Firewall Manager를 처음 배포할 때는 자동 문제 해결 없이 시작하여 기존 애플리케이션에 미치는 영향을 최소화하면서 수동 처리가 필요한 리소스를 식별하는 것이 좋습니다. 신뢰도가 높아지면 Firewall Manager를 자동 문제 해결로 전환할 수 있습니다.

Firewall Manager를 사용하려면 먼저 Firewall Manager의 사전 조건을 살펴보세요. 참고로 AWS Config는 Firewall Manager의 사전 조건 중 하나입니다. AWS Config 비용을 최적화하려면 Firewall Manager만 사용하도록 설정한 경우 레코드에 대한 리소스 유형 설정을 시나리오에 맞는 관련 리소스로 제한하세요(예: WAF, CloudFront 배포, 로드 밸런서 등). 또한 정책은 지역적 구성이라는 점에 유의하세요. 예를 들어 CloudFront에 대한 글로벌 정책과 ALB 및 API Gateway와 같은 지역 리소스가 있는 각 리전의 지역 정책이 필요합니다. AWS Organizations 전체에 Firewall Manager 정책을 쉽게 배포하려면 이 AWS 솔루션을 고려해 보세요.

WAF 정책을 생성하면 Firewall Manager는 정책 범위 내의 AWS 계정에 정책 WAF 규칙을 사용하여 WAF WebACL을 배포합니다. WAF 정책에서는 Firewall Manager에 의해 배포된 WebACL에 추가되는 두 가지 유형의 규칙 그룹을 정의할 수 있습니다.

• 첫 번째 규칙 그룹은 다른 규칙보다 먼저 평가됩니다.
• 마지막 규칙 그룹은 마지막에 평가됩니다.

이를 통해 중앙 보안 팀에서 조직 전반에 걸쳐 공통 규칙 그룹을 관리할 수 있는 동시에 애플리케이션 팀에서 첫 번째 공통 규칙 그룹과 마지막 공통 규칙 그룹 사이에 애플리케이션과 관련된 사용자 지정 규칙을 추가할 수 있습니다. AWS WAF의 규칙은 순서대로 평가되므로 첫 번째 공통 규칙 그룹이 다른 규칙보다 먼저 평가되고, 그 다음으로 애플리케이션 팀에서 생성한 규칙이 평가되고, 마지막으로 마지막 공통 규칙 그룹이 평가됩니다.

관리 AWS 계정의 AWS WAF 정책에서 공통 WAF 규칙 그룹을 업데이트하는 CI/CD 파이프라인을 구축할 수 있습니다. 그러면 Firewall Manager에서 몇 분 내에 조직 전체에 배포할 수 있습니다. 이 블로그에서 OLX가 중앙 로깅 시스템과 함께 CI/CD 파이프라인을 사용하여 중앙 WAF 정책을 배포한 방법을 알아보세요.

Firewall Manager는 조직의 요구 사항에 따라 다양한 보안 거버넌스 전략을 수립할 수 있는 유연한 도구입니다. 모든 중앙 집중식 보안 거버넌스에서는 보호 수준을 높이기 위해 규칙을 중앙 집중식으로 적용하는 정도와 중앙 집중식으로 배포된 공통 규칙으로 인한 오탐을 처리하려는 정도를 절충해야 합니다.

자율성이 매우 높은 애플리케이션 팀이 있고 오탐을 관리하지 않으려는 경우 심각한 위협을 해결하는 단일 중앙 WAF 정책을 만드세요. 예를 들어 신뢰도가 높은 악성 IP 평판 목록 및 수출 금지 국가에 대한 지역 차단 규칙과 결합하여 높은 임계값을 가진 속도 제한을 기반으로 WAF 규칙을 만들 수 있습니다. 또한 Shield Advanced를 활성화하고 자동 애플리케이션 계층 DDoS 완화를 활성화할 수 있습니다. 이러한 규칙은 오탐률이 매우 낮은 경향이 있지만 HTTP 플러드를 방지하는 데는 효과적입니다. 또한 심각하고 영향이 큰 Zero Day 취약성이 발견되면 배포된 WAF 공통 규칙 그룹을 사용하여 중앙 집중식으로 완화 조치를 적용할 수 있습니다.

애플리케이션과 관련된 사용자 지정 WAF 규칙을 WebACL에 추가하는 모범 사례에 대한 지침을 포함하여 애플리케이션 팀을 위한 내부 위키를 만드는 것이 좋습니다. 예를 들어 애플리케이션이 SQLi 및 XSS 공격에 취약한 경우 그러한 공격에 대한 보호 기능을 추가하도록 안내해야 합니다.

더 광범위한 위협으로 중앙 보안 범위를 확대하려면 중앙 공통 규칙 그룹을 강화하되 애플리케이션 팀에 오탐을 자율적으로 관리할 수 있는 가능성을 제공하세요. 이 WAF 거버넌스 모델을 구현하려면 WAF 정책의 첫 번째 규칙 그룹에 공통 규칙을 카운트 모드로 추가하세요. 이러한 규칙은 레이블만 내보내며, WAF 정책의 마지막 규칙 그룹에서 이러한 레이블과 일치하는 요청을 차단하는 데 사용할 수 있습니다.

애플리케이션 팀에서 오탐이 발생하는 경우 규칙에서 내보낸 레이블을 사용하여 제외 규칙을 만들 수 있습니다. 이를 설명하기 위한 예시로는 SQLi로부터 보호하기 위한 Amazon 관리형 규칙(AMR)이 첫 번째 규칙 그룹에 카운트 모드로 추가되는 시나리오를 고려해 보세요. 마지막 규칙 그룹에서 규칙은 앞서 언급한 AMR에서 내보낸 label_matched=”SQLi_BODY” 레이블이 있는 요청을 차단합니다. AMR이 특정 URL(url=”/form1”)의 애플리케이션에 오탐을 유발하는 경우 애플리케이션 팀은 WebACL에 이러한 오탐을 완화하는 제외 규칙을 생성할 수 있습니다(예: IF url=”/form1” AND label_matched=”SQLi_BODY” then ALLOW). 허용 규칙 작업이 종료됩니다. 즉, AWS WAF는 후속 차단 규칙 평가를 중단합니다.

기존 애플리케이션에 영향을 주지 않고 이 정책에 대한 변경 사항을 롤아웃하려면 애플리케이션 팀에서 스테이징 환경에서 사용할 이 정책의 복제본을 만드는 것이 좋습니다. 두 정책 모두 상호 배타적인 범위를 가져야 합니다. 예를 들어, 프로덕션 정책은 스테이징 태그가 있는 배포를 제외한 모든 CloudFront 배포에 적용되고 스테이징 정책은 스테이징 태그가 있는 모든 CloudFront 배포에 적용됩니다. 대부분의 업데이트의 경우 먼저 스테이징 정책에 롤아웃하고 SNS 주제를 사용하여 모든 애플리케이션 팀에 알릴 수 있습니다. 변경 사항이 통보되면 애플리케이션 팀은 자동화할 수 있는 스테이징 환경에서 새 정책 버전을 테스트하고 필요한 경우 오탐지를 관리할 수 있습니다. 그런 다음 합의된 지연 시간이 지나면 중앙 팀이 변경 사항을 생산 정책에 전파합니다. Log4j CVE에 대한 보호와 같이 일주일을 넘어가면 안 되는 중요 업데이트는 애플리케이션 팀이 예외를 처리할 때까지 일시적으로 일부 오탐을 감수하고 즉시 적용할 수 있습니다.

일관된 보안 기준을 적용하면서도 계정 관리자의 일부 사용자 지정을 허용하려는 경우. 이 문서에서는 중앙에서 관리되는 보안 기준 정책을 설계하고 구현하는 단계를 간략하게 설명합니다. 또한 정책 테스트 및 배포 모범 사례도 자세히 설명합니다.

이전과 동일한 요구 사항을 충족하지만 애플리케이션 팀의 애플리케이션 보안을 강화하는 데 따르는 인지 부하를 줄이려면 조직에 존재하는 다양한 애플리케이션 유형에 대한 정책 카탈로그를 만드는 것이 좋습니다. 예를 들어, 다음과 같은 두 가지 정책이 포함된 카탈로그를 사용할 수 있습니다.

• 첫 번째 정책: Wordpress 기반 애플리케이션을 보호하는 데 권장됩니다.
• 두 번째 정책: SQL 데이터베이스로 PHP 애플리케이션을 보호하는 데 권장됩니다. 이 정책은 차단 민감도 수준이 서로 다른 두 가지 버전으로 만들 수 있습니다. 이를 통해 애플리케이션 팀은 보안 요구 사항(편집증 수준)과 오탐에 대한 관리 의지를 충족하는 솔루션을 선택할 수 있습니다.
  
  

각 정책의 범위는 특정 태그(예: 첫 번째 정책의 경우 wordpress, 두 번째 정책의 경우 LAMP_HIGH/LAMP_LOW)로 정의됩니다. 애플리케이션 팀은 사용 가능한 정책 카탈로그를 참조하고 원하는 정책의 태그를 리소스에 적용합니다. Firewall Manager는 WAF WebACL을 해당 리소스에 자동으로 연결합니다.

참고로 이 접근 방식을 사용하면 이전 섹션에서 설명한 것과 같은 방식으로 오탐과 단계 변경을 관리할 수 있습니다.

애플리케이션 수준에서 사용자 지정 신호를 사용하여 애플리케이션에서 예상하는 사항을 기반으로 비정상적인 동작을 식별할 수 있습니다. 예를 들어, 사용자가 특정 순서로 애플리케이션을 탐색할 것으로 예상하거나, 사용자가 등록된 주소를 기반으로 특정 국가에서 특정 상품을 주문할 것이라고 예상하지 않을 수도 있습니다. 이러한 신호를 사용하면 AWS WAF를 사용하여 응답을 자동화할 수 있습니다. 예를 들어 애플리케이션 수준 동작이 의심스러운 IP에서 들어오는 CAPTCHA 요청을 차단하거나 이의를 제기할 수 있습니다. 애플리케이션 신호에 기반한 WAF 자동화의 개념을 시작하려면 이 AWS 솔루션의 예를 살펴보세요.

고급 자동화에는 다음이 포함됩니다.

• 로그인/가입 프로세스 중에 Cognito에서 발생하는 고위험 이벤트 소비.
• Fraud Detector에 의해 식별된 고위험 이벤트 소비. Fraud Detector는 기계 학습(ML) 기술과 20년간 축적된 Amazon Web Services(AWS) 및 Amazon.com의 사기 탐지 전문 지식을 활용하여 사람과 봇이 수행하는 잠재적인 사기 패턴을 실시간으로 자동으로 파악합니다. Fraud Detector를 사용하면 애플리케이션 수준의 사용자 행동을 분석하고 자체 사기 기록 데이터를 사용하여 사용 사례에 맞는 맞춤형 사기 탐지 기계 학습 모델을 교육, 테스트 및 배포하여 사기를 탐지할 수 있습니다.

WAF 관리 업무를 애플리케이션 팀에서 중앙 보안 팀으로 완전히 오프로드하려는 경우 AWS 계정에만 적용되는 범위를 지정하여 각 애플리케이션 팀을 위한 전용 정책을 만드세요. 이 시나리오에서는 초기 설정을 위한 프로세스와 오탐 관리와 같은 작업을 위해 애플리케이션 팀과 중앙 보안 팀 간의 커뮤니케이션 채널을 만들어야 합니다.

• 백서: AWS WAF 구현 지침의 거버넌스 예시 백서
• AWS re:Inforce 2024의 강연: Twilio가 AWS WAF 정책을 대규모로 관리하는 방법
• AWS WAF 제공 파트너 찾기
• 블로그: AWS의 웹 앱 보안 거버넌스를 위한 운영 모델