Google 제로 트러스트 아키텍처 실습

배경 소개

이 글의 저자는 운 좋게도 2015년부터 2020년까지 구글의 프로덕션 환경에 참여한 Chen Zhijie입니다.제로 트러스트(제로 트러스트 인 프로덕션 환경) 이론 및 실제. 이러한 맥락에서 개발된 BAB(Binary Authorization for Borg) 시스템은 Google의 프로덕션 환경에서 전체 적용 범위를 달성했습니다. 누구든지 프로덕션 환경에서 패키지를 서비스로 실행하려면 먼저 대상 서비스에 대한 충분한 인증을 설정해야 합니다. 강력한 BAB 보안 정책. BAB 보안 정책을 준수하지 않는 프로그램은 해당 서비스의 실행이 허용되지 않습니다.

이러한 제로 트러스트 생산 환경을 구현하고 홍보하는 과정에서 BAB 팀은 많은 우회를 하면서도 많은 경험을 얻었습니다. BAB 팀은 2017년부터 이러한 실무 경험을 이론으로 전환하기 시작했으며 일련의 백서( 비욘드프로드, Borg에 대한 Binary Authorization, SLSA: 소프트웨어 아티팩트에 대한 공급망 수준), 책( 안전하고 안정적인 시스템 구축) 및 보고서( Anthos 보안을 통해 제로 트러스트 보안 모델로 발전, 제로 터치 제품). 동시에 이 제로 트러스트 개념은 퍼블릭 클라우드에 대한 제로 트러스트, 퍼블릭 클라우드 자체 인프라에 대한 제로 트러스트, Android 및 Android 개발에 대한 제로 트러스트를 포함하여 더 많은 애플리케이션 시나리오로 승격되기 시작했습니다. Chrome 자체와 해당 앱.

이번에 공유된 내용은 모두 위 구글이 공개한 정보를 바탕으로 한 것이며, 구글 회사의 비밀을 유출하거나 어떠한 비밀유지 계약도 위반하지 않습니다. 이 글의 결론은 작성자의 개인적인 견해일 뿐이며 반드시 Google의 공식적인 견해는 아닙니다.

제로 트러스트란 무엇인가요?

제로 트러스트란 무엇인가요? 사람들마다 다른 대답을 할 가능성이 높습니다. 제로 트러스트가 워크로드 마이크로 세분화라고 말하는 사람도 있고, 제로 트러스트가 지속적인 위협 모니터링이라고 말하는 사람도 있고, 제로 트러스트가 네트워크에 대한 신뢰를 피어 측(네트워크가 아닌 엔드포인트 신뢰)의 신뢰로 대체한다고 말하는 사람도 있고, 제로 트러스트가 지속적인 위협 모니터링이라고 말하는 사람도 있습니다. 양방향 TLS 인증(mTLS). 이것들은 모두 의미가 있지만 분명히 포괄적이지는 않습니다.

여기서 저자는 머신러닝에 대한 농담을 빌리고 싶습니다: "머신러닝은 통계를 미화합니다." 마찬가지로 제로 트러스트도 최소 권한을 미화합니다. 기계 학습과 제로 트러스트 모두 통계 및 최소 권한보다 특정 문제와 애플리케이션 시나리오에 더 중점을 두기 때문에 이는 분명히 부정확합니다. 머신러닝과 제로 트러스트는 단일 분야나 이론이 아니라, 실질적인 문제를 해결하기 위해 개발된 여러 분야(예: 수학, 컴퓨터 아키텍처, 분산 시스템, 스토리지, 네트워크 등)의 혁신적인 관행입니다.

제로 트러스트의 경우 정의와 이론이 너무 엄격할 필요는 없지만 이를 실천과 결합하여 해결해야 할 구체적인 문제와 적용 시나리오부터 시작해야 한다는 것을 알 수 있습니다. 따라서 우리는 이 문서의 문제와 적용 시나리오를 일시적으로 결합하여 제로 트러스트를 보호할 데이터 및 권한에서 시작하여 보호되는 데이터 및 권한과 관련하여 프로덕션의 신뢰를 포괄적으로 감소 및 재구성하는 것으로 정의합니다.

제로 트러스트를 정의하는 것보다 더 중요한 질문은 '왜 제로 트러스트를 하려는가?'입니다.

제로 트러스트가 필요한 이유는 무엇입니까?

