분류 전체보기 (63) 썸네일형 리스트형 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 IAM 정책(policy) 과 역할(role) 의 차이 이번 포스팅에서는 역할에 대해 알아보고자 합니다. 역할은 정책과 차이를 가지는 개념으로서 이 두 개의 차이가 무엇인지에 대해 알아보고자 합니다. 우선 AWS 에서 정의하는 역할의 뜻은 아래와 같습니다. 계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명입니다. IAM 역할은 IAM 사용자와 몇 가지 점에서 유사합니다. 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명입니다. 그러나 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한.. AWS IAM Identity base 와 resource base policy 의 차이 AWS IAM 정책에 대해 알아보려 합니다. 우선 5가지 형태의 구조를 가지고 있습니다. Effect Principal Resources Action Condition 간단히 말해 누가(Principal) 대상(Resource)에 작업(Action)을 조건(Condition)에 따라 허용(Effect)할지 말지를 정해 놓은 정책입니다. 그런데 이 정책이 적용할 대상은 Identity 가 될 수도 resource 가 될 수도 있습니다. Identity 기반 정책 누가(Principal) 대상(Resource)에 작업(Action)을 조건(Condition)에 따라 허용여부(Effect)를 결정하는 것 간단히 행위자(사람) 에게 부여하는 정책입니다. 위 정책은 "bizhub.hy 라는 S3 버킷에 읽기 권한.. 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.. 제로 트러스트 아키텍처 SAML 2.0 SSO 연동으로 DevOps 툴 접근제어JenKins (역할, role 기반으로 권한을 분할하자) 이번에는 젠킨스를 AD 계정으로 로그인하면서 역할 admin, user, 서비스 A, 서비스 B에 맞는 권한을 부여해 보겠습니다. 단순 SAML 2.0 연동을 하게 되면 오로지 접근 제어밖에 할 수 없게 됩니다. 접근 권한 = admin 이 되어 모든 사용자가 admin이 되게 됩니다. 하지만 admin과 user 간 권한이 분리되어야 하며 admin 은 지정된 운영자만이 권한을 가질 수 있습니다. 그리고 user는 모든 Item에 접근 가능해서는 안되고 오직 권한이 부여된 Item에 대해서만 권한을 가져야 합니다. 위와 같이 AD의 admin 그룹에 속하는 유저만이 젠킨스의 admin 권한을, user 그룹과 A 서비스 그룹에 속해야만 젠킨스의 A 서비스에 대해 권한을 가져야 합니다. AD 와 젠킨스 .. 제로 트러스트 아키텍처 SAML 2.0 SSO 연동으로 DevOps 툴 접근제어JenKins Gitlab, Github, Jenkins 등 DevOps, CI/CD을 위한 툴이 많습니다. 하지만 대부분의 툴들은 계정들을 자체적으로 생성해 쓰게 되는데 이른바 "admin" 같은 계정을 만들어 사용자들은 패스워드를 공유하며 하나의 계정을 돌려 쓰게 됩니다. 이러다 보니 누가 언제 admin 이란 계정으로 들어가 어떤 작업을 했는지 추적이 불가능하며 아무렇게 방치되는 패스워드는 해킹의 노출에 심각하게 방치되어 있습니다. 그렇다면 일일히 사용자마다 개별 계정을 만들어 주면 되지 않을까라고 생각할 수 있지만 사용자가 가지고 있는 devops 툴 계정이 몇 개나 늘어날지 그리고 계정들이 똑같은 아이디/패스워드로 관리된다면? 퇴사하거나 부서 이동한 사용자의 계정을 제거하지 못하고 방치된다면? 늘 염두해둬야 .. 이전 1 2 3 4 5 ··· 8 다음
