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

[1주차]

Cloud Security Fundamentals 과정에서 Secure Access Service 엣지 아키텍처를 통해 클라우드 및 SaaS 기반 애플리케이션 보안과 관련된 기본 원칙을 배우고 기존 및 하이브리드 데이터 센터 및 미션 크리티컬 인프라에 대한 공격을 인식하고 잠재적으로 완화하는 데 필요한 개념을 파악한다. 또한, 도커 브리지 네트워크에서 컨테이너를 초기에 설정하고 구성하는 방법과 취약성 검사 및 보고서를 사용하여 컨테이너 보안을 테스트하는 방법도 배우게 된다.

[2주차] 클라우드 컴퓨팅 모델

학습목표

1. 일반적인 (SaaS, PaaS, IaaS) 클라우드 컴퓨팅 서비스 모델을 정의한다.
2. 퍼블릭, 커뮤니티, 프라이빗 및 하이브리드 클라우드 컴퓨팅 구축 모델을 설명한다.
3. 클라우드 컴퓨팅 공유 책임 모델을 식별한다.
4. 가장 일반적인 클라우드 컴퓨팅 보안 문제를 인식한다.

[2-1] 클라우드 컴퓨팅 기술

클라우드 컴퓨팅 기술
클라우드 컴퓨팅은 위치라기보다는 자동화된 온디맨드 방식으로 신속하게 프로비저닝될 수 있는 리소스 풀에 가깝다. NIST는 SP(Special Publication) 800-145의 클라우드 컴퓨팅을 "최소의 관리 노력 또는 서비스 제공자 상호 작용으로 신속하게 프로비저닝되고 릴리스될 수 있는 구성 가능한 컴퓨팅 리소스(ex. 네트워크, 서버, 스토리지, 애플리케이션 및 서비스)의 공유 풀에 유비쿼터스, 편리한 온디맨드 네트워크 액세스를 가능하게 하는 모델"로 정의한다.

클라우드 컴퓨팅의 가치는 규모의 경제와 민첩성을 달성하기 위해 리소스를 풀링하는 능력에 달려있다. 이러한 리소스 풀링 능력은 프라이빗 클라우드 또는 퍼블릭 클라우드에도 적용된다. 엔터프라이즈 애플리케이션에 배포되는 독립적이고 종종 사용 빈도가 낮은 서버 대신 리소스 풀은 집계되고 통합되며, 조직의 요구에 맞게 확장할 수 있을 만큼 탄력적으로 설계된다.

클라우드 컴퓨팅으로의 전환은 비용 및 운영상의 이점뿐만 아니라, 기술상의 이점도 가져다 준다. 사용자는 어디에 있든 데이터와 애플리케이션에 쉽게 액세스하고 프로젝트를 쉽게 확장할 수 있으며, 소비를 효과적으로 추적할 수 있다. 클라우드 컴퓨팅 아키텍처에서 가상화는 소프트웨어 오케스트레이션 및 관리 도구와 결합하면, 서로 다른 프로세스를 통합하여 필요에 따라 쉽게 복제하고 제공할 수 있도록 하는 데 매우 중요하다.

 

클라우드 서비스 모델
NIST는 3가지 클라우드 컴퓨팅 서비스 모델을 정의한다.

 

① SaaS

고객은 클라우드 인프라에서 실행되는 애플리케이션에 대한 액세스를 제공받는다. 애플리케이션은 다양한 클라이언트 장치와 인터페이스에서 액세스할 수 있지만, 고객은 기본 클라우드 인프라에 대한 지식이 없고, 관리하거나 제어하지 않는다. 고객은 제한된 사용자별 애플리케이션 설정에 액세스할 수 있으며, 고객 데이터의 보안은 여전히 고객의 책임이다.

② PaaS

고객은 공급자의 클라우드 인프라에 지원되는 애플리케이션을 배포할 수 있지만, 고객은 기본 클라우드 인프라에 대한 지식이 없고 관리하거나 제어하지도 않는다. 고객은 배포된 애플리케이션에 대한 제어권과 애플리케이션 호스팅 환경에 대한 제한된 구성 설정을 가지고 있다. 회사는 배포된 애플리케이션과 데이터를 소유하므로, 해당 애플리케이션과 데이터의 보안을 책임진다.

