인사이트리포트

들어가며

클라우드 컴퓨팅은 현대 기업과 개인들이 데이터를 저장하고, 애플리케이션을 배포하며, IT 인프라를 관리하는 방식을 혁신적으로 바꾸었고 바꾸고 있다. 클라우드 서비스의 편리성과 확장성 덕분에 많은 조직이 클라우드를 채택하고 있기 때문이다. 하지만 클라우드 환경에서의 정보보안은 큰 도전이 되기도 한다. 클라우드 서비스 제공자와 사용자 모두에게 적절한 보안 조치를 취해야 하는 책임이 있기 때문이다.

이 글에서는 클라우드 환경에서의 정보보안을 위한 기반 기술에 대해 알아보고, 이러한 기술들이 어떻게 클라우드 인프라를 보호하고, 사용자와 데이터의 프라이버시를 지키며, 클라우드 서비스와의 상호 작용을 안전하게 유지하게 하는지 알아보고자 한다.

또한, 암호화, 인증 및 권한 관리, 네트워크 보안, API 보안, 로깅 및 모니터링 등 클라우드 보안 기술들에 대해 소개하고, 각 기술이 어떻게 동작하는지, 그리고 클라우드 환경에서 어떻게 구현되어야 하는지에 대해 살펴보고자 한다. 이를 통해 클라우드 환경에서의 정보보안에 대한 이해를 높이고, 조직이 클라우드를 효과적으로 활용하면서도 안전하게 보호할 수 있는 방법을 배우는데 도움이 되었으면 한다.

데이터 보안

암호화 기술

정보보안의 가장 기본이 되는 기술인 키 암호화에 대해 먼저 살펴보겠다.

대칭키와 비대칭키는 암호화에 사용되는 키의 종류로, 각각 다음과 같은 개념과 장단점을 가지고 있다.

  대칭키 (Symmetric Key) 암호화

대칭키 암호화에서는 암호화와 복호화에 동일한 키를 사용한다. 보내는 측과 받는 측이 같은 키를 공유해야 하며, 이 키를 안전하게 전달하는 것이 중요한 포인트다.

[장 점]

• 대칭키 암호화는 비대칭키 암호화에 비해 연산 속도가 빠르고, 처리량이 큰 데이터에 효율적이다.
• 대부분의 대칭키 암호화 알고리즘은 검증된 보안성을 제공한다(예: AES, 3DES 등).

[단 점]

• 키 관리가 어려워서 키를 안전하게 공유하고 저장하는 것이 중요한데, 이 과정에서 발생할 수 있는 보안 위험을 최소화해야 한다.
• 대규모 시스템에서 다수의 사용자와의 통신에 대한 키 관리가 복잡해질 수 있다.

 비대칭키 (Asymmetric Key) 암호화

비대칭키 암호화에서는 암호화와 복호화에 서로 다른 키를 사용한다. 일반적으로 공개키(Public Key)와 개인키(Private Key)의 쌍으로 구성되며, 공개키로 암호화한 데이터는 개인키로만 복호화 할 수 있다.

[장 점]

• 대칭키 암호화에 비해 키 관리가 상대적으로 용이하다. 공개키는 안전한 공유가 가능하므로, 키 교환 문제가 크게 감소한다.
• 디지털 서명 기능을 제공하여, 메시지의 무결성과 인증에 대해 검증할 수 있다.
• 다수의 사용자와의 통신에 대한 키 관리가 비교적 간단하다.

[단 점]

• 대칭키 암호화에 비해 연산 속도가 느리고, 처리량이 큰 데이터에는 비효율적일 수 있다.
• 비대칭키 암호화 알고리즘의 보안성이 키 길이에 더 크게 의존하기 때문에 긴 키를 사용해야 보안성을 유지할 수 있으며, 이로 인해 연산이 더 복잡해질 수 있다.

대칭키와 비대칭키 암호화는 각각의 장단점을 고려하여 서로 보완하는 방식으로 사용되고 있다.

메시지 인증 코드 (HMAC)

HMAC(Hash-based Message Authentication Code)은 메시지 인증을 위한 암호화 기술로, 데이터 무결성과 인증을 보장하기 위해 사용된다. HMAC은 해시 함수와 비밀 키를 사용하여 메시지를 전송하는 도중에 변조되지 않았음을 확인하는 인증 코드를 생성하는 방식으로 클라우드 환경에서도 API 요청의 인증 및 무결성 검증에 사용될 수 있다.

