728x90

WAF IAM Policy 에 관한 이야기

AWS 를 사용하면서 만나는 Global 서비스들이 여럿 있습니다. CDN 제품인 CloudFront 가 가장 대표적인 Global 서비스이고 CF 에서 사용할 수 있는 WAF (Web Application Firewall) 역시 Global 서비스 입니다. 이런 제품들의 특징은 사용자에게 가까운 곳에서 동작해야 효과가 좋다(?)는 점이죠.

최근 WAF 는 Version 2 를 출시하면서 기존의 WAF 는 WAF Classic 으로 부르기 시작했습니다. 몇 가지 변화들이 있지만 그 이야기를 하려는 것은 아니구요, 새로운 버전이 출시되면서 IAM Policy 에도 WAF v2 에 대응하는 부분이 추가되었고 Console 접근을 하려다 보니 생겼던 에피소드를 IAM Policy 를 살펴보면서 간단히 이야기 해볼까 합니다. 


IAM 에서 미리 정의하여 제공되는 Policy 중 WAF 와 관련된 것은 두가지가 있습니다. 하나는 AWSWAFFullAccess 이고 다른 하나는 AWSWAFConsoleFullAccess 입니다. 이들 Policy 를 사용하여 권한을 부여해 두었다면 Action 항목에 "wafv2:*" 가 자동으로 추가, 적용이 되었고 WAFv2 의 사용에 문제가 없어야 합니다. 개별 정책을 JSON 으로 정의했다면 명시적으로 "wafv2" 를 넣어줘야 합니다. 

# Policy : AWSWAFFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "waf:*",
        "waf-regional:*",
        "wafv2:*",
        "elasticloadbalancing:SetWebACL",
        "apigateway:SetWebACL"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

문제는 기존 WAF Classic 은 화면 진입은 잘 되면서 에러 메세지가 눈에 안 띄는 곳에 나오면서 콘솔 진입시 위 정책이 충분치 않다는 것을 인지하기가 조금 어려웠습니다. 그런데 WAF v2 에서는 Unauthorized 메세지가 대박 크게 나오면서 마치 wafv2 정책이 제대로 들어가지 않은 것처럼 보이는 제보가 들어왔던 것이지요. 결론을 먼저 말하면 위 정책으로는 WAF Classic 이든 WAFv2 든 제대로 동작하지 않는게 정상입니다. 

# Policy : AWSWAFConsoleFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "apigateway:SetWebACL",
        "cloudfront:ListDistributions",
        "cloudfront:ListDistributionsByWebACLId",
        "cloudfront:UpdateDistribution",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeRegions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:SetWebACL",
        "waf-regional:*",
        "waf:*",
        "wafv2:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWSWAFConsoleFullAccess 정책을 살펴보면 AWSWAFFullAccess 에 있는 정책들이 모두 들어가 있습니다. 추가로 WAF 적용의 주된 대상이 되는 API Gateway, CloudFront, ELB 관련한 항목들이 추가된 것이 보이는데요, 이들 정책이 있어야 AWS Console 화면 구성에 필요한 정보들을 가져올 수 있고 화면 접근시 Authorization 에러가 발생하지 않게 되는 것으로 생각됩니다. 한참을 헤메다 요 정책을 그룹에 추가해 주고나서 문제를 해소할 수 있었습니다. 


AWS 를 쓰다보면 IAM 에서 적절하고 충분한 권한을 주는 문제에 종종 부딪히게 됩니다. 적용된 정책을 확인하는 페이지도 제공하고 있긴 하지만 실제로 사용자들이 API 호출이나 Console 액세스시에 겪게 되는 문제와 연결고리를 찾기 힘든 경우도 종종 생깁니다. 결국은 경험치가 있어야 하는 것인가 하는 고민에 빠지게 되는 5월의 어느날입니다. 

 

[ AWS 자격증을 준비하신다면 - 3만명이 수강한 강의 추천드립니다! ]

 

Ultimate AWS Certified Solutions Architect Associate (SAA)

Pass the AWS Certified Solutions Architect Certification SAA-C02. Complete AWS Certified Solutions Architect Associate!

www.udemy.com

[ WAF Classic 과 WAF v2 의 비교는 아래 블로그가 깔끔합니다! ]

 

 

AWS WAF Version 2 소개(개선 사항)

오늘은 새롭게 출시된 AWS WAF Version 2 에서 제공하는 새로운 기능들과 기존 AWS WAF(Classic) 대비 개선된 사항들에 대해 살펴보도록 하겠습니다.

medium.com

 

본 포스팅은 소정의 수수료를 받을 수 있습니다.

728x90
728x90

