[팔로 알토 네트웍스] 네트워크 보안 기초 #4

[4주차] 클라우드 네이티브 보안

학습목표

1. 클라우드 네이티브 보안의 4C를 식별한다.

2. DevOps와 DevSecOps 간의 유사점과 차이점을 이해한다.

3. 클라우드 네이티브 가시성, 거버넌스 및 규정 준수 문제를 인식한다.

[4-1] 클라우드 네이티브 보안

클라우드 네이티브 보안
오늘날의 비즈니스 세계에서 매우 바람직한 속도와 유연성으로 인해, 기업은 더 많은 보안뿐만 아니라, 새로운 보안 접근 방식을 필요로 하는 클라우드 기술을 채택하게 되었다. 클라우드에서는 수백 또는 수천 개의 애플리케이션 인스턴스를 보유할 수 있으므로, 공격 및 데이터 도난 기회가 기하급수적으로 늘어난다.

퍼블릭 클라우드 서비스 공급업체는 컴퓨팅 하드웨어의 구축, 유지보수 및 업데이트를 담당하고 VM, 데이터 스토리지 및 데이터베이스를 고객에게 기본 보안과 함께 제공하여 모든 것을 보호하는 데 탁월한 노력을 기울였다. 하지만 클라우드의 데이터, 호스트, 컨테이너 및 서버 없는 인스턴스에 보안을 제공하는 것은 여전히 고객에게 달려 있다.

 

클라우드 네이티브 보안의 4ㅋ

CNCF(Cloud Native Computing Foundation) 쿠버네티스 프로젝트는 클라우드 네이티브 보안의 맥락에서 쿠버네티스를 위한 컨테이너 보안 모델을 정의한다. 이 모델은 클라우드 네이티브 보안의 4ㅋ라고 정리할 수 있겠다. 각 계층은 다음 계층을 위한 보안 기반을 제공한다. 클라우드 네이티브 보안의 4ㅋ는 다음과 같다.

 

① 클라우드

클라우드(데이터 센터뿐만 아니라)는 쿠버네티스 클러스터에 대한 신뢰할 수 있는 컴퓨팅 기반을 제공한다. 클러스터가 본질적으로 취약한 기반 위에 구축되거나 보안 제어가 제대로 되지 않는 구성이라면, 다른 계층은 제대로 보안되지 않는다.

 

② 클러스터

쿠버네티스 클러스터를 보호하려면, 구성 가능한 클러스터 구성 요소와 클러스터에서 실행되는 애플리케이션을 모두 보호해야 한다.

 

③ 컨테이너

컨테이너 계층 보안에는 컨테이너 취약성 검사 및 OS 의존성 검사, 컨테이너 이미지 서명 및 시행, 최소 권한 액세스 구현 등이 포함된다.

 

④ 코드

마지막으로 애플리케이션 코드 자체를 보안해야 한다. 코드 보안을 위한 보안 모범 사례에는 액세스를 위한 TLS 요구, 통신 포트 범위 제한, 타사 라이브러리에서 알려진 보안 취약점을 검색하고 정적 및 동적 코드 분석을 수행하는 것이 포함된다.

 

DevOps와 DevSecOps

전통적인 소프트웨어 개발 모델에서, 개발자들은 새로운 기능, 제품, 버그 수정 등을 위해 많은 양의 코드를 작성한 다음, 일반적으로 자동 티켓팅 시스템을 통해 배포를 위해 운영 팀에 작업을 전달한다. 운영 팀은 대기열에서 이 요청을 받고, 코드를 테스트하고, 생산 준비를 한다. 이 과정은 며칠, 몇 주 또는 몇 달이 걸릴 수 있다. 이 전통적인 모델에서, 운영 팀이 배포 중에 문제가 발생하면, 개발자들에게 해결해야 할 사항을 알려주기 위해 티켓을 다시 보낸다. 결국, 이러한 오락가락하는 작업이 해결된 후, 작업량은 생산으로 밀려난다.

이 모델은 소프트웨어 제공을 길고 단편적인 프로세스로 만든다. 개발자들은 종종 Operations를 프로젝트 일정의 속도를 늦추는 장애물로 여기는 반면, Operations 팀은 개발 문제의 투기장처럼 느껴진다.

DevOps는 소프트웨어 제공 프로세스 전반에 걸쳐 개발 및 운영 팀을 통합하여 이러한 문제를 해결함으로써, 문제를 조기에 발견하고 해결하며, 테스트 및 구축을 자동화하고 출시 시간을 단축할 수 있다.

 

DevOps에 대해서는 다음을 이해하도록 한다.
① 개발팀과 운영팀의 조합이다.

그들은 단지 의사소통적이고 협력적인 방식으로 운영된다.

② 자체 팀이 따로 있다.

데브옵스 엔지니어' 같은 건 없다. 데브옵스 문화로 전환하려고 할 때, 일부 회사에서 '데브옵스 팀'을 파일럿으로 임명할 수도 있지만, 데브옵스는 소프트웨어 제공 라이프사이클 전체에서 개발자, 테스터, 운영 인력이 협력하는 문화를 말한다.

③ 도구 또는 도구 세트.