제로 트러스트가 필요한 이유는 무엇입니까? 가장 근본적인 이유는 보호해야 할 중요한 데이터나 권한이 일부 존재하는데, 기존 보안 시스템으로는 더 이상 클라우드 네이티브 시대에 충분한 보호를 제공할 수 없기 때문입니다. 사용자의 개인정보 데이터, 직원 급여 데이터, 비밀번호 변경 권한, 주요 시스템 종료 권한 등은 모두 보호 대상입니다. 이러한 데이터 및 권한은 회사 인트라넷, VPN 등 경계 보안 기반의 네트워크 접근 제어를 통해 초기에 보호되며, 장치가 회사 인트라넷에 연결되면 이러한 데이터 및 권한을 얻을 수 있는 기능을 상속받습니다. 나중에 사람들은 IP 기반 또는 사용자 이름 및 비밀번호 기반 액세스 제어뿐만 아니라 ID 및 역할(Identity and Role)을 기반으로 보다 세분화된 액세스 제어를 도입하기 시작했습니다. 그러나 이는 클라우드 기반 환경, 특히 Google과 같은 복잡한 엔터프라이즈 IT 시스템의 데이터 및 권한 보호 요구 사항을 더 이상 충족할 수 없습니다.

클라우드 네이티브는 다음과 같은 과제를 안겨줍니다. 첫째, 기업 IT 시스템은 단일 전산실 모델에서 클라우드 간 하이브리드(멀티 및 하이브리드 클라우드) 모델로 진화하여 경계가 모호해지고 경계에 따른 보안의 비효율성이 발생했습니다. 둘째, 컨테이너(Containers) 기반 컴퓨팅은 호스트 불확실성을 초래합니다.동일한 서비스는 오프라인 상태 없이 언제든지 하나의 물리적 호스트에서 다른 물리적 호스트로 마이그레이션될 수 있습니다.이로 인해 호스트 기반 보안 보호는 더 이상 불가능합니다. 서비스 로직 기반 심층 보호, 셋째, 마이크로서비스(Microservices)와 세분화된 API로 공격 표면 증가 신원과 역할은 더 이상 최종 사용자의 신원과 역할이 아니라 마이크로서비스 간 상호 작용의 더 중요한 측면 . 세분화된 ID 및 액세스 제어.

2015년 당시 구글의 상황을 시작으로 우리는 내부적으로 키와 신원인증을 기반으로 비교적 성숙한 권한관리 시스템을 구현해 왔지만 두 가지 보안 위협이 우리의 주목을 끌었습니다. 첫째, 포스트 스노든(post Snowden) 기계 간 통신 시대. 데이터 센터, 상호 신뢰를 구축하는 방법과 손상된 호스트 또는 손상된 서비스가 프로덕션 환경의 다른 부분에 영향을 미치지 않도록 보장하는 방법은 무엇입니까? 두 번째는 일회성 데이터 및 권한 액세스에 대한 권한 부여 및 감사 시스템이 잘 되어 있을 때 배치(Batch) 데이터 및 머신러닝과 같은 권한 액세스로 인한 대규모 데이터 유출을 어떻게 처리할 것인가?숨겨진 위험은 무엇일까? 제로 트러스트에 기반한 내부자 리스크 관리 및 통제 시스템 구축이 시급하다.

물론 이 모든 것은 네트워크 및 호스트 보호 시스템, 신뢰할 수 있는 부팅, 키 관리 시스템, 신원 인증 및 관리 시스템 등 견고한 기존 보안 기본 사항을 기반으로 합니다. 제로 트러스트(Zero Trust)는 이러한 보안 기반을 바탕으로 구축된 상부 구조입니다.

제로 트러스트의 세 가지 요소: 신뢰 체인, ID 2.0 및 지속적인 액세스 제어

신뢰 체인, ID 2.0 및 지속적인 액세스 제어는 제로 트러스트의 세 가지 주요 요소입니다.

신뢰의 사슬

제로 트러스트란 전혀 신뢰가 없다는 뜻이 아니라, 몇 가지 기본적인 최소한의 신뢰 루트(Root of Trust)에서 시작하여 신뢰 체인(Chain of Trust)을 재구성하는 명확한 프로세스입니다. 몇 가지 일반적인 예는 다음과 같습니다: MFA(Multi-Factor Authentication)는 개인 ID에 대한 신뢰 루트이고, TPM(신뢰할 수 있는 플랫폼 모듈) 및 신뢰할 수 있는 부팅(Trusted Boot)은 시스템 ID입니다. 신뢰 루트, 소스 코드 및 신뢰할 수 있는 빌드( Trusted Build)는 소프트웨어에 대한 신뢰의 루트입니다. 거대한 IT 시스템에 대한 신뢰는 이러한 가장 기본적인 신뢰의 뿌리에서 시작하여 일련의 표준화된 프로세스를 통해 완전한 신뢰 체인을 구축합니다(일부에서는 이를 신뢰의 나무 또는 신뢰의 웹이라고도 함).

