☁️ 클라우드 서비스의 보안적 취약점과 대응책

본 포스팅은 학교 수업에서 진행하는 이론,실습에 대해 정리하는 포스팅 입니다. 공부용으로 작성하는 포스팅으로 오류가 있을 수 있습니다.

 

클라우드 서비스

오늘날 IT 환경에서 클라우드 기술은 데이터 관리와 서비스 제공 방식에서 중요한 역할을 하고있다. 

클라우드는 자원의 효율적인 활용과 유연성을 제공하며 빠르게 변화하는 기술 환경 속에서 필수적인 위치에 있다.

이러한 클라우드 서비스의 핵심 특성을 간략히 정리하고, 이러한 특성을 보안의 측면에서 어떻게 해석해야 하는지를 정리하였다.

 

 

클라우드 주요 특성

• On-demand self-service (주문형 셀프 서비스): 클라우드 사용자는 필요에 따라 자원을 추가하거나 제거할 수 있다. 이는 서버와 저장 공간 같은 자원을 즉시 관리할 수 있는 유연성을 제공
• Broad network access (광범위한 네트워크 접근성): 클라우드 서비스는 다양한 디바이스(모바일, 데스크탑, 메인프레임)를 통해 네트워크에 접근할 수 있는 기능을 제공한다. 이로 인해 장소나 디바이스에 구애받지 않고 데이터를 활용할 수 있어.
• Resource pooling (자원 풀링): 여러 사용자가 동일한 자원을 공유하면서도 필요에 따라 동적으로 할당된다. 이 과정은 사용자에게 투명하게 이루어지며, 자원의 활용도를 극대화한다.
• Rapid elasticity (빠른 확장성): 서비스가 사용자 요구에 따라 빠르게 확장되거나 축소될 수 있다. 예를 들어, 트래픽이 급증할 때 추가 자원을 자동으로 할당하거나, 사용량이 줄어들면 자원을 회수해 비용을 절감하지.
• Measured service (측정 가능한 서비스): 클라우드 서비스는 사용량을 측정하여 청구할 수 있다. 마치 전기나 수도처럼, 사용한 만큼만 비용을 지불하면 된다.

이렇게 클라우드는 효율성, 확장성, 접근성을 제공하고 있다.

 

클라우드 서비스 모델

요즘에는 클라우드의 서비스 모델을 더 다양하게 구분할 수도 있지만, 기본적으로는 아래 대표적인 3가지 주요 서비스 모델로 분류한다. 각 모델은 제공되는 자원의 수준과 범위가 다르며, 고객의 필요에 따라 선택이 가능하다. 

• SaaS (Software as a Service): SaaS는 클라우드 제공자가 완전한 애플리케이션을 제공하는 모델이다. 애플리케이션 설치 및 업데이트가 필요 없다. 사용자는 웹 브라우저를 통해 이용 가능. 
• PaaS (Platform as a Service): PaaS는 애플리케이션을 개발하고 실행할 수 있는 플랫폼을 제공하는 모델이다. 프로그래밍 언어, 도구, 데이터베이스 등을 포함한 개발 환경 제공하여 개발 및 배포 속도를 높인다.
• IaaS (Infrastructure as a Service): IaaS는 서버, 스토리지, 네트워크 등의 기본 인프라를 제공하는 모델이다. 가상화 기술을 통해 물리적 장비를 대체한다.

각 서비스 모델은 제공자와 고객간의 관리 책임 범위가 다르다는 점에서 구분된다.

 

이렇게 클라우드의 기본적인 정의와 대표적인 모델을 알아보았다. 이러한 점을 통해 보안적인 측면에서 살펴보면, 클라우드 서버의 리소스가 매우 크다는 것이 장점이 될 수 있다. DDos와 같은 네트워크 자원을 노리는 공격은 공격자가 공격대상보다 리소스가 많아야 성공할 수 있는데, 개인이 클라우드 서버에 규모에 견줄만한 환경을 갖추는 것은 어려운 일이다.

 

그러나 이 많은 리소스를 개인이 사용하는 것이 아니라 다수가 공유하며 사용한다는 점에서 반대로 보안적인 측면에서 약점이 될 수도 있다.

 

 

 

 

클라우드 배포 모델과 마이그레이션 위험 분석

클라우드는 배포 방식에 따라 다양한 모델로 제공되며, 조직의 요구 사항과 자원 활용 방식에 따라 적합한 모델을 선택할 수 있다.

또한, 클라우드로 전환할 때는 위험 요소를 분석하고 적절한 대비책을 마련해야한다.

 

대표적인 배포 모델은 다음과 같다

