클라우드 보안 모니터링

데이터와 애플리케이션을 클라우드로 이동하는 것은 다른 사람의 인프라를 모니터링할 준비가 항상 되어 있지 않은 기업 SOC에 새로운 과제를 제시합니다. Netoskope에 따르면 일반 기업(미국으로 추정)은 1246개의 다양한 클라우드 서비스를 사용하고 있으며 이는 22년 전보다 1246% 증가한 수치입니다. 175 클라우드 서비스!!! 그 중 170개는 HR 서비스 관련, 110개는 마케팅 관련, 76개는 커뮤니케이션 분야, 700개는 재무 및 CRM 분야입니다. Cisco는 XNUMX개의 외부 클라우드 서비스만 "만" 사용합니다. 그래서 저는 이 숫자들을 보고 조금 혼란스러워졌습니다. 그러나 어쨌든 문제는 그들에게 있는 것이 아니라 자체 네트워크에서와 마찬가지로 클라우드 인프라를 모니터링하는 동일한 기능을 갖고 싶어하는 점점 더 많은 회사에서 클라우드를 매우 적극적으로 사용하기 시작했다는 사실입니다. 그리고 이러한 추세는 점점 더 커지고 있습니다. 미국회계회의소에 따르면 2023년까지 미국에서는 1200개의 데이터 센터가 폐쇄될 예정입니다(6250개는 이미 폐쇄되었습니다). 하지만 클라우드로의 전환은 단지 "서버를 외부 공급자로 옮기자"는 것이 아닙니다. 새로운 IT 아키텍처, 새로운 소프트웨어, 새로운 프로세스, 새로운 제한 사항... 이 모든 것이 IT 업무뿐만 아니라 정보 보안 업무에도 중요한 변화를 가져옵니다. 그리고 공급자가 클라우드 자체의 보안을 보장하는 데 어떻게든 대처하는 방법을 배웠다면(다행히 많은 권장 사항이 있음) 클라우드 정보 보안 모니터링, 특히 SaaS 플랫폼에서 상당한 어려움이 있습니다. 이에 대해 이야기하겠습니다.

회사에서 인프라의 일부를 클라우드로 옮겼다고 가정해 보겠습니다. 중지하세요. 이 방법은 아닙니다. 인프라가 이전되었고 이제서야 이를 모니터링할 방법에 대해 생각하고 있다면 이미 손실을 입은 것입니다. Amazon, Google 또는 Microsoft(그리고 예약이 있는 회사)가 아닌 이상 데이터와 애플리케이션을 모니터링할 수 있는 능력이 많지 않을 것입니다. 로그 작업 기회가 주어지면 좋습니다. 보안 이벤트 데이터를 사용할 수 있지만 액세스할 수 없는 경우도 있습니다. 예를 들어 Office 365입니다. 가장 저렴한 E1 라이선스를 가지고 있는 경우 보안 이벤트를 전혀 사용할 수 없습니다. E3 라이선스가 있는 경우 데이터는 90일 동안만 저장되며, E5 라이선스가 있는 경우에만 로그 기간이 3년 동안 제공됩니다. Microsoft 지원팀에 로그 작업을 위한 다양한 기능을 요청하세요. 그런데 E5 라이선스는 기업 Exchange에 비해 모니터링 기능 측면에서 훨씬 취약합니다. 동일한 수준을 달성하려면 EXNUMX 라이선스 또는 추가 고급 규정 준수 라이선스가 필요하며, 클라우드 인프라로 이동하기 위한 재무 모델에 고려되지 않은 추가 비용이 필요할 수 있습니다. 이는 클라우드 정보 보안 모니터링과 관련된 문제를 과소평가한 한 가지 예일 뿐입니다. 이 기사에서는 완전한 척하지 않고 보안 관점에서 클라우드 공급자를 선택할 때 고려해야 할 몇 가지 뉘앙스에 주목하고 싶습니다. 그리고 기사 끝 부분에는 클라우드 정보 보안 모니터링 문제가 해결되었는지 고려하기 전에 완료할 가치가 있는 체크리스트가 제공됩니다.

클라우드 환경에서는 정보 보안 서비스가 대응할 시간이 없거나 전혀 확인하지 못하는 사고로 이어지는 몇 가지 일반적인 문제가 있습니다.

• 보안 로그가 존재하지 않습니다. 이는 특히 클라우드 솔루션 시장의 초보 플레이어들 사이에서 상당히 일반적인 상황입니다. 하지만 당장 포기해서는 안 됩니다. 소규모 업체, 특히 국내 업체는 고객 요구 사항에 더 민감하며 승인된 제품 로드맵을 변경하여 일부 필수 기능을 신속하게 구현할 수 있습니다. 예, 이것은 Amazon의 GuardDuty나 Bitrix의 "Proactive Protection" 모듈과 유사하지는 않지만 적어도 뭔가가 될 것입니다.
• 정보 보안에서는 로그가 어디에 저장되어 있는지 알 수 없거나 로그에 액세스할 수 없습니다. 여기에서는 클라우드 서비스 제공자와 협상을 시작해야 합니다. 아마도 클라이언트가 자신에게 중요하다고 생각하면 그러한 정보를 제공할 것입니다. 그러나 일반적으로 “특별한 결정에 의해” 로그에 대한 접근이 제공되는 경우에는 그다지 좋지 않습니다.
• 또한 클라우드 제공업체에 로그가 있지만 제한적인 모니터링 및 이벤트 기록 기능을 제공하므로 모든 사고를 탐지하기에는 충분하지 않습니다. 예를 들어, 웹 사이트의 변경 로그나 사용자 인증 시도 로그만 수신할 수 있으며 네트워크 트래픽과 같은 다른 이벤트는 수신할 수 없습니다. 이로 인해 클라우드 인프라 해킹 시도를 특징짓는 전체 이벤트 계층이 숨겨집니다.
• 로그가 있지만 이에 대한 액세스를 자동화하기가 어렵기 때문에 지속적으로 모니터링하지 않고 일정에 따라 모니터링해야 합니다. 그리고 로그를 자동으로 다운로드할 수 없는 경우, 예를 들어 Excel 형식(여러 국내 클라우드 솔루션 제공업체의 경우)으로 로그를 다운로드하면 기업 정보 보안 서비스 측에서 이를 수정하는 것을 꺼릴 수도 있습니다.
• 로그 모니터링이 없습니다. 이것이 클라우드 환경에서 정보보안 사고가 발생하는 가장 불분명한 이유일 것이다. 로그가 있고 이에 대한 액세스를 자동화하는 것이 가능한 것 같지만 아무도 그렇게 하지 않습니다. 왜?

공유 클라우드 보안 개념

클라우드로의 전환은 항상 인프라에 대한 통제권을 유지하려는 욕구와 이를 유지 관리를 전문으로 하는 클라우드 제공업체의 보다 전문적인 손에 전달하려는 욕구 사이의 균형을 찾는 것입니다. 그리고 클라우드 보안 분야에서도 이러한 균형을 찾아야 합니다. 또한 사용되는 클라우드 서비스 제공 모델(IaaS, PaaS, SaaS)에 따라 이 균형은 항상 달라집니다. 어쨌든 우리는 오늘날 모든 클라우드 제공업체가 소위 책임 공유 및 정보 보안 공유 모델을 따른다는 점을 기억해야 합니다. 클라우드는 일부 작업을 담당하고, 다른 작업은 클라이언트가 담당하여 데이터, 애플리케이션, 가상 머신 및 기타 리소스를 클라우드에 배치합니다. 클라우드로 전환함으로써 모든 책임을 공급자에게 전가할 것이라고 기대하는 것은 무모한 것입니다. 하지만 클라우드로 이동할 때 모든 보안을 직접 구축하는 것도 현명하지 않습니다. 균형이 필요하며 이는 위험 관리 전략, 위협 모델, 클라우드 공급자가 사용할 수 있는 보안 메커니즘, 법률 등 다양한 요소에 따라 달라집니다.