③ IaaS

고객은 처리, 스토리지, 네트워크 및 기타 컴퓨팅 리소스를 프로비저닝하고 운영 체제 및 애플리케이션을 배포하고 실행할 수 있다. 그러나 고객은 기본 클라우드 인프라에 대한 지식이 없으며, 특별히 관리하거나 제어하지 않는다. 고객은 일부 네트워킹 구성 요소(ex. 호스트 방화벽)와 함께 운영 체제, 스토리지 및 배포된 애플리케이션을 제어할 수 있다. 회사는 배포된 애플리케이션 및 데이터를 소유하므로, 이러한 애플리케이션 및 데이터의 보안을 책임진다.

 

클라우드 구축 모델
NIST는 또한, 다음 네 가지 클라우드 컴퓨팅 구축 모델을 정의한다.

① 퍼블릭

일반 대중이 사용할 수 있도록 개방된 클라우드 인프라다. 제3자(또는 당사자)에 의해 소유, 관리 및 운영되고, 클라우드 제공자의 프레미스에 존재한다.

② 커뮤니티

특정 조직 그룹이 독점적으로 사용하는 클라우드 인프라다.

③프라이빗

단일 조직이 독점적으로 사용하는 클라우드 인프라스트럭처다. 조직 또는 제3자에 의해 소유, 관리 및 운영될 수 있으며(또는 둘 다의 조합), 내부 또는 외부에 존재할 수 있다.

④ 하이브리드

앞서 언급한 구축 모델 중 둘 이상을 포함하는 클라우드 인프라로서, 데이터 및 애플리케이션 이동성(ex. 재해 복구를 위해 보조 데이터 센터로 페일오버하거나 여러 클라우드에 걸친 컨텐츠 제공 네트워크)을 지원하는 표준화된 기술 또는 독점 기술에 의해 제한된다.

 

클라우드 보안 문제
오늘날 네트워크를 위협하는 보안 위험은 클라우드로 이동해도 변하지 않는다. 공유 책임 모델은 퍼블릭 클라우드에서 (보안과 관련된) 것을 누가 (고객 또는 제공자) 책임을 지는지를 정의한다.

일반적으로 클라우드 제공업체는 클라우드 데이터 센터의 물리적 보안과 기반 네트워킹, 스토리지, 컴퓨팅 및 가상화 서비스를 포함한 클라우드의 보안을 담당한다. 클라우드 고객은 클라우드의 보안을 담당하며, 이는 클라우드 서비스 모델에 의해 더욱 묘사된다.

공유 책임 모델

 

예를 들어, 서비스형 인프라(IaaS) 모델에서 클라우드 고객은 운영 체제, 미들웨어, 런타임, 애플리케이션 및 데이터의 보안을 담당한다. 서비스형 플랫폼(PaaS) 모델에서 클라우드 고객은 애플리케이션 및 데이터의 보안을 담당하고 클라우드 제공자는 운영 체제, 미들웨어 및 런타임의 보안을 담당한다. SaaS 모델에서 클라우드 고객은 데이터의 보안만을 담당하고, 클라우드 제공자는 클라우드 데이터 센터의 물리적 보안에서 애플리케이션에 이르는 전체 스택을 담당한다. 클라우드 환경, 특히 SaaS 모델에서 멀티테넌시(Multitenancy)는 고객 제어 및 리소스가 클라우드 제공자에 의해 반드시 제한됨을 의미한다.

클라우드 컴퓨팅 기술을 사용하면, 데이터 센터 환경은 애플리케이션이 전용 서버에서 실행되는 고정 환경에서 동적이고 자동화된 환경으로 진화할 수 있으며, 컴퓨팅 리소스 풀을 사용하여 언제 어디서나 모든 장치에서 액세스할 수 있는 애플리케이션 워크로드를 지원할 수 있다.

 

이 새로운 동적 클라우드 컴퓨팅 패브릭 환경을 수용할 때, 보안은 여전히 중요한 과제로 남아 있다. 클라우드 컴퓨팅을 매력적으로 만드는 많은 원칙은 네트워크 보안 모범 사례에 위배된다.

 

