ID: 클라우드에서 보안을 위한 연결 고리

클라우드의 거의 모든 요소는 단 한 번의 과도한 권한 또는 구성 오류가 위험 노출로 이어집니다. 적절한 클라우드 포스처 및 권한 관리는 위험을 완화하고 유해한 조합을 제거하는 데 도움이 될 수 있습니다.

클라우드 보안 솔루션을 구현 및 구성할 때는 모니터링할 자산의 수가 너무 많은 점이 어렵습니다. 여기에는 IaaS 및 컨테이너 리소스와 같이 Kubernetes 인프라에서 실행하는 웹 애플리케이션과 사용자 및 시스템 관련 ID 등이 포함됩니다. 클라우드 보안 팀은 각 리소스의 서비스 ID를 관리하고 취약성과 구성 오류를 스캔해야 합니다. 모니터링할 자산이 너무 많기 때문에 조직에서는 이러한 위협 벡터에 대처하기 위한 도구와 포인트 솔루션을 찾는 경우가 많습니다. 많은 조직에서는 다양한 이름의 보안 제품을 환경에서 사용하게 되었고, 그로 인해 서로 다른 제품을 구성하고 구현하는 데 막대한 비용이 발생합니다. 

각 도구는 종종 자체적으로 과다한 수의 보안 발견 사항을 생성하고 서로 다른 중요도 메트릭으로 작동합니다. 따라서 기술적으로 고도화된 도구를 사용하더라도 보안 팀은 모든 발견 사항을 조정하고 우선 순위를 지정하기 위해 스프레드시트에 또 다시 매달려야 합니다. 

클라우드에서 ID 보호의 중요성 

더 효과적인 보안 전략을 구현하려면 먼저 위협 행위자가 클라우드 인프라를 침해할 때 달성하려는 목표를 구별해야 합니다. 최근에는 거의 모든 클라우드 침해의 원인이 ID 및 권한의 구성 오류라는 것이 분명해졌습니다. Identity Defined Security Alliance(IDSA)의 "2022년 디지털 ID 보안 추세" 설문 조사에 따르면 조사 대상인 12개월 동안 84% 기업이 ID 관련 침해를 겪었습니다. 이유가 무엇일까요? ID는 Tenable이 클라우드에서 실행하고 구축하는 모든 것에 깊이 얽혀 있을 뿐만 아니라 해결해야 할 매우 복잡한 문제이기 때문입니다. ID 관리와 관련된 위험을 진정으로 이해하려고 할 때 고려해야 하는 변수는 너무나 많습니다.

악용 가능한 알려진 취약성이 있는 퍼블릭 Amazon EC2 인스턴스를 가지고 있거나 수동으로 또는 코드 기반으로 구성하는 구성 오류가 있는 인프라를 가지고 있는지 관계없이, 클라우드 위험 노출이 악용되면 공격자는 즉시 ID를 공략합니다. 공격자는 중요한 데이터 및 기타 리소스에 액세스하기 위한 내부 확산 이동이나 권한 상승을 목적으로 권한을 테스트합니다. ID는 클라우드의 경계이며 광범위한 영향을 미치기 때문에 ID 및 권한 보안은 전체적인 클라우드 보안 프로그램의 기반이 되어야 합니다. 

서비스 ID와 사용자 ID의 차이점 이해

ID를 보호할 때 최소 권한의 원칙을 달성하려면 서비스 ID와 사용자 ID의 차이는 이들을 보호하는 다양한 접근 방식을 이해하는 것이 중요합니다. 서비스 ID는 워크로드를 제공하며 일관되고 예측 가능한 방식으로 작동합니다. 할당된 권한과 실제로 사용되는 권한을 평가하는 것은 "유효 권한"을 이해하는 데 중요합니다. 서비스 ID는 특정 목적을 위해 프로그래밍되고 요구 사항은 거의 변경되지 않으므로 활동에 따라 권한 규모를 적절하게 조정할 수 있으며 이것이 최소 권한 원칙입니다. 