예를 들어, 클라우드에 호스팅된 데이터의 분류는 항상 고객의 책임입니다. 클라우드 공급자 또는 외부 서비스 공급자는 클라우드의 데이터를 표시하고, 위반 사항을 식별하고, 법을 위반하는 데이터를 삭제하거나, 어떤 방법으로든 이를 마스킹하는 데 도움이 되는 도구로만 그를 도울 수 있습니다. 반면, 물리적 보안은 항상 클라우드 제공업체의 책임이므로 고객과 공유할 수 없습니다. 그러나 이 기사에서는 데이터와 물리적 인프라 사이에 있는 모든 것이 바로 논의 주제입니다. 예를 들어, 클라우드의 가용성은 공급자의 책임이고, 방화벽 규칙 설정이나 암호화 활성화는 클라이언트의 책임입니다. 이 기사에서는 현재 러시아의 다양한 인기 클라우드 제공업체가 제공하는 정보 보안 모니터링 메커니즘과 그 사용 기능은 무엇인지, 언제 외부 오버레이 솔루션(예: Cisco E- 메일 보안)은 사이버 보안 측면에서 클라우드의 기능을 확장합니다. 경우에 따라, 특히 멀티 클라우드 전략을 따르는 경우 여러 클라우드 환경에서 동시에 외부 정보 보안 모니터링 솔루션(예: Cisco CloudLock 또는 Cisco Stealthwatch Cloud)을 사용할 수밖에 없습니다. 글쎄, 어떤 경우에는 귀하가 선택한(또는 귀하에게 부과한) 클라우드 제공업체가 정보 보안 모니터링 기능을 전혀 제공하지 않는다는 것을 깨닫게 될 것입니다. 이는 불쾌하지만 적지도 않습니다. 이를 통해 이 클라우드 작업과 관련된 위험 수준을 적절하게 평가할 수 있기 때문입니다.

클라우드 보안 모니터링 수명주기

사용하는 클라우드의 보안을 모니터링하려면 세 가지 옵션만 있습니다.

• 클라우드 제공업체가 제공하는 도구를 활용하세요.
• 귀하가 사용하는 IaaS, PaaS 또는 SaaS 플랫폼을 모니터링하는 제XNUMX자의 솔루션을 사용합니다.
• 자체 클라우드 모니터링 인프라 구축(IaaS/PaaS 플랫폼에만 해당)

각 옵션에 어떤 기능이 있는지 살펴보겠습니다. 하지만 먼저 클라우드 플랫폼을 모니터링할 때 사용되는 일반적인 프레임워크를 이해해야 합니다. 클라우드의 정보 보안 모니터링 프로세스의 6가지 주요 구성 요소를 강조하겠습니다.

• 인프라 준비. 정보 보안에 중요한 이벤트를 스토리지에 수집하는 데 필요한 애플리케이션과 인프라를 결정합니다.
• 수집. 이 단계에서는 처리, 저장 및 분석을 위한 후속 전송을 위해 다양한 소스에서 보안 이벤트가 집계됩니다.
• 치료. 이 단계에서는 후속 분석을 용이하게 하기 위해 데이터가 변환되고 강화됩니다.
• 저장. 수집된 처리 데이터와 원시 데이터의 단기 및 장기 저장을 담당하는 구성 요소입니다.
• 분석. 이 단계에서는 사고를 감지하고 자동 또는 수동으로 대응할 수 있습니다.
• 보고. 이 단계는 공급자 변경 또는 정보 보안 강화와 같은 특정 결정을 내리는 데 도움이 되는 이해관계자(관리자, 감사자, 클라우드 공급자, 클라이언트 등)를 위한 주요 지표를 공식화하는 데 도움이 됩니다.

이러한 구성 요소를 이해하면 향후 제공업체로부터 무엇을 받을 수 있는지, 스스로 수행하거나 외부 컨설턴트의 참여를 통해 수행해야 할 작업을 신속하게 결정할 수 있습니다.

내장된 클라우드 서비스

나는 오늘날 많은 클라우드 서비스가 정보 보안 모니터링 기능을 제공하지 않는다고 위에서 이미 썼습니다. 일반적으로 그들은 정보 보안 주제에 큰 관심을 기울이지 않습니다. 예를 들어, 인터넷을 통해 정부 기관에 보고서를 보내는 인기 있는 러시아 서비스 중 하나입니다(이름은 구체적으로 언급하지 않겠습니다). 이 서비스의 보안에 관한 전체 섹션은 인증된 CIPF 사용을 중심으로 진행됩니다. 국내 전자문서 관리를 위한 또 다른 클라우드 서비스의 정보보안 부문도 다르지 않다. 공개 키 인증서, 인증된 암호화, 웹 취약성 제거, DDoS 공격 방지, 방화벽 사용, 백업, 심지어 정기적인 정보 보안 감사에 대해서도 설명합니다. 그러나 모니터링에 대한 언급이나 이 서비스 제공업체의 고객이 관심을 가질 수 있는 정보 보안 이벤트에 대한 액세스 가능성에 대한 언급은 없습니다.

일반적으로 클라우드 공급자가 웹사이트와 설명서에서 정보 보안 문제를 설명하는 방식을 보면 이 문제를 얼마나 심각하게 받아들이는지 이해할 수 있습니다. 예를 들어, “My Office” 제품의 설명서를 읽어보면 보안에 관한 단어는 전혀 없지만, 별도의 제품인 “My Office” 설명서에는 보안에 대한 언급이 전혀 없습니다. 무단 액세스로부터 보호하도록 설계된 KS3"에는 "My Office.KS17"이 구현하는 FSTEC 3차 항목의 일반적인 항목 목록이 있지만 이를 구현하는 방법과 가장 중요한 방법은 설명되어 있지 않습니다. 이러한 메커니즘을 기업 정보 보안과 통합합니다. 그러한 문서가 존재할 수도 있지만 공개 도메인인 "My Office" 웹 사이트에서는 찾을 수 없습니다. 어쩌면 내가 이 비밀 정보에 접근할 수 없는 건 아닐까?..

Bitrix의 경우 상황이 훨씬 좋습니다. 문서에서는 이벤트 로그의 형식과 흥미롭게도 클라우드 플랫폼에 대한 잠재적인 위협과 관련된 이벤트가 포함된 침입 로그에 대해 설명합니다. 여기에서 IP, 사용자 또는 게스트 이름, 이벤트 소스, 시간, 사용자 에이전트, 이벤트 유형 등을 가져올 수 있습니다. 사실, 클라우드 자체의 제어판에서 이러한 이벤트를 사용하거나 MS Excel 형식으로 데이터를 업로드할 수 있습니다. 이제 Bitrix 로그 작업을 자동화하는 것이 어렵고 일부 작업을 수동으로 수행해야 합니다(보고서 업로드 및 SIEM에 로드). 그러나 비교적 최근까지 그러한 기회가 존재하지 않았다는 것을 기억한다면 이것은 큰 진전입니다. 동시에 많은 외국 클라우드 제공업체가 "초보자용" 유사한 기능을 제공한다는 점에 주목하고 싶습니다. 제어판을 통해 눈으로 로그를 보거나 데이터를 자신에게 업로드합니다(그러나 대부분의 데이터는 . Excel이 아닌 csv 형식입니다.)

