AWS TechCamp2-2(Bedrock 서비스 waf와 guardrail 연동)

https://catalog.us-east-1.prod.workshops.aws/workshops/e5ce2f2a-e576-41cc-838d-4b22da07c67d/ko-KR/6-lab3-waf/a-create-wcl

Design Secure Bedrock SaaS Architecture with API gateway

 

이번 시간은 저번 시간에 이어서 bedrock api gateway를 waf와 연동시키면서, bedrock의 ai에 악의적인 컨텐츠를 생성시키지 않도록 guardrail 서비스도 신청하여 테스트해보는 시간을 갖겠다.

 

 

Bedrock api gateway에 연결할 waf를 설정하고 있는 화면이다. 이름을 설정해주고

 

연결할 api gateway로 나의 bedrock api gw에 연결하고자 연관 리소스로 등록해두었다.

 

 

그 다음은 탐지 룰들을 골라야한다. AWS에서 관리하고 있는 룰 셋 목록들을 위 그림을 통해 볼 수 있다. aws에서 만들고 관리하는 룰 그룹들과 타사에서 만들고, 관리하는 룰 그룹들도 있다. 여기서 cloudbric 은 우리나라 기업이고, 국내 최초로 클라우드 보안 SaaS 플랫폼을 선보인 기업이라 그런지, 이렇게 공식적으로 룰 그룹에 포함되어있는 걸 볼 수 있다. 물론 저렇게 외부 기업에서 나온 것들은 다 유료이다.

 

물론 AWS에서도 paid rule group 이라는게 있다. 즉, 돈을 내야하는 룰 그룹이라는 것.

 

그러나 무료 탐지 룰 그룹들도 있어서 이걸 활용하면 된다. work studio shop에서 나온 것처럼 amazon ip reputation list와 anonymous IP list를 선택하였다.

 

amazon ip reputation list 말 그대로 외부 평판 정보를 기반으로 악성 ip를 차단하는 리스트임을 말한다. 이는 총 3개의 리스트로 구성된다.

• AWSManagedIPReputationList: MadPot 등의 위협 인텔리전스 도구가 외부 다양한 소스로부터 악성 활동에 적극적으로 가담하는 IP를 수집하고, 이를 바탕으로 탐지 룰셋을 업데이트하는 리스트이다.
• AWSManagedReconnaissanceList: AWS 리소스에 정찰을 수행하는, 즉 스캔하는 IP 들을 검사하고 등록하는 리스트임을 말한다.
• AWSManagedIPDDoSList: DDoS 활동에 적극적으로 참여하는 것으로 식별된 IP 주소를 검사해주는 리스트이다.

anonymous IP list는 AnonymousIPList와 HostingProviderIPList로 구성된다.

• AnonymousIPList: 주로 클라이언트의 정보를 익명화시키는 프록시나 vpn의 알려진 IP 주소들이 담긴 리스트이며,
• HostingProviderIPList: 최종 사용자 트래픽을 소싱할 가능성이 낮은 웹 호스팅 및 클라우드 제공업체의 IP 주소 목록을 관리하는 리스트이다. 
  • 즉, 호스팅 업체에서 갑자기 짧은 시간에 다수의 로그인 시도 및 댓글 스팸 공격 나아가 민감한 데이터 접근 시도 등이 있다면, 이는 공격자가 호스트 제공업체의 IP를 이용하여 공격을 시도하는 것으로 볼 수 있다는 것이다. 특히나, 트래픽을 보낼 가성이 적은 호스팅 업체에서는 특히나 그럴 가능성이 높기에 저러한 리스트를 관리하는 것이라 볼 수 있다.

https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon

IP reputation rule groups - AWS WAF, AWS Firewall Manager, and AWS Shield Advanced

 

 

그 다음 탐지 룰셋의 우선 순위를 정해둔다. 그런 다음 딱히 더 건들 것은 없기에 create web acl을 눌러 waf를 만들어주면 된다.

 

 

그런 다음, 로깅을 위해 로깅할 장소를 지정해줘야한다.

 

CloudWatch 서비스를 이용하여 로그 그룹을 만든 다음, 그 안에서 로그 항목들을 모니터링 및 분석하고자 한다.

 

이름을 설정해둔 뒤, 생성을 해주면,

 

 

방금 만들어둔 로그 그룹이 나타난 것을 볼 수 있으며, save를 눌러 저장한다.  이때 주의할 점이 aws-waf-logs- 이라는 이름으로 시작해야 해당 로그 그룹이 선택란에 떠서 선택할 수 있다. 안그러면, 만들어둔 로그 그룹이 안떠서 양식에 맞게 다시 만들어야 한다.

이렇게 해서 waf 에서 탐지되는 로그들을 모니터링할 수 있는 환경까지도 구축해보았다.

 