HMAC의 동작 과정은 다음과 같다.

1. 비밀 키(secret key)와 메시지를 입력 받는다.
2. 비밀 키를 사용하여 메시지를 변형시키고 해시 함수를 적용하여 고정 길이의 출력값을 생성한다.
3. 생성된 출력값은 메시지 인증 코드로 사용되며, 이를 수신자와 공유하여 메시지의 무결성과 인증에 대해 확인할 수 있게 된다.

HMAC은 다양한 해시 함수와 함께 사용될 수 있는데, 예를 들어, HMAC-SHA256은 SHA-256 해시 함수를 사용하는 HMAC 알고리즘으로 HMAC은 데이터 통신, API 인증, JSON Web Token (JWT) 등에서 사용되며, 키와 해시 함수의 조합으로 안전하게 메시지 인증을 수행할 수 있다.

HMAC은 메시지의 무결성과 인증에 대해 검증해 주지만 메시지 자체가 도청되거나 중간자 공격에 노출될 수 있기 때문에 이러한 위험을 해소하기 위해 일반적으로 HTTPS를 함께 사용하여 SSL/TLS 프로토콜을 통해 메시지를 암호화하여 전송한다.

접근 제어

인증, 권한

클라우드에서의 정보보안을 이해하기 위해서는 인증(Authentication)과 권한(Authorization)이라는 용어를 이해하고 구분하는 것은 매우 중요하다.

• 인증 (Authentication): 인증은 사용자의 신원을 확인하는 과정으로 사용자 이름과 비밀번호를 사용하여 로그인하는 것이 인증 과정의 일반적인 예라 할 수 있다. 인증은 사용자가 시스템에 접근하기 전에 그들이 누구인지 확인하는 첫 번째 단계로 보안을 강화하기 위해 다단계 인증(MFA, Multi-Factor Authentication)을 사용할 수도 있으며, MFA는 추가 인증 수단(예: 하드웨어 토큰, 휴대전화 앱, 생체 인식)을 요구하여 사용자의 신원을 더 확실히 확인하기도 한다.
• 권한 (Authorization): 권한은 인증된 사용자가 시스템에서 수행할 수 있는 작업에 대한 제한을 설정하는 과정을 말한다. 일반적으로 권한은 역할, 그룹 또는 사용자 별로 정책을 통해 관리되며, 최소 권한 원칙에 따라 필요한 권한만 부여해야 한다. 권한은 사용자가 어떤 리소스에 접근할 수 있는지, 어떤 작업을 수행할 수 있는지를 결정하게 된다.

인증 기술

  쿠키, 세션 및 토큰 기반 인증

HTTP (Hypertext Transfer Protocol) 프로토콜은 각 요청이 독립적이고 서로간에 관련이 없는(stateless) 특성이 있다.

웹에서 클라우드 서비스를 사용할 때는 먼저 서비스에 로그인 한 후, 이어지는 요청을 처리하기 위해서, 로그인한 사용자의 인증 및 상태 정보를 관리하기 위한 다음의 기술이 요구된다.

이러한 기술들은 웹 서비스의 요구사항, 보안성, 확장성 등에 따라 상황에 맞게 적절한 방법을 선택 및 조합할 수 있다.

• 쿠키 (Cookie): 쿠키는 클라이언트 측(브라우저)에 저장되는 작은 텍스트 파일로, 서버와 클라이언트 간 상태 정보를 저장하는 데 사용된다. 쿠키는 사용자 인증 정보, 세션 ID, 사용자 환경 설정 등의 데이터를 저장할 수 있으며, 웹 브라우저는 쿠키를 통해 정보를 저장하고, 서버에 요청을 보낼 때 해당 쿠키를 포함하여 전송한다. 이를 통해 서버는 사용자를 식별하고 상태 정보를 유지할 수 있다. 쿠키는 만료 기간을 설정할 수 있으며, 보안을 위해 HttpOnly 및 Secure 플래그를 사용할 수 있다.
• 세션 (Session): 세션은 서버 측에서 사용자 상태 정보를 저장하는 기술을 말한다. 세션은 사용자가 웹 사이트에 로그인할 때 생성되며, 일정 기간 동안 유지된다. 세션은 고유한 세션 ID를 사용하여 사용자를 식별하며, 이 ID는 쿠키를 통해 클라이언트에 전송된다. 클라이언트는 서버에 요청을 보낼 때 세션 ID를 포함하여 전송하고, 서버는 이를 통해 해당 사용자의 세션 데이터에 접근한다. 세션은 쿠키에 비해 상대적으로 더 안전한 방법으로 사용자 정보를 저장할 수 있다.
• 토큰 (Token): 토큰은 클라이언트와 서버 간 인증 및 권한 정보를 전달하는 데 사용되는 암호화된 문자열로 토큰 기반 인증 방식에서는 사용자가 로그인하면 서버에서 토큰을 생성하고 클라이언트에 전송한다. 클라이언트는 이 토큰을 저장하고, 서버에 요청을 보낼 때 헤더에 토큰을 포함하여 전송한다. 서버는 토큰을 검증하여 사용자를 식별하고 권한을 확인한다. 토큰 기반 인증에서 널리 사용되는 표준으로 JSON Web Token (JWT)이 있다.