로그 없음 옵션을 고려하지 않고 클라우드 제공업체는 일반적으로 대시보드, 데이터 업로드, API 액세스 등 보안 이벤트 모니터링을 위한 세 가지 옵션을 제공합니다. 첫 번째 방법은 많은 문제를 해결하는 것처럼 보이지만 이는 전적으로 사실이 아닙니다. 잡지가 여러 개 있는 경우 잡지가 표시되는 화면 사이를 전환해야 하므로 전체 그림이 손실됩니다. 또한 클라우드 제공업체는 보안 이벤트의 상관관계를 파악하고 일반적으로 보안 관점에서 이를 분석하는 기능을 제공하지 않습니다. 일반적으로 원시 데이터를 처리하므로 스스로 이해해야 합니다. 예외가 있으며 이에 대해 더 자세히 설명하겠습니다. 마지막으로, 클라우드 제공업체가 어떤 이벤트를 어떤 형식으로 기록하며, 정보 보안 모니터링 프로세스와 어떻게 일치하는지 물어볼 가치가 있습니다. 예를 들어 사용자와 손님의 식별 및 인증이 있습니다. 동일한 Bitrix를 사용하면 이러한 이벤트를 기반으로 이벤트 날짜 및 시간, 사용자 또는 손님 이름("웹 분석" 모듈이 있는 경우), 액세스된 개체 및 웹사이트에 일반적인 기타 요소를 기록할 수 있습니다. . 그러나 기업 정보 보안 서비스에는 사용자가 신뢰할 수 있는 장치에서 클라우드에 액세스했는지 여부에 대한 정보가 필요할 수 있습니다. 예를 들어 기업 네트워크에서는 이 작업이 Cisco ISE에 의해 구현됩니다. 클라우드 서비스 사용자 계정이 도난되었는지 여부를 판단하는 데 도움이 되는 geo-IP 기능과 같은 간단한 작업은 어떻습니까? 그리고 클라우드 제공업체가 이를 제공하더라도 이것만으로는 충분하지 않습니다. 동일한 Cisco CloudLock은 단순히 지리적 위치를 분석하는 것이 아니라 이를 위해 머신 러닝을 사용하고 각 사용자의 기록 데이터를 분석하고 식별 및 인증 시도에서 다양한 이상 현상을 모니터링합니다. MS Azure에만 유사한 기능이 있습니다(적절한 구독이 있는 경우).

또 다른 어려움이 있습니다. 많은 클라우드 제공업체에게 정보 보안 모니터링은 이제 막 다루기 시작한 새로운 주제이기 때문에 솔루션에서 지속적으로 무언가를 변경하고 있습니다. 오늘은 한 가지 버전의 API가 있고, 내일은 또 다른 버전이 있고, 내일 모레에는 세 번째 버전이 있습니다. 이에 대한 준비도 필요합니다. 변경될 수 있는 기능의 경우에도 마찬가지이며 정보 보안 모니터링 시스템에서 이를 고려해야 합니다. 예를 들어 Amazon은 처음에 AWS CloudTrail과 AWS CloudWatch라는 별도의 클라우드 이벤트 모니터링 서비스를 보유했습니다. 그런 다음 정보 보안 이벤트를 모니터링하기 위한 별도의 서비스인 AWS GuardDuty가 나타났습니다. 얼마 후 Amazon은 GuardDuty, Amazon Inspector, Amazon Macie 및 기타 여러 곳에서 받은 데이터 분석이 포함된 새로운 관리 시스템인 Amazon Security Hub를 출시했습니다. 또 다른 예는 SIEM - AzLog를 사용한 Azure 로그 통합 도구입니다. 이 도구는 2018년 Microsoft가 개발 및 지원 중단을 발표할 때까지 많은 SIEM 공급업체에서 적극적으로 사용되었으며, 이로 인해 이 도구를 사용하는 많은 고객이 문제에 직면했습니다(해결 방법은 나중에 설명하겠습니다).

따라서 클라우드 공급자가 제공하는 모든 모니터링 기능을 주의 깊게 모니터링하십시오. 또는 SOC와 모니터링하려는 클라우드 사이의 중개자 역할을 하는 외부 솔루션 제공업체에 의존하세요. 예, 비용이 더 많이 들지만(항상 그런 것은 아니지만) 모든 책임을 다른 사람의 어깨에 전가하게 됩니다. 아니면 전부는 아니겠습니까?.. 공유 보안의 개념을 기억하고 아무것도 변경할 수 없다는 점을 이해합시다. 다양한 클라우드 제공업체가 데이터, 애플리케이션, 가상 머신 및 기타 리소스의 정보 보안 모니터링을 어떻게 제공하는지 독립적으로 이해해야 합니다. 클라우드에서 호스팅됩니다. 이 부분에서는 Amazon이 제공하는 것부터 시작하겠습니다.

예시: AWS 기반 IaaS의 정보 보안 모니터링

예, 예, 저는 이것이 미국 서비스이고 극단주의에 맞서 싸우고 러시아에서 금지된 정보 유포의 일환으로 차단될 수 있다는 사실 때문에 Amazon이 최고의 예가 아니라는 것을 이해합니다. 하지만 이번 간행물에서는 다양한 클라우드 플랫폼의 정보 보안 모니터링 기능이 어떻게 다른지, 그리고 보안 관점에서 핵심 프로세스를 클라우드로 이전할 때 주의해야 할 사항에 대해 설명하고 싶습니다. 글쎄요, 러시아의 클라우드 솔루션 개발자 중 일부가 스스로 유용한 것을 배운다면 그것은 좋을 것입니다.

가장 먼저 말해야 할 것은 아마존은 뚫을 수 없는 요새가 아니라는 것이다. 그의 고객에게는 다양한 사건이 정기적으로 발생합니다. 예를 들어 Deep Root Analytics에서는 198억 14만 명의 유권자의 이름, 주소, 생년월일, 전화번호가 도난당했습니다. 이스라엘 회사인 Nice Systems는 Verizon 가입자의 XNUMX만 건의 기록을 훔쳤습니다. 그러나 AWS에 내장된 기능을 사용하면 광범위한 사고를 감지할 수 있습니다. 예를 들어:

• 인프라에 미치는 영향(DDoS)
• 노드 손상(명령어 주입)
• 계정 도용 및 무단 액세스
• 잘못된 구성 및 취약점
• 안전하지 않은 인터페이스와 API.

이러한 불일치는 위에서 살펴본 바와 같이 고객 데이터의 보안에 대한 책임은 고객 자신에게 있다는 사실에 기인합니다. 그리고 그가 보호 메커니즘을 켜는 데 신경 쓰지 않고 모니터링 도구를 켜지 않은 경우 그는 언론이나 고객에게서만 사건에 대해 알게 될 것입니다.

사고를 식별하기 위해 Amazon에서 개발한 다양한 모니터링 서비스를 사용할 수 있습니다(물론 osquery와 같은 외부 도구로 보완되는 경우도 있음). 따라서 AWS에서는 관리 콘솔, 명령줄, SDK 또는 기타 AWS 서비스를 통해 수행되는 방식에 관계없이 모든 사용자 작업이 모니터링됩니다. 각 AWS 계정의 활동(사용자 이름, 작업, 서비스, 활동 매개변수 및 결과 포함) 및 API 사용에 대한 모든 기록은 AWS CloudTrail을 통해 확인할 수 있습니다. CloudTrail 콘솔에서 이러한 이벤트(예: AWS IAM 콘솔 로그인)를 보고, Amazon Athena를 사용하여 분석하거나, Splunk, AlienVault 등과 같은 외부 솔루션으로 "아웃소싱"할 수 있습니다. AWS CloudTrail 로그 자체는 AWS S3 버킷에 저장됩니다.

다른 두 가지 AWS 서비스는 여러 가지 중요한 모니터링 기능을 제공합니다. 첫째, Amazon CloudWatch는 무엇보다도 클라우드의 다양한 이상 현상을 식별할 수 있는 AWS 리소스 및 애플리케이션에 대한 모니터링 서비스입니다. Amazon Elastic Compute Cloud(서버), Amazon Relational Database Service(데이터베이스), Amazon Elastic MapReduce(데이터 분석) 및 30개의 기타 Amazon 서비스와 같은 모든 내장 AWS 서비스는 Amazon CloudWatch를 사용하여 로그를 저장합니다. 개발자는 Amazon CloudWatch의 개방형 API를 사용하여 사용자 지정 애플리케이션 및 서비스에 로그 모니터링 기능을 추가함으로써 보안 컨텍스트 내에서 이벤트 분석 범위를 확장할 수 있습니다.