반면에 사용자 ID는 실제 사람이 사용합니다. 따라서 사용자 ID는 예측할 수 없으며 특히 임시 작업이 발생할 때 특정 리소스 및 행동에 대한 권한 규모를 적절하게 조정하기 어렵습니다. 제로 트러스트를 실현하려면 통합 Just-In-Time(JIT) 액세스 프로그램을 구현하는 것이 핵심입니다. 실제 사용자의 클라우드에 대한 모든 액세스를 완전히 제거할 수 있는 조직은 없으며 현실적으로 불가능합니다. 사용자 ID와 관련된 위험을 대폭 줄이는 방법은 다음과 같습니다. 중요 환경에서 특정 작업을 위해 프로그램 방식으로 클라우드에 대한 단기 액세스를 요청할 수 있는 기능을 DevOps 팀에 제공하고, 이 단기 액세스 워크플로가 Slack, Microsoft Teams 등과 같은 기존 커뮤니케이션 도구에 통합되도록 합니다. 

이러한 차이점을 고려하지 않는 보안 프로그램은 DevOps와 IT 팀 사이에 불필요한 수고와 마찰을 일으킬 수 있습니다. DevSecOps의 약속을 이행한다는 것은 보안을 확장 가능한 방식으로 워크플로에 포함하는 것을 의미합니다. 여기에서 통합된 클라우드 인프라 권한 관리(CIEM) 및 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP) 도구를 활용할 수 있습니다. 이 도구들이 통합되면 클라우드 인프라, Kubernetes, 컨테이너, 코드 기반 인프라(IaC), ID, 워크로드 등에 대한 가시성과 컨트롤을 제공할 수 있습니다.

통합 CNAPP 및 CIEM 보안 솔루션에서 다음 기능을 제공하는지 확인하십시오. 

• 권한 통찰 및 시각화: 오래된 보안 명언처럼 모니터링할 수 없는 것은 보호할 수 없습니다. 리소스, 권한 및 활동에 대한 정확한 멀티클라우드 가시성을 우선 반드시 갖추어야 합니다. 
• 지속적인 위험 평가: 네트워크 위험 노출, 구성 오류, 위험한 권한, 노출된 암호, 비정상적인 데이터 액세스를 포함한 ID 관련 위협 등의 위험 요소를 탐지하고 평가하려면 클라우드 환경을 지속적으로 모니터링해야 합니다.
• 최소 권한 원칙 적용: 통합된 도구는 최소 권한 정책을 통해 권한 가드레일을 자동화할 수 있어야 합니다.
• 수정 간소화: 어디에 위험이 있는지 이해한다면 보안 전략에 적합한 곳 어디든 자동화할 수 있는 기회를 통해 도구에서 위험을 쉽게 수정할 수 있을 것입니다. 
• 개발자 중심 액세스 제어: 보안을 워크플로에 통합할 수 있는 도구를 DevOps 팀에 제공하면 보안과 관련한 이들의 불만을 해소할 수 있습니다. 

컨텍스트로 알림 피로를 방지

많은 보안 팀에서 과도한 알림에 대처하기 위해 컨트롤 및 정책을 조정하는 데 시간을 사용하지만, 더 좋은 방법은 CNAPP 및 CIEM과 같은 보안 도구를 공격 표면 전반에 걸쳐 풍부한 컨텍스트를 제공하는 단일 플랫폼에 통합하는 것입니다. 통합된 보안 도구를 사용하면 "중요"의 진정한 의미를 표준화하고 공격자가 클라우드 환경에 피해를 주기 위해 활용할 수 있는 공격 경로를 더 잘 이해할 수 있습니다. 또한 새로운 위협과 제로데이가 발견되면 업데이트하기에 더욱 용이합니다. 

예를 들어, 공개적으로 액세스할 수 있는 100개의 워크로드를 클라우드 환경에서 실행하고 있지만 그 중 10개에만 심각한 취약성이 있고 그 중 5개에만 심각한 취약성과 높은 권한이 있을 수 있습니다. 이 컨텍스트를 통해 보안 팀은 악용될 가능성이 가장 높은 것을 기준으로 어디에 노력을 기울여야 하는지 통찰을 얻게 됩니다. 포인트 솔루션에는 위협을 효율적으로 해결하는 데 필요한 통합 및 ID 중심적 컨텍스트가 부족하기 때문에 보안 팀에서 100개의 공개 워크로드를 모두 해결하려고 시도하는 경우가 너무 많습니다. 

중요한 것은 위험과 위험 노출을 이해하는 통합 기능입니다. 인프라나 취약성 관점에서뿐만 아니라, 모든 것을 종합적으로 살펴보고 보안 환경에서 실제로 일어나는 일을 기반으로 위험 점수를 동적으로 조정하는 방법으로도 적합합니다. 

클라우드에서의 ID 보안에 대한 자세한 정보는 온디맨드 웨비나 "클라우드에서의 보안 포스처 및 권한 관리"를 확인하십시오.