커스텀 탐지 패턴을 만들고자 블랙리스트를 만들고자 IP Sets에서 블랙리스트라는 이름을 가진 IP set에 IP 주소를 나의 IP 주소로 설정하였다. 여기서 주의할 점은 리전을 US West 주로 해야 방금 설정해둔 waf가 있는 곳에 IP set을 사용할 수 있다. waf 서비스가 글로벌 서비스로 등록되어 있다만, Web ACL 즉, access control list 가 담긴 사용하고자 하는 waf는 그 리전에 귀속되어 사용하기 때문이다. 이 또한 설명하는 이유가 workshop studio에서는 region을 us west가 아닌, seoul 리전으로 선택하였고 이는 잘못된 설명이라 이를 정정하고자 이렇게 따로 설명한 것이다. 

 

블랙리스트를 waf에 등록하고자 acl에 들어가서 rules에 add my own rules로 룰을 추가해보기로 한다.

 

룰 타입을 IP set으로 지정한 뒤, 이름을 넣고, IP set은 방금 만든 Blacklist 즉, 내 IP가 담긴 블랙리스트를 추가하였다. 출발지로 탐지된 IP 를 차단할건지, 목적지로 탐지된 IP로 차단할건지 물어 출발지 IP로 설정하였다. 그리고 action은 블랙리스트닌까 block을 걸기로 한다. 

 

방금 만든 내 탐지 룰을 우선순위 최상단에 두고 저장을 한 다음, 

 

실제로 크롬에서 접속한 결과, 차단된 것을 확인할 수 있었다. 이로써 waf 테스팅에도 성공하였다.

 

waf닌까 web 공격에 주로 쓰이는 xss, csrf 공격 같은 것도 막아야 waf를 쓰는 의미가 있지 않겠는가? 그래서 core rule set을 통해 xss 공격을 테스트해보기로 한다.

 

ubuntu 리눅스에서 테스트를 해보았다. what is Amazon Bedrock? 이라고 물어본 뒤, <script>alert(document.cookie)</script> 이라는 스크립트를 삽이하였고, 그대로 전송해보았다. 그 결과, Forbidden 즉, waf로부터 막혔는지 차단 메시지를 받았다.

 

실제 cloudwatch로부터 이벤트 로그 기록을 확인한 결과, AWS-AWSManagedRulesCommonRuleSet 이라는 aws 관리 룰 셋으로부터 block 되었고, 조건 타입은 xss로 지정되었으며, matchData(탐지된 데이터)는 '<', 'script' 이다. 즉, 정상적으로 탐지되어 차단된 것을 알 수 있다.

 

 

이에 대해 workshop studio는 아키텍쳐에서 따로 waf에 대한 표시를 안해둬서 굳이 표시를 해두자면, 저 위치가 해당될 거라 생각하여 따로 그림을 그려서 표시했다. 즉, 지금까지 저 부분을 구성 및 테스트한 거라 보면 된다.

 

이번에는 bedrock guardrail 구성 및 테스트이다.

이름을 지정하고,

 

콘텐츠 필터를 구성할 수 있다. 특정 유해 카테고리를 지정하여, 모델에 입력 및 응답에 직접적으로 감지하고 차단할 수 있다는 것이다. 나아가, 프롬프트 공격도 감지하고 차단할 수 있다. 이는 유해한 콘텐츠를 생성할려고 하는 우회 공격을 차단하기위해 설정해두는 것이다.

 

거부할 수 있는 주제도 추가할 수 있다. 나는 최근 web llm attack을 공부하여 관련된 거부 주제들을 만들어보았다. 주로 사용자 계정에 접근하고자하는 사용자의 문구를 필터링 하고자했다.

 

그 다음엔 특정 단어가 들어가면 필터 처리해주는 기능이 있다. 그래서 나는 web llm attack에 쓰였던 악성스크립트의 주요 단어인 <script> 라는 단어와 iframe 이라는 단어를 필터 항목에 넣었다. 

 

개인 식별 정보도 탐지되면 마스킹 처리하고자 민감한 정보 필터 추가에서 개인 식별정보 유형을 위와 같이 설정해두었다. 그렇게 설정들을 마무리하고 가드레일을 생성해주었다.

 

실제 테스트를 해보았다. user 계정에 접근할 수 있는 api 좀 달라고 하닌까 바로 content filters 로부터 차단이 걸려왔다.

 

그리고 cloudshell 이용해서 똑같이 테스트한 결과, 같은 응답 결과를 받은 것을 확인함으로써 제대로 필터링된 걸 cloudshell을 통해서도 확인할 수 있었다.

 

아마존 가드레일을 해당 아키텍쳐에 표시한다고 하면, 아마 저기가 되지 않을까 싶다. 뭔가 amazon bedrock 서비스를 전체적으로 감싸서 검사하는 느낌이 들어서 저렇게 표시해두었다. 

 

이렇게해서 amazon techcamp 2일차 수업인 Design Secure GenAI SaaS Gateway Architecture 에 대한 학습과 리뷰를 마치도록한다. 애초에 내가 이번 techcamp 수업을 신청했던 이유도 이번 실습 체험이 제일 컸었다. 앞으로 web LLM attack이 강화될텐데, 이와 관련된 AWS의 기초적인 보안 구성을 알아두면 좋겠다 라는 생각이 들었기때문이다.