아이덴티티 2.0

Identity 2.0은 신뢰 구축 과정에서 수집된 정보를 보안 접근 정책에 활용할 수 있도록 위의 신뢰 체인을 표준화한 것입니다. Identity 2.0에서는 모든 엔터티에 ID가 있고, 사용자에는 사용자 ID가 있고, 직원에는 직원 ID가 있고, 기계에는 기계 ID가 있고, 소프트웨어에도 소프트웨어 ID가 있습니다. 예를 들어 Identity 2.0에서는 모든 액세스에 여러 ID(액세스 컨텍스트라고도 함)가 있습니다. , 데이터베이스의 데이터 행에 대한 액세스는 "사용자의 기술 문제 해결을 돕기 위해 직원 A가 사용자 B의 승인을 받아 소프트웨어 C를 통해 시스템 D에 대한 액세스를 요청했습니다."와 같은 내용을 갖습니다.

지속적인 접근 제어

Identity 2.0이 제공하는 풍부한 ID와 접속 배경 정보를 바탕으로 지속적인 접속 제어 시스템(Continous Access Control)을 구축할 수 있습니다. 지속적인 액세스 제어는 소프트웨어 개발 및 운영의 모든 측면에서 액세스를 지속적으로 제어합니다. 몇 가지 일반적인 예는 다음과 같습니다: 직원이 로그인할 때 다단계 인증 요구, 안전한 환경에서 신뢰할 수 있는 소스 코드 라이브러리에서 소프트웨어를 구축하고 소프트웨어 배포 시 코드 검토(코드 검토)를 받도록 요구, 마이크로서비스 간 연결을 설정할 때 두 가지 모두 당사자는 호스트 무결성 인증서를 제공해야 하며, 마이크로서비스가 특정 사용자 데이터를 얻을 때 사용자의 인증 토큰(Authorization Token)이 필요합니다.

제로 트러스트 배포 예시

이 섹션에서는 두 가지 구체적인 제로 트러스트 배포 예를 제공합니다. 첫 번째는 사용자가 자신의 데이터를 얻는 방법이고, 두 번째는 개발자가 소스 코드를 수정하여 프로덕션 환경에서 데이터 액세스 동작을 변경하는 방법입니다. 두 경우 모두 Google의 데이터 액세스 제어는 제로 트러스트 원칙을 따릅니다.

사용자는 자신의 데이터에 액세스합니다.

사용자가 Google 서비스를 통해 자신의 데이터에 액세스하면 요청은 먼저 사용자와 Google 프런트엔드(GFE) 간의 암호화된 연결(TLS)을 통해 GFE에 도달합니다. GFE는 보다 효율적이고 안전한 프로토콜과 데이터 구조로 전환하여 사용자 요청을 다양한 백엔드 서비스에 분산하여 사용자 요청을 공동으로 완료합니다. 예를 들어 TLS는 다음으로 대체됩니다.애플리케이션 계층 TLS(ATLS). 사용자에게 표시되는 비밀번호는 더욱 안전한 EUC(최종 사용자 컨텍스트 티켓)로 변환됩니다. 이러한 순열은 실제 요청을 기반으로 내부 연결 및 토큰의 권한을 줄여 특정 ATLS 및 EUC가 이 요청으로 제한된 데이터 및 권한에만 액세스할 수 있도록 설계되었습니다.

다음은비욘드프로드원본 사진, 사진의 개발자는 실제로 사용자여야 합니다.

 

 

개발자는 소프트웨어 데이터 액세스 동작을 변경합니다.