둘째, VPC 흐름 로그 서비스를 사용하면 AWS 서버(외부 또는 내부)는 물론 마이크로서비스 간에 주고받는 네트워크 트래픽을 분석할 수 있습니다. AWS VPC 리소스가 네트워크와 상호 작용할 때 VPC 흐름 로그는 원본 및 대상 네트워크 인터페이스는 물론 IP 주소, 포트, 프로토콜, 바이트 수, 패킷 수 등 네트워크 트래픽에 대한 세부 정보를 기록합니다. 봤다. 로컬 네트워크 보안 경험이 있는 사람들은 이것을 스레드와 유사하다고 인식할 것입니다. 넷플로우, 스위치, 라우터 및 엔터프라이즈급 방화벽에 의해 생성될 수 있습니다. 이러한 로그는 사용자 및 애플리케이션의 작업에 대한 이벤트와 달리 AWS Virtual Private Cloud 환경에서 네트워크 상호 작용을 놓치지 않도록 하기 때문에 정보 보안 모니터링 목적에 중요합니다.

요약하자면, AWS CloudTrail, Amazon CloudWatch 및 VPC Flow Logs라는 세 가지 AWS 서비스는 함께 계정 사용, 사용자 행동, 인프라 관리, 애플리케이션 및 서비스 활동, 네트워크 활동에 대한 매우 강력한 통찰력을 제공합니다. 예를 들어 다음과 같은 이상 현상을 감지하는 데 사용할 수 있습니다.

• 사이트 검색, 백도어 검색, "404 오류" 급증을 통한 취약점 검색을 시도합니다.
• “500 오류”의 폭발을 통한 주입 공격(예: SQL 주입)입니다.
• 알려진 공격 도구로는 sqlmap, nikto, w3af, nmap 등이 있습니다. 사용자 에이전트 필드 분석을 통해.

Amazon Web Services는 또한 사이버 보안을 위해 다른 많은 문제를 해결할 수 있는 다른 서비스도 개발했습니다. 예를 들어, AWS에는 정책 및 구성 감사를 위한 내장 서비스인 AWS Config가 있습니다. 이 서비스는 AWS 리소스와 해당 구성에 대한 지속적인 감사를 제공합니다. 간단한 예를 들어보겠습니다. 모든 서버에서 사용자 비밀번호를 비활성화하고 인증서를 통해서만 액세스가 가능하도록 하고 싶다고 가정해 보겠습니다. AWS Config를 사용하면 모든 서버에 대해 이를 쉽게 확인할 수 있습니다. 클라우드 서버에 적용할 수 있는 다른 정책이 있습니다. "어떤 서버도 포트 22를 사용할 수 없습니다.", "관리자만 방화벽 규칙을 변경할 수 있습니다." 또는 "사용자 Ivashko만이 새 사용자 계정을 만들 수 있으며, 그는 화요일에만 이를 수행할 수 있습니다. " 2016년 여름에는 AWS Config 서비스가 확장되어 개발된 정책 위반 탐지를 자동화했습니다. AWS Config 규칙은 본질적으로 귀하가 사용하는 Amazon 서비스에 대한 지속적인 구성 요청으로, 해당 정책이 위반될 경우 이벤트를 생성합니다. 예를 들어, 가상 서버의 모든 디스크가 암호화되었는지 확인하기 위해 주기적으로 AWS Config 쿼리를 실행하는 대신, AWS Config 규칙을 사용하면 서버 디스크를 지속적으로 확인하여 이 조건이 충족되는지 확인할 수 있습니다. 그리고 가장 중요한 점은 이 발행물의 맥락에서 위반이 발생하면 정보 보안 서비스에서 분석할 수 있는 이벤트가 생성된다는 것입니다.

AWS에는 또한 분석할 수 있고 분석해야 하는 보안 이벤트를 생성하는 기존 기업 정보 보안 솔루션과 동등한 기능도 있습니다.

• 침입 탐지 - AWS GuardDuty
• 정보 유출 제어 - AWS Macie
• EDR(클라우드의 엔드포인트에 대해 조금 이상하게 이야기하지만) - AWS Cloudwatch + 오픈 소스 Osquery 또는 GRR 솔루션
• Netflow 분석 - AWS Cloudwatch + AWS VPC 흐름
• DNS 분석 - AWS Cloudwatch + AWS Route53
• AD - AWS 디렉터리 서비스
• 계정 관리 - AWS IAM
• SSO-AWS SSO
• 보안 분석 - AWS Inspector
• 구성 관리 - AWS Config
• WAF-AWS WAF.

정보 보안 측면에서 유용할 수 있는 모든 Amazon 서비스를 자세히 설명하지는 않습니다. 가장 중요한 것은 Amazon 자체의 내장 기능과 외부 솔루션(예: SIEM)을 모두 사용하여 정보 보안의 맥락에서 분석할 수 있고 분석해야 하는 이벤트를 생성할 수 있다는 점을 이해하는 것입니다. 보안 이벤트를 모니터링 센터로 가져가서 다른 클라우드 서비스나 내부 인프라, 경계 또는 모바일 장치의 이벤트와 함께 분석하세요.

어쨌든 모든 것은 정보 보안 이벤트를 제공하는 데이터 소스에서 시작됩니다. 이러한 소스에는 다음이 포함되지만 이에 국한되지는 않습니다.

• CloudTrail - API 사용 및 사용자 작업
• Trusted Advisor - 모범 사례에 대한 보안 점검
• 구성 - 계정 및 서비스 설정의 인벤토리 및 구성
• VPC 흐름 로그 - 가상 인터페이스에 대한 연결
• IAM - 식별 및 인증 서비스
• ELB 액세스 로그 - 로드 밸런서
• 검사기 - 애플리케이션 취약점
• S3 - 파일 저장
• CloudWatch - 애플리케이션 활동
• SNS는 알림 서비스입니다.

Amazon은 생성을 위한 다양한 이벤트 소스와 도구를 제공하지만 정보 보안의 맥락에서 수집된 데이터를 분석하는 능력은 매우 제한적입니다. 사용 가능한 로그를 독립적으로 연구하여 관련 손상 지표를 찾아야 합니다. Amazon이 최근 출시한 AWS Security Hub는 AWS용 클라우드 SIEM이 되어 이 문제를 해결하는 것을 목표로 합니다. 그러나 지금까지는 여정의 시작 단계에 불과하며 작동하는 소스의 수와 Amazon 자체의 아키텍처 및 구독에 의해 설정된 기타 제한 사항에 의해 제한됩니다.

예시: Azure 기반 IaaS의 정보 보안 모니터링

저는 세 가지 클라우드 제공업체(Amazon, Microsoft 또는 Google) 중 어느 것이 더 나은지에 대해 긴 논쟁을 벌이고 싶지 않습니다. 특히 각 제공업체는 여전히 고유한 세부 사항을 갖고 있으며 자체 문제를 해결하는 데 적합하기 때문입니다. 이러한 플레이어가 제공하는 정보 보안 모니터링 기능에 중점을 두겠습니다. Amazon AWS는 이 부문의 첫 번째 제품 중 하나이므로 정보 보안 기능 측면에서 가장 발전했다는 점을 인정해야 합니다(많은 사람들이 사용하기 어렵다는 점을 인정하지만). 그러나 이것이 Microsoft와 Google이 우리에게 제공하는 기회를 무시한다는 의미는 아닙니다.