데브옵스 모델과 잘 작동하거나, 데브옵스 문화를 촉진하는 데 도움이 되는 도구가 있지만, 데브옵스는 궁극적으로 도구가 아닌 전략이다.

④ 자동화

DevOps 문화에서는 매우 중요하지만, 자동화만으로는 DevOps를 정의할 수 없다.

 

데브옵스 모델에서 개발자들은 거대한 피처 세트를 맹목적으로 배포하기 전에 코딩하는 대신, 지속적인 테스트를 위해 소량의 코드를 자주 전달한다. 티켓팅 시스템을 통해 문제와 요청을 전달하는 대신, 개발 및 운영 팀은 정기적으로 회의를 열고 분석을 공유하며, 처음부터 끝까지 프로젝트를 공동 소유한다.

 

CI/CD 파이프라인

DevOps는 지속적인 통합 및 지속적인 제공(또는 지속적인 배포)의 순환이며, CI/CD 파이프라인이라고도 한다. CI/CD 파이프라인은 개발 및 운영 팀을 통합하여 인프라 및 워크플로우를 자동화하고, 애플리케이션 성능을 지속적으로 측정하여 생산성을 향상시킨다.

지속적인 통합을 위해서는 개발자들이 자동화된 테스트를 위해 하루에 여러 번 코드를 저장소에 통합해야 한다. 각 체크인은 자동화된 빌드에 의해 검증되므로, 팀은 문제를 조기에 발견할 수 있다.

지속적인 배송은 CI 파이프라인이 자동화되어 있지만, 코드가 프로덕션에서 구현되기 전에 수동 기술 점검을 거쳐야 한다는 것을 의미한다.

지속적인 배포는 한 단계 더 지속적인 전달을 필요로 한다. 수동 점검 대신 코드가 자동화된 테스트를 통과하고 자동으로 배포되어, 고객이 새로운 기능에 즉시 액세스할 수 있다.

 

데브옵스와 보안

DevOps의 한 가지 문제는 보안 문제가 종종 결국 균열을 통해 생겨난다는 것이다. 개발자들은 빠르게 움직이고, 그들의 워크플로우는 자동화된다. 보안은 별개의 팀이고, 개발자들은 보안 검사와 요청을 위해 속도를 늦추고 싶어하지 않는다. 그 결과, 많은 개발자들이 적절한 절차를 거치지 않고 배포하고, 필연적으로 해로운 보안 실수를 저지르게 된다.

이를 해결하기 위해 각 조직은 DevSecOps를 채택하고 있다. DevSecOps는 소프트웨어 제공 전반에 걸쳐 개발자와 IT 팀이 개별적으로 협력하는 대신, 긴밀하게 협력해야 한다는 개념인 DevOps의 개념을 채택하고, 이 개념을 확장하여 보안을 포함하고 자동화된 검사를 전체 CI/CD 파이프라인에 통합한다. 이를 통해 외부 세력처럼 보이는 보안 문제를 해결하고, 개발자가 데이터 보안을 손상시키지 않으면서 속도를 유지할 수 있다.

 

가시성, 거버넌스 및 컴플라이언스

성공적인 공격을 막으려면 클라우드 리소스와 SaaS 애플리케이션이 첫날부터 올바르게 구성되고 조직의 보안 표준을 준수하는지 확인하는 것이 필수적이다. 또한, 이러한 애플리케이션은 물론 이들이 수집하고 저장하는 데이터가 적절하게 보호되고 규정을 준수하는지 확인하는 것이, 비용이 많이 드는 벌금, 브랜드 평판 손상 및 고객 신뢰 상실을 방지하는 데 매우 중요하다. 보안 팀은 SaaS 애플리케이션 전반에 걸쳐 보안 표준을 충족하고 규정을 준수하는 환경을 유지해야 한다.

다양한 툴을 사용할 수 있음에도 불구하고, 대부분의 조직은 끊임없이 변화하는 클라우드 환경과 SaaS 애플리케이션에서 데이터 노출을 효과적으로 제어하고 보안 정책을 시행하는 데 어려움을 겪고 있다. 또한 분산된 환경에서 데이터가 저장되는 위치의 규정 준수를 보장하는 것은 제한된 보안 팀에 상당한 부담이 된다.

멀티 클라우드 환경 및 SaaS 애플리케이션 전반에 걸쳐 거버넌스와 컴플라이언스를 보장하려면 다음이 필요하다.

 

① 동적 SaaS 및 PaaS 및 IaaS 환경 전반에서 리소스 및 데이터를 실시간으로 검색하고 분류한다.

② 구성 거버넌스, 애플리케이션 및 리소스 구성이 배포되는 즉시 보안 모범 사례와 일치하는지 확인하고, 구성 드리프트를 방지한다.

③ 세분화된 정책 정의를 사용하여 SaaS 애플리케이션 및 퍼블릭 클라우드의 리소스에 대한 액세스를 제어하고, 네트워크 세분화를 적용하는 거버넌스에 액세스한다.

④ 자동화 및 내장된 컴플라이언스 프레임워크를 활용한 컴플라이언스 감사를 통해 언제든지 컴플라이언스를 보장하고, 필요에 따라 감사 준비 보고서를 생성할 수 있다.