개발자가 서비스 코드를 변경하여 서비스의 데이터 및 권한 액세스 동작을 변경하려는 경우(개발자는 SSH와 같은 프로덕션 호스트에서 명령 실행 권한을 얻을 수 없음) 일련의 프로세스를 거쳐 코드 수정을 수행합니다. 작성자와 팀의 신뢰는 새로운 서비스에 대한 신뢰로 전환됩니다. 프로세스에 참여하는 모든 인원은 다중 인증을 통해 신원을 확인하고 코드 수정은 승인을 받은 한 명 이상의 사람에 의해 평가됩니다. 충분한 권한이 있어야만 코드가 중앙 코드 베이스로 병합됩니다. 중앙 코드 베이스의 코드는 BAB에 의해 보호되는 신뢰할 수 있는 빌드 서비스에 의해 중앙에서 구축, 테스트 및 서명됩니다. 소프트웨어는 배포 과정에서 대상 서비스의 BAB 정책 인증을 통과합니다.(예를 들어 GMail의 서비스는 코드 베이스의 특정 위치에서 완전히 평가되고 테스트된 코드만 실행할 수 있습니다.) 소프트웨어가 실행 중일 때 또한 해당 BAB 보안 정책에 따라 격리됩니다. 다양한 BAB 서비스 정책에 따라 관리되는 서비스는 다양한 격리 영역에서 실행됩니다.

다음은비욘드프로드원본 사진, 자세한 내용은 원본 텍스트를 참조하세요.

 

실무 경험과 교훈

사람을 최우선으로 생각하고 그 과정에서 신뢰를 쌓아보세요

BeyondCorp를 사용하여 개발 환경(Corp 환경)에서 제로 트러스트를 구현할 때 사람을 최우선으로 생각하고 직원에 대한 ID 관리 및 다단계 인증을 수행합니다. 동시에 회사 장치를 관리하는 프로세스를 구축했으며, 각 회사 장치에는 TPM 모듈과 운영 체제 무결성 검증이 탑재되어 있습니다. 이러한 두 가지 노력을 통해 올바른 사람이 올바른 장치를 사용하여 신뢰할 수 있는 인증 정보를 제공할 수 있습니다. 마지막으로, 우리는 이 인증 정보를 사용하여 개발 환경에 대한 직원의 접근을 지속적으로 제어합니다.

BeyondProd를 사용하여 프로덕션 환경(Prod 환경)에서 제로 트러스트를 구현하는 경우에도 사람과 프로세스를 신뢰의 기반으로 활용하려고 노력합니다. BeyondProd가 직면한 문제는 생산 환경이 사람들과 직접적인 상호 작용을 하지 않는다는 것입니다. 그래서 우리는 이러한 소프트웨어의 개발자에게 생산 환경에서 추적 가능한 소프트웨어 세트(Software Provenance)를 구축하고 개발자의 인증 및 개발부터 프로세스는 한 사람이 프로덕션 환경에서 소프트웨어의 동작을 변경할 수 없도록 보장하기 시작합니다(일방적인 변경 없음).

보안 규칙 수준

로마는 하루아침에 이루어지지 않았으며, 제로 트러스트를 촉진하는 것 역시 점진적인 과정입니다. 안전 개선을 정량화하고 인센티브를 제공하기 위해 우리는 안전 규칙 등급을 사용하여 한 안전 규칙이 다른 안전 규칙보다 "더 안전한"지 여부를 측정합니다. 예를 들어 Borg 시스템용 Binary Authorization에는 다음과 같은 보안 수준이 도입되었습니다.

보안 수준 0: 보호되지 않습니다. 이는 가장 낮은 보안 수준으로, 서비스가 BAB에 의해 전혀 보호되지 않음을 의미합니다. 이는 시스템에 중요한 권한이 없거나 시스템이 BAB와 동등한 다른 보호 기능을 사용하기 때문일 수 있습니다.

보안 수준 1: 감사 가능한 코드. 이 수준의 보안 규칙은 해당 서비스에서 사용하는 소프트웨어가 안전하고 검증 가능한 환경에서 알려진 소스 코드로 구축되도록 보장합니다.

보안 수준 2: 신뢰할 수 있는 코드. 이 보안 규칙은 보안 레벨 1을 보장하는 것 외에도 해당 서비스에서 사용하는 소프트웨어가 특정 코드 베이스(예: Gmail 자체 코드 베이스)에서 코드 검토 및 테스트를 거친 코드로 구축되도록 보장합니다. 2020년 2월 현재 이 수준은 모든 Google 서비스의 기본 보호 수준입니다.

보안 수준 3: 신뢰할 수 있는 코드 및 구성. 이 보안 규칙은 보안 수준 2를 보장하는 것 외에도 해당 서비스에서 사용하는 구성 파일이 코드와 동일한 보안 프로세스(코드로 구성)를 거쳤음을 보장합니다. 2020년 2월 현재 이 수준은 모든 Google 키 보호 서비스의 기본 수준입니다.