Microsoft 제품은 항상 "개방성"으로 구별되었으며 Azure에서도 상황은 비슷합니다. 예를 들어 AWS와 GCP가 항상 "허용되지 않는 것은 금지된다"는 개념에서 진행한다면 Azure는 정반대의 접근 방식을 취합니다. 예를 들어 클라우드에 가상 네트워크를 생성하고 그 안에 가상 머신을 생성하면 기본적으로 모든 포트와 프로토콜이 열려 있고 허용됩니다. 따라서 Microsoft의 클라우드에서 액세스 제어 시스템의 초기 설정에 좀 더 노력을 기울여야 합니다. 또한 이는 Azure 클라우드의 활동 모니터링 측면에서 더욱 엄격한 요구 사항을 부과합니다.

AWS에는 가상 리소스를 모니터링할 때 가상 리소스가 다른 지역에 있는 경우 모든 이벤트와 통합 분석을 결합하는 데 어려움이 있으므로 이를 제거하기 위해 다음과 같은 다양한 트릭을 사용해야 한다는 특징이 있습니다. 지역 간에 이벤트를 전송할 AWS Lambda용 코드를 직접 생성하세요. Azure에는 이 문제가 없습니다. 활동 로그 메커니즘은 제한 없이 전체 조직의 모든 활동을 추적합니다. Amazon이 최근 단일 보안 센터 내에서 많은 보안 기능을 통합하기 위해 개발한 AWS Security Hub에도 동일하게 적용되지만 해당 지역 내에서만 가능하며 이는 러시아와 관련이 없습니다. Azure에는 지역 제한에 구애받지 않는 자체 보안 센터가 있어 클라우드 플랫폼의 모든 보안 기능에 대한 액세스를 제공합니다. 또한 다양한 로컬 팀에 대해 관리되는 보안 이벤트를 포함하여 자체 보호 기능 세트를 제공할 수 있습니다. AWS Security Hub는 여전히 Azure Security Center와 유사해지는 과정에 있습니다. 그러나 연고에 파리를 추가하는 것은 가치가 있습니다. 이전에 AWS에서 설명한 많은 내용을 Azure에서 짜낼 수 있지만 이는 Azure AD, Azure Monitor 및 Azure Security Center에 대해서만 가장 편리하게 수행됩니다. 보안 이벤트 분석을 포함한 다른 모든 Azure 보안 메커니즘은 아직 가장 편리한 방식으로 관리되지 않습니다. 문제는 모든 Microsoft Azure 서비스에 스며드는 API에 의해 부분적으로 해결되지만, 이를 위해서는 클라우드를 SOC 및 자격을 갖춘 전문가의 존재와 통합하기 위한 추가 노력이 필요합니다(실제로 함께 작동하는 다른 SIEM과 마찬가지로). 클라우드 API). 나중에 설명할 일부 SIEM은 이미 Azure를 지원하고 모니터링 작업을 자동화할 수 있지만 자체적인 어려움도 있습니다. 모든 SIEM이 Azure에 있는 모든 로그를 수집할 수는 없습니다.

Azure의 이벤트 수집 및 모니터링은 Microsoft 클라우드 및 해당 리소스(Git 리포지토리, 컨테이너, 가상 머신, 애플리케이션 등)에서 데이터를 수집, 저장 및 분석하기 위한 기본 도구인 Azure Monitor 서비스를 사용하여 제공됩니다. Azure Monitor에서 수집한 모든 데이터는 실시간으로 수집되어 Azure 클라우드의 핵심 성과 지표를 설명하는 메트릭과 Azure 리소스 및 서비스 활동의 특정 측면을 특성화하는 기록으로 구성된 데이터가 포함된 로그라는 두 가지 범주로 나뉩니다. 또한 Azure Monitor 서비스는 데이터 수집기 ​​API를 사용하여 모든 REST 소스에서 데이터를 수집하여 자체 모니터링 시나리오를 구축할 수 있습니다.

다음은 Azure에서 제공하고 Azure Portal, CLI, PowerShell 또는 REST API를 통해 액세스할 수 있는 몇 가지 보안 이벤트 소스입니다(일부는 Azure Monitor/Insight API를 통해서만 가능).

• 활동 로그 - 이 로그는 클라우드 리소스에 대한 쓰기 작업(PUT, POST, DELETE)과 관련하여 "누가", "무엇을", "언제"에 대한 일반적인 질문에 답변합니다. 읽기 액세스(GET)와 관련된 이벤트는 다른 이벤트와 마찬가지로 이 로그에 포함되지 않습니다.
• 진단 로그 - 구독에 포함된 특정 리소스를 사용한 작업에 대한 데이터가 포함되어 있습니다.
• Azure AD 보고 - 그룹 및 사용자 관리와 관련된 사용자 활동과 시스템 활동이 모두 포함됩니다.
• Windows 이벤트 로그 및 Linux Syslog - 클라우드에서 호스팅되는 가상 머신의 이벤트를 포함합니다.
• 지표 - 클라우드 서비스 및 리소스의 성능과 상태에 대한 원격 분석이 포함되어 있습니다. 30분마다 측정되어 저장됩니다. XNUMX일 이내.
• 네트워크 보안 그룹 흐름 로그 - Network Watcher 서비스 및 네트워크 수준의 리소스 모니터링을 사용하여 수집된 네트워크 보안 이벤트에 대한 데이터가 포함되어 있습니다.
• 저장소 로그 - 저장소 시설 접근과 관련된 이벤트가 포함되어 있습니다.

모니터링을 위해 외부 SIEM 또는 기본 제공 Azure Monitor 및 해당 확장을 사용할 수 있습니다. 정보 보안 이벤트 관리 시스템에 대해서는 나중에 설명하겠지만 지금은 보안 측면에서 데이터 분석을 위해 Azure 자체가 무엇을 제공하는지 살펴보겠습니다. Azure Monitor의 모든 보안 관련 기본 화면은 Log Analytics 보안 및 감사 대시보드입니다(무료 버전은 단 5주일 동안 제한된 양의 이벤트 저장소를 지원합니다). 이 대시보드는 사용 중인 클라우드 환경에서 발생하는 상황에 대한 요약 통계를 시각화하는 XNUMX개의 주요 영역으로 구분됩니다.

• 보안 도메인 - 정보 보안과 관련된 주요 정량 지표 - 사고 수, 손상된 노드 수, 패치되지 않은 노드, 네트워크 보안 이벤트 등
• 주목할만한 문제 - 활성 정보 보안 문제의 수와 중요성을 표시합니다.
• 탐지 - 귀하에게 사용된 공격 패턴을 표시합니다.
• 위협 인텔리전스 - 사용자를 공격하는 외부 노드에 대한 지리적 정보를 표시합니다.
• 일반 보안 쿼리 - 정보 보안을 더 잘 모니터링하는 데 도움이 되는 일반적인 쿼리입니다.

Azure Monitor 확장에는 Azure Key Vault(클라우드의 암호화 키 보호), 맬웨어 평가(가상 머신의 악성 코드에 대한 보호 분석), Azure Application Gateway 분석(클라우드 방화벽 로그 분석) 등이 포함됩니다. . 이벤트 처리를 위한 특정 규칙이 강화된 이러한 도구를 사용하면 보안을 포함하여 클라우드 서비스 활동의 다양한 측면을 시각화하고 운영의 특정 편차를 식별할 수 있습니다. 그러나 종종 발생하는 것처럼 추가 기능을 사용하려면 해당 유료 구독이 필요하며, 이를 위해서는 해당 금융 투자가 필요하며 사전 계획이 필요합니다.