① 보안을 위해서는 분리 및 세분화가 필요하며, 클라우드는 공유 리소스에 의존한다. 보안 모범 사례에서는 "절대 신뢰하지 말고 항상 검증하라"는 제로 트러스트 원칙을 사용하여, 미션 크리티컬 애플리케이션과 데이터를 네트워크의 보안 세그먼트에 분리해야 한다. 물리적 네트워크에서 제로 트러스트는 방화벽과 애플리케이션 및 사용자 신원에 기반한 정책을 사용하여 비교적 쉽게 달성할 수 있다. 클라우드 컴퓨팅 환경에서는 서버 내 및 데이터 센터 내 VM 간의 직접 통신이 다양한 신뢰 수준에 걸쳐 지속적으로 발생하므로, 세분화 작업이 어렵다. 가상화된 포트 기반 보안 제품을 통해 호스트 내 트래픽 가시성이 부족한 상태에서 혼합된 신뢰 수준이 조직의 보안 태세를 약화시킬 수 있다.

 

② 보안 구축은 프로세스 지향적이며, 클라우드 컴퓨팅 환경은 동적이다. 클라우드 워크로드의 생성 또는 수정은 종종 몇 분 안에 수행할 수 있지만, 이 워크로드에 대한 보안 구성에는 몇 시간, 며칠 또는 몇 주가 걸릴 수 있다. 보안 지연은 의도적인 것이 아니며, 강력한 보안 상태를 유지하도록 설계된 프로세스의 결과다. 정책 변경을 승인하고 적절한 방화벽을 식별해야 하며 관련 정책 업데이트를 결정해야 한다. 이에 반해 클라우드는 워크로드(및 IP 주소)가 지속적으로 추가, 제거 및 변경되는 매우 역동적인 환경이다. 결과적으로, 보안 정책과 클라우드 워크로드 구축 간의 연결이 끊어지고, 보안 상태가 약화된다. 보안 기술 및 프로세스는 클로닝 및 스크립트로 작성된 배포와 같은 기능을 활용하여, 클라우드의 탄력성을 활용하면서 강력한 보안 상태를 유지해야 한다.

③ 멀티테넌시(Multi-tenancy)는 퍼블릭 클라우드의 주요 특성이자 주요 위험이다. 퍼블릭 클라우드 공급자는 다양한 고객 간의 격리를 보장하기 위해 노력하지만, 퍼블릭 클라우드의 인프라와 리소스는 공유된다. 공유 환경에 내재된 위험에는 잘못된 구성, 부적절하거나 비효율적인 프로세스 및 제어, 소음 문제(과도한 네트워크 트래픽, 디스크 I/O 또는 프로세서 사용률은 동일한 리소스를 공유하는 다른 고객에게 부정적인 영향을 미칠 수 있음) 등이 포함된다. 수많은 퍼블릭 또는 프라이빗 클라우드를 연결하는 하이브리드 및 멀티클라우드 환경에서는 선이 여전히 모호해지고 복잡성이 증가하며, 보안 위험을 해결하기가 더욱 어려워진다.

④ 기존의 네트워크 및 호스트 보안 모델은 서버가 없는 애플리케이션에서는 클라우드에서 작동하지 않는다. 과거에는 심층 방어가 대부분 네트워크 계층 제어를 통해 수행되었다. 고급 위협 방지 도구는 네트워크를 통과하는 애플리케이션을 인식하고, 해당 애플리케이션의 허용 여부를 결정할 수 있다. 이러한 유형의 보안은 클라우드 네이티브 환경에서 여전히 매우 필요하지만, 더 이상 자체적으로 충분하지 않다. 퍼블릭 클라우드 제공업체는 풍부한 서비스 포트폴리오를 제공하며, 이러한 서비스를 관리하고 보안하는 유일한 방법은 ID 및 액세스 관리(IAM)를 통해서다. IAM은 사용자 및 클라우드 리소스에 대한 권한과 액세스를 제어한다. IAM 정책은 사용자 또는 클라우드 리소스에 부착하여, 액세스하는 것과 액세스하는 것을 승인할 수 있는 권한 정책이다.

 