• Private Cloud: 특정 조직이 독점적으로 사용하는 클라우드 인프라 -> 데이터 자원 완전 제어 가능, 보안성이 높음
• Community Cloud: 공통의 목적, 이익, 목표를 가진 여러 조직이 공유하는 클라우드 인프라 -> 관리 비용 분담
• Public Cloud: 클라우드 서비스 제공자가 소유하며, 대중에게 제공되는 클라우드. -> 비용 효율적, 확장 쉬움
• Hybrid Cloud: 두 개 이상의 클라우드(Private, Public 등)를 결합한 모델 -> 워크로드 분산, 유연성과 보안 균형 제공

요구사항에 맞춰 적절한 모델을 선택하여 사용할 수는 있으나, 서비스를 이용하다 보면 새로운 모델로 전환하거나 마이그레이션 해야하는 상황이 생길 수 있다. 혹은, 클라우드 없이 서비스를 구현하다가 클라우드로 전환하기 전에 잠재적인 위험을 식별하고 관리하는게 중요하다.

마이그레이션 핵심 단계는 다음과 같다. 

 

• Identify assets (자산 식별): 보호해야 할 데이터, 애플리케이션, 네트워크 구성 요소 등을 파악, 조직의 중요한 정보 자산을 분류
• Determine vulnerabilities (취약점 파악): 클라우드 전환 시 노출될 수 있는 취약점을 식별 (예: 데이터 유출, 인증 절차 미흡.)
• Estimate likelihood of exploitation (공격 가능성 평가): 식별된 취약점이 악용될 가능성을 예측
• Compute expected loss (예상 손실 계산): 보안 사고 발생 시 재정적, 운영적 손실 규모를 산출, 데이터 복구 비용, 운영 중단 비용 등을 포함.
• Survey and select new controls (새로운 통제 수단 선택): 클라우드 환경에서 취약점을 보완할 보안 대책을 도입.
• Project savings (절감 비용 산출): 클라우드 전환으로 절감되는 비용과 이를 통해 얻는 이점을 분석.

전체적으로 기존 보안시 주의할 내용과 큰 차이점은, 지켜야 할 자산에서 하드웨어의 비중이 내려갔다.

그리고 취약점의 종류가 바뀌었다. 취약점이 달라졌으니 어떻게 악용하여 공격할 것인지 그 방법도 달라진다. 

결과적으로, 클라우드는 많은 이점을 가진 서비스임에는 분명하나, 클라우드로 전환을 한다고 해서 관리 책임이 줄어드는 것은 아니다. 고려해야할게 더 늘어나기도 한다.

 

클라우드는 제공하는 서비스의 다양성이 장점이지만 모든 것이 공유되어 있고, 저장되고 연산되는 과정이 내 컨트롤 밖에 있어서 보안적으로는 단점

 

 

클라우드 환경을 선택하고 유지하는데 있어 중요한 부분은 클라우드 제공자에 대한 평가와 필요시 제공자를 변경하는 과정이다. 이 과정에서 여러 요소를 고려해야 한다.

 

보안 고려사항

• 인증
• 권한 및 접근 제어
• 암호화 옵션
• 감사 로깅
• 사고 대응 능력
• 신뢰성과 가동률

이러한 보안에 필요한 요소를 서비스를 이용하는 개인이 직접 다 체크하기는 힘들기 때문에, 참고할 수 있는 평가 리스트가 존재한다.

 

참고 리소스

• FedRamp: 정부기관의 클라우드 보안 평가 기준
• PCI DSS: 카드 결제 데이터를 보호하기 위한 규격
• CSA STAR: 클라우드 보안 인증 프레임워크

클라우드 제공자 변경

클라우드 제공자를 변경하는 것은 복잡하고 비용이 많이 든다.  제일 좋은 방법은 기본 제공자로부터 백업 옵션을 마련하고 이동을 하는것인데, 실제 서비스를 제공하는 제공자들 입장에서는 이 과정을 도울 이유가 없기에 쉽지 않은 일이다.

앞서 살펴보았던 모델 중에서도, Saas>PaaS>IaaS순으로 전환이 어렵다. (인프라는 어딜가나 비슷해서..) 

 

 

클라우드 보안

앞서 가볍게 클라우드의 보안적인 요소들을 다루었는데, 좀 더 자세하게 다루어보자

보안적 이점

먼저 클라우드의 보안적 이점은 다음과 같이 정리할 수 있다.