Azure에는 Azure AD, Azure Monitor 및 Azure Security Center에 통합된 다양한 기본 제공 위협 모니터링 기능이 있습니다. 그 중에는 예를 들어 알려진 악성 IP와 가상 머신의 상호 작용 탐지(Microsoft의 위협 인텔리전스 서비스와의 통합으로 인해), 클라우드에 호스팅된 가상 머신으로부터 경보를 수신하여 클라우드 인프라에서 악성 코드 탐지, 비밀번호 가상 머신에 대한 공격 추측, 사용자 식별 시스템 구성의 취약점, 익명화 또는 감염된 노드에서 시스템에 로그인, 계정 유출, 비정상적인 위치에서 시스템에 로그인 등. 현재 Azure는 수집된 정보 보안 이벤트를 강화하기 위해 기본 제공 위협 인텔리전스 기능을 제공하는 몇 안 되는 클라우드 공급자 중 하나입니다.

위에서 언급한 것처럼 보안 기능과 그에 따라 생성된 보안 이벤트는 모든 사용자가 동일하게 사용할 수 없지만 정보 보안 모니터링을 위한 적절한 이벤트를 생성하는 필요한 기능을 포함하는 특정 구독이 필요합니다. 예를 들어 계정의 이상 현상을 모니터링하기 위해 이전 단락에서 설명한 기능 중 일부는 Azure AD 서비스에 대한 P2 프리미엄 라이선스에서만 사용할 수 있습니다. 이것이 없으면 AWS의 경우처럼 수집된 보안 이벤트를 "수동으로" 분석해야 합니다. 또한 Azure AD 라이선스 유형에 따라 모든 이벤트를 분석에 사용할 수 있는 것은 아닙니다.

Azure Portal에서는 관심 있는 로그에 대한 검색 쿼리를 관리하고 대시보드를 설정하여 주요 정보 보안 지표를 시각화할 수 있습니다. 또한 Azure Monitor 로그의 기능을 확장하고 보안 관점에서 이벤트를 더 심층적으로 분석할 수 있는 Azure Monitor 확장을 선택할 수 있습니다.

로그 작업 기능뿐만 아니라 정보 보안 정책 관리를 포함하여 Azure 클라우드 플랫폼에 대한 포괄적인 보안 센터가 필요한 경우 대부분의 유용한 기능을 제공하는 Azure Security Center를 사용해야 한다고 말할 수 있습니다. 위협 감지, Azure 외부 모니터링, 규정 준수 평가 등의 비용을 지불하고 사용할 수 있습니다. (무료 버전에서는 식별된 문제를 제거하기 위한 보안 평가 및 권장 사항에만 액세스할 수 있습니다.) 모든 보안 문제를 한 곳에 통합합니다. 실제로 Azure Monitor가 제공하는 것보다 더 높은 수준의 정보 보안에 대해 이야기할 수 있습니다. 이 경우 클라우드 팩토리 전체에서 수집된 데이터는 Azure, Office 365, Microsoft CRM 온라인, Microsoft Dynamics AX와 같은 다양한 소스를 사용하여 강화되기 때문입니다. , outlook .com, MSN.com, Microsoft DCU(Digital Crimes Unit) 및 MSRC(Microsoft Security Response Center)에 다양하고 정교한 기계 학습 및 행동 분석 알고리즘이 중첩되어 궁극적으로 위협 탐지 및 대응의 효율성을 향상시켜야 합니다. .

Azure에는 자체 SIEM도 있으며 2019년 초에 등장했습니다. 이는 Azure Monitor의 데이터를 사용하고 통합할 수도 있는 Azure Sentinel입니다. 외부 보안 솔루션(예: NGFW 또는 WAF), 그 목록은 지속적으로 증가하고 있습니다. 또한 Microsoft Graph Security API의 통합을 통해 자신의 위협 인텔리전스 피드를 Sentinel에 연결할 수 있어 Azure 클라우드에서 사고를 분석하는 기능이 강화됩니다. Azure Sentinel은 클라우드 공급자가 제공한 최초의 "네이티브" SIEM이라고 주장할 수 있습니다(예를 들어 AWS와 같이 클라우드에서 호스팅할 수 있는 동일한 Splunk 또는 ELK는 기존 클라우드 서비스 공급자가 아직 개발하지 않았습니다). Azure Sentinel 및 Security Center는 Azure 클라우드에 대한 SOC라고 할 수 있으며 더 이상 인프라가 없고 모든 컴퓨팅 리소스를 클라우드로 전송한 경우 Microsoft 클라우드 Azure가 될 경우 SOC(특정 예약 포함)로 제한될 수 있습니다.

그러나 Azure의 기본 제공 기능(Sentinel을 구독하더라도)은 정보 보안을 모니터링하고 이 프로세스를 다른 보안 이벤트 소스(클라우드 및 내부 모두)와 통합하는 데 충분하지 않은 경우가 많습니다. 수집된 데이터를 SIEM을 포함할 수 있는 외부 시스템으로 내보내야 합니다. 이는 API와 현재 Splunk(Splunk용 Azure Monitor 추가 기능), IBM QRadar(Microsoft Azure DSM), SumoLogic, ArcSight 및 ELK와 같은 SIEM에서만 공식적으로 사용할 수 있는 특수 확장을 사용하여 수행됩니다. 최근까지 이러한 SIEM이 더 많았지만 1년 2019월 XNUMX일부터 Microsoft는 Azure 존재 초기에 로그 작업에 대한 일반적인 표준화가 이루어지지 않은 상태에서 Azure 로그 통합 도구(AzLog) 지원을 중단했습니다(Azure 아직 모니터가 존재하지도 않았음)을 사용하면 외부 SIEM을 Microsoft 클라우드와 쉽게 통합할 수 있습니다. 이제 상황이 바뀌었고 Microsoft는 Azure Event Hub 플랫폼을 다른 SIEM의 기본 통합 도구로 권장합니다. 많은 사람들이 이미 이러한 통합을 구현했지만 주의해야 합니다. 모든 Azure 로그를 캡처하지 않고 일부만 캡처할 수도 있습니다(SIEM 설명서 참조).

Azure에 대한 간략한 소개를 마무리하면서 이 클라우드 서비스에 대한 일반적인 권장 사항을 제시하고 싶습니다. Azure의 정보 보안 모니터링 기능에 대해 언급하기 전에 해당 기능을 매우 신중하게 구성하고 문서에 작성된 대로 작동하는지 테스트해야 합니다. 컨설턴트가 Microsoft에 말했듯이(Azure 기능의 기능에 대해 서로 다른 견해를 가질 수 있음) 재정적 자원이 있다면 정보 보안 모니터링 측면에서 Azure에서 유용한 정보를 많이 짜낼 수 있습니다. 리소스가 제한되어 있는 경우 AWS의 경우처럼 자신의 강점과 Azure Monitor가 제공하는 원시 데이터에만 의존해야 합니다. 그리고 많은 모니터링 기능에는 비용이 들기 때문에 가격 정책을 미리 숙지하는 것이 좋습니다. 예를 들어, 고객당 최대 31GB까지 5일간의 데이터를 무료로 저장할 수 있습니다. 이 값을 초과하면 추가 비용을 지불해야 합니다(고객으로부터 각 추가 GB를 저장하는 데 약 $2+, 추가로 매달 0,1GB를 저장합니다.) 애플리케이션 원격 측정 및 지표 작업에는 추가 자금이 필요할 수도 있고 경고 및 알림 작업도 필요할 수 있습니다(특정 한도는 무료로 제공되지만 이는 요구 사항에 충분하지 않을 수 있음).

예시: Google Cloud Platform 기반 IaaS의 정보 보안 모니터링

Google Cloud Platform은 AWS 및 Azure에 비해 젊어 보이지만 부분적으로 좋습니다. 보안 기능을 포함한 기능을 점진적으로 향상시킨 AWS와 달리 중앙 집중화에 문제가 있습니다. Azure와 마찬가지로 GCP는 중앙에서 훨씬 효과적으로 관리되므로 기업 전체에서 오류와 구현 시간이 줄어듭니다. 보안 관점에서 GCP는 이상하게도 AWS와 Azure 사이에 있습니다. 또한 전체 조직에 대한 단일 이벤트 등록이 있지만 불완전합니다. 일부 기능은 아직 베타 모드이지만, 점차적으로 이러한 결함이 제거되어야 하며 GCP는 정보 보안 모니터링 측면에서 더욱 성숙한 플랫폼이 될 것입니다.