조직이 전통적인 데이터 센터 아키텍처에서 퍼블릭, 프라이빗 또는 하이브리드 클라우드 환경으로 전환함에 따라, 클라우드의 변화하는 요구 사항을 지원하기 위해 엔터프라이즈 보안 전략을 조정해야 한다. 클라우드 보안을 위한 주요 요구 사항은 다음과 같다.

 

① 물리적 폼 팩터와 가상화 폼 팩터에서 일관된 보안

클라우드 컴퓨팅 환경과 물리적 네트워크 모두를 보호하기 위해 동일한 수준의 애플리케이션 제어 및 위협 방지 기능이 사용되어야 한다. 먼저, 애플리케이션의 신원을 확인하고, 해당 애플리케이션의 신원을 확인하고, 표준 포트만 사용하도록 강제할 수 있어야 한다. 또한, 불량 애플리케이션의 사용을 차단하는 동시에, 잘못 구성된 애플리케이션을 찾고 차단할 수 있어야 한다. 마지막으로, 애플리케이션별 위협 방지 정책을 적용하여, 알려진 멀웨어와 알려지지 않은 멀웨어가 모두 네트워크 및 클라우드 환경으로 이동하는 것을 차단해야 한다.

 

② 제로 트러스트 원칙을 사용하여 세분화된 비즈니스 애플리케이션

컴퓨팅 리소스 사용을 완전히 극대화하기 위해 비교적 일반적인 현재 관행은 동일한 컴퓨팅 리소스에서 애플리케이션 워크로드 신뢰 수준을 혼합하는 것이다. 실제로는 효율적이지만, 신뢰 수준이 혼합되면, 손상 시 새로운 보안 위험이 발생한다. 클라우드 보안 솔루션은 위협의 측면 이동을 방지하면서, 워크로드 간 트래픽을 제어하는 수단으로 제로 트러스트 개념에 기반한 보안 정책을 구현할 수 있어야 한다.

 

③ 중앙에서 관리되는 비즈니스 애플리케이션; 정책 업데이트를 간소화

물리적 네트워크 보안은 여전히 거의 모든 조직에 구축되어 있으므로, 동일한 관리 인프라 및 인터페이스를 사용하여 중앙 집중식 위치에서 하드웨어 및 가상 폼 팩터 배포를 모두 관리할 수 있는 능력이 중요하다. 워크플로우가 보여줄 수 있는 변화 속도에 보안이 보조되도록 보안 솔루션에는 보안 정책 업데이트에 자주 필요한 수동 프로세스를 줄이고 경우에 따라 제거할 수 있는 기능이 포함되어야 한다.

 

어떤 유형의 클라우드 서비스를 사용하든, 특정 유형의 워크로드를 보호해야 하는 부담은 항상 공급업체가 아닌 사용자에게 돌아갈 것이다. 클라우드 환경 보안을 극대화하려면, 다음 모범 사례를 고려해야 한다.

 

① 기본 설정을 검토

특정 설정은 공급자가 자동으로 설정하지만, 일부 설정은 수동으로 활성화해야 한다. 공급자가 클라우드 네이티브 보안의 특정 측면을 관리하고 있다고 가정하는 것보다 항상 자체 보안 정책을 설정하는 것이 좋다.

② 데이터 저장 및 인증 구성을 조직에 맞게 조정

데이터가 업로드될 모든 위치는 암호를 보호해야 한다. 또한, 암호 만료 정책은 조직의 요구에 맞게 신중하게 선택해야 한다.

③ 클라우드 데이터가 안전하다고 가정하지 않기

공급업체가 암호화한 데이터가 완전히 안전하다고 가정하지 말아야 한다. 업로드하기 전에 암호화 서비스를 제공하는 공급업체도 있고, 그렇지 않은 공급업체도 있다. 어떤 경우든 전송 중이거나 정지 중인 데이터를 자신의 키를 사용하여 암호화해야 한다.

 

④ 클라우드의 데이터 보존 정책과 통합

공급업체의 데이터 보존 및 삭제 정책을 이해하는 것은 매우 중요하다. 데이터 복사본을 여러 개 가지고 데이터 보존 기간을 고정하는 것이 중요하다. 하지만 클라우드에서 데이터를 삭제하면 어떻게 될까? 공급업체는 여전히 데이터에 액세스할 수 있을까? 캐시되거나 복사되었을 수 있는 다른 장소가 있는가? 새로운 클라우드 환경을 설정할 때 이러한 사항을 미리 확인해야 한다.

