실시간 인벤토리 심층 분석

FireMon 초기(정확히는 FireMon이 되기 이전)에 저희는 고객의 클라우드 계정(구독/프로젝트 포함)을 실시간으로 평가하려는 시도가... 간단치 않다는 점을 깨달았습니다. 그만큼 많은 평가를 실행하면 서비스 한도에 금세 도달하고 고객의 내부 API 호출에 지장을 줄 수도 있었습니다. 저희가 이 작업을 시작한 것은 약 7년 전으로, CSPM이라는 개념조차 없던 시절이었고 모두가 같은 교훈을 배워가던 때였다는 점을 감안해 주시기 바랍니다.

저희가 처음 마련한 해결책은 구성 데이터를 한 번 수집해 자체 인벤토리에 입력한 뒤, 그곳에서 평가를 수행하는 방식이었습니다. 이를 통해 API 호출을 메타데이터 조회에 필요한 수준으로만 줄일 수 있었습니다. 그런 다음 동일한 데이터 세트를 기반으로 여러 평가를 실행할 수 있었습니다. 한동안 이 접근 방식은 잘 작동했습니다. 여전히 시간 기반 구성 스캔을 수행했지만, 이를 보다 고르게 분산하고 API 호출 과부하를 최소화하도록 최적화할 수 있었습니다. 그러나 이 접근 방식에도 나름의 문제가 있었습니다. 스캔 시점과 담당자가 실제로 경고를 처리하는 시점 사이에 무언가가 변경되었다면 어떻게 될까요? 또한 특정 AWS 서비스의 모든 리소스를 전수 조회하는 작업은 서비스와 리전을 기준으로 적용되는 API 한도에 여전히 부담을 주었습니다.

저희는 이 상황을 더 잘 해결하기 위해 두 가지 과제를 설정했습니다. 첫째, 인벤토리를 실시간으로 업데이트해 특정 서비스에 대한 API 호출 급증을 줄이고 고객이 오래된 데이터를 다루는 일이 없도록 하는 것이었습니다. 둘째, 이력을 유지해 고객과 조사자가 무엇이 어떻게 변경되었는지 정확히 되짚어 볼 수 있도록 하는 것이었습니다. 기술 아키텍처는 뒤에서 자세히 다루겠으며, 클라우드 플랫폼마다 조금씩 다릅니다. 요약하자면, 클라우드 제공업체의 이벤트 스트림에 직접 연결함으로써 변경 API 호출을 식별하고, 관련 리소스를 추출하며, 인벤토리를 실시간으로 업데이트하고, 해당 인벤토리 유형에 대한 모든 평가를 동시에 실행할 수 있었습니다.

저희는 여전히 하루 한 번/업무 외 시간의 시간 기반 전수 스캔으로 이를 지원하고 있지만, 실시간 방식으로 전환하면서 여러 문제가 해결되었고 흥미로운 이점도 생겼습니다. 이러한 이점은 다음과 같습니다.

• 고객은 오래된 데이터를 접하지 않습니다. 플랫폼의 모든 내용이 실제 실행 중인 구성/상태와 거의 일치해야 합니다.
• API 호출을 모니터링하므로 누가 해당 호출을 했는지 식별할 수 있습니다. 그 결과 인벤토리에 완전한 ID 귀속 정보가 확보됩니다.
• 변경이 이루어지는 시점에 무엇이 변경되었는지 쉽게 파악할 수 있어 포괄적인 변경 추적이 가능합니다.
• 변경이 발생하는 대로 모든 검사와 평가를 실시간으로 실행할 수 있습니다. 여기에는 새로운 문제를 식별하는 것뿐 아니라, 외부에서 누군가가 문제를 바로잡을 때 해당 문제를 해결(RESOLVING)하는 것도 포함됩니다.

이것으로 완성입니다. 완전한 실시간, 변경 추적, ID 귀속 기반의 이력 인벤토리입니다. 물론 AWS Config와 같은 기능은 클라우드 제공업체 내에서 기본적으로 이를 제공합니다. 그러나 비용 효율성은 차치하더라도, 저희 인벤토리와 평가는 긴밀하게 통합되어 있고, 여러 클라우드 배포와 제공업체를 포괄하며, 포괄적인 검색 기능과 같은 상당히 인상적인 역량을 제공합니다.

이를 가장 잘 경험하는 방법은 90초 분량의 동영상 둘러보기입니다! 아래는 몇 가지 주요 스크린샷입니다.

메인 페이지에서는 중요한 데이터를 한 화면에서 풍부하게 보여줍니다.

다음은 변경 이력 화면으로, 전체 세부 정보와 귀속 정보를 함께 변경 사항을 보여줍니다. 또한 관련 이벤트, 연관 리소스, 예외 항목, 해당 리소스의 통과/실패 결과 이력과 같은 유용한 기능을 갖추고 있습니다.

이 이력 화면은 변경 사항을 시간순으로 추적하며 활동 추세를 나타내는 그래프를 함께 제공합니다. 타임라인을 클릭하면 해당 날짜로 이동합니다.

특정 시점의 로그에 나타난 IP 주소를 어떤 임시 클라우드 리소스가 보유하고 있었는지 확인해야 했던 적이 있으십니까? 침해 사고 대응 담당자들이 특히 선호하는 기능입니다...

여기까지가 간략한 개요입니다. 앞으로의 게시물에서는 아키텍처와 멀티 클라우드 환경에서 이를 처리하는 방식에 대해 더 자세히 설명하겠습니다.