GCP에서 이벤트를 로깅하는 주요 도구는 Stackdriver Logging(Azure Monitor와 유사)으로, 이를 통해 전체 클라우드 인프라(및 AWS)에서 이벤트를 수집할 수 있습니다. GCP의 보안 관점에서 각 조직, 프로젝트 또는 폴더에는 XNUMX개의 로그가 있습니다.

• 관리자 활동 - 가상 머신 생성, 액세스 권한 변경 등 관리 액세스와 관련된 모든 이벤트가 포함됩니다. 이 로그는 사용자의 의사와 상관없이 항상 기록되며 해당 데이터를 400일 동안 저장합니다.
• 데이터 액세스 - 클라우드 사용자의 데이터 작업(생성, 수정, 읽기 등)과 관련된 모든 이벤트가 포함됩니다. 기본적으로 이 로그는 볼륨이 매우 빠르게 증가하므로 기록되지 않습니다. 이러한 이유로 유통기한은 30일에 불과합니다. 게다가 이 잡지에 모든 내용이 실려 있는 것은 아닙니다. 예를 들어, 모든 사용자가 공개적으로 액세스할 수 있거나 GCP에 로그인하지 않고 액세스할 수 있는 리소스와 관련된 이벤트는 여기에 기록되지 않습니다.
• 시스템 이벤트 - 사용자와 관련되지 않은 시스템 이벤트 또는 클라우드 리소스 구성을 변경하는 관리자의 작업이 포함됩니다. 항상 작성되어 400일 동안 보관됩니다.
• 액세스 투명성은 직무의 일환으로 인프라에 액세스하는 Google 직원(아직 모든 GCP 서비스는 아님)의 모든 활동을 캡처하는 로그의 고유한 예입니다. 이 로그는 400일 동안 저장되며 모든 GCP 클라이언트에서 사용할 수는 없지만 여러 조건(골드 또는 플래티넘 수준 지원 또는 기업 지원의 일부로 특정 유형의 4가지 역할 존재)이 충족되는 경우에만 사용할 수 있습니다. 예를 들어 Office 365 - Lockbox에서도 유사한 기능을 사용할 수 있습니다.

로그 예: 액세스 투명성

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

이러한 로그에 대한 액세스는 로그 뷰어 인터페이스, API, Google Cloud SDK 또는 프로젝트의 활동 페이지를 통해 여러 가지 방법(이전에 설명한 Azure 및 AWS와 거의 동일한 방식)으로 가능합니다. 이벤트에 관심이 있습니다. 동일한 방식으로 추가 분석을 위해 외부 솔루션으로 내보낼 수도 있습니다. 후자는 BigQuery 또는 Cloud Pub/Sub 스토리지로 로그를 내보내는 방식으로 수행됩니다.

Stackdriver Logging 외에도 GCP 플랫폼은 클라우드 서비스 및 애플리케이션의 주요 측정항목(성능, MTBF, 전체 상태 등)을 모니터링할 수 있는 Stackdriver Monitoring 기능도 제공합니다. 처리되고 시각화된 데이터를 사용하면 보안 측면을 포함하여 클라우드 인프라에서 문제를 더 쉽게 찾을 수 있습니다. 그러나 현재 GCP에는 동일한 AWS GuardDuty와 유사한 기능이 없고 등록된 모든 이벤트 중에서 잘못된 이벤트를 식별할 수 없기 때문에 이 기능은 정보 보안 측면에서 그다지 풍부하지 않을 것이라는 점에 유의해야 합니다(Google은 Event Threat Protection, 하지만 아직 베타 버전으로 개발 중이어서 유용성을 논하기에는 너무 이릅니다. Stackdriver Monitoring은 이상 현상을 감지하는 시스템으로 사용될 수 있으며, 이를 조사하여 발생 원인을 찾을 수 있습니다. 그러나 시장에는 GCP 정보보안 분야의 자격을 갖춘 인력이 부족하여 현재 이 작업은 어려워 보입니다.

GCP 클라우드 내에서 사용할 수 있고 AWS가 제공하는 것과 유사한 일부 정보 보안 모듈 목록을 제공하는 것도 가치가 있습니다.

• Cloud Security Command Center는 AWS Security Hub 및 Azure Security Center와 유사합니다.
• Cloud DLP - 90개 이상의 사전 정의된 분류 정책을 사용하여 클라우드에 호스팅된 데이터를 자동으로 검색하고 편집(예: 마스킹)합니다.
• Cloud Scanner는 App Engine, Compute Engine, Google Kubernetes의 알려진 취약점(XSS, 플래시 삽입, 패치되지 않은 라이브러리 등)에 대한 스캐너입니다.
• Cloud IAM - 모든 GCP 리소스에 대한 액세스를 제어합니다.
• Cloud ID - 단일 콘솔에서 GCP 사용자, 기기, 애플리케이션 계정을 관리합니다.
• Cloud HSM - 암호화 키 보호.
• 클라우드 키 관리 서비스 - GCP의 암호화 키 관리.
• VPC 서비스 제어 - GCP 리소스 주위에 보안 경계를 생성하여 누출로부터 보호합니다.
• Titan 보안 키 - 피싱으로부터 보호합니다.

이러한 모듈 중 다수는 분석을 위해 BigQuery 스토리지로 전송하거나 SIEM을 포함한 다른 시스템으로 내보낼 수 있는 보안 이벤트를 생성합니다. 위에서 언급했듯이 GCP는 활발하게 개발 중인 플랫폼이며 Google은 현재 해당 플랫폼을 위한 여러 가지 새로운 정보 보안 모듈을 개발하고 있습니다. 그 중에는 무단 활동의 흔적을 찾기 위해 Stackdriver 로그를 검사하는 Event ThreatDetection(현재 베타 버전으로 제공)(AWS의 GuardDuty와 유사) 또는 다음과 같은 지능형 정책을 개발할 수 있는 Policy Intelligence(알파로 제공)가 있습니다. GCP 리소스에 대한 액세스.

널리 사용되는 클라우드 플랫폼에 내장된 모니터링 기능에 대해 간략하게 살펴보았습니다. 하지만 "원시" IaaS 제공업체 로그로 작업할 수 있는 전문가가 있습니까(모든 사람이 AWS, Azure 또는 Google의 고급 기능을 구매할 준비가 되어 있는 것은 아닙니다)? 또한 많은 사람들은 보안 분야에서 그 어느 때보다 사실인 "신뢰하되 검증하라"는 격언을 잘 알고 있습니다. 정보 보안 이벤트를 전송하는 클라우드 제공업체의 내장 기능을 얼마나 신뢰하시나요? 그들은 정보 보안에 얼마나 집중하고 있나요?

내장된 클라우드 보안을 보완할 수 있는 오버레이 클라우드 인프라 모니터링 솔루션을 살펴볼 가치가 있는 경우도 있고, 이러한 솔루션이 클라우드에서 호스팅되는 데이터 및 애플리케이션의 보안에 대한 통찰력을 얻을 수 있는 유일한 옵션인 경우도 있습니다. 또한 다양한 클라우드 제공업체의 다양한 클라우드 서비스에서 생성된 필요한 로그를 분석하는 모든 작업을 수행하기 때문에 더 편리합니다. 이러한 오버레이 솔루션의 예로 Cisco Stealthwatch Cloud가 있습니다. 이는 Amazon AWS, Microsoft Azure, Google Cloud Platform뿐만 아니라 프라이빗 클라우드를 포함한 클라우드 환경에서 정보 보안 이상 현상을 모니터링하는 단일 작업에 중점을 둡니다.

예: Stealthwatch Cloud를 사용한 정보 보안 모니터링

AWS는 유연한 컴퓨팅 플랫폼을 제공하지만 이러한 유연성으로 인해 기업은 보안 문제로 이어지는 실수를 더 쉽게 할 수 있습니다. 그리고 공유 정보 보안 모델은 이것에만 기여합니다. 알 수 없는 취약점(예를 들어 AWS Inspector 또는 GCP Cloud Scanner를 사용하여 알려진 취약점을 퇴치할 수 있음), 취약한 비밀번호, 잘못된 구성, 내부자 등이 있는 소프트웨어를 클라우드에서 실행합니다. 그리고 이 모든 것은 정보 보안 모니터링 및 공격 탐지 시스템인 Cisco Stealthwatch Cloud에서 모니터링할 수 있는 클라우드 리소스의 동작에 반영됩니다. 퍼블릭 클라우드와 프라이빗 클라우드.

Cisco Stealthwatch Cloud의 주요 기능 중 하나는 엔터티를 모델링하는 기능입니다. 이를 통해 각 클라우드 리소스(AWS, Azure, GCP 등인지는 중요하지 않음)에 대한 소프트웨어 모델(즉, 거의 실시간 시뮬레이션)을 생성할 수 있습니다. 여기에는 서버와 사용자는 물론 보안 그룹, 자동 크기 조정 그룹 등 클라우드 환경에 특정한 리소스 유형이 포함될 수 있습니다. 이러한 모델은 클라우드 서비스에서 제공하는 구조화된 데이터 스트림을 입력으로 사용합니다. 예를 들어 AWS의 경우 이는 VPC 흐름 로그, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda 및 AWS IAM입니다. 엔터티 모델링은 모든 리소스의 역할과 동작을 자동으로 검색합니다(모든 클라우드 활동을 프로파일링하는 것에 대해 이야기할 수 있음). 이러한 역할에는 Android 또는 Apple 모바일 장치, Citrix PVS 서버, RDP 서버, 메일 게이트웨이, VoIP 클라이언트, 터미널 서버, 도메인 컨트롤러 등이 포함됩니다. 그런 다음 위험하거나 안전을 위협하는 행동이 언제 발생하는지 판단하기 위해 지속적으로 행동을 모니터링합니다. 비밀번호 추측, DDoS 공격, 데이터 유출, 불법 원격 액세스, 악성 코드 활동, 취약점 검색 및 기타 위협을 식별할 수 있습니다. 예를 들어 SSH를 통해 조직에 일반적이지 않은 국가(대한민국)에서 Kubernetes 클러스터에 대한 원격 액세스 시도를 감지하는 방법은 다음과 같습니다.

그리고 이것은 Postgress 데이터베이스에서 우리가 이전에 상호 작용을 경험하지 못한 국가로 정보가 유출되었다고 주장되는 내용입니다.

마지막으로, 중국과 인도네시아에서 외부 원격 장치를 통한 SSH 시도 실패가 너무 많이 발생하는 모습은 다음과 같습니다.

또는 정책에 따라 VPC의 서버 인스턴스가 원격 로그인 대상이 될 수 없다고 가정해 보겠습니다. 방화벽 규칙 정책의 잘못된 변경으로 인해 이 컴퓨터에 원격 로그온이 발생했다고 가정해 보겠습니다. 엔터티 모델링 기능은 이 활동(“비정상적인 원격 액세스”)을 거의 실시간으로 감지하고 보고하며 특정 AWS CloudTrail, Azure Monitor 또는 GCP Stackdriver Logging API 호출(사용자 이름, 날짜 및 시간 등의 세부 정보 포함)을 가리킵니다. ). 이로 인해 ITU 규칙이 변경되었습니다. 그런 다음 이 정보는 분석을 위해 SIEM으로 전송될 수 있습니다.