서비스를 제공하는 사람과 회사는 늘 악의적인 해커의 공격으로부터 서비스 인프라와 사용자들을 지켜야 하는 숙제를 안고 있습니다. 우리 회사의 웹 사이트는 안전한지, 공격이 발생했을 때 어떻게 사용자 정보를 보호할 것인지, 그리고 공격이 지속되는 상황에서 어떻게 서비스를 지속적으로 제공할 수 있도록 할 것인지에 대한 고민을 해야만 합니다. 세계 최대 CDN 공급 사업자인 아카마이(Akamai)는 이런 고민들 중 "지속적인 서비스의 제공" 관점에서 DDoS 공격 발생시 그 여파를 경감시킬 수 있는 보안 사업자를 선택하는 4가지 포인트를 인포그래픽으로 정리하여 공개했습니다.





#1. 위협에 대한 뛰어난 지식을 보유하고 있는가? (Maximal Threat Intelligence)


IT 기술이 발달하는 것과 보조를 맞추어 해커들의 공격 기술도 더욱 정교하게 바뀌고 있습니다. 다양한 계층에서의 공격 (e.g. OSI 7 Layer) 은 물론이고 서비스 인프라의 취약점을 발빠르게 캐치하여 진행하는 공격 등 해커들의 수준이 점점 높아지고 있습니다. 따라서 보안 사업자를 선정함에 있어 이러한 최신의 공격을 잘 이해하고 있는지, 그리고 어떻게 방어해야 할지를 알고 선제적인 조치를 취해줄 수 있는지를 검토해야 한다고 아카마이는 이야기하고 있습니다.





#2. 얼마나 많은 공격을 막아본 경험이 있는가? (Most Front-Line Experience)


음식도 많이 먹어본 사람이 맛집을 잘 찾는 것처럼 해커들의 공격 역시 많이 경험하고 막아본 사업자만이 잘 막을 수 있다는 것은 당연한 사실입니다. 하드웨어 기반의 DDoS 어플라이언스를 도입할때도 늘 중요하게 평가되는 것이 얼마나 많은 기업들이 장비를 도입 했고 사용하고 있는가 입니다. 시대가 클라우드 세상으로 바뀌면서 하드웨어 어플라이언스를 도입하는 것보다는 플랫폼을 이용하면서 플랫폼이 제공하는 방어 도구를 이용하는 경우가 많아지고 있습니다. 아카마이라던가 아마존처럼 글로벌 클라우드 인프라를 운영하는 회사들은 아무래도 이런 부분에서 경험치가 높을 수 밖에 없을 것 같습니다.





#3. 다양한 방법을 이용하여 DDoS 를 경감시킬 수 있는가? (Best Mitigation Capabilities)


해커들의 공격은 매년 규모가 더 커지고 있습니다. 제로데이 취약점을 이용하여 미처 보안 업체들이 패턴 업데이트를 하거나 취약점에 대한 패치가 공급되기 전에 공격이 시작되는 경우도 많습니다. 이런 공격들이 발생했을 때 얼마나 효과적으로 다양한 방법을 이용해서 DDoS 공격을 경감시키고 막을 수 있을 것이냐는 중요한 포인트입니다. 웹 방화벽으로 불리우는 7계층의 WAF 에서부터 IP / TCP 계층에서의 공격 등 다양한 형태의 공격을 대응 하나의 플랫폼으로 대응할 수 있는 기업은 아직 많지 않은 것 같습니다.





#4. DDoS 경감을 위한 인프라의 가용량이 충분한가? (Global Mitigation Capacity)


DDoS 공격이 무서운 것은 서비스 인프라의 자원이 정상적인 서비스를 할 수 없도록 만들기 때문입니다. IT 인프라의 수준이 발달하는 만큼 DDoS 공격의 규모가 커지는 것은 서비스 불가 상태를 만들기 위해 더 많은 공격 자원이 필요하다는 것과 일맥상통하는 부분입니다. 결국 그러한 공격을 받아낼 수 있는 인프라, 플랫폼을 가지고 있지 않은 사업자는 DDoS 에 대한 대비책으로 선택하기는 어려워 보입니다. 순간적으로 수백기가 혹은 테라급의 트레픽이 몰려왔을 때도 문제 없는 플랫폼을 가진 사업자의 선정이 중요한 포인트라 하겠습니다!





서비스를 기획하고 준비하는 단계에서부터 바야흐로 글로벌을 생각해야만 하는 시기입니다. 이는 언제든 대규모의 공격이 발생할 수 있고 이에 대한 대비도 같이 해야한다는 것을 의미합니다. 아카마이, 엣지캐스트, 아마존, 애져 등 많은 클라우드 사업자들은 근래에 보안에 대한 많은 상품과 전략을 발표하고 있습니다. 이는 고객들의 니즈가 보안에 많다는 것을 의미하고 이를 잘 처리할 수 있는 기업이 또 한번의 플랫폼 전쟁의 승자가 될 수 있다는 것을 암시합니다. 여러분의 선택은 어떤 플랫폼인가요...?





728x90

+ Recent posts