⑤ 적절한 권한 설정

권한 수준에 대한 적절한 설정은 클라우드 환경을 보다 안전하게 만드는 데 도움이 된다. 권한 부여를 위해 역할 기반 액세스 제어(RBAC)를 사용하면, 데이터를 보거나 작업하는 모든 사람이 반드시 필요한 것에만 액세스할 수 있도록 할 수 있다.

 

⑥ 클라우드 소프트웨어 최신 상태로 유지

공급업체는 인프라와 경우에 따라 미리 구축된 소프트웨어 환경 또는 클라우드 네이티브 방화벽을 제공할 수도 있다. 그러나 추가하는 모든 것은 보안을 유지해야 하는 사용자의 책임이다. 따라서 보안 패치, 운영 체제 등을 최신 상태로 유지하는 것은 사용자로서 나의 책임이 된다. 기술적 부채와 백로그를 방지하는 가장 간단한 방법은 업데이트를 자동화하는 것이다.

 

⑦ 보안 정책 및 모범 사례 클라우드 이미지에 구축

데브옵스 보안 팀의 여러 개발자에게 클라우드 네이티브 보안을 맡기면, 정책 불일치가 발생할 수 있다. 이를 방지하는 좋은 방법은 보안 도구가 구성되고 적용된 정책으로 클라우드 이미지를 생성하여, 개발자가 간단히 인스턴스를 만들 수 있도록 하는 것이다.

 

⑧ 클라우드 리소스를 격리

불량 행위자가 시스템을 완전히 제어할 위험을 줄이려면, 개발, 배포, 테스트 등을 위해 관리 계정을 분리해야 한다. 그런 식으로 불량 행위자가 하나의 계정에 액세스하면, 해당 계정을 측면에서 액세스할 수 없다.

[2-2] 클라우드 보안 용어 - 용어집

클라우드 보안 용어 - 용어집

이하의 용어는 Cloud Security Alliance에서 가져온 것이다.

 

Account Takeover
해커가 손상된 계정에 장기간 잠자고 있다가, 자신에게 중요한 정보에 접근할 수 있을 때까지 내부 메시지를 통해 조직 내에서 조용히 확산되는 사이버 공격의 한 유형이다. 해커는 해당 계정을 사용하여 다른 조직을 공격할 수 있다.

APT
공격자가 계정 또는 네트워크에 액세스하고, 초기 침입 후에 탐지되지 않은 상태로 남아 있는 공격이다. "Advanced"는 피해자의 보안을 피할 수 있었던 초기 침입 기술(피싱 또는 멀웨어)을 설명한다. 공격자가 초기 침입 후 훨씬 후에 정찰과 내부 확산을 통해 공격을 계속 수행하기 때문에 공격은 "Persistent"다.

Advanced Threat Protection (Microsoft ATP)
Safe Links: 사용자를 리디렉션하기 전에 사이트를 확인하여 각 URL을 대체한다.
Safe Attachments: 첨부 파일에서 멀웨어를 검색한다.
Spoof Intelligence: 도메인과 일치하는 외부 전자 메일을 분석한다.
Anti-phishing Filters: 들어오는 피싱 공격의 징후를 찾는다.

Anomaly
조직과 사용자의 과거 활동의 맥락에서 관찰할 때 비정상적으로 보이는 행동 또는 행동 유형이다. 일반적으로 로그인 위치와 시간, 데이터 전송 행동 및 이메일 메시지 패턴을 포함한 과거 이벤트 정보를 기반으로, 프로파일을 구축하는 일종의 기계 학습 알고리즘을 사용하여 분석된다. 이상 징후는 계정이 손상되었다는 신호일 수 있다.

