한빛출판네트워크

"기술 업계에서 일하기 시작한 후로 여러 규모의 조직에서 어떻게 보안을 적용해야 하는가에 대한 문제를 고민하는 수많은 사람을 목격했다. 보안을 중앙에서 관리해야 할지 연동해서 관리해야 할지, 독립적이어야 할지 내장해야 할지, 직접 운영해야 할지 외부에 맡겨야 할지, 기술적으로 해결해야 할지 관리적으로 해결해야 할지, 고민은 끝이 없었다."

[로열 핸슨 Royal Hansen, 구글 보안 엔지니어링 부사장(https://mobile.twitter.com/royalhansen)]

SRE(Site Reliability Engineering)* 모델과 SRE와 유사한 버전의 데브옵스(DevOps)*가 유행하면서 SRE가 다루는 문제가 보안 영역의 문제와 유사하다는 점을 깨달았다. 어떤 조직은 이 두 부문을 하나로 합쳐 ‘데브섹옵스(DevSecOps)’라고 부르기도 한다.

 

* 데브옵스(DevOps)

: 데브옵스를 두고 종종 논쟁이 일어나곤 한다. 데브옵스는 기존 소프트웨어 개발에 존재하던 모범 사례의 현대적인 이름일 뿐이라고 주장하는 사람이 있는가 하면, 개발과 운영 사이에서 더 큰 협업의 필요성을 거부하는 사람은 데브옵스 자체를 거부하기도 한다. 

 

또한 데브옵스가 실제로 무엇인지와 관련하여 '데브옵스란 직무인가? 팀인가? 방법론인가? 기술 집합인가?'와 같은 광범위한 오해가 있다. 

 

데브옵스를 주제로 영향력 있는 글을 쓰는 존 윌리스는 데브옵스의 네 가지 핵심을 문화, 자동화, 측정, 공유로 정의했다. 브라이언 도슨은 데브옵스 삼위일체를 사람과 문화, 과정과 실천, 도구와 기술로 정의했다. 

 

어떤 사람들은 클라우드와 컨테니어에 더는 데브옵스가 필요하지 않다고 주장한다. 이를 노옵스(NoOPS)라고 부른다. 이러한 관점을 가진 사람들은 모든 IT 운영이 클라우드 서비스 업체나 다른 서드 파티 서비스로 아웃소싱되므로 사업체 내에 정규 운영 직원이 필요하지 않다고 주장한다. 

 

하지만 노옵스 오류는 실제 데브옵스 업무가 무엇을 포함하는지에 대한 잘못된 이해를 기반으로 한다. 데브옵스 엔지니어이자 풀스택 소프트웨어 개발자 조던 바흐는 데브옵스를 이렇게 설명했다. 

 

데브옵스를 하면 코드가 상용 환경에 도달하기 전에 전통적인 IT 운영 작업의 상당수가 수행된다. 모든 릴리스는 모니터링, 로깅, A/B 테스트를 포함한다. CI/CD 파이프라인은 모든 커밋에 대해 유닛 테스트, 보안 스캐너, 정책 검사를 자동으로 수행한다. 배포는 자동으로 수행된다. 제어, 작업, 비기능적 요구 사항은 이제 릴리스 전에 구현되어 심각한 운영 중단의 여파를 대신한다. 

 

데브옵스를 이해하는 데 가장 중요한 점은 데브옵스가 기술적인 문제가 아니라 주로 조직적이고 인간적인 문제와 관련이 있다는 것이다. 이는 제럴드 와인버그가 말하는 컨설팅의 두 번째 법칙과 일치한다. "처음에 어떻게 보이든 문제는 항상 사람이다." (제럴드 와인버그, <컨설팅의 비밀>)

- 한빛미디어, 2021, <쿠버네티스를 활용한 클라우드 네이티브 데브옵스> 중에서 -

 

* SRE(Site Reliability Engineering, Site Reliability Engineer)

: 사이트 신뢰성 엔지니어링 또는 사이트 신뢰성 엔지니어. 사이트 신뢰성 엔지니어링은 기존의 데브옵스로부터 한 단계 더 발전한 모델이다. 

 

기존의 데브옵스는 애플리케이션을 위한 네트워크나 저장소 같은 인프라스트럭처의 구성, 모니터링, 및 알림 시스템의 구축, 빌드 및 배포 자동화 등 소프트웨어 개발 주기와 관련된 여러 작업들의 수행 및 자동화 스크립트 개발에 집중한다. 

 

반면, 사이트 신뢰성 엔지니어는 여기에서 한 걸음 더 나아가 애플리케이션이 이러한 인프라 스트럭처들을 활용할 수 있는 라이브러리나 프레임워크까지 직접 개발하기도 하고, 제품이나 서비스에 문제가 발생하면 이를 함께 해결하기도 한다. 

- 제이펍, 2018, <사이트 신뢰성 엔지니어링>, 옮긴이의 말 중에서 -

 

SRE와 보안은 모두 전통적인 소프트웨어 엔지니어링 팀에 강하게 의존하지만, 본질적으로는 전통적인 소프트웨어 엔지니어링 팀과는 다르다.

● 사이트 신뢰성 엔지니어(Site Reliability Engineers, SRE)와 보안 엔지니어는 빌드는 물론 제품에 의도적으로 문제를 일으키고 이를 수정하기도 한다.

● 담당 직무는 개발뿐 아니라 운영도 포함한다.

● SRE와 보안 엔지니어는 전통적인 소프트웨어 엔지니어보다는 전문가에 가깝다.

● 팀에 공헌하는 사람이기보다는 방해꾼처럼 보이는 경우가 종종 있다.

● 제품 팀에 소속되지 않는 경우가 많다.

SRE는 기존의 보안 엔지니어와 유사한 역할과 책임을 만들어왔다. 또한 SRE는 보안 두 팀을 연결하는 모델을 구현해왔고, 이는 보안 팀이 나아가야 할 다음 단계를 제시했다. 지난 수년간 나와 동료들은 보안을 최우선으로 고려하며 소프트웨어 품질로 다뤄야 한다고 논쟁해왔다. 

그러기 위해선 SRE의 접근법을 도입하는 것이 논리적으로 올바르다고 믿는다.

구글에 합류한 후로 구글이 SRE 모델을 어떻게 정립해왔는지, SRE가 데브옵스 철학을 어떻게 구현하고 SRE와 데브옵스가 어떻게 발전해 왔는지에 대해 많은 내용을 배울 수 있었다. 그러면서 한편으로는 그동안 재무 분야에서 쌓아온 IT 보안 경험을 바탕으로 구글의 기술적, 프로그래밍적 보안 능력을 구축해나갔다. 

이 두 분야는 서로 무관하지 않지만 배워둘 만한 나름의 역사와 전통을 가지고 있다. 그와 동시에 기업은 클라우드 컴퓨팅, 다양한 형태의 머신러닝, 복잡한 사이버 보안 환경과 함께 디지털 세계가 어느 방향으로 가고 있는지, 얼마나 빨리 도달할지, 어떤 위험이 수반되는지를 결정하는 중요한 시점에 있다.

보안과 SRE의 교집합이 점점 넓어지며 보안 원리를 소프트웨어와 데이터 서비스의 전체 수명 주기(lifecycle)에 철저히 반영하는 것이 더 중요해졌다. 

현대(대부분 상호 연결된 데이터와 마이크로서비스를 제공하는 오픈 소스 소프트웨어 프레임워크를 기반으로 하는) 하이브리드 클라우드의 본질을 고려하면, 보안과 회복성(resilience)을 강력하게 통합하는 것은 더욱 중요하다.

지난 20년 동안 대기업 운영과 조직 관점에서 보안에 접근하는 방법은 매우 다양하게 변했다. 가장 대표적인 예시는 완전한 중앙식 관리를 의미하는 최고 정보 보안 책임자(CISO, chief information securityofficer)와 방화벽, 디렉터리 서비스, 프록시 등으로 핵심 인프라스트럭처를 운영하는 방식이다. 그러면서 팀은 수백 또는 수천 명 규모로 성장했다. 

그와 반대되는 방식으로는 몇 가지 잘 알려진 기능이나 비즈니스의 운영을 지원하거나 관리하는 데 필요한 영업 부문이나 기술 전문성을 가진 연합 정보 보안 팀을 확보하는 방식도 있다. 중간적인 방식으로는 위원회와 메트릭 그리고 규제를 통해 보안 정책을 관리하고 내부의 보안 전문가가 관계를 관리하는 역할을 수행하거나 조직 단위의 이슈를 추적하는 역할을 담당하는 방식이다. 

그동안 기존의 직무를 사이트 보안 엔지니어와 유사한 직무로 발전시키거나 또는 전문 보안 팀을 위해 특정 애자일 스크럼 역할로 개선하며 SRE 모델을 도입하는 팀도 있었다.

기업 보안 팀이 기밀성(confidentiality)에 특히 집중하는 것은 당연하다. 하지만 대부분의 조직은 데이터 무결성(integrity)과 가용성(availability)의 중요도를 동일한 것으로 생각하고 서로 다른 팀과 정책으로 이 두 영역을 다루곤 한다. 

여기서 SRE는 신뢰성(reliability)에 우선적으로 집중하고 권한이 필요한 접근이나 민감한 데이터를 향한 보안 관련 공격을 포함한 기술적인 이슈를 실시간으로 탐지하고 대응하는 역할도 수행한다. 결국, 조직적으로 볼 때 엔지니어링 팀은 전문적으로 다루는 기술에 따라 구별되지만 시스템이나 애플리케이션의 품질과 안전성을 확보한다는 공통의 목표를 가지고 있다.

전 세계적으로 기술 의존도가 매년 증가하는 요즘, 구글 및 동종 업계의 경험에서 얻은 보안과 신뢰성에 대한 접근법은 소프트웨어 개발과 시스템 관리 그리고 데이터 보호에 중요한 기반이 될 수 있다. 

위협과 공격의 방법이 더욱 발전하면서 이를 방어하기 위한 동적이고 통합적인 접근법은 필수가 되었다. 이전에는 조금 더 형식적인 답만 구하고 있었을 뿐이었다. 보안 관련 업무를 하는 팀이라면 <SRE를 위한 시스템 설계와 구축>이라는 도서의 내용을 유용한 접근법이자 개선을 위한 도구로 사용했으면 한다. 

특히 현재의 운영 모델에 데브옵스, 데브섹옵스, SRE, 하이브리드 클라우드 아키텍처 등을 접목하는 기업에서라면 더 그렇다. 점차 디지털화되는 세상에서 시스템과 데이터 보안에 대한 발전과 개선을 향한 또다른 한 걸음이다.

이 글은 <SRE를 위한 시스템 설계와 구축> 도서 내용 일부를 발췌하여 작성되었습니다. 이와 관련하여 보다 자세한 정보는 하기 책에서 만나볼 수 있습니다. 

『SRE를 위한 시스템 설계와 구축』