Cisco Stealthwatch Cloud가 지원하는 모든 클라우드 환경에 대해 유사한 기능이 구현됩니다.

엔터티 모델링은 인력, 프로세스 또는 기술과 관련하여 이전에 알려지지 않은 문제를 찾아낼 수 있는 독특한 형태의 보안 자동화입니다. 예를 들어, 다음과 같은 보안 문제를 감지할 수 있습니다.

• 누군가 우리가 사용하는 소프트웨어에서 백도어를 발견했나요?
• 클라우드에 타사 소프트웨어나 장치가 있습니까?
• 승인된 사용자가 권한을 남용하고 있습니까?
• 원격 액세스나 기타 의도하지 않은 리소스 사용을 허용하는 구성 오류가 있었나요?
• 우리 서버에서 데이터 유출이 있나요?
• 누군가가 일반적이지 않은 지리적 위치에서 우리에게 연결을 시도했습니까?
• 우리 클라우드가 악성코드에 감염됐나요?

감지된 정보 보안 이벤트는 해당 티켓 형태로 Slack, Cisco Spark, PagerDuty 사고 관리 시스템으로 전송될 수 있으며 Splunk 또는 ELK를 포함한 다양한 SIEM으로도 전송될 수 있습니다. 요약하자면, 회사가 멀티 클라우드 전략을 사용하고 하나의 클라우드 제공업체에만 국한되지 않고 위에서 설명한 정보 보안 모니터링 기능을 사용하는 경우 Cisco Stealthwatch Cloud를 사용하는 것이 통합 모니터링 세트를 얻는 좋은 옵션이라고 말할 수 있습니다. Amazon, Microsoft, Google 등 선도적인 클라우드 플레이어를 위한 기능입니다. 가장 흥미로운 점은 Stealthwatch Cloud의 가격을 AWS, Azure 또는 GCP의 정보 보안 모니터링을 위한 고급 라이선스와 비교하면 Cisco 솔루션이 Amazon, Microsoft의 내장 기능보다 훨씬 저렴할 수 있다는 것입니다. 그리고 Google 솔루션. 역설적이지만 사실입니다. 그리고 더 많은 클라우드와 그 기능을 사용할수록 통합 솔루션의 이점은 더욱 분명해집니다.

또한 Stealthwatch Cloud는 예를 들어 Kubernetes 컨테이너를 기반으로 조직에 배포된 프라이빗 클라우드를 모니터링하거나 네트워크 장비(국산 포함), AD 데이터 또는 DNS 서버 등의 미러링을 통해 수신되는 Netflow 흐름이나 네트워크 트래픽을 모니터링할 수 있습니다. 이 모든 데이터는 세계 최대 규모의 사이버 보안 위협 연구원으로 구성된 비정부 그룹인 Cisco Talos가 수집한 위협 인텔리전스 정보로 강화됩니다.

이를 통해 회사에서 사용할 수 있는 퍼블릭 클라우드와 하이브리드 클라우드 모두에 대한 통합 모니터링 시스템을 구현할 수 있습니다. 그런 다음 수집된 정보는 Stealthwatch Cloud의 내장 기능을 사용하여 분석하거나 SIEM으로 전송할 수 있습니다(Splunk, ELK, SumoLogic 및 기타 여러 기능이 기본적으로 지원됨).

이것으로 클라우드 환경에서 발생하는 사고를 신속하게 감지하고 대응할 수 있는 IaaS/PaaS 플랫폼의 정보 보안 모니터링을 위한 내장 및 외부 도구를 검토한 기사의 첫 번째 부분을 완료하겠습니다. 우리 기업이 선택했습니다. 두 번째 부분에서는 주제를 이어가며 Salesforce 및 Dropbox의 예를 사용하여 SaaS 플랫폼을 모니터링하기 위한 옵션을 살펴보고, 또한 다양한 클라우드 공급자를 위한 통합 정보 보안 모니터링 시스템을 만들어 모든 것을 요약하고 정리하려고 노력할 것입니다.

출처 : habr.com