쿠키, 세션, 토큰은 각기 서로 다른 장∙단점을 가지고 있다.

• 쿠키는 클라이언트 측에서 사용자 정보를 저장하는 가장 기본적인 방법으로 쿠키를 사용하면 서버의 부하를 줄일 수 있지만, 클라이언트 측에 정보가 저장되기 때문에 보안 측면에서 취약할 수 있다.
• 세션은 서버 측에서 사용자 정보를 저장하므로 쿠키에 비해 상대적으로 보안성이 높다. 그러나 세션을 사용하면 서버에 부하가 증가하기 때문에 대규모 웹 애플리케이션에서 세션 정보를 관리하는 것이 어려울 수 있다.
• 토큰 기반 인증은 클라이언트와 서버 간 인증 정보를 전달하는 데 사용되는 암호화된 문자열로, 상태를 저장하지 않는 RESTful 서비스와 잘 호환된다. 따라서, 토큰은 서버의 부하를 줄이고 확장성을 높이며, 다양한 플랫폼과 서비스 간 인증을 쉽게 처리할 수 있다. 하지만, 토큰을 사용할 때는 토큰의 보안과 만료 관리를 신중하게 처리해야만 한다.

  JWT (JSON Web Token)

JWT는 클라이언트와 서버 간에 정보를 안전하게 전달하기 위한 개방형 표준이며 (RFC 7519), 3가지 구성 요소로 이루어져 있다.

• Header: 헤더는 주로 토큰의 유형(JWT)과 사용되는 알고리즘(HS256, RS256 등)에 대한 정보를 포함하고 Base64Url로 인코딩된다.
• Payload: 페이로드는 클레임(claim)이라 불리는 토큰에 포함된 데이터를 담고 있는데 클레임은 사용자 정보, 권한 등의 데이터를 포함할 수 있다. 페이로드는 Base64Url로 인코딩된다.
• Signature: 서명은 헤더와 페이로드를 검증하기 위한 목적으로 사용되며, 헤더, 페이로드, 비밀 키(secret key)를 사용하여 생성되고, 이를 통해 토큰의 무결성을 보장할 수 있게 된다.

JWT는 각 구성 요소를 점(.)으로 연결하여 하나의 문자열로 나타내게 되는데, 예를 들어보면, header.payload.signature와 같은 형식을 가지게 된다.

ID Federation (SAML, OAuth, OpenID Connect)

SSO는 Single Sign-On의 약자로, 여러 서비스 또는 애플리케이션에 대해 한 번의 로그인 과정으로 모든 서비스에 접근할 수 있는 인증 방식이다. SSO는 사용자 경험을 향상시키고, 비밀번호 관리를 간소화하며, 보안을 강화하는 데 도움이 된다.

클라우드에서는 클라우드 계정과 클라우드에 올라가는 애플리케이션 그리고 클라우드를 사용하는 회사의 계정 시스템 간에 사용자 인증 및 권한 부여 정보를 공유하고 인증 절차를 공동으로 수행하는 보안 방식을 말하며 이를 ID Federation(Identity Federation)이라 한다.

ID Federation의 핵심 구성 요소는 다음과 같다:

• Identity Provider (IdP): 사용자 인증 정보를 저장하고 관리하는 중앙화된 시스템으로 사용자가 로그인을 요청할 때, IdP는 인증을 수행하고 필요한 인증 정보를 제공한다.
• Service Provider (SP): 사용자가 접근하려는 서비스 또는 애플리케이션으로 SP는 사용자의 인증 정보를 IdP로부터 전달받아 인증을 확인하고, 서비스에 대한 접근을 허용한다.

