[데이터넷] 2010년 포레스터 리서치가 제로 트러스트를 처음 이야기 했을 때는 엔터프라이즈 보안 전문가들이 보안 위반이나 공격으로부터 비즈니스를 보호하기 위해 네트워크 경계만 지키는 것의 한계를 지적했다. 그런데 제로 트러스트 프레임워크가 발전하면서 이 원칙은 데브옵스(DevOps)까지 확장되고 있다.

제로 트러스트는 인간과 머신, 내부 또는 외부의 모든 사용자들이 리소스에 처음 액세스 할 때는 물론이고, 이후 지속적으로 인증과 승인, 검증을 요구한다. 이는 소프트웨어 개발 라이프사이클에서 시프트 레프트(Shift Left) 보안을 유지하는 데브섹옵스(DevSecOps)에서 추구하는 것과 완벽하게 일치한다.

깃랩의 보안 엔지니어인 마크 러브레스(Mark Loveless)가 2019년 데브옵스와 제로 트러스트의 결합 가능성을 모색하기 시작했는데, 이러한 시도가 실제로 소프트웨어 개발 프레임워크 전반으로 확산되고 있다. 미국 바이든 행정부가 사이버 보안에 대한 행정 명령에서 제로 트러스트 원칙의 소프트웨어 개발을 언급했으며, 미국 국립표준기술연구소(NIST)는 안전한 소프트웨어 개발 프레임워크 표준에 대한 접근방식으로 제로 트러스트 아키텍처를 도입했다.

애플리케이션 개발에 제로 트러스트 매핑하기

데브옵스와 제로 트러스트를 결합하기 위해서는 소프트웨어 개발 프로세스에서 다음의 3가지 핵심 구성 요소가 완벽하게 적용돼야 한다.

1. 데이터 보호: 데이터에 액세스하기 전에 데이터에 액세스하는 사람이나 대상(자동화의 경우)의 아이덴티티를 확인하고, 해당 액세스 권한을 부여할지 여부를 결정해야 한다.
2. 아이덴티티를 명확히: 요청자는 가급적 암호화된 방법을 통해 자신이 누구인지 또는 무엇인지를 증명해야 한다.
3. 데이터 액세스 위한 보안 채널 설정: 인증이 이뤄지면, 전송되는 데이터는 보안 채널로 보호돼야 하며, 해당 데이터는 요청자에게만 공개돼야 한다.

제로 트러스트 전략을 수립할 때 ‘요청자’를 사람으로만 한정해서는 안된다. 데브옵스가 보편적으로 사용되면서 자동화된 프로세스가 요청자가 될수 있다. 이러한 경우를 가정하고 다음의 질문에 정확하게 답 할 수 있어야 한다.

• 자동화된 요청이 신뢰할 수 있는 장치에서 발생했는가?
• 자동화된 데이터 요청 프로세스 작업을 개시한 사람은 누구인가?
• 해당 자동화 프로세스가 현재 데이터 요청에 대한 2차 자동화 프로세스를 개시했는가?
• 이러한 프로세스의 자격증명에 액세스할 수 있는 사람이 자동화 프로세스를 설정했는가?

마크 러브레스는 데브옵스 자동화는 매우 높은 수준의 정교함을 요구하기 때문에 제로 트러스트를 적용하기 위해서는 인증과 승인 방식을 재고해야 할 수 있다고 설명한다. 자체적으로 인증기관을 관리하거나 상호 TLS 설정과 같은 상호 인증은 어려운 과제가 될 수 있으므로 오픈ID 커넥트(OpenID Connect)와 같은 자동화된 다중요소 인증 툴을 구현하는 것을 고려할 수 있다.

깃랩은제로 트러스트 프레임워크 지원을 위해 다음의 기능을 제공한다.

• 모든 사용자와 머신에 대한 역할 기반 액세스를 설정하고 시행한다.
• 액세스를 허용하기 전에 사용자와 머신을 인증한다.
• 지속적인 인증 및 승인을 지원한다.
• 사용자와 머신의 보안 상태를 모니터링하고, 문제에 신속하게 대응한다.
• 데이터를 분류하고 그에 따라 액세스 레벨을 설정 및 시행한다.
• 실시간으로 데이터 액세스를 감사하고, 컴플라이언스 보고서를 생성한다.

개발자 1/3 “보안에 책임 느껴”

제로 트러스트를 데브옵스에 접목할 때 간과해서는 안되는 것이 개발자이다. 데브옵스의 중요한 축인 개발자들이 개발 단계에서 제로 트러스트 원칙의 보안을 적용해야 한다는 사실을 이해하지 못한다면, 시작도 할 수 없기 때문이다. 이는 보안팀이 전적으로 맡을 수도 없는 것이, 과도한 업무를 수행해야 하는 보안팀에게 개발 단계 애플리케이션을 스캐닝하고 취약점을 찾아 조치하라고 할 수는 없다.

개발팀은 시프트 레프트 보안을 받아들여야 한다. 개발 프로세스 초기에 애플리케이션의 약점을 스캐닝하고 제거해 운영환경에 도달할 때 안전한 소프트웨어를 완성하도록 하는 것이다. 이상적으로는 릴리스 직전과 직후에도 취약점을 스캐닝하고 수정하는 작업이 필요하다.