경보 시스템 및 인증 시스템

제로 트러스트를 촉진하는 과정에서 모든 당사자에게 원활한 마이그레이션 경험을 제공하기 위해 보안 규칙을 준수하지 않는 모든 액세스를 직접 금지하지는 않지만 보안 규칙 자체에 경보 시스템과 인증 시스템이라는 두 가지 모드를 제공합니다. . 경보시스템에서는 보안수칙을 위반한 출입을 차단하지 않고 기록하여 담당자에게 통보하며, 승인시스템에서는 보안수칙을 위반한 출입을 즉시 차단합니다. 이 이중 시스템의 존재는 사람들에게 경보를 기반으로 비준수 행동을 지속적으로 반복하고 개선할 수 있는 기회를 제공할 뿐만 아니라 보안 규칙을 강화하고 비준수 행동이 제거된 후 회귀를 방지하는 효과적인 메커니즘도 제공합니다.

안전하고 안정적이세요

제로 트러스트의 복잡성으로 인해 시스템 안정성(신뢰성)을 유지하는 데 있어서도 새로운 과제에 직면하게 됩니다. 제로 트러스트를 실천하는 과정에서 대부분의 시나리오에 비상 브레이크 글래스 메커니즘(Break-glass Mechanism)을 제공합니다. 이를 통해 긴급 상황 발생 시 운영자는 제로 트러스트 시스템의 한계를 깨고 복잡한 긴급 작업을 수행할 수 있습니다. 지속적으로 보안을 보장하기 위해 긴급 위반 메커니즘이 호출되면 보안 팀은 즉시 경보를 받게 되며 위반 메커니즘에 따른 모든 작업도 보안 로그에 자세히 기록됩니다. 이러한 보안 로그는 위반의 필요성을 확인하기 위해 면밀히 조사됩니다. 이러한 보안 로그는 유사한 상황에서 긴급 위반 메커니즘이 다시 호출되는 것을 방지하기 위한 새로운 제로 트러스트 기능을 설계하는 데도 도움이 됩니다.

내생적 위험에 주의하라

방어 관점에서 내생적 위험은 외생적 위험의 상위 집합입니다. 공격자가 내부자(합법적인 사용자 또는 직원)의 장치를 손상시키면 공격자는 내부자가 되므로 외부 공격자인지 내부 위반자인지 내부인지 여부 위반자는 결국 내생적 위험이 될 것입니다. 이러한 관점에서 제로 트러스트에서는 모든 호스트가 손상될 수 있다고 가정합니다.

보안 인프라

제로 트러스트 구현은 견고한 기본 보안 아키텍처를 기반으로 하며, 기반이 없으면 상부 구조도 없습니다. Google Zero Trust는 다음 인프라를 사용하여 기본적인 보안을 제공합니다.

1. 데이터 암호화 및 키 관리(암호화 및 키 관리)
2. ID 및 액세스 관리
3. 디지털 인적 자원
4. 디지털 장치 관리
5. 데이터 센터 보안
6. 사이버 보안(네트워크 보안)
7. 호스트 보안
8. 컨테이너 격리(gVisor)
9. 신뢰할 수 있는 부팅
10. 검증 가능한 빌드
11. 소프트웨어 무결성 검증
12. 상호 TLS(mTLS)
13. 서비스 접근 정책
14. 최종 사용자 컨텍스트 토큰
15. 코드로 구성
16. 표준 개발 및 배포

다른

위에서 배운 교훈 외에도 작게 시작한 다음 반복하고 심층적으로 방어하고, 보안 투자 수익을 정량화하고(Quantify return over Investment), 표준화를 통해 비용을 절감하고(Lowering Cost through Homogeneity), 보안 Shift Left도 원칙입니다. 우리는 실제로 축적해왔기 때문에 여기서는 자세히 다루지 않겠습니다.

결론적으로

제로 트러스트를 잘 달성하기 위해 20%는 이론에 의존하고 80%는 실습에 의존합니다. 제로 트러스트를 위한 실질적인 솔루션은 독특한 것이 아니며, 저자는 위의 제로 트러스트 실천 사례를 공유함으로써 출발점이 될 수 있기를 바랍니다. 여러분의 비판과 수정을 환영합니다!