aws (7) 썸네일형 리스트형 [번역]GuardDuty 와 Route 53 Resolver DNS firewall을 이용해 자동으로 의심스러운 DNS 쿼리(악성 도메인) 차단하는 방법 이번 포스팅은 https://aws.amazon.com/ko/blogs/security/automatically-block-suspicious-dns-activity-with-amazon-guardduty-and-route-53-resolver-dns-firewall/ 을 번역 및 해석해서 작성한 글입니다. 이번 포스팅에서는 AWS GuardDuty에서 탐지된 의심스러운 DNS 쿼리를 Route 53 Resolver DNS Firewall 에서 자동으로 차단하는 방법에 대해 알아보고자 합니다. 우선 의심스러운 DNS 쿼리란 무언인지 알아보고자 합니다. 예를 들어 AWS 콘솔에 접속하고자 https://aws.amazon.com/ 를 브라우저 주소창에 입력하게 됩니다. 이제 aws.amazon.com의 I.. [번역] IAM 정책 타입들(SCP, IAM, Permission boundary): 언제 어떻게 써야하는 가 AWS에서의 유저의 행위, 그리고 대상이 되는 자원의 행위는 모두 IAM 정책의 영향을 받게 되어 있습니다. 유저가 새로운 EC2나 S3 버킷을 만들거나 기존의 자원들의 삭제 그리고 S3 버킷에 파일이 업로드될 때 이 행동들은 사전에 정의된 IAM 정책에 의해 허용 여부가 결정된다는 의미입니다. 이 포스팅에서는 여러 IAM 유형들에 대해 알아보고자 합니다. IAM 정책의 유형에는 Service control policy(SCP), 권한 경계(Permissions boundaries), 자격 증명 기반 정책(Identity-based policy), 자원 기반 정책(Resource-based policy)이 있으며 이들에 대해 언제 어떤 유형의 정책을 사용하고 누가 정책을 소유하고 관리해야 하는지에 대해 .. AWS security hub 의 status 에 대해 알아보자 삭제된 자원에 대한 finding 자동으로 조치하기 이번 포스팅에서는 security hub의 finding에 대한 워크 플루 상태 4가지와 이미 삭제된 자원에 대해 자동으로 상태를 RESOLVED로 변경하는 방식에 대해 알아보고자 합니다. 우선 AWS 보안의 포괄적인 뷰를 제공하는 Security hub 는 4가지 status 가 존재합니다. NEW - finding이 최초로 생성될 때 NOTIFIED - 리소스 소유자에게 결과에 대한 작업을 수행하도록 통지한 경우 SUPPRESSED - 결과가 조치가 필요하지 않는 경우 RESOLIVED - 결과를 검토하고 조치를 취한 이후 이를 통해 생성되는 findings 을 이해하고 어떤 후속 조치를 취해야 하는지를 분석할 수 있습니다. 하지만 포괄적인 뷰를 제공하는 security hub는 단일 계정, 단일 리.. AWS SCP, OU, Policy 에 대해 알아보자 개인이 AWS 계정을 사용하는 사용하는 경우에는 사실 AWS Organization을 이용해 다른 AWS 계정들을 연동시키거나 개발계, 검증계, 운영계 등과 같은 OU를 따로 생성할 경우는 드물 것입니다. 하지만 엔터프라이즈급 기업의 경우는 다를 것입니다. 여러 가지 이유로 인해 AWS Organization을 통해 다수의 AWS 계정을 활용하며 OU를 생성해 기업의 구조와 흡사한 형태로 관리해야 할 것입니다. 이번 포스팅에서는 SCP, OU에 대해 알아보고 이들이 여태껏 봐왔던 IAM Policy 와는 어떻게 차이가 나는지 알아보고자 합니다. 위 그림의 경우 AWS Organization 에서 OU을 생성한 뒤 OU에 맞게 SCP를 적용한 후 AWS 계정을 OU에 포함시킨 후 IAM 사용자들의 Poli.. AWS Security Hub 와 Open Search Service 의 SIEM 연동 AWS 보안 설루션들(GuardDuty, Inspector, Macie 등)의 로그를 통합적으로 관리할 수 있는 툴 AWS Security Hub와 Open Search Serivce 와의 SIEM 연동에 대해 소개하고자 합니다. Security Hub의 한계 1. CloudTrail logs와 같은 대용량 이벤트 로그를 직접 수집하지 않는다. 2. on-premises 또는 AWS 서비스가 아닌 로그를 수집할 수 없다. 3. Security Hub에서는 90일 이상 로그를 저장할 수 없다. 4. SIEM과 유사한 기능을 가지고 있지만 SIEM에 비해 부족하다. Security Hub를 단독으로 사용할 때의 단점은 위와 같다고 합니다. 그런데 1번의 경우 잘 이해되지 않는 부분은 1. CloudTrail.. AWS Security Hub 를 통해 GuardDuty 에서 발견된 로그 자동으로 경감조치하기 (custom action) AWS GuardDuty의 기능에 대해서는 이미 여러 곳에서 언급되었기에 생략하겠습니다. 여기서의 요점은 GuardDuty에서 진단하는 이 로그들을 토대로 경감조치 Remediation의 자동화를 어떻게 할 것이냐입니다. 예를 들어 하나의 인스턴스가 악성 봇에 감염되어 다른 인스턴스에 Ping을 보내고 포트스캔을 시도한 흔적을 GuardDuty에서 발견했습니다. 또 다른 인스턴스에 접근하지 못하게 재빨리 감염된 인스턴스에 대해 조치를 취해야 할 것입니다. 만약 보안 관리자가 발견하였다면 즉각 조치가 취해지겠지만 늦게 발견하였다면? 그리고 일일이 보안 관리자가 직접 조치를 해야 한다면? 이런 상황에서 탐지된 로그를 바탕으로 자동조치를 취하는 케이스에 대해 알아보고자 합니다. 시나리오는 다음과 같습니다. 1.. 제로 트러스트 아키텍처 Cloud IAM 기반 태그별 권한 할당 클라우드에서 IAM 권한을 세분화 해 클라우드 내 A 팀에서 생성한 자원은 A 팀에서만 접근/관리가 가능하고 B팀에서 생성한 자원은 B팀만 접근/관리가 가능하도록 C팀에서 생성한 자원은 C팀만이 접근/관리가 가능한 클라우드 보안 정책을 소개하고자 합니다. 위의 그림의 경우 MSA 을 운영한다는 가정하에 IT 인력이 Devops 에 적합하도록 배치되어 있습니다. A 팀은 A 서비스의 모든 것을 관리/운영/개발 하며 B팀은 B 서비스의 모든 것을 관리/운영/개발 하게 되어있습니다. 마찬가지로 클라우드 내 자원의 생성/삭제 역시 각 팀의 팀장 또는 infra 담당이 관리하며 이렇게 생성된 자원은 오직 각팀의 구성원만이 접근이 가능합니다. 우선 클라우드 계정과 제로 트러스트 솔루션을 이용해 AD와의 연동 과정을.. 이전 1 다음