• 지리적 이점: 분산되어 있어서 자연재해나, 일부 노드가 멈춰도 이용이 가능하다. -> 보안의 Availability 만족
• 플랫폼, 인프라의 다양성: 다양한 플랫폼과 인프라는 버그나 취약점을 줄이고, 유연성과 안정성을 높인다. single point failure 등을 방지할 수 있다.
• 클라우드 기반 보안 기능(Functions) 제공
  • 이메일 필터링:이메일이 SMTP를 거쳐 전달되는 과정에서 클라우드 기반 필터링 추가
  • DDoS보호: 앞서 다룬 리소스의 차이 뿐만 아니라, 클라우드 자체 보호 서비스도 갖추어져 있다. (서버 앞에 프록시 서버 배치)
  • 네트워크 모니터링: 클라우드 솔루션은 고객의 하드웨어 요구사항을 완화, 모니터링 및 사고 대응 전문성 제공

 

클라우드 저장소는 기본적으로 데이터를 암호화하거나 보호하는 방식으로 보안을 제공하지만, 적용되는 보안 모델과 방식에 따라 보안 수준이 달라지기도 한다.

• 기본적인 암호화 방식 : 대부분의 클라우드 저장소는 데이터를 암호화하거나 암호화하지 않고 저장(거의 단일키로 암호화)
• 개선된 기밀성 제공 : 일부 클라우드 서비스는 사용자가 제공한 비밀번호 또는 고유 비밀을 기반으로 사용자별 키를 생성하여 데이터 암호화를 강화한다.
• Maximum Confidentiality(기밀성)을 위한 모델 TNO : 이 모델을 채택한 서비스는 제공자도 복호화가 불가능하도록 설계된 모델

 

TNO 모델

중요한 데이터를 저장하려면 TNO 모델

Lastpass는 비밀번호 관리 서비스로, 사용자의 비밀번호를 안전하게 저장하고 관리하는데 TNO 모델을 사용한다.

Lastpass TNO는 3가지 구간이 존재한다. User, Lastpass Client, Lastpass Server(신뢰할 수 없는 구간)

인증 및 암호화 과정:
사용자 입력(마스터 비밀번호) -> 비밀번호 해시(SHA-256으로 5000번해싱) -> 서버 인증 수행 -> 데이터베이스 복호화 -> 비밀번호 접근  의 순서로 이루어진다. 

서버는 사용자의 마스터 비밀번호나 복호화 키를 알 수 없음

클라이언트 측에서 복호화를 하여 데이터 기밀성을 보장한다.

 

 

 

Boxcryptor는 파일 암호화 및 클라우드 저장소 서비스를 제공한다. 마찬가지로 TNO를 통해 데이터를 보호한다.

권한을 주고 싶은 파일에만 복호화 권한을 주는 것이 가능하다. 

유저, Boxcryptor 클라이언트, 클라우드 저장소 제공자 3가지 구간이 존재하며 암호화와 복호화는 아래 과정으로 이루어진다. 

 

파일 암호화 과정

: 파일 추가 -> 파일 키 생성(하나의 파일에 하나의 key) -> 파일 키 암호화(유저의 RSA public key) -> 파일 및 키 저장

 

파일 복호화 과정

: 파일 요청 -> 파일 및 키 검색 -> 파일 키 복호화 -> 파일 복호화 -> 파일 반환

 

 

암호화 및 복호화는 클라이언트 측에서만 수행하고, 클라우드 제공자는 암호화된 파일만 보유하고 내용을 알 수 없다.

 

TNO 모델은 사용자가 암호화 키를 직접 관리함으로써, 데이터 보안과 기밀성을 극대화한다.

 

 

데이터 손실 방지(Data Loss Prevention-DLP)와 클라우드 환경

데이터손실방지는 민감 데이터 유출과 손실을 막는 보안 솔루션이다. 클라우드는 데이터의 입출구 지점에 대한 통제력이 부족하기 떄문에 DLP를 하는것은 어렵다.

 

이를 해결하기 위해 VPN을 통해 접근을 강제하거나(VPN만으로 통신하도록), 유저 컴퓨터에 DLP 에이전트(민감 데이터의 로컬 저장 및 전송을 모니터링)를 설치하거나,  DLP 서버(데이터의 입출력을 검사하고 정책 적용)를 프록시로 사용하는 방법 등이 있다.

 

Cloud Application 보안

클라우드 환경에서 애플리케이션은 다양한 보안 위협에 직면한다.

앞서 다룬 클라우드의 특성대로, 클라우드는 여러 사용자가 같은 리소스(저장소,메모리,프로세서,네트워크 등)를 공유하게 되는데,
취약한 애플리케이션과 시스템을 공유할 경우 공격자가 이를 통해 리소스를 손상시키고, 공유되는 다른 애플리케이션으로 공격을 확산시킬 수 있다. (ex. 암호화 기반 사이드 채널 공격)