ID Federation은 여러 가지 기술과 프로토콜을 사용하여 구현할 수 있는데 대표적인 ID Federation 프로토콜로는 SAML (Security Assertion Markup Language), OAuth, OpenID Connect 등이 있다. 이러한 프로토콜들은 인증 정보를 공유하고 전달하는 방식으로 서로 다른 시스템이나 도메인 간의 ID Federation을 지원한다.

SAML, OAuth, OpenID Connect는 모두 인증 및 권한 부여에 사용되는 표준 프로토콜로, 각각 다른 개념을 가지고 있기 때문에 사례별로 적합한 프로토콜을 사용하는 것이 필요하다.

  SAML (Security Assertion Markup Language)

SAML은 XML 기반의 표준으로, 주로 Single Sign-On (SSO)에 사용되며, 서비스 제공자(Service Provider, SP)와 아이덴티티 제공자(Identity Provider, IdP) 간에 인증 및 권한 부여 정보를 교환한다. 이때 SAML은 사용자 인증 정보를 포함하는 SAML 응답을 생성하여 서비스 제공자가 인증을 수행하도록 돕는다. 주로 기업 환경에서 사용되며, 웹 기반 SSO를 구현하는 데 적합하다.

  OAuth

OAuth는 인터넷 서비스 간 권한 부여를 위한 오픈 스탠다드 프로토콜이다. OAuth를 사용하면 사용자가 자신의 계정 정보를 공유할 필요 없이 서드 파티 애플리케이션에 자신의 데이터에 대한 접근 권한을 부여할 수 있다. OAuth 2.0은 현재 가장 널리 사용되는 버전으로, RESTful API를 위한 권한 부여 방식을 제공한다.

  OpenID Connect (OIDC)

OpenID Connect는 OAuth 2.0 기반의 인증 프로토콜로, 인터넷 사용자에 대한 인증을 수행하는 데 사용된다. OpenID Connect는 기본적으로 OAuth 2.0 위에 구축되어 있으며, 사용자의 인증 정보를 JSON Web Token (JWT) 형식으로 표현한다. 이 프로토콜은 사용자 인증을 위한 간단한 레이어를 제공하며, 다양한 클라이언트 애플리케이션에 적합하다.

위에서 설명한 프로토콜 간의 주요 차이점은 다음과 같다:

• 목적: SAML은 주로 웹 기반 SSO를 구현하는 데 사용되며, OAuth와 OpenID Connect는 API 권한 부여 및 인증에 사용된다.
• 데이터 형식: SAML은 XML 기반의 데이터 형식을 사용하고, OAuth와 OpenID Connect는 JSON을 사용한다.
• 인증 및 권한 부여: SAML은 인증 및 권한 부여에 모두 사용되지만, OAuth는 주로 권한 부여에 초점을 맞추고 있고, OpenID Connect는 OAuth 위에 인증 레이어를 추가하여 인증에 사용된다.
• 사용 사례: SAML은 기업 환경에서 웹 기반 애플리케이션의 SSO를 구현하는 데, OAuth는 서드 파티 애플리케이션에게 사용자의 데이터에 대한 접근 권한을 부여하는 데 사용된다. OpenID Connect는 다양한 클라이언트 애플리케이션에 대한 인증을 제공하는 데 사용되며, 특히 모바일 애플리케이션 및 웹 기반 클라이언트에서 인증을 단순화하는 데 적합하다.

결국, SAML, OAuth, OpenID Connect 모두 인증 및 권한 부여에 사용하는 프로토콜이지만, 목적과 사용 사례에 따라 적합한 프로토콜을 선택하는 것이 더 중요하다고 하겠다. SSO, API 권한 부여, 클라이언트 인증 등의 요구 사항을 고려하여 각 프로토콜의 장점을 활용하면 보다 안전하고 효율적인 인증 및 권한 부여 솔루션을 구현할 수 있다.

권한 부여

RBAC, ABAC

Role-Based Access Control (RBAC)과 Attribute-Based Access Control (ABAC)은 클라우드에서 시스템에 대한 접근을 제어하는 데 사용되는 인증 및 권한을 부여하는 모델로서 사용자에게 특정 리소스에 대한 접근 권한을 부여하는 방식에서 차이가 있다.

 Role-Based Access Control (RBAC)