API 공격
API는 두 클라우드 애플리케이션이 서로 직접 대화할 수 있도록 하여 제3자가 클라우드 애플리케이션 내에서 직접 읽거나 변경할 수 있도록 한다. API 연결을 만들려면 사용자의 승인이 필요하지만, 일단 생성되면 백그라운드에서 모니터링이 거의 또는 전혀 없이 조용히 실행된다. API 기반 공격은 일반적으로 사용자를 속여서 피싱 공격으로 API 연결을 승인하는 것을 포함한다. API 토큰을 부여하면, 사용자가 계정 암호를 변경하더라도 공격자는 거의 완벽한 액세스 및 제어 권한을 갖게 된다. 연결을 해제하려면, 사용자가 수동으로 API 토큰을 취소해야 한다.

 

Behavioral Analysis

파일에 숨겨진 악성 기능이 포함되어 있는지 또는 알 수 없는 제3자와 통신하고 있는지 확인하기 위해 격리된 환경에서 파일의 동작을 모니터링하고 분석하는 보안 조치다.

 

Brand Impersonation

유명 기업의 브랜드를 이용해 인증 정보를 입력하거나, 기밀 정보를 공유하거나, 송금하거나, 악성 링크를 클릭하는 피싱 공격 방법이다. SNS 회사에서 비밀번호를 확인해 달라는 것처럼 보이는 위조 이메일이 대표적인 예시다.

Breach Response

침해로 인한 피해를 구제하는 보안 형태다. 예를 들어, 비밀번호 변경, API 토큰 취소, 공유 문서에 대한 권한 재설정, 다중 요소 인증 가능, 분실 또는 편집된 문서 복구, 유출된 정보 문서 문서화 및 분류, 잠재적인 보안 침해 경로 식별 등이 있다.

 

CASB

Cloud Access Security Broker의 약자다. 조직의 직원이 사용할 수 있는 클라우드 애플리케이션을 모니터링하고 제어하는 보안의 한 종류다. 일반적으로 제어는 순방향 또는 역방향 프록시를 통해 웹 트래픽을 라우팅함으로써 수행된다. CASB는 Shadow IT를 관리하고 직원의 특정 SaaS 사용 또는 해당 SaaS 내 활동을 제한하는 데 유용하지만, 클라우드의 제3자 활동, 즉 공유 문서나 이메일을 모니터링하지는 않는다.

 

Cloud Access Trojan

CAT라고도 알려진 클라우드 액세스 트로이는 사용자 이름과 암호를 사용하지 않고 클라우드 계정에 액세스하는 모든 방법을 설명한다. 예를 들어, 악의적인 사용자가 데스크톱 앱을 동기화하거나, 모든 전자 메일을 외부 계정으로 전달하거나, 악의적인 스크립트를 연결하거나, 전체 액세스 권한이 있는 백업 서비스를 단순히 승인하는 것과 같은 경우, 공격자는 순간적인 액세스만 필요하다.

 

Cloud Messaging Apps

이메일을 포함하지만, 기업이 내부 커뮤니케이션을 위해 사용하는 클라우드 기반 통신 서비스에는 신뢰할 수 있는 파트너도 포함될 수 있다. 직원들은 악성 프로그램이나 피싱 메시지를 배포할 수 있음에도 불구하고, 이러한 앱에 더 많은 신뢰를 갖게 되는 경우가 많다.

 

Cloudify

온프레미스 또는 데이터센터용으로 제작된 소프트웨어를 가져와 API 컨테이너로 감싸 클라우드 서비스로 전환하는 것이다. 예를 들어, 페리미터 어플라이언스에서 멀웨어 분석 블레이드를 가져와 직접 관리할 필요 없이, 구성 및 확장이 가능하도록 조정하는 것이다. 여기에는 소프트웨어 라이센스 및 버전 제어의 자동화도 포함된다.

 

Compromised Account

악의적인 이유로 외부자에 의해 액세스되고 통제될 가능성이 있는 계정이다. 이것은 API 연결 또는 유출 또는 피싱 이메일로부터 계정에 대한 자격 증명을 얻음으로써 수행될 수 있다. 일반적으로 공격자의 목표는 탐지되지 않은 상태로 유지하여 추가 공격을 위한 기지로 사용하는 것이다.

 

Data Classification

조직의 모든 문서가 검색되고 민감도에 따라 분류된 다음, 자동으로 암호화되거나 올바른 공유 수준 권한으로 조정되는 보안 및 규정 준수 조치다. 예를 들어, 고객 정보 또는 직원의 주민등록번호가 포함된 문서는 매우 민감하고 암호화된 것으로 분류되는 반면, 외부에 있는 백서는 민감하지 않고 암호화되지 않은 것으로 분류된다.

 