이처럼 공유 리소스에 대한 공격으로 인해 간접적으로 영향을 받을 위험이 증가한다. 

 

혹은 클라우드 서비스 제공자가 잘못 설계되었거나 취약한 API를 사용하는 경우, 이로 인해 공격의 원인이 될 수 있다. 사용자의 보안 설정과는 별개로 공격에 노출될 위험이 존재한다. 

(AWS에서도 생긴 문제이다.)

 

연합 아이덴티티 관리(Federated Identity Management-FIdM)와 인증 표준

FIdM은 하나의 아이덴티티 관리 시스템을 사용해 여러 시스템과 서비스에서 인증 및 권한 부여를 처리하는 방식이다.

중요한 데이터를 분산시켜서 관리하는 것도 부담이 될 수 있다.  FIdM을 통해, 사용자는 여러 서비스에 대해 별도의 계정을 만들 필요 없이, 단일 인증으로 접근 가능하다.

사용자가 단일 인증으로 편하게 여러 서비스에 접근할 수 있을 뿐만 아니라 인증에 대한 데이터를 한 곳에서만 관리하게 되기 때문에 보안적으로도 강화가 가능하다.

ex) 구글 아이디 로그인

작동 방식

사용자가 서비스 제공자(SP)에게 접근 요청 -> SP는 사용자를 아이덴티티 관리 시스템(IdM)으로 리디렉션 -> IdM이 사용자 인증 자격을 확인하고, 인증 요청 처리 -> IdM이 SP로 인증 및 권한 부여 응답을 반환 -> 사용자가 SP의 리소스에 접근

 

여기서 IdM은 인증 뿐 아니라 접근 권한이나 역할 등을 관리하는 것도 가능

 

이러한 FIdM의 대표적인 예시 3가지를 살펴보자

SAML(Security Assertion Markup Language)

SAML은 XML 기반 표준으로, 시스템 간 사용자 아이덴티티와 권한 정보를 안전하게 교환하기 위한 프레임워크다.

(ex) 학교 이메일 구글로그인 -> 학교 포털에서 로그인)

 

주로 기업에서 클라우드 서비스에 직원 계정을 통합적으로 제공하기 위해 사용하고, 직원이 퇴사하면 회사 자격증명이 비활성화 되고 서비스 접근 권한도 자동으로 종료된다.

 

작동 방식

사용자가 서비스 제공자(SP) 사이트에 로그인 요청 -> SP가 브라우저를 IdP(Identity Provider)로 리디렉션 -> IdP가 사용자 인증 후, 인증 응답을 브라우저로 반환 -> 브라우저가 인증 응답을 SP에 전달 -> SP가 인증 정보를 확인하고, 사용자에게 리소스 접근을 허용

 

 

OAuth

권한 부여 표준이다. 제 3자 애플리케이션이 사용자를 대신하여 API에 접근할 수 있도록 허용(권한 부여)한다. (ex. SNS 아이디로 로그인)

 

사용자는 자신의 SNS 계정으로 인증을 하고, 계정의 특정 리소스만 접근하도록 제 3자 애플리케이션에 권한을 부여하며, 

비밀번호와 같은 인증 정보를 공유할 필요 없이 권한 및 특정 데이터만 공유하는것이 가능해진다.

또한 언제든 접근 권한을 철회할 수 있다.

권한 부여 흐름

1. 리소스 소유자(사용자)는 애플리케이션에게 리소스 접근 권한을 부여
2. 클라이언트(App)은 사용자를 대신해 승인 토큰을 인증 서버에 요청
3. 인증 서버는 클라이언트를 인증(Authentication)하고 승인 토큰을 발행(이때 줄 수 있는 권한을 추려서 유저에게 고르도록 함)
4. 이후로는, 토큰으로 통신이 진행되며, 리소스 서버가 승인 토큰을 검증한 후 요청된 리소스에 접근을 허용

 

OpenID Connect(OIDC)

OIDC는 OAuth2.0를 확장하여 인가(Authorization) 권한 부여 기능을 추가한 표준이다.

OAuth가 권한 부여에 중점을 뒀다면, OIDC는 인증과 권한 부여를 모두 포함한다.

 

OIDC는 아이덴티티 정보도 권한의 일부로 처리한다. 이 또한 클라우드 환경에서 사용자 경험과 보안을 동시에 강화하는 핵심 기술이다.

 

OAuth와 비슷한 인증 로직을 가지고 있으나 조금 차이가 있다. 

 

인증 흐름은 다음과 같다. 

 