RBAC은 사용자의 역할(직책, 직급, 그룹 등)에 기반하여 접근 권한을 부여하는 모델이다. 사용자는 하나 이상의 역할을 가질 수 있으며, 각 역할에는 특정 리소스에 대한 접근 권한이 할당된다.

RBAC의 주요 특징은 다음과 같다:

• 사용자가 속한 역할에 따라 시스템의 리소스에 대한 접근 권한이 결정된다.
• 중앙 집중식 권한 관리가 가능하여, 권한 변경 시 역할별로 일괄적으로 적용할 수 있다.
• 역할 간의 상속을 통해 권한을 계층적으로 구성할 수 있다.

  Attribute-Based Access Control (ABAC)

ABAC은 사용자, 리소스, 환경 및 동작과 같은 다양한 속성에 기반하여 접근 권한을 부여하는 보다 유연한 모델로서 ABAC은 정책 기반 접근 제어로도 불리며, 접근 제어 정책을 속성 조합을 사용한 규칙으로 정의한다.

ABAC의 주요 특징은 다음과 같다:

• 다양한 속성 조합으로 접근 권한을 세밀하게 설정할 수 있다.
• 동적 환경에서도 효과적인 접근 제어가 가능하다.
• 정책을 통해 접근 제어 로직을 중앙 집중식으로 관리할 수 있다.

RBAC과 ABAC은 각각 다른 시나리오와 요구 사항에 적합하다고 할 수 있는데 간단히 설명하면, RBAC은 계층적이고 명확한 역할 구조가 있는 조직에서 적합하며, ABAC은 더 복잡하고 다양한 속성을 고려해야 하는 환경에서 유용하다. 실제 시스템에서는 RBAC과 ABAC을 결합하여 사용하기도 한다.

API 보안

API 키 인증

API 키 인증은 웹 서비스와 API를 사용할 때, 서버가 사용자를 식별하고 권한을 부여하기 위해 사용하는 간단한 인증 방식으로 API 키는 고유한 문자열로 구성되며, 사용자 또는 애플리케이션에 할당되어 서버와 클라이언트 간의 통신에 사용된다.

API 키 인증의 작동 원리는 다음과 같다:

1. 사용자 또는 애플리케이션은 API를 사용하기 위해 서비스 제공자로부터 API 키를 발급받는다.
2. API 요청 시, 사용자 또는 애플리케이션은 발급받은 API 키를 요청 헤더나 쿼리 파라미터에 포함하여 전송한다.
3. 서버는 요청에 포함된 API 키를 검증하여 요청이 유효한 사용자 또는 애플리케이션으로부터 온 것임을 확인한다.
4. API 키가 유효하다면, 서버는 요청을 처리하고 응답을 반환하지만 그렇지 않은 경우, 인증 실패 메시지를 반환한다.

API 키 인증의 장점:

• 구현 및 사용이 간단하며, 서버와 클라이언트 간의 인증 과정이 빠르다.
• 사용자 및 애플리케이션 별로 API 키를 발급하고 관리할 수 있어, 요청 트래픽을 추적하고 사용량 제한을 적용할 수 있다.

API 키 인증의 단점:

• API 키가 노출되면, 제3자에 의해 사용될 수 있는 보안 위험이 존재하기 때문에 중요한 정보를 전송하는 경우에는 추가적인 보안 조치가 필요하다.
• API 키 인증은 단일 요소 인증 방식이기 때문에, 더 복잡한 인증 및 권한 부여 요구 사항에는 적합하지 않을 수 있다. 이러한 경우, OAuth, OpenID Connect와 같은 다중 요소 인증 및 권한 부여 프로토콜을 추가로 사용하는 것이 바람직하다.

마치며

지금까지 설명한 여러 기반 기술 외에도 클라우드에서는 네트워크 보안, 시스템 및 애플리케이션 보안, 로깅 및 모니터링 등 다양한 보안 기술을 사용하고 있다.

이러한 보안 기술들을 사용하는 것과 더불어 클라우드 환경에서는 정보보안에 대한 지속적인 관리와 평가가 필요하며, 기술 발전에 따라 반드시 적절한 보안 대책을 수립하고 업데이트해야 한다.

이와 같은 기술과 정책으로 체계화된 클라우드 정보보안을 통해 기업과 개인 모두 클라우드 환경에서 보다 안전하게 리소스를 사용하고 데이터 보호를 실현할 수 있게 될 것이다.