DLP

중요한 데이터(일반적으로 파일)가 조직 외부나 조직 내 권한 없는 개인에게 공유되지 않도록 하는 보안 유형이다. 이 작업은 일반적으로 데이터를 암호화하거나, 공유 설정을 제어하는 정책을 통해 수행된다.

 

DRM

기밀 정보, 독점 하드웨어 및 저작권이 있는 저작물의 사용을 제한하기 위한 액세스 제어 기술의 집합으로, 일반적으로 암호화 및 키 관리를 사용한다.(IRM 참조)

 

Gateway

게이트웨이는 임의의 장치이거나, 혹은 MTA의 다른 용어로 이해하면 된다.

 

IRM(Information Rights Management)

일반적으로 암호화 및 권한 관리를 사용하여, 기업 정보가 원치 않는 당사자에 의해 표시되거나 편집되지 않도록 보호하는 디지털 권한 관리의 하위 집합이다.(DRM 참조)

 

Latency

이메일이 의도한 수신자에게 전달되는 데 걸리는 추가 시간이다. 보안 조치는 이메일이 사용자의 받은 편지함에 도달하도록 허용하기 전에, 이메일에 대한 검색을 수행할 때 지연 시간을 추가하기도 한다.

 

Malconfiguration

일반적으로 백도어 액세스를 생성하거나 정보를 유출하기 위해 악의적인 행위자가 시스템 내에서 의도적으로 구성을 변경하는 것이다. 원래 구성 변경에는 손상된 계정이나 다른 취약성이 포함될 수 있지만, 잘못된 구성은 암호가 더 이상 필요하지 않거나, 취약성이 닫힌 후에 합법적인 도구를 사용하여 장기간 액세스를 제공하는 이점이 있다.

 

Misconfiguration

위험하거나 승인되지 않은 계정 구성은 의도가 있는 사용자가 즉각적인 비즈니스 문제를 해결하려고 시도할 때 손상으로 이어질 수 있다. 악의적인 의도는 없지만, 실제로 잘못된 구성이 데이터 손실 또는 손상의 주요 원인이다.

 

MTA

Message Transfer Agent의 약어다. MTA는 전자 메시지에 대한 공인된 기록 서버 역할을 하고, 마침내 그것들을 최종 메일 서버로 전달하는 장치 또는 서비스다.

 

Phishing

신뢰할 수 있는 출처로 위장한 악의적인 당사자로부터 메시지가 수신자를 속여서 자격 증명, 돈 또는 기밀 데이터를 포기하도록 하려는 의도로 전송되는 공격 유형이다. 악성 링크나 파일이 포함된 경우가 많지만, 한 문장으로 단순하여 안전하지 않은 응답을 유발할 수도 있다. (스피어피싱 참조)

 

Proxy

프록시는 어플라이언스 또는 클라우드 서비스를 통해 트래픽 경로를 변경하는 모든 게이트웨이, 서비스 또는 어플라이언스를 포함할 수 있다. 예를 들어, 웹 프록시 또는 CASB는 트래픽을 해독하고 특정 애플리케이션 또는 데이터를 차단하기 위해 사용자의 웹 브라우징을 리디렉션한다. 메일 프록시 게이트웨이(MTA 참조)는 스팸, 피싱 또는 기타 악의적인 이메일을 검색하고 차단하기 위해 들어오는 이메일의 경로를 변경한다. 프록시는 볼 수 없는 트래픽, 즉 원격 및 비직원 웹 사용 또는 내부 이메일 트래픽을 모니터링하거나 제어할 수 없기 때문에 표시가 제한된다.

 

Quarantine

파일의 공유 권한을 암호화, 이동 또는 변경하여 사용자가 접근할 수 없도록 하는 행위를 의도한 수신자가 안전하다고 간주하거나 승인할 수 있다.

 

Ransomware

공격자만이 키를 가지고 있는 메커니즘을 사용하여 엔드포인트 장치의 파일을 암호화하는 멀웨어의 일종이다. 공격자가 지불하는 대가로 키를 제공하지만, 지불하는 피해자의 절반 미만이 실제로 파일을 복구한다.

 

