분열을 메우다: 유연성과 보안

두 가지가 필요한데, '모두가' 그 둘이 상호 배타적이라는 걸 알고 있을 때 어떻게 하시나요?

네트워킹 및 보안 커뮤니티에는 오랫동안 보안 소프트웨어 아키텍처는 융통성이 없고, 애자일 방식으로 제공되는 소프트웨어는 보안성이 낮다는 오해가 있었습니다.  하지만 잠깐만요. 반복적 모델을 사용하여 개발된 소프트웨어가 본질적으로 보안성이 낮다는 것을 뒷받침하는 증거가 있을까요? 만약 있다면, 내 '연구' (읽어보세요: (구글링)해도 잘 나오지 않아요.   

실제로, 더 빠른 전달 주기와 자동화되고 간소화된 릴리스 프로세스가 전반적인 취약성 노출 시간을 줄여 위험을 줄인다는 믿을 만한 주장을 할 수 있습니다.    

그렇다면 유연성과 보안 사이에 실제로 차이가 있을까요? 안타깝게도, 저는 여전히 그렇다고 말하고 싶습니다. 

그러나 저는 애자일 소프트웨어 라이프사이클이 더 많은 내재적 코드 취약성을 도입한다고 확신하지 못합니다(컨테이너 관리 시스템과 같은 일부 새로운 플랫폼은 확실히 공격할 수 있는 새로운 표면을 도입하지만). 애플리케이션 코드는 조직의 전반적인 보안 포스처의 일부일 뿐이기 때문입니다.

모든 소프트웨어에 결함이 있다는 점을 인식하고 IT 기술 스택에는 네트워크 방화벽, 침입 탐지 시스템, 웹 애플리케이션 방화벽과 같은 애플리케이션 코드 외부의 보안 제어 기능도 포함되어 있습니다. 이러한 시스템 중 다수는 애플리케이션 동작을 추적하고 프레임워크나 운영 체제에서 새로 발견된 위협에 대응해야 합니다. 이상적으로 이러한 시스템은 소프트웨어 제공 라이프사이클만큼 민첩해야 합니다. 그렇지 않으면 두 가지 일 중 하나가 발생합니다. 보안 제어가 제공 속도와 가치 실현 시간에 영향을 미치는 것으로 간주되거나, 보안 제어가 제자리에 놓인 보호를 제공하지 못하게 됩니다. 이 두 가지 중 어느 것도 정확히 최적이 아닙니다.  

가장 확실한 해결책은 보안 제어 모델을 소프트웨어 제공 라이프사이클 모델에 더 가까운 모델로 옮기는 것입니다. 실제로 DevSecOps 운동은 소프트웨어 엔지니어링과 DevOps 관행을 보안 제어를 제공하고 팀의 모든 구성원과 보안에 대한 책임을 공유하는 데 적용하기 시작했습니다. 심지어 심층적인 전문 지식이 고도로 경험이 풍부하고 전문적인 실무자 팀에 남아 있더라도 말입니다.

이러한 문화적 변화에 발맞춰 기술적 진화도 이루어지며, 보안 제어 구현이 소프트웨어 제공 파이프라인에 통합됩니다. 보안 제어 기능은 테스트, 스테이징, 배포 과정 전반에서 새로운 소프트웨어 반복 과정에 포함되는 것이지, 단순히 맨 마지막에 추가하는 것이 아닙니다. 원격 측정 및 추적 요소가 스택의 여러 지점에 주입되고 추적됩니다. 적을 식별하고 추적하고 보고하는 데 도움이 되는 새로운 지표를 신속하게 수집하여 분석할 수 있습니다. 

이를 실현하려면 기술 스택도 팀과 마찬가지로 협업이 이루어져야 합니다. 그것은 미래의 F5 + NGINX 조직에서 가장 흥미로운 가능성 중 하나입니다. 네트워크 방화벽부터 애플리케이션 서버까지, 그리고 그 사이의 모든 계층을 아우르는 포트폴리오를 통해, 보다 민첩하고 통합적이며 보다 많은 정보를 제공하는 보안 제어 세트에 대한 가능성이 매우 큽니다. 가벼운 민첩성과 함께 엔터프라이즈급 보안과 가시성을 제공함으로써 모든 팀원이 원하는 도구, 정보, 그리고 (상대적인) 마음의 평화를 얻을 수 있는 잠재력이 있습니다.

F5와 NGINX를 결합하는 것의 이점에 대해 자세히 알아보려면 F5 CEO가 소개한 'Bridging the Divide' 블로그 시리즈 게시물을 확인하세요.