.jpg)
.jpg)
구글, 사용자의 데이터를 외부와 내부에서 어떻게 보호하는가?
외부에서 들어오는 데이터 반만 신뢰...TLS보다는 ALTS
[보안뉴스 문가용 기자] 보안 사고와 위협에 바람 잘 날 없는 구글이 두 개의 백서를 발표했다. 구글이 데이터를 어떤 식으로 보호하고 있는지에 관한 내용이다. 그 중 하나는 ‘움직이고 있는 데이터’에 관한 것이고, 다른 하나는 애플리케이션 레이어 트랜스포트 시큐리티(ALTS)를 사용한 서비스 간 통신에서의 데이터 보호에 관한 것이다.
.jpg)
구글은 “데이터를 어떤 식으로 보호하는가?”라는 질문을 자주 받는 업체 중 하나라고 구글 클라우드 보안과 프라이버시 제품 책임자인 마야 칵조로우스키(Maya Kaczorowski)는 발간 배경에 대해 설명한다. 그러한 궁금증을 풀어주기 위한 백서답게 구글의 데이터 무결성, 프라이버시, 진위라는 주제는 물론 데이터 출처 확인, 이동 중에도 데이터를 보호하는 방법 등도 다루고 있다.
마야의 설명에 따르면 ‘움직이고 있는 데이터’에 관한 백서의 골자는 “사용자로부터 구글에까지 데이터는 어떻게 움직이고 있는가”와 “그 정보는 구글 인프라 내에서 어떻게 움직이는가”라고 한다. “사용자가 구글 클라우드로 정보를 전송하면, HTTPS와 TLS를 활용해 암호화처리 되는 게 디폴트입니다. 구글은 구글 인프라 밖에서 돌아다니는 데이터에 대해서는 보다 엄격한 보안 장치를 적용합니다.”
구글 클라우드(Google Cloud)는 데이터가 구글의 물리적 통제 영역 밖으로 이동할 때 여러 네트워크 층위에서 데이터를 암호화하고 인증 장치를 덧입힌다. 예외는 없다. 하지만 구글의 물리적 통제 영역 안에서 돌아다니는 데이터의 경우는 조금 다를 수 있다. 인증 장치를 통해서만 접근하는 건 동일하지만 암호화까지 필수인 건 아니기 때문이다. 일일이 암호화하지 않아도 되게끔 강력한 보안 체제가 갖춰져 있어서다.
또한 ‘퍼포먼스’도 이렇게 선택적인 보안 강구책을 사용하게 하는 요인이다. “구글 정도 되는 사업 규모를 가진 조직이라면, 퍼포먼스의 안정적인 유지가 대단히 중요해집니다. 위협의 수준과 성질과 더불어 사업적 퍼포먼스까지 고려해 데이터 보안 방법을 결정합니다.” 잠재적인 위협으로부터 데이터를 보호하기 위해서 구글은 “구글 외부의 네트워크 환경을 반쯤만 신뢰한다는 원칙을 고수”하고 있기도 하다.
구글 클라우드의 가상 네트워크 인프라는 구글의 영향력이 미치는 물리적 영역과 그렇지 않은 영역을 넘나드는 상황에서는 가상 기기들 사이를 오가는 데이터를 자동으로 암호화한다. “가장 중요한 건 구글 내의 데이터와 구글 바깥의 데이터가 같은 수준과 방법으로 보호되지 않는다는 겁니다.”
두 번째 백서를 통해 ALTS 프로토콜도 자세하게 다뤄졌다. ALTS 프로토콜은 공통의 인증 및 이동 암호화 시스템으로, 보통 구글 인프라 내 서비스 간 원격 절차 호출(Remote Procedure Call) 통신을 보호하는 데 사용된다. 구글 인프라 내 존재하는 내부 서비스들은 모두 서비스 계정 아이덴티티를 가지고 있으며, 인증에 사용되는 암호화 크리덴셜 역시 계정마다 부여된다.
구글 백서에 의하면 ALTS는 TLS와 비슷하지만 구글의 데이터센터들을 위해 특별히 개발된 것이라고 한다. ALTS는 두 가지 프로토콜로 분해가 가능한데, 바로 핸드셰이크(Handshake)와 레코드(Record) 프로토콜이다. 두 가지 전부 세션들이 어떤 식으로 설정되고 인증되며 암호화되고 중단됐다가 다시 시작되는지를 다루는 것이라고 한다.
또한 HTTPS에 관한 TLS와 ALTS의 신뢰 모델은 완전히 다르다고 구글은 설명한다. TLS의 신뢰 모델은 서버 아이덴티티를 한 가지 특정 이름 및 관련된 네이밍 정책에 묶어놓지만, ALTS의 신뢰 모델은 같은 서버 아이덴티티를 여러 개의 이름 및 관련 네이밍 정책들에 적용한다. 즉 보다 부하 균형을 맞추고, 마이크로서비스를 복제하는 데 있어 보다 유연하고 간편해진다는 뜻이다. 때문에 버그와 취약점 모니터링도 더 정확하고 쉬워진다고 구글은 설명한다.
하지만 TLS 대신 ALTS를 사용하기 때문에 치러야 하는 대가도 존재한다. ALTS는 내부 서비스 통신을 숨기지 않는다. 따라서 핸드셰이크 메시지를 암호화해서 아이덴티티들을 감출 수 없게 된다. 또한 ALTS 핸드셰이크 프로토콜은 키 침해 신분위장(Key Compromise Impersonation) 공격에 취약하다는 단점도 가지고 있다. 이 공격을 감행하면 공격자가 불법 워크로드를 정상 워크로드처럼 보이게 만들 수 있다.
그밖에 구글은 이동 중인 데이터 암호화를 위해 여러 옵션들을 다양하게 활용하고 있다. IPsec 터널, 무료 및 자동화된 TLS 인증서, 오픈소스 서비스 메시인 Istio 등이 바로 그것이다. 해당 백서는 이 주소(https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/)와 이 주소(https://cloud.google.com/security/encryption-in-transit/)에서 다운로드가 가능하다(영문).
[국제부 문가용 기자(globoan@boannews.com)]
외부에서 들어오는 데이터 반만 신뢰...TLS보다는 ALTS
[보안뉴스 문가용 기자] 보안 사고와 위협에 바람 잘 날 없는 구글이 두 개의 백서를 발표했다. 구글이 데이터를 어떤 식으로 보호하고 있는지에 관한 내용이다. 그 중 하나는 ‘움직이고 있는 데이터’에 관한 것이고, 다른 하나는 애플리케이션 레이어 트랜스포트 시큐리티(ALTS)를 사용한 서비스 간 통신에서의 데이터 보호에 관한 것이다.
[이미지 = iclickart]
구글은 “데이터를 어떤 식으로 보호하는가?”라는 질문을 자주 받는 업체 중 하나라고 구글 클라우드 보안과 프라이버시 제품 책임자인 마야 칵조로우스키(Maya Kaczorowski)는 발간 배경에 대해 설명한다. 그러한 궁금증을 풀어주기 위한 백서답게 구글의 데이터 무결성, 프라이버시, 진위라는 주제는 물론 데이터 출처 확인, 이동 중에도 데이터를 보호하는 방법 등도 다루고 있다.
마야의 설명에 따르면 ‘움직이고 있는 데이터’에 관한 백서의 골자는 “사용자로부터 구글에까지 데이터는 어떻게 움직이고 있는가”와 “그 정보는 구글 인프라 내에서 어떻게 움직이는가”라고 한다. “사용자가 구글 클라우드로 정보를 전송하면, HTTPS와 TLS를 활용해 암호화처리 되는 게 디폴트입니다. 구글은 구글 인프라 밖에서 돌아다니는 데이터에 대해서는 보다 엄격한 보안 장치를 적용합니다.”
구글 클라우드(Google Cloud)는 데이터가 구글의 물리적 통제 영역 밖으로 이동할 때 여러 네트워크 층위에서 데이터를 암호화하고 인증 장치를 덧입힌다. 예외는 없다. 하지만 구글의 물리적 통제 영역 안에서 돌아다니는 데이터의 경우는 조금 다를 수 있다. 인증 장치를 통해서만 접근하는 건 동일하지만 암호화까지 필수인 건 아니기 때문이다. 일일이 암호화하지 않아도 되게끔 강력한 보안 체제가 갖춰져 있어서다.
또한 ‘퍼포먼스’도 이렇게 선택적인 보안 강구책을 사용하게 하는 요인이다. “구글 정도 되는 사업 규모를 가진 조직이라면, 퍼포먼스의 안정적인 유지가 대단히 중요해집니다. 위협의 수준과 성질과 더불어 사업적 퍼포먼스까지 고려해 데이터 보안 방법을 결정합니다.” 잠재적인 위협으로부터 데이터를 보호하기 위해서 구글은 “구글 외부의 네트워크 환경을 반쯤만 신뢰한다는 원칙을 고수”하고 있기도 하다.
구글 클라우드의 가상 네트워크 인프라는 구글의 영향력이 미치는 물리적 영역과 그렇지 않은 영역을 넘나드는 상황에서는 가상 기기들 사이를 오가는 데이터를 자동으로 암호화한다. “가장 중요한 건 구글 내의 데이터와 구글 바깥의 데이터가 같은 수준과 방법으로 보호되지 않는다는 겁니다.”
두 번째 백서를 통해 ALTS 프로토콜도 자세하게 다뤄졌다. ALTS 프로토콜은 공통의 인증 및 이동 암호화 시스템으로, 보통 구글 인프라 내 서비스 간 원격 절차 호출(Remote Procedure Call) 통신을 보호하는 데 사용된다. 구글 인프라 내 존재하는 내부 서비스들은 모두 서비스 계정 아이덴티티를 가지고 있으며, 인증에 사용되는 암호화 크리덴셜 역시 계정마다 부여된다.
구글 백서에 의하면 ALTS는 TLS와 비슷하지만 구글의 데이터센터들을 위해 특별히 개발된 것이라고 한다. ALTS는 두 가지 프로토콜로 분해가 가능한데, 바로 핸드셰이크(Handshake)와 레코드(Record) 프로토콜이다. 두 가지 전부 세션들이 어떤 식으로 설정되고 인증되며 암호화되고 중단됐다가 다시 시작되는지를 다루는 것이라고 한다.
또한 HTTPS에 관한 TLS와 ALTS의 신뢰 모델은 완전히 다르다고 구글은 설명한다. TLS의 신뢰 모델은 서버 아이덴티티를 한 가지 특정 이름 및 관련된 네이밍 정책에 묶어놓지만, ALTS의 신뢰 모델은 같은 서버 아이덴티티를 여러 개의 이름 및 관련 네이밍 정책들에 적용한다. 즉 보다 부하 균형을 맞추고, 마이크로서비스를 복제하는 데 있어 보다 유연하고 간편해진다는 뜻이다. 때문에 버그와 취약점 모니터링도 더 정확하고 쉬워진다고 구글은 설명한다.
하지만 TLS 대신 ALTS를 사용하기 때문에 치러야 하는 대가도 존재한다. ALTS는 내부 서비스 통신을 숨기지 않는다. 따라서 핸드셰이크 메시지를 암호화해서 아이덴티티들을 감출 수 없게 된다. 또한 ALTS 핸드셰이크 프로토콜은 키 침해 신분위장(Key Compromise Impersonation) 공격에 취약하다는 단점도 가지고 있다. 이 공격을 감행하면 공격자가 불법 워크로드를 정상 워크로드처럼 보이게 만들 수 있다.
그밖에 구글은 이동 중인 데이터 암호화를 위해 여러 옵션들을 다양하게 활용하고 있다. IPsec 터널, 무료 및 자동화된 TLS 인증서, 오픈소스 서비스 메시인 Istio 등이 바로 그것이다. 해당 백서는 이 주소(https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/)와 이 주소(https://cloud.google.com/security/encryption-in-transit/)에서 다운로드가 가능하다(영문).
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] 
.jpg)
.jpg)
.jpg)
.jpg)