깃랩의 2021년 데브섹옵 조사에 따르면, 조사 대상 개발자 중 3분의 1 이상이 ‘조직의 보안에 대해 전적인 책임을 느끼고 있다(전년도의 28%에서 증가)’고 답했으며, 32%는 ‘다른 팀과 부담을 공유하고 있다’고 응답했다.

보안 측면에서 개발 팀에 대한 기대치는 점점 높아지고 있다. 그러나 식별된 문제를 해결할 수 있는 어떠한 지침이나 잠재적 영향을 설명하지 않고 보안 스캔 결과만 제시하는 것은 개발자들에게 좌절감만 안겨줄 수 있으며, 개발자는 보다 신속하게 코드를 제공하기 위해 결과를 무시하고, 앱 보안 팀에게 다시 부담을 전가할 수도 있을 것이다. 이로 인해 팀 내부의 마찰이 증가하고, 릴리스 주기가 늘어날 수 있다.

개발자는 보안 전문가 아니다

개발자들이 시프트 레프트를 이행하도록 하기 위해서는 보안 취약점이 발생할 때 이를 식별 및 해결하고, 보안 문제가 발생하지 않도록 사전에 차단하는 것은 물론, 팀 내의 의사소통 및 보안 책임소재를 분명히 할 수 있도록 실시간 보안 교육이 이뤄져야 한다. 기업들이 엔터프라이즈 개발자들에게 추가적인 보안 책임을 부여하기 위해서는 어떻게 보안 경고에 대응할 것인지에 대한 교육이나 지원을 제공해야 한다.

대부분의 개발자들은 보안 전문가가 아니다. 경험이 풍부한 소프트웨어 엔지니어라도, 방대한 보안 분야의 모든 것을 배울 시간은 없다. 개발자들에게 필요한 것은 특정 보안 문제를 이해해야 하는 지점과 시기에 적절한 관련 정보를 제공해야 한다. 따라서 엔지니어들이 작업을 수행하고 있는 소프트웨어 개발 플랫폼에서 지속적으로 업데이트되는 실시간 상황 별 보안 교육 옵션을 제공해야 한다. 통합 보안 교육은 이미 과부하가 걸린 보안 팀으로 보안 작업을 전가하지 않고, 개발자에게 실시간으로 정보를 제공할 수 있는 가장 좋은 방법이다.

이러한 기술은 교과 과정이나 코딩 부트캠프에서는 거의 다루고 있지 않다. 대부분의 기업들은 소프트웨어 개발자들이 매년 보안 교육을 받도록 요구하고 있지만, 이러한 워크숍은 대체로 소프트웨어 취약성 및 문제에 대한 슬라이드 발표나 일반적인 비디오를 보여주는 것이 대부분이다. 이러한 교육 방식이 내용에 대한 유의미한 이해로 이어지는 경우는 거의 없다. 또한 학습과 지식이 적용되는 시기 간의 차이로 인해 지속적인 참여 및 유지 가능성을 감소시킨다.

개발자들이 보안을 주도할 수 있도록 지원

주로 책이나 교과과정을 통해 배운 이전 세대의 소프트웨어 개발자와 달리 젊은 세대의 개발자들은 블로그와 비디오 및 부트캠프와 같은 온라인 리소스를 통해 배우고 있다. 실제 스택 오버플로(Stack Overflow)의 연구에 따르면, 조사 대상 개발자 중 거의 60%가 온라인 리소스를 통해 코딩 방법을 학습하는 것으로 나타났다. 따라서 현재 소프트웨어를 개발하는데 사용되는 플랫폼 또한 이러한 새로운 학습 스타일에 맞게 진화해야 한다.

개발자들은 이미 효율적으로 코드를 제공해야 한다는 충분한 압박을 받고 있다. 따라서 개발자들을 더욱 난관에 빠트리는 길고도 험난한 교육 과정 대신, 실전 기술을 습득할 수 있도록 상황에 적합한 표적 레슨으로 작은 규모의 코딩 과제들을 해결할 수 있도록 해야 한다. 이를 통해 새로운 기술을 배우고, 이를 실행하기까지 걸리는 시간 간격을 줄일 수 있으며, 개발자들이 체감적으로 이를 습득할 때까지 확장함으로써 코딩할 때 보안 문제를 식별하고, 소프트웨어 생성 초기에 발생하는 일반적인 취약점의 수를 더욱 줄일 수 있다.

점차 더 많은 기업들이 개발자가 프로세스 초기에 보다 신속하게 취약성을 해결할 수 있는 워크플로우 경로를 채택함에 따라, 앞으로는 릴리스 품질을 향상시키면서도 보안 코드를 신속하게 제공할 수 있게 될 것이다.

데브옵스 워크플로우 내의 보안 코딩 교육을 통해 개발자를 위한 보안조치 지원을 자동화하고, 확장함으로써 애플리케이션 보안 팀은 모든 보안 위험을 사전에 완화하고, 조직의 보안 태세를 강화하는데 집중할 수 있게 될 것이다. 이것이 바로 시프트 레프트 보안의 진정한 잠재력이다.