1. 사용자가 서비스 접근 요청 :사용자가 OIDC를 지원하는 서비스(Relying Party, 클라이언트)에 리소스 접근을 요청.

2. 클라이언트가 인증 요청 준비 : 클라이언트는 사용자를 인증하기 위해 Authorization Server(인증 서버)로 요청을 전달할 준비를 함.

3. 인증 서버로 리디렉션 : 사용자는 인증 서버로 리디렉션되어 로그인 정보를 입력.

4. 사용자 인증 : 인증 서버가 사용자의 로그인 자격증명을 확인, 사용자가 클라이언트가 요청한 "동의 범위(Scope)"에 대해 승인을 결정.

5. Authorization Code 반환 : 사용자가 동의하면, 인증 서버가 클라이언트에 Authorization Code를 반환.

6. Authorization Code 교환 : 클라이언트는 Authorization Code를 Authorization Server로 전송하여 Access Token과 ID Token을 요청.

7. Access Token과 ID Token 수령 : 인증 서버가 클라이언트에게 Access Token과 ID Token을 반환
(Access Token은 리소스 접근 권한, ID Token은 사용자의 인증 정보를 포함한 JSON Web Token(JWT) 등)

8. 사용자 정보 요청 : 클라이언트는 Access Token을 사용해 사용자 정보(UserInfo)를 인증 서버로부터 요청.

9. 사용자 인증 완료 : 클라이언트는 ID Token과 사용자 정보를 바탕으로 사용자를 인증하고, 요청된 서비스에 접근을 허용.

 

사용자 인증 정보뿐 아니라 리소스 접근 권한의 인가 포함한다는 점과 웹뿐 아니라 모바일/데스크탑 애플리케이션에서도 효과적으로 작동하는 것이 특징이다.

 

 

IaaS 보안 가이드: 클라우드 기반 인프라를 안전하게 관리하는법

지금까지 다양한 클라우드 서비스의 보안적 측면을 다루었는데,
특히나 클라우드 서비스 모델 IaaS는 사용자가 네트워크, 서버, 스토리지 등 물리적 인프라를 가상화 하여 사용하여 유연성이 보장되는 만큼, 보안에 대한 문제가 함께 따라온다. (low-level에서의 공유이기 때문에 보안 설정도 신경쓸게 많다.)

 

보안 도전 과제

• 공유 스토리지(Shared Storage) 위험성: 스토리지가 해제되면 다른 사용자에게 재할당 될 수 있어 데이터가 노출될 위험이 있다. 
  -> 데이터를 암호화된 저장 볼륨으로 관리해 안전성을 보장하여 해결할 수 있다.
• 공유 네트워크(Shared Network) 문제점: IaaS환경에서는 여러 사용자가 동일한 네트워크를 공유한다. 이로 인해 트래픽을 스니핑 하는 공격 가능성이 존재한다 -> 모든 네트워크 트래픽(가상 머신 간 포함)을 암호화하여 안전한 데이터 전송을 보장하여 해결 가능
• 호스트 접근(Host Access) 문제: 호스트 계정의 접근은 높은 권한을 가지고 있다.
  -> 따라서 높은 보안 수준을 요구해야한다(2단계 인증 적용, 계정 공유 X, 최소한의 권한 부여, 가능한 OAuth, FIdM 사용)

Iaas는 하드웨어에 대한 권한이 사용자에게 모두 있는 것도 아니고, 공유가 되기도 하는 환경이므로

클라우드의 장점을 살리면서도, 안전성을 챙길 수 있게 보안 아키텍처를 잘 설계해야 한다.

IaaS 보안 아키텍처

• Boundary Protection Enclave: 인터넷에서 들어오는 트래픽을 첫 번째로 방어
• FTP/Web Proxy, Encalve: FTP 서버 혹은 웹 서버를 직접 노출하지 않고 프록시를 통해 요청을 처리한다. 프록시와 서버를 별도로 관리하여 보안성을 강화한다. (Encalve는 통신하려면 통과해야하는, 보안 구역이나 격리된 환경을 의미한다)
  • 가상화된 데이터를 생성하는 것이 가능하다. 
  • 방화벽 규칙도 작성하기 쉬워진다.
    방화벽은 블랙리스트 방식과 화이트리스트 방식으로 나뉘는데, 화이트리스트 방식이 좀 더 안전하지만 시스템이 복잡하면 구현하기가 힘들다. 이렇게 각 요소를 분리해서 간단화를 시켜 화이트리스트 방식을 채택할 수 있다

이러한 구조로, 기능들을 작게 만들어서 모듈을 만들고 다양한 가상 프록시,Enclave를 통해서 통신하도록 만들 수 있다.