Sandboxing

제어된 환경에서 파일 또는 링크를 테스트하여 에뮬레이트된 운영 체제(일반적으로 코드에 대한 서명이나 사전 지식이 없는 제로데이 공격에 대한 첫 번째 방어 라인)에 어떤 영향을 미치는지 확인하는 것을 포함하는 보안 조치 유형이다.

 

Shadow IT

승인되지 않은 클라우드 기반 계정 또는 솔루션을 직원이 업무용으로 구현한 경우다. 또한 알 수 없는 계정을 승인된 공급자와 함께 사용할 수 있지만, 기업 IT가 아닌 사용자가 관리하는 경우도 포함된다.

 

Shadow SaaS

기업 데이터에 액세스할 수 있지만, 조직의 허가 없이 해당 조직의 SaaS 또는 IaaS에 어떤 방식으로든(일반적으로 API를 통해) 연결되는 승인되지 않은 클라우드 애플리케이션이다.

 

Spearphishing

소수의 사용자(때로는 CEO와 같은 단 한 명의 사용자)를 목표로 하도록 설계된 피싱 공격의 한 유형이다. 스피어 피싱 공격은 일반적으로 의도한 목표가 여기에 빠질 가능성을 높이기 위해 해커의 집중적인 연구를 수반한다.

 

Tokens

API 상호 작용에 사용되는 고유한 인증 키다. 각 토큰에는 특정 수준의 액세스 및 제어 권한이 부여되며, 토큰을 수동으로 취소할 때까지 액세스 권한을 계속 제공하는 경우가 많다.

 

URL Analysis

링크를 검토하여 정품 여부를 평가하고 의도하지 않은 부작용 없이 안전하고 예상되는 목적지로 안내하는 보안 조치다.

 

URL Impersonation

해커가 훈련받지 않은 사람의 눈에 신뢰할 수 있는 웹 사이트에 대한 링크처럼 보이는 URL을 생성하는, 피싱 공격에 사용되는 기술이다. 이러한 기술은 URL 분석을 사용하여 차단할 수 있다.

 

User Impersonation

해커가 이메일을 신뢰할 수 있는 발신자(회사 또는 다른 직원)가 보낸 것처럼 보이게 만드는, 피싱 공격에 사용되는 기술이다. 닉네임을 수정하거나, 신뢰할 수 있는 기관에서 보낸 것처럼 보이는 이메일 주소를 사용하는 것이다.

[2-3] 발견 - 공유 보안 책임 모델

서비스 및 콘텐츠 공급자에서 소비자에 이르기까지 모든 클라우드 참여자들은 클라우드 공유 보안 책임 모델의 영향을 받는다. 프라이빗 클라우드 구축을 위해서라도, 클라우드 서비스 모델을 확보하는 것은 공유된 책임이다. 일반 당사자에 대한 책임을 개략적으로 설명하는 업계 표준과 통제가 있지만, 각 조직은 자신의 공유 책임 모델 관계를 명확하게 정의하고, 이러한 관계와 관련된 보안 위험을 해결해야 한다.

SaaS 및 PaaS 수준에서는 멀티 테넌트 환경에 존재하는 명백한 위험이 있지만, IaaS 배포 환경에서도 제대로 구성되지 않으면 악용될 수 있는 서비스 공급자의 핵심 보안 취약성이 있다. Gartner는 클라우드 구성 오류가 클라우드 보안 장애의 99%를 차지한다고 말한다. 사실상, 문제가 생겼다고 하면 이걸 살피면 된다는 말이다.

기업이 이러한 모든 잠재적 위험을 최소화하려면, 공유 보안 책임을 명시하는 계약이 있어야 한다. 이러한 책임 중 일부는 본질적으로 특정 클라우드 서비스 모델에 의해 정의되지만, 클라우드 보안과 관련하여 고려해야 할 영역은 항상 다음과 같다.

① 규정 준수 및 규제 제약 조건
② 애플리케이션 취약성
③ 공유 리소스
④ 암호화 및 가용성을 포함한 데이터 보안
⑤ 네트워크 접속 및 ID 관리
⑥ 개발 및 테스트